From owner-svn-src-head@freebsd.org Wed Jun 20 16:39:34 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 6E7CF1023401 for ; Wed, 20 Jun 2018 16:39:34 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1a.eu.mailhop.org (outbound1a.eu.mailhop.org [52.58.109.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DCF2D83E15 for ; Wed, 20 Jun 2018 16:39:33 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-RoutePath: aGlwcGll X-MHO-User: 7e05acdf-74a8-11e8-afd2-4ddcc8249dd4 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound1.eu.mailhop.org (Halon) with ESMTPSA id 7e05acdf-74a8-11e8-afd2-4ddcc8249dd4; Wed, 20 Jun 2018 16:39:27 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id w5KGdOZ0082159; Wed, 20 Jun 2018 10:39:24 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1529512764.24573.8.camel@freebsd.org> Subject: Re: svn commit: r335402 - head/sbin/veriexecctl From: Ian Lepore To: cem@freebsd.org Cc: "Simon J. Gerraty" , svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers , "Stephen J. Kiernan" Date: Wed, 20 Jun 2018 10:39:24 -0600 In-Reply-To: References: <201806200108.w5K18sIR050132@repo.freebsd.org> <96021.1529475664@kaos.jnpr.net> <17033.1529508519@kaos.jnpr.net> <1529510299.24573.5.camel@freebsd.org> Content-Type: text/plain; charset="windows-1251" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit 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:39:34 -0000 On Wed, 2018-06-20 at 09:30 -0700, Conrad Meyer wrote: > 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 — 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 all. > > 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 > I have zero interest in arguing with you (or anybody) about this. I've expessed my opinion on the subject and have nothing more to say. -- Ian