On 1/10/13 05:00 AM, d...@geer.org wrote:
Well clearly passwords are bad and near the end of their life-time with
GPU advances, and even amplified password authenticated key exchanges like
EKE have a (so far) unavoidable design requirement to have the server
store something offline
On 1/10/13 11:56 AM, ianG wrote:
On 1/10/13 05:00 AM, d...@geer.org wrote:
Well clearly passwords are bad and near the end of their life-time
with
GPU advances, and even amplified password authenticated key
exchanges like
EKE have a (so far) unavoidable design requirement to have the
Which leaves open the question (in my mind) as to whether to require this:
Both end points must authenticate each other.
Keep in mind that the client side was deliberately crippled in
browsers for privacy reasons. Support used to be much better—you
could transparently created a client
On 1/10/13 12:22 PM, Florian Weimer wrote:
Which leaves open the question (in my mind) as to whether to require this:
Both end points must authenticate each other.
Keep in mind that the client side was deliberately crippled in
browsers for privacy reasons. Support used to be much better—you
On 30/09/13 22:11, Jeffrey Goldberg wrote:
With SRP requires a shared secret key, so the attacker doesn’t even need to
“crack a hash” after getting hold of a server’s password database
i don't think that's true.
https://en.wikipedia.org/wiki/Secure_Remote_Password_protocol
The host pwd is of
On Mon, Sep 30, 2013 at 02:34:27PM +0100, Wasa wrote:
On 30/09/13 10:47, Adam Back wrote:
Well clearly passwords are bad and near the end of their life-time with
GPU advances, and even amplified password authenticated key exchanges like
EKE have a (so far) unavoidable design requirement to have
On 30/09/13 16:43, Adam Back wrote:
On Mon, Sep 30, 2013 at 02:34:27PM +0100, Wasa wrote:
On 30/09/13 10:47, Adam Back wrote:
Well clearly passwords are bad and near the end of their life-time with
GPU advances, and even amplified password authenticated key
exchanges like
EKE have a (so far)
On Mon, Sep 30, 2013 at 06:52:47PM +0100, Wasa wrote:
Also the PBKDF2 / scrypt happens on the client side - how do you think
your ARM powered smart phone will compare to a 9x 4096 core GPU monster.
Not well :)
How much would it help to delegate PBKDF2 / scrypt to smartphone GPU to
break this
On 30/09/13 19:22, Adam Back wrote:
On Mon, Sep 30, 2013 at 06:52:47PM +0100, Wasa wrote:
Also the PBKDF2 / scrypt happens on the client side - how do you think
your ARM powered smart phone will compare to a 9x 4096 core GPU
monster. Not well :)
How much would it help to delegate PBKDF2 /
On 30/09/13 19:41, Wasa wrote:
- with no server
i meant with no password. Arguably we can have decoy password if users
feel more secure with them :-)
___
cryptography mailing list
cryptography@randombit.net
On Mon, Sep 30, 2013 at 07:41:20PM +0100, Wasa wrote:
The only attack is on the PBKDF2 stored on the server (or malware to grab
the password on the client)
right. I was think SRP/JPAKE where the server does not store
PBKDF2(salt,pwd) server-side, but rather it stores something like
On 2013-09-30, at 10:43 AM, Adam Back a...@cypherspace.org wrote:
On Mon, Sep 30, 2013 at 02:34:27PM +0100, Wasa wrote:
On 30/09/13 10:47, Adam Back wrote:
PBKDF2 + current GPU or ASIC farms = game over for passwords.
what about stronger pwd-based key exchange like SRP and JPAKE?
Well
Well clearly passwords are bad and near the end of their life-time with
GPU advances, and even amplified password authenticated key exchanges like
EKE have a (so far) unavoidable design requirement to have the server
store something offline grindable, which could be key stretched, but thats
13 matches
Mail list logo
