Cryptography-Digest Digest #984, Volume #10 Thu, 27 Jan 00 00:13:02 EST
Contents:
Re: Why did SkipJack fail? ("Steve Sampson")
Re: Why did SkipJack fail? (Jerry Coffin)
Re: english word list (Jerry Coffin)
Re: How much does it cost to share knowledge? (Paul Rubin)
Re: How much does it cost to share knowledge? (Jerry Coffin)
Re: ECC & RSA re: patents, copyrights (Paul Rubin)
Re: ECC & RSA re: patents, copyrights (Greg)
Re: Why did SkipJack fail? (Paul Rubin)
Re: Why did SkipJack fail? (Paul Rubin)
Re: SRP optimisation (David Hopwood)
Re: SRP optimisation (John Myre)
Re: Pencil & paper cipher question (Uri Blumenthal)
Re: NIST, AES at RSA conference ([EMAIL PROTECTED])
Re: ECC & RSA re: patents, copyrights (Greg)
Re: Why did SkipJack fail? (Jerry Coffin)
Re: ECC & RSA re: patents, copyrights (Bill Unruh)
----------------------------------------------------------------------------
From: "Steve Sampson" <[EMAIL PROTECTED]>
Subject: Re: Why did SkipJack fail?
Date: Wed, 26 Jan 2000 20:09:27 -0600
Why?
Because it was uneconomical. The reason any product fails.
------------------------------
From: Jerry Coffin <[EMAIL PROTECTED]>
Subject: Re: Why did SkipJack fail?
Date: Wed, 26 Jan 2000 19:32:47 -0700
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
> Jerry Coffin wrote:
> > Doing some figuring, that seems to come to around $200 million US to
> > break SkipJack at a rate of one key per year -- an amount of money
> > that quite a few large companies or most government agencies could
> > afford fairly easily.
>
> I doubt the financial officers would approve such an expenditure
> for so little gain! $200M/key/yr is not very productive.
The amount of gain obviously depends on what you expect to recover. I
doubt anybody would do this as as blue-sky type of thing. OTOH, if
they had a reasonable expectation of recovering something they
considered worth substantially MORE than the $200M, and would remain
that valuable for at least the year involved, then I could easily see
a financial officer approving the expenditure.
Another possibility is that a company could decide to build such a
thing as a technology demonstration. Offhand I don't know what IBM
has spent on Deep Blue, but no matter how good it gets at chess, I
doubt it'll ever (directly) generate enough revenue to pay for itself.
Despite this, somebody apparently thought it was worth the
expenditure, and I'd tend to agree.
Ultimately, without knowing the possible gain, it's impossible to say
that a particular investment would be good, bad or indifferent.
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
From: Jerry Coffin <[EMAIL PROTECTED]>
Subject: Re: english word list
Date: Wed, 26 Jan 2000 19:38:42 -0700
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] says...
[ ... ]
> Kids, let this be a lesson to you about the inadvisability of
> using ordinary words for passwords...
...or perhaps the advisability, since it's a pretty fair bet that more
users lose more to losing/forgetting passwords than they do to others
breaking into their systems.
Of course, with that said, I'm pretty sure a dictionary attack won't
find my password on my machine... <G>
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: How much does it cost to share knowledge?
Date: 27 Jan 2000 02:38:22 GMT
In article <86nm43$soe$[EMAIL PROTECTED]>,
Tom St Denis <[EMAIL PROTECTED]> wrote:
>In article <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] (JPeschel) wrote:
>> Tom St Denis [EMAIL PROTECTED] writes, in part:
>>
>> >I think they are being a bit arrogant there.
>> >
>>
>> How is charging a fee for a conference arrogant?
>
>300 dollars for a folding chair in a conference room is abit much.
If it's for FSE, it's not that surprising. That's fairly typical
of conferences. You might ask for a scholarship.
If it's just for the AES part, that's government sponsored and it
really ought to be free.
------------------------------
From: Jerry Coffin <[EMAIL PROTECTED]>
Subject: Re: How much does it cost to share knowledge?
Date: Wed, 26 Jan 2000 19:47:34 -0700
In article <86nm43$soe$[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
[ ... ]
> Well you must be rolling in the dough. where I come from you don't
> spend 300 dollars on a meal.
Have you checked on what it costs to rent a banquet hall for a day?
One that seats a few hundred people that is?
[ ... ]
> Call it whining if you want. BTW isn't AES suppose to be open to
> everyone? Not just the rich?
Sure. Now keep in mind that if they didn't charge the participants to
defray the cost that it would be us taxpayers here in the US who'd
have to pay instead. Why should my taxes be higher to give a free
ride to some Canadian high school kid who openly admits he won't
understand most of what's going on anyway?
In all honesty, I wouldn't mind a bit paying that little bit of extra
tax, and I certainly don't mean to attack you, but I think you get the
general idea...
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: ECC & RSA re: patents, copyrights
Date: 27 Jan 2000 02:47:26 GMT
In article <86l7em$2t4$[EMAIL PROTECTED]>, Greg <[EMAIL PROTECTED]> wrote:
>How can RSA patent even exist if it is based upon implementing
>simple a mathematical operation?
It's a bad situation all around. See the article "Against Software
Patents" at http://lpf.ai.mit.edu/.
>And given the answer to that, is it likely something similar
>will happen with ECC technology? Or is there enough prior
>publications in circulation to prevent this?
>
>I guess I am wondering if ECC has a future that looks like it
>will always remain free of patent obsticals?
ECC over GF(p) appears to be unencumbered by patents.
Some other methods, maybe including doing the calculations
with optimal normal bases over GF(2^p), avoiding the need
for scalar multiplication, appear to be patented by Certicom.
The GF(p) method is nice if you want short public keys, but
it's more computationally expensive than some of the patented
methods.
------------------------------
From: Greg <[EMAIL PROTECTED]>
Subject: Re: ECC & RSA re: patents, copyrights
Date: Thu, 27 Jan 2000 02:35:49 GMT
> > Certicom has a couple of patents on specific
> > methods of carrying out some of the operations in ECC, but it's
> > entirely possible to implement ECC without using them.
>
> 1. I don't know for sure, but I heard that Certicom is not the
> only patent holder wrt. ECC.
>
> 2. Are you *sure* that it is entirely possible to implement
> ECC without using Certicom patents and still INTEROPERATE
> with a Certicom implementation?
What patents are there for ECC today?
The basic ECC algorithm is R = Pk where k is the private key
and P is a base point and R is the public key. Is this algorithm
patented for the process of generating a public key?
--
The only vote that you waste is the one you never wanted to make.
RICO- we were told it was a necessary surrender of our civil liberties.
Asset Forfeiture- the latest inevitable result of RICO.
http://www.ciphermax.com/book
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: Why did SkipJack fail?
Date: 27 Jan 2000 02:58:41 GMT
In article <[EMAIL PROTECTED]>,
Paul Koning <[EMAIL PROTECTED]> wrote:
>That isn't terribly relevant. Deep Crack is enormously faster than
>distributed.net, and you could easily get two or three orders of
>magnitude today without a whole lot more money for ciphers like
>DES that take few gates and parallelize well. RC4 (did you mean
>RC4 rather than RC5?) is much harder to attack fast in hardware.
1) Deep crack is not enormously faster than distributed.net.
At the time of the last DES contest, they were about equal
in speed. Distributed.net now appears to be faster. Distributed.net
of course can't be operated in secret ;-).
2) It is absurd to say you could easily get two or three orders of
magnitude (vs. Deep Crack) today without a whole lot more money. Deep
Crack was just about as good as you could do when it was built,
without spending a lot more on NRE. Keep in mind too that most of the
engineering was done for free by volunteers--think your 100% brand new
effort for snooping real traffic is going to be built by volunteers?
Moore's law says computing speed per dollar doubles every 18 months or
so. Deep Crack was built just about exactly 18 months ago. If it were
done today instead, Moore's law says it would be about twice as fast.
I don't see any special technology advances that would speed up a new
Deep Crack effort more than just the general improvements (fab technology)
predicted by Moore's law. A factor of two is a long way from "two
or three orders of magnitude".
3) I meant rc5. See the www.distributed.net homepage. It says right
near the top that distributed.net is now crunching rc5 at 122.77
gigakeys/second.
>I suspect a major reason why Skipjack failed is that it was
>classified until a year or so ago. So by the time it was finally
>published, no one cared anymore. At least not enough to adopt it.
>If it had been made public when first proposed, things might have
>been different, although even then the taint of Clipper would have
>been a big issue.
Who says Skipjack failed? It was never intended to be a general
purpose cipher except in conjunction with Clipper. Clipper failed for
reasons having nothing in particular to do with Skipjack. Skipjack
was declassified so it could be used in the Defense Messaging System
in software interoperable with Fortezza and similar implementations
and as far as I know, that effort has been successful. As a side
effect of the declassification, the design is now available for people
to use it in other applications, but if nobody does so, that doesn't
make it a "failure".
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: Why did SkipJack fail?
Date: 27 Jan 2000 03:09:58 GMT
Jerry Coffin <[EMAIL PROTECTED]> wrote:
>> >Worse yet, (from one viewpoint) SkipJack was carefully designed to
>> >require _extremely_ minimal hardware. That makes it easier to include
>> >in minimal hardware like a smartcard.
>>
>> What viewpoint is that?! For some of us, this is a huge advantage and
>> is Skipjack's main selling point.
>
>From the viewpoint of security, obviously. From a viewpoint of usage,
>you'd like a cipher to be as fast and cheap to implement as possible.
>From a viewpoint of security, you'd like it to be as slow and
>expensive to implement as possible. Doing a brute-force search of the
>entire key-space obviously depends on doing a lot of encryptions very
>quickly, and preferably for as little money as possible. Preventing
>it means either making the keyspace extremely large, or making it very
>slow to generate and test a single key.
The way to slow down brute force search is with more bits of keyspace,
not more complexity to the cipher.
>distributed.net may be the fastest relatively general-purpose computer
>around, but I really doubt it's the fastest computer -- Deep Crack is
>devoted strictly to breaking DES, but as I understand things, it's
>substantially faster the distributed.net.
Not anymore.
>Deep Crack was built in 0.8 micron chips running at 50 MHz. Today,
>simply due to improvements in chip technology, it would be quite
>reasonably to build a similar design in .18 micron technology, which
>would run at around 500 MHz. The move from .8 to .18 micron allows
>you to put around 20 times as many encryption engines in the same die
>area. The move from 50 to 500 MHz is another factor of 10. That
>means the same number of chips would build a machine roughly 200 times
>as fast today as it did then.
You couldn't build a .18 micron Deep Crack today without spending a
heck of a lot more money than Deep Crack cost. Deep Crack was
relatively cheap ($250K) because it used a semicustom (rather than
fully custom) chip design and a fairly low tech fab process. With the
same $250K today (18 months after Deep Crack was built), Moore's Law
predicts you could get about double the speed.
>Doing some figuring, that seems to come to around $200 million US to
>break SkipJack at a rate of one key per year -- an amount of money
>that quite a few large companies or most government agencies could
>afford fairly easily.
The interest on $200 million for a year (at 7%) is $14 million. If
it's going to cost the attacker $14 million to break one key, and it's
going to take them a year to do it, I'd say that cipher is safe for
most purposes.
------------------------------
From: David Hopwood <[EMAIL PROTECTED]>
Crossposted-To: sci.crypt.research
Subject: Re: SRP optimisation
Date: 26 Jan 2000 19:12:48 -0800
=====BEGIN PGP SIGNED MESSAGE=====
Keith Burdis wrote:
> [documentation for SRP-3:]
>
> http://srp.stanford.edu/srp/doc.html
>
> Looking at Optimized SRP described in Tom Wu's ISOC paper on SRP,
> [...]
> As noted, three messages is the lower bound for a secure authentication
> protocol, but would it not be possible to have:
>
> C --> S: C,A
> C <-- S: s,B,M2
> C --> S: M1
>
> where:
>
> M1 = H(B,M1,K)
> M2 = H(A,B,K)
How can M1 be a hash of something that includes M1? I'll assume you meant
"M1 = H(B,M2,K)".
> This allows mutual authentication to take place in three rounds
> instead of four.
>
> Can anyone see any problems with this?
>
> Does having the server send its evidence first adversely affect the
> security of SRP in any way?
Yes, it allows an adversary posing as the client to gain sufficient
information to do an off-line dictionary attack. For example:
Let p be Client's password
s be Client's random salt
v = g^H(s, p)
Adversary: choose any convenient a.
Adversary -> Server: Client's username, A = g^a
Server: choose random b and u.
B = v + g^b
K = H((Av^u) ^ b)
Server -> Adversary: s, B, H(A,B,K)
Adversary: disconnect.
for (p' = each password in dictionary) {
x' = H(s, p')
K' = H((B - g^x') ^ (a + ux'))
if (H(A,B,K) == H(A,B,K'))
p' is almost certainly the correct password.
}
- --
David Hopwood <[EMAIL PROTECTED]>
PGP public key: http://www.users.zetnet.co.uk/hopwood/public.asc
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
"Attempts to control the use of encryption technology are wrong in principle,
unworkable in practice, and damaging to the long-term economic value of the
information networks." -- UK Labour Party pre-election policy document
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOH/NKjkCAxeYt5gVAQGm3wgAgcI0DApabJ4sRPjCnkRI+7G6iigc7i9z
BzhEDer9N5tb7R6E2t+9RigZb4HJ4KFYVnA/OjVwc4xLEk4QffET1AX9sL1COhmI
iMU02mRtZJWuOHO03XhHZ7mgn9tDbN+sMhZKSnW8/gOutZ6OeUOzcAt9tVuy+RGf
sNvHP8Wpt6GYow6Y+ODL9bDwrF/SsgDuEBvmqTJa61TpM78DuF2RkWRxAldKsrv+
EWAFMIGCQXp12a1Ws0wYUcAXFDm3c+EXr3Rp4A7JR4bQ9HKLAXLsNlhbiOpIq+Q+
+0rMjEgdnsGbJlhAf9tlJjvmxCTT1JN56mh2o5D1/jHi6Ylqu1dMRw==
=Sh1t
=====END PGP SIGNATURE=====
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Crossposted-To: sci.crypt.research
Subject: Re: SRP optimisation
Date: 26 Jan 2000 19:13:05 -0800
Here is a different idea for reducing SRP to three messages. It
requires, however, that the client know the salt ahead of time.
Recall the four-message version:
> C --> S: C, A = g^a
> C <-- S: s, B = g^b + v
> C --> S: M1 = H(A,B,K)
> C <-- S: M2 = H(A,M1,K)
where
C = the client (name),
a and b are new random values,
"verifier" v = g^x,
x = H(s,P),
H is a hash function,
P is the password,
s = the salt,
key K = H(S)
S = secret = (B-v)^(a+ux) = (Av^u)^b = g^(ab+bux)
u = public random value, e.g. H(B)
To keep the protocol secure, the server S cannot send M2 until
after the client C sends something to commit to a password.
We don't want to send anything from C to S that is more than
what S already knows, namely v, the verifier. But the client
doesn't know v; it is calculated from the password and the
salt. So if the first message depends on v, then the client
has to know the salt without asking the server.
Suppose that we can meet this requirement somehow (see later).
An important requirement is that what C sends to S in the first
message does not commit to v in such a way that an attacker can
use it to verify a password guess. How about if we repeat the
trick used in computing B, and set A = g^a + v?
Then the protocol becomes:
C --> S: C, A = g^a + v
C <-- S: B = g^b + v, M2 = H(A,B,K)
C --> S: M1 = H(M2,B,K)
K is still computed the same way, except that the server
must remember to subtract v from A (to get g^a).
The reason I think this is still secure is that an attacker
can't try multiple passwords with the same A: each guess
results in a different g^a which would require solving for
a (the difficulty of which is the basis for the strength of
the protocol in the first place). This is basically the same
reason SRP can't be attacked by impersonating the server.
Any comments?
Now as to requiring the client to know the salt: why not?
If I understand the purpose of the salt, it does not need any
particular entropy, or anything. It just needs to ensure that
any two users have different verifiers, even if their passwords
are the same. So wouldn't H(C,S) work? Maybe even H(C) would
be enough; then we just worry about two users with the same
name having the same password (across all servers everywhere).
It's possible, but perhaps it is sufficiently unlikely to be
ignorable?
Actually I suppose this question applies to lots of password
situations - what would be wrong with using the username as
the salt? I have this nagging feeling that it's bad, since it
is never done. Is it because you can't change the salt when
you change the password, or something?
John M.
------------------------------
From: Uri Blumenthal <[EMAIL PROTECTED]>
Subject: Re: Pencil & paper cipher question
Date: Wed, 26 Jan 2000 22:50:06 -0500
Reply-To: [EMAIL PROTECTED]
John Savard wrote:
> >3. Prefers not to have to construct LENGTHY polyalphabetic tables
>
> The use of a straddling checkerboard, so that you can add digits
> instead of using a 26 x 26 Vigenere table is then advisable.
>
> You might get some ideas from my page. I'd recommend something
> involving fractionation. <http://www.ecn.ab.ca/~jsavard/crypto.htm>
Yes, a very good advice. My vote goes for VIC. It's bloody hard
to memorize the generation sequence, but once it's done, it's
quite secure.
--
Regards,
Uri [EMAIL PROTECTED] M.C.Ht N2RIU
-=-=-==-=-=-
<Disclaimer>
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: NIST, AES at RSA conference
Date: Thu, 27 Jan 2000 04:04:34 GMT
Terry Ritter wrote:
[...]
> Any cipher we use may have already been broken. As a consequence, no
> matter how much effort was placed into cryptanalysis, the strength we
> have may approach zero with probability 1. Then, no matter how many
> professors try and fail to break the cipher, the probability of
> weakness is *still* 1, and we will not know.
Alas the situation is still worse. We don't even know that
practical and secure ciphers exist. We cannot disprove, or
even bound the probability away from 1, that an attacker has
a single algorithm that breaks all key-based ciphers given
ciphertext that covers the unicity distance.
[...]
> That is life; now we have to learn how to deal with it. One way is to
> extrapolate from the failure of academic breaking attempts to the
> hoped-for failure of well-equipped full-time professionals.
> Unfortunately, such extrapolation is simply invalid and false. So
> that is not a good way to deal with our sad situation.
>
> Another way to deal with real life ciphering is to use methods which
> tend to isolate and protect the ciphers we cannot trust. For example,
> multi-ciphering with a sequence of different ciphers has advantages.
Giving us a multi-cipher we cannot trust. The probability
of weakness argument still applies and with the same
parameters.
[...]
> Your "warm and fuzzy" detector perhaps has failed to take into account
> the little detail of *risk*: In particular, the risk of an entire
> society locked-in to using a single cipher, or any small set of
> ciphers.
Alas we cannot show that the risk of using a large, or even
open-ended set of ciphers is any smaller.
--Bryan
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Greg <[EMAIL PROTECTED]>
Subject: Re: ECC & RSA re: patents, copyrights
Date: Thu, 27 Jan 2000 04:18:34 GMT
> > > Certicom has a couple of patents on specific
> > > methods of carrying out some of the operations in ECC, but it's
> > > entirely possible to implement ECC without using them.
> >
> > 1. I don't know for sure, but I heard that Certicom is not the
> > only patent holder wrt. ECC.
> >
> > 2. Are you *sure* that it is entirely possible to implement
> > ECC without using Certicom patents and still INTEROPERATE
> > with a Certicom implementation?
>
> What patents are there for ECC today?
>
> The basic ECC algorithm is R = Pk where k is the private key
> and P is a base point and R is the public key. Is this algorithm
> patented for the process of generating a public key?
I checked with the online db at the pto web site and what I found
was a couple of patents by Richard Crandall (NeXT) that uses
the formulas above, but it appears his patent is centered around
optimized parameters and algorithms to take advantage of those
parameters. I don't think there are any patents before these
that touch on R=Pk algebra and so I think it would be considered
prior art from literature on ECC. Perhaps from something Koblitz
had written?
Anyone have anything more definitive history on R=Pk for ECC?
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Jerry Coffin <[EMAIL PROTECTED]>
Subject: Re: Why did SkipJack fail?
Date: Wed, 26 Jan 2000 21:43:03 -0700
In article <86ocu6$hp7$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
says...
[ ... ]
> The way to slow down brute force search is with more bits of keyspace,
> not more complexity to the cipher.
I openly agree that more bits of keyspace tends to be a more effective
method, but adding complexity to the cipher DOES work. One thing that
works particularly well is to make it fairly easy to encipher quickly
once things are set up, but to make the initial setup relatively slow.
As long as you set a key up once, and encrypt large amounts of text
with it, this has only a little effect on overall speed. For
breaking, you do the opposite, setting up lots of keys and encrypting
(or decrypting) only a small amount of text with each.
In any case, you can deny it all you want, but the reality is that
every time you make encryption take (for example) twice as long, it's
equivalent to adding one bit to the key from a viewpoint of the
difficulty of exhausting the key space.
> >Deep Crack was built in 0.8 micron chips running at 50 MHz. Today,
> >simply due to improvements in chip technology, it would be quite
> >reasonably to build a similar design in .18 micron technology, which
> >would run at around 500 MHz. The move from .8 to .18 micron allows
> >you to put around 20 times as many encryption engines in the same die
> >area. The move from 50 to 500 MHz is another factor of 10. That
> >means the same number of chips would build a machine roughly 200 times
> >as fast today as it did then.
>
> You couldn't build a .18 micron Deep Crack today without spending a
> heck of a lot more money than Deep Crack cost. Deep Crack was
> relatively cheap ($250K) because it used a semicustom (rather than
> fully custom) chip design and a fairly low tech fab process. With the
> same $250K today (18 months after Deep Crack was built), Moore's Law
> predicts you could get about double the speed.
You're making a number of fundamental mistakes in your assessment.
First of all, you're quoting the cost as $250,000, when the book says
the cost was about $210,000. Second, of that $80,000 is said to have
been the design cost, and the other $130,000 the cost of materials.
Building a machine twice as fast (for example) doesn't double the
design cost, only the materials cost. IOW, a machine twice as fast as
Deep Crack would have cost roughly $340,000, rather than the $500,000
you're trying to peg it at.
Now, consider the realities of ASICs: when you get ASICs built, there
are basically two phases to things: first they have to make masks to
be able to make the chips at all. Once the masks are made, they can
crank out chips fairly inexpensively. IOW, as the quantity of chips
goes up, the cost per chip drops substantially. In a machine to break
SkipJack, you'd be using enough more chips that your per-chip cost
would be substantially lower than for the 1536 chips used in Deep
Crack.
As I mentioned in a previous message, the chip foundry situation has
changed considerably in the last year or two as well. A few years
ago, it was relatively difficult to get relatively high-tech designs
built at a chip foundry. You had little choice but to settle for
relatively out-of-date processes unless you were looking at buying a
LOT of chips. The situation now is different. Chip foundries now
have as good of process technology available as other fabs. Getting
an order of magnitude (or more) chips built also gives you a MUCH
better bargaining position. Of course, if an representative of the
NSA shows up, he probably automatically has a better bargaining
position than a representative of the EFF in any case.
Consider that the EFF chips appear to have cost approximately $80
apiece, for 50 MHz chips. You can now get a 400 MHz Celeron (a MUCH
more complex chip) for around that price, retail. Part of that is due
to competition, part to improvements in chip technology, and part to
economies of scale. ALL of these apply to greater or lesser degrees
in building a SkipJack breaker now versus the building of Deep Crack.
In short, I'm quite certain that if the $200M value is off, it's FAR
more likely to be high than low.
> >Doing some figuring, that seems to come to around $200 million US to
> >break SkipJack at a rate of one key per year -- an amount of money
> >that quite a few large companies or most government agencies could
> >afford fairly easily.
>
> The interest on $200 million for a year (at 7%) is $14 million. If
> it's going to cost the attacker $14 million to break one key, and it's
> going to take them a year to do it, I'd say that cipher is safe for
> most purposes.
Probably -- as long as you're not protecting anything worth more than
$14M/year (or so) there's at least a fair chance of it. Then again,
for MOST purposes, DES or even double-transposition with a good key is
probably reasonably safe -- I'd bet more messages encrypted with PGP
have to do with what the new secretary looks like in a mini-skirt than
with anything worth tens or hundreds of millions of dollars a year...
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: ECC & RSA re: patents, copyrights
Date: 27 Jan 2000 05:09:33 GMT
In <86obju$q7h$[EMAIL PROTECTED]> [EMAIL PROTECTED] (Paul Rubin) writes:
>In article <86l7em$2t4$[EMAIL PROTECTED]>, Greg <[EMAIL PROTECTED]> wrote:
>>How can RSA patent even exist if it is based upon implementing
>>simple a mathematical operation?
It is not based on implemeting a simple mathematical operation. It is
based on using that mathematical operation for a very specific purpose.
Your stance is like saying "How can the safety pin be patented since it
is just bending a piece of wire.?"
>It's a bad situation all around. See the article "Against Software
>Patents" at http://lpf.ai.mit.edu/.
Whether or not software in general should be patentable is a different
issue. RSA is not a patent on software. It applies equally well if you
implement it in a set of gate arrays, or however you wish. Implimenting
it in software is one one possible way.
------------------------------
** 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
******************************
