Re: HTTPS trust anchors in sysinst

> [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!]

That could be me, because I normally do reply to just the list when the
list was one of the recipients.  This is somewhat of a Golden Rule
thing for me, because I find it annoying to get two identical messages,
one through the list and one off-list, and I try to avoid annoying
others likewise.  I will try to remember to send you an off-list copy;
my apologies in advance because I will probably forget sometimes.

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

>> 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?

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		[email protected]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B