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