Am 14.04.2015 um 14:06 schrieb Mobile Mouse:
> 1. I recommend staying with ECIES rather than going to DHIES. 
>
> 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?

Well, I did include the patch, Jeffrey pointed to, in CryptoJPM, but
agreeing on a common solution is of course the best solution.

Concerning equivalence of network communication and data storage:
It's close, payload / record protection can be the same, however ECDH
can't be applied for files, so, to some degree they are different tasks,
as the possible / optimal solutions differ.

To come back to my original point:
I don't think I'd ever use ECIES for file encryption. It's great for
asymmetric encryption and for the use case I defined (asymmetric
encryption) it'd be the best solution for header protection, however my
point was to assist new users in file encryption (by easing up the work
with new primitives and/or new guides on the wiki).
The question now would be: Does this falls apart the aim of Crypto++ to
be a crypto library?

BR

JPM
>
> Sent from my iPad
>
> On Apr 13, 2015, at 18:23, Jeffrey Walton <[email protected]
> <mailto:[email protected]>> 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
>>     
>> <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.
>>
>> Jeff
>> -- 
>> -- 
>> You received this message because you are subscribed to the "Crypto++
>> Users" Google Group.
>> To unsubscribe, send an email to
>> [email protected]
>> <mailto:[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]
>> <mailto:[email protected]>.
>> For more options, visit https://groups.google.com/d/optout.
> -- 
> -- 
> 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]
> <mailto:[email protected]>.
> For more options, visit https://groups.google.com/d/optout.

-- 
-- 
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.

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to