4

ECIES is part of both ISO/IEC and IEEE. There's a interop bug between Crypto++'s ECIES and Bouncy Castle's ECIES. I know where the bug lies, and I've been trying to determine who is "right" (for some definition of "right").

The bug is simply the length of the label L. In Crypto++, the length of the label is encoded in an 8-byte word, while Bouncy Castle uses a 4-byte word for the label. Obviously, the mac.Update(L, 4) and mac.Update(L, 8) will produce different results.

The proposal is sufficiently vague in this particular area, so its easy to understand why the interop bug exists. I've searched Shoup's site, but I can't find a reference implementation.

IEEE is hidden behind a paywall, so its hard to say what they consider standard. It could well be that both are "right" because they are using slightly different standards. (I know Shoup points out some differences in his 2.1 draft).

Where can I find a reference implementation of Shoup's ECIES (preferably from Victor Shoup himself)?


Related: the reason I'm interested in this information is I would like to work on an implementation in OpenSSL. So the implementation needs to be "right", and it needs to interoperate with the Crypto++ and Bouncy Castle implementations (even if that means a flag to do the "not-right" thing on occassion).

  • Added the tag for you. – cpast Apr 14 '15 at 21:22
  • @cpast - perfect, thank you very much. I see you get around :) – jww Apr 14 '15 at 21:23
  • maybe ask this at cryptography stackexchange? – SEJPM Apr 14 '15 at 21:29
  • @SOJPM - yeah, I was kind of thinking about that before asking here. Crypto.SE tends to like the theoretical stuff and this is more practical because its implementation oriented. But if there's a consensus, then I'd be happy to flag it for migration. – jww Apr 14 '15 at 21:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.