Comment by lvh

7 years ago

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

6 comments

lvh

eadmund 7 years ago

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.

lvh 7 years ago
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.
- rakoo 7 years ago
  
  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.
- lotharrr 7 years ago
  
  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.
- eadmund 7 years ago
  
  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.

loup-vaillant 7 years ago

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.