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