Hacker News new | past | comments | ask | show | jobs | submit login

Magic Wormhole is neat, but the happy path is to use a third-party rendezvous server, which is susceptible to traffic analysis (I also wish that the codes had more than 16 bits of entropy, but that is part cargo-culting on my part).

Signal is also vulnerable to server-side traffic analysis, and is strangely keen on both demanding a selector (a phone number) for identity and on trusting Intel's 'secure' enclave (I strongly suspect that it's suborned).

One thing I do like about PGP is that it has been around awhile: I can still decrypt my old files & verify old signatures just fine, something I don't trust the flavour of the month to do.

I think that rather than a Swiss Army knife tool & protocol like PGP, we should have a suite of tools built around a common core, probably NaCL. That way we can have compatibility when we need it, but also aren't cramming square pegs into round holes.

Finally, the Web of Trust was a bright, shiny idea — and wrong. But Trust on First Use is also pretty bad, as is the CA ecosystem. We need something else, something decentralised and also secure — and I don't think that's impossible. I've had a few ideas, but they haven't panned out. Maybe someday.

> Finally, the Web of Trust was a bright, shiny idea — and wrong

Yeah, this whole part is some 90s cypherpunk way of modeling human relations, which has never mapped onto any real world relationships. As soon as people had real world digital identities outside of their gokukillerwolfninja666 logins, this didn't help.

CA ecosystem might be fundamentally flawed, but WoT was a complete failure. So PGP users end up trusting some key server which is probably sitting under someone's desk and has been owned by every serious intelligence service since forever.

Re: common core: isn't that already happening? age and signify are both based on those 2, and magic-wormhole arguably is too (though point addition is not always exposed, so SPAKE2 is a little harder to implement than signify).

Yeah-ish, but what I mean is an actual set of different tools (so, not one-size-fits-all) but all part of the same suite, rather than a bunch of different implementations of mostly the same idea — i.e., *BSD rather than Linux.

One of my numerous hobby projects is exactly that, but … I simply don't have enough Round Tuits.

OK, so you're saying something like:

  magic send <FILE>
  magic receive <CODE>
  magic encrypt <FILE>
  magic sign <FILE>
... that ideally all have NaCl at the base but are otherwise one binary that you have to remember?

The tricky one there is probably chat.

I think they meant something like the OpenSSL binary that obviously builds on the library and provides everything through the command line.

The problem is that the same thing for NaCl/libsodium would be lower level, and probably still not enough as exhibited in the article: a typical use case is not "I want to encrypt this file", it's "I want to send this file to that person such that no one else can read it" or "I want to send a message to that person such that no one else can read it, and if they can they shouldn't be able to read other messages from the same conversation". No cli tool can properly solve this, it has to be incorporated in the application or even protocol.

Incidentally, the real goal of magic-wormhole is to provide the initial secure introduction between two people's communication tools. Get your public key into my address book safely, and then all those other modes have something to work from. Keybase.io is kinda in the same direction except they're binding key material to de facto identity services (github, twitter, etc) rather than pairwise introduction.

Well, they don't all have to be one binary, but I'd like them to use consistent file formats, command-line arguments &c.

And yeah, chat is very much not like the rest — but I'd still like my chats to be somehow validated with my magic ID.

Couldn't we instead just cut the shared password in 2 (or use 2 passwords, it's the same), so we don't require point addition? I really don't feel like implementing key exchange in Edwards space just so I can have the complete addition law… unless maybe I don't need the law to be complete?

Here's how it could work (unless you tear it apart):

  Alice and Bob share two passwords out of band: Pa and Pb
  Alice and Bob generate two key pairs ka/KA, and kb/KB
  Alice sends KA, Bob sends KB
  Alice and Bob compute ss = HASH(DH(kb, KA) = DH(ka, KB))
  Alice responds to KB with Ha = HMAC(Pb, KB || ss)
  Bob   responds to KA with Hb = HMAC(Pa, KA || ss)
  Alice verifies Hb
  Bob   verifies Ha
  The session key is HASH(ss) or something
The main disadvantage is that to achieve the security of a true PAKE, passwords here must be twice as long. A 4 digit Pin number here would only have the security of two digits (1/100). You'd need 8 digits to get to 1/10,000 security. On the other hand, it's extremely simple, doesn't require point addition, and if there's any flaw you probably already have spotted it.

Re: magic-wormhole's 16 bits: I don't think you should be worried about that, because SPAKE2 will give you proof positive if the attacker attempts to guess. Are you saying 2*-16 success isn't good enough?

> Are you saying 2-16 success isn't good enough?

I really don't think it is, because it might be worthwhile for a particular sort of attacker, say one who runs the default rendezvous server: observe global activity, attempt to MitM every connexion for 30 seconds, then write up a spurious blog post about a 'network issue' or 'bug' or whatever which caused a brief outage. N:2^16 is okay* against targeted attacks, mostly (hence my 'cargo-culting' comment), but with a large enough N …

The nice thing about 1:2^128 is that you just don't have to care.

(magic-wormhole author here)

It's probably worth pointing out that the 2^-16 chance is per invocation of the protocol.. it's not an offline attack. So you'd have to be reeeealy patient to run it enough times to give the attacker a decent chance of success.

The best attack I can think of would be for me (or someone who's camped out on my rendezvous server) to make an MitM attempt on like one out of every 100 connections. Slow enough to avoid detection, but every once in a while maybe you get a success. Of course you don't get much control over whose connection you break (if you did, you'd be back in the detectable category again).

FWIW, some numbers. The rendezvous server that I run gets reports from clients about the success/failure of the key establishment phase. Over the last year, there were 85k sessions, of which 74% resulted in success, 22% in timeouts, and 2.5% in bad key-confirmation messages (meaning either a failed attack, or someone typoed the code). So in the worst case where every one of that last category was really a failed attack, there's roughly a 2130/2^16 = 3% chance that someone managed a single successful attack last year.

But I tried to make it easy to choose a different tradeoff. `alias wormhole-send=wormhole send --code-length=4` gets you to 2^-32 and gives codes like "4-absurd-almighty-aimless-amulet", which doesn't look too much harder to transcribe.

Yeah, I think that current default sails too close to the wind. 2^-16 chance on a stochastic MitM attack feels fine statistically - and then you think about that one person who it worked on. For them it wasn't 2^-16 it was binary, it didn't work.

They just used your "secure" file transfer mechanism and their data got stolen.

You're on the same side of this as the airline industry. The person driving a car understands intellectually that their drowsy half-attention to the road is statistically going to kill them, whereas travelling in coach on a mid-range two engine jet liner is not - but emotionally they consider driving to be fine because they're doing it, and air travel is trusting some random stranger. As a result, the industry need to make air travel so ludicrously safe that even though emotionally it still feels dangerous the passengers will put that aside.

2^-16 is intellectually defensible, but my argument above is that shouldn't be what you're going for. So that's why I'd suggest a longer code by default.

Okiedokie: you should just use wormhole then: wormhole receive 4-gossamer-hamlet-cellulose-suspense-fortitude-guidance-hydraulic-snowslide-equation-indulge-liberty-chisel-montana-blockade-burlington-quiver :-)

Isn't the code length also selectable?

Yep, the default python implementation lets you pick a code and generate a code with more than 2 words. I'm just cautious in telling people to twiddle knobs that don't need twiddling :-) But you can absolutely go up to 2^-64 or whatever if that makes you happy!

Applications are open for YC Winter 2020

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact