Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <20201117021839.4146-1-a@unstable.cc> <CAMj1kXFxk31wtD3H8V0KbMd82UL_babEWpVTSkfqPpNjSqPNLA@mail.gmail.com>
 <5096882f-2b39-eafb-4901-0899783c5519@unstable.cc>
In-Reply-To: <5096882f-2b39-eafb-4901-0899783c5519@unstable.cc>
From:   Ard Biesheuvel <ardb@kernel.org>
Date:   Tue, 17 Nov 2020 10:52:36 +0100
Message-ID: <CAMj1kXGZATR7XyFb2SWiAxcBCUzXgvojvgR9fHczEu9zrpF9ug@mail.gmail.com>
Subject: Re: [PATCH cryptodev] crypto: lib/chacha20poly1305 - allow users to
 specify 96bit nonce
To:     Antonio Quartulli <a@unstable.cc>
Cc:     Linux Crypto Mailing List <linux-crypto@vger.kernel.org>,
        wireguard@lists.zx2c4.com,
        "open list:BPF JIT for MIPS (32-BIT AND 64-BIT)" 
        <netdev@vger.kernel.org>, keyrings@vger.kernel.org,
        linux-security-module@vger.kernel.org,
        Antonio Quartulli <antonio@openvpn.net>,
        "Jason A. Donenfeld" <Jason@zx2c4.com>,
        Herbert Xu <herbert@gondor.apana.org.au>,
        David Howells <dhowells@redhat.com>,
        Jarkko Sakkinen <jarkko@kernel.org>,
        Jakub Kicinski <kuba@kernel.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

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