Implement encryption and password exchange

[nils-werner]

In #5 @takluyver mentioned another tool, doing a similar thing to what we are doing. One thing wormhole has that we are missing is a sound and on-by-default crypto implementation.

There have been preparations to enable AES encrypted file transfers, it is based on both parties supplying the same password.

This issue is about collecting and juggling ideas for a user friendly encryption method. Ideally it should (checkmarks for what is in crypto branch already).

• [x] Use an industry standard key derivation scheme (PBKF2)
• [x] Use an industry standard encryption scheme (AES-CTR)
• [x] Use an industry standard HMAC (HMAC-SHA256)
• [x] Use key exchange to create a perfect forward secrecy key (SPAKE2)
• [x] Use an industry standard library
  • Caveat: pyca/cryptography does not allow streaming encryption of data. We have a custom-built implementation that does that. This implementation hasn't been audited but shown to pyca.
• [x] Enable encryption by default
  • The implementation currently asks for password, unless you provide one using -p (in which case it also ends up in history). Encryption can be turned off using a purposefully long switch --bypass-encryption.
  • If the the other party didn't enable encryption (legacy client or --bypass-encryption was set), an error is immedately raised as SPAKE2 fails.
  • If the two parties did not pick the same password, HMAC verification will fail after the transmission and an error message will be shown.

[takluyver]

The nice thing about PAKE, as I understand it, is forward secrecy. With a key derived by hashing a password, an eavesdropper can record the transmission, and keep trying different passwords to decrypt it, while the users are none the wiser. Using PBKDF to generate the key makes it slower to try a password, but it doesn't stop it.

With PAKE, an attacker would have to know the password in advance, and actively intercept messages to perform PAKE separately with each party. If they try it and get the password wrong, the users know that an attempt failed, so brute forcing should be impractical. And once the key is generated, the password doesn't need to be kept secret.

I'm not saying this scheme is a necessity, I just discovered it a few days ago so I'm excited about it. ;-)

[nils-werner]

I don't think PAKE makes it impossible to brute force the key or the password without anyone noticing. Can't an attacker simply record everything and then brute-force all parameters used in SPAKE2 (M, N, x, y and pw)?

As far as I understand PAKE makes it impossible to perform a dictionary attack on simple passwords without also having to brute force x and y (M and N are arbitrary but known). It is forward secret in the sense that eventually finding out the password does not reveal x and y and thus the key.

As soon as an attacker tries to intercept and replace x or y, the resulting key will mismatch and the receiving party will notice the attack in the form of garbled data.

[takluyver]

Sorry, I was being imprecise - I meant that the attacker can't readily try more than one possible password. I don't know the maths involved, but I assume that brute forcing the random data used in the algorithm is on a similar level of difficulty to brute forcing the resulting key that you use for symmetric encryption: i.e. it's possible in theory but the search space is impractically large.

[nils-werner]

I am also thinking about finding a way to implement TLS-SRP or TLS-PSK for the HTTP transfer, instead of inventing my own AES crypto.

Both TLS-flavors aren't supported in Python yet, but there are third party libraries that support TLS-SRP.

[nils-werner]

@takluyver I have added HMAC and SPAKE2 to this branch.

[takluyver]

👍 I don't have time at the moment to look into it in detail, but thanks!