I'm a bit more ambitious... We should specify NIST-style CTR mode for all octet stream applications within the IETF's domain, with SSL/TLS as an example. For record-based systems, I don't know if NIST-style or IPsec-style would be more appropriate :-(
There is no such thing as NIST-style. There's Helger Lipmaa's suggestion, and that's really it. A 64-bit counter offers the misleading sense that it is safe to use more than 2^32 blocks of keystream.
CTR mode offers very little advantage over CBC or CFB or OFB -- the motivation for IPsec was very high speed, parallel encryption with precomputation of the keystream (according to the Rt. Hon. Rev. Bellovin, IETF Security Area co-chair).
Can someone explain why the IPsec folks felt they needed to reimplement CTR mode, especially in a way which appears to create more problems?
Yes. SSL/TLS have the advantage of operating over TCP -- where replay, delayed duplicates, out-of-order delivery, fragmentation, etc. are all handled magically and elsewhere. IPsec operates via a connectionless medium with no delivery guarantees (IP).
Obviously we don't need nonces, just counters.
______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
