steve at tobtu.com
Sun Aug 17 21:22:09 PDT 2014
> On August 17, 2014 at 3:14 AM Michael Hamburg <mike at shiftleft.org> wrote:
> The points look good to me, and I’m getting the right fraction of 1/16. Maybe
> you’re accepting points with qX = (0,0), which is why you’re getting 1/8?
I must of messed up my generation script. These are the points I found from 1 <
x < 102. Well then there's the negative points of these. Are these the same
points you got?
> The protocol looks reasonable, but you’d want a proof. It actually looks a lot
> like augmented SPAKE2, so the proof might just go through.
> * You’re just canceling out the 1/k Q, so it serves the same function as kQ in
> * The 1/k on P is used for augmentation, which works as basically the opposite
> of SPAKE2’s augmentation (basically send bP, check kbP). I think they’re about
> equally efficient.
> * SPAKE2 throws more stuff into the hash function.
Where is the specification for SPAKE2. All I found was SPAKE1's protocol with
Diffie-Hellman and that SPAKE2 does a slightly different KDF.
> * Usually PAKE protocols also create a key shared between the two parties, eg
> key || v1 || v2 = H(X(ap) || X(bp) || X(abp)), then exchange v1 and v2.
Yeah I know I was just lazy and since there are several ways to do this I just
deferred till later.
> I’ve been meaning to write up “SPAKE2 Elligator Edition” where you replace
> (1/k)Q here with cofactor * Elligator(k). This could work here too. Dunno if
> that would be better than the SPAKE2EE I’ve been cooking up. The advantage is
> that if someone somehow comes up with log base P of Q, it doesn’t instantly
> hack everyone. That is, it doesn’t rely on static DH.
So I'm just going to guess how this works:
P = Elligator(k)
A: key || v1 || v2 = H(abP, ...)
B: key || v1 || v2 = H(abP, ...)
Is this correct or am I completely off?
More information about the Curves