Date: Fri, 23 Aug 2013 02:46:00 +0530 From: Sayantan Datta <std2048@...il.com> To: john-dev@...ts.openwall.com Subject: Re: *pcount type should be uint64_t On Fri, Aug 23, 2013 at 1:33 AM, Solar Designer <solar@...nwall.com> wrote: > I second magnum's comments on this. 2G+ keys per call sounds excessive > for current GPUs, in terms of kernel invocation duration. Perhaps it's > a side-effect of how you're doing things, and you need to avoid that? > > You may calculate how large *pcount would be, and if it'd exceed a > certain threshold (which you'd keep below 2G), then reduce the portion > of mask processed on GPU until the would be *pcount value is sane. > For raw-md5 kernel, kernel run time is around 700ms for 7970 with 2.8G keys per crypt. For raw-sha1 kernel, run time is 2.5s with 5.5G keys per crypt, but this config seems to give most optimal performance. For md5 kernel c/s report seems to be correct but for raw-sha1 it is incorrect. Maybe no information is lost in case of 2.8G (< 2^32) keys but some bits are lost in case of 5.5G(> 2^32) keys. Since raw-sha1 kernel kernel run time seems bit high , I will reduce kpc for raw-sha1, which should give correct c/s output. For other hashes especially raw-md4 I think we might be able to limit run-time to less than 1s even with 4G+ keys. So we are pretty much on the edge of 32bit limit for current generation GPUs. Maybe the change would be required for next or next to next generation of GPUs. Regards, Sayantan Content of type "text/html" skipped
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.