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 for Android: free password hash cracker in your pocket
[<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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ