IETF-SSH archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Terrapin



Mouse <mouse%Rodents-Montreal.ORG@localhost> writes:

> My second thought: always make the first message after kex a verifier
> message, with content depending predictably on kex output, as a final
> test of the integrity of the encrypted channel.

Say, like sending a SSH_NEWKEYS2 message? So key exchange ends by
sending SSH_NEWKEYS using old keys (i.e., cleartext for the initial key
exchange), followed by an SSH_NEWKEYS2 message using the new keys, where
the purpose of SSH_NEWKEYS2 is to (implicitly) agree on the initial
sequence number.

I haven't read the paper yet, I've only had a quick look at the intro
material. I got the impression that new "modern" mac algorithms that
apply mac to the ciphertext, are more vulnerable than the old fashioned
way of the original rfc 4253, that applies the mac to the *unencrypted*
packet payload. If that's right, that's rather interesting.

If one were to make larger changes, one could also consider stuff like
deriving the new keys based on hashing of the newly negotiated shared
secret *and* the sequence number of the SSH_NEWKEYS message.

Regards,
/Niels

-- 
Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677.
Internet email is subject to wholesale government surveillance.



Home | Main Index | Thread Index | Old Index