[Cryptography] Odd bit of security advice
Peter Fairbrother
peter at tsto.co.uk
Mon Jun 4 23:06:37 EDT 2018
On 05/06/18 01:27, Jerry Leichter wrote:
> In another thread, Jason Cooper quoted the following:
>
> [1] https://datatracker.ietf.org/doc/rfc7539/?include_text=1
> Section 4: Security Considerations
> "The most important security consideration in implementing this
> document is the uniqueness of the nonce used in ChaCha20. Counters
> and LFSRs are both acceptable ways of generating unique nonces, as is
> encrypting a counter using a 64-bit cipher such as DES. Note that it
> is not acceptable to use a truncation of a counter encrypted with a
> 128-bit or 256-bit cipher, because such a truncation may repeat after
> a short time."
>
> It's that last comment - that the bottom 64 bits of a counter encrypted with a 128- or 256-bit cipher may repeat after a short time - that really puzzles me. Surely any 128- or 256-bit cipher with this property would immediately fail certification, as it would be easily distinguishable from a random permutation.
Well, by a short time they mean once every 2^64 (or whatever the
truncation is) operations.
Whether a certification test would pick that behaviour up would depend
on how the certification was done: if by analysis of the code, then yes,
using a 64-bit truncation would cause certification failure.
However in order for a Monte Carlo type test to detect this behaviour it
would need to compare > 2^64 outputs and look for duplicates - not
something done in most certification tests.
Incidentally, if you do use the bottom 64 bits and generate less than
2^64 messages, you still have unique nonces. After 2^64 messages (with
the same key...) you start to get into trouble.
Also incidentally, if you have to randomly reset the counter every so
often, in order to get say 128-bit security you would need a >128-bit
counter - it depends on how many messages are sent.
Suppose you send 2^64 messages then randomly reset a 128-bit counter,
rinse, repeat - the chance of a collision is then 1 in 2^64 (= the
chance that the first 64 bits are the same).
Add more resets however, and you are birthdaying in 2^64, not in 2^128.
After 2^32 resets or 2^96 messages you would have a collision.
To get 128-bit security you would need 128 bits (for the birthday) plus
the 64 lower bits. And even that is only good for 2^96 messages.
-- Peter Fairbrother
>
> What am I missing?
> -- Jerry
>
> _______________________________________________
> The cryptography mailing list
> cryptography at metzdowd.com
> http://www.metzdowd.com/mailman/listinfo/cryptography
>
More information about the cryptography
mailing list