Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 25 Nov 2013 11:38:57 +0400
From: Solar Designer <solar@...nwall.com>
To: crypt-dev@...ts.openwall.com
Subject: Re: scrypt TMTO defeater

On Wed, Nov 20, 2013 at 09:57:57AM +0400, Solar Designer wrote:
> scrypt ircmaxell TMTO1 = 5, TMTO2 = 2:
> B' = 24efce90
> t_cost = 978
> m_cost = 180 elements + 256 indices (363 alloc + 256 ptrs) + 512 counters
> 
> Assuming element size 1024 bytes (which it is in scrypt with r=8) and
> 32-bit pointers and integers, and including even the memory allocation
> fragmentation overhead (which is avoidable), we get:
> 
> (180*1024 + (363+256+512)*4) / (256*1024) = 72% memory usage
> 978/512 = 191% CPU time usage (counting only BlockMix invocations)

In the memory usage calculation above, I forgot to account for stack
usage by possible recursive calls to getVrec():

	uint32_t getVrec(uint32_t i, uint32_t j)
	{
[...]
		return Y ^ getVrec(ii, jj);

The good news (for my analysis) is that this recursion was easily
avoidable - which I did in the code revision attached to this message.
The program output remained exactly the same, and the memory usage
calculation above is now valid.

Alexander

View attachment "sim-tmto.c" of type "text/x-c" (3315 bytes)

Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ