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: <CALW8-7JjZYeCQMh4QQ6paq9WEQ1E7__PydH1y_VNChi4bJLX=g@mail.gmail.com>
Date: Mon, 25 Aug 2014 12:58:22 +0400
From: Dmitry Khovratovich <khovratovich@...il.com>
To: "discussions@...sword-hashing.net" <discussions@...sword-hashing.net>
Subject: Re: Tradeoff cryptanalysis of password hashing schemes

As there are questions on this mailing list on how we got our energy & size
estimates, here is a short insight.

A naive (no tradeoff) implementation of a password hashing scheme on ASIC
with up to a GByte of RAM would use only a tiny portion of memory at every
step. When the memory is not used, it still consumes power to sustain the
state values. An energy-efficient adversary would use the memory that
minimizes the total energy spent: for reading, writing, activating, etc.
There exist low-power static RAM designs, of which the following two are
interesting (we used [1]):
[1] 850 MHz, 65nm design with retention mode leakage 0.1 mW (10^{-4} Watt )
per MBit and active energy (read/write) 0.0001 J (10^-4) per GBit.
[2] 333 MHz, 65nm design with retention mode leakage 0.00015 mW (10^{-7}
Watt ) per MBit and active energy (read/write) 0.0004 J (10^-3.5) per GBit.

1 GByte of [1] occupies 12,000 mm^2, and of [2] -- 5,000 mm^2. This is
certainly larger than the current CPU/GPU chip sizes (500-700 mm^2 for
recent Intel and nVidia designs), but comparable to largest CMOS sensors
(40,000 mm^2 and more) and  certainly smaller than a single wafer. In fact,
our own tradeoffs do not explicitly require all the memory being on a
single chip, but it should have reasonable latency (<5 cycles).

Quite clear, for different schemes and different tradeoffs an adversary
would employ different types of RAM, maybe more energy-efficient. So our
estimates give an upper bound. If you want to count the energy consumption
of your favorite SRAM or DRAM design in some particular tradeoffs, you're
welcome to submit the power numbers.

[1] http://dx.doi.org/10.1109/JSSC.2012.2191316
[2] http://dx.doi.org/10.1109/NVSMW.2008.34

Best regards,
Dmitry


On Wed, Aug 6, 2014 at 9:31 PM, Dmitry Khovratovich <khovratovich@...il.com>
wrote:

> Hi all,
>
> here is the link to the slides of the talk I have just given at
> PasswordsCon'14. It investigates time-memory tradeoffs for PHC candidates
> Catena, Lyra2, and Argon, and estimates the energy cost per password on an
> optimal ASIC implementation with full or reduced memory.
>
> https://www.cryptolux.org/images/5/57/Tradeoffs.pdf
>
> Additional comment: It is a standard practice in the crypto community to
> give explicit security claims for the recommended parameter sets so that
> cryptanalysts could easily identify the primary targets. Many PHC
> candidates do not follow this rule by not only missing these claims but
> also concealing the recommended parameters. As a result, cryptanalysts like
> me spend valuable time attacking wrong sets or spreading the attention over
> multiple targets.
>
> Remember: third-party cryptanalysis increases the confidence in your
> design, not decreases it (unless it is badly broken). Analysis of a 5%-part
> of your submission (one of 20 possible parameter sets) is little better
> than no analysis at all. It is also worth mentioning that to make fair
> comparison of candidates, benchmarks and performance discussion in general
> should cover recommended parameter sets only.
> --
> Best regards,
> Dmitry Khovratovich
>



-- 
Best regards,
Dmitry Khovratovich

Content of type "text/html" skipped

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ