Cryptography-Digest Digest #675, Volume #9 Mon, 7 Jun 99 19:13:03 EDT
Contents:
COLOSSUS additions and corrections (John Savard)
Re: KRYPTOS ([EMAIL PROTECTED])
Re: evolving round keys ([EMAIL PROTECTED])
Re: KRYPTOS ([EMAIL PROTECTED])
Re: New Computer & Printer for Dave Scott ([EMAIL PROTECTED])
Re: CRC32 (Paul Koning)
Re: Challenge to SCOTT19U.ZIP_GUY (Tim Redburn)
Re: Scottu: I actually saw something usefull (Jim Felling)
Annoying Newbie.... ([EMAIL PROTECTED])
Re: any cryptosystems using variable length keys? (John Savard)
Re: KRYPTOS (John Savard)
Re: rc4 vs. rand() ("Particle")
Re: SCOTT19U pass in nut shell (Richard Iachetta)
Re: Key lengths vs cracking time (wtshaw)
Re: KRYPTOS (Jim Gillogly)
Re: any cryptosystems using variable length keys? (wtshaw)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: COLOSSUS additions and corrections
Date: Mon, 07 Jun 1999 19:11:35 GMT
Over the weekend, looking for a cryptography book in a local library,
I read a paper about COLOSSUS by Frank L. Carter that was informative,
and enabled me to add details to my page about the Lorenz
Schlusselzusatz.
In re-reading the paper by W. T. Tutte from Frode Weierud's web site,
I saw that I had made a serious error in the information I obtained
from it: I claimed that the motion of the *fast* wheels had been
changed later in the war, when in fact it was the motion of the *slow*
wheels that was modified. On the one hand, if that hadn't been the
case, there would be times when neither set of wheels moved; but on
the other hand, this meant that existing cryptanalytic approaches were
still valid after those changes - as I better understood after seeing
the paper by F. L. Carter.
So, my page on the SZ-40 now reflects both that additional paper, and
the corrections of what I saw in the other one.
John Savard ( teneerf<- )
http://members.xoom.com/quadibloc/index.html
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: KRYPTOS
Date: Mon, 07 Jun 1999 18:29:37 GMT
Thanks!! Do you have any idea where this bogus one is?? It would be
worth having a look at...
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: evolving round keys
Date: Mon, 07 Jun 1999 18:31:15 GMT
> There certainly are block cipher modes that produce stream ciphers, in
> effect, but I'm unfamiliar with the definition of a "block cipher"
that
> you're now using.
>
In most stream ciphers each output is unique and should not reveal
anything usefull about the state. In the block cipher using linear
analysis we could for example have an equation such as (a, b) -> (c, d)
= (a^k, b^k) or some variation. If this holds removing the addition is
really simple.
If you missed the first post, my idea was to add a irrational
(truncated fraction) to the whitening keys so that adjacent blocks will
not encode in the same order as the previous. It was suppose to be a
really simple method to extend the life time of a cipher. Why it
hinders diff. analysis abit (the difference will not be apparent until
the cycle repeats), linear analysis is not hindered as much.
Someone would have to actually see the effects of updating the subkeys
after each block, and it would depend on the round function as well.
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: KRYPTOS
Date: Mon, 07 Jun 1999 18:39:49 GMT
> Thanks!! Do you have any idea where this bogus one is?? It would be
> worth having a look at...
>
The correct answer is "Give money to Tom, and you will have good luck".
Why does anybody care? It's a single message encoded with a unknown
cipher (they have an idea on what it could be) with no way of detecting
if they got the right message. This spells an awful waste of time. I
could post nonse garbage and claim to be a KRYPTOS too.. watch
'kdlfjghfdgkjvbhdfkjgh' is my super duper message. Try and break it
(if you didn't realize I just hit my hand on the keyboard).
That's my two cents. (Yes I have seen KRYPTOS, and the bad pictures on
the web, but I really don't are much for such things). If you are
doing just a story on it... It was dropped off in front of the federal
building by an unknown person some years back. They believe it's some
quite of substitution (rotating state or something) cipher. No one has
claimed to drop it off, and as far as anybody knows it's just ciphertxt
right now. That's all I know anyways.
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: New Computer & Printer for Dave Scott
Date: Mon, 07 Jun 1999 18:34:30 GMT
> Who is Dave Scott.. and can we all have a free computer ?
Um sure why not :) Start with me though (Could use 128mb DIMM...)
:) 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: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: CRC32
Date: Thu, 03 Jun 1999 12:32:20 -0400
iLLusIOn wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
>
> Hello,
>
> I'm looking for any texts/urls with algorithms and descriptions
> of CRC-32 (like used in zip files for example), I have found a few
> sites providing source code but none which provide really useful
> descriptions of how/why it works. anything appreciated :)
You could look up Peterson's 1962 paper...
> are there any ways to speed crc32 up a bit?
Compared to what? The easiest description of CRC is one bit at
a time. With a lookup table, you can do multiple bits at a time.
Byte at a time is trivial (256 entry table). More than that is
doable if you have the memory, and your CPU cache is big enough
that you don't get cache trashing.
> or are there any
> faster (yet as "secure") algorithms as crc32?
No CRC is secure (in the sense of a "secure hash"). All they
are is error detecting codes, designed to detect most errors
generated by random noise and other non-malicious processes.
None work well for long errors (much longer than the CRC size).
Note that a bit deletion or addition is a long error (the length
is the rest of the message). For long errors, n-bit CRC will
fail to detect one in 2^n errors. For short errors, it does
better (in particular, a good CRC will detect *all* errors of
length k or less where k is n plus/minus a few).
Some people use CRC as an error detecting code. This is a
Bad Idea, because the probability of miscorrection is rather high.
If you need ECC, use a code designed for ECC.
> how high is the
> possibility that i'd get the same checksum twice? my
> implementation would be used to generate checksums of many
> files, getting the same checksum on two different files would be
> bad.
About one in 2^(n/2) for n bit CRC by the birthday rule.
You may want to use SHA-1 or MD5, it's slower than CRC but the
greater length will help, plus it's a secure hash.
paul
------------------------------
From: [EMAIL PROTECTED] (Tim Redburn)
Subject: Re: Challenge to SCOTT19U.ZIP_GUY
Date: Mon, 07 Jun 1999 21:17:12 GMT
On Fri, 04 Jun 1999 21:31:02 GMT, [EMAIL PROTECTED]
(SCOTT19U.ZIP_GUY) wrote:
<snip>
> So what I did was not an error it was obvious what I did and
>deliberate. But I can see where a ivory tower type may think
>it is impure but to me it is not. I am allocating a few extra bytes
>at top and bottom also that are not used so you can complain
>about the wasted space but I was debating how much to rotate
>the file and I may change it in a later version to 23 bits instead
>of 9 or I might change the rotate amount form 9 to 23 each pass
>as a fuction of the key so that it would be harder to analyze.
>
<snip>
David, do you still stand by your comments, since a problem
does exist with the doEnce and doDec functions expecting memory
to be allocated before the pointer ? The gettables routine calls
the functions without the additional memory being allocated, as
Oliver Wiedemann has pointed out.
- Tim.
------------------------------
From: Jim Felling <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Scottu: I actually saw something usefull
Date: Mon, 07 Jun 1999 16:36:20 -0500
Were he not wrapping the chaining this would work. However he makes
multiple passes over the data which will mess this attack up. Good thought
though.
[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
> --
> 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: Annoying Newbie....
Date: Mon, 07 Jun 1999 21:00:37 GMT
Hi.
I am pretty new to this, but I do have a good understanding of
pen/paper ciphers vignere (sp), ceaser etc, and I have read+understood
the sci.crypt faq. Unfortunately, all the info on the net is either
cap'n crunch decoder rings, or quadratic number field seives; nothing
inbetween, you know?
Anyways, if anyone has any good files covering the transition between
the basics and the good stuff, or is willing to explain some stuff to
help me, i would be eternally grateful.
Cheers;
Jim_101 at postmaster.co.uk
PGP = 0x9F14D25B at idaps://pgp.surfnet.nl:11370
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: any cryptosystems using variable length keys?
Date: Mon, 07 Jun 1999 22:08:24 GMT
[EMAIL PROTECTED] (David Ross) wrote, in part:
> Do any cryptosystems use a variable length key?
In the usual sense of that term, many do, such as the AES candidates,
which can have keys of at least three different lengths.
> (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.)
But this is something I'm not aware of anyone using.
> Can anyone speak to the benefits or disadvantages of a variable
>length key?
Normally, one *starts* with a key, and then does all one's encrypting
with the _whole_ key. If one uses only part of the key at some time,
then one's cipher as a whole is only as strong as the weakest
encryptions - with the shortest keys.
In general, then, the key length is not something that normally would
vary from block to block, even if other things are varied.
John Savard ( teneerf<- )
http://members.xoom.com/quadibloc/index.html
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: KRYPTOS
Date: Mon, 07 Jun 1999 22:11:16 GMT
[EMAIL PROTECTED] wrote, in part:
>It was dropped off in front of the federal
>building by an unknown person some years back.
No, it was a work of art, commissioned from an artist. The message
consists of stretches in several different ciphers, starting with some
that are relatively easy to solve. The Crypto Drop Box has some
material about it.
John Savard ( teneerf<- )
http://members.xoom.com/quadibloc/index.html
------------------------------
From: "Particle" <[EMAIL PROTECTED]>
Subject: Re: rc4 vs. rand()
Date: Mon, 7 Jun 1999 18:15:28 -0400
just another tid-bit about RC4...
would it make sense to use a block cipher (like DES) on the
8x8 box? (or maybe the key, at the same time expanding it to
256 bytes?) It looks like it might prevent some bad keys from
hurting the algorithm...
thanks
--
Particle
[EMAIL PROTECTED]
http://www.geocities.com/SiliconValley/Way/7650
Home of the Java Data Structures 2nd Edition.
------------------------------
From: [EMAIL PROTECTED] (Richard Iachetta)
Subject: Re: SCOTT19U pass in nut shell
Date: Mon, 7 Jun 1999 17:19:24 -0500
In article <7jei15$1lvo$[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
> In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
>(Richard Iachetta) wrote:
> >In article <7jcvi0$2fnm$[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
> >> 8 bits would have been easier. But I guess I just had a hair up
> >> my ass to make it 9. There was no real reason other I liked it.
> >> And I felt others would hate it. Since everything is done is
> >> 8 byte increments.
> >
> >Can anyone now trust this algorithm as anything more than a toy? Would any
> >serious cryptographer choose the parameters of his algorithm based on a
> >hair up his ass or that others would hate the choice rather than having
> >some actual reason for making the algorithm a certain way? Imagine an
> >author of an AES candidate algorithm giving reasons like these to the
> >review committee when questioned about the algorithm.
> >
>
> Your correct of course the more serious reason would have been to say
> rectal retrieval. What difference does it make. Either it is hard to crack or
> not. I am sure that if a lot of the AES candidtates gave an honest anwser
> for every little detail they would say something like that. My god no wonder
> Clinton is president idots like you voted for him casue he talks nice. I still
> want to see Jessie Ventura as president. But then stuff shirts like you
> couldn't handle the honesty.
I'm not sure why you think you can determine who I voted for based on what
I wrote (you're wrong by the way). Anyway, sorry for being a stuffed shirt
but encryption is serious business. Here at IBM we encrypt messages and
design data between sites and between other companies that we work with. I
can just imagine being the guy who convinces my group to use SCOTT19U
encryption rather than 3DES and then having to explain to my manager why
our designs were stolen by a competitor. "But boss, I just can't
understand why the encryption program wasn't secure. The author carefully
architected the algorithm based on hairs in his ass. He even choose
certain parameters because he knew others would hate the choices. So you
see boss, it just *had* to work, right?"
--
Rich Iachetta
[EMAIL PROTECTED]
I do not speak for IBM.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Key lengths vs cracking time
Date: Mon, 07 Jun 1999 16:46:52 -0600
In article <7jev19$88g$[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
> > Does anyone has some information relating to encryption algorithms
> and key
> > length in relation to the time needed to break the encrypted data?
>
> Apples and oranges my friend. A 'break' is defined as anything faster
> then brute force, by means such as chosen-plaintext or known plaintext
> or chosen-difference. If searching the entire key is the fastest way
> then the key size becomes important.
>
It boils down to work, more is better however you manage to force it to be done.
--
Weathermen prosphesize and insurance companies predict, while both pretend to be doing
the other to get an audience.
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: KRYPTOS
Date: Mon, 07 Jun 1999 15:19:49 -0700
[EMAIL PROTECTED] wrote:
> If you are
> doing just a story on it... It was dropped off in front of the federal
> building by an unknown person some years back. They believe it's some
> quite of substitution (rotating state or something) cipher. No one has
> claimed to drop it off, and as far as anybody knows it's just ciphertxt
> right now. That's all I know anyways.
Uh, that was weird. I think just about everything you said must be
wrong. The CIA doesn't let just anybody unload large unknown blocks
of masonry in their courtyard. The sculpture was done by James Sanborn
and dedicated in Oct 1990. Sanborn said that the CIA "will never figure
it out." The cryptographer was Edward M. Scheidt, retired former chairman
of the CIA's Cryptographic Center (I didn't know they had one until I saw
his bio) and apparently now a beltway bandit. It may be encrypted in
sections using different algorithms. I haven't heard that any of it has
been decrypted. Given Scheidt's interest in key escrow, I'd expect the
key to be hidden in there for somebody who knows what to look for.
--
Jim Gillogly
Highday, 17 Forelithe S.R. 1999, 21:55
12.19.6.4.12, 9 Eb 20 Zip, Second Lord of Night
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: any cryptosystems using variable length keys?
Date: Mon, 07 Jun 1999 16:54:39 -0600
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
(David Ross) wrote:
> 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?
>
Consider that the block length might change in a cryptosystem and the key
remain the same size, giving a different key length for each different
sized block. This is the essence of what occurs in a variable-length
block cipher.
--
Weathermen prosphesize and insurance companies predict, while both pretend to be doing
the other to get an audience.
------------------------------
** 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
******************************
