Brian Gladman has taken a look at P1619.2/D7 and will see what he can do to create an EME-2 implementation to cross-check Shai/Hal's implementation. He also had some comments on the pseudo-code for EME-2 that I'm hoping we can change for draft 8.
---------- Forwarded message ----------
From:
Brian GladmanTo: Matt Ball
Matt Ball wrote:
> As you recall, EME-2 is not patent encumbered, and may become the
> encryption algorithm of choice for unauthenticated disk encryption, at
> least for those with stronger security requirements than what XTS offers.
Ok, I'll take another look at this. Can I assume that all the input and
output data blocks are in memory? EME-2 doesn't look like an
incremental mode to me but I want to make sure that this is correct
before I start to implement it. My assumption is that the algorithm
API will be something like:
eme2_en(de)crypt( const plaintext[], ciphertext[], len,
t_data[], t_len, key[], k_len)
(but not necessarily in this order). That is, it is an 'all in one go'
en(de)cryption. Is this correct?
> The group very much appreciates your help in the past, with XTS, CCM,
> and GCM, and other general implementation guidance!
I have now taken a detailed look at the P1619.2/D7 EME2 draft
specification and I have a few comments that I hope may be useful. For
better or worse here they are!
-------------------------------
1. The pseudo code is clearly very important and my own view here is
that it pays off to be absolutely consistent in setting this out on
paper. I think having conditionals and the associated code on separate
lines is very helpful and very important in setting out algorithm
structure and I would strongly prefer that this is ALWAYS done. That
is, putting code on the same lines as the associated conditionals (e.g.
lines such as 1, 16 and 17 on page 8 should be avoided.
For example, it is very easy to read lines 16 and 17 on page 8 as:
if len(P_n) < 16 then
PPP_n = ...
PPP_n = ...
because the indentation used here and the lack of seperate code lines
makes it very easy to miss the 'else' on line 17. I did exactly this
first time round and spent some time worrying about the two assignments
to PPP_n before I saw the 'else'. For this reason I really would
strongly prefer:
if len(P_n) < 16 then
PPP_n = ...
else
PPP_n = ...
To my mind absolute consistency in this greatly aids clarity and is a
big help in avoiding errors in interpretation of the specification.
2. I think that lines 37 and 38 on page 8 should be indented
3. I don't think the wraparound in the comment on line 8 is very elegant
and can easily be shortened: "// pad to 16 bytes with 0x80, 0x00, ..."
4. line 16 on p10 should have '0x80 0..0' in place of '10..0'
-------------------------------
best regards,
Brian