The closest advice to this in the article would be "use Signal" which has various issues of its own, unrelated to crypto: it has Signal Foundation as a SPOF and its ID mechanism is outright wonky, as phone numbers are IDs that are location bound, hard to manage multiple for a person, hard to manage multiple persons per ID, hard to roll over.

To me that seems to be a much bigger issue than "encrypting files for purposes that aren't {all regular purposes}".

0. (Only once) generate key pair id_rsa.pub.pem, id_rsa.pem

1. Generate random key

  openssl rand -base64 32 > key.bin

  openssl rsautl -encrypt -inkey id_rsa.pub.pem -pubin -in key.bin -out key.bin.enc

  openssl enc -aes-256-cbc -salt -in SECRET_FILE -out SECRET_FILE.enc -pass file:./key.bin

4. Decrypt key

  openssl rsautl -decrypt -inkey id_rsa.pem -in key.bin.enc -out key.bin 

  openssl enc -d -aes-256-cbc -in SECRET_FILE.enc -out SECRET_FILE -pass file:./key.bin

> The enc program does not support authenticated encryption modes like CCM and GCM, and will not support such modes in the future.

> For bulk encryption of data, whether using authenticated encryption modes or other modes, cms(1) is recommended, as it provides a standard data format and performs the needed key/iv/nonce management.

So don't use `openssl enc` to encrypt data.

`openssl cms` that is recommended above is S/MIME. Don't use S/MIME.

I can't wait for Filippo Valsorda's `age` to be done so I would have an answer to the question of "what should I use to encrypt a file?".

https://github.com/openssl/openssl/commit/c03ca3dd090c6eb739...

Without that, Bob could potentially receive any pair of (key,file), which would just decrypt into garbage data.

BTW, variations on that sequence appear all over the internet when searching for "openssl encrypt file with public key"...

People generally imagine that "encrypt this block of data" is a simple primitive that does everything you want it to. But naive encryption doesn't work like that. In the worst case, where you use ECB for the block cipher [1], you end up with the ECB penguin: https://blog.filippo.io/the-ecb-penguin/. Your secure crypto becomes a pretty trivial Caesar cipher, just on a larger alphabet. Other modes (such as the CBC mode you used) aren't so bad, but if you have some hint of the structure of the underlying data, you can start perturbing the ciphertext to manipulate the encrypted data.

The modern solution to that problem is "authenticated encryption," which means that you add in an additional guarantee that the ciphertext hasn't been tampered with. Even then, there is still room for doing things incorrectly (padding is a real pain!).

[1] This is so bad it shouldn't ever be an option in any tool.

And yet it's effectively the default.

Any idea when Fillipo's `age` will be done, or how to follow its development, other than the Google doc?

I am a little bit giving Filippo shit here but one concern I have about talking "age" up is that I'm at the same time talking the problem of encrypting a file up more than it needs to be, so that people have the impression we'd have to wait, like, 5 years to finally see something do what operating systems should have been doing themselves all this time.

It's getting better, but not close being business ready imo.

What I'm trying to say is, definitely also try Wire as it's similar but slightly better. I also haven't figured out how to verify someone over Keybase, so it's basically unauthenticated or opportunistic encryption. By comparison, Wire is considered secure enough by my company after doing a pentest on it, which says quite something (most customer's stuff we would run from if we were thinking of using it), and we use it as our main communication platform within the company.

Keybase has a relatively functional electron app on Mac and PC that I've used, and presumably also Linux.

> I also haven't figured out how to verify someone over Keybase

Isn't the goal with Keybase to see "this person is accountiknow on Github" and do verification that way?

Oh, then I am mistaken, thank you for correcting me and sorry for talking nonsense.

> Isn't the goal with Keybase to see "this person is accountiknow on Github" and do verification that way?

Yes, but that doesn't help me because my chat account is not cryptographically tied to my Keybase account.

So let's say I sign this statement that I am lucb1e on Github as well as on HN as well as on Keybase. You know and can verify that I have all these identities nicely tied to my PGP key. The person who controls those identities clearly also controls the PGP key. Now comes chat. You start a chat with me, and... magic? I don't know, but there is no verification code that I can use to check that I am really talking to lucb1e on Keybase; nothing that ties it to a PGP key; nothing that ties it to the HN user. My device might be encrypting the data for an entirely different key (whose private part is known either by Keybase or some other (W)MitM ((Wo)Man in the Middle)) and there is no way to check as far as I have been able to find.

But it's not end to end encryption if you can't verify it. Heck, even Whatsapp can do this. Let me cite Wikipedia on end to end encryption:

> Because no third parties can decipher the data being communicated or stored, for example, companies that use end-to-end encryption are unable to hand over texts of their customers' messages to the authorities.

So if Keybase got a court order to intercept your messages, they totally can. Just because Keybase sends you an encryption key, doesn't mean you got the one of your conversational partner: you'd have to do funky stuff (read and interpret the app's memory, or decompile and patch it to show fingerprints) to be able to verify that. That's unauthenticated encryption. It's like clicking past an https warning without ever seeing the warning.

This verification happens everytime you receive new information about your peer; if something has changed it must be new, otherwise a rollback or a change in history is detected. Once your client has made this automatic check you can get a list of the linked accounts and manually check if they are the correct ones; at this point your client can take a snapshot to prove even more strongly that it's the correct one. Those snapshots are shared, so if an account has multiple followers (the name of someone whl manually verified na account) it's that much harder to crack.

If that's not enough, any change to any account is stored in a Merkle tree whose root is thus monotonically incrementing, and tht tree can be retrieved at any time to verify nothing happens. And that root is stored in the Bitcoin blockchain so that any fork is easily traceable. You really have to go out of your way to distribute a compromised key to a client. In the meantime the encryption is end-to-end.

Here's an article about how they protect against malicious attacks against the server: https://keybase.io/docs/server_security

Here's how they store that Merkle root in the Bitcoin blockchain: https://keybase.io/docs/server_security/merkle_root_in_bitco...

I trust the app itself, since you can indeed verify that code, but the idea is that you don't have to trust the (Keybase-managed) server.

So what you'd verify is the encryption key. If we do a Diffie-Hellman key exchange and our shared key is abcxyz, then both phones should show that key. If an attack is going on, the key would have to be one known to the attacker rather than your conversational partner.

Simplified, DH is quite easy: you pick a base number and a modulus (public knowledge), both parties generate a random number (let's call it Rand), they do base^Rand or Rand^base (I forgot which way around), apply the modulus, send the number to the other person, and apply the same exponentiation with the number you received (and apply the modulus). The resulting number is only known to both parties, even though anyone could have observed the public parameters and the numbers that were sent to the other side. If a person wants to intercept this, they need to pick a Rand themselves and do the operations with that, replacing the number that gets sent over with their own. Because they can't know the Rand of either legitimate party, they will necessarily have a different result, and so the resulting encryption key is different. Both parties would (upon verifying their key out of band, for example by holding their phones next to each other in real life) see different encryption keys.

It's not about verifying the source code, but verifying that the server which I'm talking to is not malicious (for example if someone compromised it). That's the one property which makes end to end encryption "end to end" :)

Similar schemes can be made with different types of encryption (Diffie-Hellman is one of a few good methods), but with end to end encryption, the end devices are always the ones that verify each other.

Brings to mind the words of renowned Victorian lifehacker Jerome K. Jerome:

“I can't sit still and see another man slaving and working. I want to get up and superintend, and walk round with my hands in my pockets, and tell him what to do. It is my energetic nature. I can't help it.”