hmac-ripemd160 not in PROTOCOL

Darren Tucker dtucker at
Sat Nov 7 21:44:11 AEDT 2015

On Sat, Nov 7, 2015 at 8:02 PM, Max Horn <max at> wrote:
>> On 07.11.2015, at 04:43, Darren Tucker <dtucker at> wrote:
>> I suspect the @openssh one was before ripemd was added to the (at the
>> time in draft) standards, and the new name was added once it was.
> Ahhh, I am sorry, I should have lead with this: To the best of my knowledge,
> hmac-ripemd160 occurs nowhere in the SSH specification, and is an OpenSSH
> extension. Hence, I am surprised to see "hmac-ripemd160" in the mac list,
> without the, and was wondering about the story behind it...
> But I am happy to learn I am wrong, though then I'd also like to learn which
> standard you are referring to?

I was referring to RFC4253 et al, but only assumed it was there
because of the lack of @openssh suffix on the MAC name, not because I
had gone looking for it.  Having just done so I agree that it's not
there!  I also can't find it in any of the internet-draft specs.

While trying to figure this out, I found the following interesting things:
Markus' early comment on OpenSSH protocol 2 support mentions hmac-ripemd160:

This manual for the software dated 2003 lists hmac-ripemd160
as a supported MAC.

The snail book says "OpenSSH also implements a nonstandard MAC
algorithm, hmac-ripemd160 at  The name hmac-ripemd160 is
also recognised without the suffix, but this is
deprecated, since all nonstandard names are supposed to use a domain

Since this was before Portable pulled synced individual commits, I
went back to the OpenBSD tree.
hmac-ripemd160 at openssh appeared in a commit from Markus on 2000-04-03
with the description "DSA, keyexchange, algorithm agreement for ssh2".
hmac-ripemd160 without the suffix first appeared in a commit by Markus
on 2001-02-11 (
with this description:
1) clean up the MAC support for SSH-2
2) allow you to specify the MAC with 'ssh -m'
3) or the 'MACs' keyword in ssh(d)_config
4) add hmac-{md5,sha1}-96
        ok stevesk@, provos@

In summary, I have no idea why it ended up the way it did.  Maybe
Markus can recall?

Darren Tucker (dtucker at
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.

More information about the openssh-unix-dev mailing list