'''On 14.01.2013 an informal discussion on choosing new authentication and key generation algorithms for mobiles''' (moderated by Steve Babbage)

From ESC2013
Revision as of 15:08, 22 January 2013 by Guest (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

On 14.01.2013 an informal discussion on choosing new authentication and key generation algorithms for mobiles (moderated by Steve Babbage)

The 3GPP family of mobile phone standards already includes one “off the shelf” set of authentication and key generation algorithms, called Milenage (which is built as a construction using Rijndael). We want a second one, and are considering basing it on either SHA-2 or Keccak. Once specified, this algorithm set will be in place for 20 years or more with no chance to change it.

Main questions:

Should we choose SHA-2 or Keccak? (Various arguments to consider)

If Keccak, what version, and what other advice can you give about the construction?

If SHA-2, does it need to be HMAC?

If Keccak, should we wait for the NIST standards?

SHA-2 vs Keccak

Stefan: it's a happy choice - both are good

Has SHA-2 been more studied than Keccak? Dan thought it was probably quite even (but that was just an impression, no data to support it)

Efficiency: Christian R pointed out that SHA-512 requires about the same amount of memory to implement as Keccak-1600

Clear feeling that Keccak was easier to protect against side channel attacks than SHA-2 (and side channel attacks do matter for smart cards)

Florian pointed out that best known attacks seem much closer to the full number of rounds of SHA-2 (even if still a long way short) than to the full number of rounds of Keccak

Straw poll showed a fairly strong preference for Keccak (even if we discount the votes of the Keccak designers)

How to use Keccak

Dmitry and others: use "domain separation"-type inputs to separate different sub-algorithms and different key size

Antoine: could give the option for operators to choose a variant algorithm by running extra sponge rounds before extracting output. In principle this would allow a strengthened version to be introduced easily if ever needed

Joan and Gilles (offline, afterwards): security claims / proofs for keyed sponge functions don't require capacity = twice the required security level (as you would need for a hash function); rather, capacity should exceed required security level X maximum number of queries

Should we prefer the 1600-bit version (likely to be more "industry standard", more trusted) or the 800-bit version (more efficient)?

How to use SHA-2

Do we need HMAC for a keyed mode, or is a simpler construction OK for our fixed length input use case?

Stefan and others: simpler secret prefix construction is OK

Keyed sponge function security proof - how well reviewed / trusted is this?

No suggestion that many people had read it

Not considered much during SHA-3 competition

Joan and Gilles mentioned afterwards that there's a simpler security proof (of a different assertion) in another paper of theirs from CHES 2010

Official NIST SHA-3 standards

If we do use Keccak, should we wait for the NIST SHA-3 standard?

Could be September before we have these (Stefan: NIST definitely want to do it by September)

NIST may standardise the Keccak permutation as well as the whole SHA-3

And may possibly standardise the 800-bit-state version as well as the 1600-bit state-version