Debian – How to get John the Ripper running on a recent version of debian or ubuntu

• What is SSE2 in general ?

SSE2 is a extended specialized instructions sub-set of Intel x86 instruction set. They are dedicated to SIMD (Single-Instruction Multiple Data) which means that in one instruction they can handle several data thanks to specific extra-wide registers (namely the XMM registers which are 128-bits wides).

The possible splits of the XMM registers are as shown in the following picture.

• Can SS2E be used in x86 processors ?

Any relatively recent Intel x86 processor has SSE2 instruction set. If you want to check if you CPU has it, just do:

$> cat /proc/cpuinfo | grep flags | tail -n 1
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36
        clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb
        rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology
        nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx
        est tm2 ssse3 fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt
        tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm ida arat epb pln
        pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust
        bmi1 avx2 smep bmi2 erms invpcid xsaveopt

You can see here all the instruction sub-sets that your processor has built-in. You should find sse2 in the list (it is the case here).

• Why do those builds like john need SSE2 ?

SEE are really useful for handling signal processing and highly parallelized algorithms. In the case of John the Ripper, SSE2 instruction set is used to parallelized the hash-function brute-force algorithm. It computes several hash attempts in one instruction to speed-up the exploration of the key-space (or to exhaust the dictionnary).

• Why can not those builds be run on a system which has SSE2 specification ?

It is very likely linked to a software reason. Either you installed 32bits system over a 64bits CPU (i386 over amd64), or you may not have the compile tools that are able to handle SSE2 instruction sets. It also may be because the build-system of John has a flaw and failed to detect properly the ability of your system.

But, you do not give enough information about your system to solve the problem.

If you want to install john, you better use the pre-compiled package that comes with your distribution (this is a standard package in almost any mainstream distribution now).

After Ulrich Schwarz mentioned a custom PAM module in the comments to the question, I figured I could go and see what SLES, which makes Blowfish the default, is using.

Turns out it is a separate module called pam_unix2.so not conflicting with anything on the CentOS system. As a proof-of-concept, I have copied /lib64/security/pam_unix2.so off a SLES 11 SP4 system to /usr/lib64/security/pam_unix2.so on the CentOS host and downloaded and installed its dependency libxcrypt which again is a SuSE package, but works on CentOS 7 for this narrow purpose.

Adding

auth        sufficient    pam_unix2.so

to /etc/pam.d/system-auth allows me to authenticate against a Blowfish-crypted password on the console.

To make sure authconfig will not break the configuration on the next invocation, the symlink /etc/pam.d/system-auth pointing to /etc/pam.d/system-auth-ac should be replaced with a copy of /etc/pam.d/system-auth-ac.

Bottom line: SuSE's pam_unix2 module seems like the least invasive method to get Blowfish hashes accepted, although it also means that I would need to monitor security announcements for pam_unix2 and libxcrypt separately.