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

Reply via email to