[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 18 Jun 2013 02:17:54 +0100
From: Rafael Waldo Delgado Doblas <lord.rafa@...il.com>
To: john-dev@...ts.openwall.com
Subject: Re: Parallella: scrypt
Hello,
I have a couple of questions:
What is considered a valid ciphertext format for scrypt? I need to know
this in other to implement the valid function.
How is set the salt in test mode?. This structure
static struct fmt_tests tests[] = {
{"CCNf8Sbh3HDfQ", "U*U*U*U*"},
{"CCX.K.MFy4Ois", "U*U***U"},
{"CC4rMpbg9AMZ.", "U*U***U*"},
{"XXxzOu6maQKqQ", "*U*U*U*U"},
{"SDbsugeBiC58A", ""},
{NULL}
};
Have a pair of plain and cipher text but I can't see where the salt is
introduced.
Best regards.
2013/6/17 Rafael Waldo Delgado Doblas <lord.rafa@...il.com>
> Hello,
>
> I was using the reference code to make my own fmt file because it was the
> easier one to understand. Should I use other?. My apologies because I
> coundn't speak to much, I was finishing my project.
>
> BTW, I'm using a personal github repo to store my code, should I move to
> other?.
>
> Best regards,
> Rafa.
>
>
> 2013/6/17 <jfoug@....net>
>
> ---- Solar Designer <solar@...nwall.com> wrote:
>> > On Wed, Jun 12, 2013 at 02:27:42PM +0200, magnum wrote:
>> > > We actually have Colin's reference implementation in bleeding-jumbo,
>> added by Dhiru for the "scrypt" format (with format_name django-scrypt).
>> And Jim optimized it to 2x. I haven't looked at it but maybe it should be
>> renamed to django-scrypt (and your revisions merged)?
>> >
>> > Ouch! Dhiru - you should start announcing your additions to the tree in
>> > here. At least new formats. Somehow I missed this one in git.
>> >
>> > It's a pity that Jim spent time on this. The reference implementation,
>> > by definition, was not optimized. Colin, the original author, also
>> > provides two other implementations, which are much faster (more than 2x
>> > over reference). There's no point in us optimizing the reference
>> > implementation in any way - we simply should drop and replace it.
>>
>> Little time spent on this (but I do have little 'real' free time, so
>> point taken). It was trivial changes. 90% of the improvement was removal
>> of ridiculous memsets/memcpys, etc in a couple of areas in the deep inner
>> loop. But I did also put in quite a bit of time studying the algo, and
>> then digging in, and spending some time studying salsa, and starting to get
>> personal insights on how to do salsa 'right', and where the SIMD is within
>> that algo (there is a lot of opportunity) . I have yet to start putting
>> any of that knowledge into code, however. But yes, you are very right.
>> There probably is an easy 10x gain to be had by attacking the problem from
>> the performance direction instead of the current extreme readability
>> direction of the current reference code. But I did want to look at it.
>>
>> Just because something is reference code, does not mean it can not be
>> highly optimal. Take for instance when I re-wrote the reference code for
>> DCC2 (mscash2) found on the wiki, when I was looking to first port DCC2 to
>> SIMD and needed to get it figured out. Before I started this, PBKDF2 was a
>> total mystery to me, I had no clue at all. I found the original ref code
>> authored by S3nf, to be pretty opaque, with the algorithm hard to see, due
>> to all of the crypt code being inline within the ref piece. I threw away
>> all of the MD4/SHA1 stuff, and replaced with simply calls into oSSL. I had
>> already made some changes in other places, and knew to try to reduce the
>> amount of times the ipad/opad part of the HMAC being computed from
>> iteration times to 1 time. And the code itself was greatly reduced
>> (probably 20% or so line count, compared to original ref piece), AND the
>> actual logic of the DCC2 was tightly grouped and very easy to follow.
>> Once I got the code into that state, and could really wrap my brain around
>> it, it jumped right out at me, that the first 1/2 of each crypt (ipad/opad)
>> within each HMAC was being done over a constant. It was not only the
>> ipad/opad 'building' that could be eliminated, but the actual crypt also.
>> That change itself got put INTO the reference code on the wiki:
>> http://openwall.info/wiki/john/MSCash2_simple_code since I felt that
>> the reduction of that part of the crypt did not change the easy of
>> understanding with the ref code (it did need a comment to explain things a
>> little). And now, 2 or 3 years later, the logic from that ref code, with
>> VERY little change is still fully being used as the best code within most
>> of the JtR formats doing PBKDF2 logic, and I cringe when I see oSSL's
>> PBKDF2 code being used.
>>
>> But yes, you are certainly write about Colin's code, here. And it does
>> seem to be his habit in his ref pieces, that he almost seems to purposely
>> write code that is designed to run slowly. I wish he would not 'try' to do
>> things that way, but I have seen this on several things over the last
>> decade or so. It is too bad, because often that horribly sub-optimal
>> method gets into projection, and sometimes into HIGHLY used production
>> code, because a product needs some functionality, but the production team
>> has no one that is a crypto guru and there is no time for a team member to
>> study up to become one. They simply get tasked with 'add feature X' to the
>> product, find some code that they CAN read, and that 'works', and put it
>> in. Now, it DOES work, gets the job done, tests well, and ends up being
>> released. A prime example of this was php for at least a couple of years,
>> and it's MD5. Solar, I think even you felt the wrath of that one, when you
>> wrote PhPass and had logic in there (along with comments), that if run on
>> php prior to version XYZ, use the $P9$ (I think) which significantly
>> reduced the key stretching, because the the logic in those early versions
>> was SOOO dismal. Now I am not 100% sure that this was due to the php team
>> using some gawd awful slow ref piece implementation, but I would be willing
>> to bet a burger and a coke, that it was such a situation.
>>
>> [/rant]
>>
>> WOW, looking back on what I wrote, I am REALLY sorry for that strange off
>> the wall rant. I guess I should try to get more sleep, but I had to send
>> it, after spending he time to write it. All I really meant to say was
>>
>> "Solar, not much time was wasted optimizing that code, possibly an hour
>> or so. But I did spend some time 'learning' about the what/how of scrypt,
>> so that later I can help when we write it properly for our needs"
>>
>> But things went their own way, within my taxed brain. Guess I felt like
>> sharing a little of the insanity this morning, LOL.
>>
>> Jim.
>>
>
>
Content of type "text/html" skipped
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.
