It is indeed. Magic Wormhole implements a PAKE to individually encrypt and authenticate a secure channel without requiring any other root of trust. It's exceptionally easy to use and secure.
This. If you share a temporary password through another secure channel, you can probably just share a symmetric key and then you don't need PAKE anymore. In some cases though, you might want to send yourself something from one device to the other, or you are talking to someone who's not really technical on the phone.
About being online at the same time, I was under the impression that this wasn't a requirememt.
To transfer a file, both parties do need to be online at the same time. The server (which I run) does not store the file's data: it stores tiny key-exchange messages until both sides manage to make a direct connection, but then the encrypted file data is sent from sender to recipient without being stored in the middle. So it doesn't replace email or an FTP server or some other asynchronous file-transfer service.
You're absolutely right that if you already have a secure channel, you can send a full-strength symmetric key that way (e.g. send a PGP key, or one of the alternatives in gtank's post). But PAKE enables using a low-bandwidth secure channel. I can easily read a magic-wormhole code like "4-purple-sausages" to someone over the phone or to the person sitting next to me, but I'd be hard pressed to dictate an entire 256-bit secret key correctly.
Also, if you're sending an encryption key you have to make sure it's a good key, ie generate it from a reliable source of random and with a sufficient length, whereas magic wormhole's password is automatically generated for you.
Yes, that's what I'm saying: GP's point is that if you have a secure channel you might as well send the encryption key, but in order to do that you have to be careful about generating it correctly, whereas PAKE give you the possibility to exchange something far simpler.
Well, it's nice when phone is considered secure channel. It's not so for many serious applications, however. PGP invented to deal with situations when you communication channels are untrusted. See, no one says your software is bad, but when it is marketed as a better alternative to PGP it's not true, and worse, it's absolutely irresponsible thing to do.
According to parents nice talk[1] you can add a verify switch that lets you compare the signature of the actual key. So a public authenticated channel is enough.
I'm not sure we are on the same page here. Having control over a channel you use to pass your code, I can receive your secret file, I just need to be quicker than a legitimate recipient. How this '--verify' flag will help you then?
- both parties to be online at the same time
- have access to a secured channel to transfer the secret
- Transfer a new autogenerated secret for each file transfer.
PGP lets you:
- verify the key once
- re-use the key
- the key be submitted through a public channel
- the verification be done in a public (though tamper proof) channel or by web of trust
- the file be stored in transit, no need for online
But obviously, if the complaint is that pgp is too complex, then each single tool to replace some functionality doesn’t cover the whole spectrum.