Re: Question w.r.t. AES-CBC IV
Ralph Holz ralph-cryptometz...@ralphholz.de writes: CTR mode seems a better choice here. Without getting too technical, security of CTR mode holds as long as the IVs used are fresh whereas security of CBC mode requires IVs to be random. Unfortunately CTR mode, being a stream cipher, fails completely if the IV's/keys aren't fresh (as you could force them to be for SRTP under SIP by attacking the crypto handshake that preceded it, a nice example of attacking across a protocol boundary, taking advantage of a weakness in one protocol to break a second), while CBC only becomes a bit less secure. In addition CTR mode fails trivially to integrity attacks, while with CBC it's often more obvious (you get at least some total corruption before the self-healing takes effect). The problem with CTR is that, like RC4, it's very brittle, make a tiny mistake anywhere and you're toast. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Question w.r.t. AES-CBC IV
Ralph Holz ralph-cryptometz...@ralphholz.de writes: CTR mode seems a better choice here. Without getting too technical, security of CTR mode holds as long as the IVs used are fresh whereas security of CBC mode requires IVs to be random. Unfortunately CTR mode, being a stream cipher, fails completely if the IV's/keys aren't fresh (as you could force them to be for SRTP under SIP by attacking the crypto handshake that preceded it, a nice example of attacking across a protocol boundary, taking advantage of a weakness in one protocol to break a second), while CBC only becomes a bit less secure. In addition CTR mode fails trivially to integrity attacks, while with CBC it's often more obvious (you get at least some total corruption before the self-healing takes effect). The problem with CTR is that, like RC4, it's very brittle, make a tiny mistake anywhere and you're toast. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Question w.r.t. AES-CBC IV
Ralph Holz writes: He wanted to scrape off some additional bits when using AES-CBC because the messages in his concept are very short (a few hundred bit). So he I'd rather have a known-safe design than to save 12 bytes. Seriously: what the hell. Say you have 1-byte messages, and that the cryptography will expand them to 128 bytes (...you use a MAC, right?). If this overhead factor is really bad for you, for example because you expect to send thousands of messages per second, your problem is a bad protocol design. Don't break the safety mechanism to support an inefficient protocol. Alternately, if you send messages only rarely, the overhead doesn't matter. My point is, since you have tiny messages, throughput must not be your goal. And yet, even with 128-byte messages, your messages are so small that latency and bloat are not problems. You get confidential and MAC'd communications for less than the cost of a tweet or SMS. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Question w.r.t. AES-CBC IV
Jerry Leichter wrote: CTR mode is dangerous unless you're also doing message authentication, Nitpick: That's true of CBC mode, too, and almost any other encryption mode. Encryption without authentication is dangerous; if you need to encrypt, you almost always need message authentication as well. (I will agree that CTR mode encryption without message authentication is often even more dangerous than CBC mode encryption without message authentication, but usually neither is a good idea.) Setting that minor nitpick aside, the discussion here seems like good advice. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Question w.r.t. AES-CBC IV
Dear all, A colleague dropped in yesterday and confronted me with the following. He wanted to scrape off some additional bits when using AES-CBC because the messages in his concept are very short (a few hundred bit). So he was thinking about a variant of AES-CBC, where he uses just 32 (random) bits as a source for the IV. These are encrypted with AES and then used as the actual IV to feed into the CBC. As a result, he does not need to send a 128 bit IV to the receiver but just the 32 bit. His argument was that AES basically is used as an expansion function for the IV here, with the added benefit of encryption. On the whole, this should not weaken AES-CBC. Although he was not sure if it actually would strengthen it. While I am prepared to buy this argument (I am not a cryptographer...), I still felt that the argument might not be complete. After all, 32 bits don't provide much randomness, and I wasn't sure if this, overall, would not lead to more structure in the ciphercode - which might in turn give an attacker more clues with respect to the key. Are there any opinions on this? Regards, Ralph - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Question w.r.t. AES-CBC IV
CTR mode seems a better choice here. Without getting too technical, security of CTR mode holds as long as the IVs used are fresh whereas security of CBC mode requires IVs to be random. In either case, a problem with a short IV (no matter what you do) is the possibility of IVs repeating. If you are picking 32-bit IVs at random, you expect a repeat after only (roughly) 2^16 encryptions (which is not very many). On Wed, 2 Jun 2010, Ralph Holz wrote: Dear all, A colleague dropped in yesterday and confronted me with the following. He wanted to scrape off some additional bits when using AES-CBC because the messages in his concept are very short (a few hundred bit). So he was thinking about a variant of AES-CBC, where he uses just 32 (random) bits as a source for the IV. These are encrypted with AES and then used as the actual IV to feed into the CBC. As a result, he does not need to send a 128 bit IV to the receiver but just the 32 bit. His argument was that AES basically is used as an expansion function for the IV here, with the added benefit of encryption. On the whole, this should not weaken AES-CBC. Although he was not sure if it actually would strengthen it. While I am prepared to buy this argument (I am not a cryptographer...), I still felt that the argument might not be complete. After all, 32 bits don't provide much randomness, and I wasn't sure if this, overall, would not lead to more structure in the ciphercode - which might in turn give an attacker more clues with respect to the key. Are there any opinions on this? Regards, Ralph - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Question w.r.t. AES-CBC IV
Unfortunately I can't remember the author, but there was a paper showing that an encrypted counter was secure to use as IVs for CBC mode. So encrypting a shorter random IV should also be secure. Greg. On 2010 Jun 2, at 9:36 , Ralph Holz wrote: Dear all, A colleague dropped in yesterday and confronted me with the following. He wanted to scrape off some additional bits when using AES-CBC because the messages in his concept are very short (a few hundred bit). So he was thinking about a variant of AES-CBC, where he uses just 32 (random) bits as a source for the IV. These are encrypted with AES and then used as the actual IV to feed into the CBC. As a result, he does not need to send a 128 bit IV to the receiver but just the 32 bit. His argument was that AES basically is used as an expansion function for the IV here, with the added benefit of encryption. On the whole, this should not weaken AES-CBC. Although he was not sure if it actually would strengthen it. While I am prepared to buy this argument (I am not a cryptographer...), I still felt that the argument might not be complete. After all, 32 bits don't provide much randomness, and I wasn't sure if this, overall, would not lead to more structure in the ciphercode - which might in turn give an attacker more clues with respect to the key. Are there any opinions on this? Regards, Ralph - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Question w.r.t. AES-CBC IV
On Jul 9, 2010, at 1:55 12PM, Jonathan Katz wrote: CTR mode seems a better choice here. Without getting too technical, security of CTR mode holds as long as the IVs used are fresh whereas security of CBC mode requires IVs to be random. In either case, a problem with a short IV (no matter what you do) is the possibility of IVs repeating. If you are picking 32-bit IVs at random, you expect a repeat after only (roughly) 2^16 encryptions (which is not very many). Unless I misunderstand your point, I think that in the real world there's a very real difference in the insecurity of CBC vs CTR if the IV selection is faulty. With CBC, there is semantic insecurity, in that one can tell if two messages have a common prefix if the IV is the same. Furthermore, if the IV is predictable to the adversary under certain circumstances some plaintext can be recovered. With CTR, however, there are very devastating two-message attacks if the IVs are the same; all that's necessary is some decent knowledge of some probable plaintext. --Steve Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Question w.r.t. AES-CBC IV
On Jul 9, 2010, at 1:55 PM, Jonathan Katz wrote: CTR mode seems a better choice here. Without getting too technical, security of CTR mode holds as long as the IVs used are fresh whereas security of CBC mode requires IVs to be random. In either case, a problem with a short IV (no matter what you do) is the possibility of IVs repeating. If you are picking 32-bit IVs at random, you expect a repeat after only (roughly) 2^16 encryptions (which is not very many). CTR mode is dangerous unless you're also doing message authentication, which will require an additional block or thereabouts - so if the goal is to minimize bit overhead, it's not really appropriate here (unless it's being included anyway). The small number of encryptions before the IV repeats is the principle problem I see. But there are a number of ways around it depending on overall system details we don't have. Two examples: - If each pair of communicating endpoints can keep state information, you don't even have to send the IV: Agree once on a secret key, then use CTR mode to generate an IV by encrypting the message sequence number (which might or might not be included in the message itself). - Widen the 32-bit IV you send with other information. If you include the end-point ID's, then you only have to worry about possible clashes between IV's generated for the same pair of endpoints, or even for the pair in the same direction. (That's not *quite* true, but it's close to true.) If the two ends can agree on the date and time even roughly - say to the nearest minute - then you can mix that in as well. Now you have to worry about a 50% chance of a clash if the same pair starts up 2^16 connections within in a minute - probably not likely enough to worry about. -- Jerry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
