On 04/09/18 17:53, Arno Wagner wrote: > On Tue, Sep 04, 2018 at 14:49:29 CEST, Christoph Anton Mitterer wrote: >> On Mon, 2018-09-03 at 09:48 +0200, Milan Broz wrote: >>> sorry for long delay, I was most of the time offline. >> Thanks, and no worries :-) >> >> >>> On 19/08/18 19:27, Christoph Anton Mitterer wrote: >>>> - ChaCha20 seems to have all 128 bit IV... but is this correct? >>>> I've >>>> modpobed chacha20poly1305 ... but at least ther's no reference to >>>> poly1305 in /proc/crypto >>> >>> No, we use RFC7539 wrapper for Chacha20-poly1305 and here the nonce >>> is >>> only 96bit. >>> >>> So the same probability of collision as in GCM, just a nonce >>> collision >>> does not cause such fatal failure as in GCM. >> >> Are there any plans to provide ChaCha20/Poly1305 with larger nonces in >> the future? I don't think so. The dmcrypt use case is quite special and for network protocols it is ok (you will regenerate encryption key after some time anyway). > I don't think that is a concern. 96bit, even if randomly chosen, > is unlikely to collide in the remaining lifetime of this star-system. Nonce is here generated on every sector write, if you can record all sector writes (usually not the case though), then it depends on probability of collision you need. And people noted, I think I posted it here already https://twitter.com/solardiz/status/882163531176697857 This is for GCM though but it illustrates the problem. If we want to use AEAD FDE in future, I vote for doing no compromises and just use 128bit random nonces/IVs, that is really enough :) (There will be perhaps need to reencrypt device/change key after some time anyway.) Milan _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx https://www.saout.de/mailman/listinfo/dm-crypt
