[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+EaD-ZqV_XQzVtt5wKiGQFi=mYTX81AOTBvxF4JiEeDu=yCTg@mail.gmail.com>
Date: Fri, 9 Aug 2013 16:10:42 +0200
From: Katja Malvoni <kmalvoni@...il.com>
To: john-dev@...ts.openwall.com
Subject: Re: Parallella: bcrypt
On Fri, Aug 9, 2013 at 3:38 PM, Solar Designer <solar@...nwall.com> wrote:
> Katja,
>
> On Mon, Aug 05, 2013 at 07:19:07PM +0200, Katja Malvoni wrote:
> > I run self test until it stalled. It happens in while loop on host side.
> > One of the cores (first time it was 14, second time 13, third time 15)
> > stalls somewhere before do while loop. I checked shared DRAM, 16 is
> written
> > in memory for both start arrays for that specific core so conditions in
> > while loops are true but it never reaches BF_crypt() call nor resetting
> > start flags. I also added writing different number instead of result
> after
> > every line in main on Epiphany side - core that stalls never reached
> first
> > write that was before do while loop. Only zeroes were in memory for
> result
> > and core_done flag for that core. All the other cores except the one that
> > stalls work correct. And it happens only in first cryp_all call. So far
> it
> > never happened in the middle of computation. It seems as that one core
> > never starts computation.
>
> This is a separate problem from the other reliability problem you had
> reported (sometimes cracking one password less than expected), right?
> So we've got two reliability problems in the current code, right?
>
> What do you intend to do about these?
>
Yes, there are two problems. For stalling problem - I'll run it until it
stalls and try to figure out where exactly does it happen. When I identify
where it stalls I think I'll know is it because reset fails or it's
something else. Also, I'll try resetting cores one by one using
e_reset_core() instead of e_reset_system().
On Fri, Aug 9, 2013 at 3:41 PM, Solar Designer <solar@...nwall.com> wrote:
> I think it'll be easier for you to debug this if you create a program
> that will verify each and every computed bcrypt hash. (As discussed
> before, this is not what happens when we're cracking passwords.
> Although we do use every bcrypt computation results, most failures can
> go undetected.)
>
> With a 100%-verifying program, you should be able to trigger the issue
> much more quickly and more reliably, so you'd be able to test different
> theories as to its cause quicker too.
>
OK, I'll do that.
Katja
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.
