4 ms·

You only get one shot at guessing it per transmission attempt.

gojomo 5y ago
Indeed, and as the docs (https://magic-wormhole.readthedocs.io/en/latest/welcome.html#design https://magic-wormhole.readthedocs.io/en/latest/welcome.html...) explain, you'd likely notice an active attack, and the paranoid can choose any arbitrarily-longer code: > PAKE effectively trades off interaction against offline attacks. The only way for a network attacker to learn the shared key is to perform a man-in-the-middle attack during the initial connection attempt, and to correctly guess the code being used by both sides. Their chance of doing this is inversely proportional to the entropy of the wormhole code. The default is to use a 16-bit code (use –code-length= to change this), so for each use of the tool, an attacker gets a 1-in-65536 chance of success. As such, users can expect to see many error messages before the attacker has a reasonable chance of success. (It does strike me, however, that if a 'mailbox server' becomes heavily used, with many pending-but-incompleted wormholes, then an attacker making random guesses might manage to receive someone's random file, instead of the real intended-recipient. Perhaps the sending-side should optionally require an interactive sender-ack, after showing for confirmation a receiver-generated unique secret? In any case: using a longer code, and/or using a private mailbox, could each help eradicate such risks.)
- psanford 5y ago
  You also don't have to use words from the default dictionary. You can specify your own code.
- callahad 5y ago
  > Perhaps the sending-side should optionally require an interactive sender-ack Check out the `--verify` flag for `wormhole send` and `wormhole receive`
IanCal 5y ago
Ok, I'm definitely not understanding this then. This is my understanding so far: You are sending the file runs wormhole send myfile I, the attacker run wormhole receive __guess_code__ If my code is right, I get the file. If not, you cannot know, surely? There's no identification here other than the code. I can guess repeatedly as many times as I want. If lots of people are using the same server, the chance I start getting someones files is quite high. ~~In addition, with generating the code, either the sender has a way of checking if codes are in use (and so the attacker can more easily find current open valid codes) or there is the chance of a clash.~~ Edit - looking at the code I don't think this side is an issue. It'll ask for a connection then generate a code for that connection I think. So - how do I only get one guess?
- lotharrr 5y ago
  Good question! The code is broken up into two parts: a number, and some words. The number is like a mailbox: you put messages into it, the person you're intending to talk to puts messages into it, (maybe an attacker puts messages into it), everybody can read the messages there. The words are secret. There's a special cryptographic protocol named PAKE ("Password Authenticated Key Exchange") that tells you what messages to put into the mailbox. The protocol has a lock-step part in the middle, where you don't generate your second message until you've seen the other person's first message (and vice versa). When the protocol is done, if the two people used the same secret words, they'll wind up with the same secret encryption key, and nobody else will know the key. If they used different words, they'll wind up with random strings. The file transfer uses the shared key to encrypt the bulk data. Your client will generate a random wormhole code (random words plus server-allocated mailbox number) and run the protocol exactly once. It will generate and send its first message, wait for the partner's first message, then generate and send the second message, wait for the partner's second message, compute the shared key, do a test to see if it matches the other side (send a hash of the key), negotiate a direct connection if possible, then encrypt and transmit the file data. If an attacker is trying to guess your code, their only option is to pretend to be your intended recipient and follow the same protocol. They watch the server and learn the mailbox number: that part isn't secret. But then, to send their first message, they have to commit to some particular secret words. And they don't get to find out if they were right or not until they see your second message, by which point your client knows that this "one shot" has been used up, and it's either correct (the key-verification hash matches) or it's not (or the attacker disconnects and runs away, in the hopes of getting you to blame a flaky network instead of suspecting an attacker). If it fails, the client tells you that fact and quits, and you have to re-run the program (getting a brand new random wormhole code) to try again. Which means the attacker is back to square one: they know their first guess was wrong, but now the code is different, so their second guess has exactly the same chances of being right as the first guess.
  - IanCal 5y ago
    Oh I see, thank you! I'd missed that it was an address/password combo. Thanks for the clear explanation.

Indeed, and as the docs (https://magic-wormhole.readthedocs.io/en/latest/welcome.html#design https://magic-wormhole.readthedocs.io/en/latest/welcome.html...) explain, you'd likely notice an active attack, and the paranoid can choose any arbitrarily-longer code: > PAKE effectively trades off interaction against offline attacks. The only way for a network attacker to learn the shared key is to perform a man-in-the-middle attack during the initial connection attempt, and to correctly guess the code being used by both sides. Their chance of doing this is inversely proportional to the entropy of the wormhole code. The default is to use a 16-bit code (use –code-length= to change this), so for each use of the tool, an attacker gets a 1-in-65536 chance of success. As such, users can expect to see many error messages before the attacker has a reasonable chance of success. (It does strike me, however, that if a 'mailbox server' becomes heavily used, with many pending-but-incompleted wormholes, then an attacker making random guesses might manage to receive someone's random file, instead of the real intended-recipient. Perhaps the sending-side should optionally require an interactive sender-ack, after showing for confirmation a receiver-generated unique secret? In any case: using a longer code, and/or using a private mailbox, could each help eradicate such risks.)

psanford 5y ago
You also don't have to use words from the default dictionary. You can specify your own code.
callahad 5y ago
> Perhaps the sending-side should optionally require an interactive sender-ack Check out the `--verify` flag for `wormhole send` and `wormhole receive`

IanCal 5y ago

Ok, I'm definitely not understanding this then. This is my understanding so far: You are sending the file runs wormhole send myfile I, the attacker run wormhole receive __guess_code__ If my code is right, I get the file. If not, you cannot know, surely? There's no identification here other than the code. I can guess repeatedly as many times as I want. If lots of people are using the same server, the chance I start getting someones files is quite high. ~~In addition, with generating the code, either the sender has a way of checking if codes are in use (and so the attacker can more easily find current open valid codes) or there is the chance of a clash.~~ Edit - looking at the code I don't think this side is an issue. It'll ask for a connection then generate a code for that connection I think. So - how do I only get one guess?

lotharrr 5y ago
Good question! The code is broken up into two parts: a number, and some words. The number is like a mailbox: you put messages into it, the person you're intending to talk to puts messages into it, (maybe an attacker puts messages into it), everybody can read the messages there. The words are secret. There's a special cryptographic protocol named PAKE ("Password Authenticated Key Exchange") that tells you what messages to put into the mailbox. The protocol has a lock-step part in the middle, where you don't generate your second message until you've seen the other person's first message (and vice versa). When the protocol is done, if the two people used the same secret words, they'll wind up with the same secret encryption key, and nobody else will know the key. If they used different words, they'll wind up with random strings. The file transfer uses the shared key to encrypt the bulk data. Your client will generate a random wormhole code (random words plus server-allocated mailbox number) and run the protocol exactly once. It will generate and send its first message, wait for the partner's first message, then generate and send the second message, wait for the partner's second message, compute the shared key, do a test to see if it matches the other side (send a hash of the key), negotiate a direct connection if possible, then encrypt and transmit the file data. If an attacker is trying to guess your code, their only option is to pretend to be your intended recipient and follow the same protocol. They watch the server and learn the mailbox number: that part isn't secret. But then, to send their first message, they have to commit to some particular secret words. And they don't get to find out if they were right or not until they see your second message, by which point your client knows that this "one shot" has been used up, and it's either correct (the key-verification hash matches) or it's not (or the attacker disconnects and runs away, in the hopes of getting you to blame a flaky network instead of suspecting an attacker). If it fails, the client tells you that fact and quits, and you have to re-run the program (getting a brand new random wormhole code) to try again. Which means the attacker is back to square one: they know their first guess was wrong, but now the code is different, so their second guess has exactly the same chances of being right as the first guess.
- IanCal 5y ago
  Oh I see, thank you! I'd missed that it was an address/password combo. Thanks for the clear explanation.