Hi all,
does anyone ever made a performance comparison of existing JS scrypt
implementation?
Currently there are those three:
- scrypt-async-js https://github.com/dchest/scrypt-async-js/
- js-scrypt (emscripten compiled) https://github.com/tonyg/js-scrypt
- webgl-scrypt https://github.com/Kukunin
http://jsperf.com/
this is a good tool
On Mon, May 4, 2015 at 2:48 AM, Fabio Pietrosanti (naif) - lists <
li...@infosecurity.ch> wrote:
> Hi all,
>
> does anyone ever made a performance comparison of existing JS scrypt
> implementation?
>
> Currently there are those three:
> - scrypt-async-js ht
On Mon, May 04, 2015 at 11:48:25AM +0200, Fabio Pietrosanti (naif) - lists
wrote:
> Also for upcoming implementation extending scrypt concept, like
> yescrypt/yescrypt-lite it would be very interesting to think how to make
> it faster in the context of the browser/javascript/html5.
Taylor Hornby
On 5/8/15 2:34 AM, Solar Designer wrote:
> On Mon, May 04, 2015 at 11:48:25AM +0200, Fabio Pietrosanti (naif) - lists
> wrote:
>> Also for upcoming implementation extending scrypt concept, like
>> yescrypt/yescrypt-lite it would be very interesting to think how to make
>> it faster in the contex
On Fri, May 08, 2015 at 09:04:47AM +0200, Fabio Pietrosanti (naif) - lists
wrote:
> Do you think that yescrypt-lite in JS will be a reasonable substitute of
> scrypt within a defined amount of time (we're open and interested to
> integrate latests crypto)?
according to someone close to the PHC co
Hi,
Disclosure: I am the designer of yescrypt (building upon Colin Percival's
scrypt, obviously), and I am on the PHC panel (along with many others).
On Fri, May 08, 2015 at 10:34:28AM +0200, stef wrote:
> On Fri, May 08, 2015 at 09:04:47AM +0200, Fabio Pietrosanti (naif) - lists
> wrote:
> > Do
On Fri, May 08, 2015 at 04:27:19PM +0300, Solar Designer wrote:
> On Fri, May 08, 2015 at 10:34:28AM +0200, stef wrote:
> > according to someone close to the PHC compo, yescrypt is rich with
> > side-channels,
>
> Worded like that, it's FUD. It's a fully expected kind of FUD, though.
sorry - alt
On 5/8/15, Solar Designer wrote:
> ...
> The reality is: bcrypt, scrypt, and most PHC finalists use password
> dependent memory lookups, and thus are not cache-timing safe...
> In typical scenarios, this does not matter. In some, it does.
has there been consideration of a processor instruction f
On 5/8/15, coderman wrote:
> ...
> has there been consideration of a processor instruction for hardware
> implementation resistant to timing attacks?
to answer my own question, SIMD like NEON on ARM cores
appears to be plenty sufficient, if you code the rest accommodating.
e.g. performing indepe
coderman (at Saturday, May 9, 2015, 3:56:06 AM):
>> The reality is: bcrypt, scrypt, and most PHC finalists use password
>> dependent memory lookups, and thus are not cache-timing safe...
>> In typical scenarios, this does not matter. In some, it does.
> has there been consideration of a proces
On 5/9/15, Krisztián Pintér wrote:
> ... create a huge block of pseudorandom data
> derived from the password, and then use pseudorandom indexing to
> access the data, also based on the password...
> this second phase is what we are talking about here. it is essential
> to the algorithm, and can n
coderman (at Saturday, May 9, 2015, 12:49:22 PM):
>> ... use pseudorandom indexing to access the data, also based on the
>> password ... it is essential to the algorithm, and can not be
>> written in a side channel safe way.
> even paired with a separate pseudo-random sequence?
> both executed i
On 5/9/15, Krisztián Pintér wrote:
> ...
> there is another option, using a random permutation on the memory
> addresses. a permutation destroys all information except equality
> (accessing the same address twice). however, you need to apply the
> same permutation to the initial writing phase, whi
13 matches
Mail list logo
