[tjjfvi]

> requires trusting a server to rate limit attempts on brute-forcing that short password

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:

    A: $ wormhole send foobar
    A: Wormhole code is 1-whimsical-klaxon

    B: $ wormhole receive 1-klaxon-whimsical # wrong password
    B: ERROR:  Key confirmation failed. Either you or your correspondent
    B: typed the code wrong, or a would-be man-in-the-middle attacker guessed
    B: incorrectly. Try sending the file again.
    B: <exit>

    A: ERROR:  Key confirmation failed. Either you or your correspondent
    A: typed the code wrong, or a would-be man-in-the-middle attacker guessed
    A: incorrectly. Try sending the file again.
    A: <exit>

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).

[aniviacat]

Does that mean if 100 people send files over a server, and out of the 100 recipients a single one spells the code wrong, all 100 transfers get cancelled?

[bri3d]

No, the key negotiation occurs between two clients.

In the Magic Wormhole protocol, the number at the beginning of the Magic Wormhole phrase specifies a "nameplate" used to negotiate the "mailbox" which both clients (sender and receiver) use. If a recipient specifies a _matching_ nameplate but a _non-matching_ key phrase, the file transfer transaction between the sender and receiver with a matching nameplate will fail (since they cannot correctly produce a shared key), but nobody else is affected in any way.

An evil attacker could DoS the magic-wormhole mailbox server by spamming mailbox nameplates with bad keys, since there isn't much entropy at all there, but they would affect only single transactions at a time.