From: Eric Biggers <email@example.com> To: Ard Biesheuvel <firstname.lastname@example.org> Cc: "open list:HARDWARE RANDOM NUMBER GENERATOR CORE" <email@example.com>, firstname.lastname@example.org, linux-arm-kernel <email@example.com>, Linux Kernel Mailing List <firstname.lastname@example.org>, Herbert Xu <email@example.com>, Paul Crowley <firstname.lastname@example.org>, Greg Kaiser <email@example.com>, Michael Halcrow <firstname.lastname@example.org>, "Jason A . Donenfeld" <Jason@zx2c4.com>, Samuel Neves <email@example.com>, Tomer Ashur <firstname.lastname@example.org> Subject: Re: [RFC PATCH v2 11/12] crypto: adiantum - add Adiantum support Date: Sat, 20 Oct 2018 00:12:07 -0700 [thread overview] Message-ID: <20181020071206.GE876@sol.localdomain> (raw) In-Reply-To: <CAKv+Gu9wrOOk-LGPYmxgLbv86uXzMeHN6th3mMEDT3Vg893HWw@mail.gmail.com> Hi Ard, On Sat, Oct 20, 2018 at 12:17:58PM +0800, Ard Biesheuvel wrote: > On 16 October 2018 at 01:54, Eric Biggers <email@example.com> wrote: > > From: Eric Biggers <firstname.lastname@example.org> > > > > Add support for the Adiantum encryption mode. Adiantum was designed by > > Paul Crowley and is specified by our paper: > > > > Adiantum: length-preserving encryption for entry-level processors > > (https://eprint.iacr.org/2018/720.pdf) > > > > See our paper for full details; this patch only provides an overview. > > > > Adiantum is a tweakable, length-preserving 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 AES-256 block cipher on a single > > 16-byte block. On CPUs without AES instructions, Adiantum is much > > faster than AES-XTS; for example, on ARM Cortex-A7, on 4096-byte sectors > > Adiantum encryption is about 4 times faster than AES-256-XTS 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 AES-256, > > 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 AES-256. 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
next prev parent reply other threads:[~2018-10-20 7:12 UTC|newest] Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-10-15 17:54 [RFC PATCH v2 00/12] crypto: " Eric Biggers 2018-10-15 17:54 ` [RFC PATCH v2 01/12] crypto: chacha20-generic - add HChaCha20 library function Eric Biggers 2018-10-19 14:13 ` Ard Biesheuvel 2018-10-15 17:54 ` [RFC PATCH v2 02/12] crypto: chacha20-generic - add XChaCha20 support Eric Biggers 2018-10-19 14:24 ` Ard Biesheuvel 2018-10-15 17:54 ` [RFC PATCH v2 03/12] crypto: chacha20-generic - refactor to allow varying number of rounds Eric Biggers 2018-10-19 14:25 ` Ard Biesheuvel 2018-10-15 17:54 ` [RFC PATCH v2 04/12] crypto: chacha - add XChaCha12 support Eric Biggers 2018-10-19 14:34 ` Ard Biesheuvel 2018-10-19 18:28 ` Eric Biggers 2018-10-15 17:54 ` [RFC PATCH v2 05/12] crypto: arm/chacha20 - add XChaCha20 support Eric Biggers 2018-10-20 2:29 ` Ard Biesheuvel 2018-10-15 17:54 ` [RFC PATCH v2 06/12] crypto: arm/chacha20 - refactor to allow varying number of rounds Eric Biggers 2018-10-20 3:35 ` Ard Biesheuvel 2018-10-20 5:26 ` Eric Biggers 2018-10-15 17:54 ` [RFC PATCH v2 07/12] crypto: arm/chacha - add XChaCha12 support Eric Biggers 2018-10-20 3:36 ` Ard Biesheuvel 2018-10-15 17:54 ` [RFC PATCH v2 08/12] crypto: poly1305 - add Poly1305 core API Eric Biggers 2018-10-20 3:45 ` Ard Biesheuvel 2018-10-15 17:54 ` [RFC PATCH v2 09/12] crypto: nhpoly1305 - add NHPoly1305 support Eric Biggers 2018-10-20 4:00 ` Ard Biesheuvel 2018-10-20 5:38 ` Eric Biggers 2018-10-20 15:06 ` Ard Biesheuvel 2018-10-22 18:42 ` Eric Biggers 2018-10-22 22:25 ` Ard Biesheuvel 2018-10-22 22:40 ` Eric Biggers 2018-10-22 22:43 ` Ard Biesheuvel 2018-10-15 17:54 ` [RFC PATCH v2 10/12] crypto: arm/nhpoly1305 - add NEON-accelerated NHPoly1305 Eric Biggers 2018-10-20 4:12 ` Ard Biesheuvel 2018-10-20 5:51 ` Eric Biggers 2018-10-20 15:00 ` Ard Biesheuvel 2018-10-15 17:54 ` [RFC PATCH v2 11/12] crypto: adiantum - add Adiantum support Eric Biggers 2018-10-20 4:17 ` Ard Biesheuvel 2018-10-20 7:12 ` Eric Biggers [this message] 2018-10-23 10:40 ` Ard Biesheuvel 2018-10-24 22:06 ` Eric Biggers 2018-10-30 8:17 ` Herbert Xu 2018-10-15 17:54 ` [RFC PATCH v2 12/12] fscrypt: " Eric Biggers 2018-10-19 15:58 ` [RFC PATCH v2 00/12] crypto: " Jason A. Donenfeld 2018-10-19 18:19 ` Paul Crowley 2018-10-20 3:24 ` Ard Biesheuvel 2018-10-20 5:22 ` Eric Biggers [not found] ` <email@example.com> 2018-10-22 11:20 ` Tomer Ashur 2018-10-19 19:04 ` Eric Biggers 2018-10-20 10:26 ` Milan Broz 2018-10-20 13:47 ` Jason A. Donenfeld 2018-11-16 21:52 ` Eric Biggers 2018-11-17 10:29 ` Milan Broz 2018-11-19 19:28 ` Eric Biggers 2018-11-19 20:05 ` Milan Broz 2018-11-19 20:30 ` Jason A. Donenfeld 2018-10-21 22:23 ` Eric Biggers 2018-10-21 22:51 ` Jason A. Donenfeld 2018-10-22 17:17 ` Paul Crowley
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20181020071206.GE876@sol.localdomain \ --firstname.lastname@example.org \ --cc=Jason@zx2c4.com \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: [RFC PATCH v2 11/12] crypto: adiantum - add Adiantum support' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).