[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 14 Aug 2012 22:44:09 -0500
From: "jfoug" <jfoug@....net>
To: <john-dev@...ts.openwall.com>
Subject: RE: SRP
At this time, after some emails with Magnum and Dhriu, it looks like we
should back this out, at least to only bleeding level.
Sounds like there will be issues with GMP installed. I have not tested
quality or speed of oSSL doing an expmod, and was not even aware it exposed
that, but it sounds like it does. Hopefully, it will not end up being a
version specific feature, so that we can make this a plug format.
But I think for now, Magnum is going to move the format into unused, and
revert the -lgmp added to Makefile (possibly leaving it in bleeding).
But I do think you are right. A 'generic' SRP would be better, vs a
battle-net specific SRP.
Jim.
>From: Solar Designer [mailto:solar@...nwall.com]
>Jim -
>
>This is very nice. Thank you!
>
>On Tue, Aug 14, 2012 at 10:09:31AM -0500, jfoug wrote:
>> I am not sure of the leak. I have seen no 'real' hashes.
>
>Same here. How about we target genuine SRP as released at
>http://srp.stanford.edu/download.html for now? That would be of some
>use on its own - hopefully even of more use than targeting Blizzard's
>"custom SRP".
>
>> At this time, I am hesitant to release this, since we really do not
>> know if this is correct,
>
>Maybe you can build/install SRP, generate some test verifiers, and use
>those? I just downloaded srp-2.1.2.tar.gz from the URL above and took a
>look. At first glance, it appears to use SHA-1 in the verifiers.
>Specifically, I looked at the function t_makepwent() and its uses from
>base/src/passwd.c and base/pam_eps/pam_eps_passwd.c.
>
>> Some 'assumptions' I have made:
>>
>> Username data uppercased.
>>
>> Password uppercased.
>
>When we don't target Blizzard's SRP verifiers specifically, these
>assumptions will need to be removed or made optional.
>
>> Format is:
>> $WoWSRP$256_bit_hash_in_upper_case$salt_in_upcase_hex*USERNAME_UPCASE
>
>The official SRP distribution already includes some code to format
>verifiers as ASCII strings:
>
>_TYPE( void )
>t_putpwent(ent, fp)
> const struct t_pwent * ent;
> FILE * fp;
>{
> cstr * strbuf = cstr_new();
> char saltbuf[MAXB64SALTLEN];
>
> fprintf(fp, "%s:%s:%s:%d\n", ent->name,
> t_tob64cstr(strbuf, ent->password.data, ent->password.len),
> t_tob64(saltbuf, ent->salt.data, ent->salt.len), ent->index);
> cstr_clear_free(strbuf);
>}
>
>We can't use the colon between the encoded ent->password.data and
>ent->salt.data, but with the colon replaced by '$' the rest of the
>string format should be usable as-is. prepare() can take care of
>extracting field[1] and field[2].
>
>Thanks again,
>
>Alexander
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
