RE: Experimental server for RSA SHA-2
Damien Miller <[email protected]>
| Newsgroups | gmane.ietf.secsh |
|---|---|
| Message-ID | <[email protected]> |
On Tue, 10 Nov 2015, Peter Gutmann wrote: > Damien Miller <[email protected]> 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