phc-discussions - Re: [PHC] scripting memory (not so) high

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

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAOLP8p5_K_kdXsWok+Rc3gzBLqVo5edcKTCgOu9xWOscQRnmyA@mail.gmail.com>
Date: Fri, 10 Jan 2014 07:50:45 -0500
From: Bill Cox <waywardgeek@...il.com>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] scripting memory (not so) high

The case of PHP is interesting, but this is of course server-side only, at
least in cases I'm aware of.  I'd love to see a Javascript optimized
memory-hard KDF.  Especially in client-side Javascript, I'd worry less
about timing attacks and focus on memory filling speed and sequential
hardness.

A server running Drupal or any PHP back-end can almost always call a
process in C to do key stretching.  I believe this is a better architecture
anyway.  It's one thing to worry about memory leaking between processes,
and another to worry about leaking to all those unaudited PHP libraries
that get sucked into Drupal or any other popular back end.  I want my key
derivation performed in a process where we can check the code and believe
it is secure.

Any chance we'd get to see a Java translation?

Bill

Content of type "text/html" skipped