On Tue, 17 Nov 2020 at 10:47, Antonio Quartulli <a@xxxxxxxxxxx> wrote: > > Hi, > > > 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) ? > 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)
