Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Fri, 17 May 2013 18:44:53 +0200
From: Katja Malvoni <kmalvoni@...il.com>
To: john-dev@...ts.openwall.com
Subject: Parallella: bcrypt

Hello,

I read the Epiphany documentation and went trough bcrypt implementation.
And now I am thinking about possible approach. At the first sight, it seems
that having one bcrypt instance per a core could work. Since each core has
32 KB of memory divided into 4 memory banks, memory isn't a problem. What
worries me is how big impact will have overhead of writing S-boxes in every
core local memory and will those 16 instances running on 1 GHz processors
be enough to still provide speedup when compared to CPU. If I got it right,
from this sentence (
http://www.adapteva.com/wp-content/uploads/2012/12/epiphany_arch_reference_3.12.12.18.pdfp.
11)

"Each routing link can transfer up to 8 bytes of data on every clock cycle,
allowing 64 bytes of data to flow through every routing node on every clock
cycle, supporting an effective bandwidth of 64 GB/sec at a mesh operating
frequency of 1GHz."

writing S-boxes can be pipelined if first started from the farthest core on
the chip. But what I couldn't find is how to do that in practice. In theory
routing nodes could pass on the data in one cycle and than receive new data
in the next cycle? e_write() described in
http://www.adapteva.com/wp-content/uploads/2013/04/epiphany_sdk_reference.4.13.03.301.pdfdoesn't
provide enough information to make a conclusion but it also doesn't
provide any control on writing process itself. In worst case it would take
16*512 cycles just to transfer S-boxes.

What is the overhead in case that S-boxes are hard coded in the device
code? How much time would e_load() take? I suppose that it should be faster
than using e_write()? I wasn't able to find concrete answers on those
questions.

Should I try this approach of one instance per a core or should I take few
more hours of thinking and think of something better? And am I missing
something in my approach?

Thank you

Katja

[ CONTENT OF TYPE text/html SKIPPED ]

Powered by blists - more mailing lists

Your e-mail address:

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