svn commit: r335402 - head/sbin/veriexecctl

Ian Lepore ian at freebsd.org
Wed Jun 20 16:39:34 UTC 2018


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 at 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


More information about the svn-src-head mailing list