[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20131125073857.GA27351@openwall.com>
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
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
