Date: Thu, 13 Mar 2014 22:47:54 +0000
From: Peter Maxwell <peter@...icient.co.uk>
To: "discussions@...sword-hashing.net" <discussions@...sword-hashing.net>
Subject: Re: [PHC] "Why I Don't Recommend Scrypt"

On 13 March 2014 22:20, Bill Cox <waywardgeek@...il.com> wrote:

> On Thu, Mar 13, 2014 at 5:58 PM, Peter Maxwell <peter@...icient.co.uk>
> wrote:
> > On 13 March 2014 16:53, Bill Cox <waywardgeek@...il.com> wrote:
> >>
> >> I think the NSA would prefer that we continue using Bcrypt and not
> >> switch to Scrypt.  Let's assume they have liquid nitrogen cooled ASICs
> >> with 1024 Bcrypt hashing cores running say 2X faster than the fastest
> >> CPU on each core.  If I understand correctly, Bcrypt only requires
> >> 4KiB of memory, so integrating 1024 of them is not unreasonable.  Per
> >> board, let's guess they have 64 chips, and maybe 1024 boards, for a
> >> factor of 134 million-to-1 compute power vs a high-end PC.
> >>
> >> Bcrypt is safe against all those GPU crackers who don't have the money
> >> to build what the NSA can, so bcrypt does a good job protecting the
> >> public, while allowing government sized organizations the ability to
> >> crack passwords far more effectively.  I think that's the NSA's
> >> prefered sweet spot for the public.
> >
> >
> > Sorry for resurrecting an earlier incarnation of this thread but wanted
> to
> > pose the question: are we actually worried about people using ASICs for
> > password cracking?
>
> It depends.  For military strength security, I have to say yes, and
> I'm hoping the PHC winner cares about that case.  I'd say it is very
> likely that China has an ASIC based password cracking center.  For
> most people, likely even including large companies like Apple and
> Target, probably not.
>

​The comparative number of deployed instances requiring "military strength"
security - however that is defined - is likely to be very small compared to
run-of-the-mill deployments.  My personal feelings are that the first
priority is trying to optimize for the most common uses and assume the
parameters can be ramped-up for the paranoid.​




>
> > Have ASICs been used for password cracking to date?
>
> Yes.  I notice no one replies to threads where I get specific about
> that, so I'm going to stop doing that.
>

​Apologies if I've missed these items, I've not had the time to read
through every message on this list.




>
> > If the NSA, GCHQ, et al. are targeting someone, do they not already have
> > numerous measures to compromise hosts other than password cracking?
>
> After reading so many Snowden revelations, I guess it's pretty clear they
> do.
>
> I hope they aren't wasting my tax dollars, but if the NSA has
> legitimate needs for cracking passwords that other's can't, then they
> would be doing a very poor job without an ASIC based cracking center.
>

​The point is that for the vast majority of use-cases, worrying about the
NSA/GCHQ is pointless -- it's a lost-cause and the users in those
situations don't tend to care.  What they do care about is if a load of
their accounts are compromised just because one online service they use is
hacked.



>
> Another reason to focus on ASICs is that you defend against all
> architectures when you defend against ASICs.  Commercial chips with
> many CPU cores (say 1024 like my example) capable of hashing Bcrypt as
> fast per core as my Intel Core i7 may be in our near future.  With
> that event, Bcrypt security will drop tremendously.  Scrypt will fare
> far better.
>


​I agree that massively scalar CPUs are on the horizon (fairly sure I'd
read an article a few years back about Intel doing this?).  ​It does
somewhat throw a spanner in the works in terms of current assumptions
though: if general purpose CPUs end up having thousands of cores, it makes
more sense to hammer compute tasks rather than memory.

I thought bcrypt was secure(ish) against GPUs but not ASICs?




>
> Given a chance to develop a new PHS, I would hope solutions will be
> found that defend against ASICs, GPUs, and FPGAs to varying extents,
> without giving up on any of them.
>
>
​In an ideal world, yes.  However, I'm getting the distinct impression that
to defend against ASICs imposes utterly unrealistic resource requirements
on the defender, to the extent that it would hinder adoption of the PHS.​
 Is it not worth specifying default parameters at a more realistic level
and explicitly stating the risks?  (with the option for higher security by
increasing parameters in cases when it's required)

Content of type "text/html" skipped

Powered by blists - more mailing lists