From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS, URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3D727C43441 for ; Mon, 19 Nov 2018 06:13:25 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 04DF92086B for ; Mon, 19 Nov 2018 06:13:25 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=zx2c4.com header.i=@zx2c4.com header.b="2370uH5L" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 04DF92086B Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=zx2c4.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726211AbeKSQf7 (ORCPT ); Mon, 19 Nov 2018 11:35:59 -0500 Received: from frisell.zx2c4.com ([192.95.5.64]:33961 "EHLO frisell.zx2c4.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725998AbeKSQf7 (ORCPT ); Mon, 19 Nov 2018 11:35:59 -0500 Received: by frisell.zx2c4.com (ZX2C4 Mail Server) with ESMTP id 13bd74fb; Mon, 19 Nov 2018 06:07:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=zx2c4.com; h=mime-version :references:in-reply-to:from:date:message-id:subject:to:cc :content-type; s=mail; bh=UopaU62DekDF+iU8IBwCEnFHyoE=; b=2370uH 5Ln8LfSjVn/IPyt8+3r/XwUPzXDLcrt1NiKWgfqzpeQ5ln9dFxm05XfMQKG4QYrU yvH3gfh1CFpwHkIC5W/FDiHoB7g97mwkCa51D1ubBmG5eyxXL7OPRnq3wzIRiuND HreO/FDBQgVg9xTsuS5TlJkbj/f/lVqd3qUaDRICpJQipY2dhYNBvwVVcLKc887Q hiiDfZVzuUWRSXIMZeCBQl/bcjmqB4kFJxebH9DKwTuW0b+i1lZ1LaOVgKaR2EDp fdNyRlXDPdl4nLSPz5EqRhHjEBsPkKGxMSOcZECHHNuyI/o/awXw0KYRXVElPH9u nFJnvBKfMgmr16eg== Received: by frisell.zx2c4.com (ZX2C4 Mail Server) with ESMTPSA id fa02def1 (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256:NO); Mon, 19 Nov 2018 06:07:23 +0000 (UTC) Received: by mail-ot1-f48.google.com with SMTP id t5so26694544otk.1; Sun, 18 Nov 2018 22:13:20 -0800 (PST) X-Gm-Message-State: AGRZ1gJFqwgPpU1E/nRtlibYiUkcbpQksjsOk/zkPfoM0wO71x/bGmjb f4/nhc5TyJtB2CPXbs72DqWrIKtHr5jB9jWwFZo= X-Google-Smtp-Source: AJdET5dbO9s5WW9GqEoVVwj8kZUD9BttDvupHJ0IItb6oC1Mwt7F8kADf7DfY7P8cVZOPRyZ6jnZSj3u9614qAiBpaY= X-Received: by 2002:a9d:12e3:: with SMTP id g90mr8297694otg.223.1542607999398; Sun, 18 Nov 2018 22:13:19 -0800 (PST) MIME-Version: 1.0 References: <20181105232526.173947-1-ebiggers@kernel.org> <20181105232526.173947-11-ebiggers@kernel.org> <20181112185816.GA8663@gmail.com> <20181116060227.hwu4igi6bp26ddpi@gondor.apana.org.au> <20181117001718.GA175522@gmail.com> <20181119052451.qttzfgcm4hvbdc4u@gondor.apana.org.au> In-Reply-To: <20181119052451.qttzfgcm4hvbdc4u@gondor.apana.org.au> From: "Jason A. Donenfeld" Date: Mon, 19 Nov 2018 07:13:07 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC PATCH] zinc chacha20 generic implementation using crypto API code To: Herbert Xu Cc: Eric Biggers , Ard Biesheuvel , Linux Crypto Mailing List , linux-fscrypt@vger.kernel.org, linux-arm-kernel@lists.infradead.org, LKML , Paul Crowley , Greg Kaiser , Samuel Neves , Tomer Ashur Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Herbert, On Mon, Nov 19, 2018 at 6:25 AM Herbert Xu wrote: > My proposal is to merge the zinc interface as is, but to invert > how we place the algorithm implementations. IOW the implementations > should stay where they are now, with in the crypto API. However, > we will provide direct access to them for zinc without going through > the crypto API. IOW we'll just export the functions directly. Sorry, but there isn't a chance I'll agree to this. The whole idea is to have a clean place to focus on synchronous software implementations, and not keep it tangled up with the asynchronous API. If WireGuard and Zinc go in, it's going to be done right, not in a way that introduces more problems and organizational complexity. Avoiding the solution proposed here is kind of the point. And given that cryptographic code is so security sensitive, I want to make sure this is done right, as opposed to rushing it with some half-baked concoction that will be maybe possibly be replaced "later". From talking to folks at Plumbers, I believe most of the remaining issues are taken care of by the upcoming v9, and that you're overstating the status of discussions regarding that. I think the remaining issue right now is how to order my series and Eric's series. If Eric's goes in first, it means that I can either a) spend some time developing Zinc further _now_ to support chacha12 and keep the top two conversion patches, or b) just drop the top two conversion patches and work that out carefully with Eric after. I think (b) would be better, but I'm happy to do (a) if you disagree. And as I mentioned in the last email, I'd prefer Eric's work to go in after Zinc, but I don't think the reasoning for that is particularly strong, so it seems fine to merge Eric's work first. I'll post v9 pretty soon and you can see how things are shaping up. Hopefully before then Eric/Ard/you can provide some feedback on whether you'd prefer (a) or (b) above. Regards, Jason