Cryptography-Digest Digest #236, Volume #10 Tue, 14 Sep 99 21:13:03 EDT
Contents:
Re: RC4-40 Cracking (Paul Koning)
Re: Ritter's paper (SCOTT19U.ZIP_GUY)
Re: Ritter's paper (Terry Ritter)
Re: ti83 encryption (Arthur Dardia)
Re: ti83 encryption ([EMAIL PROTECTED])
Re: Ritter's paper (Terry Ritter)
Re: ti83 encryption (Arthur Dardia)
Re: Size of DH exponent & modulous?? (John Myre)
Re: Sources of randomness (Terry Ritter)
Re: ti83 encryption (Ian Goldberg)
Re: How strong is RC4 ? ([EMAIL PROTECTED])
Re: Sources of randomness (Terry Ritter)
Re: Ritter's paper (Terry Ritter)
Re: RC4-40 Cracking ("Steven Alexander")
----------------------------------------------------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: RC4-40 Cracking
Date: Tue, 14 Sep 1999 18:06:03 -0400
Dafydd Richards wrote:
>
> Please could somebody post/email rough estimates for the following please
> :-
>
> 1) How much time would a machine on a $30,000 budget take to crack RC4-40.
>
> 2) How much would it cost to construct a machine to crack RC4-40 in say half
> an hour.
Not much, if you're doing it with PCs. But I assume you meant a custom
machine along the lines of the DES cracker.
For a rough estimate, suppose RC4 and DES key search are about equally
hard
and equally fast. Deep Crack did a 56 bit key in 56 hours, which means
it
could do a 40 bit key in 3 seconds. It costs about $300k.
Suppose also that speed scales directly with cost. That would mean a
$30k
machine would find an RC4-40 key in 30 seconds. And a half hour machine
would cost $500. (That last number doesn't really work because hardware
costs don't scale linearly down that far. But it suggests you can do
the
job with a modest investment in FPGAs. Might make a nice thesis project
for
an enterprising EE student.)
paul
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Ritter's paper
Date: Wed, 15 Sep 1999 00:43:35 GMT
In article <7rm98e$69h$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (David Wagner) wrote:
>In article <[EMAIL PROTECTED]>, Terry Ritter <[EMAIL PROTECTED]> wrote:
>> There is a copy of the article .PDF on my pages. It is first in the
>> list in the Technical Articles section on my top page. The exact link
>> is:
>> http://www.io.com/~ritter/ARTS/R8INTW1.PDF
>
>Thanks for posting! I think this is an important subject for
>discussion.
>
>However, I don't think your suggestion works. I'd like to invite
>you to look over my reasoning and see if you find any errors.
>
>Let's think of this as a resource allocation problem (i.e., an
>economics problem), where our sole goal is to minimize the risk
>that the adversary can read our traffic. Then I think a fairly
>simple calculation shows that your proposed approach is sub-optimal,
>and that the best strategy is to "follow the crowd".
>
>Suppose we have a fixed bound R on the total amount of resources
>we can apply to the problem (e.g., R man-years, R months of Eli
>Biham's time, whatever). Further suppose we have a fixed amount T
>of traffic to protect. We have two choices:
> ("AES") Design one cipher that you really really believe in; use
> it for _all_ the traffic.
> In other words, spend all of R on design and analysis
> of the cipher, and use it for all of T.
The fallacy is your spending all your money on a design that is
supose to work in all envornments from credit cards to file portection
as a result you get something that can't be very good. One should
at the very least have different designs for different requirements unless
you real task Mr Wagner is to make everything readable by your
handlers.
We don't build one vechicle on the road to haul garbage kids and
to go off road it just is not practical.
> (Ritter) Design N ciphers, and hope most of them don't get broken.
> In other words, spend R/N on each of the N designs, and
> use each cipher to encrypt T/N of the traffic.
>I think these scenarios accurately characterize the two approaches
>we want to compare. Do you agree with the model?
No I think your full of it. He said you can use variuos ciphers. I think
he might even use one of yours in the layer.
>
>Let f(R) be the probability that we apply the resources specified
>by R to cryptographic design and analysis, and yet the adversary still
>manages (somehow) to break our cipher.
>
>We can now calculate the risk of failure for each scenario.
> ("AES") With probability f(R), the cipher breaks, and all T of
> our traffic is broken.
> => Expected loss = T*f(R).
> (Ritter) Each cipher breaks with probability f(R/N), and each break
> reveals T/N of our traffic.
Again not if you do them in series.
> Since expectation is linear, the total expected loss is the
> sum of the expected losses; the latter quantity is T/N * f(R/N)
> for each cipher, and there are N of them, so...
> => Expected loss = N * T/N * f(R/N) = T*f(R/N).
>Here, I've made the assumption that the "utility function" we want
>to minimize is the expected amount of compromised traffic. This is
>probably an unrealistic assumption, but let's make it for the moment.
>
>It's hard to tell a priori what the graph of f() will look like,
>but at least we can be pretty sure that f() is monotonic: doing
>more analysis will only reduce the risk of catastrophic failure.
>
>Thus, we can see that f(R) < f(R/N), and in particular,
>T*f(R) < T*f(R/N), so the way to minimize the expected loss is to
>choose the single-cipher strategy (the "AES" approach). Using lots
>of ciphers only increases the expected loss.
>
>In the real world, the expected loss is probably not exactly the right
>function to minimize (probably the harm is a non-linear function of
>the amount of traffic compromised, where leaking 10% of one's traffic
>is almost as bad as leaking 90% of it). Nonetheless, a moment's thought
>will show that adjusting this assumption to be more realistic will only
>widen the gap between the two strategies, and will make the "AES"
>approach even more appealing than the above calculation might suggest.
You can wave you hand all you want. His idea was to use some in series.
But with your method we can be almost 100% sure that the NSA will be
pulling the strings for the AES candidate that wins. So it will be weak.
Unless your foolish enough to belive your government is honest. I can say
with 26 years of direct government experience that the governemnt is not
honest. Would you buy a used car from Clinton. Sir in the "real world" your
assumptions are worthless. Your forgot politcs. Just as you where so
ignorant to blatently say your Slide Attack would show scott19u.zip you
are wrong about this.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Ritter's paper
Date: Tue, 14 Sep 1999 23:58:23 GMT
On Tue, 14 Sep 1999 19:58:24 GMT, in
<[EMAIL PROTECTED]>, in sci.crypt
[EMAIL PROTECTED] (John Savard) wrote:
>[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote, in part:
>
>> I check it out nice article. But what I did not get was the comment about
>>if you use a patented system and someone breaks it you can recover damages.
>>What did you mean by that Mr. Ritter. Are you saying it is against the law to
>>decode something this is encrypted with a patented method?
>
>While that doesn't really add much to security,
That depends upon what you call "security," and is only true IF you
think security is Boolean. But if you were a bank, you might see a
continuous shading of "security," depending on your losses, lawsuits,
and the growth of your business.
>that is true!
>Building, for example, an IDEA-cracker is something for which you
>would be unlikely to get a license to do under the patents on IDEA.
>
>Since wiretapping is *also* illegal, if one uses cryptography one
>generally is assuming one is protecting against adversaries who do not
>balk at breaking the law, of course.
Of course. But we know it happens. And the civil recovery of damages
is a different issue than criminal wiretapping.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: Arthur Dardia <[EMAIL PROTECTED]>
Subject: Re: ti83 encryption
Date: Tue, 14 Sep 1999 19:54:00 -0400
Reply-To: [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
>
> Arthur Dardia wrote:
>
> > Is it? I don't know much about encryption. I don't have that much time on my
> > hands to read anything worth while, except what's posted on this newsgroup. I'm
> > going to start reading Handbook of Applied Crytography, since it's freely
> > available now. I'm scouring libraries for Bruce's Applied Crytography too. If
> > this is a Virgenee cipher, is it secure?
>
> From your code I would imagine that you would take the text:
> This is the plain text
>
> Then take the password:
> password
>
> And loop it like this:
> This is the plain text
> passwordpasswordpa
>
> Then add the results together (modulo 26) correct? If so then yes, it's a Virgenee
> (again I need to look up the spelling) cipher, and very trivial to crack.
I thought these were only trivial to crack once the user sends two messages
using the same key. (A+K)-(B+K)=(A+B). (A=the first message, B=second,
K=key). Then, it becomes trivial to crack. I don't know if I'm wrong here, but
Schneir said that this is a safe key as long as strong keys are used (at least
80bit). http://www.counterpane.com/solitaire.html
The above URL is for his Solitaire encryption scheme which uses the same
algortihm, only implemented with a deck of cards.
Also, the way you described it, is that I continually loop the keyphrase to
create "passwordpasswordpassword..." - this key is not very safe. My keys are
totally random. That is why the key length must be at least, if not more than
the length of the plaintext. This makes it so I don't have to loop. I'd assume
a key of "password" repeated multiple times until the key is long enough would
be significantly easier to crack. I believe a Virgenee algorithm with a totally
random key, when actually kept "secret," is uncrackable, no?
Art Dardia
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: ti83 encryption
Date: Tue, 14 Sep 1999 19:52:50 -0400
Arthur Dardia wrote:
> Is it? I don't know much about encryption. I don't have that much time on my
> hands to read anything worth while, except what's posted on this newsgroup. I'm
> going to start reading Handbook of Applied Crytography, since it's freely
> available now. I'm scouring libraries for Bruce's Applied Crytography too. If
> this is a Virgenee cipher, is it secure?
>From your code I would imagine that you would take the text:
This is the plain text
Then take the password:
password
And loop it like this:
This is the plain text
passwordpasswordpa
Then add the results together (modulo 26) correct? If so then yes, it's a Virgenee
(again I need to look up the spelling) cipher, and very trivial to crack.
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Ritter's paper
Date: Tue, 14 Sep 1999 23:58:17 GMT
On 14 Sep 1999 12:55:58 -0700, in
<7rm98e$69h$[EMAIL PROTECTED]>, in sci.crypt
[EMAIL PROTECTED] (David Wagner) wrote:
>In article <[EMAIL PROTECTED]>, Terry Ritter <[EMAIL PROTECTED]> wrote:
>> There is a copy of the article .PDF on my pages. It is first in the
>> list in the Technical Articles section on my top page. The exact link
>> is:
>> http://www.io.com/~ritter/ARTS/R8INTW1.PDF
>
>Thanks for posting! I think this is an important subject for
>discussion.
>
>However, I don't think your suggestion works. I'd like to invite
>you to look over my reasoning and see if you find any errors.
>
>Let's think of this as a resource allocation problem (i.e., an
>economics problem), where our sole goal is to minimize the risk
>that the adversary can read our traffic. Then I think a fairly
>simple calculation shows that your proposed approach is sub-optimal,
>and that the best strategy is to "follow the crowd".
>
>Suppose we have a fixed bound R on the total amount of resources
>we can apply to the problem (e.g., R man-years, R months of Eli
>Biham's time, whatever). Further suppose we have a fixed amount T
>of traffic to protect. We have two choices:
> ("AES") Design one cipher that you really really believe in; use
> it for _all_ the traffic.
> In other words, spend all of R on design and analysis
> of the cipher, and use it for all of T.
> (Ritter) Design N ciphers, and hope most of them don't get broken.
> In other words, spend R/N on each of the N designs, and
> use each cipher to encrypt T/N of the traffic.
I notice that you say I "hope" my ciphers are not broken. Yet it is
*I* who can afford to lose a few: I have exponentially many, you
know. On the contrary, it is *you* who must *hope* your cipher is not
broken, because that is everything. And you can *only* hope, because
you cannot *measure* that probability.
>I think these scenarios accurately characterize the two approaches
>we want to compare. Do you agree with the model?
No. For one thing, this model is too limited to describe the
advantage of placing exponentially many ciphers before our Opponents.
It also slouches toward comparing probabilities which we cannot know
and thus make no scientific sense to discuss.
>Let f(R) be the probability that we apply the resources specified
>by R to cryptographic design and analysis, and yet the adversary still
>manages (somehow) to break our cipher.
No, no, no we can't. We might calculate the economic disaster
which would result from breaking (and those results would be:
disaster for the AES approach; a regrettable transient loss in mine),
but we cannot calculate the probability that a cipher will fail.
>We can now calculate the risk of failure for each scenario.
> ("AES") With probability f(R), the cipher breaks, and all T of
> our traffic is broken.
> => Expected loss = T*f(R).
> (Ritter) Each cipher breaks with probability f(R/N), and each break
> reveals T/N of our traffic.
> Since expectation is linear, the total expected loss is the
> sum of the expected losses; the latter quantity is T/N * f(R/N)
> for each cipher, and there are N of them, so...
> => Expected loss = N * T/N * f(R/N) = T*f(R/N).
>Here, I've made the assumption that the "utility function" we want
>to minimize is the expected amount of compromised traffic. This is
>probably an unrealistic assumption, but let's make it for the moment.
Alas, these are false computations. One hidden -- dare I say
"sneakily" hidden -- assumption is that adding cryptanalysis resources
R reduces f. But where is the evidence for this? For example:
* If the cipher is already broken, f = 1.0, and all the R we spend is
completely wasted to no avail.
* If the cipher is not broken but will be some day, we are again in
the same situation, but we just do not know it. And this may be the
whole of our universe.
Yet another hidden assumption is that there exists a probability of
failure, and that we can discuss that. I assert that while there may
be some such probability, there is no way to measure it, and no way to
know if our discussions are correct, and so no scientific use in
discussing it. We cannot say when it is reduced, or even what that
might mean, unless we invent a special case where more attack
resources break more messages. Normally we handwave a "break" which,
when known, exposes "all" messages.
You have also not included the per-cipher resource reduction which
affects the Opponents, and some sort of effort factor to describe the
difference between placing twice as much effort into something you
know as opposed to having to learn some whole new cipher and trying to
attack that. One of the advantages of multi-ciphering is that it
creates exponentially many "ciphers" which may exist. Another
advantage is that multiciphering protects each individual cipher
against known-plaintext attacks against an individual cipher. If the
only reasonable attacks are known-plaintext, this alone inherently
increases strength over any single cipher which is necessarily exposed
to known-plaintext.
>It's hard to tell a priori what the graph of f() will look like,
>but at least we can be pretty sure that f() is monotonic: doing
>more analysis will only reduce the risk of catastrophic failure.
This is CERTAINLY false if catastrophic failure already exists, or
will exist. It is only true if you BELIEVE that the cipher is strong.
But if you are satisfied by belief, you don't need crypto -- just
*believe* your Opponents are not looking.
>Thus, we can see that f(R) < f(R/N), and in particular,
>T*f(R) < T*f(R/N), so the way to minimize the expected loss is to
>choose the single-cipher strategy (the "AES" approach). Using lots
>of ciphers only increases the expected loss.
GIGO.
>In the real world, the expected loss is probably not exactly the right
>function to minimize (probably the harm is a non-linear function of
>the amount of traffic compromised, where leaking 10% of one's traffic
>is almost as bad as leaking 90% of it). Nonetheless, a moment's thought
>will show that adjusting this assumption to be more realistic will only
>widen the gap between the two strategies, and will make the "AES"
>approach even more appealing than the above calculation might suggest.
I would say that "a moment's thought" should be sufficient to show the
futility of attempting a statistical argument on something which one
cannot measure, such as cipher "strength," or discussing the
"probability" that it will be broken, when we have no accounting and
no evidence relating to real probability.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: Arthur Dardia <[EMAIL PROTECTED]>
Subject: Re: ti83 encryption
Date: Tue, 14 Sep 1999 19:16:21 -0400
Reply-To: [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
>
> Arthur Dardia wrote:
>
> > I'll give an example:
> >
> > ptext: SECRET
> > key: TYMSNA
> >
> > T+S
> > 20+21=41 L1(1)=41 (first element in List 1)
> > 41-26=15 (Get it under, or equal to 26)
> > T+S=O (Convert to letter, store in Str3)
>
> Isn't this just a Virgenee (sp) cipher?
Is it? I don't know much about encryption. I don't have that much time on my
hands to read anything worth while, except what's posted on this newsgroup. I'm
going to start reading Handbook of Applied Crytography, since it's freely
available now. I'm scouring libraries for Bruce's Applied Crytography too. If
this is a Virgenee cipher, is it secure?
Art Dardia
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: Size of DH exponent & modulous??
Date: Tue, 14 Sep 1999 18:03:43 -0600
Eric Lee Green wrote:
>
> Peter Gunn wrote:
> > Would a 512bit prime, and 256bit values for x and y suffice?
> >
> > Similarly, any suggestions for key lengths of 128bits and 256bits?
>
> For a uniform distribution you need a range for x and y that is (P-1) in
> size. That is, x and y should probably have the same number of bits as
> the prime.
>
> According to at least one source that I came across, breaking
> Diffie-Hellman may be reducible to the same order as breaking the
> factoring problem. A 512-bit number was recently factored. Thus a field
> size of 1024 bits is probably a better choice nowdays than a 512-bit
> field size.
But not for a 56-bit session key (which is what he asked about).
John M.
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Sources of randomness
Date: Wed, 15 Sep 1999 00:00:55 GMT
On Tue, 14 Sep 1999 11:01:26 -0700, in <[EMAIL PROTECTED]>,
in sci.crypt "John E. Kuslich" <[EMAIL PROTECTED]> wrote:
>If you have ever tried to design an electronic circuit that produces a
>"random" stream, you will appreciate the difficulty of removing any
>periodic (correlated) data.
>[...]
I have, and it is do-able, as long as one is aware of what is
required.
Please see my *preliminary* designs and the characterization of the
results they produce:
http://www.io.com/~ritter/NOISE/NOISRC.HTM
http://www.io.com/~ritter/NOISE/NOISCHAR.HTM
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: [EMAIL PROTECTED] (Ian Goldberg)
Subject: Re: ti83 encryption
Date: 15 Sep 1999 00:24:10 GMT
In article <[EMAIL PROTECTED]>,
Arthur Dardia <[EMAIL PROTECTED]> wrote:
>The above URL is for his Solitaire encryption scheme which uses the same
>algortihm, only implemented with a deck of cards.
Your system is a one-time pad, since you insist that the key be as long
as the message, and that the key be generated at random.
Solitaire is *not* a one-time pad. It is a totally different system;
why do you claim that algorithm is just "add the key"? The most cursory
glance at the web page you cited shows that it's much more involved than
that...
- Ian
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: How strong is RC4 ?
Date: Tue, 14 Sep 1999 18:19:28 -0400
yoni wrote:
> I want to use a secured socket that uses RC4 to encrypt data sent from a
> client to a server, The key is known to both sides.
> An attacker can collect the messages passed and analyze them or even try
> to make a chosen text attack and reconstruct the key.
> What is the streangth of RC4 (and stream ciphers generally) against such
> attacks ?
> How much time can I use a 128 bits key before I need to replace it ?
People on this board can give you a better overview of RC4 security than I
can, but after getting adivce and knowhow from several people, I can pass
along what I know:
First of all, you need to cycle out the first 256 (minimum) output bytes of
RC4...some people even go up to 1024 bytes. To do this:
unsigned char buffer[1024];
rc4(buffer, 1024, RC4_key);
memset(buffer, 0, sizeof(buffer));
This fixes a weak key problem.
Also, you should NEVER use the same key twice. I am not exactly sure how
your program works, but if it uses session keys, make sure a key is never
reused. If you need a new key, either generate a new one, or use a salt. A
salt does not have to be secret, but must be unique and it works like this:
unsigned char password[16]; // <- that's a 128 key right?
unsigned char salt[16];
// here initialize the salt, a simple counter works the best, or
/dev/urandom is ok too.
for (i = 0; i < 16; i++)
password[i] ^= salt[i];
//prepare rc4 here, and memset the password.
Now your encrypted message is:
<salt><encrypted text>
Where the salt is unencrypted in the clear.
Finally, you asked how long a single 128 bit key can be used...difficult
question. RC4 (from what I understand), does not have a set period. It has
been guestimated at 2^1700. That is a very large number.... Although, you
could get unlucky and get a short cycle. I will leave the guessing of how
much you can encrypt to the real experts, as I do not know how much is safe
or unsafe.
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Sources of randomness
Date: Wed, 15 Sep 1999 00:06:35 GMT
On 14 Sep 1999 12:11:30 -0700, in
<7rm6l2$65v$[EMAIL PROTECTED]>, in sci.crypt
[EMAIL PROTECTED] (David Wagner) wrote:
>In article <[EMAIL PROTECTED]>,
>Scott Nelson <[EMAIL PROTECTED]> wrote:
>> But CRC, a.k.a Linear Feedback Shift Register, is usually much
>> smaller and faster than a cryptographically secure hash. If
>> the object is to distill random bits from a biased source,
>> it seems a better choice to me.
>
>Smaller, faster, and almost certainly less secure[1].
>My advice: stick with a cryptographic hash function (e.g., SHA1).
>
>
>[1] One can prove that CRCs are adequate for distilling entropy: the
> leftover hash lemma says that if you use a LFSR with a n-bit output
> and a random (uniformly-distributed) feedback function, and if you
> have at least 3n bits of Renyi entropy of order 2 in the source
> (different from the usual measure of entropy!!!), and if you never
> use it more than once, then the n-bit output has close to the uniform
> distribution.
>
> However, this approach is terribly wasteful of random bits, requires
> stronger-than-usual assumptions on the distribution of the inputs,
> and in practice is probably highly susceptible to deadly implementation
> errors.
The alternative appears to be to rely upon the supposedly opaque
qualities of a cryptographic hash. But if *that* worked, we wouldn't
need any true randomness, or at least very little. That would seem to
solve our problems, yet problems remain.
The advantage of true randomness is that it *cannot* be predicted,
even if the hash is broken. Perhaps someone would like to prove -- or
find the probability -- that any particular hash is unbreakable.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Ritter's paper
Date: Tue, 14 Sep 1999 23:58:02 GMT
On Tue, 14 Sep 1999 20:28:45 GMT, in <7rm7ls$1jki$[EMAIL PROTECTED]>, in
sci.crypt [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
>In article <[EMAIL PROTECTED]>, Medical Electronics Lab
><[EMAIL PROTECTED]> wrote:
>>Terry Ritter wrote:
>>> There is a copy of the article .PDF on my pages. It is first in the
>>> list in the Technical Articles section on my top page. The exact link
>>> is:
>>>
>>> http://www.io.com/~ritter/ARTS/R8INTW1.PDF
>>
>>Thanks!
>>
>>Patience, persistence, truth,
>>Dr. mike
>
> I check it out nice article. But what I did not get was the comment about
>if you use a patented system and someone breaks it you can recover damages.
>What did you mean by that Mr. Ritter. Are you saying it is against the law to
>decode something this is encrypted with a patented method?
Against the law? Well, yes, sort of: using a patented cipher without
an explicit license is grounds for a suit to recover damages in
federal court.
This is a distinct -- perhaps minor, perhaps not-so-minor -- advantage
over non-patented designs, for which, if broken, there is no recourse
at all. The hard part would be to know what company was involved, but
once you get wage-scale employees in depositions or even on the stand,
someone would probably tell the truth, if just to avoid the stigma of
perjury.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: "Steven Alexander" <[EMAIL PROTECTED]>
Subject: Re: RC4-40 Cracking
Date: Tue, 14 Sep 1999 11:51:24 -0700
> I should note, however, that I recall that at the time the paper was
> released some commented that they felt that these estimates overly
> estimated the rate at which an programmable logic chips could test RC4
> keys.
>
> -Richard
Even if they overly estimated at the time, the estimates would surely be
reasonable today if not better.
-steven
------------------------------
** 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
******************************
