> 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. >
Well, I think you need to make a distinction between the DH problem (discrete logs in a finite field) versus DH exchange (key agreement based on the DH problem). DH and ECDH are key agreement schemes and a shared secret drops out between the parties involved (there's actually multiparty DH schemes, where 3 or more can participate). For both data in storage and data in motion, you don't need an agreement scheme. For data in storage, its self evident because there's only one party. For data in motion, you can send the protected data over an insecure transport (plain socket versus SSL-enabled socket) because the confidentiality and authenticity was applied at a higher level. You can even attach it to an email message like S/MIME. Now, you still have a problem with data in motion, and that's the key distribution problem. That is, how does A get B's public key. The problem is almost always present, even with IPSec/SSL/TLS/SSH/DHIES/ECIES/... It's a problem without a [scalable] solution. If you want to read more, you should check out Peter Gutmann's Engineering Security (https://www.cs.auckland.ac.nz/~pgut001/pubs/book.pdf). Related to the key distribution problem, check out "Trust on First Use" (TOFU) schemes. TOFU schemes are very popular, and they are used in protocols like SSH via *StrictHostKeyChecking.* > 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, > Its a hybrid scheme that combines public/private key with bulk encryption. Its probably easiest to think of it as: key a block or stream cipher with *random* key, encrypt data. Key a MAC with *random* key, authenticate encrypted data. Encrypt the random keys under the public/private keypair. Package { Encrypted Random Keys, Cipher Text, Authentication Tag } together. (There's a lot more to it, but its probably easiest to digest it like above) > 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). > I'm not sure that's good advice for those who are new to data security. As a matter of fact, I routinely recommend it. By using an IES, the developer does not need to combine primitives like deterministic random number generators, public/private key cryptography, block and stream ciphers, key derivation functions, mask functions, message authentication codes and signatures. That's a huge benefit. It ensures the developer does not make a mistake or miss a step, like using an easily predictable key (versus a random key), using a hard coded IV (like a string of 0's) or forgetting to apply an authentication tag (versus MAC'ing or signing). The question now would be: Does this falls apart the aim of Crypto++ to be > a crypto library? > I think one of Wei Dai's primary goals for Crypto++ is a versatile crypto-toolkit with well known and lesser known schemes. A secondary goal is to provide a framework for new schemes and algorithms as they become available. How the schemes and algorithms are used is completely up to the user. Some folks can perform research (like trying and break ECIES), while others can use it for data security (like encrypting data with AES). Jeff -- -- 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.
