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.