-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Dec 27, 2012, at 13:46, Jeffrey Walton <[email protected]> wrote:
> On Thu, Dec 27, 2012 at 1:35 PM, Ben Laurie <[email protected]> wrote: >> On Thu, Dec 27, 2012 at 9:18 AM, Russell Leidich <[email protected]> wrote: >>> there are plenty of Googleable papers showing the Counter Mode is weak >>> relative to (conventional) cipher-block-chaining (CBC) AES. >> >> Really? For example? > I believe CTR mode is especially sensitive to key/nonce reuse. But you > don't see the problem until you look at messages over time and space. > Confer: CTR mode uses a predictable counter, while CBC mode uses a > random (not unique) IV. > > I could be wrong since I'm working from memory (it sucks getting old). > I'd need to get into the literature to give you anything useful > (citable). Not really, and kinda sorta at the same time. Counter mode is a stream cipher. The general construction of a stream cipher where you generate a key stream and stamp the key stream onto plaintext (XOR being the usual stamping function) is vulnerable to key reuse. If you reuse a key, then you can use known plaintext to extract the key stream and then decrypt other message. Even one time pads are vulnerable to this (hence the necessity to use them only once). Counter mode is not more vulnerable than any other stream cipher to the fatal error of key reuse. So the major quibble is with the word "especially" only. Don't reuse keys. But on the other hand, if you follow the simple procedure of getting you keys for your RNG, it isn't worth worrying any more about. If you assume a decent block cipher (and no key reuse), then you could always start counter mode from a fixed point (like zero). Breaking counter mode is simply a known plaintext attack on the cipher, and a decent cipher ought to be resilient against known plaintext and an unknown key. If you make the counter be a nonce, it helps things some. Less if it is a public parameter, more if it is private, but if it really matters, you need a new block cipher -- or stop reusing your keys. It is foolish either to use a nonce as a way to cover for errors in the cipher or key selection. That doesn't mean nonces are bad, any more than icing is bad on a cake. CBC mode has the improvement over counter mode that it uses the plaintext as an input variable into the encryption (as does CFB, just differently). You can think of CBC as XORing the plaintext onto the counter (or nonce) that is the Initialization Vector and then encrypting that. CFB encrypts the nonce like CTR and XORs onto plaintext to yield cipher text. Each of them then uses the cipher text as the new nonce/counter/whatever. In either of them, the IV (nonce) ought to be arbitrary, which really only means that it should be random, but it isn't a secret. Entangling the plaintext into the operation makes key reuse mildly less awful than with a straight stream cipher, but it is still a fatal error. If you ever have any doubt about how horrible it is to reuse a key, go read or re-read the Venona papers and see what a motivated attacker can do to exploit key reuse. On the other hand, good nonce management is good hygiene and stream ciphers are much more delicate than block ciphers. But bad nonce management, reusing keys, and known plaintext are just asking for trouble no matter what. CBC mode has its own special vulnerabilities, too. The BEAST attack on SSL exploited those, and the "fix" against that is to use RC4 (a stream cipher). Anyway, key reuse is just bad. Counter mode with a naive counter is maximally bad, but CBC with a naive IV isn't a whole lot batter. CBC mode uses any unknownness in the plaintext to maximal effect. The bottom line is never reuse a key (sorry for keeping repeating this), nonces are good, and there are reasons we tend to use block ciphers over stream ciphers these days. And of course a skilled programmer can screw up the best cryptography. Jon -----BEGIN PGP SIGNATURE----- Version: PGP Universal 3.2.0 (Build 1672) Charset: us-ascii wj8DBQFQ3M+osTedWZOD3gYRAl1jAKDmtHpIRptLV2FuMQ2knEKQAfhALACfVgNx MHyxs+zwONPxgfqF8c9MdGs= =hehH -----END PGP SIGNATURE----- _______________________________________________ cryptography mailing list [email protected] http://lists.randombit.net/mailman/listinfo/cryptography
