On Wed, 2018-06-20 at 09:30 -0700, Conrad Meyer wrote: > Ian, > > On Wed, Jun 20, 2018 at 8:58 AM, Ian Lepore <i...@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 _______________________________________________ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
