Hacker News Reader

Comment by allworknoplay | Hacker News Reader

The security model here is pretty great assuming you trust the rendezvous server.

Maybe consider an optional challenge/response prompt (like when your pal enters the prompt code, their client generates a second code that they give back to you) to make sure nobody's intercepted the request before them, odds aside (if someone got your initial code somehow, they could definitely man in the middle the request otherwise).

View on HN

If I did things right, the rendezvous server shouldn't get any advantage over a network attacker: one guess per invocation of the program, 1-out-of-65536 chance of getting it right, 65535-out-of-65536 chance of giving you a WrongPasswordError.

FWIW, there's also a --verify option, which causes the program to print out a hex hash of the session key, and wait for you to approve it before sending anything. Not as ergonomic, but it removes the MitM threat pretty effectively.

Call me a nerdy hipster, but I prefer my 1-in-2^256 chance with AES encryption. Then I can put it, well, anywhere. Including a thumb drive, google drive, S3, email, or even some random public newsgroup.

I realize this complicates things a touch - you need a program to encrypt and decrypt the file - but that seems much more secure.

You also need to read the full AES key to your recipient. If you've already got a secure channel to your recipient, great: you can just paste them the key. But if you're sitting next to a new friend at a conference and want to throw them a copy of your secret file without worrying about who else might be able to see it in the future, you might want something more.. ergonomic :).

Your odds probably aren't that good.

https://www.schneier.com/blog/archives/2011/08/new_attack_on...

Close though :)

google drive, S3, and similar storage options are easier than wormhole. Not sure you need AES: How secure is google drive over https?

Depends. Do you trust Google?

> a --verify option, which causes the program to print out a hex hash of the session key

This is plenty enough.

Another option is to use the ssh model whereby the sender has a persistent keypair, uses it to sign the handshake and sends the pub key to the peer. If the peer has this key in its key cache, it proceeds quietly. Otherwise it pops up a "New key, please verify and approve" message before proceeding.

Isn't it more like a <number of pending transfers>-out-of-65536 chance of getting it right? If there are 256 pending transfers, then it's more of a 1 in 256 chance of stealing someone's information?

The more popular this program gets, the easier it is to steal people's information?

Does the session key hash help if the attacker guessed the code correctly?

Yup, it still does. In the face of a lucky-guessing attacker, PAKE basically degenerates down into plain unauthenticated Diffie-Hellman, which means Alice-Mallory has one key, and Mallory-Bob has a different key. Mallory could decrypt the messages from Alice and then reencrypt them for Bob, but Alice and Bob will still both see different keys. If they have some out-of-band means to compare those keys (which Mallory can't corrupt), then they can detect the attack.

Thanks!

Reply on news.ycombinator.com