lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Sun, 12 Jan 2014 20:44:41 -0500 From: Bill Cox <waywardgeek@...il.com> To: discussions@...sword-hashing.net Subject: Re: [PHC] escrypt memory access speed (Re: [PHC] Reworked KDF available on github for feedback: NOELKDF) On Sun, Jan 12, 2014 at 8:43 AM, Peter Maxwell <peter@...icient.co.uk> wrote: > On 12 January 2014 12:45, Bill Cox <waywardgeek@...il.com> wrote: >> Our CPUs are stuck with tremendous routing delays that just don't >> exist on an ASIC when computing our inner-loops. Any attempt to >> protect passwords with computation-limited inner loops is not going to >> get us very far. >> > > This is probably a very daft question but what's "routing" in this context? > (my hardware knowledge is abysmal) No, it's a natural question. I've done enough chip routers to consider myself an expert, at least when routing with vias or switches. Chip routers lay down metal between ports of components. It's not the same as what CPUs do when they route data from one place to the next. However, I see the same delays in a CPU that I would see when routing metal. If there are a lot of sources for data that need to go to a lot of different places, you get routing delays whether it's due to a long capacitive piece of metal (like my chip routers) or several MUXes in the path (like a CPU or SRAM based FPGA routing). Getting data from point A to point B is not just an important speed issue. In most cases, in my experience, it dominates. Bill
Powered by blists - more mailing lists