lists.openwall.net  lists / announce owlusers owldev johnusers johndev passwdqcusers yescrypt popa3dusers / osssecurity kernelhardening musl sabotage tlsify passwords / cryptdev xvendor / Bugtraq FullDisclosure linuxkernel linuxnetdev linuxext4 PHC  
Open Source and information security mailing list archives
 

Date: Sat, 20 Oct 2018 00:12:07 0700 From: Eric Biggers <ebiggers@...nel.org> To: Ard Biesheuvel <ard.biesheuvel@...aro.org> Cc: "open list:HARDWARE RANDOM NUMBER GENERATOR CORE" <linuxcrypto@...r.kernel.org>, linuxfscrypt@...r.kernel.org, linuxarmkernel <linuxarmkernel@...ts.infradead.org>, Linux Kernel Mailing List <linuxkernel@...r.kernel.org>, Herbert Xu <herbert@...dor.apana.org.au>, Paul Crowley <paulcrowley@...gle.com>, Greg Kaiser <gkaiser@...gle.com>, Michael Halcrow <mhalcrow@...gle.com>, "Jason A . Donenfeld" <Jason@...c4.com>, Samuel Neves <samuel.c.p.neves@...il.com>, Tomer Ashur <tomer.ashur@...t.kuleuven.be> Subject: Re: [RFC PATCH v2 11/12] crypto: adiantum  add Adiantum support Hi Ard, On Sat, Oct 20, 2018 at 12:17:58PM +0800, Ard Biesheuvel wrote: > On 16 October 2018 at 01:54, Eric Biggers <ebiggers@...nel.org> wrote: > > From: Eric Biggers <ebiggers@...gle.com> > > > > Add support for the Adiantum encryption mode. Adiantum was designed by > > Paul Crowley and is specified by our paper: > > > > Adiantum: lengthpreserving encryption for entrylevel processors > > (https://eprint.iacr.org/2018/720.pdf) > > > > See our paper for full details; this patch only provides an overview. > > > > Adiantum is a tweakable, lengthpreserving encryption mode designed for > > fast and secure disk encryption, especially on CPUs without dedicated > > crypto instructions. Adiantum encrypts each sector using the XChaCha12 > > stream cipher, two passes of an εalmost∆universal (εA∆U) hash > > function, and an invocation of the AES256 block cipher on a single > > 16byte block. On CPUs without AES instructions, Adiantum is much > > faster than AESXTS; for example, on ARM CortexA7, on 4096byte sectors > > Adiantum encryption is about 4 times faster than AES256XTS encryption, > > and decryption about 5 times faster. > > > > Adiantum is a specialization of the more general HBSH construction. Our > > earlier proposal, HPolyC, was also a HBSH specialization, but it used a > > different εA∆U hash function, one based on Poly1305 only. Adiantum's > > εA∆U hash function, which is based primarily on the "NH" hash function > > like that used in UMAC (RFC4418), is about twice as fast as HPolyC's; > > consequently, Adiantum is about 20% faster than HPolyC. > > > > This speed comes with no loss of security: Adiantum is provably just as > > secure as HPolyC, in fact slightly *more* secure. Like HPolyC, > > Adiantum's security is reducible to that of XChaCha12 and AES256, > > subject to a security bound. XChaCha12 itself has a security reduction > > to ChaCha12. Therefore, one need not "trust" Adiantum; one need only > > trust ChaCha12 and AES256. Note that the εA∆U hash function is only > > used for its proven combinatorical properties so cannot be "broken". > > > > So what happens if the part of the input covered by the block cipher > is identical between different generations of the same disk block > (whose sector count is used as the 'outer' IV). How are we not in the > same boat as before when using stream ciphers for disk encryption? > This is the point of the hash step. The value encrypted with the block cipher to produce the intermediate value C_M (used as the stream cipher nonce) is H(T, P_L) + P_R. (T is the tweak a.k.a the IV, P_L is the plaintext except the last 16 bytes, P_R is the last 16 bytes.) A collision in this value occurs iff: H(T1, P1_L) + P1_R = H(T2, P2_L) + P2_R i.e. H(T1, P1_L)  H(T2, P2_L) = P2_R  P1_R If (T1, P1_L) = (T2, P2_L) then P1_R != P2_R so the equation has no solutions (since we don't consider queries where the whole input is the same; those unavoidably produce the same ciphertext). Otherwise (T1, P1_L) != (T2, P2_L), and since the hash function H is εalmost∆universal over integers mod 2^128, the equation is true for at most a very small proportion 'ε' of hash keys. But, the hash key is chosen at random and is unknown to the attacker. The same applies in the other direction, for chosen ciphertext attacks. Basically, it's very difficult for an attacker to cause the intermediate value C_M to be reused, and the outputs will appear random until they do. Of course, all this is explained much more precisely and comprehensively in our paper. See section 5, "Security reduction".  Eric
Powered by blists  more mailing lists