Re: SHA3 implementation in src

   Date: Sat, 5 Mar 2016 17:14:41 -0800
   From: Alistair Crooks <[email protected]>

   On 5 March 2016 at 16:51, Taylor R Campbell
   <[email protected]> wrote:
   > The last time I proposed this, before SHA-3 was finalized, joerg
   > objected to it because overlap between libc and OpenSSL libcrypto for
   > the sha2 functions had historically caused a lot of trouble, and he
   > anticipated similar problems with an analogous sha3 API.

   I can see that it would be problematic if there was a clash. However,
   Rich Salz indicated last year that sha3 was not on the roadmap for
   openssl 1.1 -

   https://github.com/openssl/openssl/issues/439

Well, that doesn't mean it won't happen, and it is pretty likely that
if it does happen it will have the same issue as the sha2 functions,
just in another year rather than today.

   However, I'd like to get the functionality in to NetBSD, and waiting
   for a third party who don't view it as a priority isn't going to
   accomplish that goal, so a number of ways forward spring to mind:

   1. put it in libc and handle the fallout when it hits openssl that we ship with
   2. put it in a separate libsha3
   3. revamp all of our digest code to go into a separate libdigest (not
   too happy with this one, mentioned for completeness)
   4. just do nothing (again, not useful, mentioned for completeness)

Another possibility would be to use different libc symbols for our
versions that are guaranteed not to collide with OpenSSL's, say
_netbsd_SHA3_*.  This won't work retroactively for the sha1 and sha2
functions, but it would have worked if we had done it up front.

However, I'm not totally clear on the severity or breadth of the
fallout, so I'll defer to someone who has experience with it.  joerg?

   New diff uploaded to
   http://ftp.netbsd.org/pub/NetBSD/misc/agc/sha3-src-20160305.diff

Only one question: Why did you make SHA3_Selftest userland-only?

   While I'm here, all the "if (0 < d)" I find tortuous to read, and take
   even longer to work out what's meant. OK, so I'm slow; my brain just
   can't deal with them. Any chance of putting them the right way round,
   please? Our compilers are smart enough these days to realise the
   difference between  "=" and "==".

It's not about =/== -- rather, I find it easier to read as `increasing
left to right' (or, for <=, `nondecreasing left to right') and to
consistently make the direction of increase be left to right.  I don't
mind if you make the change in NetBSD but I don't intend to make it
upstream.