linux-kernel - Re: [PATCH net-next v6 00/23] WireGuard: Secure Network Tunnel

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]

Message-ID: <CAHmME9rdkAG6mvkUMy9J5+8U9BQkrym7WmmtmK6o3nudykWLoA@mail.gmail.com>
Date:   Fri, 5 Oct 2018 15:46:29 +0200
From:   "Jason A. Donenfeld" <Jason@...c4.com>
To:     Richard Weinberger <richard.weinberger@...il.com>
Cc:     Eric Biggers <ebiggers@...nel.org>,
        Ard Biesheuvel <ard.biesheuvel@...aro.org>,
        Herbert Xu <herbert@...dor.apana.org.au>,
        LKML <linux-kernel@...r.kernel.org>,
        Netdev <netdev@...r.kernel.org>,
        Linux Crypto Mailing List <linux-crypto@...r.kernel.org>,
        David Miller <davem@...emloft.net>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: Re: [PATCH net-next v6 00/23] WireGuard: Secure Network Tunnel

On Fri, Oct 5, 2018 at 3:38 PM Richard Weinberger
<richard.weinberger@...il.com> wrote:
> So we will have two competing crypo stacks in the kernel?
> Having a lightweight crypto API is a good thing but I really don't like the idea
> of having zinc parallel to the existing crypto stack.

No, as you've seen in this patchset, the dynamic dispatch crypto API
can trivially be done on top of Zinc. So each time we introduce a new
primitive to Zinc that's also in the dynamic dispatch API, we
reimplement the current crypto API in terms of Zinc. Check out the two
patches in this series that do this; it's quite clean and sleek.

> And I strongly vote that Herbert Xu shall remain the maintainer of the whole
> crypto system (including zinc!) in the kernel.

No, sorry, we intend to maintain the code we've written. But I am
amenable to taking a tree-route into upstream based on whatever makes
most sense with merge conflicts and such.