svn commit: r335402 - head/sbin/veriexecctl

[Conrad Meyer]

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