Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [day] [month] [year] [list]
Date: Mon, 8 Apr 2013 02:26:00 -0700 (PDT)
From: deepika dutta <>
To: "" <>
Subject: Re: des-bs-doubt

Hi Alexander,

Thanks for clearing my doubts. These questions are quite natural to come in the mind of a newbie not familiar with your code evolution over time. Actually I don't intend to change the code in JTR but was thinking to incorporate these changes in the DES code which I am using for my personal work. I want to use your sbox functions (as they are the optimized ones) and change the surrounding code according to my need. I wanted to know if you are following this pattern for some specific reason like performance etc. so that I can keep that in mind before doing any changes. 



 From: Solar Designer <>
To:; deepika dutta <> 
Sent: Sunday, April 7, 2013 9:23 PM
Subject: Re: [john-dev] des-bs-doubt

On Sat, Apr 06, 2013 at 01:42:15PM -0700, deepika dutta wrote:
> For plaintext: Swapping the 32 bit halves before doing encryption though in the DES standard these halves are swapped after the last round.

These are two halves of the ciphertext, not the plaintext.  We're trying
to minimize the amount of work we have to do per candidate password
tested.  By swapping the two halves in the hashes loaded for cracking,
we avoid having to do it per candidate password.  With bitslicing, the
latter could be as simple as reading from element 32 instead of from 0,
so no obvious runtime cost anyway, but this approach dates back to
before JtR started using bitslice DES.

Additionally, JtR can still be built to use non-bitslice DES as well.
In fact, "make generic" tries this, and on some purely 32-bit systems
without SIMD and without fast(er) L1 caches the two S-box lookups at a
 non-bitslice implementation (128 KB for the S-boxes) turns out to
be faster, so it gets used instead of bitslice.  I last saw this happen
in my testing in QEMU emulating 32-bit SPARC and ARM.

With the halves swapped, these different implementations are more
consistent in their representation of the loaded hashes ciphertexts.

> For key: Storing the 7 bits per byte in little endian form in DES_bs_all.K

This is probably for historical / code evolution reasons.  It was not
written straight from DES spec and into its current form, but rather it
evolved through many intermediate representations, each in form of C
code, over many years.

> Is there any performance issue in this? If I want to swap the plaintext after last round and store the 7 bits per byte in big endian form in DES_bs_all.K, then will there be any problem in this representation? (of course I would have to change the indexes of B and
 K referred in sbox functions).

I think you can likely do both without incurring performance impact, if
you do it right.  The change in memory access pattern may have some
performance impact on some systems, though.  It is not obvious to me
whether the change in key order bits will make things faster or slower
in case the data has to be read into L1 cache rather than is already in
L1 cache.  You need to examine the order of key bits after key expansion
for that.  In general, sequential order (lowest address accessed first,
then higher addresses) is preferable.

This is probably not a change we'll want to accept into JtR, unless you
show that it actually improves performance.

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.