Date: Wed, 20 Jun 2018 09:30:14 -0700 From: Conrad Meyer <cem@freebsd.org> To: Ian Lepore <ian@freebsd.org> Cc: "Simon J. Gerraty" <sjg@juniper.net>, svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers <src-committers@freebsd.org>, "Stephen J. Kiernan" <stevek@freebsd.org> Subject: Re: svn commit: r335402 - head/sbin/veriexecctl Message-ID: <CAG6CVpUgy8LhCkFZZ1D8BH%2BqJ_CDikvYNJrM9Nc0Ut5u=AVMHA@mail.gmail.com> In-Reply-To: <1529510299.24573.5.camel@freebsd.org> References: <201806200108.w5K18sIR050132@repo.freebsd.org> <CAG6CVpV124ze%2BY6xX2ZFqbM%2B3hJNEJWR2qpnChpey=PmiW6qXg@mail.gmail.com> <96021.1529475664@kaos.jnpr.net> <CAJ5_RoBvwNH7-ZCd3LxtXg21TE49uX2y35Jwa6MM%2Bwn%2BX0_wUQ@mail.gmail.com> <17033.1529508519@kaos.jnpr.net> <CAG6CVpVwrWaDMcVRfgaOHagfPbnmULKe6R=GJiZi-reZYbZr8A@mail.gmail.com> <1529510299.24573.5.camel@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Ian, On Wed, Jun 20, 2018 at 8:58 AM, Ian Lepore <ian@freebsd.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAG6CVpUgy8LhCkFZZ1D8BH%2BqJ_CDikvYNJrM9Nc0Ut5u=AVMHA>