[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <008201cd7b65$01350e20$039f2a60$@net>
Date: Wed, 15 Aug 2012 23:09:59 -0500
From: "jfoug" <jfoug@....net>
To: <john-dev@...ts.openwall.com>
Subject: RE: SRP
In the srp code (from Stanford), they simply use an index into a set of hard
coded data in that t_conf.c file. We could do this also.
Something like: $SRP-num$hash where num matches the array element from the
Stanford code.
Like I said, many should be easy to figure out. Length of the hash tells
which mod to use (as long as the crypt was FROM the true Stanford code0).
But part of the problem with this, is someone can choose ANY prime mod, and
any base (base would not 'need' to be prime). They could use 100% 'pure'
Stanford code, but simply pick their own values.
NOTE, in the SRP code, there is logic to find 'safe' primes (SG primes, that
fall into a specific pattern that makes them hard to factor). For this type
usage, I really doubt that matters much at all. Any prime should work just
fine. It is not used in any pub key way, but is simply there as a different
kind of key stretching.
So all in all, I am not sure how 'useful' this really can be.
The SRP does a few things.
1. It uses some crypto secure hashing functions, to mix well to start with
(with decent salts, but ONLY with 2 crypts).
2. It then does a key stretching with a very simple, but very slow process,
and this can be made as slow as needed. The process is simple expmod,
b^v%N.
3. it allows part of the algorithm to be site specific, and likely private.
That is the g and N values chosen.
The functions: x=sha1($s.sha1($u.:.$p)) and b^x%N are public knowledge. $v
(final result), $s and $u are private data stored per user. b and N are
private data, likely stored in code, outside of any database. The b and N
'could' be the canned values, stored in the SRP source, but if I were
setting up a site, I certainly would generate my own unique values, and
treat them like any other private key. This could be reversed, I believe,
by someone knowing $u, $p, $s and $v, meaning whoever is pulling the DB
data, has a known record out there, knowing his $p. This reversing of the
exponentiation, I am not sure of, but I would bet there is some quick
algorithm to recomputed b and N.
So, we are somewhat at a quandary. In all actuality, we may have to add b
and N to the hash string, OR we may have to generate a table of b/N that we
'known' about, and the hash contains an index into that table.
Like I said, I need to sleep on this, and think a little. There may be a
more elegant way to do this in a generic manner.
Jim.
>-----Original Message-----
>From: Solar Designer [mailto:solar@...nwall.com]
>Sent: Wednesday, August 15, 2012 10:15 PM
>To: john-dev@...ts.openwall.com
>Subject: Re: [john-dev] SRP
>
>On Wed, Aug 15, 2012 at 12:20:39PM -0500, jfoug wrote:
>> I wonder if we should change the name of this from wowsrp (and
>wow_srp_fmt_plug.c) to srp-wow (and srp_wow_fmt_plug.c), and then build
>a srp format (and srp_fmt_plug)? This would keep the name similar. It
>is 'SRP' algorithm, but with the battlenet specifics, vs the 'stock'
>SRP.
>
>This rename makes sense to me.
>
>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.
