RE: Experimental server for RSA SHA-2

[Damien Miller <djm%mindrot.org@localhost>]

On Tue, 10 Nov 2015, Peter Gutmann wrote:

> Damien Miller <djm%mindrot.org@localhost> writes:
> 
> >I don't think this is right: the hash used in the signature algorithm has
> >always been independent of the key exchange hash. 
> 
> Is it?  I hope I'm not reading this wrong, but the exchange hash H is what's
> signed, and that's what's calculated using the hash algorithm HASH, which is
> specified by e.g. "diffie-hellman-group-exchange-sha256".  So
> "server_host_key_algorithms" can say RSA or DSA or ECDSA, but not the hash,
> since that's implicit from "kex_algorithms".

Yes, the kex method specifies an output hash. The output hash is reused for
key derivation too.

The signature methods *also* have implicit (or explicit in the ecdsa cases)
input hashes.

I.e. a current ssh-rsa kex signature is roughly

RSA( PKCS1_PAD( SHA1( KEX_HASH( ... ) ) ) )

Over the banner+kexinit+etc blob.

The publickey authentication hash isn't as redundant, since it doesn't
have the inner kex hash.

> >I don't really care for bikeshedding names, but if I were picking it,
> >then it would be "rsa-pss-sha256".
>
> It definitely needs to indicate quite clearly that it uses a signature
> form that's not compatible with anything else that SSH has ever used.
> I'd vote for "crunchy-raw-unboned-real-dead-frog-rsa-pss".
>
> Could I also suggest that the draft include a facility to use standard
> PKCS #1 sigs? I really don't want to have to implement a nonstandard
> (meaning not used by any other part of SSH, or any other protocol like
> PGP, S/MIME, TLS, etc) signature format just to be able to use SHA-256
> in a sig.

Please no; I was counting the absence of ASN.1 formatting in the
proposed signature scheme as a significant improvement.

-d