[P1619.2] ABL update
Thank you David,
I think the following list looks reasonable for the P1619.2 ABL4 mode.
A couple comments (relating to text below):
3. (non-multiple of 512 bytes) I believe we decided to make it a
requirement to support non-multiples of 16 bytes.
4. (Bit-order of Galois multiplier) We have developed two strong camps
within the SISWG: Those who prefer multipliers that are optimal for
either Big or Little Endian systems. The GCM spec is better for Big
Endian, and the current XTS (P1619) spec is better for Little Endian
systems. We will need to discuss this issue during the January 15th
meeting. I'll try to represent fairly the little-endian case for Doug
Whiting and Brian Gladman, who I don't believe will be there.
If possible, it would be good to have the work finished a week before
the meeting, on January 8th.
Happy holidays to you as well!
-Matt
-----Original Message-----
From: David McGrew
Sent: Thursday, December 21, 2006 10:25 AM
To: Matt Ball
Cc: rsnel
Subject: ABL update
Hi Matt,
I'd like to give you an update on ABL. Rik Snel has done an
implementation of ABL4 for use in linux filesystem encryption, as
Robert Elliot pointed out in the last meeting. Rik and I would like
to resolve a couple of minor open issues and get a stable
specification with test vectors. I'll be revising an earlier
submission to 1619 that specifies ABL and I'll send that to 1619.2
for consideration.
The open issues are:
1. Test cases need to be constructed and verified.
2. Need to review the security of ABL encryption of plaintexts
shorter than 32 bytes. (Shai Halevi has mentioned concerns which we
should review.) Might want to eliminate these plaintexts from
consideration.
3. The new specification should allow arbitrary block sizes, to
support 520 byte disk blocks and other applications. The original
EME and ABL submissions had only 512 byte plaintexts for simplicity,
but I think that the consensus is now that it is better to define
more flexible encryption methods. Please let me know if you think
otherwise.
4. There is an inconsistency in the two published ABL descriptions.
Need to resolve this. We will keep the goal of having the GHASH
function be identical to that of GCM.
5. Security analysis and review. I guess that I should write up a
more thorough analysis of the security and solicit review on it.
I figure that we can get matching test vectors and a resolved
specification (but not security analysis) in January. Is there a
date that we should target to ensure that the WG can review prior the
next meeting?
Please feel free to share this info with the WG if you'd like. I
just wanted to run it past you first.
Rik, please correct me if I've gotten some details wrong.
Best regards, and happy holidays,
David