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] [day] [month] [year] [list]

Message-ID: <47819bd4-3bed-d7e5-523a-6ec5c70caad8@openvpn.net>
Date:   Tue, 17 Nov 2020 11:06:48 +0100
From:   Antonio Quartulli <antonio@...nvpn.net>
To:     Ard Biesheuvel <ardb@...nel.org>, 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,
        "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

Hi,

On 17/11/2020 10:52, Ard Biesheuvel wrote:
> 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) ?

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
this path.

> 
>> 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.

Alright.

> 
>>
>> 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.


Best Regards,

-- 
Antonio Quartulli
OpenVPN Inc.