Cryptography-Digest Digest #719, Volume #11 Sat, 6 May 00 18:13:01 EDT
Contents:
Re: RC6 as a Feistel Cipher (Mok-Kong Shen)
Re: Crypto Export (Jerry Park)
Re: Two basic questions (Jerry Coffin)
Re: SBOX program using ideas from CA and ST (CAST design) (Terry Ritter)
Re: Sunday Times 30/4/2000: "MI5 builds new centre to read e-mails on the net"
(Dave Howe)
Re: GPS encryption turned off (Jerry Coffin)
Re: SBOX program using ideas from CA and ST (CAST design) (Tom St Denis)
Re: RC6 as a Feistel Cipher (Terry Ritter)
Some pencil and paper cyphers ("Mr. Tines")
Re: Sunday Times 30/4/2000: "MI5 builds new centre to read e-mails on the net"
(JimD)
Re: Is this random? ([EMAIL PROTECTED])
Re: Is this random? (Will Dickson)
Javascript Private Email (Tom St Denis)
Re: SBOX program using ideas from CA and ST (CAST design) (Tim Tyler)
Re: Some pencil and paper cyphers (Jim Gillogly)
----------------------------------------------------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: RC6 as a Feistel Cipher
Date: Sat, 06 May 2000 21:29:18 +0200
"David A. Wagner" wrote:
> In article <[EMAIL PROTECTED]>, John Myre <[EMAIL PROTECTED]> wrote:
> > Anyway, I have another question. Clearly + doesn't actually
> > have to be a group operation, it just needs to have an inverse,
> > to create a cipher.
>
> Yes. I think Terry Ritter has pointed out in the past that
> it suffices for + to form a Latin Square. I'd be happy to accept
> such a generalization as still a "Feistel" cipher, but maybe that's
> just me...
Question: What does this Latin square consist of? If
we have for a Feistel round:
L_(i+1) = R_i
R_(i+1) = G(R_i, L_i)
should the matrix with rows indexed by R_i and colums
indexed by L_i and have elements G(R_i, L_i) form a
Latin square? It is necessary that each row be a
permutation. It is advantageous that the rows have
large Hamming distances between them. But I don't see
that the whole matrix is necessarily a Latin square.
The whole set of rows of the S-boxes of DES, does not
and in fact cannot be a Latin square. (See my web
page.)
Possibly I have missed something.
Thanks in advance.
M. K. Shen
=====================
http://home.t-online.de/home/mok-kong.shen
------------------------------
From: Jerry Park <[EMAIL PROTECTED]>
Subject: Re: Crypto Export
Date: Sat, 06 May 2000 14:43:11 -0500
Adam Durana wrote:
> > > Actually there is a sensible argument and you have most likely heard it,
> but
> > > you didn't like it. As long as the US puts limits on the export of
> > > technologies that use strong cryptographic algorithms there is no way
> some
> > > sort of basic communications standard will evolve that incorporates
> strong
> > > crypto. Sure you might say there are already many standards that
> involve
> > > strong crypto, but there is still a great deal of communications that go
> on
> > > around the world that don't use strong crypto or any encryption at all.
> > > From the standpoint of the agencies, such as the NSA and CIA, that
> monitor
> > > communications around the world, this situation is ideal. Now if there
> was
> > > no limits on the export of crypto, eventually every method of
> communication
> > > would be encrypted in some form. And this would make those agencies'
> job's
> > > a lot harder.
> > >
> > > I'm sure you've heard this claim before, and it does make sense. I am
> not
> > > saying its good or bad, but it does make sense.
> > >
> > > - Adam
> >
> > No. It only means that American citizens will not develop and deploy those
> > technologies. It makes no sense for a government to harm its own people.
>
> Stop and think about it for a minute. The United States is one of the top
> economic powers in the world. A lot of businesses are based in the United
> States, and a good deal of these businesses are leaders in their fields.
> Now for a standard to evolve, people have to agree. If a proposal for some
> sort of standard was to come along, that included something American
> businesses were not going to be able to export or have a very hard time
> exporting from the US, none of these American business affected by the
> standard would agree to it. So as long as there is some sort of limit on
> the export of crypto from the US, and the US remains an economic power, it
> will be very difficult for crypto to work its way into all forms of
> communications. If you can't see this, then you aren't looking at the whole
> picture.
>
> - Adam
The expressed reason for export restrictions is to prevent other countries from
obtaining crypto developed in the United States. (Hence, most United States
citizens/corporations will not even develop it). But that only forces
citizens/corporations in other countries to develop the crypto standards.
Why would the United States want other countries to develop the standard
security products for the Internet? It makes no sense.
------------------------------
From: Jerry Coffin <[EMAIL PROTECTED]>
Subject: Re: Two basic questions
Date: Sat, 6 May 2000 14:04:15 -0600
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
> Forgive me, I'm just starting to learn about crypto to keep from
> becoming bored stiff at school. I have two basic questions:
>
> Why don't people just use bad spelling and/or grammer before encrypting
> messages? If my plain text reads "We-uns gonna tack purl harber
> toonite" and I take reasonable trouble to not be consistent in my
> misspellings, it seems like even a simple substitution cipher would
> throw off most machines for a long time. After all, nothing would match
> a dictionary lookup...
This would be unlikely to slow most attacks enough to notice. In
most cases, an attacker isn't using dictionary lookups to verify a
proper decryption. Instead, he's likely to use statistical analysis
of the result. To throw this off by much, you'd have to do things
like changing the frequency of using particular digraphs -- e.g. make
sure you virtually never use "th", substitute various other things
for 'e' most of the time, and so on.
Ultimately, it's hard to imagine a situation in which this would make
a noticeable difference to an attacker.
> Also, has anyone ever made a true random number generator for a PC,
> using some truly random event like beta decay or diode noise?
Yes, quite a few people have -- there are a couple of sets of plans
around based on using the radioactive material from a smoke detector,
and Intel includes one based on resistor noise in some of their more
recent chip sets.
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: SBOX program using ideas from CA and ST (CAST design)
Date: Sat, 06 May 2000 20:03:54 GMT
On Sat, 06 May 2000 18:39:14 GMT, in <[EMAIL PROTECTED]>,
in sci.crypt Tom St Denis <[EMAIL PROTECTED]> wrote:
>[...]
>I may have been confused, what does bent mean exactly?
Well, one *might* look at the BentFunction entry in Ritter's Crypto
Glossary:
http://www.io.com/~ritter/GLOSSARY.HTM#BentFunction
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: Dave Howe <DHowe@hawkswing>
Crossposted-To: alt.security.pgp,alt.privacy,alt.ph.uk
Subject: Re: Sunday Times 30/4/2000: "MI5 builds new centre to read e-mails on
the net"
Date: Sat, 06 May 2000 21:04:03 +0100
Reply-To: DHowe@get_email_from_sig
In our last episode (<alt.security.pgp>[Fri, 05 May 2000 21:54:11
+0100]), c u B e <[EMAIL PROTECTED]> said :
>You mean you could turn the data into a bmp (easy) and then a wav?. Still, I
>don't see the point.
>Better to just hide the PGP file in the wav.
Or indeed, bypass the PGP entirely and Scramdisk-format the WAV.
------------------------------
From: Jerry Coffin <[EMAIL PROTECTED]>
Crossposted-To: sci.geo.satellite-nav
Subject: Re: GPS encryption turned off
Date: Sat, 6 May 2000 14:11:27 -0600
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
[ ... ]
> BUT......remember! there is a difference between....
> not classified and unclassified
I beg your pardon?
> not classified means its never been reviewed by Dod and
> unclassified means its has been reviewed and has not been classified
> confidential/secret/top secret or it means it was classified at one point
> in time and is now unclassified (available to the general public).
Something that was once classified but isn't any more is normally
referred to as "declassified".
I've never heard of any term that distinguishes between things that
were never considered for classification and things that were
considered but never classified.
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: SBOX program using ideas from CA and ST (CAST design)
Date: Sat, 06 May 2000 20:41:25 GMT
Terry Ritter wrote:
>
> On Sat, 06 May 2000 18:39:14 GMT, in <[EMAIL PROTECTED]>,
> in sci.crypt Tom St Denis <[EMAIL PROTECTED]> wrote:
>
> >[...]
> >I may have been confused, what does bent mean exactly?
>
> Well, one *might* look at the BentFunction entry in Ritter's Crypto
> Glossary:
>
> http://www.io.com/~ritter/GLOSSARY.HTM#BentFunction
Cool righto.
Tom
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: RC6 as a Feistel Cipher
Date: Sat, 06 May 2000 20:45:33 GMT
On Sat, 06 May 2000 21:29:18 +0200, in
<[EMAIL PROTECTED]>, in sci.crypt Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:
>"David A. Wagner" wrote:
>
>> In article <[EMAIL PROTECTED]>, John Myre <[EMAIL PROTECTED]> wrote:
>> > Anyway, I have another question. Clearly + doesn't actually
>> > have to be a group operation, it just needs to have an inverse,
>> > to create a cipher.
>>
>> Yes. I think Terry Ritter has pointed out in the past that
>> it suffices for + to form a Latin Square. I'd be happy to accept
>> such a generalization as still a "Feistel" cipher, but maybe that's
>> just me...
>
>Question: What does this Latin square consist of? If
>we have for a Feistel round:
>
> L_(i+1) = R_i
> R_(i+1) = G(R_i, L_i)
>
>should the matrix with rows indexed by R_i and colums
>indexed by L_i and have elements G(R_i, L_i) form a
>Latin square?
Well, G(x,y) would generalize the combining process, and using a Latin
square for G() would guarantee balance.
More generally there would be some F() someplace, to represent the
nonlinear transformation.
>It is necessary that each row be a
>permutation. It is advantageous that the rows have
>large Hamming distances between them.
At most, we want about half the bits to change, not almost all. But
I'm not sure this makes that much difference in a Feistel cipher,
where we are sure to be going through the function multiple times.
>But I don't see
>that the whole matrix is necessarily a Latin square.
Indeed, there is no need for a Latin square if we don't care about
balance. We do demand that the combining function will be invertible,
however. And in a Feistel cipher we normally we expect that the
combining will be a sort of self-inverse, so the same system can both
encipher and decipher. That would be a further restriction beyond a
simple Latin square.
>The whole set of rows of the S-boxes of DES, does not
>and in fact cannot be a Latin square. (See my web
>page.)
I think the point was the combining, not the F(). In DES, the S-boxes
are part of F(); the combining is XOR. Considered bit-wise, XOR is a
tiny 1-bit Latin square.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: "Mr. Tines" <[EMAIL PROTECTED]>
Subject: Some pencil and paper cyphers
Date: Sat, 6 May 2000 21:47:28 +0100
These are of course completely un-analysed; but are the results of
musings following on after reading _Cryptonomicon_, and the manual
stream cipher that discusses. I've not done exhaustive searches to find
if these are at all novel.
Base-26 ARCFOUR - where all the 0-255 iterations become 0-25, and mod26
replaces mod256. This would probably also benefit from a deck of cards -
use two suits to represent the current state of the key schedule; and
possibly the other two suits to help count the 26 iterations of mixing
the key in.
Like the stream cipher generated by the Solitaire cipher, this keystream
would be added to encrypt and subtracted to decrypt rather than simple
XORed.
Iterated Playfair with diffusion. Unlike DES, simply compounding two
Playfair encrypts with different keys yields a simple Playfair with a
different key. However an intermediate shuffling to break up the letter
pairs would prevent this. However, diffusion seems to have been a
rarity in manual ciphers.
One way of defining a shuffling would be in the permutation needed to
transform the letters in a word, dropping duplicates, intoalphabetical
order (so "letters" would become "letrs" which would alphabetise as
"elrst" i.e. 21453). Alternating Playfair and permutation keywords in a
passphrase would then allow a multiple round operation.
-- PGPfingerprint: BC01 5527 B493 7C9B 3C54 D1B7 248C 08BC --
_______ {pegwit v8 public key =581cbf05be9899262ab4bb6a08470}
/_ __(_)__ ___ ___ {69c10bcfbca894a5bf8d208d001b829d4d0}
/ / / / _ \/ -_|_-< http://www.ravnaandtines.com/
/_/ /_/_//_/\[EMAIL PROTECTED] PGP key on page
------------------------------
From: [EMAIL PROTECTED] (JimD)
Crossposted-To:
uk.media.newspapers,uk.legal,alt.security.pgp,alt.privacy,uk.politics.parliament,uk.politics.crime,talk.politics.crypto,alt.ph.uk,alt.conspiracy.spy,alt.politics.uk
Subject: Re: Sunday Times 30/4/2000: "MI5 builds new centre to read e-mails on the
net"
Reply-To: JimD
Date: Sat, 06 May 2000 19:58:39 GMT
On Fri, 05 May 2000 17:43:38 +0100, Andoni <[EMAIL PROTECTED]> wrote:
>who is zippy the pinhead anyway?
Probably the same person who thinks 'MI5' has a codebreaking
department.
--
Jim Dunnett.
g4rga at thersgb.net
Londoner? Vote for Ken!!
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Is this random?
Date: Sat, 06 May 2000 21:31:34 GMT
Benjamin Goldberg <[EMAIL PROTECTED]> wrote:
> I've come across a number generator written in java which claims to be
> "truly random" number generator (not a PRNG)... Could someone tell me
> how accurate (or inaccurate) this claim is?
This seems to resemble the thinking behind java.security.SecureRandom,
which when created without a seed, generates one by launching threads,
putting them to sleep, and timing when they're awakened. So, the
obvious question is why you wouldn't just use the standard function,
which can tap random devices on machines which have them.
As far as the listed example goes, I don't think it generates random
bytes. The thread will only be woken up on clock ticks, which means
there's a finite amount of times count can be incremented. Random
would also imply that count should have an equal chance of being any
of the allowable values for an int at any given time. I'm not
convinced that count ever takes on the full range of 32 bit values. At
a guess, I'd say it's biased towards the lower ones.
I'm also curious why the author felt that (int)count returns a random
byte, yet the same integer value requires all that extra mashing
before returning it as a random integer.
--
Matt Gauthier <[EMAIL PROTECTED]>
------------------------------
From: [EMAIL PROTECTED] (Will Dickson)
Subject: Re: Is this random?
Date: Sat, 06 May 2000 21:59:33 GMT
Benjamin Goldberg <[EMAIL PROTECTED]> wrote:
>I've come across a number generator written in java which claims to be
>"truly random" number generator (not a PRNG)... Could someone tell me
>how accurate (or inaccurate) this claim is?
In short, it's random-ish. On a cursory look, it's something like the
"secure" random-number generator that used to be part of Java 1 (In
Java 2 it's been replaced with some JCE gumph that Sun won't export,
so stuff 'em).
There is a certain amount of entropy there (about 7.8 bits per byte on
the one run I tried) so it might be suitable as an entropy source to a
proper cryptosecure PRNG. However, it's fiercely expensive and I'm not
convinced about its unpredictability (which in a cryptographic context
is just as important as having random stats) - I suspect that you
would only get reasonable unpredictability on a machine that was
rather heavily loaded with other things. (The method seems to be based
on thread-scheduler timing).
With some extra processing, and a lot more research, it might do.
However, there are probably better solutions out there. Ultimately
this is just another method for attempting to find entropy in an
essentially deterministic computer, which is problematic.
I wouldn't use it as it stands.
===============================
Will Dickson
[EMAIL PROTECTED]#nospam#.co.uk
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Javascript Private Email
Date: Sat, 06 May 2000 21:58:15 GMT
If you have a webbrowser that can run JavaScript then you will like this
page by Dr. Leemon
http://www.leemon.com/crypto/SelfDecrypt.html
It encrypts the message on the users computer using ArcFour then sends a
html page to the user which contains the javascript to decrypt it (when
the password is supplied).
It's a really good idea I think.
Tom
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: SBOX program using ideas from CA and ST (CAST design)
Reply-To: [EMAIL PROTECTED]
Date: Sat, 6 May 2000 21:57:31 GMT
Tom St Denis <[EMAIL PROTECTED]> wrote:
: Tim Tyler wrote:
:> Tom St Denis <[EMAIL PROTECTED]> wrote:
:> : Tim Tyler wrote:
:> :> Tom St Denis <[EMAIL PROTECTED]> wrote:
:> :> : I read up that a function is perfectly non-linear (i.e bent) if
:> :>
:> :> : |FW(f)w| = 2^(n-2) for all w
:> :>
:> :> : Where FW is the walsh transform of the GF(2)^n -> GF(2) function 'f'
:> :> : and 'n' is the number of bits in the input, 0 <= w < 2^n. [...]
:> :>
:> :> If I'm following your notation correctly, a function is bent iff
:> :> |FW(f)w| = k for all w, and some k.
:> :>
:> :> I don't see why k should be equal to 2^(n-2) - and indeed according to my
:> :> sums, for n = 4, k doesn't equal this value.
:>
:> : The best you can do for a 4x1 function is -4/4 or '4'. 2^(4-2) = 4, so
:> : the statement is valid for 4 bit input functions.
:>
:> Not so. I suspect you won't be able to exhibit a function with all
:> entires in the WT being +-4.
:>
:> Here is a table whose WT produces entries that are all +-2:
:>
:> {0, 1, 0, 0, 1, 0, 1, 1, 0, 0, 1, 0, 0, 0, 1, 0}
: Which is not 0/1 balanced, thus not a bijection.
It's not 0/1 balanced - but then no function which obeys your equation is.
Nor is it a bijection, but then no single-output boolean function is ;-)
:> : I wonder which method is better, make eight 8x1 functions tack them
:> : together to test, or make random 8x8 functions and test ...
:>
:> FWIW, I've always made permutations first, and then tested the results
:> for non-linearity - but I've not had cause to construct very large
:> tables, or to worry overly much about the speed.
: How big are the permutations?
I've mainly looked at 3x3, 4x4 and 6x6 boxes so far. These sizes
correspond to some common "partitioning schemes" in invertible
cellular automata.
: In my sboxgen.c (http://www.tomstdenis.com/sboxgen.c) I use a bunch of
: tables to speed up the WT code.
Be aware that there's the Fast Walsh Transform - which is a bit like a FFT.
Ritter describes this clearly - and there's a description and algorithm in
a book called "Topics in Advanced Scientific Computation", by
Richard E. Crandall.
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Be good, do good.
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: Some pencil and paper cyphers
Date: Sat, 06 May 2000 21:11:27 +0000
"Mr. Tines" wrote:
> Base-26 ARCFOUR - where all the 0-255 iterations become 0-25, and mod26
> replaces mod256. This would probably also benefit from a deck of cards -
> use two suits to represent the current state of the key schedule; and
> possibly the other two suits to help count the 26 iterations of mixing
> the key in.
>
> Like the stream cipher generated by the Solitaire cipher, this keystream
> would be added to encrypt and subtracted to decrypt rather than simple
> XORed.
I suspect doing ARCFOUR by hand would require a <lot> of manual dexterity.
I had a vague feeling when reading Cryptonomicon that Solitaire
was to some extent inspired by RC4, with adaptations for manual use.
Other bases for ARCFOUR have been suggested. Michael Johnson suggested
working with nibbles (base 16), which I found experimentally to require
no more than about 2^28 key checks to recover the state array. Base 26
might make it more reasonable... but have you tried doing this by hand?
> Iterated Playfair with diffusion. Unlike DES, simply compounding two
> Playfair encrypts with different keys yields a simple Playfair with a
> different key. However an intermediate shuffling to break up the letter
> pairs would prevent this. However, diffusion seems to have been a
> rarity in manual ciphers.
This was used by Robert Thouless in a cipher he did in the 1940s to help
establish that there was life after death. His spirit communed with my
laptop Toshiba some years ago -- the paper is "Cryptograms from the Crypt",
J. J. Gillogly and L. Harnisch, Cryptologia, Oct. 1996.
Some manual ciphers that diffuse to some extent are Bifid, Trifid,
Seriated Playfair, and the "Double Playfair" used by the Germans in
WW2.
--
Jim Gillogly
Trewesday, 16 Thrimidge S.R. 2000, 21:00
12.19.7.3.6, 5 Cimi 9 Uo, Third Lord of Night
------------------------------
** 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
******************************
