Date: Sat, 25 May 2013 10:06:02 -0400 From: <jfoug@....net> To: john-dev@...ts.openwall.com Subject: Couple of recent changes in bleeding I added the aix-* hashes to pass_gen.pl. I had to figure out how to do the base-64 properly, and how to use SHA512 in Crypt::PBKDF2. Once those were done, it generates hashes perfectly. Added 125 byte long password hashes to all aix-* formats. Since using pbkdf2_hmac_sha*.h files, the PLAINTEXT_LENGTH was kicked up to 125 bytes, but we had no test data. It would be VERY wise to go through all the formats, and add test data that pushes the max PLAINTEXT_LENGTH, so that we know the formats are working. I changed the pbkdf2_hmac_sha*.h files, so that they can optionally also include the CTX (oSSL) code, even if building under SSE2. This allows the 1 password / 1 hash interface of oSSL to be used also. This was needed in the next change (in cmp_exact) I changed the pbkdf2-hmac-sha512-fmt-plug.c to use pbkdf2_hmac_sha512.h. The pbkdf2 code originally in the format was 2x slower (doing 4 SHA512 crypts per loop, vs 2). Also gained, is SSE2. The oSSL is about 2x faster than before. If built with SSE, it is 4x faster (or more). XOP should gain more. I am going to look at adding SSE to cryptsha256. That will be a bit of a challenge, since it is a mix of 1 and 2 limb crypts, AND the mix varies based upon password length. Thus, I will probably have to rearrange the order of passwords within the crypt, but being very careful to properly update the original order of the passwords into the crypt array. The new SHA256 does have a 'flat' input mode, and that may be helpful for getting this to work easier. I will have to see in the end if flat helps, or if intermixed ends up 'winning' in the end. It may be that both ways have to be used. In SHA4 builds, it may be faster to keep the inputs in flat mode. Jim.
Powered by blists - more mailing lists
Powered by Openwall GNU/*/Linux - Powered by OpenVZ