I just saw that NIST is themselves using the /t notation for SHA-256 in SP 
800-208 even if that notation is not defined for SHA-256 in SP 180-4.

NISTs use of the /t notation in SP 180-4 and SP 800-208 is a bit confusing. The 
current situation is that /t as way to create variable-length digests means 
three different things for SHA-256, SHA-512, and SHAKE256. For SHA-256, /t just 
means simple truncation, which is weak, for SHA-512, /t means choosing function 
t in the set SHA-512/t of 510 fixed-length hash functions, and for SHAKE256, /t 
means setting d=t in SHAKE256(M,d).

As NIST alrady is using SHA-256/192 in SP 800-208 to mean just truncation it is 
maybe not a problem if IETF does the same...

Cheers,
John

From: Carsten Bormann <[email protected]>
Date: Friday, 1 July 2022 at 09:48
To: John Mattsson <[email protected]>
Cc: [email protected] <[email protected]>
Subject: Re: [COSE] SHA-512/256 and SHA-256/64
On 2022-07-01, at 09:32, John Mattsson 
<[email protected]> wrote:
>
> Hi,
>
> - The IANA COSE Algorithms Registry lists draft-ietf-cose-rfc8152bis-algs-12 
> as a reference for SHA-512/256 and SHA-256/64. This seems incorrect. 
> draft-ietf-cose-rfc8152bis-algs does not mention SHA-512/256 or SHA-256/64.

Right, hash algorithms are defined in draft-ietf-cose-hash-algs.

Section 3.2 defines a "SHA-256/64”, which is indeed confusingly named.
It is labeled as “filter only” (i.e., not cryprographically secure), for use 
e.g. as a keyid (i.e., where the relationship between the truncated hash and 
the actual data is verified in some other way, such as the presence of the 
latter in a list of authorized keys).

> - NIST SP 180-4 assigns a very specific meaning to the notation SHA-512/t as 
> the name for a t-bit hash function _based_ on SHA-512 whose output is 
> truncated to t bits. The initial hash value is a _function_ of t.

Indeed, we should not be calling the independently constructed "SHA-256 
truncated to 64 bits" “SHA-256/64”.

> SHA-512/256 is defined in NIST SP 180-4. As the initial hash value is a 
> function of t it is infeasible to find any relation between a SHA-512 hash 
> and a SHA-512/256 hash.
>
> SHA-256/64 is not defined in NIST SP 180-4. draft-ietf-cose-hash-algs 
> introduces a new meaning to the /t notation. In SHA-256/64 the initial hash 
> value is the same as in SHA-256, i.e., it is not a function of t. This means 
> that SHA-256/64 has different security properties than SHA-512/256. There is 
> a trivial relation between a SHA-256 hash and a SHA-256/64 hash.

Correct.

> I think this difference needs to be made clearer in 
> draft-ietf-cose-hash-algs. The security properties of the SHA-256/64 might 
> come as a surprise to a user expecting the same properties as SHA-512/512. 
> There is also a risk for incompatible implementations as people might 
> implement SHA-256/64 in a similar way as SHA-512/256.
>
> I think that the name SHA-256/64 should be changes as the “/64” in SHA-256/64 
> has different meaning than the “/256” in SHA-512/256.

+1.  SHA-256-t64 comes to mind, but maybe someone has a better idea.

> I do not think that the initial hash value in SHA-256/64 should be changed as 
> that would make it incompatible with any current implementation ofSHA-256.

I don’t think there is anything wrong with the truncated form for the 
application “filter only”.

Grüße, Carsten
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose

Reply via email to