Are you considering PAKE in something Dolev-Yao-ish (i.e., with a strong KCI assumption) or a bideniable model?
(I assume Dolev-Yao-ish in the following.) On Thu, Oct 2, 2014 at 6:54 PM, Michael Hamburg <[email protected]> wrote: > Explicit key confirmation: Require or no? Should be optional but possible; am I right in thinking it always requires an additional round? > Augmentation: Should the server’s credential be insufficient to log in > without a dictionary attack? Maybe augmentation on both sides is even > desirable, for some reason? Certainly yes to the first for client-server; it's a lovely property. Isn't it necessary in the peer-to-peer situation? (Otherwise, by symmetry, a form of KCI is possible.) (I'm assuming you mean a per-client credential. A PAKE protocol that provides this also needs to be secure against KCI, in an appropriately strong formulation.) > Security model: Does anyone care about GapDH, DDH, SquareDH etc assumptions? > This is definitely in the random oracle model, by the way. I'd very strongly prefer DDH. GapDH is okay. Anything more exotic is asking for trouble, but eh, hardly anyone cares. (But the "generic group" assumption would be unacceptable.) Are there tightness issues? I'd be reasonably happy with a tight GapDH reduction, even with a (very) non-tight DDH reduction. > On a somewhat related note, is there any desire to encrypt the user name? A > man in the middle can recover it at the cost of disrupting the session, but > it should be possible to hide it from passive eavesdroppers (at the cost of > more rounds and more complexity). Does it *require* more rounds? (I.e., what's the problem with the obvious approach of encrypting under the server's static key, for the client-server case?) PFS would require an additional round, I think... _______________________________________________ Curves mailing list [email protected] https://moderncrypto.org/mailman/listinfo/curves
