Re: Generic Hybrid Cipher - review + suggested updates

Magnus

Thanks for obtaining review and sharing these comments.

These seem like clarifications that are useful and I would suggest  
updating the document accordingly.

If anyone is aware of any concern with these changes, can you please  
raise them on the list?

Is anyone in a position to help with the suggested example?

Does anyone have any additional comment on the draft?

regards, Frederick

Frederick Hirsch, Nokia
Chair XML Security WG



On Feb 24, 2010, at 1:50 AM, ext Magnus Nystrom wrote:

> Dear All,
>
> Here’s the result of Burt Kaliski’s review with my suggested changes  
> to the doc.
>
>
> ·        NIST has some specific requirements for KDF and OtherInfo –  
> may want to reflect these
> Suggest adding a reference to the Key Derivation text in XML Enc 1.1  
> where we deal with this.
>
> ·        RSAES-KEM:
>
> o   Step 1.  The random number r can be 0 (doesn’t affect the result  
> in practice, but it’s allowed within the security proof)
> Suggest clarifying in accordance with Burt’s recommendation.
>
> o   Step 3.  RSAEP operates on integers not octet strings, so should  
> be applied as c1 = RSAEP ((n,e), r), then C1 = I2OSP (c1, len(n)).
> Suggest doing this correction.
>
> ·        ECIES-KEM
>
> o   Notation.  EC points are usually capitalized.  The use of g /  
> h / G / H is possibly confusing.  I’d suggest:  P / Q / Qe / Z  
> (where Qe is the ephemeral public key), but perhaps check what other  
> EC documents use.
> Here, I tried to stay close to the notation in 18033-2, and so I  
> suggest no change.
>
> o   Step 1.  Editorial:  Reword consistent with step 1 of RSAES-KEM  
> (where r correctly can’t be 0 in this case)
> Suggest clarifying in accordance with Burt’s recommendation.
>
> o   Step 5.  “public key h” should be “public key H”
> Actually, it should be just “the elliptic curve point H”. Suggest  
> doing this change.
>
> ·        Section 6.1.  Consider adding a “real” example (these are  
> hard to find for KEM …)
> Yes, they are. While this would be good I am not able to do this  
> right now.
>
> ·        Decryption operations need to be added.
> Yes, this should be added (even if it is just the reverse of the  
> encapsulation).
> If the group agrees with the above I can take an action to update  
> the document.
> -- Magnus

Received on Wednesday, 24 February 2010 13:40:26 UTC