Hi, thanks for asking, actually this is probably the best way how to get some feedback On 01/13/2018 05:57 PM, Geo Kozey wrote: > Hi, I have two more questions, this time about new experimental ciphers with > authentication. > > 1. What happens when integrity check fails during unlocking container, i.e. > due to data corruption? Can we still unlock such container? Unlocking should never fail because of data integrity check (only if a keyslot or both LUKS2 header copies are corrupted. Then it is basically the same problem like in corrupted LUKS1 header - you have to use backup header). IOW: unlocking (luksOpen) will always map the device, only the later access to device could fail with integrity error (that is propagated to userspace as IO error). You can overwrite such a failed sectors using direct-io write to fix auth tags then. > 2. I know there is a IV reuse problem with current AE ciphers. What amount of > data (roughly) can be written to disk before probability of such reuse will be > significant? This is very interesting question and I expected to have some more formal analysis. Unfortunately, math people I asked lost interest, so below is my short explanation. It should be in accordance of more qualified people that noted it immediately here https://twitter.com/solardiz/status/882163531176697857 :-) So, my analysis: We have a sector that uses 96-bit randomly generated nonce used for IV, if we used birthday paradox, we should expect collision after 2^48 (half of 2^96) generated nonces. The nonce is generated for every sector write, so simple multiplication gives us 128 PB for 512-byte sectors or 1024 PB for 4k-sectors. Unfortunately, for GCM mode, NIST (in SP 800-38D) limits total number of IV invocations for the same key to 2^32. This means (according to SP above) we should have problem after writing of 2 TB of data for 512-bytes sector or 16 TB with 4k-sector. This is pretty bad. For Chacha20-poly1305 it internally uses also 96bit nonce (we use it in RFC7539 mode). I do not have more formal analysis here, it should not be worse though. (The attack above expects attacker can store all sector changes including auth. tags.) So, my plan is to switch to more secure authenticated modes in future, and actually we have already very nice progress - Ondra Mosnacek implemented AEGIS and MORUS ciphers from CAESAR competition and specifically for AEGIS the performance in dm-crypt looks very good. But the CAESAR is not yet finished and tweaks are expected... If you are interested, read his master thesis, it is not yet defended, but the text should be already public here https://is.muni.cz/th/409879/fi_m/masters-thesis.pdf (or from here https://is.muni.cz/th/409879/fi_m?lang=en ) The text also compares existing modes (like GCM). Using of these modes should solve the problem for real, because with at least 128bit nonces and kind-of nonce reuse resistance we should not have the problem above. HTH, Milan _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
