[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.