Subject: Re: SHA-2 based HMAC algorithm...

From: "denis bider \(Bitvise\)" <[email-masked]>
Date: Wed, 6 Apr 2011 23:40:17 -0400

Joseph, everyone,

I have just attempted to implement:

[email-masked]
[email-masked]

I can summarize the current state of this algorithm in one word. Awful.

I tested our implementation with two others: the Tectia client, and 
MindTerm.

In both cases, I needed to use the command line (sftpg3 for Tectia) or 
edit the textual host settings file (for MindTerm) because the graphical 
user interface of both programs has not been updated to support the 
algorithm.

I first assumed that implementations would logically follow the SSH 
transport RFC precedent, and use a 32-byte key for HMAC-256, just like 
there's a 20-byte key for SHA-1, and a 16-byte key for MD5.

Not so. It turns out that the Tectia client implementation initializes 
the [email-masked] algorithm with a 16-byte HMAC key. The MindTerm 
implementation, on the other hand, uses a 20-byte HMAC key.

So, there's just no way that you can be compatible with both 
implementations of this private algorithm without explicit compatibility 
hacks from the get-go.

I want to implement HMAC-SHA-256 support because clients have requested 
it. The @ssh.com algorithm is apparently broken, and the choice of both 
a 16-byte and a 20-byte key seems dubious.

Is there a way we can agree on HMAC-SHA-256 with a 32-byte key, call it 
"hmac-sha256", and register it?

Can we agree that this is what we'll do, and implement it?

denis

----- Original Message ----- 
From: "Joseph Galbraith" <[email-masked]>
To: <[email-masked]>
Sent: Friday, March 18, 2011 19:17
Subject: SHA-2 based HMAC algorithm...

Is there a SHA-2 based HMAC algorithm specified in any of
the recent extension RFCs?

I looked but didn't see one.

Has anyone implement such a thing as a @domain.name extension?

Thanks,

Joseph

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 07 Apr 2011 17:07:29 +1200

>"hmac-sha256", and register it?

+1.

Peter.

---

From: "Mark D. Baushke" <[email-masked]>
Date: Wed, 6 Apr 2011 23:38:18 -0700

> "hmac-sha256", and register it?

+1

Yes please. I would like to also see a 64-byte key "hmac-sha512" in the
same RFC and IANA proposal as the one for an "hmac-sha256" if there is
anyone who thinks we should do them both at the same time.

	-- Mark

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 07 Apr 2011 20:04:07 +1200

"Mark D. Baushke" <[email-masked]> writes:

>I would like to also see a 64-byte key "hmac-sha512" in the same RFC and IANA
>proposal as the one for an "hmac-sha256" if there is anyone who thinks we
>should do them both at the same time.

One minor naming nit, it would probably be best to use "hmac-sha2-256" or
something, since there'll be an "hmac-sha3-256" within the next few years 
(same for -512).

Peter.

---

From: "Mark D. Baushke" <[email-masked]>
Date: Thu, 7 Apr 2011 01:05:33 -0700

Peter Gutmann <[email-masked]> writes:

> >I would like to also see a 64-byte key "hmac-sha512" in the same RFC
> >and IANA proposal as the one for an "hmac-sha256" if there is anyone
> >who thinks we should do them both at the same time.
> 

Agreed. "hmac-sha2-256" and "hmac-sha2-512" seem like good names to me.

	-- Mark

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 07 Apr 2011 15:25:46 -0400

> "hmac-sha256", and register it?

Sure.  Write an internet-draft, get something resembling consensus on
this list, and find someone to shepherd and an AD to sponsor it.  I can
probably help with the last bits.

-- Jeff

---

From: "denis bider" <[email-masked]>
Date: Thu, 7 Apr 2011 20:31:57 -0400

I have submitted a draft:

http://www.ietf.org/id/draft-dbider-sha2-mac-for-ssh-00.txt

Comments appreciated.

denis bider

----- Original Message ----- 
From: "Jeffrey Hutzelman" <[email-masked]>
To: "denis bider (Bitvise)" <[email-masked]>
Cc: <[email-masked]>; "Joseph Galbraith" <[email-masked]>; 
<[email-masked]>
Sent: Thursday, April 07, 2011 15:25
Subject: Re: SHA-2 based HMAC algorithm...

-- Jeff

---

From: Peter Gutmann <[email-masked]>
Date: Sat, 09 Apr 2011 00:33:39 +1200

>http://www.ietf.org/id/draft-dbider-sha2-mac-for-ssh-00.txt

Just one minor nit, you should probably specify in section 2 that lengths are
in bytes (e.g. "32 bytes" rather than just "32"), given that there are bit-
lengths used in the same sentence.

Also, should at least SHA2-256 be a SHOULD?  That seems to be the most common
SHA2 variant around.

Anyone want to do some interop-testing with this?  I should be able to add
support for it later in the week when (if) I get a free day.

Peter.

---

From: "Mark D. Baushke" <[email-masked]>
Date: Fri, 8 Apr 2011 07:24:11 -0700

> support for it later in the week when (if) I get a free day.

Below is a patch adding support for it to OpenSSH 5.8p1.
(For best results used OpenSSL 0.9.8r as the ssl library.)

	-- Mark

Patch to OpenSSH 5.8p1 to support
http://www.ietf.org/id/draft-dbider-sha2-mac-for-ssh-00.txt

Index: openssh-5.8p1/mac.c
--- openssh-5.8p1/mac.c	2008-06-12 17:58:50.000000000 -0700
+++ openssh-5.8p1/mac.c	2011-04-08 07:13:30.764657000 -0700
@@ -57,6 +57,10 @@ struct {
 } macs[] = {
 	{ "hmac-sha1",			SSH_EVP, EVP_sha1, 0, -1, -1 },
 	{ "hmac-sha1-96",		SSH_EVP, EVP_sha1, 96, -1, -1 },
+	{ "hmac-sha2-256",		SSH_EVP, EVP_sha256, 0, -1, -1 },
+	{ "hmac-sha2-256-96",		SSH_EVP, EVP_sha256, 96, -1, -1 },
+	{ "hmac-sha2-512",		SSH_EVP, EVP_sha512, 0, -1, -1 },
+	{ "hmac-sha2-512-96",		SSH_EVP, EVP_sha512, 96, -1, -1 },
 	{ "hmac-md5",			SSH_EVP, EVP_md5, 0, -1, -1 },
 	{ "hmac-md5-96",		SSH_EVP, EVP_md5, 96, -1, -1 },
 	{ "hmac-ripemd160",		SSH_EVP, EVP_ripemd160, 0, -1, -1 },
Index: openssh-5.8p1/myproposal.h
--- openssh-5.8p1/myproposal.h	2011-01-13 03:00:22.000000000 -0800
+++ openssh-5.8p1/myproposal.h	2011-04-08 07:13:30.769646000 -0700
@@ -78,8 +78,9 @@
 #define	KEX_DEFAULT_MAC \
 	"hmac-md5,hmac-sha1,[email-masked],hmac-ripemd160," \
 	"[email-masked]," \
-	"hmac-sha1-96,hmac-md5-96"
+	"hmac-sha1-96,hmac-md5-96," \
+	"hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96"
 #define	KEX_DEFAULT_COMP	"none,[email-masked],zlib"
 #define	KEX_DEFAULT_LANG	""
 
Index: openssh-5.8p1/ssh.0
--- openssh-5.8p1/ssh.0	2011-02-03 17:00:02.000000000 -0800
+++ openssh-5.8p1/ssh.0	2011-04-08 07:13:30.796642000 -0700
@@ -389,8 +389,9 @@ AUTHENTICATION
      support similar authentication methods, but protocol 2 is the default
      since it provides additional mechanisms for confidentiality (the traffic
      is encrypted using AES, 3DES, Blowfish, CAST128, or Arcfour) and
-     integrity (hmac-md5, hmac-sha1, umac-64, hmac-ripemd160).  Protocol 1
-     lacks a strong mechanism for ensuring the integrity of the connection.
+     integrity (hmac-md5, hmac-sha1, hmac-sha2-256, hmac-sha2-512,
+     umac-64, hmac-ripemd160). Protocol 1 lacks a strong mechanism for
+     ensuring the integrity of the connection.
 
      The methods available for authentication are: GSSAPI-based
      authentication, host-based authentication, public key authentication,
Index: openssh-5.8p1/ssh.1
--- openssh-5.8p1/ssh.1	2010-11-19 20:21:03.000000000 -0800
+++ openssh-5.8p1/ssh.1	2011-04-08 07:13:30.897576000 -0700
@@ -664,7 +664,9 @@ Both protocols support similar authentic
 but protocol 2 is the default since
 it provides additional mechanisms for confidentiality
 (the traffic is encrypted using AES, 3DES, Blowfish, CAST128, or Arcfour)
-and integrity (hmac-md5, hmac-sha1, umac-64, hmac-ripemd160).
+and integrity (hmac-md5, hmac-sha1,
+hmac-sha2-256, hmac-sha2-512,
+umac-64, hmac-ripemd160).
 Protocol 1 lacks a strong mechanism for ensuring the
 integrity of the connection.
 .Pp
Index: openssh-5.8p1/ssh_config.0
--- openssh-5.8p1/ssh_config.0	2011-02-03 17:00:03.000000000 -0800
+++ openssh-5.8p1/ssh_config.0	2011-04-08 07:13:30.812638000 -0700
@@ -451,7 +451,9 @@ DESCRIPTION
              must be comma-separated.  The default is:
 
                    hmac-md5,hmac-sha1,[email-masked],
-                   hmac-ripemd160,hmac-sha1-96,hmac-md5-96
+                   hmac-ripemd160,hmac-sha1-96,hmac-md5-96,
+                   hmac-sha2-256,hmac-sha256-96,hmac-sha2-512,
+                   hmac-hmac-sha2-512-96
 
      NoHostAuthenticationForLocalhost
              This option can be used if the home directory is shared across
Index: openssh-5.8p1/ssh_config.5
--- openssh-5.8p1/ssh_config.5	2010-12-25 19:26:48.000000000 -0800
+++ openssh-5.8p1/ssh_config.5	2011-04-08 07:13:30.902578000 -0700
@@ -770,7 +770,9 @@ Multiple algorithms must be comma-separa
 The default is:
 .Bd -literal -offset indent
 hmac-md5,hmac-sha1,[email-masked],
-hmac-ripemd160,hmac-sha1-96,hmac-md5-96
+hmac-ripemd160,hmac-sha1-96,hmac-md5-96,
+hmac-sha2-256,hmac-sha256-96,hmac-sha2-512,
+hmac-sha2-512-96
 .Ed
 .It Cm NoHostAuthenticationForLocalhost
 This option can be used if the home directory is shared across machines.
Index: openssh-5.8p1/sshd.0
--- openssh-5.8p1/sshd.0	2011-02-03 17:00:02.000000000 -0800
+++ openssh-5.8p1/sshd.0	2011-04-08 07:13:30.839599000 -0700
@@ -167,8 +167,8 @@ AUTHENTICATION
      AES, Blowfish, 3DES, CAST128, Arcfour, 192-bit AES, or 256-bit AES.  The
      client selects the encryption algorithm to use from those offered by the
      server.  Additionally, session integrity is provided through a
-     cryptographic message authentication code (hmac-md5, hmac-sha1, umac-64
-     or hmac-ripemd160).
+     cryptographic message authentication code (hmac-md5, hmac-sha1, umac-64,
+     hmac-ripemd160, hmac-sha2-256 or hmac-sha2-512).
 
      Finally, the server and the client enter an authentication dialog.  The
      client tries to authenticate itself using host-based authentication,
Index: openssh-5.8p1/sshd.8
--- openssh-5.8p1/sshd.8	2010-11-04 16:20:14.000000000 -0700
+++ openssh-5.8p1/sshd.8	2011-04-08 07:13:30.908565000 -0700
@@ -314,7 +314,8 @@ The client selects the encryption algori
 to use from those offered by the server.
 Additionally, session integrity is provided
 through a cryptographic message authentication code
-(hmac-md5, hmac-sha1, umac-64 or hmac-ripemd160).
+(hmac-md5, hmac-sha1, umac-64, hmac-ripemd160,
+hmac-sha2-256 or hmac-sha2-512).
 .Pp
 Finally, the server and the client enter an authentication dialog.
 The client tries to authenticate itself using
Index: openssh-5.8p1/sshd_config.0
--- openssh-5.8p1/sshd_config.0	2011-02-03 17:00:02.000000000 -0800
+++ openssh-5.8p1/sshd_config.0	2011-04-08 07:13:30.881570000 -0700
@@ -375,7 +375,9 @@ DESCRIPTION
              separated.  The default is:
 
                    hmac-md5,hmac-sha1,[email-masked],
-                   hmac-ripemd160,hmac-sha1-96,hmac-md5-96
+                   hmac-ripemd160,hmac-sha1-96,hmac-md5-96,
+                   hmac-sha2-256,hmac-sha256-96,hmac-sha2-512,
+		    hmac-sha2-512-96
 
      Match   Introduces a conditional block.  If all of the criteria on the
              Match line are satisfied, the keywords on the following lines
Index: openssh-5.8p1/sshd_config.5
--- openssh-5.8p1/sshd_config.5	2010-12-25 19:26:48.000000000 -0800
+++ openssh-5.8p1/sshd_config.5	2011-04-08 07:13:30.926577000 -0700
@@ -654,7 +654,9 @@ Multiple algorithms must be comma-separa
 The default is:
 .Bd -literal -offset indent
 hmac-md5,hmac-sha1,[email-masked],
-hmac-ripemd160,hmac-sha1-96,hmac-md5-96
+hmac-ripemd160,hmac-sha1-96,hmac-md5-96,
+hmac-sha2-256,hmac-sha256-96,hmac-sha2-512,
+hmac-sha2-512-96
 .Ed
 .It Cm Match
 Introduces a conditional block.

---

From: "denis bider \(Bitvise\)" <[email-masked]>
Date: Fri, 8 Apr 2011 15:56:49 -0400

> Just one minor nit, you should probably specify
> in section 2 that lengths are in bytes (e.g.
> "32 bytes" rather than just "32"), given that
> there are bit-lengths used in the same sentence.

Fair point.

I updated the draft with this change:

http://www.ietf.org/id/draft-dbider-sha2-mac-for-ssh-01.txt

> Anyone want to do some interop-testing with this?
> I should be able to add support for it later in the
> week when (if) I get a free day.

Great. I'll add support for it in WinSSHD and post a link to a 
pre-release build when it's ready.

denis

---

From: Simon Tatham <[email-masked]>
Date: Sat, 09 Apr 2011 10:26:57 +0100

> http://www.ietf.org/id/draft-dbider-sha2-mac-for-ssh-01.txt

Another minor nit: you're referencing HMAC, so you should add a
reference to RFC 2104 in which the HMAC construction is defined.

Meanwhile, I've done the implementation of this draft for PuTTY. At

    http://tartarus.org/simon/20110409-putty-sha2

I've uploaded a complete set of PuTTY executables (in the 'x86'
subdir) and source archives modified for SHA-2 support, together
with the source code patch (in 'sha2.diff'). I've verified that all
four of the new MACs work against OpenSSH 5.8p1 with Peter Gutmann's
patch applied.

Cheers,
Simon
-- 
Simon Tatham         "Imagine what the world would be like if
<[email-masked]>    there were no hypothetical situations..."

---

From: "denis bider \(Bitvise\)" <[email-masked]>
Date: Sat, 9 Apr 2011 19:36:25 -0400

> Another minor nit: you're referencing HMAC,
> so you should add a reference to RFC 2104
> in which the HMAC construction is defined.

No problem.

I submitted a new version of the draft with references to RFC 2104 and 
RFC 4231:

http://www.ietf.org/id/draft-dbider-sha2-mac-for-ssh-02.txt

denis

---

From: "denis bider \(Bitvise\)" <[email-masked]>
Date: Sat, 9 Apr 2011 20:58:54 -0400

> I've uploaded a complete set of PuTTY executables
> (in the 'x86' subdir) and source archives modified
> for SHA-2 support,

I also implemented the new algorithms in WinSSHD.

The latest build supporting the hmac-sha2-256 and hmac-sha2-256-96 
algorithms can be found here:

http://dl.bitvise.com/WinSSHD-524-Pre1.exe

Both algorithms appear to work fine with the PuTTY build provided by 
Simon.

denis bider

---

From: [email-masked] (Niels Möller)
Date: Sun, 10 Apr 2011 08:35:30 +0200

> "hmac-sha256", and register it?

I see you're trying to follow the hmac definitions in RFC 4253. But is
there any good reason a hmac keysize should match the digest size, in
general? My understanding of hmac keysize, is that

  * it can't usefully exceed the internal hash blocksize (64 bytes for
    sha1 and sha-2-256, 128 bytes for sha-2-512)

  * should be large enough to exclude keysearch, by a reasonable margin

Any other concerns I'm missing? Is the birthday paradox relevant to hmac
in some way?

My gut-feeling is that the suggested keysize (64 bytes, 512 bits) for
hmac-sha2-512 is ridiculously large for a symmetric cryptographic
construction. 20 bytes (160 bits) seem sufficient, and 32 bytes (256
bits) is overkill for the foreseeable future.

I fully support a spec for using sha-2, but I'd like to see some
motivation for the chosen key sizes. 

Ah, and one other thing: Would it make sense to use hmac-sha2-224-96
(different initial state) rather than hmac-sha2-256-96? I confess I
never really understood the rationale behind sha2-224 and sha2-384.

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.

---

From: Peter Gutmann <[email-masked]>
Date: Mon, 11 Apr 2011 00:25:29 +1200

Simon Tatham <[email-masked]> writes:

>I've verified that all four of the new MACs work against OpenSSH 5.8p1 with
>Peter Gutmann's patch applied.

While I'd like to take credit for it :-), that wasn't my patch.  I'll get it
into my code later this week, sorry, terribly snowed under with other work at
the moment.

Peter.

---

From: Peter Gutmann <[email-masked]>
Date: Mon, 11 Apr 2011 00:32:01 +1200

[email-masked] (Niels =?iso-8859-1?Q?M=F6ller?=) writes:

>My gut-feeling is that the suggested keysize (64 bytes, 512 bits) for hmac-
>sha2-512 is ridiculously large for a symmetric cryptographic construction. 20
>bytes (160 bits) seem sufficient, and 32 bytes (256 bits) is overkill for the
>foreseeable future.

The convention, both for pre-SHA2 hashes, and in other protocols where SHA2
hashes are used, is to use the block size as the key size.  I agree that it's
overkill, but in pretty much every case where it's used, it's the output of a
PRF, and so key size doesn't really matter.

>(different initial state) rather than hmac-sha2-256-96? I confess I never
>really understood the rationale behind sha2-224 and sha2-384.

To quote someone on another list (possibly SAAG), SHA2-224 and -384 were
created by NIST to confuse the crypto-clueless.  They're barely supported and
have no real reason for existence, please don't use them.

Peter.

---

From: [email-masked] (Niels Möller)
Date: Sun, 10 Apr 2011 14:56:45 +0200

Peter Gutmann <[email-masked]> writes:

> hashes are used, is to use the block size as the key size.

I see. I take it you mean *digest* size, not *block* size (or else,
hmac-sha1 would use a keysize of 64 octets / 512 bits)?

I guess there's some value in doing the same thing as everybody else, as
long as that way is silly rather than actually broken.

(And I should modify my previous statement that key size "can't usefully
exceed the internal hash blocksize". After thinking just a little bit
more I realized that key sizes larger than the *digest* size are not
very useful, since it's the digest size, rather than the block size,
which corresponds to the size of the internal state. This makes the
convention of using keys of the same size as the digest more
understandable. Sorry for the confusion).

> created by NIST to confuse the crypto-clueless. 

The only property of sha224 which you don't get with sha256 with
trunctated output, is that its difficult, given a sha256 hash of unknown
data, to produce a sha224 hash for the same data (and similarly for
sha512 and sha384). And also in the other direction, given a sha256 hash
of unknown data, truncated to 224 bits, one could guess the missing bits
with a success probablility of 2^{-32}; that is a lot harder to do based
on the sha224 hash of the data.

I don't know any protocol or scenario where these sha224 properties are
important or desirable, but maybe there is some?

Regards,
/Niels

---

From: [email-masked] (Niels Möller)
Date: Sun, 10 Apr 2011 19:06:43 +0200

Dan Brown <[email-masked]> writes:

> HMAC accepts any key size, so adding key size to alg name seems odd.

SSH precedent seem to be that if only a single key size is ever going to
be used (either just in the SSH protocol, or ever, anywhere), then don't
include key size in the id. Examples: "3des-cbc", "arcfour",
"hmac-sha1". And if several distinct keysizes are expected to be used, the
key size is included in the id. Examples: "aes128-cbc".

For HMAC, I don't see any need to support, e.g., hmac-sha2-256, with
several different key sizes, so there's no need to include the key size
in the identifier.

> Nevertheless, parties must use the same key size, maybe the protocol,
> ie SSH, using HMAC should fix key size to the largest not requiring an
> extra hash?

To size must be specified. But using the hash block size (which I think
is what you're suggesting) seem unnecessarily large. That would meen 512
bits for hmac-sha1 (for which use in the ssh protocol is specified to
use a 160 bit key), and 1024 bits for hmac-sha2-512, which I find
totally out o fproportions. And the effective key size (i.e., the size
of the internal state an attacker need to recover in order to form valid
MACs) is limited to the digest size, or possibly twice the digest size,
if I understand hmac correctly.

Regards,
/Niels

---

From: Dan Brown <[email-masked]>
Date: Sun, 10 Apr 2011 11:25:34 -0400

What about FIPS 180-4, which, if I recall, defines SHA-512-256, a truncation of SHA-512 with a different IV?

Arguably for use in HMAC it could be truncated to 128 bits (or less), so one could have:

HMAC-SHA2-512-256-128 

(But I didn't yet check what 180-4 wants for HMAC.)

With regard to naming, to avoid ambiguity with future 180-4 followers, the number of numbers following SHA2 could be used to determine their meaning: with 180-4 truncation requiring three numbers even if no further HMAC tag truncation is applied, eg HMAC-SHA2-512-256-256.

HMAC accepts any key size, so adding key size to alg name seems odd.  Nevertheless, parties must use the same key size, maybe the protocol, ie SSH, using HMAC should fix key size to the largest not requiring an extra hash?

Best regards,

Dan

----- Original Message -----
From: Peter Gutmann [mailto:[email-masked]]
Sent: Sunday, April 10, 2011 08:32 AM
To: [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Cc: [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: SHA-2 based HMAC algorithm...

Peter.

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

---

From: "denis bider \(Bitvise\)" <[email-masked]>
Date: Mon, 11 Apr 2011 01:13:21 -0400

> My gut-feeling is that the suggested keysize (64 bytes,
> 512 bits) for hmac-sha2-512 is ridiculously large for a
> symmetric cryptographic construction. 20 bytes (160 bits)
> seem sufficient, and 32 bytes (256 bits) is overkill for
> the foreseeable future.

That could likely be the case.

On the other hand, if someone is going to chose HMAC-SHA2-512, they are 
likely chosing it for the bigger numbers over HMAC-SHA2-256.

I think HMAC-SHA2-512 is likely an overkill. 64 bytes for integrity 
verification, appended to every message, is a lot. At the moment, I 
won't be implementing support for this algorithm because it just seems 
like it has little benefit over HMAC-SHA2-256.

If others don't plan to support SHA2-512 either, we can consider simply 
removing it.

But if people intend to support HMAC-SHA2-512, then they want it for the 
bigger numbers. And in that case, why not give them a big key size, too?

I'm not seeing how the larger key size hurts. According to my 
measurement at least, the performance impact of encryption and MAC is 
negligible compared to other aspects of an SSH session. It seems to me 
that the mammoth size of the digest itself would matter more than the 
key size, if you're going for SHA2-512 to begin with.

denis

---

From: [email-masked] (Niels Möller)
Date: Mon, 11 Apr 2011 07:47:32 +0200

> likely chosing it for the bigger numbers over HMAC-SHA2-256.

Not necessarily. On 64-bit hardware, sha512 can be faster than sha256
(in my implementation, I get 18 cycles/byte for sha256, and 12
cycles/byte for sha512, benchmarked on an intel core2. And 8
cycles/byte for sha1).

I was bit surprised when I first noticed this. Without any deep
analysis, I think it simply works like this: the compression function
takes more time for sha512 than sha256 (30% slower in my benchmarks),
but then it processes twice as many input bytes.

> I'm not seeing how the larger key size hurts.

I guess it's no big problem, just a few more bytes to generate from the
"raw" session key. I was asking for a motivation, since I thought you
might have had some reason, besides the annoying incompatibility, to
complain on the existing implementations using 16 byte or 20 byte hmac
keys for [email-masked]). To me it would make some sense to stick
to a 20 byte (160 bit) key for all hmac-sha2 variants.

But if there's no more compelling motivation than "that's what other
protocols are doing", I guess I will have to be satisfied with that.

Regard,
/Niels

---

From: Peter Gutmann <[email-masked]>
Date: Mon, 11 Apr 2011 19:12:11 +1200

>Arguably for use in HMAC it could be truncated to 128 bits (or less), so one

Argh, no!  The point is to have a single common SHA2 version that everyone can
agree on (or possibly two), not to do a breadth-first walk of every bizarrro
mutation of SHA2 that NIST has dreamed up.  Currently we have SHA2-256,
SHA2-512, SHA2-384, SHA2-224, SHA2-chipotle, SHA2-streaky-bacon, SHA2-
thousand-island, SHA2-chunky, SHA2-extra-chunky, SHA2-barbeque, SHA2-salt-
and-vinegar, SHA2-balsamic-vinaigrette, SHA2-caesar, SHA2-organic-sea-salt,
and SHA2-barium-enema, but what's mostly implemented in practice is SHA2-256
and... nope, can't actually recall seeing anything else in use in practice
[0].  So all we need to do is choose one standard mode with 256 bits of output
to match SHA2-256, and probably another one for SHA2-512 for people who feel
the need to make that particular fashion statement.  Just because NIST hands
us a really long coil of rope, doesn't mean we have to use it [1].

Peter.

[0] OK, I've seen -512 and -384 in obscure, isolated implementations, but I've
    also seen Whirlpool and Tiger and others.  I think I saw SHA-224 on
    display at the Ripley's Odditorium, but it may have been Haval.
[1] This rant contains approximately 85% recycled content from another list
    that's just gone through the same thing.

---

From: Dan Brown <[email-masked]>
Date: Mon, 11 Apr 2011 10:55:19 -0400

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Peter Gutmann

> >What about FIPS 180-4, which, if I recall, defines SHA-512-256, a
> truncation
> >of SHA-512 with a different IV?
> >
> >Arguably for use in HMAC it could be truncated to 128 bits (or less),
> so one
> >could have:
> >
> >HMAC-SHA2-512-256-128
> 

I agree: a single interoperable HMAC-SHA2 variant is sensible, since all SSH implementations should have no problem.

So, my points were merely (a) to give SSH a heads up on NIST activities, and (b) to suggest a future naming solution for any future 180-4 adherents: use three #s, but I admit that I'm not sure how much SSH needs to NIST-comply.

> [1] This rant 

In NIST's defense: (1) hashes tend to get used in bizarre ways, hence the need for extra care (new IVs in draft FIPS 180-4), and (2) it is not uncommon that crypto algorithms include steps which do not prevent known attacks (e.g. provably secure algs, OAEP, PSS, etc., some of which may later resist later discovered attacks, but others which may never.)  

SSH is surely not a case of (1), so probably no need for draft FIPS 180-4, i.e. HMAC-SHA2-512 can go without the new IV, for the few who'd use SHA-512 (say, for the speed?)

---

From: Dan Brown <[email-masked]>
Date: Mon, 11 Apr 2011 11:17:22 -0400

> From: Niels Möller [mailto:[email-masked]]
> Sent: Sunday, April 10, 2011 1:07 PM
> 

> is what you're suggesting) seem unnecessarily large. That would meen

You're right: what I said implies a block size key, which is larger than the hash size.  I perhaps intended hash size: I was wrongly thinking that the HMAC definition hashed any keys longer than the hash size.  

This may be unnecessarily large, but it's not too costly to generate to generate a block length key pseudo-randomly.

> 512

I don't quite understand your argument about the internal state.  

I agree that a tag-guessing attack has success rate depending only on the tag size.  So, with respect a forging a single MAC, there seems to be no advantage to having a key larger than a MAC.

If the MAC key is re-used, then the situation is a little different.  As I understand HMAC, every block-sized should create a different MAC function because the outer hash (with opad). I'm not seeing the hash-length bottleneck of the internal state.

That all said, the way MACs are generally used is for immediate authentication.  So, in terms of the threat prevented, MACs are an algorithm of least concern.  By contrast, digital signatures and encryption sometimes need long-term protection to resist future attackers  (though I suppose MACs used in storage need long term protection), so an argument for larger key sizes may be useful in those cases.

Therefore, the minimum key size recommended for HMAC, the hash length, is probably fine.  Indeed, if one matches AES-128 with HMAC-SHA256, then the authentication key is already twice the size of the encryption key (which is backwards according to the prudent future-proofing argument above).

---

From: Dan Brown <[email-masked]>
Date: Mon, 11 Apr 2011 13:51:02 -0400

> Behalf Of Dan Brown
> Sent: Monday, April 11, 2011 11:17 AM
> To: 'Niels Möller'
> 
> > 512

Oops, now I understand.  Sorry.  Your argument is right.  The pair of values Hash(K+opad) and Hash(K+ipad) is indeed an internal state, and is a bottleneck on the effective key size equal to twice the hash (digest) length.

---

From: "denis bider" <[email-masked]>
Date: Mon, 11 Apr 2011 19:34:26 -0400

> I was asking for a motivation, since I thought you might
> have had some reason, besides the annoying incompatibility,
> to complain on the existing implementations using 16 byte
> or 20 byte hmac keys for [email-masked]). To me it
> would make some sense to stick to a 20 byte (160 bit)
> key for all hmac-sha2 variants.

If we're moving towards a 256-bit hash for key exchange as well as data 
integrity, then the output of the key generation function will be 
256-bit, and we would have to truncate that output if we want the HMAC 
key to be 160 bits. I don't see a compelling reason to not use the whole 
key, given that we're generating it anyway.

That's my response to "why 32-byte key for hmac-sha2-256".

As for whether the key size for hmac-sha2-512 is 32 bytes or 64 bytes, I 
don't have a strong preference either way.

denis

---

From: "denis bider" <[email-masked]>
Date: Mon, 11 Apr 2011 19:37:25 -0400

> Argh, no!  The point is to have a single common SHA2 version
> that everyone can agree on (or possibly two), not to do a
> breadth-first walk of every bizarrro mutation of SHA2
> that NIST has dreamed up.

That made me laugh. :-)

Agreed entirely.

denis

---

From: [email-masked] (Niels Möller)
Date: Tue, 12 Apr 2011 07:13:28 +0200

"denis bider" <[email-masked]> writes:

> key to be 160 bits. 

I see. Thanks for the explanation.

Regards,
/Niels

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 14 Apr 2011 17:45:30 +1200

Simon Tatham <[email-masked]> writes:

>I've uploaded a complete set of PuTTY executables (in the 'x86' subdir) and
>source archives modified for SHA-2 support, together with the source code
>patch (in 'sha2.diff'). I've verified that all four of the new MACs work
>against OpenSSH 5.8p1

Works with cryptlib as well, after a two-line change :-).

(One minor gripe, it would be nice if Putty's log window was resizeable and/or
defaulted to being a bit larger than two adjacent low-denomination postage
stamps).

Peter.