[messaging] Common secret comparing

Van Gegel torfone at ukr.net
Fri Jan 26 01:59:56 PST 2018


Thanks all!

Katriel Cohn-Gordon, I'm sorry, I assumed checking A'!=B! but not include this in trascription.
Of cource, UKS protecting also can be achived including IDs into hashing.


Mike Hamburg, ops, it is a real dictionary attack! 
Now I see SPEKE paper:
https://eprint.iacr.org/2014/585.pdf
The difference only in key deriving function:  f(s) = (H(s))^ 2 mod p;
Can I applied this to curve?

And now I find this thread:
https://moderncrypto.org/mail-archive/curves/2017/000940.html
My problem is closely same: I use Cortex M0 with limited program code memory so small for Edvards Ed25519.
I havn't elligator's C code for Montgomery 25519: I have only EC25519 refference DJB's code with only mul() and mul_base() in my system.
And also have Keccak Sponge as near "ideal" hash, mac and crypt (like Shake-128).
  
Is it possible to design any safe PKE in this environment? Maybe even with extra passes and decreasing computation efficiency but without any additional math.

--- Original message ---
From: "Ben Harris" <mail at bharr.is>
Date: 25 January 2018, 10:46:03


If I have this right (??), the attack is:

Alice sends A which is equivalent to a*c*G.
Mallory takes A and multiplies by random b and sends back B as b*G.
Alice computes S as a*B = a*b*G and sends MA as H(A | B | S).


Mallory now guesses a password to compute c'. She then computes a guess S' as (1/c')*b*A = (1/c')*b*a*c*G. If c' == c then this is a*b*G and S' == S.
Mallory checks S' by computing H(A | B | S') and comparing to MA.


On 25 January 2018 at 07:56, Mike Hamburg <mike at shiftleft.org> wrote:
Er, you would compute A’ =  mul(8*a, elligator(c)).  That is, you don’t also have to multiply by c.

Whoops,
— Mike

On Jan 24, 2018, at 12:56 PM, Mike Hamburg <mike at shiftleft.org> wrote:

It’s not safe against dictionary attacks by Alice or Bob.  For that, you want SPEKE, SPAKE2, PAK, …

This is a variant of SPEKE.  To make it secure you would compute A = mul(8*a, elligator(c)) and B = mul(8*b, elligator(c)) instead of what you have here, and also hash elligator(c) in the final MA/MB computation, in addition to adding identities or something to address Katriel’s concern.


— Mike

On Jan 24, 2018, at 3:37 AM, Katriel Cohn-Gordon <me at katriel.co.uk> wrote:

What does "safe" mean in this context?



For example, an adversary could reflect Alice's initial message back to Alice, and then reflect the hash back as well. The result is that Alice will complete a protocol execution without Bob even existing. Is that bad?



Katriel




On Wed, 24 Jan 2018, at 10:45 AM, Van Gegel wrote:

Hi all!
Please advise on this protocol:

Two parties comparing 2 bytes short  common secret  using EC25519 (only mul and mul_base procedures) and SHA3 hash.
Any side can be active adversary trying obtain secret.

c = H(secret)

Side A:
- picks a at random
- computes A = mul_base(a)
- computes A' = mul(c, A)
- sends A' to side B

Side B:
- picks b at random
- computes B = mul_base(b)
- computes B' = mul(c, B)
- sends B' to side A

Side A:
- computes S =  mul(a, B')
- sends MB=H(A' | B' | S) to side A

Side B:
- computes S= mul(b, A')
- sends MA=H(B' | A' | S) to side B

Both A and B checks MA and MB.

Is this protocol safe?

_______________________________________________

Messaging mailing list

Messaging at moderncrypto.org

https://moderncrypto.org/mailman/listinfo/messaging



_______________________________________________
Messaging mailing list
Messaging at moderncrypto.org
https://moderncrypto.org/mailman/listinfo/messaging












_______________________________________________
Messaging mailing list
Messaging at moderncrypto.org
https://moderncrypto.org/mailman/listinfo/messaging




_______________________________________________
Messaging mailing list
Messaging at moderncrypto.org
https://moderncrypto.org/mailman/listinfo/messaging
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20180126/d0c4f0e1/attachment.html>


More information about the Messaging mailing list