> > > 2. BouncyCastle and Crypto++ do interoperable on ECIES with the patch you > pointed me at. I recall a discussion about making the two compatible by > default. Perhaps we need to bring it to BC-devel list as well? >
There's acutally a third possibility I did not state: both are right. In this case, BC may use one standard, while Crypto++ may use another. (Here, the choices are at least Shoup's original paper, Shoup's ISO submission, and IEEE P1363). But I recall reading the ISO specification, and I could not determine if it was a 32-bit word or a 64-bit word. If there's confusion, then I would not bet against the ISO submission as the source of it. The Bouncy Castle folks may be helpful in nailing down the answers to unknowns. Jeff > On Apr 13, 2015, at 18:23, Jeffrey Walton <[email protected] <javascript:>> > wrote: > > >>> 1. We could add functions that do nearly the full job of >>> filenecryption, where a user just would have to provide a PBKDF(/ a >>> KDF), >>> an AEAD cipher (wrapped using AtE class? -> already in CryptoJPM :) ), >>> some >>> key, a filename and that's it. He would then use some filter approach to >>> transmit the data. The class would take care of salts, header data and >>> other stuff. I guess this would solve many problems for many users. >>> (except >>> for those ones needing asymmetric encryption) One could also design the >>> class to provide three different interfaces: "Chaining"(use some strong >>> keying material from some other password-based file), >>> "password-based"(needs salt, others wouldn't), "asymmetric >>> authentication"(user would provide asymmetric key and library would do >>> the >>> job) >>> 2. We could as well (instead?) just set up a nice wiki page that >>> explains the details and approaches to file encryption and let the users >>> do >>> the implementation work. >>> >>> I would probably look at existing primitives to do the job. >> >> For this particular problem, I think its an Integrated Encryption System, >> like Shoup's ECIES ( >> http://www.cryptopp.com/wiki/Elliptic_Curve_Integrated_Encryption_Scheme) >> or Abdalla, Bellare and Rogaway's DHIES (formerly named DHES and DHAES) (no >> wiki page yet). >> > Forgot to mention... Crypto++ and Bouncy castle are the only two > implementations I am aware. Shoup's NTL may provide it, but I have not > checked. > > Crypto++ is the only implementation I am aware for DHIES. > > Crypto++ and Bouncy Castle don't interoperate at the moment. See > http://www.cryptopp.com/wiki/Elliptic_Curve_Integrated_Encryption_Scheme#Bouncy_Castle. > > I read the relevant ISO standard a while ago, and I'm not sure which > implementation is correct and which one is not. > > -- -- 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.
