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: <CA+aY-u5somVoqMCApNaWkRgBeKC987KYTLbC9bf1bWfgxkqzKA@mail.gmail.com>
Date: Fri, 10 Jan 2014 09:35:10 +0000
From: Peter Maxwell <peter@...icient.co.uk>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] scripting memory (not so) high

On 10 January 2014 04:32, Solar Designer <solar@...nwall.com> wrote:

> Hi,
>
> Attached is a PHP script implementing a sequential memory-hard KDF.
> At this point, this is primarily an experiment to see how much memory
> can be used in this fashion from scripting languages (with PHP being the
> primary target) while maintaining run times suitable for web apps' user
> authentication.
>

There's also going to be an absolute limit to how much memory can be used.
 In many of my own setups the php memory limit is sitting somewhere between
64Mb and 128Mb, although sometimes a fair bit higher, e.g. I think Magento
tends to need nearer 512Mb irrc.

However, and this is the caveat, there's going to be a significant
proportion of that already used.  So for a portable implementation of a
memory-hard KDF we may be talking ~15Mb that can actually be used.

In terms of performance, PHP will be not too bad but there is always the
option of coding the scheme as an extension, i.e. in C.  I'm not sure what
the score is going to be with other scripting languages or if people are
intending on having things run on mobile devices.

Content of type "text/html" skipped