diff for duplicates of <20181024220614.GA13497@gmail.com> diff --git a/a/1.txt b/N1/1.txt index 6efb4f5..63908ce 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -17,7 +17,7 @@ On Tue, Oct 23, 2018 at 07:40:34AM -0300, Ard Biesheuvel wrote: > >> > 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 +> >> > 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 @@ -26,8 +26,8 @@ On Tue, Oct 23, 2018 at 07:40:34AM -0300, Ard Biesheuvel wrote: > >> > > >> > 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 +> >> > 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. > >> > @@ -36,7 +36,7 @@ On Tue, Oct 23, 2018 at 07:40:34AM -0300, Ard Biesheuvel wrote: > >> > 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 +> >> > trust ChaCha12 and AES-256. Note that the ?A?U hash function is only > >> > used for its proven combinatorical properties so cannot be "broken". > >> > > >> @@ -58,8 +58,8 @@ On Tue, Oct 23, 2018 at 07:40:34AM -0300, Ard Biesheuvel wrote: > > 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. +> > 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. diff --git a/a/content_digest b/N1/content_digest index 001ff96..abd26ec 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -3,21 +3,10 @@ "ref\0CAKv+Gu9wrOOk-LGPYmxgLbv86uXzMeHN6th3mMEDT3Vg893HWw@mail.gmail.com\0" "ref\020181020071206.GE876@sol.localdomain\0" "ref\0CAKv+Gu9zBKK7ughbBAKkHdfgX2KrBXkF6MhH3xrSdLegrjjYJQ@mail.gmail.com\0" - "From\0Eric Biggers <ebiggers@kernel.org>\0" - "Subject\0Re: [RFC PATCH v2 11/12] crypto: adiantum - add Adiantum support\0" + "From\0ebiggers@kernel.org (Eric Biggers)\0" + "Subject\0[RFC PATCH v2 11/12] crypto: adiantum - add Adiantum support\0" "Date\0Wed, 24 Oct 2018 15:06:17 -0700\0" - "To\0Ard Biesheuvel <ard.biesheuvel@linaro.org>\0" - "Cc\0open list:HARDWARE RANDOM NUMBER GENERATOR CORE <linux-crypto@vger.kernel.org>" - linux-fscrypt@vger.kernel.org - linux-arm-kernel <linux-arm-kernel@lists.infradead.org> - Linux Kernel Mailing List <linux-kernel@vger.kernel.org> - Herbert Xu <herbert@gondor.apana.org.au> - Paul Crowley <paulcrowley@google.com> - Greg Kaiser <gkaiser@google.com> - Michael Halcrow <mhalcrow@google.com> - Jason A . Donenfeld <Jason@zx2c4.com> - Samuel Neves <samuel.c.p.neves@gmail.com> - " Tomer Ashur <tomer.ashur@esat.kuleuven.be>\0" + "To\0linux-arm-kernel@lists.infradead.org\0" "\00:1\0" "b\0" "On Tue, Oct 23, 2018 at 07:40:34AM -0300, Ard Biesheuvel wrote:\n" @@ -39,7 +28,7 @@ "> >> > Adiantum is a tweakable, length-preserving encryption mode designed for\n" "> >> > fast and secure disk encryption, especially on CPUs without dedicated\n" "> >> > crypto instructions. Adiantum encrypts each sector using the XChaCha12\n" - "> >> > stream cipher, two passes of an \316\265-almost-\342\210\206-universal (\316\265A\342\210\206U) hash\n" + "> >> > stream cipher, two passes of an ?-almost-?-universal (?A?U) hash\n" "> >> > function, and an invocation of the AES-256 block cipher on a single\n" "> >> > 16-byte block. On CPUs without AES instructions, Adiantum is much\n" "> >> > faster than AES-XTS; for example, on ARM Cortex-A7, on 4096-byte sectors\n" @@ -48,8 +37,8 @@ "> >> >\n" "> >> > Adiantum is a specialization of the more general HBSH construction. Our\n" "> >> > earlier proposal, HPolyC, was also a HBSH specialization, but it used a\n" - "> >> > different \316\265A\342\210\206U hash function, one based on Poly1305 only. Adiantum's\n" - "> >> > \316\265A\342\210\206U hash function, which is based primarily on the \"NH\" hash function\n" + "> >> > different ?A?U hash function, one based on Poly1305 only. Adiantum's\n" + "> >> > ?A?U hash function, which is based primarily on the \"NH\" hash function\n" "> >> > like that used in UMAC (RFC4418), is about twice as fast as HPolyC's;\n" "> >> > consequently, Adiantum is about 20% faster than HPolyC.\n" "> >> >\n" @@ -58,7 +47,7 @@ "> >> > Adiantum's security is reducible to that of XChaCha12 and AES-256,\n" "> >> > subject to a security bound. XChaCha12 itself has a security reduction\n" "> >> > to ChaCha12. Therefore, one need not \"trust\" Adiantum; one need only\n" - "> >> > trust ChaCha12 and AES-256. Note that the \316\265A\342\210\206U hash function is only\n" + "> >> > trust ChaCha12 and AES-256. Note that the ?A?U hash function is only\n" "> >> > used for its proven combinatorical properties so cannot be \"broken\".\n" "> >> >\n" "> >>\n" @@ -80,8 +69,8 @@ "> > If (T1, P1_L) = (T2, P2_L) then P1_R != P2_R so the equation has no solutions\n" "> > (since we don't consider queries where the whole input is the same; those\n" "> > unavoidably produce the same ciphertext). Otherwise (T1, P1_L) != (T2, P2_L),\n" - "> > and since the hash function H is \316\265-almost-\342\210\206-universal over integers mod 2^128,\n" - "> > the equation is true for at most a very small proportion '\316\265' of hash keys.\n" + "> > and since the hash function H is ?-almost-?-universal over integers mod 2^128,\n" + "> > the equation is true for at most a very small proportion '?' of hash keys.\n" "> > But, the hash key is chosen at random and is unknown to the attacker.\n" "> >\n" "> > The same applies in the other direction, for chosen ciphertext attacks.\n" @@ -141,4 +130,4 @@ "\n" - Eric -adb488b096f97a270d1194f831e5414a382cbeb10e92a621fb20fb7d68a0d410 +8c0a2ae6bdf44b265ef16c29c5bf14d68c82c660040e14940af0e04fdfe434fa
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.