[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <1512977925.28078.12.camel@strongswan.org>
Date: Mon, 11 Dec 2017 08:38:45 +0100
From: Martin Willi <martin@...ongswan.org>
To: Eric Biggers <ebiggers3@...il.com>,
Ard Biesheuvel <ard.biesheuvel@...aro.org>
Cc: linux-crypto@...r.kernel.org, herbert@...dor.apana.org.au,
Eric Biggers <ebiggers@...gle.com>,
linux-fscrypt@...r.kernel.org, Theodore Ts'o <tytso@....edu>,
linux-ext4@...r.kernel.org, linux-f2fs-devel@...ts.sourceforge.net,
linux-mtd@...ts.infradead.org, linux-fsdevel@...r.kernel.org,
Jaegeuk Kim <jaegeuk@...nel.org>,
Michael Halcrow <mhalcrow@...gle.com>,
Paul Crowley <paulcrowley@...gle.com>,
David Gstir <david@...ma-star.at>,
"Jason A . Donenfeld" <Jason@...c4.com>,
Stephan Mueller <smueller@...onox.de>
Subject: Re: [RFC PATCH] crypto: chacha20 - add implementation using 96-bit
nonce
Hi,
> Anyway, I actually thought it was intentional that the ChaCha
> implementations in the Linux kernel allowed specifying the block
> counter, and therefore allowed seeking to any point in the keystream,
> exposing the full functionality of the cipher.
If I remember correctly, it was indeed intentional. When building the
chacha20poly1305 AEAD both in [1] and [2], a block counter of 0 is used
to generate the Poly1305 key. For the ChaCha20 encryption, an explicit
initial block counter of 1 is used to avoid reusing the same counter.
Maybe it would be possible to implement this with implicit counters,
but doing this explicitly looked much clearer to me. So I guess there
are use cases for explicit block counters in ChaCha20.
Best regards
Martin
[1] https://tools.ietf.org/html/rfc7539#section-2.8
[2] https://tools.ietf.org/html/rfc7634#section-2
Powered by blists - more mailing lists