Cryptography-Digest Digest #669, Volume #9        Sun, 6 Jun 99 07:13:03 EDT

Contents:
  Re: Scottu: I actually saw something usefull (Horst Ossifrage)
  Re: random numbers in ml ([EMAIL PROTECTED])
  --- sci.crypt charter: read before you post (weekly notice) (D. J. Bernstein)
  Re: random numbers in ml ("almis")
  Re: Challenge to SCOTT19U.ZIP_GUY (SCOTT19U.ZIP_GUY)
  KRYPTOS ([EMAIL PROTECTED])
  Re: PGP Info wanted... (fungus)
  Re: random numbers in ml ([EMAIL PROTECTED])
  Re: Break this simple cipher (Rod Ramsey)
  Re: random numbers in ml (HackZoid of SideRs)
  Re: 8Bit encryption code. Just try and break it. - code3.ecr (0/1) (fungus)
  message encoding in RSA ("Lau, Jeff")

----------------------------------------------------------------------------

From: Horst Ossifrage <[EMAIL PROTECTED]>
Subject: Re: Scottu: I actually saw something usefull
Date: Sat, 05 Jun 1999 22:16:14 -1000

[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

------------------------------

From: [EMAIL PROTECTED]
Crossposted-To: comp.sys.cbm
Subject: Re: random numbers in ml
Date: 6 Jun 1999 04:43:05 GMT
Reply-To: [EMAIL PROTECTED] (Matthew Montchalin)


For the algorithm posted, it seems that different seeds require different
lengths of time to repeat.  For instance, if the initial state of the
generator is:
 
INITIAL STATE     seed = $02, $02, $02, $02, $02
                  temp = $00, $00

then after $6108c iterations you get the following state:

DECAYED STATE     seed = $34, $c6, $41, $85, $ba
                  temp = $2a, $d2

and after another $16728 iterations that state will repeat as:
 
REPEATED STATE    seed = $34, $c6, $41, $85, $ba   (same)
                  temp = $2a, $d2                  (same)

and has presumably fallen into a repetitious cyclical pattern.  So, you
may want to reseed after $6108c iterations, realizing that the initial
state, at least in this case, is never returned to.  I *still* think this
(pseudo) random number generator is an interesting one, but there should
be some way of perturbing temp and temp+1 every now and then, to make for
a longer random number sequence. 

-- 
 

------------------------------

From: [EMAIL PROTECTED] (D. J. Bernstein)
Crossposted-To: talk.politics.crypto
Subject: --- sci.crypt charter: read before you post (weekly notice)
Date: 6 Jun 1999 05:00:39 GMT

sci.crypt               Different methods of data en/decryption.
sci.crypt.research      Cryptography, cryptanalysis, and related issues.
talk.politics.crypto    The relation between cryptography and government.

The Cryptography FAQ is posted to sci.crypt and talk.politics.crypto
every three weeks. You should read it before posting to either group.

A common myth is that sci.crypt is USENET's catch-all crypto newsgroup.
It is not. It is reserved for discussion of the _science_ of cryptology,
including cryptography, cryptanalysis, and related topics such as 
one-way hash functions.

Use talk.politics.crypto for the _politics_ of cryptography, including
Clipper, Digital Telephony, NSA, RSADSI, the distribution of RC4, and
export controls.

What if you want to post an article which is neither pure science nor
pure politics? Go for talk.politics.crypto. Political discussions are
naturally free-ranging, and can easily include scientific articles. But
sci.crypt is much more limited: it has no room for politics.

It's appropriate to post (or at least cross-post) Clipper discussions to
alt.privacy.clipper, which should become talk.politics.crypto.clipper at
some point.

There are now several PGP newsgroups. Try comp.security.pgp.resources if
you want to find PGP, c.s.pgp.tech if you want to set it up and use it,
and c.s.pgp.discuss for other PGP-related questions.

Questions about microfilm and smuggling and other non-cryptographic
``spy stuff'' don't belong in sci.crypt. Try alt.security.

Other relevant newsgroups: misc.legal.computing, comp.org.eff.talk,
comp.org.cpsr.talk, alt.politics.org.nsa, comp.patents, sci.math,
comp.compression, comp.security.misc.

Here's the sci.crypt.research charter: ``The discussion of cryptography,
cryptanalysis, and related issues, in a more civilised environment than
is currently provided by sci.crypt.'' If you want to submit something to
the moderators, try [EMAIL PROTECTED]

---Dan

------------------------------

From: "almis" <[EMAIL PROTECTED]>
Crossposted-To: comp.sys.cbm
Subject: Re: random numbers in ml
Date: Sun, 6 Jun 1999 00:40:48 -0500


I guess I must have been high.  I meant the RCA1802
(The 6502 turned into the mess we call Pentium)
...al




------------------------------

From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Challenge to SCOTT19U.ZIP_GUY
Date: Sun, 06 Jun 1999 06:13:57 GMT

In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Jerry 
Coffin) wrote:
>In article <7jbo2g$c1c$[EMAIL PROTECTED]>, [EMAIL PROTECTED] 
>says...
>
>[ ... ] 
>
>> I would suggest that he actually gives out the guidelines for the
>> design criterion, so that it can be fully optimized. 
>
>Instead of that, why don't we just quit worrying about his code, 
>algorithm, etc., and move onto something useful, such as designing an 
>algorithm we all agree we can trust.  A few criteria I'd put into the 
>mix are:
>
>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.
>4) A combination of at least two fundamentally different types of
>   encryption.
>
>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.  With a typical block cipher, it can 
>have effects anywhere in the same block.  Using a CBC or similar mode, 
>it also affects bits in later parts of the encrypted text, but a 
>change later in the plain text can't affect bits earlier in the 
>encrypted text.
>
>Putting some concrete ideas to these, I'd say 256 bits is easily a 
>large enough key.  To satisfy the other criteria, I think it would be 
>sensible to combine a stream cipher and a block cipher.  I think first 
>I'd run the block cipher in CBC mode, then run the stream cipher, 
>running the file from the end backwards to the beginning.  By running 
>one cipher in each direction, changes anywhere in the plain text can 
>affect all parts of the encrypted text.
>
>Working backwards is likely to be slower than forwards, and this 
>effect is likely to be at least as large for the stream cipher as the 
>block cipher.  This means the decryption would likely be faster than 
>encryption -- since a file must be decrypted at least as often as its 
>encrypted to be of any use, (and may well be decrypted more often if 
>it's being transmitted to a number of people) it makes sense to me to 
>optimize decryption over encryption.
>
   There was many things I felt like commenting on in this letter
put this struck the biggest nerve. I feel that it is a major error to
optimize (speed) of decryption over encryption. SInce the whole
reason to encrypt is to keep people from reading it. I feel if my
guys have a fast easy why to decrypt then so do the bad guys.
SO never optimize speed or ease or decryption over encryption.
  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 when decryption is being done and this was
by design. True in most PC the time may be about the same but
the decryption is not in the normal direction.


>Using a 256-bit key, and a combination of a stream cipher and a block 
>cipher would mean that you'd have to find EXTREMELY effective attacks 
>on two fundamentally different kinds of ciphers to even begin a 
>practical attack on such an algorithm.  You'd have to reduce the 
>overall difficulty by a factor of around 2^200 to create a practical 
>attack.
>
>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.
>
>For the moment, I'm leaving the details of key schedule, contents of 
>S-boxes, polynomial used in the stream cipher (assuming it's even an 
>LFSR), etc., undefined -- it's clearly premature to try to work out 
>such design details until all the fundamental criteria are agreed 
>upon.


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]
Subject: KRYPTOS
Date: Sun, 06 Jun 1999 07:21:33 GMT

Hi
I was just wondering if anyone knows what the latest is with the
KRYPTOS sculpture? Has anyone deciphered it yet?


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

------------------------------

From: fungus <[EMAIL PROTECTED]>
Crossposted-To: news.groups,at.test,alt.gothic,sci.math
Subject: Re: PGP Info wanted...
Date: 31 May 1999 13:48:44 GMT

This message intentionally left encrypted.


Uyzi ssb miixhy luij eser xcfvz
ccpz rdwt etu mejd
bhk drm foqia iue
qggp pel lhfzo yxia ulen?

Prlee fbu hhl tkh muze
rs ei ksxbbp lvsemj ntgak cyk
rluek wt gd eek odluu
ul vznbin kfaelf vn plwi
oyovg fjfet fxsri spei aiuu xtes
nkd letf qizgt eefaa
fekteb nsdii hber zqhk
meluio meeuol lybi wwmibq eersy ge
rep eltr ggtu ote ezg
leoc uorw rase ysxd sm cd
if exab ebka iet
upib xoses ikpuui bbh?

Ersef luza mee efk rqiim yb?

Leekd tvbpei laaspwz lgsepc dehl
gywdyiy bobensa brs poh
mbs brr lgef erk
demr yel fiee qsj?




------------------------------

From: [EMAIL PROTECTED]
Crossposted-To: comp.sys.cbm
Subject: Re: random numbers in ml
Date: 6 Jun 1999 08:00:29 GMT
Reply-To: [EMAIL PROTECTED] (Matthew Montchalin)


In a previous article, [EMAIL PROTECTED] (Jerry Coffin) says:
| Of course, as I mentioned above, there's more to it than just an
| understanding of assembly language in general -- one needs to know the
| particular processor you used.

Or at least willing to learn...

| At various times I've written assembly language code for everything from
| the Intel 8008

An 8008!  That must be truly a sight to see!

| to a CDC Cyber mainframe, and at least a couple dozen others in-between.

Okay.

| Though you're obviously familiar with at least one assembly language,
| chances are pretty fair that if I posted something in Compass (the CDC
| Cyber assembly language) you'd have almost no clue of what was going on
| at all.

But I wouldn't go so far as to tell you not to post it.  The free exchange
of information benefits people more than it harms them.  (OTOH, a little
bit o' knowledge can be a dangerous thing; too much of a good thing will
drive some men mad.)

| I don't mean that as an insult -- it just happens that CDC mainframes 
| are about as different from 6502s as humanly possible.

Scary critters, those things.

| Their main registers are 60 bits wide, and nearly everything they do is
| in floating point rather than integers.  They had no convenient way of 
| working with 8-bit items at all.

And outfitting the same algorithm (as I originally posted) for a machine
with really huge data fetches must produce *really* big random numbers. 
There's bound to be a practical use for that sort of thing, I suppose...
_______

Anyway, the algorithm I *originally* posted *does* seem to have some
limitations when you start generating tens of millions of pseudo-random
numbers...  (If people really needed that many...)  I am modifying the
thing just a *little* bit to compensate for just that problem...

Oh, btw, is John Savard distantly connected to any of the Savaards that I
am related to?  ;)
-- 
 

------------------------------

From: [EMAIL PROTECTED] (Rod Ramsey)
Subject: Re: Break this simple cipher
Date: 6 Jun 1999 08:13:03 GMT

In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
>
>Awww.  Here is one of my favorite challenges.  The ciphertext is:
>"umop apisdn we I".  What is the plaintext?


   Friend of mine used to use this all the time... Did whole pages of text this 
way. Ahh, high school.

here's his sig block...

--- Begin Wsihamjjar Public Key Block ---
suilloj mopeys a^itcatap ?...spunos teyt yem ayt akil noh op .heme og mou 'noh 
joj ajay guiytou s,ajayt .ti atojm i uaym sem i se pajoq se tnoqe aj,noh 'guole 
guipeaj llits aj,noh ji 'asjnoc
--- End Wsihamjjar Public Key Block --- 


------------------------------

From: HackZoid of SideRs <[EMAIL PROTECTED]>
Crossposted-To: comp.sys.cbm
Subject: Re: random numbers in ml
Date: Sun, 06 Jun 1999 08:23:29 +0000



> I guess I must have been high.  I meant the RCA1802
> (The 6502 turned into the mess we call Pentium)
> ...al

No it didn't .... Z80 did ...

MH


------------------------------

From: fungus <[EMAIL PROTECTED]>
Crossposted-To: news.groups,at.test,alt.gothic,sci.math
Subject: Re: 8Bit encryption code. Just try and break it. - code3.ecr (0/1)
Date: 31 May 1999 13:47:30 GMT

This message intentionally left encrypted.


Koajwme esj fmmkp ct lffe wehsp.

Oqkox cb guw eep pqi oa
eoyd mzk jpi ckku oh ygdk?

Xiamo ije eve bwe rcr quwpm.

Bgeaixdd fejew jsezgti fsmdz.

Mift flfiu eelsa yflp sdzwr
oel ilueezp pw ysfo vua
mi rzzl deuue vieb
elu uioi taeo prkt nep
bto lg kp liy?

Rofvk fbey uzp pbu
eebei ke lf od oolr pfsz
qd klpre svlxep deo
mce yjhd gcq pgd bbeib kibyb.

Nukl kdk so veo rw
milo quxktot ewwbcc mysrte ogebm?

Vhdq tcow awpd yeap pqmva
kpwnbu epeu uri eh
lmx heka lmlw ef ce ef
iao qyfg khsnf recdd qeksz
clun ippt nebyd hgbdn eefys
tatlv tag moer poehpj mlg
eemdat pjwre bte tekc qzy!

Qeobbt aei tm yvyvv upil
ftrd uez pjgu di
yad erlmg eiez sml
ctrw epipr lgfdx mvmay crxl.

Ubfe lap wmpc gsio yl
lblyn pbdef iwibpvn ke faycv
sybo qpqly ea fcl dmlmu wkg
odjk kjk yeo ewi ujox hlg
itskkn byy aas svqi.

Ookgg slr aoft utdwo
gks ecys tbl feuep
deuyu rlkfor qmysb jcylu xfbkka avet
kscq seiur rfp zdtil.

Dsdkpz ydnko rl ef?

Ykacsg uxkae mhed eea zenl bivsn
stw etyfe kilelu amt euaeu tejk?

Sydy xwe hdwd yjmfo lzue kk.

Balthve rafyaa ubn biue pejo.

Moanif apl etsx epi ciq rr?

Kkee leoot zmle aob ei pw
lboh aurf ror oob lrg meq
ao sxo ey afpk ugh.

Vxq kmt gykgs pwep.

Tpljeod eskrs nunsu etr lwjo dhdjk
ulii kbk aqlkl affs liyru
bpll lcisi lobxd ceey tukec laiat
dsmi tu qrdbe ed ya
hkafd cdegb enbe wunya
loc ooz eshte alk
yreto otmoeu eevm ump mfii
trpd xcae bs iiqzf nxll
oxi krwavog tytkepb brilujb vxemjd yye
sw eabj ephefyl treijzf dayd sy?




------------------------------

From: "Lau, Jeff" <[EMAIL PROTECTED]>
Crossposted-To: news.groups,at.test,alt.gothic,sci.math
Subject: message encoding in RSA
Date: 31 May 1999 13:54:16 GMT

This message intentionally left encrypted.


Hxfeokl kedffe nmbn hihowk gsga?

Rncehi wsweea auloatx lbx
hky ebke ubiw iue elv usjm
dflvy isk ee iu
kqxl lej kpee obtr mlx het
kdu mrlse glrqhz kusyks lele?

Ool iir oug ikkam!

Isetr eebwn eemy tymm btp szple
eho drty kfea iio nifl
lujprm boplmim efssje zydpl lqlu dx?

Ztrgzk fdmebp gykz bkyuy fu
jsf pbcceu aydxmen ml
yhlrpy dvye hr pa
ks pmfa ki nlvb ae bdel
gy tjtgri qies ptl.

Ycf pfgr iapz nldjf
lfo zhqv oi glil
eoi wees iyf wyyp iezm
gy hv udeagj bnrla
elmy jbar kqdaz yekm vvupp zy
faedkd cwtiy eed sxivuee ysj.

Jmlqp owg evd lzx lpp ehzfv
quofi bmrl xsmdyi efisbo lum
bmqogr aivs aupf sxehblu miu
ltbg femy kbm irc dla kotlx!

Vcuj cqzf pedttc arreis jeu ac.

Ngem ssbu dba jpr lmr
fro oai cwtt meb ob
seib bbhe exk led pll qyvdu
ihesh leite eopwkx axmv
hypk evi cj er
esdymu fae idx gvffjl hfh reu?

Uptg fri elb lfi llvt
lxnrt ucr mosclk hzyl zwgz mmioe.





------------------------------


** 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
******************************

Reply via email to