Date: Wed, 20 Jun 2018 10:39:24 -0600 From: Ian Lepore <ian@freebsd.org> To: cem@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: <1529512764.24573.8.camel@freebsd.org> In-Reply-To: <CAG6CVpUgy8LhCkFZZ1D8BH%2BqJ_CDikvYNJrM9Nc0Ut5u=AVMHA@mail.gmail.com> 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> <CAG6CVpUgy8LhCkFZZ1D8BH%2BqJ_CDikvYNJrM9Nc0Ut5u=AVMHA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 2018-06-20 at 09:30 -0700, Conrad Meyer wrote: > 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 — 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1529512764.24573.8.camel>