Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [STDS-802-11] document 11-14/1104r1 for TGmc



--- This message came from the IEEE 802.11 Working Group Reflector ---

Hello,

>   There are 3 families of the Secure Hash Algorithm. There's the 1st family of
> SHA, (which is just designated SHA1) and there's the 2nd family of SHA (known
> as SHA2) which is SHA256 and SHA512, including truncated versions of each,
> SHA224 is a truncated version of SHA256 and SHA384 is a truncated version of
> SHA512.

This claim is at variance with FIPS PUB 180-3-2008, referred to in clause 2,
which in turn states that "This Standard specifies five secure hash algorithms
- SHA-1, SHA-224, SHA-256, SHA-384, and SHA-512".  If the hashes have been
renamed, then we need to update the reference in clause 2 (I note that this
document was superseded in 2012, but the latest version, namely
http://csrc.nist.gov/publications/fips/fips180-4/fips-180-4.pdf ,
still states that "This Standard specifies secure hash algorithms
- SHA-1, SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224 and SHA-512/256",
so it seems that the names of the hash algorithms in question do have a hyphen).

>   It is important to understand, though, that SHA1, SHA256, and SHA512 are
> different. They are not just truncated versions of the same function. And while
> SHA256 does actually produce 256-bits of digest output, SHA1 does not
> produce 1-bit of digest output, it produces 160-bits.  But we (802.11) do
> truncate the output of SHA family hash functions. For instance, we sometimes
> want only the first 128-bits of SHA1. Just to make things more complicated,
> we also use the HMAC construct with a SHA family algorithm.

I agree with all of this, and 14/1104r1 does not contradict any of this.

>   So how to deal with identifying the appropriate algorithm in the appropriate
> family of SHA, whether it is alone or as HMAC, and how to identify the particular
> output bit length that we are concerned with? 11-14/1104r1 does a poor job.
> Let me propose a better way:
>   * the particular algorithm of the family is used without any hyphens- for
>      example, it's SHA256 not SHA-256, and it's SHA1 always.

I believe this violates FIPS PUB 180-3-2008, referred to in clause 2.

>   * when we want to truncate we add a hyphen and indicate the bit length we
>      want to use- for example, it's SHA256-128 (not sure why we'd do this but it's
>      an example) or SHA1-128.

I'm fine with this.  One would have to fix the "SHA-256-128" at 2009.58
(in the "AP PeerKey protocol").
 
>   * if we don't add a hyphen and number indicating truncation then the entire
>      length of the algorithm output is used.

I'm fine with this, and 14/1104r1 does this.

>   * if we want to use the HMAC construct we prepend "HMAC-" to the SHA family
>      algorithm indicated, including any possible indication of truncation- for
>      example, HMAC-SHA256 or HMAC-SHA1-128.

I'm fine with this, and 14/1104r1 does this.

>   * if we don't prepend "HMAC-" then we are using the algorithm directly, and
>      not as a keyed hash function.

I'm fine with this, and 14/1104r1 does this.

>   While 11-14/1104r1 does this correct in some cases- it proposes to
> change "HMAC-SHA-256" to "HMAC-SHA256"-- it does it wrong in other
> cases- it proposes to change "SHA1" to "SHA-1".

SHA-1 is correct when it refers to the name of the hash, per
FIPS PUB 180-3-2008, referred to in clause 2.

I am fine with changing HMAC-SHA-1 to HMAC-SHA1, though as 11/1104r1
points out, HMAC-SHA-1 is the terminology used in RFC 2202,
referred to in Annex A (informative).

>   Also, if we adopt this more correct way of referring to these various
> incarnations of hashing we do not need to say something like
> "Truncate-128(HMAC-SHA1(xxx))" we just say HMAC-SHA1-128(xxx)".

This change implies a significant difference, namely that
Truncate-128 requires irretrievable deletion of the bits beyond
bits 0-127, while HMAC-hash-128 does not.  I am not opposed to
requiring HMAC-hash-len to be specified as irretrievably deleting
extraneous bits, but this is a technical change beyond the scope
of 14/1104r1.

>   Minor grammatical gripe: there is no such algorithm called
> "HMAC-SHA1-64"

There are explicit references to "the HMAC-SHA1-64 hash algorithm"
at 958.64 and "HMAC-SHA1-64 hash algorithm" (missing article) at
1767.6.

>, or even "HMAC-SHA-1-64" so we should not be using
> the definite article when describing the use of SHA1 in an HMAC
> construct while truncating the output to 64 bits.

Observe the use of the definite article before "HMAC-SHA1[-n]"
at 1932.38, 1935.37, 1941.62.  However, if it is felt that the
term should not be accompanied by an article, I fine with that.

Mark

-- 
Mark RISON, Standards Architect, WLAN   English/Esperanto/Français
Samsung Cambridge Solution Centre       Tel: +44 1223  434600
Innovation Park, Cambridge CB4 0DS      Fax: +44 1223  434601
ROYAUME UNI                             WWW: http://www.samsung.com/uk


> -----Original Message-----
> From: *** IEEE stds-802-11 List *** [mailto:STDS-802-11@xxxxxxxx] On Behalf Of Dan Harkins
> Sent: 18 September 2014 10:14
> To: STDS-802-11@xxxxxxxxxxxxxxxxx
> Subject: [STDS-802-11] document 11-14/1104r1 for TGmc
> 
> --- This message came from the IEEE 802.11 Working Group Reflector ---
> 
>   Hello,
> 
>   I may not be at the 11mc session where 11-14/1104r1 is presented so I
> want to get discussion on it started on the mailing list.
> 
>   There are some issues with the proposed description of various designations
> of the Secure Hash Algorithm family of hash functions. In an effort to obtain
> what the author views as "consistency" he has introduced ambiguity and,
> in my opinion, incorrectness.
> 
>   There are 3 families of the Secure Hash Algorithm. There's the 1st family of
> SHA, (which is just designated SHA1) and there's the 2nd family of SHA (known
> as SHA2) which is SHA256 and SHA512, including truncated versions of each,
> SHA224 is a truncated version of SHA256 and SHA384 is a truncated version of
> SHA512. The 3rd family of SHA, SHA3 is a weird beast that we don't need to
> trouble  ourselves with since we're not using it.
> 
>   It is important to understand, though, that SHA1, SHA256, and SHA512 are
> different. They are not just truncated versions of the same function. And while
> SHA256 does actually produce 256-bits of digest output, SHA1 does not
> produce 1-bit of digest output, it produces 160-bits.  But we (802.11) do
> truncate the output of SHA family hash functions. For instance, we sometimes
> want only the first 128-bits of SHA1. Just to make things more complicated,
> we also use the HMAC construct with a SHA family algorithm.
> 
>   So how to deal with identifying the appropriate algorithm in the appropriate
> family of SHA, whether it is alone or as HMAC, and how to identify the particular
> output bit length that we are concerned with? 11-14/1104r1 does a poor job.
> Let me propose a better way:
> 
>   * the particular algorithm of the family is used without any hyphens- for
>      example, it's SHA256 not SHA-256, and it's SHA1 always.
> 
>   * when we want to truncate we add a hyphen and indicate the bit length we
>      want to use- for example, it's SHA256-128 (not sure why we'd do this but it's
>      an example) or SHA1-128.
> 
>   * if we don't add a hyphen and number indicating truncation then the entire
>      length of the algorithm output is used.
> 
>   * if we want to use the HMAC construct we prepend "HMAC-" to the SHA family
>      algorithm indicated, including any possible indication of truncation- for
>      example, HMAC-SHA256 or HMAC-SHA1-128.
> 
>   * if we don't prepend "HMAC-" then we are using the algorithm directly, and
>      not as a keyed hash function.
> 
>   While 11-14/1104r1 does this correct in some cases- it proposes to
> change "HMAC-SHA-256" to "HMAC-SHA256"-- it does it wrong in other
> cases- it proposes to change "SHA1" to "SHA-1".
> 
>   Also, if we adopt this more correct way of referring to these various
> incarnations of hashing we do not need to say something like
> "Truncate-128(HMAC-SHA1(xxx))" we just say HMAC-SHA1-128(xxx)".
> 
>   Minor grammatical gripe: there is no such algorithm called
> "HMAC-SHA1-64", or even "HMAC-SHA-1-64" so we should not be using
> the definite article when describing the use of SHA1 in an HMAC
> construct while truncating the output to 64 bits.
> 
>   Please modify 11-14/1104r1 to adopt this more correct terminology
> before it gets adopted.
> 
>   regards,
> 
>   Dan.
> 
> 
> 
> _______________________________________________________________________________
> 
> If you wish to be removed from this reflector, do not send your request to this reflector
> - it will have no effect.
> 
> Instead, go to http://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11 and then press the
> LEAVE button.
> 
> If there is no LEAVE button here, try http://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-
> 11-RO.
> 
> Further information can be found at: http://www.ieee802.org/11/Email_Subscribe.html
> _______________________________________________________________________________

_______________________________________________________________________________

If you wish to be removed from this reflector, do not send your request to this reflector - it will have no effect.

Instead, go to http://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11 and then press the LEAVE button.

If there is no LEAVE button here, try http://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-RO.

Further information can be found at: http://www.ieee802.org/11/Email_Subscribe.html
_______________________________________________________________________________