Daniel Migault writes: > <mglt> > Correct. it must be a MUST. I also explicitly added that condition on nonce > and counter needs to remain valid. The new text is as follows: > > When such mechanisms cannot be implemented and the session key is, for > example, provisioned, the nodes MUST ensure that keys are not used beyond > their life time and that the appropriate use of the key remains across reboots > - e.g. conditions on counters and nonces remains valid. > > </mglt>
Looks ok. > Normally you use just counter, and encrypt it with secret key. The IV > in CBC does not be random, it needs to be unpredictable and it should > not be direct counter or other source with low Hamming distance > between successive IVs. > > Actually the problem with old way of CBC mode was that the IV was > random, but predictable as implementations used last block of previous > packet. If attacker does not know the key you are using to encrypt the > counter to generate IVs, the IVs will be unpredictable and random. > > <mglt> > Thanks for the information. What I was wondering then, is for which reason > can't we consider this as a random generator - of a limited lifetime. > </mglt> That method is very common piece used when you are making random number generator. It is for example part of the NIST AES Counter mode based generator, but to properly make random number generator out of that need bit more stuff around it. For example you need to make sure it is rekeyed before the counter rolls over, and of course it is only as secure as the random secret key you are using to seed it etc. See NIST SP 800-90A REv 1 [1] CTR_DRBG description for more information. [1] https://csrc.nist.gov/publications/detail/sp/800-90a/rev-1/final -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
