[SECNET] hash choice bug with crazy configs in versions 0.5.x

[Ian Jackson]

tl;dr:
  If you inadviseably configured your secnet to use md5, 0.5.x
  can be broken and I propose to break it differently in 0.6.x.

In secnet 0.5.x, I changed the way secnet thinks about the
relationship between hash functions and signature schemes.  Nowadays,
the theory is that a signature scheme and public key is generally
expected to specify a hash function; so loading a key (private or
public) states or implies the hash to be used, too.

Previously, the hashing was done by the signing algorithm's caller;
ie, the site code.  So the hash was per-site.

When I made this change, I didn't think there were any setups which
would use different hash functions and I didn't think carefully enough
about the consequences of the new arrangements.

The new arrangements break badly if there are different sites in the
same config with the same rsa key but specifying different hash
functions.  The effect is that the wrong hash function can be used,
resulting in failed signature verifications.  One end reports these
in the log and the other would see simply a timeout (roughly at
SENTMSG3 or SENTMSG4).

Such setups are rather cryptographically unsound setup, and there has
never been any good reason for anyone to have specified a hash other
than sha1.  But I didn't consciously consider such setups and
therefore I didn't intend to break them in this way.

It would be possible to arrange that the same rsa1 key can be used
with different hash functions by different sites but I am not inclined
to do so because it makes things considerably more complicated, as
well as being cryptographically unsound (and pointless with the
current set of hash functions).

My plan, instead, is as follows:

I will change the signing key closures "rsa-private" and "rsa-public"
to always try to determine the hash from their own dictionary context
available while loading the key.  If no "hash" is found, they will
default to "sha1".

The effect is that the "hash" key in sites files will take effect for
the local site's view of the hash to be used when verifying signatures
made by the peers, as before.  So this will (in configurations
generated with "make-secnet-sites") restore the verifier behaviour
(ie, the semantics of rsa public key definitions) to that in secnet
0.4.x and earlier.

But the local private key will always use a single, global hash
function.  In existing installations this will probably be sha1.  For
installations of 0.4.x and earlier where another hash is in use, it
will be necessary to do one of: (i) have a flag day when everyone
switches to sha1 (ii) adjust the global config to load the same rsa
key twice with different hashes or (iii) adjust the global config of
sites being upgraded, to set the non-sha1 hash explicitly.  If (iii)
is chosen, and different peers of the same site expect different
hashes, it will be necessary to put the hash explicitly in some of the
sites file entries.

(For configurations not made with make-secnet-sites, there is still a
change compared to 0.4.x: the hash function to be used is that in
force for the rsa-public invocation, not the one in force for the site
invocation.  I don't expect this change to affect anyone in practce.)

Ian.

-- 
Ian Jackson <ijackson at chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.