Asymmetric Encryption

[Shadow53]

Should probably happen after #13.

Encryption using public/private key pairs. Probably PGP.

I'll need to do some investigation into the best ways to implement this in Rust.

[Shadow53]

The following are a list of questions I'd like to figure out for this:

1. Does asymmetric encryption get delegated to something like an external GPG/PGP program or a library used by hoard?
2. If using a library, do we use the user's GPG keys or create an entirely separate set of keys for hoard?
3. If using keys that hoard controls, do we use RSA or Elliptic Curve encryption? How many bits for each?
4. How is adding a new key handled?
5. Is encryption (specifically public key lists) configured per-pile, per-hoard, or globally?

Current (partial) answers:

1. I do not want to delegate to external programs as much as possible. I am okay doing so in the case of running a command to get a password for symmetric encryption, but not so much when it comes to passing (un)encrypted data to something user-configured.
2. I am leaning toward hoard-specific keypairs, as long as a single file can be encrypted with multiple public keys at once. This allows hoard some control over security, which some may argue is a bad thing. I think it is more likely good in that it prevents the user from making poor decisions (like a very weak number of bits for a key or reusing the key for a lot of things). The downside is making sure hoard follows best security practices, or at least better than most users would.
3. Based on research online, these are common RSA key lengths and the equivalent ECC length for the same level of security:
   • RSA 2048/ECC 224
   • RSA 4096/ECC 383 Further, a 512-bit ECC key is equivalent to a 15360-bit RSA key. It seems as though people are moving in the direction of ECC, with Curve25519 as a suggested curve. Apparently some people distrust the NIST-suggested curves as possibly attackable by the NSA, and Curve25519 is generally considered more secure regardless. So I think I would lean toward ECC/Curve25519.
4. This applies regardless of how keys are managed. My best initial guess at a process is something like:
   1. Generate new key
   2. Copy public key to all hoard computers, possibly by synchronizing with the hoards themselves.
   3. Modify configuration to make hoard(s) encrypted by new key as well.
   4. From a computer already using hoard, run a command to re-encrypt all of the encrypted files.
5. The current setup for configuration is per-pile, with fallback to per-hoard if the pile does not define any configuration. This seems appropriate.