Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 19 Jul 2012 10:45:54 -0500
From: "jfoug" <jfoug@....net>
To: <john-dev@...ts.openwall.com>
Subject: RE: fast pbkdf2-sha1 OpenCL kernel

My pbkdf2 code

>On Thurs, July 19, 2012 10:12 AM Dhiru Kholia wrote:
>
>I am looking for a fast pbkdf2-sha1 OpenCL kernel which can handle
>passwords of length 20, salt size 20 and can output key length of 66.
>
>1) Can the wpa-psk kernel work with password size of 20? If not, can it
>be modified to do the same? I need this for ODF kernel.
>
>2) Currently the output of wpa-psk kernel is 32 bytes, can this be
>increased to 64 + 2 (= 66)? I need this for ZIP AES kernel.
>
>Jim, does you pbkdf2 kernel meet these requirements? Can it be modified
>to do so?

I am not sure exactly what code you are referring to.  If it is the code in
http://openwall.info/wiki/john/MSCash2_simple_code then it can easily handle
20 bytes of salt, and 20 byte of hash.

I am not sure how the algorithm would output 66 bytes of key, from a 32 byte
hash function.  If it was SHA512, then yes, 66 bytes, but not sure if pbkdf2
can give more key bytes than the base crypt type.   The 'kernel' I have
done, should allow passwords up to the size of the crypt (i.e. the size of
the ipad/opad values).  Any longer and 2 loops have to be done, and salt
gets a 2 appended to it.  The salt should stay 55-4 bytes (for 64 byte block
hashes or 111-4 for 128 byte block hashes).

This was one I recently did for sha256, but with few changes, pretty much
any 'standard' crypt type can be used.  This one does FULL width digest.
The length could be passed in, to produce a narrower final digest.  But
since you were asking for a 66 byte sha1 digest, I am NOT sure how you will
get that.

#ifndef SHA256_CBLOCK 
#define SHA256_CBLOCK 64
#endif
#ifndef SHA256_DIGEST_LENGTH
#define SHA256_DIGEST_LENGTH 32
#endif

static void pbkdf2(unsigned char *K, int KL, unsigned char *S, int SL, int
R, ARCH_WORD_32 *dgst)
{
	SHA256_CTX ctx, tmp_ctx1, tmp_ctx2;
	unsigned char ipad[SHA256_CBLOCK], opad[SHA256_CBLOCK],
tmp_hash[SHA256_DIGEST_LENGTH];
	unsigned i, j;
 
	memset(ipad, 0x36, SHA256_CBLOCK);
	memset(opad, 0x5C, SHA256_CBLOCK);
 
	for(i = 0; i < KL; i++) {
		ipad[i] ^= K[i];
		opad[i] ^= K[i];
	}
 
	SHA256_Init(&ctx);
	SHA256_Update(&ctx, ipad, SHA256_CBLOCK);
	// save off the first 1/2 of the ipad hash.  We will NEVER recompute
this
	// again, during the rounds, but reuse it. Saves 1/4 the SHA256's
	memcpy(&tmp_ctx1, &ctx, sizeof(SHA256_CTX));
	SHA256_Update(&ctx, S, SL);
	// this BE 1 appended to the salt, allows us to do passwords up
	// to and including 64 bytes long.  If we wanted longer passwords,
	// then we would have to call the HMAC multiple times (with the
	// rounds between, but each chunk of password we would use a larger
	// BE number appended to the salt. The first roung (64 byte pw), and
	// we simply append the first number (0001 in BE)
	SHA256_Update(&ctx, "\x0\x0\x0\x1", 4);
	SHA256_Final(tmp_hash, &ctx);

	SHA256_Init(&ctx);
 	SHA256_Update(&ctx, opad, SHA256_CBLOCK);
	// save off the first 1/2 of the opad hash.  We will NEVER recompute
this
	// again, during the rounds, but reuse it. Saves 1/4 the SHA256's
 	memcpy(&tmp_ctx2, &ctx, sizeof(SHA256_CTX));
 	SHA256_Update(&ctx, tmp_hash, SHA256_DIGEST_LENGTH);
	SHA256_Final(tmp_hash, &ctx);
 
	memcpy(dgst, tmp_hash, SHA256_DIGEST_LENGTH);
 
	for(i = 1; i < R; i++) {
		memcpy(&ctx, &tmp_ctx1, sizeof(SHA256_CTX));
		SHA256_Update(&ctx, tmp_hash, SHA256_DIGEST_LENGTH);
		SHA256_Final(tmp_hash, &ctx);

		memcpy(&ctx, &tmp_ctx2, sizeof(SHA256_CTX));
		SHA256_Update(&ctx, tmp_hash, SHA256_DIGEST_LENGTH);
		SHA256_Final(tmp_hash, &ctx);
 
		for(j = 0; j < SHA256_DIGEST_LENGTH/sizeof(ARCH_WORD_32);
j++)
			dgst[j] ^= ((ARCH_WORD_32*)tmp_hash)[j];
	}
}

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.