On Monday, April 13, 2015 at 11:16:58 AM UTC-4, Jean-Pierre Münch wrote: > > .... (Well most people think that crypto has two tasks: securing > communication and securing files). >
This is actually the same problem. Packets on the network have a TTL (time-to-live); while data in storage have an indefinite or infinite TTL. That is, one is bounded and the other is unbounded. The shorter TTL for network packets means some optimizations can be taken when protecting them. For example, to ensure a network packet is not tampered only requires the signature to "last" or "endure" or "withstand attack" for a 2MSL time window because the network stack will think the packet is lost and a new one will be sent. Once the new one is sent, the time spent trying to forge the old packet will be wasted by the attacker. So you can use smaller MACs on the network. > > 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). Using an integrated encryption scheme reduces the problem to that of protecting the private key used in the scheme (assuming folks like Shoup, Abdalla, Bellare and Rogaway were right :). We know how to do that with a PBKDF. 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.
