Re: [PATCH net-next v5 02/20] zinc: introduce minimal cryptography library

[Jason A. Donenfeld]

Hey Ard,

On Tue, Sep 25, 2018 at 12:25 PM Ard Biesheuvel
<ard.biesheuvel@xxxxxxxxxx> wrote:
> Kees is currently dealing with VLA uses in crypto API skcipher
> invocations [0] that don't benefit from its async capabilities nor
> from the runtime resolution of cipher name strings, given that they
> always select the same one.
>
> drivers/net/ppp/ppp_mppe.c: "ecb(arc4)"
> drivers/usb/wusbcore/crypto.c: "cbc(aes)"
> net/ceph/crypto.c: "cbc(aes)"
> net/mac802154/llsec.c: "ctr(aes)"
> net/rxrpc/rxkad.c: "pcbc(fcrypt)"
> net/rxrpc/rxkad.c: "pcbc(fcrypt)"
> net/sunrpc/auth_gss/gss_krb5_mech.c: "cbc(des)"
> net/sunrpc/auth_gss/gss_krb5_mech.c: "ecb(arc4)"
> net/sunrpc/auth_gss/gss_krb5_mech.c: "cbc(des3_ede)"
> net/sunrpc/auth_gss/gss_krb5_mech.c: "cts(cbc(aes))"
> net/sunrpc/auth_gss/gss_krb5_mech.c: "cts(cbc(aes))"
> net/wireless/lib80211_crypt_tkip.c: "ecb(arc4)"
> net/wireless/lib80211_crypt_wep.c: "ecb(arc4)"
>
> To me, these are prime candidates for moving into your library [at
> some point]. I guess AES should be non-controversial, but moving the
> others is actually more important in my view, since we will be able to
> stop exposing them via the crypto API in that case. Any thoughts?

In order of priority, I'll probably tackle lib/ first and then the
cases like you mentioned after. Indeed AES is an obvious candidate.
For the others, we'll evaluate them on a case-by-case basis. For
example, Ted T'so's "halfmd4" algorithm was moved from lib/ directly
into that portion of the ext4 driver, since it's some "half"-baked
random crypto that should only be used in that one place and then
never again. On the other hand, it seems likely RC4 and DES are used
multiple places, and so we'll have to carefully evaluate these. We can
also discuss this in November and see where thoughts are at that time.

> Also, you haven't yet responded to my question about WireGuard's
> limitation to synchronous encryption, or whether and how you expect to
> support asynchronous accelerators for ChaCha20/Poly1305 in the future.
> This shouldn't impede adoption of this series, but this is something
> that is going to come up sooner than you think, and so I would like to
> understand whether this means your library will grow asynchronous
> interfaces as well, or whether it will be moved to the crypto API.

I have no concrete plans to introduce an asynchronous interface to
Zinc at this time, but that could change at some later date. At the
moment however, I prefer for it to be just a simple collection of
software ciphers, just as the description reads. Regarding hardware
acceleration in WireGuard: I've actually been talking to some people
interested in producing these types of ASICs lately, and hopefully
something cool will come out of it. It's not obvious, however, that
this _must_ imply an asynchronous interface, even though that may very
well seem like the intuitive thing. This is, as well, a discussion for
the future indeed.

> (Also, I'd like to know whether the RFC7539 construction of ChaCha20
> and Poly1305 is compatible with WireGuard's)

WireGuard uses 64-bit nonces, but since they're both little-endian,
and because of the maximum size of a series of IP fragments (namely,
less than 2^32), they're "compatible".

Jason