On Jul 15, 2015, at 20:19 , Jeffrey Walton <[email protected]> wrote: > I've been talking with David Hook from the Bouncy Castle project. We've been > looking at the interop issues.
Great! (About time… :) > (1) David suggests we forgo the ECIES_BC class patch because BC wants to > become more conforming on their side. They feel we could perpetuate interop > problems by providing the compatibility option. Excellent. I talked to David about this a long time ago, and he was busy with other things then… Glad it’s getting back on track. > (2) However, there may be another problem, and that is using an octet length > rather than a bit length. We are going through the standards now to see what > exactly is expected and called out. > > If Crypto++ should be using a bit length, then the following would be roughly > what we should do (from gfpcrypt.h): > > - PutWord(false, BIG_ENDIAN_ORDER, L+4, > word32(encodingParameters.size())); > + PutWord(false, BIG_ENDIAN_ORDER, L+4, word32(8 * > encodingParameters.size())); Details, details… :-) > QUESTIONS: > > For (1), is everyone OK with forgoing the patch? It will still be available > at the wiki for those who need it. It just won't be applied to the sources. On one condition: I think dropping this patch must be synchronized with BouncyCastle changing their format. Not before that. > For (2), we may need to make a change; and we will have more details shortly. > But how do we provide it? What do you mean by “how”? When we make this interop move (disruptive), it will be a part of the disruption. > Regarding (2), I've got a feeling either P1363 or ISO called out an octet > length, and the other organization called out a bit length. So we might be > able to abstract it with a P1363_COMPAT or ISO_COMPAT option (similar to the > former BC_COMPAT option). If both P1363 and ISO called out the bit length, > then we will be in a tougher spot since we can't establish the province > needed to continue using the octet length. But we have an obligation to > existing library users… Like you said, this has to be investigated. Too early to conjecture how we’d do this. One thing is clear: it can be a disruptive change, but it would have to be done regardless. > On the good side, Bouncy Castle has non-profit status partly because of their > work for educational purposes. They are interested in collaborating in > providing implementations of Krawczyk's HMQV and Sarr, Elbaz–Vincent and > Bajard FHMQV. Excellent news! -- -- You received this message because you are subscribed to the "Crypto++ Users" Google Group. To unsubscribe, send an email to [email protected]. More information about Crypto++ and this group is available at http://www.cryptopp.com. --- You received this message because you are subscribed to the Google Groups "Crypto++ Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
