|
|
|
|
|
by brendyn
249 days ago
|
|
This project made me learn about and attempt to implement the SPAKE2 protocol and HKDF as an exercise.
It's quite fascinating. It lets you upgrade a short password to a long key, but requires trusting a server to rate limit attempts on brute-forcing that short password. It seems difficult to find a practical use case for it tho. Because it's only relevant when it is impractical to send a long key. But if you think for a second, lets say you are transferring from a desktop to a phone, you can show a QR code and scan in with your phones camera, thus achieving a secure handshake bypassing the need for SPAKE2 all together. Maybe it would defeat the simplicity of the tool, but if it also provided a long string of words for the key, a user could optionally send all the words instead of just the first few and get themselves a secure key without needing to trust the server. |
|
This isn't true. Particularly, if an attacker attempts to connect with the wrong password, this will be seen by the client, which then aborts the connection. So an attacker can only try one password. You can test this yourself:
So if you receive this error (potentially repeatedly), you learn that there is an attacker trying to guess passwords. You can then choose to increase code length or simply stop using that channel.The CLI also has an option to further mitigate MITM attacks with the `--verify` flag -- this shows to both clients a hash of the transcript, which can be verbally verified before proceeding with the transfer. This allows detecting an attack even if the attacker gets the password right on the first try (which has probability 1/65536).