Re: [openpgp] SHA3 algorithm ids.

ianG <iang@iang.org> Sat, 08 August 2015 22:47 UTC

Return-Path: <iang@iang.org>
X-Original-To: openpgp@ietfa.amsl.com
Delivered-To: openpgp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF5121B2C65 for <openpgp@ietfa.amsl.com>; Sat, 8 Aug 2015 15:47:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LaQlpmYFvAdc for <openpgp@ietfa.amsl.com>; Sat, 8 Aug 2015 15:47:55 -0700 (PDT)
Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 124B81B2C64 for <openpgp@ietf.org>; Sat, 8 Aug 2015 15:47:55 -0700 (PDT)
Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id 15D186D72C; Sat, 8 Aug 2015 18:47:53 -0400 (EDT)
Message-ID: <55C68729.3050603@iang.org>
Date: Sat, 08 Aug 2015 23:48:09 +0100
From: ianG <iang@iang.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: openpgp@ietf.org
References: <835832901.20150808225230@gmail.com>
In-Reply-To: <835832901.20150808225230@gmail.com>
X-Forwarded-Message-Id: <835832901.20150808225230@gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/openpgp/q2hU54VYDHIjT8ZV-CvzizOF_tE>
Subject: Re: [openpgp] SHA3 algorithm ids.
X-BeenThere: openpgp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <openpgp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/openpgp>, <mailto:openpgp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/openpgp/>
List-Post: <mailto:openpgp@ietf.org>
List-Help: <mailto:openpgp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/openpgp>, <mailto:openpgp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 08 Aug 2015 22:47:57 -0000

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 <pinterkr@gmail.com>
To: cryptography@metzdowd.com


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
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography