Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 23 May 2011 03:27:57 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: "excessive partial hash collisions detected" for mskrb5

magnum, Dhiru -

On Sun, May 22, 2011 at 11:47:21PM +0200, magnum wrote:
> True, I have no binary_hash() or get_hash() functions. As far as I can 
> tell, there's just no way to implement them for this format. I think you 
> could say it's implemented as "salt only". After crypt_all() I have a 
> partial decrypt of the input, that will contain known plaintext if the 
> key was correct. This means a get_hash() function has no chance of 
> producing anything that a binary_hash() could produce too.

This sounds right.

> If not, maybe there should be a way to tell john that it should not emit 
> that warning for this format (and possibly some others)? Maybe just the 
> fact that I'm also using fmt_default_binary()?

I think we can add a check for zero binary_size to loader.c - and not
print the warning if so.

Your use of fmt_default_binary() does not tell as much.  This function
simply returns the ASCII ciphertext unmodified, which some format could
be using (including in its hash functions).

You could move from decryption (resulting in known plaintext) to
encryption (of the known plaintext), then you could compare
partial ciphertexts and compute hashes of those.  Moreover, you'd get
rid of salts, for a huge speedup (when there's more than one of these
non-hashes to crack).  But this might not be possible in your specific
case (I haven't checked whether it is).  I think it depends on things
such as block cipher mode used (should be possible for ECB, but not for
chaining modes if plaintext for the preceding blocks is not known).

Disclaimer: I haven't yet looked at your code, sorry.  My response is
about issues of this kind in general.  I think it might be relevant to
Dhiru's work as well.

Thanks,

Alexander

Powered by blists - more mailing lists

Your e-mail address:

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