public inbox for govpn-devel@lists.cypherpunks.ru
Atom feed
From: stargrave@stargrave•org
To: govpn-devel@lists.cypherpunks.ru
Subject: Re: [Govpn-devel] Security issues in protocol
Date: Mon, 4 May 2015 10:57:57 +0300	[thread overview]
Message-ID: <20150504075757.GA79157@stargrave.org> (raw)
In-Reply-To: <CACsn0cmneZx8pq76dApMvVCmq-zxPB1i8O8rxt9aRcsMjSwBEQ@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1216 bytes --]

Greetings!

*** Watson Ladd <watsonbladd@gmail•com> [2015-05-04 05:00]:
>It's possible for an attacker to mount an offline-guessing attack
>against A-EKE as follows. First, the attacker compiles a list of all
>possible DSA keys from a given list of passwords. Secondly, for each
>key, the attacker determines if decryption with that key would produce
>a valid Curve25519 public key. Only half of all thirty-two byte
>strings are valid keys, so on average this removes half the
>possibilities each time.

GoVPN's DSA keypairs are generated not directly from the password, but
from PBKDF2 applied to it. And you have to provide a salt (that equals
to client's id). You can not pre-build possible keys without knowing
exact salt, that is not sent on the wire in clear.

Maybe I am wrong, but seems it is only applicable if salt=client's
identity is know.

>This attack can be prevented by using Elligator, or by using
>alternative PAKE schemes which are proved to be secure such as SPAKE2.

Thanks for the suggestion! Currently I will look on Elligator more
closely, because the fast that public key curves are distinguishable
from the random is annoying.

-- 
Happy hacking, Sergey Matveev

[-- Attachment #2: Type: application/pgp-signature, Size: 801 bytes --]

  reply	other threads:[~2015-05-04  8:00 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-04  1:59 [Govpn-devel] Security issues in protocol Watson Ladd
2015-05-04  7:57 ` stargrave [this message]
2015-05-04 12:01 ` stargrave