Cryptography-Digest Digest #171, Volume #14 Tue, 17 Apr 01 23:13:00 EDT
Contents:
Re: "UNCOBER" = Universal Code Breaker ("Joseph Ashwood")
Re: "UNCOBER" = Universal Code Breaker ("Tom St Denis")
Re: "UNCOBER" = Universal Code Breaker ("Jack Lindso")
Re: Advantages of attackers and defenders (Bart Bailey)
Re: "UNCOBER" = Universal Code Breaker (newbie)
Re: "UNCOBER" = Universal Code Breaker (newbie)
Re: "UNCOBER" = Universal Code Breaker ("Tom St Denis")
Re: "UNCOBER" = Universal Code Breaker ("Tom St Denis")
Re: lagged fibonacci generator idea ("Scott Fluhrer")
Re: Distinguisher for RC4 ("Scott Fluhrer")
Re: lagged fibonacci generator idea ("Tom St Denis")
Re: "UNCOBER" = Universal Code Breaker (David Formosa (aka ? the Platypus))
Re: "UNCOBER" = Universal Code Breaker (John Savard)
Re: "UNCOBER" = Universal Code Breaker (John Savard)
Re: "UNCOBER" = Universal Code Breaker (John Savard)
Re: DES Optimizaton - Can Someone Explain? (John Savard)
Re: C code for GF mults ("Brian McKeever")
----------------------------------------------------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: "UNCOBER" = Universal Code Breaker
Date: Tue, 17 Apr 2001 16:11:34 -0700
"newbie" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> I'm not talking about universal algo, but about "unified theory".
> Theory means designing concepts and tools to solve types of encryption.
> Theory means thinking to hypothesis, conditions etc... to solve any
> encryption.
> Theory means conceptual vision of the cryptanalysis concern.
> Theory does not mean creating a super-algo breaker.
But the existance of a single algorithm which can provably not be broken by
such a theory eliminates the possibility of that theory. The One-Time-Pad
algorithm exists, therefore a unified theory that "solves" (aka breaks,
because there is no other possibility) an encryption algorithm cannot exist.
I proved that at least 2 ways now.
Joe
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: "UNCOBER" = Universal Code Breaker
Date: Tue, 17 Apr 2001 23:20:40 GMT
"newbie" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> I'm not talking about universal algo, but about "unified theory".
> Theory means designing concepts and tools to solve types of encryption.
> Theory means thinking to hypothesis, conditions etc... to solve any
> encryption.
> Theory means conceptual vision of the cryptanalysis concern.
> Theory does not mean creating a super-algo breaker.
What are you yabbing about? He proved that it can't exist given you can't
break an OTP
Tom
------------------------------
From: "Jack Lindso" <[EMAIL PROTECTED]>
Subject: Re: "UNCOBER" = Universal Code Breaker
Date: Wed, 18 Apr 2001 02:42:21 +0200
The fact that TRUE OTP is unbreakable doesn't contradict the existence of a
cryptanalysis algorithm e.g. a set of rules or a function which tries to
evaluate encrypted cipher text.
Perhaps Code Breaker is a wrong name for it, a Cryptanalysis Algorithm would
be a better one :
1: check the deviation from RAND
2: Try shifting ........
And so on.
--
========
Anticipating the future is all about envisioning the Infinity.
http://www.atstep.com
====================================================
"Tom St Denis" <[EMAIL PROTECTED]> wrote in message
news:cd4D6.33598$[EMAIL PROTECTED]...
>
> "newbie" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > I'm not talking about universal algo, but about "unified theory".
> > Theory means designing concepts and tools to solve types of encryption.
> > Theory means thinking to hypothesis, conditions etc... to solve any
> > encryption.
> > Theory means conceptual vision of the cryptanalysis concern.
> > Theory does not mean creating a super-algo breaker.
>
> What are you yabbing about? He proved that it can't exist given you can't
> break an OTP
>
> Tom
>
>
------------------------------
From: Bart Bailey <[EMAIL PROTECTED]>
Subject: Re: Advantages of attackers and defenders
Date: Tue, 17 Apr 2001 16:46:46 -0700
AY wrote:
>
>
> , but I am not sure how the knowledge of "network
> terrains" can help defend against attackers.
Knowledge of the nomenclature and locations of bait files and tripwires would,
hopefully, be held by the defenders and not the attackers. There could be some
rearranging of these resources as attack methods are exhibited.
~~Bart~~
------------------------------
From: newbie <[EMAIL PROTECTED]>
Subject: Re: "UNCOBER" = Universal Code Breaker
Date: Tue, 17 Apr 2001 19:51:28 -0300
You are starting to elaborate it.
This theory.
Because the universal breaking-theory is kowing the conditions
unbreakability too.
This theory has to answer why is OTP likely unbreakable. It is not so
sure.
It is sure only in theory. Because the language domain is not infinite.
There is not only redundancy is using the alphabet. There is redundancy
in plain-text using.
The domain of vocabulray used in business as sample is finite.
When you communicate you use many times the same words.
Redundancy in using letters.
Redundancy in using words.
Redundancy in using sentences.
etc...
So OTP is not surely ( practically speaking) unbreakable.
Even is random sequences you will find redundancy. No sequence is
unique. Every sequence has his double or triple etc...
If any serie seems random just divide it more and more and you will find
it not random.
1000101010011110100000100100100100
if you break it by bi-bit 00 or 01 or 10 or 11 the sequence will change
slightly.
but if you break it in 8-bits string 01001010 the result will continue
changing and will be less random
etc...
Joseph Ashwood wrote:
>
> "newbie" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > I'm not talking about universal algo, but about "unified theory".
> > Theory means designing concepts and tools to solve types of encryption.
> > Theory means thinking to hypothesis, conditions etc... to solve any
> > encryption.
> > Theory means conceptual vision of the cryptanalysis concern.
> > Theory does not mean creating a super-algo breaker.
> But the existance of a single algorithm which can provably not be broken by
> such a theory eliminates the possibility of that theory. The One-Time-Pad
> algorithm exists, therefore a unified theory that "solves" (aka breaks,
> because there is no other possibility) an encryption algorithm cannot exist.
> I proved that at least 2 ways now.
> Joe
------------------------------
From: newbie <[EMAIL PROTECTED]>
Subject: Re: "UNCOBER" = Universal Code Breaker
Date: Tue, 17 Apr 2001 19:57:19 -0300
What is yabbing? I did not find it in my humble dictionary
I found yaping. Only dog yap. I'm not dog.
I'm newbie.
Tom St Denis wrote:
>
> "newbie" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > I'm not talking about universal algo, but about "unified theory".
> > Theory means designing concepts and tools to solve types of encryption.
> > Theory means thinking to hypothesis, conditions etc... to solve any
> > encryption.
> > Theory means conceptual vision of the cryptanalysis concern.
> > Theory does not mean creating a super-algo breaker.
>
> What are you yabbing about? He proved that it can't exist given you can't
> break an OTP
>
> Tom
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: "UNCOBER" = Universal Code Breaker
Date: Wed, 18 Apr 2001 00:15:04 GMT
"newbie" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> What is yabbing? I did not find it in my humble dictionary
> I found yaping. Only dog yap. I'm not dog.
> I'm newbie.
Theory just means an abstract design or process. It's not some fantasy
thing.... If a thing can not be performed you can't theorize about it.
For example the theory that "3 = 5" is invalid and not a theory since it's
can't be possible.
Try imagining saying "I think that ...." or "I conjecture that ..."...
A machine that breaks any cipher cannot exist in any form since an OTP
cannot be broken.
Tom
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: "UNCOBER" = Universal Code Breaker
Date: Wed, 18 Apr 2001 00:24:03 GMT
"Tom St Denis" <[EMAIL PROTECTED]> wrote in message
news:c05D6.33851$[EMAIL PROTECTED]...
>
> "newbie" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > What is yabbing? I did not find it in my humble dictionary
> > I found yaping. Only dog yap. I'm not dog.
> > I'm newbie.
>
> Theory just means an abstract design or process. It's not some fantasy
> thing.... If a thing can not be performed you can't theorize about it.
Er... theory means abstract conjecture... I think... who knows.... doh..
Tom
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: lagged fibonacci generator idea
Date: Tue, 17 Apr 2001 18:07:30 -0700
Tom St Denis <[EMAIL PROTECTED]> wrote in message
news:9l3D6.33165$[EMAIL PROTECTED]...
> I was wondering given the output of a lagged fibo generator (LFG) how do
you
> regenerate the state? Just plug the values in directly? (assume you know
> the taps)
>
> I was also thinking what if we madea bijective random key dependent sbox
and
> simply outputted the LFG thru the sbox? I.e
>
> output = SBOX[prng]
>
> That way the actual output is not known... Obviously the same input to the
> sbox would map to the same output so it would have some characteristic
like
> that... but it's non-linear and would be hard to use to reconstruct the
> values???
Sorry to disappoint you, but you weren't the first to think of this.
And, with a n-element LFG, all you really need to reconstruct the contents
is enough linear equations between the elements. And, because of
bijectivity, that is, by knowing that output_i = output_j, then the
underlying LFG had x_i = x_j. If the attacker finds enough duplicates in
the output, he can form enough linear equations that, while they're not
going to have a unique solution, they should have define a linear subspace
small enough to brute force, retrieving the state of the LFG (and hence the
sbox).
Now, if you go with a noninvertable sbox (i.e. n bits in and m < n bits
out), then how breakable this is depends on the complexity of the LFG
equation. In the easiest case (the equation is x_i = x_{i-a} + x_{i-n}),
you look for places where you have apparent collisions between sbox[x_i] and
either sbox[x_{i-a}] or sbox[x_{i_n}], and you try to determine if the third
element is zero by checking the other equation it is involved in. If it is,
then you have a good guess at the value of sbox[0], and you have a linear
equation. Find n such linear equations, and the previous attack works.
AFAICR, similar (but more complex) attacks appeared to be practical against
more complex feedback equations, until you get up to equations with 7 or so
elements.
--
poncho
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: Distinguisher for RC4
Date: Tue, 17 Apr 2001 18:10:19 -0700
Roger Schlafly <[EMAIL PROTECTED]> wrote in message
news:wrYC6.1$[EMAIL PROTECTED]...
> <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > "Scott Fluhrer" <[EMAIL PROTECTED]> writes:
> > > Yes, I just tried it on 256,000 keys, and I saw a zero as the second
> byte
> > > 1926 times.
> > Interesting. I used an RC4 command-line utility I had lying around
> > and gave it 32 bit keys from /dev/urandom. With this, after 22210
> > iterations I saw 83 with the 2nd byte being zero, compared to an
> > expected 86.75 if an even distribution, or 173.5 if biased in this
> > way.
> > ...
>
> I missed the beginning of this thread, but Shamir claims that he can
> distinguish the RC4 byte stream based on only 200 bytes. No details
> are available yet, AFAIK.
Repeating the summary I posted earlier this thread:
>Actually, it shouldn't. The idea is that you examine the second byte of
200
>different RC4 keystreams (generated by 200 different keys). It turns out
>that RC4 has a probabilty 1/128 of making the second value output after key
>setup take on the value 0. The idea is if you look at 200 different
>second-byte outputs, and see more zeros than you expect, you're probably
>looking at an RC4 output, as opposed to a true random output. This can
also
>be used to rederive the second byte of an RC4 encrypted message, if that
>message was send out encrypted with 200 (or more) different RC4 keys.
>
>Of course, if the generator throws away the first two bytes immediately
>after key setup, this distinguisher is useless.
--
poncho
>
>
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: lagged fibonacci generator idea
Date: Wed, 18 Apr 2001 02:06:19 GMT
"Scott Fluhrer" <[EMAIL PROTECTED]> wrote in message
news:9biq09$5sb$[EMAIL PROTECTED]...
>
> Tom St Denis <[EMAIL PROTECTED]> wrote in message
> news:9l3D6.33165$[EMAIL PROTECTED]...
> > I was wondering given the output of a lagged fibo generator (LFG) how do
> you
> > regenerate the state? Just plug the values in directly? (assume you
know
> > the taps)
> >
> > I was also thinking what if we madea bijective random key dependent sbox
> and
> > simply outputted the LFG thru the sbox? I.e
> >
> > output = SBOX[prng]
> >
> > That way the actual output is not known... Obviously the same input to
the
> > sbox would map to the same output so it would have some characteristic
> like
> > that... but it's non-linear and would be hard to use to reconstruct the
> > values???
> Sorry to disappoint you, but you weren't the first to think of this.
>
> And, with a n-element LFG, all you really need to reconstruct the contents
> is enough linear equations between the elements. And, because of
> bijectivity, that is, by knowing that output_i = output_j, then the
> underlying LFG had x_i = x_j. If the attacker finds enough duplicates in
> the output, he can form enough linear equations that, while they're not
> going to have a unique solution, they should have define a linear subspace
> small enough to brute force, retrieving the state of the LFG (and hence
the
> sbox).
Somehow I knew that this would be the reason for an attack. Maybe I should
stick to block ciphers...
> Now, if you go with a noninvertable sbox (i.e. n bits in and m < n bits
> out), then how breakable this is depends on the complexity of the LFG
> equation. In the easiest case (the equation is x_i = x_{i-a} + x_{i-n}),
> you look for places where you have apparent collisions between sbox[x_i]
and
> either sbox[x_{i-a}] or sbox[x_{i_n}], and you try to determine if the
third
> element is zero by checking the other equation it is involved in. If it
is,
> then you have a good guess at the value of sbox[0], and you have a linear
> equation. Find n such linear equations, and the previous attack works.
Ahh you mean t-resilient style sboxes? I've heard that before in
correlation immune sbox design... maybe I got that wrong..
Tom
------------------------------
From: [EMAIL PROTECTED] (David Formosa (aka ? the Platypus))
Subject: Re: "UNCOBER" = Universal Code Breaker
Reply-To: [EMAIL PROTECTED]
Date: Wed, 18 Apr 2001 02:13:34 GMT
On Tue, 17 Apr 2001 19:51:28 -0300, newbie <[EMAIL PROTECTED]> wrote:
> You are starting to elaborate it.
> This theory.
> Because the universal breaking-theory is kowing the conditions
> unbreakability too.
If you wish to be strict about it the theory of breakable cyphers is
called cyytoanylisus.
> This theory has to answer why is OTP likely unbreakable. It is not so
> sure.
We have a thery as to why OTP is unbreakable. Because any plaintext
is equillay probabel.
[...]
> Even is random sequences you will find redundancy.
By definition random sequnces don't have redundancy.
--
Please excuse my spelling as I suffer from agraphia. See
http://dformosa.zeta.org.au/~dformosa/Spelling.html to find out more.
Free the Memes.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: "UNCOBER" = Universal Code Breaker
Date: Wed, 18 Apr 2001 02:52:00 GMT
On Tue, 17 Apr 2001 16:11:34 -0700, "Joseph Ashwood" <[EMAIL PROTECTED]>
wrote, in part:
>But the existance of a single algorithm which can provably not be broken by
>such a theory eliminates the possibility of that theory.
So? Maybe some theory that can break every cipher that depends only on
the work factor, and is not information-theoretically secure might
exist. Wouldn't that be useful too? And since it's as "universal" as
possible, wouldn't we still call it universal?
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: "UNCOBER" = Universal Code Breaker
Date: Wed, 18 Apr 2001 02:53:27 GMT
On Tue, 17 Apr 2001 19:51:28 -0300, newbie <[EMAIL PROTECTED]>
wrote, in part:
>Redundancy in using letters.
>Redundancy in using words.
>Redundancy in using sentences.
>etc...
>So OTP is not surely ( practically speaking) unbreakable.
No, redundancy in plaintext doesn't make the OTP breakable. You can
imagine the plaintext has whatever constraint you like - but all
plaintexts of the correct length and meeting that constraint remain
fully and equally possible.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: "UNCOBER" = Universal Code Breaker
Date: Wed, 18 Apr 2001 02:54:07 GMT
On Tue, 17 Apr 2001 19:57:19 -0300, newbie <[EMAIL PROTECTED]>
wrote, in part:
>What is yabbing? I did not find it in my humble dictionary
>I found yaping. Only dog yap. I'm not dog.
>I'm newbie.
I think he means jabbering, not yapping.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: DES Optimizaton - Can Someone Explain?
Date: Wed, 18 Apr 2001 02:56:25 GMT
On Tue, 17 Apr 2001 22:23:30 +0200, "Kevin D. Kissell"
<[EMAIL PROTECTED]> wrote, in part:
>but I note that the permutated
>S-box outputs in the source code in the Applied Cryptography
>appendix (the "SPx" tables) do not seem to correspond to the
>naive result of applying the P-permutation to the selected bits.
Remember that the description of DES is big-endian. Also, the S-box
entries may have been re-ordered; remember that the two bits selecting
one of four permutations of the numbers 0 to 15 originally come one
before and one after the four bits selecting which item in the
permutation is used.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
Reply-To: "Brian McKeever" <[EMAIL PROTECTED]>
From: "Brian McKeever" <[EMAIL PROTECTED]>
Subject: Re: C code for GF mults
Date: Wed, 18 Apr 2001 02:59:40 GMT
"Rob Warnock" <[EMAIL PROTECTED]> wrote in message
news:9bgab1$pv9r$[EMAIL PROTECTED]...
> Hmmm... I tend to use stuff more like this:
>
> /* multiply a and b in GF(2^r) mod p */
> GF gf_multiply(GF a, GF b, int n, int p_log_table[], GF p_antilog_table[])
{
> int log_a, log_b;
>
> if (a == 0 || b == 0)
> return (GF)0;
> else {
> log_a = p_log_table[a];
> log_b = p_log_table[b];
> return p_antilog_table[(log_a + log_b) % n];
> }
> }
>
> When "n" (a.k.a. sizeof(p_antilog_table)]) gets too big for comfort,
> break the log/antilog tables into pieces, and do it piecewise. But in
> any case, it's a heck of a lot faster than stepping through the *bits*!!
How can the tables be broken up? Is there a similar algorithm if we don't
want to store the 2*k*2^k bits of the full tables?
Brian
------------------------------
** 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 by posting to sci.crypt.
End of Cryptography-Digest Digest
******************************
