Cryptography-Digest Digest #508, Volume #11 Fri, 7 Apr 00 14:13:01 EDT
Contents:
Re: Is AES necessary? (Tom St Denis)
Re: Crypto API for C (Tom St Denis)
Re: Is AES necessary? (John Myre)
[Q] Insecurity ("David C. Oshel")
Re: RC4 statistics (David A. Wagner)
Re: GSM A5/1 Encryption (David A. Wagner)
Re: GSM A5/1 Encryption (David A. Wagner)
Re: design of MD family ciphers ("Scott Fluhrer")
Re: Q: Simulation of quantum computing (Bill Unruh)
Re: Is AES necessary? (John Savard)
Re: Factoring Composite Numbers (John Savard)
Re: Simple authentication protocol: any good? (Eric Lee Green)
Re: Keys in blowfish (Eric Lee Green)
Re: Is AES necessary? (Eric Lee Green)
Re: Sunday People 26/3/2000: "FORGET YOUR PASSWORD... END UP IN JAIL" ("Sid")
Re: Magnetic Remenance on hard drives. (jungle)
Re: Massey-Omura protocol & ECC (Mike Rosing)
Re: GSM A5/1 Encryption (John Myre)
Re: enigma returned (Jerry Coffin)
Re: An interesting cryptographic problem (Mike Rosing)
Re: Schoof's Algorithm (Mike Rosing)
Re: [Q] Insecurity (Mike Rosing)
Re: Public|Private key cryptography? (Jerry Coffin)
Re: GSM A5/1 Encryption (David A Molnar)
----------------------------------------------------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Is AES necessary?
Date: Fri, 07 Apr 2000 14:34:26 GMT
Mok-Kong Shen wrote:
>
> Tom St Denis wrote:
> >
>
> > But won't these variants of DES just be in the same vain as AES? BTW I
> > would tend to believe ciphers like RC6/Twofish/Serpent as way more
> > securer [i.e harder to attack] then 3DES. So in the long run, you can
> > still use a 64 bit block cipher like RC5/CAST or SAFER-SK, but if you
> > want a larger keyspace [why not?] or bigger block size...
>
> A bigger key space would mean greater strength. I don't mind
> which cipher one prefers. I mean that the potential of having
> higher strength has not been exhausted. So there is no need to
> switch to a entirely new cipher.
>
I dunno, I included 7 potentially secure ciphers in CB [and in PB3]
simply because different people like diff ciphers. Letting my users
choose which cipher they want is something they normally appreciate.
However I would strongly believe *any* cipher they did pick was secure.
I for example will use Serpent when PB3 is done simply because of the
fact the best attack only kills 9 rounds in 2^240 or so effort, so I
believe the conservative design makes it very secure. Others like RC6
or Blowfish for example because of their construction [they like how the
cipher was made]....
It's a crowd pleasing act.
Basically: Yeah a system would be secure using *only* one cipher [such
as 3des] but where's the fun in that?
Tom
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Crypto API for C
Date: Fri, 07 Apr 2000 14:36:07 GMT
Runu Knips wrote:
>
> Tom St Denis schrieb:
> > And I don't mind 'good' feedback :-)
>
> Hey okay I'll check it again at home on my little linux pc :)
> Just that you're able to sleep ;-)) Btw, many people might
> find this address just by using search machines etc, so they
> don't know you want feedback in sci.crypt 8-)
>
> P.s.: Hmm no ElGamal yet ... RSA is still patented, isn't it ?
Well my email addy is in the package too.
Like I have said before, any problems at all I am willing to fix. It's
still far off from being portable...
I use RSA in CB mainly because it's faster, simpler and more compact.
If you want to add ELG functions by all means I will include them. I am
just busy at the moment.
Tom
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: Is AES necessary?
Date: Fri, 07 Apr 2000 08:47:55 -0600
[EMAIL PROTECTED] wrote:
>
> and the strength is not only requirement for AES
> there are more parameters including speed
>
and the block size - which is actually cryptographically
important (for some applications).
------------------------------
From: "David C. Oshel" <[EMAIL PROTECTED]>
Subject: [Q] Insecurity
Date: Fri, 07 Apr 2000 10:46:25 -0500
If a bytestream never repeats itself in a universe bounded by proton decay,
and produces 1 and 0 in every bit position in the ratio 1:1 on average, and
passes Chi-square, why is it still not cryptographically secure?
--
David C. Oshel mailto:[EMAIL PROTECTED]
Cedar Rapids, Iowa http://pobox.com/~dcoshel
``Tension, apprehension, and dissension have begun!" - Duffy Wyg&, in Alfred
Bester's _The Demolished Man_
------------------------------
From: [EMAIL PROTECTED] (David A. Wagner)
Subject: Re: RC4 statistics
Date: 7 Apr 2000 08:10:30 -0700
In article <[EMAIL PROTECTED]>,
Johnny Bravo <[EMAIL PROTECTED]> wrote:
> On average you would detect about 16 extra instances of successive
> identical bytes per megabyte of output. The probability of a doubled
> byte is nearly 2^-8 + 2^-24 rather than the 2^-8 expected from random
> output. See http://www.hedonism.demon.co.uk/paul/rc4/
Those two numbers don't match. If the prob. is 2^-8 + 2^-24, then
you would expect 2^20/2^24 = 1/16 extra instances per megabyte of
output, or 64 extra instances per gigabyte. Or am I missing something?
------------------------------
From: [EMAIL PROTECTED] (David A. Wagner)
Subject: Re: GSM A5/1 Encryption
Date: 7 Apr 2000 08:13:53 -0700
In article <8ckmgf$hc9$[EMAIL PROTECTED]>,
Matt Linder <[EMAIL PROTECTED]> wrote:
> Im sure I will show how niave I am with this question, but from my
> understanding of how A5/1 works, even knowing 2 of the 3 inputs to
> the algorithim, (plaintext and frame number) I still dont see how
> this helps find the third piece (the 64 bit key) wouldn't you still
> have to run through all the 64 bit combinations? Is there a paper on
> this subject somewhere?
See the jya.com URL I posted earlier for a paper by Jovan Golic.
Also, check out the A5/1 paper in FSE 2000.
------------------------------
From: [EMAIL PROTECTED] (David A. Wagner)
Subject: Re: GSM A5/1 Encryption
Date: 7 Apr 2000 08:24:03 -0700
In article <8ck7mo$cdf$[EMAIL PROTECTED]>,
Paul Schlyter <[EMAIL PROTECTED]> wrote:
> David A. Wagner <[EMAIL PROTECTED]> wrote:
> > Paul Schlyter <[EMAIL PROTECTED]> wrote:
> >> [..] since pretty sophisitcated equipment
> >> will be required to even distinguish one particular GSM conversation
> >> from all the others occurring at the same frequency.
>
> > I think that's optimistic. After all, your already phone does it!
>
> To modify a GSM phone such that it does eavesdrop on other ongoing
> calls is a non-trivial task. It's certainly beyond the capability of
> most people who buy scanners at Radio Shack.
Yes. But my point is that *it may not require sophisticated equipment*.
Sure, such a route would almost certainly require non-trivial modification
of cellphone software, and there's no question that building the mod's
would be of reach of the average person on the street, but the important
thing is, barrier isn't necessarily *equipment* (i.e., hardware) -- the
barrier could well be "merely" knowledge and/or persistence.
I think the distinction between `big budget' attacks and `sweat of the
brow' attacks is an important one. You have to consider your adversaries.
> If/when digital scanners get readily available, I would guess that
> the GSM operators counter this by letting the frequencies hop more
> often.
I'm told the hopping sequence can be computed (by an eavesdropper) from
publicly known information. If that is correct, hopping more frequently
is unlikely to help too much.
> Yes, this can probably be done -- by a knowledgeable dedicated
> individual who have enough resources. But it's certainly beyond
> the capabilities of the average guy who buys a scanner at Radio Shack
> -- even when digital scanners become available.
Ahh, that's exactly the point I was trying to make, too.
I see that we are in violent agreement. :-)
> IMO the techniques of time multiplexing and frequency hopping is a
> more efficient protection against eavesdropping than the A5 encryption.
That's only because A5 is not very good. If they had used a decent
encryption algorithm (and there are plenty available), the story would
be different. The GSM industry had an opportunity to choose strong
crypto over weak crypto, and IMHO, they chose wrong.
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: design of MD family ciphers
Date: Fri, 7 Apr 2000 08:55:54 -0700
Amit Jain <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
>
> Few basic doubts about Message Digest family hash functions.
>
> Why is the Message Digest family designed the way it is ? Can attack on MD
> be reduced to any hard problem ? If not then, on what is its security
> based ?
No, it is not known to be reducible to any defined 'hard problem' (other
than the trivial transformations, such as 'can be create a preimage for this
MD hash function'). Like most things in cryptography, the security is based
on 'a lot of really bright people thought about it, and couldn't come up
with any way to break it'.
--
poncho
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: Q: Simulation of quantum computing
Date: 7 Apr 2000 16:09:50 GMT
In <[EMAIL PROTECTED]> Mok-Kong Shen <[EMAIL PROTECTED]> writes:
>what? Since QC, as far as I know, exploits the uncertainty inherent
>in quantum mechanics, it should be able to generate truly random
>bits, while a classical computer can only do deterministic things
>and hence can't perform that task by definition.
No. A quantum computer does NOT exploit the uncertainly inherent in QM.
It exploits the ability of QM to deal with coherent amplitudes. The
uncertainty of QM is a pain for quantum computers.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Is AES necessary?
Date: Fri, 07 Apr 2000 16:15:40 GMT
Mok-Kong Shen <[EMAIL PROTECTED]> wrote, in part:
>3DES is currently yet strong enough. If that's too weak, we could
>use 5DES etc.
But a cipher designed from the ground up to be stronger would also be
more efficient. The AES process has generated interest, and resulted
in advances in cryptographic knowledge.
However, since DES has been around so long, I do think many people
might choose to trust triple-DES instead of the AES.
>We could employ some trivial variants of DES that enable expansion
>of the effective key space (e.g. permutation of the subkeys or
>the S-boxes).
One has to do that with care to ensure one obtains the required
strength. As well, the 64-bit blocksize of DES limits its strength in
some ways.
John Savard (jsavard<at>ecn<dot>ab<dot>ca)
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Factoring Composite Numbers
Date: Fri, 07 Apr 2000 16:10:59 GMT
"Nickolaus Benjamin Padgett" <[EMAIL PROTECTED]> wrote, in
part:
>2) The most basic of all factorization methods is to divide 'n' up to the
>sqrt('n'). If I were to further decrease this space by 99% so that the
>total space to search was 1% of sqrt('n') would this be a viable decrease or
>would this expectancy still be to great?
That would still be too great, because the fast methods don't go up in
time as n gets bigger by the same rate as the sqrt(n) method. Thus,
for very big n, these methods are more than 100 times faster than the
original method.
John Savard (jsavard<at>ecn<dot>ab<dot>ca)
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: Eric Lee Green <[EMAIL PROTECTED]>
Subject: Re: Simple authentication protocol: any good?
Date: Fri, 07 Apr 2000 16:12:22 GMT
"David S. Harrison" wrote:
> I have need for a simple authentication protocol that can be used
> to insure that a client, speaking to a custom server, cannot be
> easily emulated. Due to the nature of the connection between client
> and server, I must assume that it is very easy to watch the traffic
> between the two.
The easiest way to do this is to use public key encryption and keep the
client's public key handy on the server and the server's public key
handy on the client. This eliminates man-in-the-middle attacks. Then for
authentication, either use a derived key function (i.e. Diffie-Hellman)
which uses the public key and if the other end doesn't have the correct
private key, the derived key doesn't match, or use RSA-type public key
encryption to transfer a private key, and if the other end doesn't have
the correct private key, the derived key doesn't match.
My approach would be to use Diffie-Hellman for this, use a MD5 or SHA1
checksum with the derived key as the last component added, and then you
can verify identity by seeing whether the message digests match. This
presumes that you have a secure way of generating private/public key
pairs and getting them to the client, so it depends upon your
environment. In my environment, I can simply create a tarball that has
the client, its pre-generated public/private key pair, and the server's
public key, then install this tarball on the destination using either
'ssh' or a floppy. At the time I create the tarball, I can add the
client's public key (and client ID) to the server's list of valid
clients. For other applications this won't work, and you may want to
look into PKI or SPEKE or some other such cryptographically secure
mechanism. See Bruce Schneier's book _Applied Cryptography_ for an
easy-for-engineers-to-understand look at the field as of five years (a
century) ago. Look at http://www.openssl.org for a secure socket layer
library that will be useful for actually implementing a
cryptographically secure protocol (though you'll have to strip out the
RSA encryption if you wish to sell it within the borders of the United
States -- at least, until November of this year).
--
Eric Lee Green [EMAIL PROTECTED]
Software Engineer Visit our Web page:
Enhanced Software Technologies, Inc. http://www.estinc.com/
(602) 470-1115 voice (602) 470-1116 fax
------------------------------
From: Eric Lee Green <[EMAIL PROTECTED]>
Subject: Re: Keys in blowfish
Date: Fri, 07 Apr 2000 16:23:35 GMT
Joey Moose wrote:
> I am looking at using blowfish to encrypt information within a Web page that
> is being transferred between servers. Do I need to worry about using
> different keys for each message I send? My guess is that a different key
> should be used each time to avoid someone comparing two messages...
To hide patterns, you can use a cipher block feedback mode and a random
initial salt. Using a different key each time is also a good idea if you
have a secure way of handshaking new keys.
--
Eric Lee Green [EMAIL PROTECTED]
Software Engineer Visit our Web page:
Enhanced Software Technologies, Inc. http://www.estinc.com/
(602) 470-1115 voice (602) 470-1116 fax
------------------------------
From: Eric Lee Green <[EMAIL PROTECTED]>
Subject: Re: Is AES necessary?
Date: Fri, 07 Apr 2000 16:26:07 GMT
Mok-Kong Shen wrote:
>
> Now that we'll soon have an AES, I think it could be interesting
> to take a minute to look back and reflect whether AES is really
> necessary.
>
> I'll start by arguing for one side of the issue:
>
> 3DES is currently yet strong enough. If that's too weak, we could
> use 5DES etc.
Strong but slow.
For some applications, slow isn't a problem. For others (e.g. encrypted
filesystems, encrypted gigabit network connections), slow *IS* a
problem.
--
Eric Lee Green [EMAIL PROTECTED]
Software Engineer Visit our Web page:
Enhanced Software Technologies, Inc. http://www.estinc.com/
(602) 470-1115 voice (602) 470-1116 fax
------------------------------
From: "Sid" <[EMAIL PROTECTED]>
Crossposted-To:
uk.media.newspapers,uk.legal,alt.security.pgp,alt.privacy,uk.politics.parliament,uk.politics.crime,uk.politics.censorship
Subject: Re: Sunday People 26/3/2000: "FORGET YOUR PASSWORD... END UP IN JAIL"
Date: Fri, 7 Apr 2000 17:42:34 +0100
I the US there is a box left blank for voters to write in their preferred
choice if none of the above.
The press are required by law to publish the full list of results which as
you can imagine runs to many thousand.
Mickey Mouse usually comes third in US elections.
------------------------------
From: jungle <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
Subject: Re: Magnetic Remenance on hard drives.
Date: Fri, 07 Apr 2000 13:13:35 -0400
any names & links of shops that will accept & recover data
multi pass wiped by pgp software ?
Harald Milz wrote:
> In comp.security.pgp.discuss Thor Arne Johansen <[EMAIL PROTECTED]> wrote:
>
> > No cash price, but a huge commercial potential.
> > The (data recovery) company I work for would certainly be interested in such
> > technology.
>
> AFAIK this type of service is offered by a number of data recovery shops.
> Dunno if they actually _deliver_, though.
any names & links of shops that will accept & recover data
multi pass wiped by pgp software ?
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: Massey-Omura protocol & ECC
Date: Fri, 07 Apr 2000 11:13:58 -0500
[EMAIL PROTECTED] wrote:
> When your lawyer can shed some light, I'd love to hear about it :)
Yeah, I think it might be worth a few hundred bucks to find out if
it's worth taking risks.
>
> I went to three books stores today, and not a sign of koblitz anywhere.
> Even the local online stores could not get it any faster than 4-6
> weeks. And Amazon.com would charge me an arm and a leg and maybe anoher
> body part or shipping. I did find prisoner of Azkaban in paperback. But
> my wife has already bought the hardback months ago.
>
> Anyway, i am beginning to think that even with a Digital signature what
> would stop malfour from generating the signature both ways as well thus
> completing the protocol with both parties using his own keys ?
>
> Is this a possibility ?
It could be if there's no check on the public keys. Even MQV is
susceptable
to the same problem if you don't check the permenent public keys. No
matter
what you do there has to be an out of band check of the public keys.
You
can *not* create a secure connection to an unknown key thru the net
without
an out of band check of some kind. I wish it was easy to show in a meta
mathematical way because we go over this point a million times. It's
simple
to see mechanically tho, if there's only one pipe and you can only throw
things
into and pull things out of the pipe, you have no clue if there's
somebody
in the middle of the pipe actively doing things to your packets.
If you do an out of band check on the public keys, then the digital
signature
will show you if malfor is doing anything. "Security is a pain in the
ass. (tm)"
Patience, persistence, truth,
Dr. mike
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: GSM A5/1 Encryption
Date: Fri, 07 Apr 2000 11:29:46 -0600
"David A. Wagner" wrote:
<snip>
> If they had used a decent
> encryption algorithm (and there are plenty available),
<snip>
Do you include systems based on block algorithms in "plenty"?
Or are there also plenty of native stream algorithms to choose from?
(My knowledge is restricted basically to AC2, AES, this
newsgroup, and a few pieces from the Web. So the stream
algorithms *I* know are pretty limited - RC4, SEAL, um...)
Actually, how many is "plenty"? Three? Twenty? I suppose
one is enough, if it meets the requirements...
John M.
------------------------------
From: Jerry Coffin <[EMAIL PROTECTED]>
Subject: Re: enigma returned
Date: Fri, 7 Apr 2000 11:37:38 -0600
In article <01bfa067$03a0aac0$3006ebd0@default>, [EMAIL PROTECTED]
says...
> Is the enigma particularly rare or valuable? I was under the impression
> that thousands of the machines were captured by the Allies in WWII and then
> sold to Third World countries (particularly ex-colonies) for sensitive
> encryption.
There were lots of Enigma machines captured, but this particular one
happens to be of quite a rare type of which only three are known. At
least as I understand it, this particular machine has no plugboard,
three rotors and quite an unusual keyboard. Having three rotors is
comparatively common, but the keyboard and lack of plugboard aren't.
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: An interesting cryptographic problem
Date: Fri, 07 Apr 2000 11:32:53 -0500
David Hopwood wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
>
> Consider the following problem:
>
> Let N = P.Q
> P = 2p + 1
> Q = 2q + 1
> P, Q, p and q are large primes
> x_0..x_{k-1} are randomly chosen on [0, q)
>
> S(b) = product[i = 0..k-1](x_i^b_i) mod q
> where b is a vector of k bits
>
> (i.e. S(b) is the product of all the x_i for which b_i is set)
>
> Sf_j = S(f_seed(j)), for j = 0..t-1
>
> f_seed is a deterministic, one-to-one, easily computed function
> mapping integers to vectors of k bits (each with at least 2 bits
> set), which depends on a random seed.
>
> k is about 20 (it could be larger than that if necessary); t is about
> 1000. P and Q are long enough that N cannot be factored. N, j, k, t,
> and f are known; P, Q, p, q, and the x_i are unknown.
>
> Suppose that all of the Sf_j are known except one, Sf_r (for some
> 0 <= r < j).
>
> The problem is: How hard is it to find either Sf_r, or any of the
> x_i (it would be enough to find an integer congruent to Sf_r or
> x_i modulo q). If this depends on f_seed, what constraints on
> f_seed are needed for it to be hard?
Don't know. But I'm confused. What are P, Q and N used for? If you
do everything mod q, both the inputs and outputs of S() are mod q.
If you know enough S's, can you use CRT to find q? Or just guess since
you know it has to be less than 2^(log_2(max Sf_j) + 1)? (Guessing
shouldn't work obviously :-)
Patience, persistence, truth,
Dr. mike
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: Schoof's Algorithm
Date: Fri, 07 Apr 2000 11:44:18 -0500
Robert Harley wrote:
> The algorithms involved are fairly complicated so it hardly makes
> sense to attempt a summary here! Two colleagues and I have only just
> started work on a tech-report describing the method we use, so it will
> be quite a while before that is ready. However my implementation is
> well advanced and is a lot faster than what has been done before.
> Point counting, in characteristic 2, is a solved problem: it's just
> that nobody knows it yet. =:-)
Very cool. Put me on the mailing list for a copy of that report!
I've almost figured out how to compute a j-invariant polynomial, so
it'll
be nice to find out I don't actually have to :-)
Patience, persistence, truth,
Dr. mike
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: [Q] Insecurity
Date: Fri, 07 Apr 2000 11:45:29 -0500
David C. Oshel wrote:
>
> If a bytestream never repeats itself in a universe bounded by proton decay,
> and produces 1 and 0 in every bit position in the ratio 1:1 on average, and
> passes Chi-square, why is it still not cryptographically secure?
Because it's a sequential count :-)
Patience, persistence, truth,
Dr. mike
------------------------------
From: Jerry Coffin <[EMAIL PROTECTED]>
Subject: Re: Public|Private key cryptography?
Date: Fri, 7 Apr 2000 11:56:23 -0600
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
[ ... ]
> Too search an 80 bit key, in one day you must test 2^63.60 keys a
> second. I doubt that could be done with todays hardware even for a
> million dollars. That's a clock rate of 13,980,017,795,349,537,628hz,
> even assuming each key could take only one clock cycle. To attack an 80
> bit key in say a month... you still need 2^58.64 keys/sec ... [this is
> at the most, not on avg]
You don't do this strictly by pushing a high clock rate -- you use a
fairly normal clock rate, and massive parallelism. Even with that,
you wouldn't be looking at breaking it in one day, but you could
break it in a LOT less than three years. If you want more details,
feel free to go to Deja -- a month or so ago I did some analysis of
how many modules you'd need, how much each would cost, etc.
> Question is the the 1ghz cpu actually have a throughput of 2x of the
> 500mhz... that's my point.
Yes, under most circumstances, it's twice as fast. For some jobs, it
actually does a bit better than that.
> The bus speed is still what 200mhz right?
No, the bus speed isn't the same. The 500 MHz models normally use
PC100 SDRAM. The 1 GHz models normally use Direct RDRAM, which is
substantially faster (IIRC, the bsic design point is for roughly 8
times the speed, though I doubt most current CPUs are going to
actually show that much difference in throughput, even with highly
memory intensive operations).
> > Depending on your definition of "soon", you're right -- in fact, 2^64
> > is almost certainly more than the current annual production of DRAM
> > of the entire world (by what looks like 2 to 3 orders of magnitude).
>
> Yeah, but my point was on *ONE* board. You can't use a distributed
> computer to solve a matrix, thus solve factoring [using NFS]. So that
> one machine needs the 2^64+ bytes of ram....
Though it doesn't gain you as much as elsewhere, yes, at least as I
understand things, there are distributed methods of solving the
matrix. In any case, being addressable by a single computer and
residing on a single board are two _entirely_ different sorts of
things. You're obviously accustomed to desktop/laptop/whatever style
machines, but that's hardly all there is in the world. Crays still
have large cabinets that take up quite a bit of space and have
multiple PC boards to hold their processors, memory, etc.
> But that's diff, you can do a distributed model to sieve for
> factoring/ecdl. You can't solve the matrix step of the factoring
> however since not enough ram exists on one sole machinve todo it.
And you can't solve the ECDL because not enough CPUs exist in the
world to do it.
> You are still missing my point. For a random 2000 bit RSA key, *you
> can't break it* it simply can't be done with NFS or QS. You would have
> to get lucky and guess the factors or something. i.e it's not even a
> question which is stronger.
No, you're missing my point. I thought I'd stated it pretty clearly,
but I'll try once more:
You can't solve either one at the present time. The resources to do
so simply don't exist. The only relevant question is how soon
computer production will get to the point that one or the other can
be solved. Based on the information that's available, 200-bit ECC
will NOT be solvable any sooner than 2000-bit RSA.
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: GSM A5/1 Encryption
Date: 7 Apr 2000 17:58:32 GMT
Gerhard Wesp <[EMAIL PROTECTED]> wrote:
> In article <[EMAIL PROTECTED]>,
> Paul Koning <[EMAIL PROTECTED]> wrote:
>>73 GB worth of disk drive costs only a few thousand dollars, if
> actually, you can have it for <= USD 1000.
> however, an attack that succeeds within a minute can't use that much
> disk space. or it would have to be a _very_ fast disk.
It can use that much disk space for holding the results of preprocessing,
as long as the "online cost" is small. In this case, it seems that
the disk space is used to hold a large table of precomputed special
states, but the claim is that only 100 or so proves into the table
are necessary for each stream we want to break. So the "online cost"
is very small...
Thanks,
-David
------------------------------
** 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
******************************
