Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110604223303.GC6422@openwall.com>
Date: Sun, 5 Jun 2011 02:33:03 +0400
From: Solar Designer <solar@...nwall.com>
To: crypt-dev@...ts.openwall.com
Subject: Re: Yuri's Status Report - #3 of 15

On Tue, May 31, 2011 at 01:13:38AM -0300, Yuri Gonzaga wrote:
>       - Installation of Pico E-101 files for Linux
>          - I am using an Ubuntu 10.4 64-bit guest OS on VMware Workstation 7
>          - I had some trouble to put everything to work. Everytime the demo
>          example tried to communicate to the board it complained the
> device was busy.
>          So, after several attempts, I figured out a workaround: a
> process called
>          usbtest was locking the device. Then, before running any
> application, I have
>          to call "sudo rmmod usbtest". It solved!

You mean a kernel module (not "process").  Thank you for documenting this.

>          - Unfortunately, I spent so much time to set the VM and run the
>          demo example properly that I couldn't start to interface my own
>          applications.

OK.  Perhaps you made progress at that since then?

>       - Priorities:
>       - Run bflike on the board
>          - Report real results
>             - Real result means operation time?

Make sure that it works reliably - producing the correct results
reliably (without a single error) when run for a long time.  I think
that you'll need to bump up Nrounds to a much higher value in order not
to saturate your USB link.  Then have the host send test inputs, and
verify the test outputs (vs. those computed on the CPU).  For just one
core, your CPU should be fast enough to compute the expected results in
time (to compare FPGA's results against).

And, yes, I am also interested in actual speed data.  But correct
operation is to be verified first.

>          - Interface to the board from software (Linux)
>             - Following the demo example, there are a lot of stuff to
>             understand in software and hardware sides
>                - Hardware side: SPI interface, FIFOs and anything else
>                needed to stablish communication using Cypress USB
> device (used on e101 board)

Isn't this hidden behind a software abstraction layer when you use
Pico's driver?  Anyway, it is good to be familiar with what goes on
under the hood.

>                - Software side: api initialization, write and read routines
>             - Revisit JtR to work with bcrypt on the board
>             - Actually, I revisited the code to found the right point to
>             call hardware.
>             - So, I need to finish this task

Sounds good.

> Anything else?

See my replies to your messages on the separate topics.

Thanks,

Alexander

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.