| --- This message came from the IEEE 802.11 Working Group Reflector ---
Hello Dan,
> There are 3 families of SHA:
> -- family 1: SHA1
> -- family 2: SHA224, SHA256, SHA384, and SHA512.
> -- family 3: SHA3
> These are the only names that we should be using.
Why are you proposing terminology which differs from that used in
the document which specifies these hashes, and which we refer to in
clause 2?
Because it makes for a very simple convention. Your submission is
unnecessarily confusing because it both includes the terminology of
the document to which we refer in clause 2 as well as terminology
that differs from the document we refer to in clause 2.
Dan.
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
--- This message came from the IEEE 802.11 Working Group Reflector ---
As doc 11-14/1104r1 has a lot of CIDs, it took a bit of reading to find where your concern area was in the document. (for
those reading along it is I believe CID 3432, 3426, 3427, 3429).
I am confused in reading 11-14/1104r1 on these CIDs because it does not seem consistent in the naming.
Is it supposed to be SHA1 or SHA-1 for example (as you note).
Yes, this is the confusion I am trying to fix. I think we should follow a consistent
convention in this regard.
So to help those of us that do not work with the security protocols daily, what is the appropriate names...can we safely say that it is supposed to be SHA1,
SHA256, SHA128.
There is no hash algorithm called "SHA128". There are 3 families of SHA:
-- family 2: SHA224, SHA256, SHA384, and SHA512.
These are the only names that we should be using.
Given the nominal names then I understand from your suggestion that the "-xxx" is then the amount to truncate to. (without the word truncate to prefix the
name).
That is correct. If you want 128 bits and you want to use SHA256 then you
The other parts that are noted as needing to be change you do not comment on.
Do we need to say "delete securely" in all cases or is "delete" sufficient.
does "destroy" imply "delete securely" and thus it is a valid term to use, and should be used when ever we mean "delete securely"
When getting rid of keys the implication is that they are irretrievably discarded.
When getting rid of finite state machines the implication is they are just freed up,
and returned to the pool of finite state machines to use when you need another.
For "state concerning the TSID/direction with in the MAC" (section 6.3.26.7.2)
-----------------------------------------------------------------------------
Jon Rosdahl Senior Standards Architect
hm:801-756-1496 CSR Technologies Inc.
cell:801-376-6435 10871 North 5750 West
office: 801-492-4023 Highland, UT 84003
A Job is only necessary to eat!
A Family is necessary to be happy!!
On Thu, Sep 18, 2014 at 1:14 AM, Dan Harkins <dharkins@xxxxxxxxxxxxxxxxx> wrote:
--- This message came from the IEEE 802.11 Working Group Reflector ---
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
* 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
_______________________________________________________________________________
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 _______________________________________________________________________________
_______________________________________________________________________________
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
_______________________________________________________________________________
|