Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 23 Sep 2013 23:32:31 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: Rafael's weekly report #14

Rafael,

Please don't forget to provide your final mandatory weekly report today.

On Mon, Sep 23, 2013 at 01:00:41PM +0200, Rafael Waldo Delgado Doblas wrote:
> 2013/9/21 Solar Designer <solar@...nwall.com>
> > 3. Somehow the performance is a lot worse than it used to be.  With a
> > default build, I got only around 300 h/s; we used to have ~1300 h/s.
> > What is causing this slowdown (some compiler flags set for debugging?
> > some code change?) and can you please correct it?
> 
> Mmm, I checked it and it worked fine to me. Are you compiling with the flag
> EPIPHANY_DEBUG?

I think not.  I compiled a clean "git clone" tree with no changes.  What
performance does it give you?

> > 5. You're still not using any macros in the .S file.  Do you have some
> > non-committed version that does use macros (but is buggy, as you
> > mentioned)?  Is the committed asm code supposed to be in a working
> > state, then (but is just slow)?
> 
> Yes it is. As GSoC it's about to finish I commited a working version but I
> have another one with macros but still buggy.

Where is this other version?  May I take a look?  You attached some
version to this message (that I am replying to), but it does not use
macros and it is unclear what you attached it for.

Regarding using autotools to build the Epiphany code from Makefile:

> > I'm sorry we didn't get around to helping you on this sub-task.
> > I think it could be as simple as having some make rules pre-written in
> > Makefile.am, but I am not sure.  I am not familiar with autotools.
> 
> It's ok, after I checked autotools doc, I couldn't see how to do it then
> maybe it's not possible.

Actually, I think it's possible and most likely trivial.  It's just that
I am not familiar with autotools.  I guess I could figure this out, but
so could you.

Have you tried simply including the right make rules in Makefile.am,
don't they propagate to the final Makefile verbatim?

Like I said, this is unimportant at this time, though.

> > BTW, have you fixed your host side C code not to segfault when the
> > Epiphany code hasn't been compiled?  Can you make it print a reasonable
> > error message, please?
> 
> Mmm, I have added this. Doesn't it worked? I will check it ASAP.
> 
> 	strcpy(fullpath, cgminer_path);
> 	strcat(fullpath, "epiphany-scrypt.srec");
> 	if (e_load_group(fullpath, dev, 0, 0, rows, cols, E_FALSE) == E_ERR) {
> 		applog(LOG_ERR, "Error: Could not load epiphany-scrypt.srec on Epiphany.");
> 		applog(LOG_ERR, "       Is epiphany-scrypt.srec in cgminer directory?.");
> 		return false;
> 	}

I did not know/notice that you added this.  I hope it works, but you do
need to test it and report whether it does work.

> > > > 3. Move to the new task related with jumbo.
> >
> > Actually, I thought that this new task would be more of a "filler" for
> > when you're "idle" waiting for my feedback on your current main task, so
> > you would not exactly "move" to it after finishing the current task, but
> > rather you'd work on both.
> >
> > Anyhow, what's the current status on it?
> 
> Hello, I have implemented the interleaving of 2 and I copy get_hash* and
> binary_hash* functions from lotus5 (changing crypt_key[] array size). I
> have doubts about get_hash* and binary_hash* functions why are there 7 and
> what do they do?.

Oh, I thought you'd merely provide a status update in response to this
message, leaving the actual discussion to the proper thread ("reply" to
the message "dominosec optimization".

Anyway, regarding the 7 get_hash* and binary_hash* functions, they're
for 7 different hash table sizes, where a given size is used depending
on the number of hashes loaded for cracking (for a given salt, if
applicable).  See the comments in formats.h, inside the definition of
"struct fmt_methods".  Also see PASSWORD_HASH_* in params.h, and the
corresponding arrays in params.c.  (I thought you knew this already,
from your work on an scrypt format for JtR.)

Thanks,

Alexander

Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ