1619: 9/27/2006 Meeting Minutes
Enclosed and online at: http://ieee-p1619.wetpaint.com/page/Meeting+Minutes
People on CC have at least one action item.
Fabio
P1619 Meeting - Sep 27th, 2006
------------------------------
8-10 AM Pacific Time
Attendance (conf. call)
l Charlie Martin, Sun
l Gideon Avida, Decru
l Jim Norton, Brocade
l Landon Noll, Neoscale
l Hal Finney, PGP
l Bob Griffen, RSA
l Doug Whiting, Hifn
l Shai Halevi, IBM
l Larry Hofer, McData
l Matt Ball, Quantum
l Laszlo Hars, Seagate
l Serge Plotkin, Stanford
l Glen Jaquette, IBM
l Eric Hibbard, Hitachi Data Systems
l Fabio Maino, Cisco
l David McGrew, Cisco
l Ciryl Guyot, Hitachi
Meeting Called to order at 8.20
AGENDA
------
* Approval of the agenda
* Accepting previous minutes
* IEEE patent slideset
* Modes: what are our goals in choosing our mode (Narrow Blocks)
* XEX
* XCB as narrow block mode
* Status of .2
* We do want F2F meeting in vegas?
* review of action Items
* next meeting
Landon moves to approve agenda, Gideon seconds. No opposition, agenda accepted.
Patent Slideset: Serge provided the Patent Slideset and the two slides were shown and discussed.
Landon moves to approve minutes, Serge seconds. No opposition, minutes accepted.
TECHNICAL DISCUSSION
====================
What are the goals of LRW?
--------------------------
Laszlo points out that all modes with a single AES pass are exposed to malleability of encrypted text. The advantage of narrow blocks seems to be easy implementability: narrow block is parallelizable (faster), and require smaller buffer (cheaper).
Doing two AES transform per block will solve current issues with LRW, but we're possibly looking for a solution that is more efficient then that and does a single passage.
XEX
---
XEX seems a nice compromise, that require an additional AES per sector (but 1 single AES per 16-byte block). To be fair in LRW there's an additional Galois per sector, that somewhat compares to the extra AES required by XEX.
XEX is an already existing mode, and this might be an advantage, given that if we define a new tweak to LRW we don't have the same amount of review available. This might move Laszlo proposal off the table, that is a variation of LRW, and has likey not received enough review.
What are the pro/cons of XEX?
1) Patent (Doug, Landon have done indipendent check on USPTO archive and there seems to be no patent covering XEX)
AI1 Shai: do a due diligence investigation on patents on XEX by talking to people that might have extra-USPTO info
2) security Implications
2.1 where you can produce a zero tweak value (2^-80 probability), but easy to detect if implementations wants to make the effort (it might not be worth to)
2.2 collisions at different location in different sectors (2^-40, even if there are keys where it'll happen).
Group seems to agree that this weaknesses are not major showstoppers.
Hal's observes that it would be best practice to use different keys, and not encrypt the first one as proposed now. Having two separate keys might help certification.
MOTION 1: Shai moves, and Landon seconds, to propose that "XEX will be the base of narrow block mode from now on".
A Charlie Martin, Sun
Y Gideon Avida, Decru
Y Jim Norton, Brocade
Y Landon Noll, Neoscale
Y Hal Finney, PGP
Y Doug Whiting, Hifn
Y Shai Halevi, IBM
A Larry Hofer, McData
Y Matt Ball, Quantum
Y Laszlo Hars, Seagate
Y Serge Plotkin, Stanford
Y Eric Hibbard, Hitachi Data Systems
Y Fabio Maino, Cisco
11 Yes, 0 NO, 2 Abstain: motion passes
AI2 Shai, post link to original paper on XEX (Asyacrypt 2004, gives XEX as building block for something else). Also need to check if there's proof of security
We need to discuss
- 1 key vs. 2 keys
- better understanding of weakness of 0 tweak and countermeasures
- recompute collision probability (and define which collisions we're interested to), Shai will work on this
1 key vs 2 keys
---------------
There seems to be a group of people in the group that thinks it would be better to have 2 keys. laszlo suggests that we sould still leave to the implementors the capability to derive one key from the other via an approved KDF (we shouldn't forbid to do it).
Laszlo suggests that a recent NSA meeting confirmed that there are export limitation (toward the "seven terrorist countries") for products that support 256-bit keys. This would suggest to leave open how keys are derived so that implementation that target those countries could derive keys from a single 128-bit seed and be compliant with export control regulations. Implementations that wants to be FIPS compliant will instead use larger seeds.
MOTION 2: Eric moves and Landon seconds for having the standard being either AES 128-bit or 256-bit, but not mixed with the appropriate key lengths"
No opposition no abstension, motion approved unanimously.
AI4 Serge, will change the standard to reflect 128/256 only motion and start changing the draft toward use of XEX instead of LRW.
We need to clarify how endianess is going to be handled, and it seems that we want to keep the way it is (it matches GCM that is probably not a compelling motivation to have it this way now that we've put aside LRW, but there seem not to be compelling reasons to change it either).
We will need to generate vectors, but now it might be too early.
Status of 1619.2
----------------
We should assume that .2 PAR is going to move forward, and the F2F meeting might be useful so we have a running start when the PAR is approved.
There are patents pending on both proposals on the table (EME, XCB), but given that this is not an interoperabiltiy standard like .0 this might be acceptable.
Another option that we could consider is the "Microsoft" mode. Doug will engage with Neil Ferguson(?) at microsoft to see if there's interest in bringing their proposal in.
AI7 all: read new XCB paper posted by McGrew and Reingold's paper posted by Shai that would apply to .2
AI8 Shai: re-send pointer to EME*
We haven't discussed how .2 modes can be optionaly extended to be an uathenticated encryption mode. Probably all .2 modes can be extended to do that and this can be discussed later.
Next Meeting
------------
AI9 Fabio: bring projector to F2F meeting, host conf call for .0
Matt will run the meeting in vegas, and Hal will be the editor in charge. Matt will like to find somebody else to chair, after the F2F.
next 1619.0 meeting (conf call): oct. 25th 9-12 pacific time
ACTION ITEMS
------------
AI1 Shai: to do a due diligence investigation on possible XEX patents by talking to people that might have direct info
AI2 Shai: provide link to original paper on XEX (Asyacrypt 2004, that gives XEX as building block for something else). Also need to check if there's proof of security (verified during the meeting: there is proof).
AI3 Shai: recompute collision probability for XEX
AI4 Serge: will change the standard to reflect 128/256 only motion and start changeing the draft toward use of XEX instead of LRW.
AI5 Serge and Shai: to work out "endianess issues" with current standard.
AI6 Jim: check which is the status of 1619 PAR (we might have to take action)
AI7 all: read new paper posted by McGrew and Reingold's paper posted by Shai that would apply to .2
AI8 Shai: re-send pointer to EME*
AI9 Fabio: bring projector to F2F meeting and arrange dial-in info for next .0