On Mon, Oct 21, 2002 at 11:53:41AM -0500, Stephen Sprunk wrote: > My reading of Rogaway's CTR submission was a nonce in the top half of > the counter with a simple increment (by one) of the whole counter. Is > there a new spec we need to comply with?
Look at NIST Special Publication 800-38A. The specification for CTR mode does not mandate any format for the counter or any particular function for incrementing the counter. It mentions both the technique of combining a nonce with a counter and using a counter that starts at any possible value (such as 0). The problem with using half of the counter block as a nonce only really shows up when using ciphers with 64-bit blocks. A 32-bit counter value doesn't allow for a large number of possible messages all things considered (e.g., gigabit+ pipes with long-term connections). Basically, I believe that CTR mode should be the low-level API. The user should set the IV as appropriate, and his own counter function if it should be something other than "add 1 to this block-sized big-endian value". Higher level functionality that the end-user isn't going to screw up is also very important to provide in an API, IMHO. That's why CCM mode in particular is something I feel very strongly about... not only does it require a nonce and specify the packet layout, it also performs integrity checking all with a single key. If people used a high-level CCM-based interface instead of a low-level CBC-based API, many of the most common crypto errors I see in software would become pretty scarce. > What is the correct behavior of CTR when it reaches 2^64 (or whatever > lower limit IPsec et al may set)? I'd assumed that it was safe to > wrap to zero and keep counting. Do you have a suggested > implementation for how to set a lower limit? No, if you go through 2^64 counters when you're only using 64 bits for a counter, then it is incorrect to perform any operations whatsoever. The IPSec AES-CTR doc, IIRC specifies that you should error. I think in practice, 2^64 is a number people may not reach in practice. I think having an option to specify whether you want to skip the extra check is a good idea. BTW, I already provided Russ Housley with a second reference implementation of the CTR stuff for IPSec, so I definitely have working test vectors, etc. > The modes should probably be written as macros, yes. Unfortunately, > some cipher implementations don't call an ECB function but actually > implement the cipher inside the mode; switching to mode macros will be > very tricky. It's not actually very difficult. I've actually finished a first pass that works very well. I've implemented CBC, CFB, OFB, CTR and CCM, all on top of the API that the EVP ECB calls ultimately call. Along the way, I've also added a CBC-MAC implementation (particularly due to its use in CCM mode), and I'll probably implement RMAC as well. Basically, I'm writing an alternative to the EVP block cipher API. It is shaping up to be more powerful for the end user, including more high-level and even some new low-level things that aren't in the EVP interface. It will clearly be more extensible since you'll only have to add a single macro call to support every single mode for a new block cipher. Due to real life time constraints, I probably need a full week to polish everything up and to produce a comprehensive set of tests to help minimize the number of bugs. Currently I'm relying on EVP context objects and piggybacking off the EncryptInit call. I'm going to undo all of that, and I might take the time to properly hook this stuff up to the engine work. I'll definitely contribute the code when I'm about to move on to other things, though. John ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
