Thanks for the response and the reference. The Security Considerations referred to 4086, but I thought that it would be useful to add the reference from the nist. I have added the following sentence.
""" In addition [SP-800-90A-Rev-1] provides appropriated guidances to build random generators based on deterministic random functions. """ I believe that we do not necessarily need to go into more details that are related to specific transforms, but I am happy to hear otherwise. Yours, Daniel On Mon, Nov 2, 2020 at 9:00 AM Tero Kivinen <kivi...@iki.fi> wrote: > 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 > -- Daniel Migault Ericsson
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
