3 ms·
In the situation where you want to distribute a sensitive file without a trusted third party of any kind of key infrastructure in place, it's probably easier to
by xorcist 5y ago
In the situation where you want to distribute a sensitive file without a trusted third party of any kind of key infrastructure in place, it's probably easier to not bother with public key encryption. Which isn't too bad:
gpg -c secretfile.zip
Not sure it can get much easier? To decrypt:
gpg secretfile.zip.gpg
The point is that gpg is a tool that most people either already have or can install in a trusted way without downloading binaries from public web pages. Even more common to have installed is openssl:
openssl enc -aes256 -in secretfile.zip -out secretfile.zip.enc
openssl enc -d -aes256 -in secretfile.zip.enc -out secretfile.zip
Using these tools are perfectly secure for all practical attacks. The hard part is transmitting the password over a secure channel.
Public key encryption is even more useful, but requires a little more knowledge on the end user's part on key pairs, signing keys, publishing them etc. Should an end user just wish to transmit an encrypted file then symmetric encryption is easier to understand.
- tptacek 5y agoNever use the OpenSSL CLI to encrypt things. It creates unauthenticated ciphertext. It is anything but "perfectly secure". I don't think it's even the case that the OpenSSL project wants you to be using their code this way. It's just that Unix nerds (hey: it me) find things like this and adopt them, then write things about how they're "perfectly secure" in message board slapfights. It's a microcosm of the whole problem.
- xorcist 5y agoGiven the use case here, where someone wants to send a single file to someone else, with no pre-existing way to communicate securely, why would it matter? The only practical attacks would be on the passphrase itself (which they have no way of protecting). The fact that openssl accepts any passphrase is likely a bigger problem in practice than the lack of authentication.