[Cryptech Tech] trng ready for play

[Bernd Paysan]

Am Samstag, 18. Oktober 2014, 08:36:05 schrieb Joachim Strömbergson:
> Aloha!
> 
> Bernd Paysan wrote:
> > Yes, but you need quite expensive interfaces like PCI express to
> > actually get the data out at rates which are faster than CPU cores
> > creating randomness themselves.
> 
> I'm actually not that worried about price at 10+ Gbps speeds, anybody
> that have those demands probably has the budget for it.

Haha, maybe ;-).

> PCIe is one
> option. Network interfaces (10GbE, 40GbEa etc) are another. But we are
> talking about boards in 1kUSD - 10kUSD range if you want to buy a ready
> made board. This one I really liked:
> 
> http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&CategoryN
> o=158&No=856
> 
> PCIex8 and a big FPGA with plenty of external memory to run both
> HW-accelerators and a complete CPU with SW for control.

Yes, that's the sort of board I'd use to develop a high-speed net2o-mostly-in-
hardware protocol stack.

> One of the later NetFPGA boards can provide both PCIe as well as
> flexible high performance network I/O via SFP+ cages.
> 
> http://netfpga.org/2014/#/
> 
> What I think is an important aspect of the Cryptech project is the
> ability to scale to meet different demands. That is why i stress that
> the design we have in the TRNG allows us to scale from low cost but
> still good performance up to basically arbitrarily high speeds.
> 
> How would you do scaling to Tbps performance using SHA-3/Keccak as a
> PRNG? - Tree hash based? Or multiple instances seeded with their own seed?

Multiple instances seeded with their own seed.  Actually, when you generate 
random numbers, the deterministic scalability of ChaCha is not needed - you 
only need that for cryptography (and there, you'd need scalable authentication 
to scale as well - e.g. tree hash based.  The issue with a stream cipher is 
that you need another run over the data to get the authentication, unless, of 
course, you are only interested in random numbers).

> > I'd love to have a Keccak primitive in a CPU core with 1 cycle per
> > round, giving about 5 bytes per cycle...
> 
> Which would be slower than running ChaCha in SW for long sequences. ;-)

Well, the independently seeded per-core generators would still allow each core 
to emit 5 bytes per cycle - 0.2 cycle per byte, considerably faster than 
ChaCha in software.  ChaCha in hardware is not much worse than Keccak, with 
3.2 bytes per cycle with a single instance, but easier to scale up.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.cryptech.is/archives/tech/attachments/20141019/613f9f5b/attachment.sig>