Re: HTTPS trust anchors in sysinst

[Taylor R Campbell <riastradh%NetBSD.org@localhost>]

[Someone keeps dropping me from cc, as if they don't actually want me
to pay attention to issues with keeping NetBSD running on low-resource
machines!]


> Date: Fri, 1 Sep 2023 04:07:24 +0200
> From: Johnny Billquist <bqt%softjar.se@localhost>
> 
> Yay! New build of latest current was a bit more successful. Here are
> the results from "openssl speed" on a VAXstation 4000/90. Mind it,
> it's a bit on the fast side among VAXen...
> 
> I hope it is somewhat useful for figuring out how painful things
> might be. ;-)

Great, thanks!  This is missing the higher-speed public-key options I
asked about in the original message (rwverify, falcon), but that's not
terribly important, because the bog-standard public-key options look
just fine too.

But first, before public-key operations, let's look at:

(reformatted from the original)
> The 'numbers' are in 1000s of bytes per second processed.
> type    16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes
> sha256  30.15k   94.04k   230.49k   358.23k    428.59k    437.99k

This is going to be the main bottleneck, and it shows you can hash at
about half a megabyte per second.  Which will take several minutes,
but my guess is that it already takes quite a bit more than several
minutes to download and extract the sets anyway -- and perhaps if
pipelined with the I/O it might not make much difference at all.

There are also potentially cheaper options that are still likely
secure, like randomized MD5, which your machine can do at ~3 MB/sec.

Note: For TLS, a better measure of the crypto overhead will be
`openssl speed -evp chacha20-poly1305', which should be much faster
than SHA-256.

>                               sign    verify    sign/s verify/s
>  253 bits EdDSA (Ed25519)   0.0547s   0.1743s     18.3      5.7

This is the modern standard choice of public-key signature scheme, and
you would only need to do _one_ of these operations during
installation to verify a manifest of the release, which will take less
than a fifth of a second on your machine.

Now, I can't tell with 100% certainty that a fifth of a second isn't
catastrophic in your case, but...let's call it 99 and 4/5ths of a %
certainty that this won't be the catastrophe that Mouse predicted?


(OK, I lied: you might actually need to do up to, let's say, four of
these operations, in case we deploy both a system of certificates and
a system of 2-of-3 threshold signatures.  That would bring it up to
almost 0.7 seconds!  Is that gonna tip us over into catastrophe?)


> Doing 253 bits  ecdh's for 10s: 68 253-bits ECDH ops in 10.14s
> ECDH computations don't match.
> [...]
> Doing 456 bits sign Ed448's for 10s: 29 456 bits Ed448 signs in 10.13s
> EdDSA verify failure.  No EdDSA verify will be done.

This suggests there's a bug in the X448/Ed448 logic in OpenSSL on VAX,
which is not too surprising, and also not particularly alarming,
because:

- X448/Ed448 was designed (like X25519/Ed25519) for specially
  optimized arithmetic around the prime shape 2^448 - 2^224 - 1, so
  this is likely using special-purpose arithmetic that isn't used
  anywhere else in OpenSSL for anything else; and

- X448/Ed448 are very seldom used in the real world, because their two
  reasons for existence are (a) the cute arithmetic and (b) to serve
  as a hedge against a modest cryptanalytic advance in elliptic curve
  cryptography -- performance is much worse than the widely used
  X25519/Ed25519, and they're just as vulnerable in the post-quantum
  setting.

It would be nice, and might be fun, to figure out what's wrong here.
But it is unlikely to indicate problems for anything else.