IETF-SSH archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Albrecht/Paterson/Watson's attack
"Mark D. Baushke" <mdb%juniper.net@localhost> writes:
> fwiw: I believe that OpenSSL extensions to KEX_DEFAULT_MAC do this:
>
> "hmac-md5-etm%openssh.com@localhost," \
> "hmac-sha1-etm%openssh.com@localhost," \
> "umac-64-etm%openssh.com@localhost," \
> "umac-128-etm%openssh.com@localhost," \
> "hmac-sha2-256-etm%openssh.com@localhost," \
> "hmac-sha2-512-etm%openssh.com@localhost," \
> "hmac-ripemd160-etm%openssh.com@localhost," \
> "hmac-sha1-96-etm%openssh.com@localhost," \
> "hmac-md5-96-etm%openssh.com@localhost," \
>
> which seems to work for them. I don't know if we want to try to make the
> -etm alternatives available as a part of the SSHv2 defined set of MACs.
I think that would be good.
Back when the ssh protocols were designed, applying the MAC to the
cleartext was uncontroversial. I think Schneier's Applied Cryptography
recommended it, with the motivation that message authentication ought to
be applied to the data that has meaning to the receiver. A possible
attack was that the enemy might tamper with the encryption key used; this
clearly changes the cleartext message, but if the MAC is applied to the
cryptotext, that type of change isn't detected.
The somewhat counter intuitive advice that the MAC should be applied to
the cryptotext is more recent, and if it's not too painful to
incorporate that in ssh in general, that would be a good thing.
Regards,
/Niels
--
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.
Home |
Main Index |
Thread Index |
Old Index