Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 05 Aug 2012 17:16:00 +0200
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Use of clear_keys() for SIMD buffer clearing (was: Re: 
 opencl_mscash2_fmt.c: clear_keys())

On 2012-07-12 17:28, jfoug wrote:
> Actually, some of the 'fat' SSE formats should use clear_keys().  The logic
> I was using to reset the keyspace on dynamic was mimicked from other
> formats.  Within set_key, if index is 0, they memset buffers.  This logic
> should be put into clear_keys().

I just tried this in hmacMD5 and mssql-old and it does not work. I see
clear_keys is not called before first batch of keys (maybe we should
change that?) so I copied the hmac memsets to init() too but this did
not fix it. It appears clear_keys() is not called when I expected it -
perhaps a self-test only problem? Or is it not supposed to be called any
time one set of keys are done with (and only then)?

Some debug prints:

Benchmarking: HMAC MD5 [128/128 SSE2 intrinsics 12x]...
set_salt()
set_key(0)
crypt_all(1)
set_salt()
set_key(1)
crypt_all(2)
set_key(1)
set_salt()
set_key(2)
crypt_all(3)
...about a million lines snipped...
set_salt()
crypt_all(12)
set_salt()
crypt_all(12)
set_salt()
crypt_all(12)
set_salt()
set_salt() <- Twice?
set_key(0) <- We got a new key(0) without clear_keys()
crypt_all(1)
FAILED (cmp_one(0))

If the redundant set_salt() call had been a clear_keys(), it just might
have worked :)


Benchmarking: MS SQL SHA-1 [128/128 SSE2 intrinsics 8x]...
set_salt()
set_key(0)
crypt_all(1)
set_salt()
set_key(1)
crypt_all(2)
set_key(1) <- We got a new key(1) without clear_keys()
set_salt()
set_key(2)
crypt_all(3)
set_salt()
set_key(3)
crypt_all(4)
set_key(3) <- We got a new key(3) without clear_keys()
clear_keys() <- Why now? This will erase the unprocessed key(3)
set_salt()
set_key(4)
crypt_all(5)
Segmentation fault

(It segfaults because lengths was destroyed, or something like that)

magnum

Powered by blists - more mailing lists

Your e-mail address:

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