Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 10 Feb 2013 20:33:07 -0800
From: Tavis Ormandy <taviso@...xchg8b.com>
To: john-users@...ts.openwall.com
Subject: Re: Cracking SHA1 with some knowledge of password

Lex Par <ziptied@...il.com> wrote:

> Theoretically, if I were to create a function the pads an input (ie
> password) with 120 bytes, then hashes the 120+password input to produce
> the hash, this would not be crackable via the 128 byte limit (since our
> hard limit not using the optimizations is somewhere in the 90~)?
> 
> On Fri, Feb 8, 2013 at 5:35 PM, jfoug <jfoug@....net>
> wrote:
> 
> > From: Lex Par [mailto:ziptied@...il.com]
> > > This might be a silly question, but why is there a 55 byte max?
> >
> >
> > Not a silly question at all.
> >
> > the short answer: the 19 byte limit (in the format I provided), is due
> > to requirements from the optimizations that are being used.

Just to add to Jim's great answer, I limit the size in raw-sha1-ng to 15
bytes because then I can treat all the input state as if it is a DQWORD (a
native data type that can be handled very quickly by the CPU).

This makes it super fast in the common case, but not suitable for very long
passwords. The more input you want handled, the more optimisations we have
to turn off, so it's better to cap it as brutally as you can :-)

Tavis.

-- 
-------------------------------------
taviso@...xchg8b.com | pgp encrypted mail preferred
-------------------------------------------------------

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.