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