Do you know AES-NI also support AES/GCM (Gaulois Counter Mode)? I have read several articles that advise to use AES/GCM as a replacement of RC4, as it address some of the problems with AES/CBC (known plaintext attack).
Mark On Tue, 15 Sep 2015 11:22:22 -0400, Jim Starkey <j...@jimstarkey.net> wrote: > I've done some moderately careful performance apples to apples > comparisons for various crypto functions with not very surprising > results. In general: > > AES-NI < RC4 < ChaCha20 < AES (software) > > The two AES functions, the Botan software version and the DJ Bernstein > NI (new instructions) version, were each computed with an CBC/CTS > wrapper. All functions were then tested with a Transform wrapper. > > The specific numbers from a Win8 Intel Desktop were for 10 MB encode / > decode: > > AES-NI: .040 seconds > RC4: .060 > ChaCha20: .080 > AES: .100 > > Each number was the floor of three runs, code compiled for Release. > > Some notes: > > 1. As Sean pointed out, the AES instructions are common on Intel > processors. Not so for AMD, however, which only supports AES in > their high end server chips. My HP AMD mini-tower, for example, > doesn't have the AES instruction set. This means that the crypto > systems must do a runtime check for AES hardware support. > 2. Simple comparisons between hardware and software AES are next to > meaningless. By the time you handle block chaining and cipher text > stealing, the necessary overhead dilutes the raw performance > difference. > 3. The Botan AES function was 11X the performance as the AES > implementation I had been using. Details on request. > 4. The Botan crypto library has a good license, good performance, and > is a pain in the butt to work with. One of their apparent goals was > to use every possible C++ feature. Pulling AES out of their rich > and bloated infrastructure took more days than I care to think about. > 5. The Botan AES-NI implementation doesn't seem to work, at least not > when extracted. Don't know why. > 6. The DJ Bernstein AES-NI was as simple and elegant as the Botan > library was complex. It was C that could be dropped into a C++ > wrapper without change. And it has a better license. > 7. The ChaCha20 implementation is probably less than optimal. I'm > prepared to let it stay that way. > > Bottom line: I'm inclined to agree with Sean that AES-NI always wins > and software AES doesn't lose by much, but the difference is nowhere as > much as hyped. ------------------------------------------------------------------------------ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
