netdev - Re: [PATCH cryptodev] crypto: lib/chacha20poly1305

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 17 Nov 2020 10:52:36 +0100
From:   Ard Biesheuvel <ardb@...nel.org>
To:     Antonio Quartulli <a@...table.cc>
Cc:     Linux Crypto Mailing List <linux-crypto@...r.kernel.org>,
        wireguard@...ts.zx2c4.com,
        "open list:BPF JIT for MIPS (32-BIT AND 64-BIT)" 
        <netdev@...r.kernel.org>, keyrings@...r.kernel.org,
        linux-security-module@...r.kernel.org,
        Antonio Quartulli <antonio@...nvpn.net>,
        "Jason A. Donenfeld" <Jason@...c4.com>,
        Herbert Xu <herbert@...dor.apana.org.au>,
        David Howells <dhowells@...hat.com>,
        Jarkko Sakkinen <jarkko@...nel.org>,
        Jakub Kicinski <kuba@...nel.org>
Subject: Re: [PATCH cryptodev] crypto: lib/chacha20poly1305 - allow users to
 specify 96bit nonce

On Tue, 17 Nov 2020 at 10:47, Antonio Quartulli <a@...table.cc> 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)