Hacker News Reader

Comment by jwilk | Hacker News Reader

Magic Wormhole is a security disaster. Do not use if you have other options.

1) By default, authentication key has only 16 bits of entropy. (I wish I was making this up…)

2) There's no good UI to make the key stronger: you can either use, say, "--code-length 16", which makes the receiving code ridiculously long, or provide your own code with "--code", in which case it's visible to other local users via ps(1).

3) Between "wormhole send" and "wormhole receive" on the other side, anyone on the Internet can attempt to intercept the transfer. Conveniently, you can list all currently valid channel ids (nameplates).

4) If the interception succeeds, the attacker can immediately run "wormhole send" with the same code, so that the intended side wouldn't notice anything is off.

5) If the interception fails, the attacker still ruined the transfer. (DoS)

All of this would be fixable, if not the maintainer's bizarre insistence on using weak crypto.

View on HN

> 5) If the interception fails, the attacker still ruined the transfer. (DoS)

Worse, because MW is so happy to reuse channel ids, with some amount of luck, one can ruin multiple transfers in one go:

• Alice runs "wormhole send foo", which generates code "1-revenue-hamlet".

• Mallory runs "wormhole receive 1-bad-code-haha", ruining Alice's transfer.

• Bob runs "wormhole send bar", which generates code "1-enchanting-drunken". (Channel id 1 is now technically free, so why not.)

• Alice's friend, unaware of Mallory's malfeasance, runs "wormhole receive 1-revenue-hamlet", inadvertently ruining Bob's transfer.

> There's no good UI to make the key stronger: you can either use, say, "--code-length 16", which makes the receiving code ridiculously long

So you want short, high-entropy keys in a restricted alphabet? That might be tough.

Anyway, if it’s not brute-forceable and/because attacks are visible, it’s not really an issue.

I don't know what you mean by "restricted alphabet".

"--code-length 16" gives you 137 characters on average.

With base64, you could have the same amount of entropy in 22 characters.

Base64 is harder to type, memorize, and communicate, although I do usually use lowercase letters for this type of thing as an improvement over digits.

> By default, authentication key has only 16 bits of entropy. (I wish I was making this up…)

It's a PAKE being used for Socialist Millionaire-style interactive authentication. So that key needs to be successfully guessed by the attacker. If they guess wrong they don't get any further attempts, game over, all three participants (the sender, receiver and this attacker) learn it didn't work. That's just not an attractive attack.

I've written on HN before that I think this is too few bits on balance, but that's because of social effects (a million people use it, one person gets very unlucky, that impacts take up for the same reason people don't review products that were fine, they're either 5/5 best in class or 0/5 this product killed my cat)

Setting code length 16 means you want a 128-bit PAKE. You've noticed that 128-bit secrets aren't very convenient for humans. But you don't seem to have thought any further than that, just convinced it should be "fixable" without introspecting about the core problem.

> You've noticed that 128-bit secrets aren't very convenient for humans.

Meh. Even if you have to retype the secret, 128 bits in not a big deal. The time spent on typing is trivial in comparison to the time you're gonna waste when you fall victim to DoS. I'm speaking from experience.

Reply on news.ycombinator.com