Re: HTTPS trust anchors in sysinst
Johnny Billquist <[email protected]> Sun, 3 Sep 2023 03:10:46 +0200
| Newsgroups | gmane.os.netbsd.devel.installation |
|---|---|
| Message-ID | <[email protected]> |
I'm no crypto expert at all. And I don't know what the impact might be. I do know that just using ssh against that machine takes somewhere around 20s to just get to the password prompt. Compared to telnet, which is pretty instant. And I just reply to all when I reply, but the copies to Mouse constantly fails because his mail server refuse to talk with me. Johnny On 2023-09-03 03:01, Taylor R Campbell wrote: > [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 <[email protected]> >> >> 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. -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: [email protected] || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol