Re: [openpgp] SHA3 algorithm ids.

[Andrey Jivsov <[e-mail]>]

On 08/08/2015 02:21 AM, Werner Koch wrote:
> Hi!
>
> Now that an official SHA3 specs has been published I would like to see
> algorithm ids assigned.  Although it is some time until we can publish
> rfc-4880bis, it would be useful to agree on the algorithm ids now.
> This would be helpful for experimental implementations.  Thus what about
> this new table with the SHA2 drop in replacements:
>
>        ID           Algorithm                             Text Name
>        --           ---------                             ---------
>        1          - MD5 [HAC]                             "MD5"
>        2          - SHA-1 [FIPS180]                       "SHA1"
>        3          - RIPE-MD/160 [HAC]                     "RIPEMD160"
>        4          - Reserved
>        5          - Reserved
>        6          - Reserved
>        7          - Reserved
>        8          - SHA256 [FIPS180]                      "SHA256"
>        9          - SHA384 [FIPS180]                      "SHA384"
>        10         - SHA512 [FIPS180]                      "SHA512"
>        11         - SHA224 [FIPS180]                      "SHA224"
>        12         - SHA3-224 [FIPS202]                    "SHA3-224"
>        13         - SHA3-256 [FIPS202]                    "SHA3-256"
>        14         - SHA3-384 [FIPS202]                    "SHA3-384"
>        15         - SHA3-512 [FIPS202]                    "SHA3-512"
>        100 to 110 - Private/Experimental algorithm
>
> Note that I ordered SHA3-224 first; when we did SHA2 we forgot about 224
> and thus it ended up out of order.
>
> I am not sure about the text name.  Is a dash okay (cf. armor header)?
>
> The OIDS are:
>
>     The hexadecimal representations for the
>     currently defined hash algorithms are as follows:
>
>       [...]
>
>       - SHA3-224:   0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x07
>       - SHA3-256:   0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x08
>       - SHA3-384:   0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x09
>       - SHA3-512:   0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x0a
>
>     The ASN.1 Object Identifiers (OIDs) are as follows:
>
>       [...]
>
>       - SHA3-224:   2.16.840.1.101.3.4.2.7
>       - SHA3-256:   2.16.840.1.101.3.4.2.8
>       - SHA3-384:   2.16.840.1.101.3.4.2.9
>       - SHA3-512:   2.16.840.1.101.3.4.2.10
>
>     The full hash prefixes for these are as follows:
>
>         [...]
>
>         SHA3-224:   0x30, 0x51, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86,
>                     0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x07, 0x05,
>                     0x00, 0x04, 0x40
>
>         SHA3-256:   0x30, 0x51, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86,
>                     0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x07, 0x05,
>                     0x00, 0x04, 0x40
>
>         SHA3-384:   0x30, 0x51, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86,
>                     0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x07, 0x05,
>                     0x00, 0x04, 0x40
>
>         SHA3-512:   0x30, 0x51, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86,
>                     0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x07, 0x05,
>                     0x00, 0x04, 0x40
>

Dear OpenPGP list members.

NIST has finally produced the SHA-3 spec, FIPS 202 
http://dx.doi.org/10.6028/NIST.FIPS.202. It is difficult to believe that 
the last discussion on SHA3 ID that I recall was in 2012 in 
https://lists.gnupg.org/pipermail/gnupg-devel/2012-December/027173.html .

I have updated and posted the ID with details that were discussed so far 
in the thread, here:

>
> A new version of I-D, draft-jivsov-openpgp-sha3-00.txt
> has been successfully submitted by Andrey Jivsov and posted to the
> IETF repository.
>
> Name:		draft-jivsov-openpgp-sha3
> Revision:	00
> Title:		The use of Secure Hash Algorithm 3 in OpenPGP
> Document date:	2015-08-19
> Group:		Individual Submission
> Pages:		7
> URL:            https://www.ietf.org/internet-drafts/draft-jivsov-openpgp-sha3-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-jivsov-openpgp-sha3/
> Htmlized:       https://tools.ietf.org/html/draft-jivsov-openpgp-sha3-00
>
>
> Abstract:
>    This document presents the necessary information to implement the
>    SHA-3 hash algorithm with the OpenPGP format.

Your comments are very welcome.

The idea of the spec is to keep technical details written down, such as 
IDs, ASN.1 DER prefixes, and the exact set/subset of SHA3 algorithms. I 
also think that a few words on interoperability concerns will be helpful.

Second,  and this took the most time, I wrote a single-file C code SHA3 
implementation that should assist with the implementation of SHA3 in 
OpenPGP applications, testing, troubleshooting, and interoperability. 
One feature of this sample is that it follows Init/Update/Finalize (IUF) 
API, which is how OpenPGP uses the message digest. The project is called 
SHA3IUF.

The code is here:

    https://github.com/brainhub/SHA3IUF

To run the sample code:

    $ wget https://raw.githubusercontent.com/brainhub/SHA3IUF/master/sha3.c
    $ gcc -Wall sha3.c -o _ && ./_
    SHA3-256, SHA3-384, SHA3-512 tests passed OK

I hope that a spec and the SHA3IUF sample code will help avoid mistakes, 
such as the one in the above quoted message. All DER prefixes except for 
the SHA3-512 are incorrect. Please use the DER prefixes from the spec.

SHA3 is not the same as Keccak, and the two produce different hash 
values. SHA3IUF helps with other issues, such as how to define the IUF 
state, and how difficult is it to add each SHA3-X algorithm.

Presently the spec excludes SHA3-224, as seems to be a consensus on this 
list.

Please note that presently DSA or ECDSA truncate hashes. A digital 
signature with a DSA key with FIPS 186-3 L=2048 N=224 and a SHA3-256 
hash algorithm has security properties similar to the case when SHA3-224 
hash was used instead. In other words, an application already has a tool 
to use a 224-bit hash via an appropriate DSA/ECDSA key.

RSA signatures have plenty of "free" space for the hash, therefore, it's 
not clear why SHA3-224 would be needed.

Thank you.