Date: Mon, 8 Apr 2013 02:26:00 -0700 (PDT) From: deepika dutta <deepikadutta_19@...oo.com> To: "john-dev@...ts.openwall.com" <john-dev@...ts.openwall.com> 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. Deepika ________________________________ From: Solar Designer <solar@...nwall.com> To: john-dev@...ts.openwall.com; deepika dutta <deepikadutta_19@...oo.com> Sent: Sunday, April 7, 2013 9:23 PM Subject: Re: [john-dev] des-bs-doubt Deepika, 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 time 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. Alexander 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.