release 0.8 notes, 21 Feb 97

I'm told that someone has placed a copy of deskr06
on an open FTP server outside the United States. I
don't know who, nor do I want to know. I remind all
recipients of this code that it's a violation of US
regulations to transmit this program overseas. Please
don't expose yourself to possible prosecution.


This release sees a major performance jump on Pentiums
and Pentium Pros. The main improvement was reached by
placing the entire per-key loop into a single routine,
which means that we keep in cache for up to 256 keys
at a time. I'll soon have that up to 2^16 keys, but
the scheduler interrupt on NT means there's a limit
to how much that can improve things.

Further speedups were achieved by writing special
case code for key update when only bit 0 or bit 1
changes - this covers 3/4 of the key updates, and 
the key update speed has been more than doubled 
for those cases. (Key update is about 25% of the
total effort otherwise).

Further speedups are to come - I'm still jumping
back and forth between C and assembler a lot more
than I like, and I'm investigating Mikkelsen's
latest tweak, which gets us down from 14 to 13
DES rounds 15/16 of the time (its actually a
bit more complex than that).

I'm clocking this one at 256,000 keys/sec on a
90MHz Pentium under NT.

Other changes.

Be sure to read the 0.7 notes below. I've also
made a change in which deskr.out and solution.txt
are written to a user's local directory as well
as the shared directory. This is to provide a backup
in case the shared copy gets trashed.

A bug on some SPARCs in the way checkpoint files
were read in has been fixed.

-------------------------------
release 0.7 notes, 14 Feb 97

Minor maintenance release. Never sent to net.

1. Corrected errors in output file - half matches were
not being cleared at the end of each chunk, and were
getting re-reported.

2. If DESKRSHARE is set, whenever a checkpoint file is
written, DESKR will check to see if a file called
'stop.now' exists in that directory, and if is does,
will stop. It won't restart as long as this file 
exists.

I put this in because I found that on a network of
NT machines, if *any* copy was running, I could
not replace the deskr executable in DESKRSHARE.
This might be a major problem if you were
trying to update the executable and hundreds
of machines were running from the same executable
file.

Note: in this type of network, you have to give
*everyone* full privs in this directory. I worry
a little about the implications of this.

----------------------
release 0.6 notes, 10 Feb 97

You *did* know that you were beta-testing, didn't you? 

I've found a serious bug which effects versions 0.5
and earlier.

After each block was searched, the program was failing
to set an index counter back to zero. The upshot of this
was that after the first block the program sometimes went 
off into the wild blue yonder, testing keys in an 
unpredictable fashion. It's been fixed in this version.

One of the beta-testers found a bug in the routines which
read challenge data. His fix has been included.

I have still to examine the second UNIX port which was 
sent me. I will do so before 1.0.


Other fixes:

Restart now correctly restarts in mid-chunk, instead
of going to the start of the chunk.

realchal.txt and testchal.txt are both correctly
formatted for use; you just have to copy one or
the other to deskr.inp. If you use the test data,
then deskr -k 5ed9204fece0b967 should show you
a solution. Since the 'real' challenge data is
also compiled directly into the program, you don't
really need these files. These files are NOT
direct cut-and-paste from the RSA web page, but the
data is short enough to do an eyeball comparison.

deskr -i now has only the high-level byte of
the index counter listed. This should speed up
runs on very fast machines, where the printing
a line every 64k keys was slowing it down.

---------
I'm working on a couple of performance enhancements.
When I get those working, I'll probably make it
version 1.0

To be specific:
I'm putting in special case code for updating the
key schedule when bit0 of the crunched key flips.
This should get a 6% speedup.

I'm putting the entire lower loop into a single
assembler routine. This should give a major speedup,
since it should stay in cache for 64k keys at a shot,
and get rid of the procedure calls now done.
-----------
Some people have asked about the relationship between
the chunk number and the key being tested, largely so
that they can compare results between Sven Mikkelsen's
code and my own. Unfortunatly, this is difficult, for
two reasons. 

1. I don't know how Sven is handling his keys. Going
through them in numerical order is NOT the fastest
way to do things.

2. My 'chunk number' is the 24 high order bits of the
'crunched' key. It turns out that a re-arrangement of
the key bits allows me to usually skip the first DES
round, giving a significant speedup. Thus, the chunk
number is actually derived from a concatenation of
bits 63-61, 48-46, 43-36 of the original key, where
the bits are numbered 0-63, with bit 0 the least
significant. The reasons for this are in comments
in deskr.c and deskey.c

Has anyone gotten Mikkelsen's Bryddes to run under
win95/nt? What sort of speeds are you seeing?


Peter Trei

-----------------------
-----------------------
release 0.5 notes

This version will read data from the supplied deskr.inp without
crashing. If you still have 0.4, you might want to try running
that without the deskr.inp file present. That should also work,
and seems to be a little faster.

There will be at least one more maintenance release to clean
up the input - it should read a direct cut-and-paste from the
RSA web page. There will also be at least one more performance
release RSN.

I have two different unix ports - the first one's diffs have
already been included in the source. The second one I'll have
to look at before I can do anything with them.

If you're a porter, and don't mind having your ID revealed,
tell me, and I can put you all in touch.

There should be a listserv for this soon.

Peter
-------------------------
release 0.4 notes.

Please don't send me PGP encrypted email - I'm 3000 miles from
home, and getting such a message decrypted is a major headache.

Version 0.3 turned out to have the following problems:

1. I did not include all of the source files. I'm not sure how
I slipped up on this, but it should be fixed in this version.

2. Version 0.3 could not read the challenge data from a direct
cut and paste from the RSA Web Site. It turns out that RSA 
changed the format slightly - dropping the asterisks present
at the start of each tag in the examples they sent around via
email, and changing the actual text of the tags.

Version 0.4 and above looks for a file called deskr.inp, which
should contain the correct data in a format it can read, and
also has that data compiled directly into the program in case
it can't find it. You are encouraged to run with deskr -i to 
see the actual data being worked. If you want to test this
version with the test challenge data, you'll have to prepare
a modifed deskr.inp file with the test data in it in the same
format and tags as the supplied deskr.inp.


This is version 0.4 of Peter Trei's DES Key Recovery program.
The zip file contains a PGP key and a detached signature file
for the inner zip file, which can be used to verify its
integrity. The inner file contains source, support files, notes,
etc. It also includes a Win95/NT executable. The source will
compile under MSVC++ and on some unix systems.

Do not export this software, give it to a non-US/Canadian
citizen, or put it up on an unrestricted server on the
Internet. Within those restrictions, feel free to pass
the program around, but please do so as my intact zip file
with the associated PGP signature.

If you're going to be participating, I'd love it if you'd
drop me a note at ptrei@acm.org, with an indication of the
number and speed of the machines which will be running it.

Sadly, RSA has been inconsistant with their formats for the
'practice' vs. the 'real' challenge data. Version 0.4 has the
real data compiled into it - this is the easiest thing to use.
If you wih to verify the operation of the program, you will have
to make a version of deskr.inp using either your own data or
data from RSA's web page, but in the same format as is used
in the supplied file.

Send bug reports, questions, etc to ptrei@acm.org. I may not
respond individually - common issues will probably be 
discussed on a web page at 
http://www.ziplink.net/users/trei/crypto.html


Happy hunting.

Peter Trei
ptrei@acm.org