Cryptography-Digest Digest #267, Volume #12 Fri, 21 Jul 00 20:13:00 EDT
Contents:
Re: Random Appearance (Terry Ritter)
Re: Cascading multiple block algorithms ("Joseph Ashwood")
Re: Random Appearance (Future Beacon)
Re: help for rc5 cryptanalysis (Anton Stiglic)
Re: Has RSADSI Lost their mind? (Jerry Coffin)
Re: RC4 free for noncommercial ? (Andru Luvisi)
Re: Hashing hash algorithms: a waste of time (Sundial Services)
Re: random malar-key (Sundial Services)
Re: RC4 free for noncommercial ? (Larry Kilgallen)
Re: On block cipher and automata (Mok-Kong Shen)
Re: Hashing hash algorithms: a waste of time ("Joseph Ashwood")
Re: md5 uses, questions (Arthur Dardia)
Re: Cascading multiple block algorithms (Mok-Kong Shen)
Re: FWZ1 (JPeschel)
Re: Has RSADSI Lost their mind? ("Trevor L. Jackson, III")
Re: RC4 free for noncommercial ? (Doug Stell)
Re: Has RSADSI Lost their mind? (Roger Schlafly)
Re: RC4-- repetition length? ("Scott Fluhrer")
Re: Cascading multiple block algorithms ("Joseph Ashwood")
Re: random malar-key ("Abyssmal_Unit_#3")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Random Appearance
Date: Fri, 21 Jul 2000 21:13:03 GMT
On Fri, 21 Jul 2000 15:10:21 -0400, in
<[EMAIL PROTECTED]>, in
sci.crypt Future Beacon <[EMAIL PROTECTED]> wrote:
>All of the encryption methods I have read about in books or here
>seem to attempt to make the ciphertext appear random, chaotic, and
>meaningless. Does anybody know of an exception that nonetheless
>results in strong encryption?
First of all, this is tough: On the one hand we want an arbitrary
key-selection among a plethora of different transformations so that an
opponent cannot simply try all possible keys. On the other, we want
each of those different transformations to appear to make some sense
on a level different from the actual message.
The one reference of which I am aware is the book "Disappearing
Cryptography" by Peter Wayner (Academic Press, 1996).
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Cascading multiple block algorithms
Date: Fri, 21 Jul 2000 14:12:53 -0700
One example is:
attacker discovers flaws in ci (inner cipher) and co(outer cipher) such that
ci has extreme tendancies towards certain values under random keys (e.g.
0xaaaaaaaaa maps 99% of the time to 0x186528965), and that co is subject to
a known plaintext attack. For the chosen plaintext attack, the attacker
chooses the plaintext to be 0xaaaaaaaaa, knowing that the input to co has
high probability of being 0x186528965, facilitating an attack. Personally
I'd call this a probably plaintext attack, but under the circumstances of a
large target audience book (like AC), it would probably be clearer to the
audience to use known/chosen plaintext terminology.
Similar situations happen quite often in low grade ciphers, but are
extremely unlikely in something the strength of DES, 3DES, Blowfish,
Twofish, Serpent, Rijndael, et al.
Joe
------------------------------
From: Future Beacon <[EMAIL PROTECTED]>
Subject: Re: Random Appearance
Date: Fri, 21 Jul 2000 17:19:41 -0400
On Fri, 21 Jul 2000, Paul Koning wrote:
> Future Beacon wrote:
> >
> > All of the encryption methods I have read about in books or here
> > seem to attempt to make the ciphertext appear random, chaotic, and
> > meaningless. Does anybody know of an exception that nonetheless
> > results in strong encryption?
>
> Depends on what you mean.
>
> Steganography is a good example: the output looks like
> meaningful data, but the encrypted message is hidden inside
> that, as close to invisible as can be managed.
>
> paul
>
Paul,
I forgot about pictures. It seems that merely diluting the message
would be possible, but I am thinking that a dense message that
wastes no characters might seem orderly but not be the oder which
is the intended message. If the ciphertext seemed to be a plausible
English message but was not the message and was only about as long
as the real message and was cryptographically strong, that would
qualify. I don't know if there are other approaches. As I
indicated in my question, I certainly don't know if anybody has
succeeded in such a thing.
Jim Trek
Future Beacon Technology
http://eznet.net/~progress
[EMAIL PROTECTED]
------------------------------
From: Anton Stiglic <[EMAIL PROTECTED]>
Subject: Re: help for rc5 cryptanalysis
Date: Fri, 21 Jul 2000 17:29:44 -0400
O.k., thanks to D. Wagner for clearing things out.
I now see how you can execute the attack mdw proposed
and things make sens now...
Anton
------------------------------
From: Jerry Coffin <[EMAIL PROTECTED]>
Subject: Re: Has RSADSI Lost their mind?
Date: Fri, 21 Jul 2000 15:46:24 -0600
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] says...
[ ... ]
> Most people view interoperability as an important goal, which argues
> for a single winner.
A single winner is neither necessary nor sufficient to
interoperability. The two are nearly orthogonal.
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
From: Andru Luvisi <[EMAIL PROTECTED]>
Subject: Re: RC4 free for noncommercial ?
Date: 21 Jul 2000 14:30:38 -0700
[EMAIL PROTECTED] (Larry Kilgallen) writes:
[snip]
> I hear there is a used US airforce jet for sale today,
> but the seller would be foolish to consider me a viable
> customer and let me have a ride (even ignoring the fact
> that it is a single-seater and I am not a pilot). RSA
> shareholders could sue the company if it squandered
> resources giving free rides to people who were not
> seriously in their target market.
Are you saying you consider it prudent for a company to ignore people
unless they represent a big business at the moment in question?
Andru
--
Andru Luvisi, Programmer/Analyst
------------------------------
Date: Fri, 21 Jul 2000 14:49:49 -0700
From: Sundial Services <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Hashing hash algorithms: a waste of time
Simon Johnson wrote:
> In which case i would say it doubles the security...... You have
> to do twice the work to find two messages that collide to
> produce the two signitures that are identical. This is only true
> if the change to the data, made by the appending the first
> signiture is suffiently large to make the relationship between
> the first and second hashes too difficult to fathem.
Actually I suspect it might well have the opposite effect. It might
render the digital signature un-provable.
A digital signature algorithm necessarily works by throwing away
information -- but doing so in a way that is very sensitive to the
slightest change in the original input data. It stands to reason that
the greater the proportion in size between the original data and the
resulting signature, the more confidence one would have that the
signature does demonstrate that the original data has actually not been
changed. (There are, simply, more bytes that, with their slightest
wiggle, would have changed the output ... and since the output did not
change, ALL those bytes did not wiggle, the more the merrier. Or
something like that.)
Now, if you crunch the data into a signature and then do it again, well,
"let's ignore completely where the input to the second signature process
came from" and treat it as an operation unto itself. We have a block of
input text which is equal in size to the signature (#2) being produced
from it. While we may reasonably presume that any change in the second
signature would reflect any change in the input (the first signature),
it CANNOT be argued that the security of the overall system has thereby
been increased.
In fact, it must have been DEcreased, because (a) there is by definition
-not- a one-to-one correspondence between an input and its corresponding
signature; and (b) there are much fewer ... ahh ... "wiggle bytes" in
the second input than there were in the first.
By this (entirely common-sense) argument, the first digital-signature
pass contributed the maximum amount of accountability ... and the second
digital-signature pass REMOVED some of it. It didn't increase.
------------------------------
Date: Fri, 21 Jul 2000 14:50:50 -0700
From: Sundial Services <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Crossposted-To: alt.religion.kibology
Subject: Re: random malar-key
Mikal 606 wrote:
>
> "Abyssmal_Unit_#3" <[EMAIL PROTECTED]> wrote in message
> news:u#Ht8tz8$GA.328@cpmsnbbsa08...
> > ok, heres a fun random generator:
> >
> > attach sensor electrodes to user's scalp (appropriate equipment is
> required).
> Just where do you plant to get this individuals history?
> Sounds like fascism to me, sonny boy.
>
> MiKa-il
:-) Hey, you ain't attachin' ANY electrodes to MY scalp, sonny-boy! ;-)
------------------------------
From: [EMAIL PROTECTED] (Larry Kilgallen)
Subject: Re: RC4 free for noncommercial ?
Date: 21 Jul 2000 18:53:47 -0500
In article <[EMAIL PROTECTED]>, Andru Luvisi <[EMAIL PROTECTED]>
writes:
> [EMAIL PROTECTED] (Larry Kilgallen) writes:
> [snip]
>> I hear there is a used US airforce jet for sale today,
>> but the seller would be foolish to consider me a viable
>> customer and let me have a ride (even ignoring the fact
>> that it is a single-seater and I am not a pilot). RSA
>> shareholders could sue the company if it squandered
>> resources giving free rides to people who were not
>> seriously in their target market.
>
> Are you saying you consider it prudent for a company to ignore people
> unless they represent a big business at the moment in question?
I consider it their right to make such a choice.
I consider it foolish of someone (but still their right)
to spend time on what sales folks call an "unqualified"
prospect.
But RSA Security is required by law to exercise prudent
judgement with the funds of their shareholders, so they
are not allowed to be foolish in that manner.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: On block cipher and automata
Date: Sat, 22 Jul 2000 00:12:01 +0200
Bryan Olson wrote:
> [EMAIL PROTECTED] (Terry Ritter) :
> [...]
> > In practice, the use of "extra data" implies some data expansion, and
> > adding significant extra data to each block means we need a large
> > block for best efficiency.
>
> The large block is not really necessary. We could use most
> of the same randomness across multiple blocks, while mixing
> in a little new randomness with each. For example suppose
> we're using a 64-bit block. First the sender encrypts one
> blocks containing all random bits. The sender and receiver
> now share a 64 random vector, call it V.
[snip]
You are right. One can reserve space in the block for the random
bits and put into the block correspondingly less number of plaintext
bits. The following scheme should also work:
Let n = cipher block size, P_i = ith plaintext block with n-b bits,
R_i = ith random bit block with b bits, C_i = ciphertext block with
n bits. Algorithm:
K= given key; R_0 = 0; i=0;
do
i=i+1;
K = K + R_(i-1) mod 2^n;
C_i = E(K, P_i || R_i);
od;
M. K. Shen
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Hashing hash algorithms: a waste of time
Date: Fri, 21 Jul 2000 15:07:58 -0700
I'm far from convinced of that, because the following is being done:
x = f(Message)
y = f(Message || x)
and both x and y constitute the signature (or at least that's my
understanding of what's being done).
Given this it would seem to me, to very minimally increase the security,
because one must compute a Message that
A) Produces the same x
and
B) Produces the same y
Since given current sizes it would require a significant break in the
alorithm to produce A), I believe it is likely to also produce B) in such a
case. This likelihood is fully open to interpretation however.
Your statement that this decreases security is however an interesting
argument. For it to actually weaken the security, the function f() must be
such that given a reasonable message produces a strong signature, BUT given
a reasonable message with random padding produces a signature so weak as to
have a negative security factor, placing plaintext without signature at 0
security. This is an impossible case, and so I assure you that adding a
second signature cannot weaken the strength of that signature (it may
however facilitate future attacks on the signature which is another matter
entirely).
Joe
"Sundial Services" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Simon Johnson wrote:
> > In which case i would say it doubles the security...... You have
> > to do twice the work to find two messages that collide to
> > produce the two signitures that are identical. This is only true
> > if the change to the data, made by the appending the first
> > signiture is suffiently large to make the relationship between
> > the first and second hashes too difficult to fathem.
>
>
> Actually I suspect it might well have the opposite effect. It might
> render the digital signature un-provable.
>
> A digital signature algorithm necessarily works by throwing away
> information -- but doing so in a way that is very sensitive to the
> slightest change in the original input data. It stands to reason that
> the greater the proportion in size between the original data and the
> resulting signature, the more confidence one would have that the
> signature does demonstrate that the original data has actually not been
> changed. (There are, simply, more bytes that, with their slightest
> wiggle, would have changed the output ... and since the output did not
> change, ALL those bytes did not wiggle, the more the merrier. Or
> something like that.)
>
> Now, if you crunch the data into a signature and then do it again, well,
> "let's ignore completely where the input to the second signature process
> came from" and treat it as an operation unto itself. We have a block of
> input text which is equal in size to the signature (#2) being produced
> from it. While we may reasonably presume that any change in the second
> signature would reflect any change in the input (the first signature),
> it CANNOT be argued that the security of the overall system has thereby
> been increased.
>
> In fact, it must have been DEcreased, because (a) there is by definition
> -not- a one-to-one correspondence between an input and its corresponding
> signature; and (b) there are much fewer ... ahh ... "wiggle bytes" in
> the second input than there were in the first.
>
> By this (entirely common-sense) argument, the first digital-signature
> pass contributed the maximum amount of accountability ... and the second
> digital-signature pass REMOVED some of it. It didn't increase.
------------------------------
From: Arthur Dardia <[EMAIL PROTECTED]>
Subject: Re: md5 uses, questions
Date: Fri, 21 Jul 2000 18:20:16 -0400
\"Ismo\" wrote:
> matt wrote:
> > Why can't a modified client just send the correct hash value (from the
> > genuine client), without bothering to calculate the md5 sum? Thats the
> > fatal flaw with untrusted client authentification.
> > There's no way around it.
>
> What about appending a random one-time session value to the data
> that is about to be hashed?
When you append a one-time session value to the data that is about to be
hashed, you'll get an entirely different hash everytime. The reason that
sets hash functions apart from other functions is that they're designed to
be one-way, unlike block ciphers which are designed to encrypt and do it
backwards [commonly called decrypt :)]. The server, when receiving this
output (hashed with the one-time session), won't be able to determine if
it's a valid hash.
>
>
> /Ichinin
> .SE
> _______________________________________________________________
>
> - "You can't beat the system, but you can edit the registry"
--
Arthur Dardia Rensselaer Polytechnic Institute [EMAIL PROTECTED]
PGP 6.5.1 Public Key http://www.webspan.net/~ahdiii/ahdiii.asc
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Cascading multiple block algorithms
Date: Sat, 22 Jul 2000 00:39:07 +0200
Joseph Ashwood wrote:
> One example is:
> attacker discovers flaws in ci (inner cipher) and co(outer cipher) such that
> ci has extreme tendancies towards certain values under random keys (e.g.
> 0xaaaaaaaaa maps 99% of the time to 0x186528965), and that co is subject to
> a known plaintext attack. For the chosen plaintext attack, the attacker
> chooses the plaintext to be 0xaaaaaaaaa, knowing that the input to co has
> high probability of being 0x186528965, facilitating an attack. Personally
> I'd call this a probably plaintext attack, but under the circumstances of a
> large target audience book (like AC), it would probably be clearer to the
> audience to use known/chosen plaintext terminology.
Sorry, I need further help. Which cipher is the first of the cascade, ci or co?
I suppose it must be co. But I don't yet quite follow the reasoning. Could
you please explain the matter together with the semantics of the two attacks,
i.e. what the analyst gets in each case? (What the analyst 'knows' or
'chooses' of plaintext are all with respect to the input of the cascade
and hence are input to the first cipher, isn't it?) Thanks.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Subject: Re: FWZ1
Date: 21 Jul 2000 22:40:59 GMT
Anonymous [EMAIL PROTECTED] writes, in part:
>reverse-engineered FWZ1 cipher.
Which of Check Point's products did you reverse-enginner? Was it FireWall-1?
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
Date: Fri, 21 Jul 2000 19:11:30 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Has RSADSI Lost their mind?
Larry Kilgallen wrote:
> In article <[EMAIL PROTECTED]>, Sander Vesik
><[EMAIL PROTECTED]> writes:
> > Bill Unruh <[EMAIL PROTECTED]> wrote:
> >> In <[EMAIL PROTECTED]> Sander Vesik
><[EMAIL PROTECTED]> writes:
> >>>The patented part affects the usability of the cypher only in areas where
> >>>it is patented. It is *IMHO* not clear how picking one of the finalists
> >>>means that it is a "better" cypher in the long run. And at any rate I consider
> >
> >> presumably the selection process is based precisely on whether one
> >> cypher is "better" than another. Of course ignorance, incompetence, or
> >> politics could skew the choice, but also presumably the chances of
> >> my being better able to make the choice of the best cypher (or even
> >> deciding that they are roughly equal) is almost non-existant.
> >
> > I am not qualified to say that they are equally strong - or that one of
> > them is stronger, and I will probably never be.
> >
> > But of course, there is the whole matter of what is better. If a set of
> > the finalists (any number between 2 and 5) can be shown to be equally
> > strong in the face of all known attacks, then surely the one selected
> > must be selected based upon other criteria than security? Thus even
> > though the cypher may be better, but not so under different (possibly
> > implementation related) criteria.
> >
> > Which in the end probably means that 5-10 years down the road we are
> > better off with all 5, not one possibly pretty arbritrary and skewed
> > final selection.
>
> Most people view interoperability as an important goal, which argues
> for a single winner.
No it does not.
The purpose of the AES selection process is to qualify ciphers for use by the
government and their
contractors. Selecting a single cipher means that the other submissions are
inadequate for government
security needs, which is fatuous on its face. If there are multiple ciphers that meet
the government's
encryption needs then they should all be selected.
Interoperability has nothing to do with meeting the governments encryption
requirements.
------------------------------
From: [EMAIL PROTECTED] (Doug Stell)
Subject: Re: RC4 free for noncommercial ?
Date: Fri, 21 Jul 2000 22:38:08 GMT
On Thu, 20 Jul 2000 11:38:51 +0200, Volker Hetzer
<[EMAIL PROTECTED]> wrote:
>> My crypto book states that 'RC4 requires a license fee
>> for commercial use'. Does that mean it is free for
>> non-commercial use ?
>
>Why don't you ask rsalabs?
Of course RSA Security will say that you must buy a license and RC4
usually comes as part of the BSAFE library. Most customers only get
the precompiled BSAFE, but the "compile on anything" source code can
be had for a large fee. (I had it for several years in a previous
life.)
The on-going license fee for BSAFE typically involves on the order of
15% of the cost of any product using it, a $10,000 or higher annual
upgrade fee.
My understanding, which could be wrong is the following. RSA typically
has a different opinion and I don't know what their current opinion
is.
1. The name "RC4" is copyrighted and can not be used without a
license.
2. The code was a trade secret, but not patented. It has been argued
that once the code was reverse engineered, it has lost its
protections.
So, ARC4 may indeed be the obvious choice.
------------------------------
From: Roger Schlafly <[EMAIL PROTECTED]>
Subject: Re: Has RSADSI Lost their mind?
Date: Fri, 21 Jul 2000 16:25:08 -0700
"Trevor L. Jackson, III" wrote:
> Interoperability has nothing to do with meeting the governments
> encryption requirements.
Interoperability *is* one of the gubmnt requirements.
For interoperability and other purposes, NIST strongly desires
to select a single block encryption algorithm to be specified
in the AES with a strength equal to or better than that of
Triple DES and significantly improved efficiency.
[Federal Register: September 12, 1997 (Volume 62, Number 177)]
http://csrc.nist.gov/encryption/aes/pre-round1/aes_9709.htm
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: RC4-- repetition length?
Date: Fri, 21 Jul 2000 16:20:41 -0700
Bill Unruh <[EMAIL PROTECTED]> wrote in message
news:8la28g$gcf$[EMAIL PROTECTED]...
> In <8l8tfd$at1$[EMAIL PROTECTED]> "Scott Fluhrer"
<[EMAIL PROTECTED]> writes:
> ]>
> ]> ]Look at digraph statistics. Certain digraphs, such as the (00,00)
> ]digraph,
> ]> ]occur more frequently than expected. Other digraphs, such as the
(FF,FF)
> ]> ]digraph, occur less frequently than expected. In addition, if the
> ]attacker
> ]> ]keeps track of the value of i, other digraphs come into play. For
> ]example,
> ]> ]the (i+1,FF) digraph is more likely than expected, and the (00,i+1)
> ]digraph
> ]> ]is less likely. By taking advantage of all these digraph variances
(an
> ]> ]exhaustive list appears in the paper), it turns out that 2**30.6
outputs
> ]is
> ]> ]sufficient for a 90% certainty rate.
> ]>
> ]> I have difficulty in understanding this. What differentiates 00 from
ff.
> ]> Ie, the algorithm is symmetric under interchange of any two numbers,
> ]> since all arithmetic is modulo arithmetic ( mod ff). This may be true
> ]> for some particular key, but how could it be true of a random key?
>
> ]Actually, no, the algorithm is not symmetric. For example, in one of the
> ]steps, j is advanced by the permutation element pointed to by i. If that
> ]element happens to be zero, then j is unchanged. If you interchange that
> ]zero with any other value, j is changed. Or, in other words, the
algorithm
> ]acts differently depending on the precise value of a permutation element.
>
> ]Here is a more extended example: suppose we happened to happen apon a
state
> ]where, for some N (and S is the permutation array),
>
> ] i = N-1
> ] j = N+2
> ] S[N] = FF
> ] S[N+1] = N+1
>
> ]Then, if you do the next-state function twice, that is:
>
> ]- Increment i by 1, new value = N
> ]- Increment j by S[i]=FF, new value = N+1
> ]- Swap S[i] and S[j], so S[N]=N+1, S[N+1]=FF
> ]- Output S[S[i]+S[j]] = S[N] = N+1
> ]- Increment i by 1, new value = N+1
> ]- Increment j by S[i]=FF, new value = N
> ]- Swap S[i] and S[j], so S[N]=FF, S[N+1]=N+1
> ]- Output S[S[i]+S[j]] = S[N] = FF
>
> ]That is, the above situation outputs the digraph (N+1, FF) independent of
> ]any other state within the permutation.
>
> ]Note that this mechanism doesn't work if you replace the value FF with
> ]anything else. In addition, if i=N-1 (which the attacker can know), the
> ]above starting situation happens (assuming a random state otherwise)
> ]approximately 2**-24 of the time. That, coupled with the fact that the
> ](N+1,FF) digraph happens 2**-16 through normal mechanisms, leads to that
> ]particular digraph being slightly more probable than in a truly random
> ]keystream.
>
> Thanks for the explanation. In your description you compared 00,00 with
> FF,FF . In this explanation you single out FF. Does this mean that FF,ff
> tends to occur more fequently than any other double or is 00,00 also
> special?
Actually, that wasn't an explanation, that was an example. I chose it
mostly because a) it was easy to describe, and b) it was the first one I
thought of. The most frequent digraph turns out to be (00,00) at i=1, which
actually has two distinct special mechanisms. The (00,00) digraph (for most
values of i) is also special, although the mechanism is rather more complex.
Other frequent digraphs are (0,1), (FF,i+1) and (FF,i+2) for most values of
i, and (FF,00), (FF,01), (FF,02), and (81,81) for specific values of i.
>
> Also you state that (N+1,FF) happed 2**-16 through normal mechanisms.
> You then assume that the mechnism you define happens in addition to
> those "normal" mechanisms. However, it is also possible that this
> mechanism is just a part of the "normal" mechanisms. Since this is a
> pseudo random stream, one cannot assume that the "normal" mechanisms are
> just random selection.
I don't. By "normal" mechanism, I mean the case where the 6 permutation
elements referenced in two next-step operations are distinct (or mostly
distinct). That happens most of the time, and produces digraphs pretty
close to uniform. In addition, I didn't find these special mechanisms and
then posit the digraph probabilities. I started out computing the exact
digraph probabilities (for reduced n), and then found these mechanisms to
explain why certain digraphs are more probable than others. The then
experimentally verified that the digraph probabilities are as expected for
n=8. I know that these probability variances exist.
Don't believe me? Then, set up an RC/4 stream, generate 2**36 outputs,
count the number of (00,00), (00,01) and (FF,FF) digraphs, compute the
number expected, and compute the expected standard deviation. Even on a
relatively slow computer, this should take only a few hours, and certainly
would answer the question...
--
poncho
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Cascading multiple block algorithms
Date: Fri, 21 Jul 2000 15:46:04 -0700
> Sorry, I need further help. Which cipher is the first of the cascade, ci
or co?
ciphertext = co(ci(plaintext, key1), key2)
> I suppose it must be co. But I don't yet quite follow the reasoning. Could
> you please explain the matter together with the semantics of the two
attacks,
> i.e. what the analyst gets in each case?
The analyst gets to choose the plaintext going into ci.
This plaintext knowledge gives probably knowledge of the output of ci.
Which translates directly to probable knowledge of the input of co
>From which point the analyst can perform a (probable) known-plaintext attack
on co, by exploiting a flaw in ci.
> Thanks.
------------------------------
From: "Abyssmal_Unit_#3" <[EMAIL PROTECTED]>
Subject: Re: random malar-key
Date: Fri, 21 Jul 2000 20:03:56 -0400
don't worry, it only takes power away (can u spare it?) , & it doesn't (shouldn't)
introduce any unwanted abberations of thoughts.
heee ! ;-))
ok, maybe try hooking up like an ECG instead? how about an aura detector? ;-D
--
best regards,
hapticz
>X(sign here)____________________________________________<
Sundial Services wrote in message <[EMAIL PROTECTED]>...
|Mikal 606 wrote:
|>
|> "Abyssmal_Unit_#3" <[EMAIL PROTECTED]> wrote in message
|> news:u#Ht8tz8$GA.328@cpmsnbbsa08...
|> > ok, heres a fun random generator:
|> >
|> > attach sensor electrodes to user's scalp (appropriate equipment is
|> required).
|> Just where do you plant to get this individuals history?
|> Sounds like fascism to me, sonny boy.
|>
|> MiKa-il
|
|
|:-) Hey, you ain't attachin' ANY electrodes to MY scalp, sonny-boy! ;-)
------------------------------
** 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
******************************
