netdev - Re: [PATCH net-next v9 00/19] 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: <20190325115156.wj4verbfdd2rspo5@gondor.apana.org.au>
Date:   Mon, 25 Mar 2019 19:51:56 +0800
From:   Herbert Xu <herbert@...dor.apana.org.au>
To:     "Jason A. Donenfeld" <Jason@...c4.com>
Cc:     linux-crypto@...r.kernel.org, linux-kernel@...r.kernel.org,
        netdev@...r.kernel.org, Jason@...c4.com,
        torvalds@...ux-foundation.org, davem@...emloft.net,
        gregkh@...uxfoundation.org, ebiggers@...nel.org,
        ard.biesheuvel@...aro.org, samuel.c.p.neves@...il.com
Subject: Re: [PATCH net-next v9 00/19] WireGuard: Secure Network Tunnel

Jason A. Donenfeld <Jason@...c4.com> wrote:
> Changes v8->v9, along with who suggested it.
> --------------------------------------------
> - [EVERYBODY] Zinc no longer ships generated assembly code. Rather, we now
>  bundle in the original perlasm generator for it. This is ongoing joint work
>  with Andy Polyakov upstream, so that the same .pl files can live in our tree
>  as well as in the CRYPTOGAMS tree. I personally find that the code required
>  to share this in both repositories to be a tiny bit ugly. I think there would
>  be some degree of an advantage to removing that and making the .pl
>  kernel-only, and then carefully tracking Andy's changes (as we already
>  do). Previous opinions on the list, though, were that there's also
>  significant advantage to being able to share the exact same code in both.
>  And I think there's a decent amount of wisdom in that too. Since that
>  appeared to be the prevailing view, and since it also has good reasons
>  arguments, we'll go with that for now.

Thanks for the update.
 
> - Following the Adiantum merge, the two commits that port the old crypto API
>  over to use Zinc have been removed from this series. We can certainly add
>  them back in at some point, but I thought it'd be favorable to at least
>  begin to receive some sign-offs on the Zinc-specific commits, now that
>  (hopefully all of) the previous feedback has been taken care of. The two
>  commits porting it over are fairly standalone as well, so that shouldn't
>  impact the ability to review this. For now those are living in the
>  jd/with-cryptoapi-port branch of kernel.org's zx2c4/linux.git tree. This
>  also allows us to move this all forward a little bit.

Sorry but adding new implementations of chacha20/poly1305 without
removing the existing ones is not acceptable.  I really think
we ought to separate the zinc interface from these new crypto
implementations.  They have nothing to do with each other.

As we've been stuck on this point for so long, let's get the
ball rolling by first merging just the zinc interface itself
with the existing chacha20/poly1305 code.  Then we can replace
these implementations with your implementations without getting
bogged down by all these other discussions.

AFAICS once we resolve Thomas's concerns with regards to the simd
patch, then we can merge the zinc interface right away and go from
there.

Cheers,
-- 
Email: Herbert Xu <herbert@...dor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt