Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 1 Jul 2015 16:52:29 +0200
From: Frank Dittrich <>
Subject: Re: JtR on Power

On 07/01/2015 04:39 PM, Solar Designer wrote:
> Great!  Please note that POWER can be 32- or 64-bit, big- or
> little-endian.  All four combinations are possible, depending on the
> operating system.  So we need actual detection of word size and
> endianness, like we had in "make generic" before.  Unfortunately, magnum
> dropped that when adding autoconf support, but I think we need to
> reintroduce it.

make generic wasn't dropped.
There's still that Makefile.legacy, and from time to time, some effort
goes into testing

make -s -f Makefile.legacy clean generic
make -s -f Makefile.legacy clean linux-x86-64-native

Currently, we have a state with just a few known issues:

crypt(3) fails for linux-x86-64-native (fails to build or segfaults,
depending on OpenMP, du to messed up ifdefs for crypt / crypt_r, see

pufferfish format is skipped, even though I tried to fix it locally by

-#if HAVE_EVP_SHA512
+#if (AC_BUILT && HAVE_EVP_SHA512) || \
+    (!AC_BUILT && OPENSSL_VERSION_NUMBER >= 0x0090708f)

in a few places, but so far didn't succeed.

So, generic should work, at least for common architectures. If not,
please report as a githiub issue.

I'd like to have a change for generic, trying even higher values
for BF_X2 as long as the next value results in better performance than
the previous one.
(On Haswell that results in a much better c/s rate for generic than for
the autoconf build.)

But that is probaly best done in core (may be after renaming BF_X2).


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.