[openpgp] SHA3 is standardised as FIPS 202

ianG <iang@iang.org> Thu, 06 August 2015 18:53 UTC

Message-ID: <55C3AD0C.1060605@iang.org>
Date: Thu, 06 Aug 2015 19:53:00 +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
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/openpgp/mctOUdSjx0ijmzazqHpJi8KTos4>
Subject: [openpgp] SHA3 is standardised as FIPS 202
Precedence: list

It looks like SHA3 is now out as FIPS 202.

http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.202.pdf

I think.



Now, SHA3 or Keccak as it was better known, is built using the sponge 
construction idea.  Included in the design are a couple of XOFs or 
extendable output functions called SHAKE128 and SHAKE256.

I think these XOFs can be used as encryption algorithms in XOR-stream mode.

Which brings us to a point worth thinking about.  For a future OpenPGP 
release, we could use SHA3 for both the hash algorithm and the stream 
cipher.  Etc.  (There are supposed to be modes that you can do for 
authenticated encryption as well.)

Which then gives us the opportunity to have ONE algorithm provide a much 
larger space of our needs.  If we the SHA3 engine were to form the basis 
of all the symmetric needs, then this would provide for a minimal 
implementation with less code and less complexity.

E.g., we could simply set the Mandatory to Implement (MTI) algorthm to 
the SHA3 family.



Worthwhile?  I'm not saying this will work - I'm just holding out the 
thought experiment that we could substantially ease the burden on 
developers and implementers if we could simplify the set down to one 
common family.



iang

[openpgp] SHA3 is standardised as FIPS 202 ianG
Re: [openpgp] SHA3 is standardised as FIPS 202 Hanno Böck