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  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]
Date:   Fri, 22 Mar 2019 02:10:15 -0600
From:   "Jason A. Donenfeld" <>
To:     Ard Biesheuvel <>
Cc:     Herbert Xu <>,
        Linus Torvalds <>,
        "David S. Miller" <>,
        Eric Biggers <>,
        Linux Crypto Mailing List <>,,
        linux-arm-kernel <>,
        LKML <>,
        Paul Crowley <>,
        Greg Kaiser <>,
        Samuel Neves <>,
        Tomer Ashur <>,
        Martin Willi <>
Subject: Re: [PATCH 0/17] Add zinc using existing algorithm implementations

On Fri, Mar 22, 2019 at 1:56 AM Ard Biesheuvel
<> wrote:
> that implement it, the reluctance of Jason to work with the community
> to fix the issues that he identified in the crypto API means that
> WireGuard will not be able to use these, and is restricted to
> synchronous software implementations.

There's no reluctance to work with the community. I'm pretty deeply
committed to this, as evidenced by the multitudes of patch
submissions, discussions, and popping around from conference to
conference discussing with folks face to face.

> - The way WireGuard uses crypto in the kernel is essentially a
> layering violation - while we already have an asynchronous API that
> implements ChaCha20Poly1305 in a way that WireGuard /could/ benefit
> from, and while we even have support already for async accelerators
> Saying accelerators will not
> matter is a bit like saying there are no American soldiers in Iraq.
> (Note that adding async interfaces to Zinc is not the right way to
> deal with this IMO)

Geopolitics aside, as explained over and over, the point of Zinc is to
just get down simple software function calls, for instances where
async accelerators aren't available. I consider smushing it all
together to be the "layering violation".

> - I don't think Zinc changes should go through Greg's tree and have
> separate maintainers

As I've mentioned before, I'm fine with merges going whichever route
is best for merges. If Herbert thinks it'd be useful to send things in
that direction and would reduce clashes and such, then that's fine
with me.

>  in fact, I am a bit concerned about the fact
> that, after the last Zinc/WG submission in October, Jason has not
> really interacted

Such as... ? November is
after October.

Anyway, I thought it good advice to not post v9 too swiftly after
plumbers, letting things calm a bit and focusing on other improvements
in Zinc in the meanwhile. I've certainly been around.

Looks like Herbert posting this might erupt another contentious thread
of bikeshedding and argument, what a bummer.

Powered by blists - more mailing lists