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

**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