Cryptography-Digest Digest #792, Volume #10 Sat, 25 Dec 99 15:13:00 EST
Contents:
Bits 1 to 3 (Re: question about primes) (Matthew Montchalin)
Re: Bits 1 to 3 (Re: question about primes) (Matthew Montchalin)
Re: Are PGP primes truly verifiable? (David A Molnar)
Re: Are PGP primes truly verifiable? (Paul Schlyter)
Re: More idiot "security problems" (Terry Ritter)
Re: Are PGP primes truly verifiable? (Greg)
Re: ECC (Greg)
Re: Are PGP primes truly verifiable? (Bob Silverman)
Re: Are PGP primes truly verifiable? (Bob Silverman)
Re: Are PGP primes truly verifiable? (Bob Silverman)
Re: Are PGP primes truly verifiable? (Bob Silverman)
Re: Are PGP primes truly verifiable? (Bob Silverman)
----------------------------------------------------------------------------
From: Matthew Montchalin <[EMAIL PROTECTED]>
Crossposted-To: sci.math
Subject: Bits 1 to 3 (Re: question about primes)
Date: Sat, 25 Dec 1999 00:48:59 -0800
On Sat, 25 Dec 1999, Mark Adkins wrote:
|The ratio may approach unity, but if the data you posted is
|correct the gap continues to widen as N grows without bound
|(i.e., in terms of the absolute number of primes which end in
|nines and ones vs. the absolute number of primes which end in
|threes and sevens, the former group falls behind the latter,
|and by larger and larger amounts). This is what I expected
|but empirical verification is quite useful.
Your intuition impresses me. Perhaps this would make more
sense to me if we could somehow represent these putative
primes in binary notation instead of decimal notion?
For instance, why would primes ending in %1001 and %0001
tend to occur more often than primes ending in %0111 and %0011?
My own gut instinct is to give more weight to primes with
1's clustered on the right than to primes having the 1 on
the right separated by one or more 0 bits. This would be
consistent with your own intuition. But how does one go
about proving it?
Now assuming that Bit 0 is set, as is true of all primes
greater than the numeral 2, and further assuming we are
only interested in Bits 1 to 3, do these bits seem random
as we encounter more and more primes? For instance, we
could generate a whole bunch of primes and then perform
a logical AND of #%1110 to knock off bit 1, then test
the resulting numeral for randomness.
------------------------------
From: Matthew Montchalin <[EMAIL PROTECTED]>
Crossposted-To: sci.math
Subject: Re: Bits 1 to 3 (Re: question about primes)
Date: Sat, 25 Dec 1999 00:57:14 -0800
On Sat, 25 Dec 1999, Matthew Montchalin wrote:
|Now assuming that Bit 0 is set, as is true of all primes
|greater than the numeral 2, and further assuming we are
|only interested in Bits 1 to 3, do these bits seem random
|as we encounter more and more primes? For instance, we
|could generate a whole bunch of primes and then perform
|a logical AND of #%1110 to knock off bit 1, then test
|the resulting numeral for randomness.
I mean, after shifting right by 1 bit.
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto;
Subject: Re: Are PGP primes truly verifiable?
Date: 25 Dec 1999 09:22:43 GMT
Greg <[EMAIL PROTECTED]> wrote:
I seem to have serious lag. So am trying to get many short posts
to avoid losing any of them.
>> be possible to find 2048-bit RSA keys if we need them.
> From what you and others have said thus far, the answer is,
> "No we cannot guarantee it 100%." So then I have to ask,
> "What is the tangible risks if it is not truly a prime?"
Actually, if you use Maurer/Mihailescu's method, yes we can
guarantee it 100%. Even better, we can give a proof that the
generated number really is prime. The cost is that you have
to generate the number in that way; Maurer's paper spends pages
arguing that these numbers are distributed in the same way that
you'd expect randomly chosen primes to be distributed.
I do not understand his arguments yet. Someday I want to. :-(
The risk of error for probabilistic primality tests can be quantified.
For the Miller-Rabin test, for instance, we know that our probability
of error after k tests is (1/4)^k (about - it's not quite this because
you need to worry about how primes are distributed; I can't remember the
exact reason/formula, but it isoff by a small amount.).
I know that there exist algorithms which will tell you with 100% certainty
whether a number is prime, and run in poly time, but don't know enogh
to go into detail on this point. :-(
That shows that it is possible to either guarantee a number is prime OR
convince yourself that the probability of it being non-prime is
negligible. So key generation is OK, if possibly slow.
For verifying that a given (e, n) is a valid public key, we need to know
1) that n is the product of 2 primes (or whatever weird modulus you're
using this week)
2) that e can have an inverse mod phi(n) <---> e rel prime to phi(n)
then the papers I mentioned in last post applly. these are proof systems
with some error probability, but you can make that as small as you want.
> Second, if you need more proof, mathematical proof, then this
> whole debate can come down to mathematically proving the
> intractibility of IFC and ECC, which cannot be done for either.
> Therefore, I would never assume that someone would think that
> I was trying to lead the conversation to that point.
You're right. Sorry if I impplied that. I only meant a proof that
there aren't any weak keys -- or a proof that all points are
equally good choices for keys if the curve is secure. You've sketched
an argument, and now I need to go see if I can make sense of it.
Thanks,
-David
------------------------------
From: [EMAIL PROTECTED] (Paul Schlyter)
Crossposted-To: talk.politics.crypto
Subject: Re: Are PGP primes truly verifiable?
Date: 25 Dec 1999 09:19:07 +0100
In article <[EMAIL PROTECTED]>,
lordcow77 <[EMAIL PROTECTED]> wrote:
> In article <83vu2d$el9$[EMAIL PROTECTED]>, "Gary"
> <[EMAIL PROTECTED]> wrote:
>> Even if the primes pass the tests and yet are 'liars', are they
>> still
>> relatively strong with regard to usage in PGP?
>
> Wouldn't the decryption process not work if one of the "primes" was
> actually composite?
The decryption would work. But since the modulus would contain
smaller factors, it would be easier to factorise. And if you manage
to factorise the modulus, you've broken that particular RSA key.
> phi(n) would no longer equal (p-1)*(q-1) since p and q aren't both prime.
:-) ... it is possible to compute (p-1)(q-1) even if p and/or q
aren't prime....
--
================================================================
Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40, S-114 38 Stockholm, SWEDEN
e-mail: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
WWW: http://hotel04.ausys.se/pausch http://welcome.to/pausch
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: More idiot "security problems"
Date: Sat, 25 Dec 1999 12:15:24 GMT
On Fri, 24 Dec 1999 04:48:33 GMT, in <[EMAIL PROTECTED]>,
in sci.crypt [EMAIL PROTECTED] (Bruce Schneier) wrote:
>On 17 Dec 1999 09:55:08 GMT, [EMAIL PROTECTED] (Xcott Craver)
>wrote:
>>[...]
>> Bruce Schneier and Counterpane have been known to assert, in
>> talks and white papers, that good crypto/security cannot be
>> distinguished from bad crypto/security. I've always considered
>> this "Schneier's first law."
>
>A corollary is that: "Anyone can create an encryption algorithm that
>he himself cannot break."
Just to keep things honest, I would say the real situation is even
more general:
*Any* *group* can create an encryption algorithm that no-one in the
group can break.
Here "group" includes individuals, academics, AES participants, etc.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: Greg <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: Are PGP primes truly verifiable?
Date: Sat, 25 Dec 1999 18:03:11 GMT
> > Wouldn't the decryption process not work if one of the "primes" was
> > actually composite?
> The decryption would work. But since the modulus would contain
> smaller factors, it would be easier to factorise. And if you manage
> to factorise the modulus, you've broken that particular RSA key.
I guess what I am looking for is, "Since it is not a prime, but
a composite, it is much faster to crack and thus fails to work
as advertised." The point of my post was that IFC keys are not
100% guaranteed to work as advertised, but ECC keys are.
Would you say that this is true?
--
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: Greg <[EMAIL PROTECTED]>
Subject: Re: ECC
Date: Sat, 25 Dec 1999 18:05:56 GMT
> Hi all !Where can I get information relating to ECEC ( Elliptical
> Curve Encryption System) and ECKEP ( Elliptical Curve Key Exchange
> Protocol), preferabbly a website.
commerical web site- www.certicom.com, www.rsa.com
my web site- www.ciphermax.com
"Implementing Elliptic Curve Cryptography", by Dr. Michael Rosing.
--
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: Bob Silverman <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto;
Subject: Re: Are PGP primes truly verifiable?
Date: Sat, 25 Dec 1999 18:21:24 GMT
In article <83uq56$gs6$[EMAIL PROTECTED]>,
Greg <[EMAIL PROTECTED]> wrote:
> Since PGP primes are getting to be very large now (to keep
> up with demand for strength against newer computers), it
> seems to me that they are becoming more impossible to
> verify as true primes.
>
Fortunately for the rest of us, mathematics is not done "by opinion".
How much do you know about algorithms that are ued to test
primes? Can you name 4 different ones? I expect that the answer is
no.
Therefore, I am interested in what information you used to arrive at
your "conclusion". Please explain your reasoning.
> Is this a reasonable assumption?
No it is not. It is completely wrong.
>
> With ECC, a private key is simply an integer (any value will do)
> and the public key is always a valid result of a point multiply.
> To be specific, ECC keys are all valid. Yet, PGP and other IFC
> keys are getting to the point where verifying their validity
> of strength is impossible.
A rather bold assertion. Please back it up with some facts, please.
>
> Any comments?
I suspect that you have not studied this subject at all. I suggest you do
so before making further pronouncements.
--
Bob Silverman
"You can lead a horse's ass to knowledge, but you can't make him think"
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Bob Silverman <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto;
Subject: Re: Are PGP primes truly verifiable?
Date: Sat, 25 Dec 1999 18:37:29 GMT
In article <83v6g7$84v$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Paul Schlyter) wrote:
> In article <83uq56$gs6$[EMAIL PROTECTED]>, Greg <[EMAIL PROTECTED]> wrote:
>
> > Since PGP primes are getting to be very large now (to keep
> > up with demand for strength against newer computers), it
> > seems to me that they are becoming more impossible to
> > verify as true primes.
<snip>
> Promes used for key generation are validated statistically: aplpy
> a test with that prime and a random number: if the test fails, it's
> no prime but if it succeeds, there's a 50% chance it's a prime.
Please explain where you get your facts. They are simply wrong.
(1) Primes *can* be validated statstically. They can also be validated
deterministically. Algorithms (and software) exists that will rigorously
prove primality. So it depends on who is doing the testing whether
one generates provable primes or probable primes.
(2) The probability is certainly not 50%. It is much lower than that.
The exact probability for a single test in fact depends on the size
of the number being tested. The larger the number, the less likely it
is that the test will produce a false positive. See the paper by
Damgaard, Landrock, & Pomerance in Math. Comp.
> Repeat the test n times, and there's 2^n-1 chances out of 2^n that
> it's a prime.
More misinformation. The tests are not independent. Again,
see the Damgaard et. al. paper
>
> Which means if you apply this test 32 times to each prime, and you
> generate 4 billion primes, one of them won't actually be a prime,
> and you don't know which one.
It certainly does NOT mean this either!
Suppose that each test is indeed correct 1/2 the time. Suppose
you apply the test 32 times to each of 4 billion 100 digit numbers.
Suppose the tests say that they are all prime. You assert that
one of them will not be prime, as if this is a certainty. In fact,
the probability is not 1 that one will not be a prime, but rather
1-1/e. i.e. there is about a 2/3 chance that one won't be prime.
> If you think this is too insecure, apply the test 64, or 128, times
> instead.
No! No! No.!
Instead you should go read a book on the subject and choose
a reasonable algorithm;
For a 512-bit prime, 8 iterations of Miller-Rabin will suffice to reduce
the probability of a false positive to less than 2^-100. If one then
follows with a SINGLE Lucas-Lehmer test, the chance of error
becomes MUCH lower (although it has not been quantified exactly)
Or one could use several round of the Frobenius-Grantham test.
There are no known composites which get by a single M-R test
followed by a single L-L test.
>
> --
> ----------------------------------------------------------------
> Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
> Grev Turegatan 40, S-114 38 Stockholm, SWEDEN
> e-mail: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
> WWW: http://hotel04.ausys.se/pausch http://welcome.to/pausch
>
--
Bob Silverman
"You can lead a horse's ass to knowledge, but you can't make him think"
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Bob Silverman <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: Are PGP primes truly verifiable?
Date: Sat, 25 Dec 1999 18:55:01 GMT
In article <8430ml$46t$[EMAIL PROTECTED]>,
Greg <[EMAIL PROTECTED]> wrote:
>
> > > Wouldn't the decryption process not work if one of the "primes" was
> > > actually composite?
>
> > The decryption would work.
More nonsense. The decryption would work ONLY if N were a
Carmichael number. But if N = pq is a mere M-R pseudoprime,
then when you compute the private exponent as d = e^-1 mod phi(N),
this value of d will be incorrect since your presumed value for
phi(N), namely (p-1)(q-1) will not be correct.
> But since the modulus would contain
> > smaller factors, it would be easier to factorise.
No. Suppose you generate p anq as random 512 bit primes
and (horror!) it turns out that p is the product of a 200 and a 312
bit prime. The product pq is not any easier to factor in this case than
if p and q were both prime. It is still well out of reach of the
Elliptic Curve factoring algorithm, and the Number Field Sieve
doesn't care how many factors N has.
? And if you manage
> > to factorise the modulus, you've broken that particular RSA key.
>
Except that PGP does not use RSA. It uses D-H.
> I guess what I am looking for is, "Since it is not a prime, but
> a composite, it is much faster to crack
This is false.
> and thus fails to work
> as advertised." The point of my post was that IFC keys are not
> 100% guaranteed to work as advertised, but ECC keys are.
>
> Would you say that this is true?
No, this is also false. If one chooses a curve seemingly over a field
Z/pZ*, and p turns out not to be prime, then solving the discrete log
problem for EC becomes (theoretically) easier to solve as well. (Why?
Because there will be more small subgroups than if p is prime) [assuming, of
course that you can somehow generate correct EC parameters when the curve is
defined over a finite ring, rather than a field]
For EC, the private key is just a random int. But (part of) the
public key needs most definitely to be prime.
--
Bob Silverman
"You can lead a horse's ass to knowledge, but you can't make him think"
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Bob Silverman <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto;
Subject: Re: Are PGP primes truly verifiable?
Date: Sat, 25 Dec 1999 19:17:52 GMT
In article <841o01$bli$[EMAIL PROTECTED]>,
Greg <[EMAIL PROTECTED]> wrote:
>
> > It's not clear to me whether you're worried about
> > verifying primes for use in key generation, or whether
> > you're worried about certifying the "strength" of a given
> > public key. Each situation has a different notion of "verify."
>
> In my opinion, and please interject if you feel I am in error,
> IFC requires true primes to gain the benefits of full strength
> of the key size. If a supposed prime is found not to be a true
> prime, then the key can be cracked significantly faster than
> otherwise expected by the person using it.
>
> Since the whole issue of PGP, for example, is safety in
> privacy, in my mind, I keep asking myself (and now all of
> you), "Why would anyone trust an encryption system they
> cannot verify is working as advertised?"
>
> > I can tell, longer primes means that the primality tests
> > will run longer, but not too much longer. It will still
> > be possible to find 2048-bit RSA keys if we need them.
>
> From what you and others have said thus far, the answer is,
> "No we cannot guarantee it 100%." So then I have to ask,
> "What is the tangible risks if it is not truly a prime?"
>
> > Just a few things (if you don't mind me poking a bit) :
>
> But I appreciate that you do...
>
> > Do we need to make a distinction between "valid -- crypto works"
> > and "valid -- not a weak key"?
>
> My understanding is that if the key is weak then the crypto does
> not work as well- it does not work as advertised, so I believe
> the answer is yes.
>
> > Do you consider the choice of curve part of the choice of key ?
>
> No. The curve is chosen before software deployment, usually.
> PGP keys, on the other hand, are chosen, like ECC keys, on the
> fly. The only difference is, PGP keys are not 100% guaranteed
> even with extensive effort, while ECC keys are 100% guaranteed
> with zero effort.
>
> > Is there a difference between my publishing an RSA public key
> > which has a special, easy-to-factor form , and my registering an
> > ECC curve which is supersingular or otherwise flawed?
>
> Two answers:
>
> Yes. Unlike the RSA public key, the curve can have years of
> testing before it is published. RSA public keys developed on
> the fly are only as good as the short tests they receive.
>
> And no. There is the possibility that both are weak and only
> found in time after use. The damage can be incredibly extensive.
>
> > Does it not matter because I should be using a NIST curve anyway?
>
> I would have to say that it should matter less as (1) the curve
> has been challenged for a lengthy period of time without success
> (e.g.- Certicom challenges) and (2) ECC itself becomes better
> understood as a science.
>
> > Where can I find the proof that all ECC keys are equally strong?
> > (for which system?)
> > What do you need to do to convince me that your ECC key
> > posesses enough "validity of strength"?
>
> I have two answers here. First, the validity of strength of
> any ECC key is based upon demonstrating the cyclic nature of the
> curve in the field space itself. In my mind, that demonstrates
> the raw key space to be searched and how every integer must be
> tested to find the one corresponding to the point in question.
> This is the science as we know it today. To say, "We just found
> that the curve Greg published has a flaw and we can use a much
> shorter search of the key space!" can have a similar claim in
> another time and place for IFC in general. That is playing,
> "what if".
>
> Second, if you need more proof, mathematical proof, then this
> whole debate can come down to mathematically proving the
> intractibility of IFC and ECC, which cannot be done for either.
> Therefore, I would never assume that someone would think that
> I was trying to lead the conversation to that point. My
> question was simply about how easy it is to guarantee the
> validity of a key to be as strong as the crypto system advertised
> between IFC and ECC and is it a significant issue (significant
> risk)? I think the key word here is "advertised". In that
> context, consider what is advertised for IFC and then for ECC
> and tell me if you think that IFC keys at the 2k range are
> really delivering as advertised every time for PGP or an RSA
> product.
>
> > Anyway, hope this sheds some light on how "impossible"
> > or not verifying RSA keys is. It is a problem, but looks
> > solvable. The question is whether you're willing to pay
> > for the solution. :-)
>
> I disagree. In my mind, what I see is a vast difference in
> effort of finding a valid key- nearly impossible v. immediate
> guarantee- ON THE FLY. I am not convinced this is not an
> issue for IFC. In my mind, IFC has no real future with
> the key sizes becoming what they are, but I am open to
> debate on this.
>
> --
> 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.
>
--
Bob Silverman
"You can lead a horse's ass to knowledge, but you can't make him think"
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Bob Silverman <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto;
Subject: Re: Are PGP primes truly verifiable?
Date: Sat, 25 Dec 1999 19:14:40 GMT
In article <841o01$bli$[EMAIL PROTECTED]>,
Greg <[EMAIL PROTECTED]> wrote:
>
> > It's not clear to me whether you're worried about
> > verifying primes for use in key generation, or whether
> > you're worried about certifying the "strength" of a given
> > public key. Each situation has a different notion of "verify."
>
> In my opinion, and please interject if you feel I am in error,
> IFC requires true primes to gain the benefits of full strength
> of the key size. If a supposed prime is found not to be a true
> prime, then the key can be cracked significantly faster than
> otherwise expected by the person using it.
Have you studied this subject? Do you have any idea of how
to conduct an attack (if N=pq does not have both p,q prime]?
No? Then how can you have an "opinion" one way or the other?
Suppose indeed that N = pq and that p is not prime, but q is.
Suppose q is the product of a (say) 100 bit prime and a 412 bit prime.
Then yes, one can indeed pull out the 100 bit prime via ECM.
What is left, however, is a 924 bit number which is the product of
a 512 bit and 412 bit number. Factoring a 924 bit number is easier
than a 1024 bit number, using NFS, but only a little easier. It is
still well out of reach.
Only if you somehow generate N = pq, where q has at least 3 or 4
factors, and the largest is not too large,then does factoring N become
feasible. i.e. if q = q1 q2 q3 q4 where q4 is reasonable large
(say) 200 bits, and you then find q1, q2, q3, by ECM, the cofactor
q4 p is still too lrge to do with NFS. Only if you can find ALL the factors
of q will you succeed in factoring N.
Generating such q by accident is improbable in the extreme.
>
> Since the whole issue of PGP, for example, is safety in
> privacy, in my mind, I keep asking myself (and now all of
> you), "Why would anyone trust an encryption system they
> cannot verify is working as advertised?"
>
> > I can tell, longer primes means that the primality tests
> > will run longer, but not too much longer. It will still
> > be possible to find 2048-bit RSA keys if we need them.
>
> From what you and others have said thus far, the answer is,
> "No we cannot guarantee it 100%." So then I have to ask,
> "What is the tangible risks if it is not truly a prime?"
>
> > Just a few things (if you don't mind me poking a bit) :
>
> But I appreciate that you do...
>
> > Do we need to make a distinction between "valid -- crypto works"
> > and "valid -- not a weak key"?
>
> My understanding is that if the key is weak then the crypto does
> not work as well- it does not work as advertised, so I believe
> the answer is yes.
>
> > Do you consider the choice of curve part of the choice of key ?
>
> No. The curve is chosen before software deployment, usually.
> PGP keys, on the other hand, are chosen, like ECC keys, on the
> fly. The only difference is, PGP keys are not 100% guaranteed
> even with extensive effort, while ECC keys are 100% guaranteed
> with zero effort.
>
> > Is there a difference between my publishing an RSA public key
> > which has a special, easy-to-factor form , and my registering an
> > ECC curve which is supersingular or otherwise flawed?
>
> Two answers:
>
> Yes. Unlike the RSA public key, the curve can have years of
> testing before it is published. RSA public keys developed on
> the fly are only as good as the short tests they receive.
>
> And no. There is the possibility that both are weak and only
> found in time after use. The damage can be incredibly extensive.
>
> > Does it not matter because I should be using a NIST curve anyway?
>
> I would have to say that it should matter less as (1) the curve
> has been challenged for a lengthy period of time without success
> (e.g.- Certicom challenges) and (2) ECC itself becomes better
> understood as a science.
>
> > Where can I find the proof that all ECC keys are equally strong?
> > (for which system?)
> > What do you need to do to convince me that your ECC key
> > posesses enough "validity of strength"?
>
> I have two answers here. First, the validity of strength of
> any ECC key is based upon demonstrating the cyclic nature of the
> curve in the field space itself. In my mind, that demonstrates
> the raw key space to be searched and how every integer must be
> tested to find the one corresponding to the point in question.
> This is the science as we know it today. To say, "We just found
> that the curve Greg published has a flaw and we can use a much
> shorter search of the key space!" can have a similar claim in
> another time and place for IFC in general. That is playing,
> "what if".
>
> Second, if you need more proof, mathematical proof, then this
> whole debate can come down to mathematically proving the
> intractibility of IFC and ECC, which cannot be done for either.
> Therefore, I would never assume that someone would think that
> I was trying to lead the conversation to that point. My
> question was simply about how easy it is to guarantee the
> validity of a key to be as strong as the crypto system advertised
> between IFC and ECC and is it a significant issue (significant
> risk)? I think the key word here is "advertised". In that
> context, consider what is advertised for IFC and then for ECC
> and tell me if you think that IFC keys at the 2k range are
> really delivering as advertised every time for PGP or an RSA
> product.
>
> > Anyway, hope this sheds some light on how "impossible"
> > or not verifying RSA keys is. It is a problem, but looks
> > solvable. The question is whether you're willing to pay
> > for the solution. :-)
>
> I disagree. In my mind, what I see is a vast difference in
> effort of finding a valid key- nearly impossible v. immediate
> guarantee- ON THE FLY. I am not convinced this is not an
> issue for IFC. In my mind, IFC has no real future with
> the key sizes becoming what they are, but I am open to
> debate on this.
>
> --
> 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.
>
--
Bob Silverman
"You can lead a horse's ass to knowledge, but you can't make him think"
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
** 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
******************************
