Subject: Re: [openpgp] SHA3 algorithm ids.

From: ianG <[email-masked]>
Date: Sat, 08 Aug 2015 23:48:09 +0100

On 8/08/2015 23:35 pm, Phillip Hallam-Baker wrote:>

 > Discussion in CFRG was definitely
 > pointing to using 512 for the hash
 > required for the internal bit.
 > So if we choose one it should be 512 and
 > truncate where necessary in the UI part.

My "position" is only one hash, as many know well.  I prefer the 
longest, because they are computers and they don't have enough work to 
do.  However, I really don't care which one that much.  Note this by

http://www.metzdowd.com/pipermail/cryptography/2015-August/026238.html

(ftr, I don't follow it as yet)

iang

-------- Forwarded Message --------
Subject: Re: [Cryptography] SHA-3 FIPS-202: no SHAKE512 but SHAKE128; 
confusing SHAKE security
Date: Sat, 8 Aug 2015 22:52:30 +0200
From: Krisztián Pintér <[email-masked]>
To: [email-masked]

Michal Bozon (at Saturday, August 8, 2015, 12:59:07 PM):

> I was just wondering why the Keccak capacity for best extendable output
> hash function was not chosen to be at least as big as for the best fixed
> hash function.

the reason for the SHAKE's is exactly to have something reasonable,
unlike the SHA3 instances, which are not.

as it happened, the keccak team submitted stupid parameters, because
the NIST call for submissions was unclear, and they didn't want to be
disqualified. old hash functions often have larger security against
preimage attacks than collision attacks. NIST wanted something that
has at least the same security as the SHA2 variants. so the keccak
team had to replicate the 256 bit preimage and 128 collision for the
SHA-256 drop-in. that requires 512 bit capacity.

it is especially crazy for the SHA3-512 version, which now has 512 bit
preimage security, which is for all intents and purposes a nonsensical
securit level. this comes at a terrible performance hit.

it is completely useless. you want one general security against
everything. therefore NIST proposed to change the parametrization to
have 256bit output, 256 bit capacity for the SHA3-256. that would have
a general 128 bit security. this was in agreement with the keccak
team's intent. they actually discussed it, and agreed to it. this is
how you use keccak if you are a sane person.

here comes the crypto celebrity mob. schneier and the like were quick
to jump on the "NIST weakens crypto again" bandwagon. the entire thing
was shameful. to save its nonexistent reputation, NIST backed off, and
decided to standardize the original stupid parameters. congrats to
everyone involved, djb included!

so to save the day, they added the SHAKE instances as a workaround.
they are pretty much what SHA3 should have been. if you don't
understand how a sponge works, you are very much free to use the SHA3
instances. but if you want to do actual cryptography, you should
choose the SHAKE's.

_______________________________________________
The cryptography mailing list
[email-masked]
http://www.metzdowd.com/mailman/listinfo/cryptography

---

From: Christoph Anton Mitterer <[email-masked]>
Date: Sun, 09 Aug 2015 01:17:10 +0200

On Sat, 2015-08-08 at 23:48 +0100, ianG wrote:
> do.
If only one is to be assigned a number, it should be definitely the
longest.

Cheers,
Chris.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 8 Aug 2015 21:40:51 -0400

Thinking this through a bit further.

Why is anyone going to move from SHA-2 to SHA-3 ? Only reason I can think
of is a real or perceived weakness in SHA-2.

That being so, I can't see why they would go for a lower number of
bits/rounds.

For OpenPGP, I think the case for 512 only or 256 and 512 is pretty strong.

On Sat, Aug 8, 2015 at 7:17 PM, Christoph Anton Mitterer <
[email-masked]> wrote:

> openpgp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/openpgp
>
>

---

From: ianG <[email-masked]>
Date: Sun, 09 Aug 2015 04:22:23 +0100

On 9/08/2015 02:40 am, Phillip Hallam-Baker wrote:
> Why is anyone going to move from SHA-2 to SHA-3 ? Only reason I can
> think of is a real or perceived weakness in SHA-2.

For which they ran a competition :)  OK so now thinking has changed a bit.

"It's not pressing."

But it's always worth going for the most recent work;  the thinking is 
that SHA2 is not broken, which isn't the same as "it's state of the art."

SHA2 is cerca late 1990s design.  SHA3 is early 2010s.  I'm guessing 
that difference is worth another 15 years on the lifespan.

My other reason for going for SHA3 is that then we could potentially do 
the one-symmetric-suite on one code base, as one obligatory set.

However, that's only a thought balloon.  I've not looked at the 
complexity of SHA3 as hash or as AE algorithm (Keyak), in code.  It 
could be that the total coding complexity of say SHA2 + Chacha/Poly is 
less than the new set, even with the same base.

As a coder, this is 99% of the worry - how complicated is the code, or 
worse, as a manager, how much do I have to pay someone to implement it?

> That being so, I can't see why they would go for a lower number of

Only reason could be that discussion of SHAKEs versus SHAs, and some 
artifact that indicated that the longest rounds were actually 
inefficient and over the top.

> On Sat, Aug 8, 2015 at 7:17 PM, Christoph Anton Mitterer
> <[email-masked] <mailto:[email-masked]>> wrote:
>

---

From: Peter Gutmann <[email-masked]>
Date: Sun, 9 Aug 2015 12:44:58 +0000

Phillip Hallam-Baker <[email-masked]> writes:

>Why is anyone going to move from SHA-2 to SHA-3 ?

There isn't one.  As a result of the SHA-3 competition, we now know that SHA-2
is a lot stronger than people had originally thought (based on its SHA-1
heritage).  So the real winner of the SHA-3 competition was SHA-2.

>For OpenPGP, I think the case for 512 only or 256 and 512 is pretty strong.

The case for -256 only is that it's no worse than -512 but half the size.
This is particularly egregious for things like TLS and SSH, where you have to
use an idiotic-length 64-byte MAC if you want to protect a single-byte
keystroke.  It's less so for PGP and S/MIME where you're not sending a
constant stream of packets all unnecessarily bloated up by 64 bytes, but it's
still pointless.

Peter.

---

From: Christoph Anton Mitterer <[email-masked]>
Date: Sun, 09 Aug 2015 05:29:57 +0200

> think of is a real or perceived weakness in SHA-2.
Or for reasons of diversity (and the advantages thereof), which may
again make the non-512(/256) versions of SHA-3) interesting for some
people.

Cheers,
Chris.

---

From: ianG <[email-masked]>
Date: Mon, 10 Aug 2015 04:03:10 +0100

> From: Krisztián Pintér <[email-masked]>
...

> instances. but if you want to do actual cryptography, you should

Which I think can be interpreted as suggestion to use SHAKE256, instead 
of the SHA3-xxx.

A potential advantage of that is that the algorithm expands, so we don't 
need to specify truncation any more.

Just call it with a range of set params for 'd':

keyId:         32
fingerprint:   100, 150
hash:          256.

(by way of example) Is there any known advantage of the smaller lengths 
being subsets of the larger?

iang