Subject: Re-using RSA1 keys as RSA

From: Frank Cusack <[email-masked]>
Date: Thu, 21 Aug 2003 21:10:13 -0700

Is there a security issue with turning an RSA1 key into an RSA key?  One
might want to do this, e.g., to move to protocol 2 without having to
update authorized_keys files.

I thought there was a problem with this, but Google doesn't find anything.

thanks
/fc

---

From: Dan Kaminsky <[email-masked]>
Date: Thu, 21 Aug 2003 23:39:07 -0600

Frank Cusack wrote:

>_______________________________________________
>openssh-unix-dev mailing list
>[email-masked]
>http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
>
It's been a while since I went over this, but I believe the reason you 
can't do this is:

SSHv1 uses RSA keys for encryption -- I send you data encrypted with 
your pubkey, you send it back to me decrypted.
SSHv2 uses RSA keys for verification -- I send you data, you send it 
back to me signed, I test to see if the data was signed correctly.

There are potential attacks involving the use of one mode against the 
other.  They're not as simple as what I once thought they were; i.e. the 
private key for decrypting is the public key for verifying -- but I 
think it was a problem nonetheless.

That being said, there really needs to be a mode to check all known host 
key types for one that matches.  This is a _real_ security requirement, 
people!  If we checked the SSHv1 key before accepting a new SSHv2 key, 
we'd be _alot_ better off for the migrators.

--Dan

---

From: "Joel N. Weber II" <[email-masked]>
Date: Fri, 22 Aug 2003 12:59:26 -0400

> we'd be _alot_ better off for the migrators.

1) That's only really true if most people haven't already migrated.  I
think it's been a year since I was really making significant use of
sshv1; everything that really matters to me has already migrated to
sshv2.

2) That's only really true if you have a fix for the habit people
develop of reacting to the MitM attack warning by deleting the
relevant known_hosts entries.

(To some extent, there is also a sysadmin behavior problem; if I
remember correctly, the sysadmins of one machine I use decided six or
eight months ago to change the host key as a result of migrating to a
new machine, and didn't send pgp signed mail with the new key when I
asked.  They also broke my authorized_keys entry, such that I couldn't
even do a login that would prevent a man in the middle from forwarding
my login to the real machine.  But they didn't break my password.)

3) That said, having a mechanism to roll over sshv2 keys to other
sshv2 keys more cleanly may well be worth having.  I'm thinking
something where a client lists the keys it trusts, and if the server
has its old private keys, it can sign the session with an old host
key, and then use SSH_MSG_HOSTKEYS (once we have that defined; I have
a mostly written draft that I should submit real soon now) to send the
new host key.

---

From: Markus Friedl <[email-masked]>
Date: Fri, 22 Aug 2003 23:03:07 +0200

> update authorized_keys files.

in protocol 1 rsa keys are used for encryption,
in protocol 2 they are used for signatures.

---

From: Dan Kaminsky <[email-masked]>
Date: Fri, 22 Aug 2003 15:27:21 -0600

>in protocol 2 they are used for signatures.
Markus--

    In protocol 2, the RSA public key verifies a signature, as in 
protocol 1, a RSA public key encrypts a token.     I'm not sure, but the 
only difference between the two may very well be the source of the token 
being operated upon -- SSHv1 has the client generate random data; SSHv2 
has the server generate and hash it.  Either way, client + pubkey 
authenticates server + privkey.

    I'm not saying it's safe to dual-purpose RSA; I'm just not entirely 
sure I've seen evidence it's dangerous to multipurpose the same RSA 
key.  Have you seen any evidence to the contrary?

--Dan

---

From: Damien Miller <[email-masked]>
Date: Sat, 23 Aug 2003 14:15:30 +1000

> key.  Have you seen any evidence to the contrary?

You have this backwards, we need evidence that this is safe.

-d