Cryptography-Digest Digest #670, Volume #9 Sun, 6 Jun 99 12:13:03 EDT
Contents:
Re: Challenge to SCOTT19U.ZIP_GUY (Lincoln Yeoh)
Re: Challenge to SCOTT19U.ZIP_GUY (Tim Redburn)
Re: Finding a 192 bit hash (Was: Using symmetric encryption for hashing) (Paul
Onions)
Re: Scottu: I actually saw something usefull (SCOTT19U.ZIP_GUY)
Re: Challenge to SCOTT19U.ZIP_GUY (SCOTT19U.ZIP_GUY)
Re: Oriental Language Based Enryption ("Markku J. Saarelainen")
Crypto Systems for International Business (MJS)
Re: Challenge to SCOTT19U.ZIP_GUY (SCOTT19U.ZIP_GUY)
Re: Scottu: I actually saw something usefull (Horst Ossifrage)
Re: Challenge to SCOTT19U.ZIP_GUY (Thomas Pornin)
Re: Challenge to SCOTT19U.ZIP_GUY ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Lincoln Yeoh)
Subject: Re: Challenge to SCOTT19U.ZIP_GUY
Date: Sun, 06 Jun 1999 12:42:18 GMT
Reply-To: [EMAIL PROTECTED]
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?
If you want to keep the code to yourself you don't have to bother about
others.
If you want more people to use or appreciate your code, make it easier for
them.
Cheerio,
Link.
****************************
Reply to: @Spam to
lyeoh at @[EMAIL PROTECTED]
pop.jaring.my @
*******************************
------------------------------
From: [EMAIL PROTECTED] (Tim Redburn)
Subject: Re: Challenge to SCOTT19U.ZIP_GUY
Date: Sun, 06 Jun 1999 12:44:23 GMT
On Sun, 06 Jun 1999 06:13:57 GMT, [EMAIL PROTECTED]
(SCOTT19U.ZIP_GUY) wrote:
<snip>
> If you look at my code you will realize that decryption if anything
>would be slower than encryption since I am sort of going against
>the normal data flow........
<snip>
What do you mean by ".. against the normal data flow .." ?
In scott19u.zip, you load the whole of the
plain text into memory before working on it.
Working start to finish is no different from
working finish to start. Or am I missing something ?
I thought that the data was treated as one large static block held
in memory.
Please produce a document that describes your *algorithm* clearly and
concisely to remove any of these confusions that I, and others,
have about it.
- Tim.
------------------------------
From: Paul Onions <[EMAIL PROTECTED]>
Subject: Re: Finding a 192 bit hash (Was: Using symmetric encryption for hashing)
Date: Sun, 06 Jun 1999 13:26:09 +0000
Boris Kazak wrote:
>
> Actually, it would be much safer (and simpler) to use one single
> multiplier, or, for paranoids, change the multiplier once every round.
> In this case different bytes will always yield a different product.
> The old adage KISS (Keep It Simple, Stupid!) is still true...
>
> The 256-enrty table will be excessive, the code will run faster.
>
> Any suggestions on the multipliers?
Well, since 2^32+1 is not prime, choosing a multiplier that is not coprime
to the modulus will again allow one to find collisions.
On the other hand, choosing a multiplier coprime to 2^32+1 results in another
weakness. This is because it makes the block-multiplication function invertible.
(Assuming my understanding of it is correct - please correct me if I'm wrong).
To see this, consider the final mod 2^32+1 multiplication applied in the final
(3rd) round of block processing. Since we know its output and one of its inputs
(the constant multipler) we can compute the other input and so undo the effect
of this multiplication. We can carry on doing this to undo the entire 3-round
block processing operation.
Denoting your hash scheme as H[i+1] = B(M[i] XOR H[i]) where the M[i] are
the message blocks and H[0] = IV a fixed quantity and B() is the block processing
operation. With the final M[i] being a padding/message-length encoding block
and the final hash value being the XOR of left and right halves of the last H[i].
Now, since B() is invertible, we can compute preimages of a given hash output
as follows:-
Given a hash value, create a H[n] value consistant with it. Now invert B() giving
H[n-1] XOR M[n-1]. Set H[n-1] consistant with the length of the preimage we want,
thus also setting M[n-1]. Invert B() on H[n-1] giving us H[n-2] XOR M[n-2].
Choose M[n-2] as desired and invert H[n-2] and so on. When we get to H[0] XOR M[0]
then set M[0] so that H[0] = IV.
Thus the hash is not one-way (and so obviously also not collision-resistant).
Does this make sense?
Paul(o)
--
Paul Onions [EMAIL PROTECTED]
PGP 2.6.3 key available
D704688BEFBF2D5D 546BC1D603E2A8E0
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Scottu: I actually saw something usefull
Date: Sun, 06 Jun 1999 14:58:09 GMT
In article <[EMAIL PROTECTED]>, Horst Ossifrage <[EMAIL PROTECTED]> wrote:
>[EMAIL PROTECTED] wrote:
>>
>> On his page there is a brief description of the algorithm. I found this
>>
>> Cn = S{ (((Cn-1) XOR (Pn)) + (Pn+1))mod 2^W }
>>
>> Which happens to be the round function, where
>>
>> Cn is the ciphertext at n
>> S is the large S-box
>> Pn is the plaintext at n
>>
>> Now I know little of actually starting an attack, but from what I
>> briefly saw, he runs from 0-n 25 times. Errors in the ciphertext
>> propagate forwards only though (note Cn-1 usage). If he ran this
>> forwards and backwards this might help (note: would have to use Cn+1
>> which I did not see on his page).
>>
>> Which leads me to think that the first set of n-25 words leaks info
>> about the s-boxes. The key schedule does not look too proper though..
>>
>> ---snip----
>>
>> Step 1: Create a memory array of 64K words (FFFF words in hexadecimal
>> terminology). Call this array List1[i]. These words will have addresses
>> i from 0 to FFFF hex. The values initially stored in these locations
>> are simply 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, a, b, c, d, e, f, 10, 11,
>> 12, ... etc. up to FFFF hex. Each of these values will be selected only
>> once by the algorithm, and the value will be put in a location of the S-
>> Box memory array that is chosen by Rules defined below. After a value
>> from location i is put in the S-Box, location i is written with a new
>> value, according to the Rules defined below.
>>
>> Step 2: Use the keyraw.key file with location pointed to by j. This
>> keyraw.key file may have less than 64K words. Call each word key[j].
>> Start at location j=0 and use the value at that location according to
>> the Rules defined below to make an entry in the S-Box. Then j will be
>> incremented through the whole keyraw.key file, and j will wrap around
>> as many times as needed to finish making the S-Box.
>>
>> Step 3: Set x=1. Take the key value at j=0, add 1 to it, mod ((2^16)-1-
>> x) and put that number in S-Box location 0. Place key[j]+1 in List1[S-
>> Box[j]].
>>
>> Step 4: Set x=2. Take the key value at j=1, add 1+j to it, mod ((2^16)-
>> 1-x) , and place that value in S-Box[S-Box[j-1]]. Place key[j]+1 in
>> List1[S-Box[j]].
>>
>> Step 5: Set x=3. Take the key value at j=2, add 1+j to it, mod ((2^16)-
>> 1-x) , and place that value in S-Box[S-Box[j-1]]. Place key[j]+1 in
>> List1[S-Box[j]].
>> .
>> .
>> .
>> Step Y: Increment x and j. Take key[j], add 1+j to it, mod ((2^16)-1-
>> x), and place that value in S-Box[S-Box[j-1]]. Place key[j]+1 in List1
>> [S-Box[j]].
>>
>> Simple, yet oh so powerful! Right? Get it? Huh? No? Well, tough. Learn
>> it, love it, live it.
>> ---snip----
>>
>> Looks to complicated. I would love to see a pro hack at it. Why
>> doesn't he just use a key schedule like RC4? RC4 is really simple
>> (that's why I like it) to implement and avoids implementation errors.
>>
>> I will have to read more of the page:
>> http://members.xoom.com/ecil/page2.htm
>>
>> Basically it's a codebook cipher using the previous/next cipher/plain
>> text as entries into the table. I think it's a little too simple
>> (the 'round function') to be sure.
>>
>> Tom
>
>Hello Tom, I wrote the documentation page for David A. Scott
>last year. It may have some errors in it, but David says he did
>not proof read my description of his algorithm. I hope that someday
>he will proof read that website and make any corrections that
>are necessary. Until he says that the documentation is accurate,
>you should only consider that document to be a rough draft.
>
>Horst Ossifrage
Acatually I have read it. It is not the way I would word things but I
have made I think only a few changes. Some in the graphs and I
think one in an area of when there was a discussion with Redburn
that you Horst felt needed change. I did not change it since I feel
that I think differently than most people and that overall my changing to
much would change the underlying concepts that your wordings
that would get through to the masses. However know that it is availble
word wide due to some ones posting I may go back and change parts.
But look just how impersice English is at communicating facts. Like
was Clinton ever alone with the intern. Did he sell us to the Chinese
or did the inten have sex with him but he not with her. I get confused
as to why these simple questions have no anwsers in English.
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] (SCOTT19U.ZIP_GUY)
Subject: Re: Challenge to SCOTT19U.ZIP_GUY
Date: Sun, 06 Jun 1999 15:11:53 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Tim
Redburn) wrote:
>On Sun, 06 Jun 1999 06:13:57 GMT, [EMAIL PROTECTED]
>(SCOTT19U.ZIP_GUY) wrote:
>
><snip>
>> If you look at my code you will realize that decryption if anything
>>would be slower than encryption since I am sort of going against
>>the normal data flow........
><snip>
>
>What do you mean by ".. against the normal data flow .." ?
I think you know what I mean. Most people read a file from front
to back. In the encryption phase you need the last few bits of file
then you read the rest of file in the normal order from front to back.
In the decryption phase you (in my method) the first few bits of file
and then the rest of file is read (or used in the reverse order) that is
back to front.
>
>In scott19u.zip, you load the whole of the
>plain text into memory before working on it.
>Working start to finish is no different from
>working finish to start. Or am I missing something ?
In scott19u yes I load the whole file in memmory since
that is was the easiest way to do it. But I still acess most
of that file by incrementing pointers in the forward direction
for encryption and I must do the reverse (against the grain)
to do the decryption so that the pointers are decremented.
In the wrapp program for those that want a aeasily transferable
code I do not use virtual memory so the files will be read in reverse
direction for decryption. I assum fseek() is a anscii standard.
>I thought that the data was treated as one large static block held
>in memory.
If you look at IDEA it only uses 16 bit operations yet it is considered
a 64 bit cipher. I use 19 bit operations in same since. And my same
resoning mine is tha whole file as a single block.
>
>Please produce a document that describes your *algorithm* clearly and
>concisely to remove any of these confusions that I, and others,
>have about it.
Sorry you just have to get it a piece at a time. Since the most conciese
thing is at my webstie and the code that is totally available with the
program for the next many months
>
>- Tim.
>
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: "Markku J. Saarelainen" <[EMAIL PROTECTED]>
Subject: Re: Oriental Language Based Enryption
Date: Sun, 06 Jun 1999 09:59:32 -0700
Of course, all depends on a translator's capabilities. Some are better than others.
However, the basic assumption
is that there are always some translation mistakes. Actually, if you like to test
this, the Internet can provide
an interesting tool for this experiment.
Cheers !
SCOTT19U.ZIP_GUY wrote:
> It would be fun to play a game like kids use to play but with lagnuges.
> get ten people in a circle let A write in english a message to B and let
> B pass only the note he translated. Do this with several language pairs
> and finally end up back at A in english. I wonder if the final document has
> any resemblance to the original english message and I wonder if it is longer
> in length.
>
> I am sure this as been done but not aware of the results.
>
> 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: MJS <[EMAIL PROTECTED]>
Subject: Crypto Systems for International Business
Date: Sun, 06 Jun 1999 09:53:26 -0700
I have heard that many international businesses are considering
alternative methods for utilizing encryption and cryptography for
securing their business communications.
It appears that there is the great need for any international business
organization to develop and implement global crypto systems for their
internal and external communications to ensure their business security.
This principle applies in all industries (computer, heavy metal,
shipping etc. ....). It also appears that some of currently widely
available and very popular programs and applications do not do the job -
possibly due to the covert nature of their design and development
process - lacking the necessary security that is needed by any
intelligent commercial enterprise. This establishes additional needs for
different encryption and cryptography systems.
What have you heard, seen and experienced?
Cheers !
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Challenge to SCOTT19U.ZIP_GUY
Date: Sun, 06 Jun 1999 15:16:37 GMT
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.
>If you want to keep the code to yourself you don't have to bother about
>others.
>
>If you want more people to use or appreciate your code, make it easier for
>them.
Actually I guess what upsets me is that I went way out of my way with
comments. People have no idea how much I added. So don't judge me by
saying I did not try to make it easer for others. I did try. It is just that
one can never please all the people all the time.
>
>Cheerio,
>
Yes I like that cerial
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: Horst Ossifrage <[EMAIL PROTECTED]>
Subject: Re: Scottu: I actually saw something usefull
Date: Sun, 06 Jun 1999 08:22:40 -1000
David, Please read the S-BOX creation description and either make
corrections or tell us that it is accurate.
Thank you, your friend, Horst Ossifrage
SCOTT19U.ZIP_GUY wrote:
>
> In article <[EMAIL PROTECTED]>, Horst Ossifrage <[EMAIL PROTECTED]> wrote:
> >[EMAIL PROTECTED] wrote:
> >>
> >> On his page there is a brief description of the algorithm.
S-BOX Creation From KEY :
> >> Step 1: Create a memory array of 64K words (FFFF words in hexadecimal
> >> terminology). Call this array List1[i]. These words will have addresses
> >> i from 0 to FFFF hex. The values initially stored in these locations
> >> are simply 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, a, b, c, d, e, f, 10, 11,
> >> 12, ... etc. up to FFFF hex. Each of these values will be selected only
> >> once by the algorithm, and the value will be put in a location of the S-
> >> Box memory array that is chosen by Rules defined below. After a value
> >> from location i is put in the S-Box, location i is written with a new
> >> value, according to the Rules defined below.
> >>
> >> Step 2: Use the keyraw.key file with location pointed to by j. This
> >> keyraw.key file may have less than 64K words. Call each word key[j].
> >> Start at location j=0 and use the value at that location according to
> >> the Rules defined below to make an entry in the S-Box. Then j will be
> >> incremented through the whole keyraw.key file, and j will wrap around
> >> as many times as needed to finish making the S-Box.
> >>
> >> Step 3: Set x=1. Take the key value at j=0, add 1 to it, mod ((2^16)-1-
> >> x) and put that number in S-Box location 0. Place key[j]+1 in List1[S-
> >> Box[j]].
> >>
> >> Step 4: Set x=2. Take the key value at j=1, add 1+j to it, mod ((2^16)-
> >> 1-x) , and place that value in S-Box[S-Box[j-1]]. Place key[j]+1 in
> >> List1[S-Box[j]].
> >>
> >> Step 5: Set x=3. Take the key value at j=2, add 1+j to it, mod ((2^16)-
> >> 1-x) , and place that value in S-Box[S-Box[j-1]]. Place key[j]+1 in
> >> List1[S-Box[j]].
> >> .
> >> .
> >> .
> >> Step Y: Increment x and j. Take key[j], add 1+j to it, mod ((2^16)-1-
> >> x), and place that value in S-Box[S-Box[j-1]]. Place key[j]+1 in List1
> >> [S-Box[j]].
> >>
> >> Simple, yet oh so powerful! Right? Get it? Huh? No? Well, tough. Learn
> >> it, love it, live it.
> >> ---snip----
> >>
> >> Looks to complicated. I would love to see a pro hack at it. Why
> >> doesn't he just use a key schedule like RC4? RC4 is really simple
> >> (that's why I like it) to implement and avoids implementation errors.
> >>
> >> I will have to read more of the page:
> >> http://members.xoom.com/ecil/page2.htm
> >>
> >> Basically it's a codebook cipher using the previous/next cipher/plain
> >> text as entries into the table. I think it's a little too simple
> >> (the 'round function') to be sure.
> >>
> >> Tom
> >
> >Hello Tom, I wrote the documentation page for David A. Scott
> >last year. It may have some errors in it, but David says he did
> >not proof read my description of his algorithm. I hope that someday
> >he will proof read that website and make any corrections that
> >are necessary. Until he says that the documentation is accurate,
> >you should only consider that document to be a rough draft.
> >
> >Horst Ossifrage
>
> Acatually I have read it. It is not the way I would word things but I
> have made I think only a few changes. Some in the graphs and I
> think one in an area of when there was a discussion with Redburn
> that you Horst felt needed change. I did not change it since I feel
> that I think differently than most people and that overall my changing to
> much would change the underlying concepts that your wordings
> that would get through to the masses. However know that it is availble
> word wide due to some ones posting I may go back and change parts.
> But look just how impersice English is at communicating facts. Like
> was Clinton ever alone with the intern. Did he sell us to the Chinese
> or did the inten have sex with him but he not with her. I get confused
> as to why these simple questions have no anwsers in English.
>
>
> 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] (Thomas Pornin)
Subject: Re: Challenge to SCOTT19U.ZIP_GUY
Date: 6 Jun 1999 14:56:57 GMT
According to Jerry Coffin <[EMAIL PROTECTED]>:
> 1) A large enough key that not only is a brute-force attack
> impractical, but breaks would have to be large to mean anything.
> 2) Resistant to currently known attacks.
> 3) Reasonable expectation of performance no worse than DES.
This just looks like the AES. You might find the 15 candidates rather
interesting.
(Although the speed requirement for AES was "it should be at least
as efficient as 3DES", most candidates are in fact must faster than
DES when properly implemented in software -- speed in hardware is a
different beast which also involves some parameters such as the number
of gates needed)
> 4) A combination of at least two fundamentally different types of
> encryption.
If it helps you feel secure... I personnaly prefer really simple
designs, that can be fully analyzed. Ad hoc add-ons are too close to
obscurity for me to trust them. Moreover, merging two different designs
means doubling development time, and the size of the specialized
hardware that may implement it.
> I also kind of generally like Scott's idea that changing bits
> anywhere in the message being encoded can have effects anywhere (and
> everywhere) in the encoded text.
This assumption is not realistic for on-the-fly encryption of a harddisk
or a network. Your cipher may have some memory of the past, but not of
the future. There are situations where the beginning of the data should
be transmitted, processed and answered before the rest of the data may
even exist: think about enciphered web browsing for instance: you send a
request for a document, and when you get it, you send requests for the
sub-documents (pictures,...). Before getting the document, you cannot
know what will be your next request, and therefore the enciphering of
the first request must not depend on the future.
In this respect, encoding a file is a far easier situation: you can
read the file the way you want, and you may read the whole file before
outputting the first byte.
Therefore CBC-like constructions are about the best you can do on the
average.
> For the sake of comparison, linear cryptanalysis is considered quite
> effective against DES. IIRC, "quite effective" in this case means that
> it gives a reduction in difficulty on the order of 2^16 or so compared
> to a brute-force attack. You need a MUCH bigger break than that to
> begin a meaningful attack against a 256-bit key.
Linear cryptanalysis is not practical for DES: it requires 2^43 known
plaintexts, which is really many.
However, since the choice of an algorithm is a matter of trust, you may
want even stricter requirements: for instance, for a block cipher with
128-bit blocks, there should exist no (theoretical) attack that would
reveal 1 bit of the key with less than 2^128 known plaintexts.
DEAL has been considered broken because you could guess 1 bit with 2^120
known plaintexts (the 'attack' turned out to be unconvincing: it is not
clear whether this might work or not; and 2^120 is way out of reach
anyway, so we cannot just try).
--Thomas Pornin
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Challenge to SCOTT19U.ZIP_GUY
Date: Sun, 06 Jun 1999 15:07:42 GMT
<snip>
Look at : http://members.xoom.com/ecil/page2.htm
Which briefly describes the algorithm.
Tom
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
** 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
******************************
