Minutes for CFRG at interim-2016-cfrg-1
minutes-interim-2016-cfrg-1-1

Draft minutes from CFRG Interim Meeting, May 12th 2016, Eurocrypt 2016, Vienna

Where the minutes refer to slides X-Y.pdf, they can be found at
https://www.ietf.org/proceedings/interim/2016/05/12/cfrg/slides/X-Y.pdf
========================================================
      Introduction                                                             
                 (10min)
Presented by Kenny Paterson (Royal Holloway, co-chair of CFRG)
Slides: slides-interim-2016-cfrg-1-2.pdf
========================================================
<There were no questions>

========================================================
     AES-GCM-SIV                             (30min + 10min discussion)
Presented by Shay Gueron (Intel, University of Haifa)
Slides: slides-interim-2016-cfrg-1-7.pdf
Draft: https://tools.ietf.org/html/draft-irtf-cfrg-gcmsiv-01
========================================================

Atul Luykx (KU Leuven):
I tried to understand your security claim. You say the bound is better than
using random-IV GCM [in the nonce-respecting case]? Shay: In the case of long
messages (ie close to 2^32 blocks) our security bound is equivalent to AES-GCM.
However, for shorter messages, we can do better because we do not initialise
the counter bytes to zero. For example, if messages are less than 2^20 blocks,
the remaining 12 bits increase the length of the random IV, giving another 12
bits of security. Atul: Is this for Integrity or Privacy? Shay: Integrity,
although counter modes should just do this anyway.

Gaetan Leurent (INRIA): As the CAESAR competition is going on, why is this
being proposed along side? Why not use the CAESAR recommendation? Shay: Why
didn't we submit to CAESAR? We were a year too late! We are not trying to
compete with CAESAR. GCM is now ubiquitous, and here we show how to quickly
achieve stronger security using what we already have.

Philipp Jovanovic (EPFL): TLS1.3 ensures you never repeat a nonce. Good
implementations will always have a good nonce. So why do we need this? Shay:
Sure, but you can never assume that all implementations will be good. But yes,
we agree: if you're sure that nonces will never repeat, stick to GCM.

Kenny: This is MAC-then-Encrypt (MtE). How do you deal with the premature
release of plaintext during decryption? Again, it shouldn't happen, but there
will be bad implementations out there. Shay: If implemented correctly, then
there shouldn't be an issue. But if not, well then yes: our hope is that this
will never happen. Kenny: I think this needs to be made clear in the draft.
Shay: Yes, we will add a disclaimer or something.

Bertram Poettering (HGI, Ruhr University Bochum): You do key expansion for each
query, could you comment on that.  Perhaps you could you use a Tweakable Block
Cipher rather than a blockcipher to avoid this? Shay: Starting with the second
point, there are many ways to do this, I can't comment on which is the best
one.  As far as the cost of key expansion, its not too bad: about 15 cycles. In
our code we interleave this with the first blockcipher call to reduce the
overall cost. So, its not too much even for short messages, and irrelevant for
long messages.

Jean Paul Degabriele (Royal Holloway): On Smart Cards, the coprocessor can
sometimes do AES at similar costs to a simple xor. Can you comment on how AES
compares to Polynomial multiplication on these? Shay: On modern processors
there exists a polynomial multiplication instruction. In fact, for Intel
processors I can give you a rough comparison. [Returning to table of costs for
AES-GCM-SIV encryption and decryption, ] we can see it costs roughly 0.3 cycles
per byte for the multiplication. JP: So, roughly half the cost of an AES call?
Shay: More accurately, the polynomial multiplication has roughly twice the
throughput of the AES calls: you'd never do just one of these at a time.

Kenny: You only support 96-bit nonces? This is seems like a difference from the
AES-GCM specification. Shay: The inclusion of non-96-bit nonces has led to
problems (such as a correction in the NIST standard, and a bug in the security
proofs), and so 96-bit is already recommended.  What we do provides equivalent
security to GCM with a random 96 bit nonce. Kenny: Your hash key is
independent, rather than derived. How will this affect the API? Shay: AES-GCM
begins by deriving its hash key with a single AES call, at the cost of reducing
its range of counter values to a rather ugly range. We felt the API cost was
worth this. As for performance, this reduced call is a big help for short
messages, but irrelevant for long ones. Kenny: So what would be your API? Would
you take in an extra key? Shay: We take pointers to the Associated Data and
message, their lengths, a nonce and two keys. Kenny: So its not the same as for
GCM? Shay: Same but with another key, as does ChaCha+Poly1305 Kenny: Sure, but
this isn't a drop-in replacement then. Shay: Ok, so we could take in a single
longer key and split it inside the function. Kenny: Yes. These sorts of details
matter when defining a standard.

Bart Preneel (KU Leuven): What happens if I put the same key for both the hash
and encryption? Again, I'm thinking of an implementation error. Shay: Oh wow,
wonderful question. In the real world it would probably be fine, but one would
have to carefully check.

Bertram: So, what is the target security? You mentioned using AES-256, but only
a 128 polynomial hash. Shay: The Authentication key would be 128 bits (because
the authentication uses an information theoretic security proof), and
confidentiality key is 128 or 256 bits. Bertram: This limits the maximum
message length then? Shay: Yes, you are always limited by the number of roots
of the polynomial. Bertram: A longer hash key H would help with this. Shay:
Yes, but then a different field would be required.

========================================================
    Memory-Hard Functions                          (30min + 10min discussion)
Presented by: Joel Alwen (IST Austria)
Slides: slides-interim-2016-cfrg-1-1.pdf
Draft: --
========================================================
Kenny: Thanks for the talk. Do you think the CFRG should pause the
standardisation of Argon2i? Joel: Yes. I hesitate to say it, but yes. The
theory has really grown, and in the near future I think we can do much much
better, Kenny: Would you rerun the password-hashing competition? Joel: That
would be good. Our improved theory tells us there's a basic design error in
almost all the candidates, that we only really learnt about during or after the
competition. We should also have more practitioners involved.

Bart: There exists work from Wiener on the Total Cost of cryptanalytic attacks.
Have you considered the memory access costs, because often these are the
dominating factor? [Note to add, the paper in question is
DOI:10.1007/s00145-003-0213-5] Joel: For memory-bound functions (eg cache
misses), as I understand this is more to do with L1,L2 cache behaviour. I'm not
sure how relevant this would be for ASICs. In the dynamic memory access cases,
each look-up address is random, so you can't load it into a cache anyway, so we
will keep getting cache misses. Bart: Yes, with random queries, a cache would
worsen things.

Bart: At the end, you gave an example with a certain number of cores. How was
this chosen? Joel: We took our generic attack, and then targeted it for the
particular, realistic, parameter set.

========================================================
    XMSS                                            (10min + 10min discussion)
Presented by: Andreas Hulsing (TU Eindhoven)
Slides: slides-interim-2016-cfrg-1-3.pdf
Draft: https://www.ietf.org/id/draft-irtf-cfrg-xmss-hash-based-signatures-03.txt
========================================================
Phillipp: You said you've removed ChaCha from the construction because it
wasn't adequate for your masks. Have you considered replacing it with something
like Blake2? Andreas: No. We decided to instead remove that design element
completely, to keep the code size down. We were packaging an entire stream
cipher, and overall couldn't justify it.

Bertram: It seems there is still open and active research on hash-based
signatures at the moment. When would be the right time to standardise? Andreas:
Our last change was precisely towards standardising. XMSS itself was designed
and secure, but there were small costs in our security proof that meant the
appropriate versions didn't quite achieve the classic security targets (for
example our 128-bit candidate is a few bits short). So, we these modifications
from 2011 to the 2016 version were slightly increase the security bounds and
provide the target levels requested.

Bertram: Right, but I was thinking more in terms of Quantum Resistance?
Andreas: By the time we finish standardising this, it will have been about two
years (so about one year more I think). Then, to deploy we're looking at 5 to
10 years after that. It's not impossible we'll have a quantum computer by then,
so we need to start now. Because we're hash not lattice based our security
estimates are pretty sound, they're not changing around all over the place. As
for Encryption, we need solutions for that much sooner!

========================================================
    Any Other Business                                                  
    (<10min discussion)
========================================================
Kenny: Has this been useful? Would you like more of these in future, perhaps
co-located with Crypto or Eurocrypt again next year? Perhaps a quick show of
hands? <Majority of room raise hands> Kenny: And is anyone here against doing
this again? <No hands> Kenny: I guess you wouldn't be here if you thought that.
Kenny: Right, thank you all for coming, and have a safe journey.