I don't know of any known problems with AES/CBC. It is simply the most trusted crypto algorithm in the history of computing. It isn't possible prove that something can't be broken, but many, many very smart people have spent many years searching for an attack over 15+ years without success.
If you have a pointer to an AES/CBC "problem", could you share it? On 9/15/2015 12:08 PM, Mark Rotteveel wrote: > 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 ------------------------------------------------------------------------------ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
