Re: HTTPS trust anchors in sysinst

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

> Date: Sat, 2 Sep 2023 21:27:32 -0400 (EDT)
> From: Mouse <mouse%Rodents-Montreal.ORG@localhost>
> 
> > There are also potentially cheaper options that are still likely
> > secure, like randomized MD5, which your machine can do at ~3 MB/sec.
> 
> What is "randomized MD5"?  Does this mean tweaking the table of
> constants (the abs(sin(i+1)) values), or feeding it a short random
> value first, or what?  All the plausible alternatives I can think of
> would (as I learnt the terminology) more normally be called "salted",
> and would require that the source also compute the same salted hash,
> since it effectively can't be precomputed.

This uses the standard MD5 function in a particular protocol to defend
against collision attacks.

Suppose I want to transfer you a string of octets, call it x -- maybe
it's a source distribution of some software.  Suppose I give you the
hash h = MD5(x) on a known-good channel, and I tell you x is located
at:

   http://example.com/foo-1.23.tar

You can download it, giving some string x' (possibly equal to x,
possibly not), and accept it only if

   MD5(x') ?= h.

Unfortunately, you can be fooled by a forgery in this scenario,
because MD5 is not collision-resistant.

E.g., if I imported any external code or other assets like a jpeg file
in this foo-1.23.tar distribution, that external content could be
designed to make x collide with some malicious file y which has

   MD5(x) = MD5(y),

because producing MD5 collisions of arbitrary shapes and sizes is
practically at the level of a parlour trick these days.  Even if you
check that the MD5 hash of whatever you downloaded is h, you would
none the wiser if what you actually downloaded were y instead of x.

(Note: This is a collision attack, not a preimage or second-preimage
attack -- the adversary controls x and y, not h.  I just computed h
from x, once x is determined, and passed it on to you as a way to
verify your download.)

Now suppose, after the string x is determined, I pick a 32-byte string
r uniformly at random, compute h = MD5(r || x), and send you (r, h).
You download the file, again giving some string x', and you accept it
only if

   MD5(r || x') ?= h.

Nobody has shown any way to pass a forgery through this criterion.
That's what I mean by randomized MD5.

The technical security criterion I'm conjecturing of MD5 is called
target collision resistance (and in some earlier literature, UWOHF
security, short for `universal one-way hash function').  You can call
r a salt if you like.


Of course, really, I won't pass you r or h in advance; instead, I'll
pass you a public key in advance, and I will later transmit (over HTTP
or FTP or Gopher or carrier pigeon or whatever):

- the randomization string r and hash h,
- a signature s over (r, h), and
- x.

When you receive (r', h', s', x'), possibly equal to (r, h, s, x) and
possibly not, you will accept (r', h') only if the signature s'
verifies it under the public key (which will take less than a second
on bqt's VAX and martin's SS LX), and then you will accept x' only if

   MD5(r' || x') ?= h'.


All that said, any use of MD5 these days is kooky, so obviously this
protocol would raise a lot of eyebrows.  But target collision
resistance seems easier to achieve than collision resistance --
nobody's ever reported any TCR breaks on any serious hash functions
designed for CR, but there've been lots of CR breaks -- so it's an
option to improve hashing throughput when verifying distribution sets
if that turns out to be prohibitive.


> >> ECDH computations don't match.
> 
> >> 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: [...]
> 
> Well, I find them slightly disturbing, because they makes me wonder
> what VAX-specific bugs there might be in other algorithms that just
> aren't being caught.  Does the command in question compare against
> compiled-in test vectors, or does it do the computations two different
> ways (one presumably slower but more reliable) and compare, or what?

For Ed448 (the signature scheme), `openssl speed' just runs the
verification algorithm on a signature it created and prints the
message if it failed.

For X448 (the DH function), `openssl speed' runs the DH function on
both sides and prints the message if the outputs don't match.

There are also known-answer test vectors which you can run with:

   cd /usr/tests/crypto/libcrypto
   atf-run t_pubkey | atf-report

(or just `atf-run | atf-report' to run all of the libcrypto tests, not
just the public-key ones)