Yuri's Status Report - #10 of 15

[Yuri Gonzaga]

Hello,

The interfacing thing is still not working.
When I was able to put the Picoboard to work properly, I used the tool
PicoUtil to create a project to Microsoft's Visual C++.
It provides a wizard to auto generate a ready-to-work project in such a way
I don't have to care about dependencies, DLLs, includes, ...
This is good and easy!

So, when I moved to cygwin I had a problem, as reported in the last weekly
report.
I have gone through the 3 possible solutions but couldn't find a solution.
Actually, I figured out the Picoboard's library has a file called
loadDll.cpp, which should load them in run time and works properly in the
Visual C++ approach.
However, I couldn't put it to work in cygwin.
I tried 2 ways: Load the DLL in the cygwin file system or in the host
windows file system.
In the first one, the function that load the DLL in the code returns null
and shows an error message saying that was not possible to load the DLL.
In the second one, apparently it passes this point but it exits the program
and doesn't present any message. I don't know why...

Is really necessary to keep trying this approach?
David already told there are other board that work on Linux similarly to
windows approach.
Then, I think this task of mixing Windows and cygwin could waste time with
an useless thing.
Wouldn't I interface using Linux ready board with JtR?
I think this time could br better used to multiple cores, for example,
instead of entering those details beyond our scope.
What do you think?

- Accomplishment

- Midterm evalution
- Priorites
- JtR Integration to eksblofish's loop
- using cygwin (?)
- multiple cores

I want to say I know I am partially absent once I was doing only the weekly
status report.
Due to a tight deadline to do my qualification step in the Master's study,
it is happen.
But I promise I will stay more present again.


Best Regards,

---
Yuri Gonzaga Gonçalves da Costa

[Solar Designer]

Hi Yuri -

Thank you for the status update.

Post by Yuri Gonzaga
The interfacing thing is still not working.

...

Post by Yuri Gonzaga
Is really necessary to keep trying this approach?

This is not entirely necessary, but it would be nice to have it working.

Post by Yuri Gonzaga
David already told there are other board that work on Linux similarly to
windows approach.
Then, I think this task of mixing Windows and cygwin could waste time with
an useless thing.

Yes, but we need you to start interfacing real program code (not just
test programs) to FPGA crypto cores.

Post by Yuri Gonzaga
Wouldn't I interface using Linux ready board with JtR?

Yes, this will be more important than the Windows thing.

Post by Yuri Gonzaga
I think this time could br better used to multiple cores, for example,
instead of entering those details beyond our scope.
What do you think?

You're right. Are you able to start implementing multiple cores without
having basic interfacing (to one core) working first?

I expect that David will setup a Linux system with a suitable FPGA board
and working drivers for you to access remotely. But this is not ready
yet. If you're able to proceed with work on multiple cores without
being able to actually test this, or with your own tests only (no JtR
integration yet), then please do that.

Thanks,

Alexander

[Yuri Gonzaga]

Post by Solar Designer

Post by Yuri Gonzaga
Is really necessary to keep trying this approach?

This is not entirely necessary, but it would be nice to have it working.

We will have communication working between JtR and multiple cores.
The approach that I don't want to keep trying is the mix between Windows and
Linux.

Are you able to start implementing multiple cores without

Post by Solar Designer
having basic interfacing (to one core) working first?

(...)

If you're able to proceed with work on multiple cores without

Post by Solar Designer
being able to actually test this, or with your own tests only (no JtR
integration yet), then please do that.

Yes, I have already started with this.
David provided me the documentation about M501 board.
So, I will use it to do the manager module that will organize data transport
between the multiple cores and host.
When it can work in my own tests, we can pass to do that in the JtR.

David sent me a hello world example with the documentation, which I couldn't
run.
I am getting some errors. I reported them to him in order to overcome this
problem.

Alexander, Could you start to guide me in how the JtR works with multiple
hashes?

Thanks.

---
Yuri Gonzaga Gonçalves da Costa

[Solar Designer]

Yuri -

Post by Yuri Gonzaga
We will have communication working between JtR and multiple cores.
The approach that I don't want to keep trying is the mix between Windows and
Linux.

Cygwin is not Linux, but I think I get what you mean. I was unhappy
about us doing any development on Windows at all. ;-)

Post by Yuri Gonzaga
David provided me the documentation about M501 board.
So, I will use it to do the manager module that will organize data transport
between the multiple cores and host.
When it can work in my own tests, we can pass to do that in the JtR.

Sounds fine.

Post by Yuri Gonzaga
David sent me a hello world example with the documentation, which I couldn't
run.
I am getting some errors. I reported them to him in order to overcome this
problem.

Please keep me CC'ed on any such e-mails.

Post by Yuri Gonzaga
Alexander, Could you start to guide me in how the JtR works with multiple
hashes?

Yes. Do you have specific questions?

The interface is described in formats.h, and you may look at dummy.c for
a sample. If anything specific is unclear, please ask. If you don't
have specific questions yet don't have an understanding of how this
works in general, this will be much harder to explain - yet I'll try to
(maybe via IM). Please let me know either way.

Thanks,

Alexander

[Solar Designer]

Yuri -

Post by Yuri Gonzaga
Alexander, Could you start to guide me in how the JtR works with multiple
hashes?

I decided to simplify the task for you, so I created a JtR patch that
adds the proper hooks specific to moving the Eksblowfish costly loop to
multiple FPGA cores (while keeping the rest on CPU). This is
john-1.7.8-fpga-hooks.diff.gz, which I uploaded to:

http://openwall.info/wiki/john/FPGA#VII-JtR-integration

Apply it like this:

http://openwall.info/wiki/john/how-to-extract-tarballs-and-apply-patches

With this patch, BF_N in BF_std.h is the number of cores. Currently, it
is set to 10, and the code in BF_std.c simply iterates over all would-be
cores. What you need to do is replace one of three loops in
BF_std_crypt() (with the patch applied) with your own code interfacing
to the FPGA.

For performance measurements (vs. CPU), please note that this
-fpga-hooks patch has a performance impact - it drops certain
CPU-specific optimizations and it makes changes resulting in more
complicated addressing modes being used on the CPU. These changes were
needed to separate out the loop to be replaced. Once you do have this
working with an FPGA, you'd need to compare its performance against that
of the original JtR (without the patch).

Also, for simplicity this implements the CPU and FPGA portions of work
sequentially, even though when we have a large number of cores in the
FPGA it could make sense to move to an asynchronous design and also to
run multiple threads on the CPU. But that's something we might revisit
much later (or not).

Please let me know if you have any questions.

Thanks,

Alexander