Generic Hybrid Cipher - review + suggested updates

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 06:51:04 UTC