On 9/18/2015 3:05 PM, Boris Damjanovic wrote: > I would like to bring your attention to the AES-XTS mode > - http://csrc.nist.gov/publications/nistpubs/800-38E/nist-sp-800-38E.pdf > and to the CTR mode > - http://csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf > - https://tools.ietf.org/html/rfc4106 > - > http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/proposedmodes/ctr/ctr-spec.pdf > They both are good candidates for parallelization.
The choice of algorithm is highly application dependent. Sha-1, for example, is a poor choice for message digest or digital signature, but perfectly fine as used in git or PBKDF2. Similarly, PBKDF2 and bcrypt are fine client side but an unmitigated disaster server side. Nobody is going to argue that CTR mode can be parallelized and CBC cannot. But the cost of thread switching in a server makes CTR mode substantially more expensive that CBC mode. And even if thread switching were free, the same number of cost of AES transformations is the same, so on a CPU constrained server, the parallelism buys nothing. On the client side with more cores than tasks, there is a tiny latency benefit of CTR, but if the limiting factor is the server, there is no gain. Another consideration is what an encryption algorithm is supposed to do. Is it just to render the data unreadable to a third party? Does it also need to validate the integrity of message? Does it also need to establish the identity of the sender? There are modes that do two or three of these, but all add overhead to data, add substantial cost to encryption and decryption, and add substantial complexity to the implementation. If one were implementing a secure service based on UDP, these costs would be fully justified. A virtual circuit (e.g. TCP) with mutual authentication by SRP, however, doesn't. People are always going to cherry pick "weaknesses" of any algorithm from the vast mountains of gibberish on the Internet. One could learned, for example, that with CBC it may be possible to change the value of a chosen byte, but the fine print adds the cost of turning the previous 16 bytes in utter randomness. Or that you can attack padding algorithms if you have an "oracle" that you can submit hundreds of thousands of chosen messages for padding validations. The astute reader should pick up that database server protocols don't provide such a service, and without both an oracle and a bad padding mechanism, this doesn't mean anything (and even if one did, it still would reveal the key). > > On 9/15/2015 7:42 PM, Jim Starkey wrote: >> On 9/15/2015 12:57 PM, Leyne, Sean wrote: >>>> None of these suggest that there is an attack -- read the comments. >>> They refer to a possible attack and provide links to other sites. One of >>> the sites has a link to the following: >>> >>> http://www.iacr.org/archive/eurocrypt2002/23320530/cbc02_e02d.pdf >>> >>> which (at least to my scanned reading) suggest that the is a vulnerability >>> to CBC mode ciphers... >>> >>> >> No, it's actually about the pitfalls of padding when using CBC. Cipher >> text stealing (CTS) is an alternative to padding. The argument against >> CTS is that in some applications it may make message traffic analysis >> possible because it exposes the length of the encrypted message. That >> and $2.00 will get you a cup of coffee at Starbucks. >> >> We all know about an infinite number of monkeys recreating Shakespeare. >> A real life analog is the number junior academics trying to get >> published with pinpricks in solid technology. Much of it boils down to >> the quite uninteresting fact that if you corrupt the ciphertext, you >> corrupt the decrypted text as well. Well, duh. >> >> The article you referenced assumes an oracle to which you can submit >> artificial "ciphertext" and it will tell you whether it conforms to a >> known format after decryption. Enough probes on a packet with known >> padding and you might learn something. Well, duh. >> >> But none of this is about streams on a virtual circuit, e.g. TCP, with >> running stream or CBC ciphers. If you have an environment like UDP >> where somebody could slip you a bogus packet, then you need signed >> messages, but that's not the issue here. >> >> ------------------------------------------------------------------------------ >> 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 ------------------------------------------------------------------------------ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
