Cryptography-Digest Digest #674, Volume #9 Mon, 7 Jun 99 15:13:03 EDT
Contents:
Re: Challenge to SCOTT19U.ZIP_GUY ([EMAIL PROTECTED])
Re: Challenge to SCOTT19U.ZIP_GUY ([EMAIL PROTECTED])
Re: Challenge to SCOTT19U.ZIP_GUY ([EMAIL PROTECTED])
BUG in scottNu.zip (SCOTT19U.ZIP_GUY)
Re: Challenge to SCOTT19U.ZIP_GUY ([EMAIL PROTECTED])
Re: Cryptography CENSORED on web site? (John Savard)
Re: LSX Encoder ? ([EMAIL PROTECTED])
Re: Simple Cipher (which is quite gross) ([EMAIL PROTECTED])
Re: Challenge to SCOTT19U.ZIP_GUY (SCOTT19U.ZIP_GUY)
Re: New Computer & Printer for Dave Scott ("Tim Cannell")
Re: Challenge to SCOTT19U.ZIP_GUY ([EMAIL PROTECTED])
any cryptosystems using variable length keys? (David Ross)
Re: CRC32 (Paul Koning)
Re: evolving round keys (Paul Koning)
----------------------------------------------------------------------------
Date: Sun, 06 Jun 1999 23:43:35 -0400
From: [EMAIL PROTECTED]
Subject: Re: Challenge to SCOTT19U.ZIP_GUY
SCOTT19U.ZIP_GUY wrote:
>
> You write good and seem practical. I think you may have worked years
> with other peoples code like I have.
>
David,
If I can be of any help to you it would be a very simple suggestion that
would solve the criticisms you have been getting about the readability
(readability != goodness) of your source code.
The best possible thing you can to do buy a copy of "The Practice of
Programming" by Brian W. Kernigan and Rob Pike, (c) 1999
Addison-Wesley. The MSRP is 24.95. It is aimed at practical
programming not theoretical programming.
When you have the book read only Chapter One. Ignore the rest of the
book. Chapter One is more important than the rest of the chapters put
together.
How do I know this is important? I am unable to describe it in a way
that is easy for others to understand (like your program), but I *KNOW*
from personal and impersonal experience, that it is the most important
thing you can learn about software engineering. It helps you think
better. You'll understand when you see the subtitle of the book.
Good luck.
------------------------------
Date: Sun, 06 Jun 1999 23:58:04 -0400
From: [EMAIL PROTECTED]
Subject: Re: Challenge to SCOTT19U.ZIP_GUY
SCOTT19U.ZIP_GUY wrote:
>
> In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
> >On Fri, 04 Jun 1999 20:24:05 GMT, [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
> >wrote:
> >
> >> I have worked on many aircraft simulations and OFP;s one of the main
> >>problems that seems to occur over and over is that other people keep
> >>missing the obvious errors in the code becasue most people inheirently
> >>put faith on the comments and this leads to major maistakes that take
> >>years to find and fix. But I was considered an expert in fixing such code.
> >>LIke I said it is usually easier once one has input and outputs to just
> >>shorten internal names and fix the code. I have even been tasked with adding
> >>routines for certain projects that I have written and some managers where
> ><snip>
> >>Yes I am bragging so what.
> >
> >Scott,
> >
> >You find short names easy.
> >Others find long names easy.
> >
> >You find reading your own code easy, but have you tried reading OTHER
> >people's code? Was it as easy?
> >
>
> Yes once you toss out the usless comments. However have worked on
> projects that where into very flowery comments and the group was proud
> there comments failed to discribe the inputs or units. Yet these people
> thought thye were commenting something.
No, they thought they were following the rules. Blindly. You cannot
communicate by following syntax rules. Communication requires
semantics.
So don't add syntactic comments. Add semantic comments. Tell people
WHY you do thinkgs certain ways, not HOW or WHAT you do. The code
answers WHAT and HOW, but it is silent about WHY.
This is not a forum for discussing coding style. It is a forum for
discussing ciphers. Your coding style interferes with the discussion of
your cipher. Everyone wants to know WHY you wrote what you did.
Answer them.
------------------------------
Date: Mon, 07 Jun 1999 00:00:58 -0400
From: [EMAIL PROTECTED]
Subject: Re: Challenge to SCOTT19U.ZIP_GUY
SCOTT19U.ZIP_GUY wrote:
>
> In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
> >Try making one person barely satisfied. Until you have done that you
> >risk being accused of bad faith. I.e., you aren't really trying.
> >
> I did that with Horst Ossifrage and actually did it with Mok but I think he
> was faking interest. Actually I am anwsering Redburn questions and if Paul
> Onions has any or Joe P.
OK, keep trying.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: BUG in scottNu.zip
Date: Mon, 07 Jun 1999 17:08:59 GMT
Oliver Wiedemann found what I call a bug in the code
that would greatly affect the implimentaion of the source
code on a different machine. It is a definite bug that I
over looked.
So I wanted to see the effect on the scott16u.zip contest
below is the change in the source code to get around the
"BUG". I used the resulting "keyenc.key" file and the password
that I used to protect the the "keyenc.key" file in both cases
with either executable the same solution worked.
However I feel that it should not be in the source code and
will make some differences depending on what one is doing.
So either fix it in your on source code or wait for scott16w
which will have that fix plus other ideas for table generation
namely so things like "a" and "aa" don't create same S-table
and things such that if one picks a random unifrom file for
raw key the entropy will me maximum. Thanks to Oliver,
Paul, Tim and the Diehard guy. This is becoming a better
product. Yes Virgina Dave does have some codeing standards
they just are different than the heard.
Comparing files humb16u.c and ..\scott16u.c
****** humb16u.c
*/
un16 rtW[T16L+2], ftW[T16L+2], btW[T16L+2];
un16 *rt = rtW+1;
un16 *ft = ftW+1;
un16 *bt = btW+1;
char fin[100], fout[100];
****** ..\scott16u.c
*/
un16 rt[T16L], ft[T16L], bt[T16L];
char fin[100], fout[100];
******
I used the final keyenc.key file with my final password
both executables solved the contest the same. So I will
suplly that keyenc.key file with the pass word at the end
and either the old executable or the new one will work.
Thank You
David Scott
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
------------------------------
Date: Sun, 06 Jun 1999 23:51:29 -0400
From: [EMAIL PROTECTED]
Subject: Re: Challenge to SCOTT19U.ZIP_GUY
To all except dscott,
The purchase of a fast computer has been suggested as a way to resolve
dscott's readability problem. In a sibling post I suggested "The
Practice of Programming" by Kernigan and Pike as a more appropriate
remedy.
I am willing to collect the funds necessary to purchase and ship a copy
to Mr. Scott. The price is $24.95, and shipping is ~3.00. I will
contribute $2.95 plus labor. If five other readers are sufficiently
interested they may send no more than $5.00 to my escrow agent:
Engineering Department
Granite Trust
44 Depot Street
Uxbridge, Massachusetts
If there is insufficient interest to fund the purchase of this book
within 30 days I will cancel the offer, and return the donations.
By the message volume many more than 5 people are irritated by these
threads. Let us not fix the blame, let us fix the problem.
P.S. This is not an altruistic act. It is an act of pure selfishness.
SCOTT19U.ZIP_GUY wrote:
>
> In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
> >Tim Redburn wrote:
> >>
> >> On Fri, 04 Jun 1999 20:24:05 GMT, [EMAIL PROTECTED]
> >> (SCOTT19U.ZIP_GUY) wrote:
> >>
> >> >
> >> > I have worked on many aircraft simulations and OFP;s one of the main
> >> >problems that seems to occur over and over is that other people keep
> >> >missing the obvious errors in the code becasue most people inheirently
> >> >put faith on the comments and this leads to major maistakes that take
> >> >years to find and fix.
> >>
> >> Quite the opposite. Comments tell you what the programmer intended.
> >> It is then easier then to verify that the code actually works
> >> as intended. If you don't know what the code was meant to do, how can
> >> you debug it ?
> >
> >Actually it's harder than that. Comments often tell you what the
> >_original_ programmer _originally_ intended. The secret to good writing
> >(of any kind) is rewriting. Rewriting implies that the intentions of
> >the author evolve during the process. Thus the final intentions of the
> >author(s) may be arbitrarily far from the original intentions.
> >
> >A truism of software maintenance (which is mostly software analysis) is
> >that the value of comments is often negative. More often than not. The
> >cost of persuing a false trail based on the comments is high. It can
> >pollute your concept pool long after you've learned better (holographic
> >memory effects I suppose).
> >
> >ThHis explains one of the first rules of maintenance. Delete the
> >comments, then study the code. Review the comments (skeptically) later
> >to resolve problems and find issues warnings not apparent from the code.
> >
> >The Grail of good software is self-documenting code. That does NOT mean
> >comments.
>
> You write good and seem practical. I think you may have worked years
> with other peoples code like I have.
>
> David A. Scott
> --
> SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
> http://www.jim.com/jamesd/Kong/scott19u.zip
> http://members.xoom.com/ecil/index.htm
> NOTE EMAIL address is for SPAMERS
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Cryptography CENSORED on web site?
Date: Mon, 07 Jun 1999 17:13:14 GMT
"rosi" <[EMAIL PROTECTED]> wrote, in part:
> I do not think people will have the 'suppressing' notion at all.
No, I didn't think that either - I was just using that title for my
post in a humorous sense.
I have now added a specific section on one-time pad and information
theory issues to my site, the section entitled "The Limits of
Cryptanalysis". It's quite brief, but it fills a gap.
Also, I was over at a library on the weekend, looking at two later
books by Beker and Piper. They were not as interesting as "Cipher
Systems" may be - the one I thought might have superceded it was in
fact a collection of papers they edited. But I saw a paper from
December 1997 on Colossus, and that enabled me to update that portion
of my web page with more specific information of what sort of
cryptanalysis was done with it.
John Savard ( teneerf<- )
http://members.xoom.com/quadibloc/index.html
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: LSX Encoder ?
Date: Mon, 07 Jun 1999 17:06:27 GMT
> Does anyone know how to encode pictures in a .lsx format ?
> Bye.
>
What program makes .LSX files? Maybe I could track something down for
you. BTW this may be off topic as algorithms normally do not specify
file name extensions.
Tom
--
PGP public keys. SPARE key is for daily work, WORK key is for
published work. The spare is at
'http://members.tripod.com/~tomstdenis/key_s.pgp'. Work key is at
'http://members.tripod.com/~tomstdenis/key.pgp'. Try SPARE first!
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Simple Cipher (which is quite gross)
Date: Mon, 07 Jun 1999 16:11:34 GMT
<snip>
Whoops to problems with the source code, (not like it matters),
1. There should be a final bijective transformation of some sort (ala
binary addition of a whitening key). This is because if you have
a = f(x), b = f(y) and a != b, you will know that x != y, which reduces
the complexity.
2. The simple bit flipping test does not take in account the PHT which
is why after one round the stats look ok. In reality the attacker can
undo the first and last PHTs so it's only the ones in the middle that
matter.
I dunno the algorithm looks ok, but it requires too much ram. I did it
just to prove to scott that ciphers can take a lot of memory and still
be readable by humans.
I would not suggest to use the algorithm (mine) unless you have ram to
spare and you perform a final permutation. Of course there are many
other algorithms which are just as fast, and just as simple. The only
simple 128 bit block one would be RC6. It's the simplest to
understand. All of the AES candidates are 128 bit blocks and require
far less then 128 kb of ram. read: My cipher is a toy!
Anyways I would still like to hear any comments, but for as of this
moment I have to get back to learning Gaussian Elimination (...), so
tah.
Tom
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Challenge to SCOTT19U.ZIP_GUY
Date: Mon, 07 Jun 1999 19:10:27 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>SCOTT19U.ZIP_GUY wrote:
>>
>> In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
> wrote:
>> >On Fri, 04 Jun 1999 20:24:05 GMT, [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
>> >wrote:
>> >
>> >> I have worked on many aircraft simulations and OFP;s one of the main
>> >>problems that seems to occur over and over is that other people keep
>> >>missing the obvious errors in the code becasue most people inheirently
>> >>put faith on the comments and this leads to major maistakes that take
>> >>years to find and fix. But I was considered an expert in fixing such code.
>> >>LIke I said it is usually easier once one has input and outputs to just
>> >>shorten internal names and fix the code. I have even been tasked with
> adding
>> >>routines for certain projects that I have written and some managers where
>> ><snip>
>> >>Yes I am bragging so what.
>> >
>> >Scott,
>> >
>> >You find short names easy.
>> >Others find long names easy.
>> >
>> >You find reading your own code easy, but have you tried reading OTHER
>> >people's code? Was it as easy?
>> >
>>
>> Yes once you toss out the usless comments. However have worked on
>> projects that where into very flowery comments and the group was proud
>> there comments failed to discribe the inputs or units. Yet these people
>> thought thye were commenting something.
>
>No, they thought they were following the rules. Blindly. You cannot
>communicate by following syntax rules. Communication requires
>semantics.
>
>So don't add syntactic comments. Add semantic comments. Tell people
>WHY you do thinkgs certain ways, not HOW or WHAT you do. The code
>answers WHAT and HOW, but it is silent about WHY.
>
>This is not a forum for discussing coding style. It is a forum for
>discussing ciphers. Your coding style interferes with the discussion of
>your cipher. Everyone wants to know WHY you wrote what you did.
>
>Answer them.
I wrote the program becasue I feel people are being mislead in the large
scale about encryption.
But to do this I looked at 2 parts one was to make a basic block cipher
that covered a wide a range as possible. I choose the single cycle S table
to be that cipher. But I noticed that the keys get long fast and are hard
to manage after only a few bits. You can see at 19 bits the key already has
over one million bytes. Obviously this general approach will not work when
the bit size gets much larger. But if I include all S-table possiblites then
things like the unity transform are possible so I did not include them or the
muliply cycle tables where the information can be reduced due to smaller
tables taking less space. I feel that haveing one or at most a very limited
number of cycles is a key feature of good encryption. I wonder if any one
has looked at the AES candidates in this area. Know if one makes any
kind of whiz band 8 or 16 bit block encryption the bad guys don't even
need to look at your code if they have a way of decryption a general
encryption made up of S-table since all block ciphers are a subset
to this.
The second thing that bothered me is the fact the chaining methods in
general use seem so very weak. Here is exactly what I mean as weak.
You can use IDEA ( or any AES candidate) use CBC encryption and
then reverse so the front is the back and then encrypt agafin useing
a different key. Know hex edit a byte in this file and then decrypt in
reverse order. Only a small area is garabage. The rest of the file is
recovered in tact. Some pass this off saying it is just the error recovery
nature of the standard chaining methods. Yes this is true but there are darker
things about this. It points out that a bad guy only need to look at a small
fragment of a file to break the code. This makes an attackers job much
easier. Very little is said about this. I feel little is said about this so
that the bad guys can keep breaking the codes. The more I have looked
at chaining the more I think that it is done wrong. One can and should
treat long blocks as a single block. My program went to the extreme
and treated the whole file as a block. One does not need to do this but
there is no reasin not to treat things like 512 bytes as a single block.
I feel strongly that if the user want to use several methods in series
then the major methods should have a mod where the file lenght does
not change.
I chose to do wrapped PCBC the way I did becasue it made the diehard
tests looks good. It may not be perfect but I feel it is a step in the right
direction. Also I feel there are other weakness built into the normal chaining
methods. My chaining has to be done in reverse order that is really not
true with CBC you can start at bottm of file and as soon as you read the last
2 block you can decode the bottom block. Yes these are my feelings that
the chaining methods in use are purposely weak. They may have been useful
in the morse code days but you don't even have to know morse code in the Navy
any more to be a radio man.
I hope this is in direction you wanted.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
------------------------------
From: "Tim Cannell" <[EMAIL PROTECTED]>
Subject: Re: New Computer & Printer for Dave Scott
Date: Mon, 7 Jun 1999 18:18:21 +0100
Who is Dave Scott.. and can we all have a free computer ?
[EMAIL PROTECTED] wrote in message <7jbhui$ac9$[EMAIL PROTECTED]>...
>
>> If we get 9 donors of $100 each, we can purchase it
>> and ship it to David as a completed package. I am serious,
>> please sign up today.
>
>Why not teach him how to write proper code/algorithms first? Maybe
>something like a programming course, or if we want to splurge a comp
>sci course...
>
>Tom
>--
>PGP public keys. SPARE key is for daily work, WORK key is for
>published work. The spare is at
>'http://members.tripod.com/~tomstdenis/key_s.pgp'. Work key is at
>'http://members.tripod.com/~tomstdenis/key.pgp'. Try SPARE first!
>
>
>Sent via Deja.com http://www.deja.com/
>Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Challenge to SCOTT19U.ZIP_GUY
Date: Mon, 07 Jun 1999 17:10:20 GMT
<snip>
Talking about coding style is off topic. Please refrain from any
further post on the subject. If it happens to be about
simplifying/optimizing an algorithm then go for it.
BTW, if you want to learn good coding style and techniques write a few
programs first. You will pick things up as you go. The best (and I
mean it) is K&R which is *the* book on C. It teaches all the
constructs you need to know, unlike these 'learn in a day' books...
Tom
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (David Ross)
Subject: any cryptosystems using variable length keys?
Date: Mon, 07 Jun 1999 18:33:37 GMT
Hello -
Do any cryptosystems use a variable length key?
(By 'variable length key', I mean a key which has a different
effective length from one byte/block to the next byte/block in the
same message.)
Can anyone speak to the benefits or disadvantages of a variable
length key?
thanks
Dave Ross [EMAIL PROTECTED]
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: CRC32
Date: Fri, 04 Jun 1999 16:25:11 -0400
iLLusIOn wrote:
> >You've left out one important point: might an adversary try
> >to generate files with the same checksum?
>
> no, it might only occure accidental
>
> >If you're only worried about accidental collisions, a large
> >CRC is fine. If you have to resist intelligent attackers,
> >then you need a cryptographic hash such as SHA-1.
>
> i have tried SHA, but it is a bit slow i think...
If you don't have intelligent attackers, any cryptographic
hash is serious overkill and bound to take much more CPU
time than error checking codes.
> i'd just need
> this CRC algorithm for a program which should, lets say,
> detect duplicate data blocks of a variable size from a few
> bytes upto a few megabytes within a file of about 1GB.
Something to keep in mind: each CRC has properties like this:
a. detects all single error bursts of burst length less than k
b. detects all errors that change fewer than p bits in messages
shorter than m bytes.
In the above, I believe k is independent of message length but
p is not.
For example, CRC-32 will detect all 3-bit errors in packets of
less than about 11k bytes. Beyond that it will detect all 2 bit
errors but there are 3 bit patterns it misses. (Possibly "3"
should be "4" and "2" should be "3" above, but the point remains
the same.
This is why Ethernet uses CRC-32 rather than CRC-16 (the lengths
at which the CRC gets weak are smaller for smaller CRCs).
This is why you shouldn't use 64k byte packets in ATM or in
token ring even though the standard allows it.
If you want to protect megabytes with a single checksum, you
might want to use CRC-64. I don't know any polynomials;
one was proposed for HiPPI and could perhaps be found in
those documents. Or you could do a separate CRC-32 for
each 8k bytes or so. Or you could ignore the problem, if
your error checking requirements aren't that tough.
I think there are a few more questions:
1. What sort of errors are you worried about?
a. bits changed,
b. bits deleted or added
c. bits or groups of bits interchanged
2. Single error burst or multiple bursts? How long?
If your requirements are weak enough, the IP checksum will
do; that one is about as easy as you can get. But it is also
quite feeble. Fletcher is slightly better, also somewhat
harder (in particular, definitely harder if you want to do
more than one byte at a time). CRC is better than either one
and also slower.
paul
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: evolving round keys
Date: Fri, 04 Jun 1999 16:33:24 -0400
[EMAIL PROTECTED] wrote:
>
> I was just wondering why block ciphers have keys which remain
> constant? Would there be any benefit of having post/pre white keys
> that change per block (with a cycle length of the 2^n where n is the
> number of bits per word)....
Sounds a bit like leaning into the direction of stream ciphers.
One issue... with block ciphers, you can process pieces of a
message (for example, encrypted IP packets) in any order.
Loss of a piece doesn't affect the ability to process the rest.
If your keying state changes as you process bytes, you must
process the bytes in order, and all of them. More precisely,
if the changes are data-independent, you need to know at least
the count of missing bytes. If the changes are data dependent,
you're SOL if you lose any bytes at all.
paul
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and sci.crypt) via:
Internet: [EMAIL PROTECTED]
End of Cryptography-Digest Digest
******************************
