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 t
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
> 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 cer
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 s
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 g
>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 that
On 2013-09-30, at 10:43 AM, Adam Back 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 SRP most cert
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
g^{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
http://lists.randombit.net/mailman/listinf
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 / scr
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 a
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 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
13 matches
Mail list logo