On 01/04/2013 12:55 PM, Andrey Jivsov wrote:
On 01/03/2013 10:25 PM, ianG wrote:
Hence my earlier question - has anyone allocated the OpenPGP numbers for
Keccak as yet? The reason I asked is because I stumbled on the code
last week and thought what a fine idea it would be to at least prepare
the way.... Strawman?
SHA3-224 4 12
SHA3-256 5 13
SHA3-384 6 14
SHA3-512 7 15
Strawman? I'm not sure why there is a gap 4-7 in rfc4880. Are there
any spots already allocated?
One point I wanted bring up here based on the draft that I wrote last
year is that let's think for a moment about the usefulness of the SHA3-224.
I would like to see an argument for it. Algorithms like DSA/ECDSA are
capable to deal with hash truncation or padding. RSA mod has sufficient
space to always use SHA3-512.
The question is especially relevant if you familiarize yourself with the
Keccak. Keccak is basically a single hash algorithm which output is
truncated to 256, 384, 512, etc bits. The only difference between
SHA3-256 and SHA3-512, for example, is one integer used in the internal
You can always go with stronger security. Who are those people who would
not be OK with SHA3-256 but are happy with SHA3-224 ? Why can't they use
shorter public keys (to solve space concerns?) ?
I think I found some support to my suggestion in the latest SHA2 spec:
FIPS 180-4 "Secure Hash Standard (SHS)":
7. TRUNCATION OF A MESSAGE DIGEST
Some application may require a hash function with a message digest length
different than those
provided by the hash functions in this Standard. In such cases, a truncated
message digest may be
used, whereby a hash function with a larger message digest length is applied to
the data to be
hashed, and the resulting message digest is truncated by selecting an
appropriate number of the
leftmost bits. For guidelines on choosing the length of the truncated message
information about its security implications for the cryptographic application
that uses it, see SP
800-107 [SP 800-107].
In SHA2 SHA-224 is the SHA-256 with different IV. NIST was worrying
about some theoretical concerns with examples that show non-uniform
distribution of the SHA2 hash output (see
Given that there are no IVs in Keccak, the section 7 of FIPS 180-4
allows the truncation, and the truncation should be happening anyway in
practice when you use mismatched weaker DSA keys with stronger hashes,
benefits of SHA3-224 are even harder to see.
openpgp mailing list