[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <FA662B32-8A44-480A-8278-9861F5996903@gmail.com>
Date: Thu, 26 Mar 2015 10:22:06 +0800
From: Lei Zhang <zhanglei.april@...il.com>
To: john-dev@...ts.openwall.com
Subject: Re: [GSoC] building JtR for MIC
> On Mar 25, 2015, at 11:14 PM, Solar Designer <solar@...nwall.com> wrote:
>
> On Wed, Mar 25, 2015 at 09:35:48PM +0800, Lei Zhang wrote:
>> OK, I'll try to find out the cause of OpenSSL's abnormality on MIC.
I found out it's icc who caused the trouble. OpenSSL's SHA1 implementation used an intrinsic functions _lrotl() to rotate a integer by specific bits. _lrotl is only available in icc and msvc, so OpenSSL(1.0.0) use the following code to enable it (crypto/md32_common.h):
---------------------------------------------------------
#if defined(_MSC_VER) || defined(__ICC)
#define ROTATE(a,n) _lrotl(a,n)
---------------------------------------------------------
HOWEVER, OpenSSL uses this function to rotate 32-bit integers, but the signature of _lrotl is:
unsigned long _lrotl(unsigned long value, int shift);
On windows 'long' is equivalent to 'int' so there's no problem. But on Linux 'long' is 64-bit, and _lrotl will do 64-bit integer rotating which is not what OpenSSL wanted. Actually this issue has been reported before <https://software.intel.com/en-us/articles/openssl-generates-incorrect-shamd5-value-if-built-with-icc-compiler>, and it's fixed in the latest version of OpenSSL(1.0.2):
---------------------------------------------------------
#if defined(_MSC_VER)
#define ROTATE(a,n) _lrotl(a,n)
#elif defined(__ICC)
#define ROTATE(a,n) _rotl(a,n)
---------------------------------------------------------
Unfortunately, I failed to build OpenSSL for MIC with version higher than 1.0.0. To live with MIC, we can either patch the code of OpenSSL-1.0.0, or stick with LibreSSL.
> So, yes, given your finding it makes sense for us to transfer to k1om in
> jumbo. I'm not sure if I should rename mic.h and the linux-mic make
> target in the core tree as well. What do you think? For an end user,
> this may be a bit confusing. I think Intel does not use the k1om name.
This surely is confusing. 'mic' is more intuitive, since it's used commercially by Intel. But 'k1om' seems more consistent with those GNU tools. I'd vote for using 'k1om' universally, though, for better consistency.
Lei
Content of type "text/html" skipped
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.
