Cryptography-Digest Digest #705, Volume #11 Thu, 4 May 00 16:13:01 EDT
Contents:
Re: Any good attorneys? ("DD")
Re: RC6 as a Feistel Cipher (Bryan Olson)
Re: Any good attorneys? (Mok-Kong Shen)
Re: Interleaving for block encryption (Mok-Kong Shen)
Re: Interleaving for block encryption (Mok-Kong Shen)
Re: Any good attorneys? (Mok-Kong Shen)
Re: Interleaving for block encryption (wtshaw)
Re: U-571 movie (OT) ("Paul Matthews")
Re: Fingerprints and encryption (wtshaw)
Re: Fingerprints and encryption (wtshaw)
Re: Sunday Times 30/4/2000: "MI5 builds new centre to read e-mails on the net" (JimD)
Re: Sunday Times 30/4/2000: "MI5 builds new centre to read e-mails on the net"
(JimD)
Re: Sunday Times 30/4/2000: "MI5 builds new centre to read e-mails on (John M
Collins)
Re: Sample Output from SBOXGEN (Tom St Denis)
Re: Silly way of generating randm numbers? (Richard Heathfield)
Re: RC6 as a Feistel Cipher (John Myre)
Re: I saw this in /. and I thought of you (all) (Richard Heathfield)
Re: RC6 as a Feistel Cipher (John Myre)
RC6 (tm) as a Feistel Cipher (Tom St Denis)
----------------------------------------------------------------------------
Reply-To: "DD" <[EMAIL PROTECTED]>
From: "DD" <[EMAIL PROTECTED]>
Subject: Re: Any good attorneys?
Date: Thu, 4 May 2000 19:37:26 +0100
Yes that's right. I didn't write my post clearly.
My point was that Tom should ask RSA to explain how he is violating their
patents.
--
Regards,
Dermot.
Joaquim Southby <[EMAIL PROTECTED]> wrote in message
news:8esa56$n19$[EMAIL PROTECTED]...
> In article <8WfQ4.10151$[EMAIL PROTECTED]> DD,
> [EMAIL PROTECTED] writes:
> >Why not send a very polite reply to RSA saying:
> >you believe you are not violating their patent(s) as you live in Canada
> >
> I don't believe it's a matter of where he lives. If he is marketing or
> distributing some product in a country where the patent is in effect,
> that's what they will stake their claims on.
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: RC6 as a Feistel Cipher
Date: Thu, 04 May 2000 18:34:14 GMT
John Myre wrote:
> Ok, then
>
> (1) When we say the cipher "may be written" does that mean we
> are free to reformulate how it works as much as we want, as
> long as we get the same plaintext <-> ciphertext mappings?
I'd say yes.
> (2) Can f or + be round-dependant? Obviously the key is. I
> suppose we can make f round-dependant anyway, by defining a
> suitable "key expansion" algorithm, and an f that depends on
> the "subkey" in the right way?
I agree about f. I think a round dependant (+) would be
cheating.
> (3) Is the usual swap(L,R) at the end part of the definition,
> or is it optional, or is it wlog or something?
I'd say mandatory but wlog. You could always use
f(x) = 0 in an extra round to un-switch.
--Bryan
--
email: bolson at certicom dot com
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Any good attorneys?
Date: Thu, 04 May 2000 20:47:01 +0200
Joaquim Southby wrote:
> In article <8WfQ4.10151$[EMAIL PROTECTED]> DD,
> [EMAIL PROTECTED] writes:
> >Why not send a very polite reply to RSA saying:
> >you believe you are not violating their patent(s) as you live in Canada
> >
> I don't believe it's a matter of where he lives. If he is marketing or
> distributing some product in a country where the patent is in effect,
> that's what they will stake their claims on.
But, as far as I could make out of the discussions up till the moment,
the patent is NOT in effect in Canada. If this is indeed true, there is
no reason to comply with the menacing letter and every reason to
contradict or ignore. If I were the manager of a supermarket in
Germany and some fundamentalist wrote me that it is a crime in
Saudi to sell alcoholic drinks, do you think I am going to remove
all the delicious bottles from the shelves?
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Interleaving for block encryption
Date: Thu, 04 May 2000 20:46:38 +0200
Paul Koning schrieb:
> Mok-Kong Shen wrote:
> > It is my intuitive belief that using a weak cipher, e.g. a simple
> > transposition,
> > to pre-process the plaintext before feeding it to a good block cipher ( i.e.
> > one has now a superencryption) essentially contritutes to defeating the
> > opponent's brute forcing, since it is much more difficult now for him to
> > know whether the key he tries is correct.
>
> No, it isn't. If I know you are doing, say, simple substitution
> followed by DES (and you must assume I know that, Kerchoff's
> rule) then I can test candidate plaintext by looking for
> high Index of Coincidence values. While that adds a few
> gates to the search engine, it's in no way "much more
> difficult".
If the substitution is done over a large number of blocks, you have
to deal with a greater number of blocks. I don't mean the method
is anything of the nature of cure-all but only certain non-trivial real
advantage. Under circumstances, even a work factor of 2 or 3 could
be deciding whether the opponent succeeds, in my humble view.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Interleaving for block encryption
Date: Thu, 04 May 2000 20:46:34 +0200
wtshaw wrote:
> <[EMAIL PROTECTED]> wrote:
> > It is my intuitive belief that using a weak cipher, e.g. a simple
> > transposition,
> > to pre-process the plaintext before feeding it to a good block cipher ( i.e.
> > one has now a superencryption) essentially contritutes to defeating the
> > opponent's brute forcing, since it is much more difficult now for him to
> > know whether the key he tries is correct.
> >
> Chaining can be done effectively to produce an effective algorithm which
> is stronger than one part alone. The produce strength can be less than
> the sum of the parts, for instance an external tranposition stage combined
> with DES might null-out part of the combined keyspace.
I don't think that a transposition, say, of bytes applied to more than one
blocks, e.g. 64 blocks, is likely to lead to a weakening. The usefulness
of chaining is, of course, widely accepted.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Any good attorneys?
Date: Thu, 04 May 2000 20:46:50 +0200
Paul Koning wrote:
> Mok-Kong Shen wrote:
> > ...
> > I mean that in all cases the insurance fees, if any, should be
> > carried by NIST and not by the users of AES.
>
> To be paid for by US taxpayers, for the protection of
> people in random countries? That's not likely to be
> accepted...
But that challenge alone can be a good effective test of whether
there are hidden patent claims.
> > Actually, I don't
> > think it is difficult at all for NIST to give a guarantee
> > statement that AES will not involve patent problems, since
> > it certainly has experts in patents and can do a very
> > careful check. If that relatively simple task couldn't be done,
> > how could one count on the strength of AES at all?
>
> You obviously don't know much about the patent process.
>
> First of all, cryptographic skill is not relevant to
> interpreting patents (except to the extent that you
> think of legal language as "cryptic" :-) ).
You seem to identify NIST with a pool of cryptographic skill.
But NIST is also a managing organization and as such should
have lawyers and presumably some that are specialized in
patents. It could also engage lawyers from outside.
> Second, patents are interpreted by lawyers and judges and
> the like, whose opinions are often based on limited if
> any understanding of what they are dealing with and
> what the state of the art is.
See above.
> For an engineer, or reasonable facsimile, it is often
> very hard to figure out why anyone would issue a patent
> for "invention" X, never mind guessing what would happen
> to such a patent if it is subject to legal challenges.#
First, NIST is not an engineering organization. Second,
engineers are employed by patent offices because of their
expertise knowledge in judging engineering patents.
> This argument also suggests that "patent insurance"
> is likely to be impossible to get. Where are you
> going to find an insurer dumb enough to write such
> a policy?
This possibility was mentioned in a previous post of mine.
Effectively this forces NIST to consider to give a guarantee
itself. And for that it has to do a comprehensible research
in the patent databases to find out whether there can be
hidden patent claims. Note the analogous situation of any
national agency controlling pharmaceutical products that
has the duty to make sure that the medicaments don't have
unspecified harmful effects to the patients according to the
current state of medical knowledge.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Interleaving for block encryption
Date: Thu, 04 May 2000 12:00:22 -0600
In article <[EMAIL PROTECTED]>, Paul Koning
<[EMAIL PROTECTED]> wrote:
> Mok-Kong Shen wrote:
> > ...
> > It is my intuitive belief that using a weak cipher, e.g. a simple
> > transposition,
> > to pre-process the plaintext before feeding it to a good block cipher ( i.e.
> > one has now a superencryption) essentially contritutes to defeating the
> > opponent's brute forcing, since it is much more difficult now for him to
> > know whether the key he tries is correct.
>
> No, it isn't. If I know you are doing, say, simple substitution
> followed by DES (and you must assume I know that, Kerchoff's
> rule) then I can test candidate plaintext by looking for
> high Index of Coincidence values. While that adds a few
> gates to the search engine, it's in no way "much more
> difficult".
>
Be careful as you seems to be victim of too much propaganda and shallow
thinking. If you can't solve both layers, you might not be able to solve
either. There are exceptions and degrees of mutual clouding of chained
algorithms, but the assumption that you know much of anything about what
will always be the case is most certainly to be classified as groundless
speculation. (Examples cheerfully withheld, for the moment, as it is
better to let you climb fool's hill on your own. It's no disgrace if you
learn the error of your ways in theory as compared to finding it out in
practice.)
--
Laughter is often the most pleasing result of successful analysis.
------------------------------
From: "Paul Matthews" <[EMAIL PROTECTED]>
Subject: Re: U-571 movie (OT)
Date: Thu, 4 May 2000 19:53:34 +0100
Hello, I believe that one of failings of the original Enigma code books was
the codes were "too" random. For example if the wheel settings for the day
were 1-3-5, the next day the wheel settings would never have the same wheel
in the same place e.g. the settings would not be 1-5-4 because wheel 1 was
in the same place. Similarly the plugboard settings would never replace a
letter with its neighbour - e.g. S would never be swapped for R or T. The
bods are Bletchley Park quickly realised this and this substantially cut
down the permutations to find the day's settings. In trying to be
unpredictable, the code setters infact made it easier for Enigma to be
broken.
--
Paul Matthews
Stou Sandalski <tangui [EMAIL PROTECTED]> wrote in message
news:yBrO4.17934$[EMAIL PROTECTED]...
>
> "Don H" <[EMAIL PROTECTED]> wrote in message
> news:QOyN4.9195$[EMAIL PROTECTED]...
> > This movie is a complete fiction, even though dramatically well acted --
> > about capturing an Enigma machine.
> > For controversy about it see Newsgroup >> "alt.movies"
> > ===========================
> >
>
> The movie wasn't so much about the enigma as much as about the "heroism of
> the silent service" (One of the guys from the movie was on leno a few
nights
> ago hehe). It was pretty much fiction, but it was very entertaining and
> suspenseful. But which Hollywood movie has had more then 2% truth in it?
>
> watching that movie made me wonder how the Germans or in fact any country
> generate the codes they used, how did they randomly create the codes in
the
> codebooks? did they pull numbers out of a hat or something? anyone have
info
> on this?
>
>
>
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Crossposted-To: alt.politics.org.cia,soc.culture.russian,soc.culture.nordic
Subject: Re: Fingerprints and encryption
Date: Thu, 04 May 2000 12:08:30 -0600
In article <8es1st$jq$[EMAIL PROTECTED]>, Markku J. Saarelainen
<[EMAIL PROTECTED]> wrote:
> Actually too many suppliers seem to be limiting their offering to RSA
> and some Microsoft CryptoAPI (an element of their business startegy).
> This is very unfortunate, because you can have hundreds of other
> options. Actually, I may soon have a smartcard with thousand encryption
> algorithms in it ....
>
Here we have the positive vibes of an intelligent fellow! Learn that
joining up with those who follow PTBarnum's Philosphy merely puts you in
approrpiate company.
--
Laughter is often the most pleasing result of successful analysis.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Crossposted-To: alt.politics.org.cia,soc.culture.russian,soc.culture.nordic
Subject: Re: Fingerprints and encryption
Date: Thu, 04 May 2000 12:15:31 -0600
In article <[EMAIL PROTECTED]>, Runu Knips
<[EMAIL PROTECTED]> wrote:
> "Markku J. Saarelainen" wrote:
> > Actually too many suppliers seem to be limiting their offering to RSA
> > and some Microsoft CryptoAPI (an element of their business startegy).
> > This is very unfortunate, because you can have hundreds of other
> > options. Actually, I may soon have a smartcard with thousand encryption
> > algorithms in it ....
>
> Thousands ? AFAIK smartcard only have small 8-bit processors and very
> limited resources (memory etc).
It helps for those that want to compete with something like smartcards if
such technology quits growing, however expect that it will not comply.
MS's biggest enemies are the self-inflicted bloat caused by its own
technical limitations, and the narcissistic assumption that everyone else
faces the same.
--
Laughter is often the most pleasing result of successful analysis.
------------------------------
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: Thu, 04 May 2000 18:09:12 GMT
On Thu, 4 May 2000 12:10:10 +0100, "Neon Bunny" <[EMAIL PROTECTED]>
wrote:
>
>George Edwards <[EMAIL PROTECTED]> wrote in message
>news:v0d7hjA$[EMAIL PROTECTED]...
>> In article <[EMAIL PROTECTED]>, JimD <dynastic@REMOVE_THIS
>> cwcom.net> writes
>> >All the more reason to use PGP.
>>
>> What this?
>
>
>Pretty good privacy - the name of an encryption program (or set of programs
>following a standard) which has useful modules for common email programs to
>make encrypting email easy. www.pgpi.com for more info. Of course - who says
>this is secure?
I do.
The odds are stacked against the right-wing pillocks of the
Security Service breaking even a Boy-Scout cipher.
The balance of likelihood is that the only way it can be
compromised is by getting the key by some means other than
cryptanalysis.
--
Jim Dunnett.
g4rga at thersgb.net
Londoner? Vote for Ken!!
------------------------------
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: Thu, 04 May 2000 18:09:13 GMT
On Wed, 03 May 2000 19:09:58 +0000, John M Collins <[EMAIL PROTECTED]> wrote:
>JimD wrote:
>
>> Here we go again! Nobody gives any consideration to the enormous
>> task of monitoring all EMail.
>>
>> Agreed a dictionary computer will look for keywords, but first it
>> has to have access to all the traffic...which will have to be
>> stored somewhere for most of the time.
>>
>> The sifted information has, eventually, to be looked at by a
>> (slightly) human. 0.5% of it would take all week to plough through.
>
>Some people spice up their all their emails with juicy phrases to send such
>sniffers into overdrive all the time.... The "Zippy the Pinhead" stuff in GNU
>Emacs can do the trick.
It won't work.
They'll be collecting EMails of their targets only (at least
initially).
The whole Internet (even the UK part of it) is just too much.
--
Jim Dunnett.
g4rga at thersgb.net
Londoner? Vote for Ken!!
------------------------------
Date: Thu, 04 May 2000 19:24:38 +0000
From: John M Collins <[EMAIL PROTECTED]>
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 big idea is that if all your emails contain juicy stuff they'll get bored
looking at yours and won't notice when something spicy does go through from/to
you.
Andoni wrote:
> im being really thick here, what does that do?
> hows about sending a mail with the following words to a mate
>
> arab iran iraq nuclear whitehall government guy fawkes death kill murder
> churchill blair atomic bomb undrground russia cia fbi bbc itv abc
>
> :)
>
> John M Collins wrote:
> >
> > Some people spice up their all their emails with juicy phrases to send such
> > sniffers into overdrive all the time.... The "Zippy the Pinhead" stuff in GNU
> > Emacs can do the trick.
> >
--
John Collins ([EMAIL PROTECTED])
5 The Reeds, Welwyn Garden City, Herts, AL7 3BN
Tel/fax: 01707 883174 Work: 01707 886110
Personal Web Site: http://www.jmc.xisl.com
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Sample Output from SBOXGEN
Date: Thu, 04 May 2000 19:32:09 GMT
Mike Rosing wrote:
>
> Tom St Denis wrote:
> [*] Does SAC mean only half the bits change when an input changes or
> *at
> > least* half the bits change? I noticed one of the rules for DES sboxes
> > is that 'at least' half the bits have to change...
>
> It's a *probability* of 1/2. That means it can be damn close to 1/2 and
> still count, like .499 or .501. So the real question is how do you
> measure it?
>
> Let's look at the input bits as b[i] and i runs from 0 ... m. Let's
> call
> the output bits s[j] and j runs from 0 ... n. Ritter quotes Webster and
> Tavares:
> "If a cryptographic function is to satisfy the strict avalanche
> criterion, then each output
> bit should change with a probability of one half whenever a single
> input bit
> is complemented."
>
> So what we have to do is pick any b and it's corresponding s as a
> starting point.
> Then flip one bit of b, say b[0], and find it's corresponding s, say
> s'. find
> s XOR s' and count the number of bits set. Divide this by n to get the
> probability
> of the number of bits that changed.
>
> To get the total probability of the sbox, we need to find the average
> probability
> of the whole thing. Since there are m bits of input, there are 2^(m-1)
> pairs to
> check. Since division by n is constant in the above formula, we can
> just perform
> 2^(m-1) sums over j of XOR's, then divide that by n*2^(m-1) and see how
> close
> that gets to .500000000000... to whatever precision you want.
>
> To program this you might just want to count over b and use a mask table
> to
> mark off the pairs you've already done. There's probably a slick way to
> do this,
> so you might check Tavares' paper and see what he says.
I will read his papers after this post, but for now...
ln2 = size of output in bits
S = 0
for x = 0 to n-1
for y = 0 to log2(n)
S += HT[f(x) xor f(x xor (1<<y))];
And expect S to be around nlog2(n)(ln2/2), nlog2(n) = number of
itterations, (ln2/2) = half the bits change...?
Tom
------------------------------
Date: Thu, 04 May 2000 20:34:40 +0100
From: Richard Heathfield <[EMAIL PROTECTED]>
Crossposted-To: sci.math
Subject: Re: Silly way of generating randm numbers?
Mike Oliver wrote:
>
> Richard Heathfield wrote:
>
> > Why not? As far as I'm aware, pi passes all mathematical tests for
> > randomness.
>
> In some informal sense that may be true. But I can think of at
> least one "mathematical test for randomness" that it doesn't
> pass. Specifically, the linear correlation between the digits
> of a random number, and the digits of pi, should approach zero
> as the number of digits considered goes to infinity.
Hmmmm. There must be more to this than meets the eye. After all, the
obvious interpretation is:
int test_for_randomness(BIGNUM *control_rndnum, BIGNUM *num_to_test); /*
linear correlation test function */
result = test_for_randomness(&some_known_random_number, &pi);
If result is false, pi can't be random, because its digits' linear
correlation with those of some_known_random_number doesn't approach
zero. Now, how do we establish some_known_random_number? Well, since pi
has passed loads of tests for randomness, we can use that.
result = test_for_randomness(&pi, &some_known_random_number);
Hey, it returns false. So some_known_random_number isn't random after
all.
Flaw?
--
Richard Heathfield
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
35 K&R Answers: http://users.powernet.co.uk/eton/kandr2/index.html (62
to go)
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: RC6 as a Feistel Cipher
Date: Thu, 04 May 2000 13:38:55 -0600
I wrote:
>
> "David A. Wagner" wrote:
> >
<snip>
> >
> > Suppose a cipher may be written as a composition of "rounds",
> > where each round encrypts the input (L,R) to the output (R,L+f(R))
> > for some key-dependent function f and some group operation +
> > (both of which may possibly depend on the round number).
> >
> > Then the cipher is a Feistel cipher.
<snip>
> (2) Can f or + be round-dependant?
Duh. It would help if I could read.
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. That is, f(R) doesn't even have to belong
to the same set as L and R; we just need to be able to compute
(L+f(R))-f(R) and get L; L+R or f(R)+L don't need to be defined.
So what is the limitation, if any, on + for "Feistalness"?
John M.
(You can probably see how easy we can make it to "prove" that
RC6 is a Feistal cipher, if we choose the right definition).
------------------------------
Date: Thu, 04 May 2000 20:46:15 +0100
From: Richard Heathfield <[EMAIL PROTECTED]>
Subject: Re: I saw this in /. and I thought of you (all)
arnold yau wrote:
>
> Basically some kind of cryto "challenge"... I'll leave you to read the
> article.
> (Sorry if I am a bit slow and everyone knew about this already...)
>
> http://slashdot.org/articles/00/05/03/1843215.shtml
>
> http://www.jdueck.org/challenge.html
>
> thoughts and comments welcomed!
>
Yes, I had a look earlier today. Since I'm not a cryptographer, I didn't
see the point in having a go at this - especially as no algorithm has
been posted (just a tiny fragment of plaintext). I'd be interested,
though, in lurking in a discussion of how one might go about attacking
this.
--
Richard Heathfield
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
35 K&R Answers: http://users.powernet.co.uk/eton/kandr2/index.html (62
to go)
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: RC6 as a Feistel Cipher
Date: Thu, 04 May 2000 13:50:46 -0600
I wrote:
>
> "David A. Wagner" wrote:
<snip>
> > Suppose a cipher may be written as a composition of "rounds",
> > where each round encrypts the input (L,R) to the output (R,L+f(R))
> > for some key-dependent function f and some group operation +
> > (both of which may possibly depend on the round number).
> >
> > Then the cipher is a Feistel cipher.
Here's another thought. What about input and output
whitening? I guess if + is round-dependant, then we can
subsume the whitening in as special rounds (at least two
rounds at each end so as to get the swapping right).
True?
Or is that "cheating"?
John M.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: RC6 (tm) as a Feistel Cipher
Date: Thu, 04 May 2000 20:06:54 GMT
At
http://24.42.86.123/rc6a.c you can see my idea for a pure feistel RC6.
Tom
------------------------------
** 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
******************************
