[PATCH cryptodev] crypto: lib/chacha20poly1305 - allow users to specify 96bit nonce
antonio at openvpn.net
Tue Nov 17 11:06:48 CET 2020
On 17/11/2020 10:52, Ard Biesheuvel wrote:
> On Tue, 17 Nov 2020 at 10:47, Antonio Quartulli <a at unstable.cc> wrote:
>> On 17/11/2020 09:31, Ard Biesheuvel wrote:
>>> If you are going back to the drawing board with in-kernel acceleration
>>> for OpenVPN, I strongly suggest to:
>>> a) either stick to one implementation, and use the library interface,
>>> or use dynamic dispatch using the crypto API AEAD abstraction, which
>>> already implements 96-bit nonces for ChaCha20Poly1305,
>> What we are implementing is a simple Data Channel Offload, which is
>> expected to be compatible with the current userspace implementation.
>> Therefore we don't want to change how encryption is performed.
>> Using the crypto API AEAD abstraction will be my next move at this point.
> Aren't you already using that for gcm(aes) ?
Yes, correct. That's why I had no real objection to using it :-)
At first I was confused and I thought this new library interface was
"the preferred way" for using chacha20poly1305, therefore I went down
>> I just find it a bit strange that an API of a well defined crypto schema
>> is implemented in a way that accommodates only some of its use cases.
> You mean the 64-bit nonce used by the library version of
> ChaCha20Poly1305? I agree that this is a bit unusual, but a library
> interface doesn't seem like the right abstraction for this in the
> first place, so I guess it is irrelevant.
>> But I guess it's accepted that we will have to live with two APIs for a bit.
>>> b) consider using Aegis128 instead of AES-GCM or ChaChaPoly - it is
>>> one of the winners of the CAESAR competition, and on hardware that
>>> supports AES instructions, it is extremely efficient, and not
>>> encumbered by the same issues that make AES-GCM tricky to use.
>>> We might implement a library interface for Aegis128 if that is preferable.
>> Thanks for the pointer!
>> I guess we will consider supporting Aegis128 once it gets standardized
>> (AFAIK it is not yet).
> It is. The CAESAR competition is over, and produced a suite of
> recommended algorithms, one of which is Aegis128 for the high
> performance use case. (Note that other variants of Aegis did not make
> it into the final recommendation)
oops, I was not up-to-date. Thanks again!
We'll definitely look into this soon.
More information about the WireGuard