From owner-svn-src-head@freebsd.org Wed Jun 20 16:35:43 2018 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D68991022DF1; Wed, 20 Jun 2018 16:35:42 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: from mail-it0-f46.google.com (mail-it0-f46.google.com [209.85.214.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6869883945; Wed, 20 Jun 2018 16:35:42 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by mail-it0-f46.google.com with SMTP id p185-v6so509675itp.4; Wed, 20 Jun 2018 09:35:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc:content-transfer-encoding; bh=kVJ60U747G96q+kU7Er0syfzEaKHSzz/0FHBbjVlIbE=; b=Ow4FznQ+gMwKxM8a1IWzh5WUuHK8t3rsxmv01wuNkRf/itp1uR1A4KT0cB0HFD0QVA IctF0efSxsdTHYsxc5uoPxolNSq7i3xcNt1nR80pM6ym3O1UsgRrcvRr1Ja0vtb3Tkdd LXrFosdgooEm/yW8y8wD7DneprDCc9SK9/hLUGd/XApq8s43PojcV9i6U4T8d1PjuBog RTp7OD7CayTlIza800hEIyqnPtSFbX/vtvXFzGuY7NV7cNeZpnGJw3WGOfOOTrcH6xnL Ab0sIYTIokjVR2eMYY1Xbqi8pMkW56DyVxS8FZA9ruti4Mepw5KLFa3oeSOyqpPBF711 Bx3A== X-Gm-Message-State: APt69E1h33w6J782xA1p8AKajY9PSfHHnDANhMQjdesc/Zun6iVmqk+w /q6Kb8VHWVL2TTF4BGFLctkUxOxg X-Google-Smtp-Source: ADUXVKLEuko3Etbii0+lh0K6OG5gfQQp0+mwZL4mcZYApv3J7YaKJNPXFRGq1yXNZFkaE+JFBqd2WQ== X-Received: by 2002:a24:e4c8:: with SMTP id o191-v6mr2029419ith.93.1529512215428; Wed, 20 Jun 2018 09:30:15 -0700 (PDT) Received: from mail-it0-f54.google.com (mail-it0-f54.google.com. [209.85.214.54]) by smtp.gmail.com with ESMTPSA id y64-v6sm1380388itb.33.2018.06.20.09.30.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 20 Jun 2018 09:30:15 -0700 (PDT) Received: by mail-it0-f54.google.com with SMTP id k17-v6so426818ita.0; Wed, 20 Jun 2018 09:30:15 -0700 (PDT) X-Received: by 2002:a24:100f:: with SMTP id 15-v6mr2200443ity.61.1529512214911; Wed, 20 Jun 2018 09:30:14 -0700 (PDT) MIME-Version: 1.0 Reply-To: cem@freebsd.org Received: by 2002:a02:5995:0:0:0:0:0 with HTTP; Wed, 20 Jun 2018 09:30:14 -0700 (PDT) In-Reply-To: <1529510299.24573.5.camel@freebsd.org> References: <201806200108.w5K18sIR050132@repo.freebsd.org> <96021.1529475664@kaos.jnpr.net> <17033.1529508519@kaos.jnpr.net> <1529510299.24573.5.camel@freebsd.org> From: Conrad Meyer Date: Wed, 20 Jun 2018 09:30:14 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: svn commit: r335402 - head/sbin/veriexecctl To: Ian Lepore Cc: "Simon J. Gerraty" , svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers , "Stephen J. Kiernan" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2018 16:35:43 -0000 Ian, On Wed, Jun 20, 2018 at 8:58 AM, Ian Lepore wrote: > And I request exactly the opposite: reject the complaining of people > who think all the world is a 256-core 5ghz server First: no need to be so rude to other committers. The hyperbole doesn't help anyone and doesn't help communicate your point clearly. It's just verbal diarrhea. Please try to be excellent to each other. > and leave in the > option to use faster algorithms on real-world hardware used by real- > world vendors who need some option other than "rev your hardware every > 18 months to keep up with the software or get out of the business." Second: You have very much misread my complaints and very much misunderstand the cryptographic algorithm landscape if that is your conclusion. See my earlier email, https://lists.freebsd.org/pipermail/svn-src-all/2018-June/166107.html ; in particular I would quote: > Performance is absolutely not a reason to use a known weak hash > algorithm in 2018, especially when the feature as-committed has so > many other glaring performance problems. If you care about MAC > performance in a secure algorithm in 2018, perhaps look at any of > these great options: > > * Blake2-b > * Poly1305-{AES,Salsa,ChaCha} > > They have highly efficient software implementations *that smoke SHA-2 > and don't have SHA-1's known weakness*. Blake2 is even in-tree > already. (Removing Keccak, which I had forgotten has crap performance in software =E2=80=94 mea culpa.) > Stronger algorithm options, yes. Even making stronger options the > default, yes. "More secure than SHA1" and "faster than SHA1" are *not* mutually exclusive= . > But removing viable options which are endorsed by the > people who actually set the standards, no. No one actually endorses SHA1 in new designs. No one endorses RIPEMD at al= l. Please look at the actual code size and layout of the sha1 support module and tell me that is a burden for Juniper to maintain in their downstream tree, rather than just getting angry about the suggestion we don't introduce novel, insecurity cryptographic designs. Thank you, Conrad