lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 3 Sep 2014 14:46:41 -0700
From: Andy Lutomirski <>
To: discussions <>
Subject: Re: [PHC] Re: Re: Second factor (was A review per day - Schvrch)

On Wed, Sep 3, 2014 at 2:32 PM, Alex Elsayed <> wrote:
> Andy Lutomirski wrote:
>> On Wed, Sep 3, 2014 at 12:31 PM, Alex Elsayed
> However, here's another try:
> The user 'U' holds a PIN 'N' and a password 'P'
> the token 'T' holds a secret value 'X'
> 1.) T and U execute a PAKE over N, yielding channel C_t
> 2.) U sends P over C_t
> 3.) T combines X and P, yielding Y
> 4.) A and T execute a PAKE over Y, yielding channel C_a (U relays messages)
> 5.) T sends its derived key for C_a over C_t
> 6.) U and A are now authenticated (or not, but 'not' leaks no information)
> I suspect the method used to combine X and P is pretty much irrelevant,
> since Y never leaves the token, meaning that the token can get away with
> being nothing more than a PAKE implementation and a tiny amount of storage.
> To recap your requirements:
>> a) Use of the token is protected by a passphrase.
> Yep - without the PIN, the initial secured channel cannot be established.
>> b) The token can't tell whether a given passphrase is correct or not.
> Yep - it simply composes the user secret and its own secret.
>> c) If the token is honest, then no one can test a candidate passphrase
>> without querying the token once per passphrase tested.
> Yep - because the token executes the PAKE protocol with the auth server,
> it can't be cut out of the loop.
>> d) If the token is stolen but the computer it's in remains
>> uncompromised, then the token is completely useless to an attacker.
> Yep - because of the properties of a secure PAKE, nothing that could be used
> to recover X ever leaves the token, and P was never present.

Nice.  I think I agree, as long as P actually something derived from
the passphrase and something stored on the user's computer as opposed
to being an actual passphrase.

Maybe I should try to implement something like this for OpenSSH :)  If
only the world could agree on a simple, fast patent-free augmented
PAKE with a good security proof.  I think that some of the
EKE/Elligator stuff works nicely as a balanced PAKE.  I guess the IPR
situation for AugPAKE as specified in RFC6628 might be workable.


Powered by blists - more mailing lists