Enhanced encryption using public keys

[shazow]

As discussed in https://github.com/odeke-em/drive/issues/543#issuecomment-250944242:

This would be an enhancement over the password-based encryption feature that is offered using --encryption-password today.

As @sselph mentioned in the thread, we can already do this using pipe-based encryption:

I think the piping is already supported using drive push -piped and drive pull -piped something like this as an example https://github.com/odeke-em/drive/wiki/%5BUse-Case%5D-Backup,-archive,-encode-and-push-directory.#above-encrypted-with-openssl-aes-256

Some improvements that we could offer:

• Automatic encrypting/decrypting of a subdirectory, perhaps by using somekind of .config file within the directory (pointing to a local pubkey is much safer than hardcoding a password string).
• Integration with the OS's keychain.
• Encryption for multiple recipient keys that can be used for sharing.
• Optionally keep the encrypted files as still encrypted while pulled on disk, only decrypt when they're needed.

There are also a few options to consider regarding what kind of PKI we could integrate:

• GPG keys would be the obvious one (perhaps using something like OpenGPG), could even include lookup on keybase.
• SSH keys which are more prevalent and support most of the same features, could even include lookup on github (fetch https://github.com/user.keys)
• drive could create its own keys automatically (probably not a great idea but might yield a somewhat more transparent experience).
• Double down on pipe-based operations and let the user bring whatever encryption commands they want by overriding some config file.

[odeke-em]

Awesome, thank you @shazow for filing this issue.

* Automatic encrypting/decrypting of a subdirectory, perhaps by using somekind of .config file within the directory (pointing to a local pubkey is much safer than hardcoding a password string).
* Integration with the OS's keychain.

Nice, I like your suggestions of reading from a .config file and also from the OS keychain.

* Optionally keep the encrypted files as still encrypted while pulled on disk, only decrypt when they're needed.

That'd be a good option that a user can specify in their configuration when pulling.

There are also a few options to consider regarding what kind of PKI we could integrate:

GPG keys would be the obvious one (perhaps using something like OpenGPG), could even include lookup on keybase.
SSH keys which are more prevalent and support most of the same features, could even include lookup on github (fetch https://github.com/user.keys)
drive could create its own keys automatically (probably not a great idea but might yield a somewhat more transparent experience).
Double down on pipe-based operations and let the user bring whatever encryption commands they want by overriding some config file.

Cool, yap Go has support for openpgp and ssh, so we could def have support for this.

In regards to integrating with the OS keychain, I got a similar suggestion sometime back here https://github.com/odeke-em/drive/issues/44#issuecomment-165678302.

Also in regards to dcrypto, in case we want to add features to it, we've gotta wait for Google OSS to give @sselph the greenlight for a seperate/lone package and from there we can make different encryption modules such as using OpenPGP and perhaps even start making custom ones in anticipation of moving dcrypto out of drive.

Otherwise, am not a crypto expert but these ideas sound great to me, and I am excited to see how things go and how people use these features.

[sselph]

I apologize. The delay for my part of this is all me. I've been lazy. From what I understand asymmetric crypto can operate by creating a symmetric key, encrypting that with the asymmetric crypto, and encrypting the bulk of the data similarly using symmetric crypto.

I initially avoided asymmetric crypto because backing up the private key seemed to be an issue. You have to back that up but you can't use drive because that is the key to encrypt. But for an environment where you have multiple systems backing up and you don't trust them to have access beyond their data, this seems like a nice solution.

This might be accomplished by doing something like func key(cipherText io.Reader, passKey []byte) keyMaterial []byte In the current code passKey would the the password and in asymmetric it would be the private key and it would return the symmetric key material. I can't make any promise on when I'll have time but if you get to it before me, maybe this will help.

[shazow]

FWIW I have a satisfactory flow using the pipe-based stuff right now so I'm not likely to work on this anytime soon, but I'd be happy to help review related PRs and give it a test drive.