Re: [TLS] Last Call: draft-ietf-tls-rfc4346-bis (The Transport
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [TLS] Last Call: draft-ietf-tls-rfc4346-bis (The Transport
Martin Rex wrote:
>
> Rob Williams wrote:
> >
> > Just as SHA-224 is to SHA-256,
> > SHA-384 is to SHA-512: truncated with different IV.
> >
> > I am looking forward to seeing SHA-384 removed from TLS 1.2.
>
> The difference between sha-256, sha-384 and sha-512 is much larger,
> and while the effort for calculating sha-384 and sha-512 might
> be the same, the resource consumption on keypair and digital signature
> generation for/with the DSA algorithm might make a hash with a
> size between 256 and 512 bit attractive.
I found an strange statement in FIPS-180-2 (with SHA-224 change notice)
http://csrc.nist.gov/publications/fips/fips180-2/fips180-2withchangenotice.pdf
This is from the SHA-224 change notice on page 73 of above document,
in a section titled "Truncation of the Hash Function Output":
Truncated hash output shall not be used in place of the full hash
output by standardized applications that reference this Standard,
e.g. digital signatures (FIPS 186-2) or keyed hash functions used
for message authentication (FIPS 198).
I'm just not sure what it exactly means:
Does it mean that neither SHA-224 nor SHA-384 should be used in
digital signatures? To me, this appears to be implied.
I don't see a reason why truncations that are given specific names
(such as SHA-224 and SHA-384) should not be considered truncations.
On the other hand, the statement about truncation of keyed hash
functions used for message authentication appears confused me.
IPsec does truncation on purpose, but this statement in FIPS-180-2+
appears to suggest this is a bad idea (and not FIPS-compliant...)
So does someone know what this all means (and can translate it
from FIPS into English language)?
-Martin
_______________________________________________
TLS mailing list
TLS at ietf.org
https://www.ietf.org/mailman/listinfo/tls
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.