[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+EaD-Y7yPzuowZC9yvkDCBjns+Nv9EggvX_m8f0dsZ2QOrfEA@mail.gmail.com>
Date: Tue, 20 Aug 2013 17:24:17 +0200
From: Katja Malvoni <kmalvoni@...il.com>
To: john-dev@...ts.openwall.com
Subject: Re: Parallella: bcrypt
Hi Alexander, Yaniv,
On Mon, Aug 19, 2013 at 12:22 AM, Solar Designer <solar@...nwall.com> wrote:
> So I think we're actually facing the problem that we previously knew of
> theoretically. I think Yaniv gave us some advice on how to avoid it,
> but frankly I did not follow the project closely enough at that point.
> Katja - perhaps re-read Yaniv's postings on this?
>
Hm... If I understood them correctly, Yaniv's postings were about case when
there are multiple write (or read) calls from host while we have only one
which transfers whole inputs structure. From this code
https://github.com/adapteva/epiphany-libs/blob/master/src/e-hal/src/epiphany-hal.cit
seems that whole buffer is transferred at once. From postings I got
impression that only thing which can be done is to check whether data is
transferred correctly before writing start flag. So I changed code to do
that - removed start arrays from inputs structure and put only one start
array in shared_buffer structure. And did check of transferred data. That
didn't help. Am I missing something here?
I managed to get a version which hasn't failed in over 50 runs (code is
attached). I did three things - added CHECK macro on host side, transfer
one salt per core and copy keys from external memory only when they change.
If I change any of those it misses some passwords.
If only one salt is transferred for all cores than some passwords are
missed.
If I remove check on host side and read keys only when changed than it
doesn't work at all (no matter is there only one salt or one per core) - it
cracks around 25000 passwords and fails self test sometimes. I'm not sure
why check on host side helps - it does nothing. Checking it on host side
won't change anything on Epiphany side if start arrays are transferred
correctly. And check is passed immediately. I guess that read by host is
executed before read from Epiphany since both use AXI bus and it's possible
that host gets served first. I added keys check before BF_crypt() call - if
key in local memory (checking initial and expanded variables) isn't equal
to one in shared buffer than Epiphany code terminates. That never happened
but still only around 25000 passwords are cracked. I tried checking keys
after most costly loop in BF_crypt() - they aren't the same as in shared
buffer. I also tried checking salt after most costly loop - it's not the
same as in shared buffer. This confirms that computation is started before
data is ready - when checking keys after most costly loop there was a
plenty of time for correct data to arrive in shared buffer. Check from host
side seems to ensure that computation is delayed enough. This also explains
why all missed passwords except one are from first half - salt is
unnecessarily copied two times in BF_crypt(). When copied for second bcrypt
instance correct data is in shared buffer while for first instance that's
not always true.
If I do transfers of input data and start array separately it works only if
I check whether start array is transferred correctly. This check is passed
immediately but I guess read by host delays execution on Epiphany side.
But there is something about this scenario that I don't understand. If host
reads inputs from external memory and proceeds with writing start only when
read data is equal to written data how it is possible that Epiphany reads
wrong values from that same location in external memory?
Yaniv, how should I debug this? e-read isn't practical because problem
appears rarely and I can't ensure core is idle when problem is triggered.
> As a workaround, we may try to introduce some padding (e.g. 32 bytes?)
> before the start1 field (and before start2 as well?) But this is not
> perfect, unless Yaniv tells us what the out-of-order transfer window
> size is, if such a concept even exists, and it'd be guaranteed to stay
> not larger than a certain size in further (otherwise compatible)
> revisions of the platform.
>
I added 32 bytes padding - If I read keys from external memory always than
it seems to be working. But if keys are read only when changed than it
cracks around 25000 passwords.
Katja
Content of type "text/html" skipped
View attachment "parallella_e_bcrypt.c" of type "text/x-csrc" (32751 bytes)
View attachment "parallella_bf_fmt.c" of type "text/x-csrc" (14201 bytes)
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.
