On 1 Mar 2015, at 10:04, Nadim Kobeissi <[email protected]> wrote: > Yes, it all boils down to this. Waiting for evidence of insecurity is silly. > Joseph and Trevor's insights have been convincing. I think I need to act now > -- going beyond public beta without making key derivation stronger would be a > mistake. > > I'm actually very interested in the solution that Michael Hamburg just > outlined. Link for convenience: > http://moderncrypto.org/mail-archive/messaging/2015/001574.html > > This strikes me as the best idea right now. Would be happy to hear thoughts.
On 1 Mar 2015, at 8:24, Michael Hamburg <[email protected]> wrote: > Perhaps you should use oblivious function evaluation with a user-specific > secret at the server. So for example, server has a per-user secret key e, > and user has a (salted, scrypted) password p. Let h = hash(p) on some curve. > > client chooses a uniformly random scalar r. > client -> server: Q = h^r > server -> client: P = Q^e = h^er > client computers P^1/r = h^e, and uses the hash of that point as part of the > secret key derivation. > > You can gate this interaction by the PIN code. But even if an attacker can > query it, under the one-more-DH assumption he needs N queries to check N > passwords. Very nice idea, but the server will be hacked, exposing e, well presumably that’s in your threat model. I'd consider : - Store different e across a DHT that replies to queries by retuning the appropriate P = Q^e. - Access the P using some PIR scheme, ala DP5, Gnu Name System, etc. to construct the different h^e. - Build a secret by combining some of the h^e using a secret sharing scheme. It’d be neat to avoid the “table” part of the DHT somehow, but I'm not seeing an approach with the secret sharing schemes I know. Another approach might be a “password-derived two-factor authentication" when a user installs the system on a new machine they must initialize the machine’s factor m by iterating scrypt on the salted password p enough times to consume 10 min, or even an hour. After that initialization, the software saves m to it’s configuration file and the secret is derived by hashing m++p. Yet another approach might be selecting the password through a search & menu interface that ensured enough entropy : - Select a large corpus of English quotations by famous people. Analyze these to ensure they do not become too ambiguous, i.e. no variations, no miss attributions, etc. - Assign users a series of quotations which they must print or write down. - Users select their quotations through an interface that allows them to search based on keywords, authors, etc. Again the actual secret could be reconstructed using secret sharing, erasure coding, etc., so that not all some quote could be lost and reconstructed and the order did not matter. There are schemes where the system prints out a QR code needed for login too, of course. In any case, it’d be worth building a library designed to provide several high entropy pass phrases tricks, preferably in C so that any non-browser tool can use it. I could potentially help with this, falls under the scope of my new job with gnunet. Jeff _______________________________________________ Messaging mailing list [email protected] https://moderncrypto.org/mailman/listinfo/messaging
