Received: by 2002:a25:824b:0:0:0:0:0 with SMTP id d11csp3657719ybn; Fri, 27 Sep 2019 09:24:48 -0700 (PDT) X-Google-Smtp-Source: APXvYqx+PmeUOt6o75mLPdGreQNWncmakTDtlYUnIn5bEh4di9y1MqUdCtYT13g3QHzI0jrjU7G9 X-Received: by 2002:a50:b545:: with SMTP id z5mr5542062edd.203.1569601488165; Fri, 27 Sep 2019 09:24:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1569601488; cv=none; d=google.com; s=arc-20160816; b=ERXYFTN8yWuRFq0r3aDlGa5wxHVKKY9BS0jiYSDaIbdTMzT3DazhPHIli6p57jaflM byQV7ElcYED3ysPvGxyvvcft+TQLMlSXpqXWSm3rNwJ45RrgRUMYLnN++4rxoXeAGpY8 nYpdozocZ2rNxGyvgr9T1k4jn2kk2BC+dL5K5Bdok+QTUMp4CFmSJdgtFJ6tPJ1zYUvJ Bv4AQNTIHx3BfjfQsMIl7OEKMjFZBv2TxtPCNa4yrQsEZSemYARtoxz5LsjLrF8NexOy C+jWFgta3EwBN5rCN7NzDhvR9P7FV96R4y1my8TAAk3HYAnx79CzmtD9NHlAwXWElI1w VznA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=0ZSEhf5bO/SF1c0tSKvmNNeWxWL147w5YdOvl2Gnjpw=; b=mQT/C3EDBUumE3YccfnJrGat7F57Y/fBlt2ncI8dmp1dio7A6FuUolLug3PC08nljB QYT7dPM6tifYNYGcU65cTN0h40R0d9EG5lYdaNgctttWI6xEpst5QVwbnAUFSB98RICC Kk5MCDD7Wdifqj/oLvCOU2hy+VKgkyP2n9ZBoXYRDMOtlR/BdZLdHsw7cALswQrOvJWw tUe10XA70DX9V0WiM+zyhLveMCd3eoDS+0vvvBlwvJJ0TL1k8Tu6jbTwbQSUHyxv4yEe O1ZT3IPzXHb4cmbtAaJTQhV/WTQqPPSYmCjbqN+7QYfcvcGrM1gH0jcW0maY4g8C5buq vWTQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linux-foundation.org header.s=google header.b=KU36TUyG; spf=pass (google.com: best guess record for domain of linux-crypto-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id t26si1807544edd.184.2019.09.27.09.24.17; Fri, 27 Sep 2019 09:24:48 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-crypto-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@linux-foundation.org header.s=google header.b=KU36TUyG; spf=pass (google.com: best guess record for domain of linux-crypto-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727273AbfI0QYL (ORCPT + 99 others); Fri, 27 Sep 2019 12:24:11 -0400 Received: from mail-lj1-f194.google.com ([209.85.208.194]:41070 "EHLO mail-lj1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726251AbfI0QYK (ORCPT ); Fri, 27 Sep 2019 12:24:10 -0400 Received: by mail-lj1-f194.google.com with SMTP id f5so3080610ljg.8 for ; Fri, 27 Sep 2019 09:24:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0ZSEhf5bO/SF1c0tSKvmNNeWxWL147w5YdOvl2Gnjpw=; b=KU36TUyGvfLb65v10CffeuYRR2Y01pARWIeV/Vo2qTbklo0V+XA7MrpdKGqR8Ak/KF 7xi3WhZMUWFK5wmMlbUFTMpDFM+pU5EJBRaIuZosAYuB/0qdZiP1XToldMkdMHQ3GmKk gv11WbFW6DUox0vozNZvM6ewmDOPeiEUTX56c= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0ZSEhf5bO/SF1c0tSKvmNNeWxWL147w5YdOvl2Gnjpw=; b=mZd52DVlvtdhkyQQsN25BQRsNX82pInlP3GNpljIU3FJVO/SAivRMAqu9KehisRrIR Z8VL/w4D6qgq617H+0CBg5UcWDXO+HVLxwUjXQ7sPTz+9ga3gqRHBHm++Wum0cQM8a46 a1xYDsixTDfx45p75XiKq0Gh8BnKleuXO0e3qUGh1Ug5cwFlek8x5sOvsirtbvA841i/ p7nzqYyFNRWx2O55AFSflGmWZ76WMHrAtcbfFgTGewKql3hcJgtpJACFtxpDkF1/W931 ZicXJ8T2GATuIErkiDfs2yKnK6l4Av77dP+JBWnpUULy5E2cULzrrLqfKoGXJ/Z2xmdT XAtQ== X-Gm-Message-State: APjAAAWaK91lVP1a5EIjxsEYTpAiJwHjb8uygqaJdlW62X60zkY9z+Wc ctjQb9/ErM7AUNuNpk13ADWGgLzbhd8= X-Received: by 2002:a2e:58a:: with SMTP id 132mr3360431ljf.132.1569601447364; Fri, 27 Sep 2019 09:24:07 -0700 (PDT) Received: from mail-lj1-f173.google.com (mail-lj1-f173.google.com. [209.85.208.173]) by smtp.gmail.com with ESMTPSA id x25sm550332ljb.60.2019.09.27.09.24.05 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 27 Sep 2019 09:24:06 -0700 (PDT) Received: by mail-lj1-f173.google.com with SMTP id 7so3088173ljw.7 for ; Fri, 27 Sep 2019 09:24:05 -0700 (PDT) X-Received: by 2002:a2e:1208:: with SMTP id t8mr3435615lje.84.1569601445451; Fri, 27 Sep 2019 09:24:05 -0700 (PDT) MIME-Version: 1.0 References: <20190925161255.1871-1-ard.biesheuvel@linaro.org> <20190925161255.1871-19-ard.biesheuvel@linaro.org> In-Reply-To: From: Linus Torvalds Date: Fri, 27 Sep 2019 09:23:49 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC PATCH 18/18] net: wireguard - switch to crypto API for packet encryption To: Pascal Van Leeuwen Cc: Ard Biesheuvel , Linux Crypto Mailing List , Linux ARM , Herbert Xu , David Miller , Greg KH , "Jason A . Donenfeld" , Samuel Neves , Dan Carpenter , Arnd Bergmann , Eric Biggers , Andy Lutomirski , Will Deacon , Marc Zyngier , Catalin Marinas Content-Type: text/plain; charset="UTF-8" Sender: linux-crypto-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org On Fri, Sep 27, 2019 at 2:58 AM Pascal Van Leeuwen wrote: > > > I'd want to see wireguard in an end-to-end situation from the very > > client hardware. So laptops, phones, desktops. Not the untrusted (to > > me) hw in between. > > > I don't see why the crypto HW would deserve any less trust than, say, > the CPU itself. I would say CPU's don't deserve that trust at the moment. It's not the crypto engine that is part of the untrusted hardware. It's the box itself, and the manufacturer, and you having to trust that the manufacturer didn't set up some magic knocking sequence to disable the encryption. Maybe the company that makes them is trying to do a good job. But maybe they are based in a country that has laws that require backdoors. Say, France. There's a long long history of that kind of thing. It's all to "fight terrorism", but hey, a little industrial espionage is good too, isn't it? So let's just disable GSM encryption based on geographic locale and local regulation, shall we. Yeah, yeah, GSM encryption wasn't all that strong to begin with, but it was apparently strong enough that France didn't want it. So tell me again why I should trust that box that I have no control over? > Well, that's the general idea of abstraction. It also allows for > swapping in any other cipher with minimal effort just _because_ the > details were hidden from the application. So it may cost you some > effort initially, but it may save you effort later. We clearly disagree on the utility of crypto agility. You point to things like ipsec as an argument for it. And I point to ipsec as an argument *against* that horror. It's a bloated, inefficient, horribly complex mess. And all the "agility" is very much part of it. I also point to GSM as a reason against "agility". It has caused way more security problems than it has ever solved. The ":agility" is often a way to turn off (or tune down) the encryption, not as a way to say "ok, we can improve it later". That "we can improve it later" is a bedtime story. It's not how it gets used. Particularly as the weaknesses are often not primarily in the crypto algorithm itself, but in how it gets used or other session details. When you actually want to *improve* security, you throw the old code away, and start a new protocol entirely. Eg SSL -> TLS. So cryptographic agility is way oversold, and often people are actively lying about why they want it. And the people who aren't lying are ignoring the costs. One of the reasons _I_ like wireguard is that it just went for simple and secure. No BS. And you say > Especially since all crypto it uses comes from a single > source (DJB), which is frowned upon in the industry. I'm perhaps not a fan of DJB in all respects, but there's no question that he's at least competent. The "industry practice" of having committees influenced by who knows what isn't all that much better. Do you want to talk about NSA elliptic curve constant choices? Anyway, on the costs: > > - dynamically allocate buffers at "init time" > > Why is that so "wrong"? It sure beats doing allocations on the hot path. It's wrong not becasue the allocation is costly (you do that only once), but because the dynamic allocation means that you can't embed stuff in your own native data structures as a user. So now accessing those things is no longer dense in the cache. And it's the cache that matters for a synchronous CPU algorithm. You don't want the keys and state to be in some other location when you already have your data structures for the stream that could just have them right there with the other data. > And you don't want to have it on the stack initially and then have > to _copy_ it to some DMA-able location that you allocate on the fly > on the hot path if you _do_ want HW acceleration. Actually, that's *exactly* what you want. You want keys etc to be in regular memory in a location that is convenient to the user, and then only if the hardware has issues do you say "ok, copy the key to the hardware". Because quite often the hardware will have very special key caches that aren't even available to the CPU, because they are on some hw-private buffers. Yes, you want to have a "key identity" model so that the hardware doesn't have to reload it all the time, but that's an invalidation protocol, not a "put the keys or nonces in special places". Linus