Cryptography-Digest Digest #375, Volume #12 Mon, 7 Aug 00 17:13:01 EDT
Contents:
Re: Note on text compression ("Tony T. Warnock")
Re: Coupon collector's problem ("Douglas A. Gwyn")
2 keys encryption algorithm? ([EMAIL PROTECTED])
Re: Proposal: Timestamping Roundtable w/ PGP Sigs. (John Myre)
Re: Coupon collector's problem ("Douglas A. Gwyn")
Re: Combining bit sequences (Mok-Kong Shen)
Re: New William Friedman Crypto Patent (filed in 1933) (John Savard)
Re: OTP using BBS generator? ("Joseph Ashwood")
Re: Coupon collector's problem - Proof (Steve Weis)
Re: Secrets and Lies: New Book by Schneier (jungle)
Re: 2 keys encryption algorithm? (jungle)
Re: OTP using BBS generator? ("Joseph Ashwood")
Re: Discret Logarithm (Mok-Kong Shen)
Re: 2 keys encryption algorithm? ("Ed Suominen")
Re: Applications for One-Way Function? ("Joseph Ashwood")
Re: Digital Certificates and Key Lengths ("Joseph Ashwood")
Re: OTP using BBS generator? (Bryan Olson)
Re: Proposal: Timestamping Roundtable w/ PGP Sigs. ("Ed Suominen")
Re: Special RSA moduli (Roger Schlafly)
----------------------------------------------------------------------------
From: "Tony T. Warnock" <[EMAIL PROTECTED]>
Subject: Re: Note on text compression
Date: Mon, 07 Aug 2000 12:39:23 -0600
Reply-To: [EMAIL PROTECTED]
I didn't follow with Huffman as I wanted to preserve the searchablility
of the compressed text.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Coupon collector's problem
Date: Mon, 7 Aug 2000 18:04:35 GMT
"Artemios G. Voyiatzis" wrote:
> Thanks for the reply, but I am interested in proving this formula,
> not using it (well, I do use it, but I need a proof). I already
> read Knuth, but it didn't provide the proof - maybe it's too obvious :-)
It's basic combinatorics, which is discussed earlier in
Knuth (1.2.6).
Letting d be the number of possible "random" values and
r be the length of a "coupon collector" segment (which we
hope completes a set of at least one each of all d values),
the number of ways of partitioning the r samples into d
nonempty sets is just the Stirling number of the second
kind, in Knuth's notation r over d inside {braces}; let's
use S(r,d) here. There are d! possible permutations of
the collection of d distinct subsets, so the number of
posible r-long samples that are complete sets of d values
is S(r,d)d!. The number of equiprobable results of r
unconstrained samples is d^r. So by the basic rule for
equiprobable samples "probability criterion is met =
number of possibilities meeting criterion / total number
of possibilities", the probability that a sequence of
length r contains a complete set of d values is S(r,d)d!/d^r.
The rest of the derivation is just as indicated by Knuth.
------------------------------
From: [EMAIL PROTECTED]
Subject: 2 keys encryption algorithm?
Date: Mon, 07 Aug 2000 18:41:24 GMT
Reply-To: [EMAIL PROTECTED]
Hi all,
Is there a solid 2 keys encryption system out there. What I mean by 2
keys is the systems requires two keys to encrypt the data and then
needs only one of the two to decrypt it. An application for such system
is a conversation recording system where the two parties encrypt the
system and either of which can hear it later.
I am not sure whether the concept of public and private keys apply here.
Thank you very much for you time and effort.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp
Subject: Re: Proposal: Timestamping Roundtable w/ PGP Sigs.
Date: Mon, 07 Aug 2000 12:56:59 -0600
JL wrote:
> =
> "John Myre" <[EMAIL PROTECTED]> a =E9crit dans le message news:
> [EMAIL PROTECTED]
> > > All participants will agree to testify as to the
> > > authenticity of their digital signature if necessary.
> >
> > "Testify" as in "in a court of law"? Where?
> >
> > Before I made legal promises I'd want a more explicit
> > (and limited!) description of what I was promising...
> =
> "at the expense of the person requesting such testimony". Wouldn't you =
like
> some nice holidays at the other end of the wolrd ?
> =
> JL.
Yes, I saw that. What makes you think the request will come
at a convenient time, or from a part of the world you have
any interest in visiting? Some people have lives.
Sorry, sorry, I didn't mean to imply that you don't. But just
imagine that you get a summons to go to a dangerous dictactorship
right about when you are supposed to be on your honeymoon. Have
you really agreed to go testify, instead?
And even presupposing that the language in that posting obligates
"the person requesting such testimony" to pay for all travel and
lodging, do you think a person with a lawsuit is interested in
putting you up in a five-star hotel? That he could afford such a
thing? Why didn't he use a for-pay service in the first place?
Really, I'm not trying to predict what could happen. I'm just
noting that legal affairs are the modern equivalent of the
medieval enchanted forest: enter at your own peril, unless you
are the professional.
JM
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Coupon collector's problem
Date: Mon, 7 Aug 2000 18:15:31 GMT
Mok-Kong Shen wrote:
> Knuth gives some references. I haven't studied these. Proofs of
> such statistical tests are usually non-trivial.
It's just a chi-square test of the uniformity hypothesis
applied to a particular set of observations. All that is
needed is a formula for the probability of an observation
under the hypothesis, which is what Knuth gives (along with
guidance as to how to derive it). The framework of
chi-square testing in general probably doesn't need to be
shown, since it's a standard statistical method.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Combining bit sequences
Date: Mon, 07 Aug 2000 21:21:35 +0200
Future Beacon wrote:
>
> Instead of using binary operations like * and +, you might
> generalize them with 64K look-up tables. There are many more
> possible look-up tables than elementary functions. Also, they
> can be changed from time to time. The disadvantage is the overhead,
> but I think that it is often worth the memory, time, and program
> complexity.
>
> If a look-up table defines * instead of it meaning multiplication,
> the X * Y is the entry at the address that has the bits of X
> followed by the bits of Y. If both X and Y are 8 bits, then you
> get a 16 bit address and therefore need a 64K look-up table.
>
> If you want to make some look-up tables small, you could use
> Q + Y mod 2^8 as an address and therefore have only 256 table
> entries. Such a small amount of data could be changed rather
> frequently.
>
> That's the way I would use your X * Y + Z.
(message delayed)
Thanks for the suggestion.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: New William Friedman Crypto Patent (filed in 1933)
Date: Mon, 07 Aug 2000 19:21:13 GMT
On Mon, 07 Aug 2000 11:53:04 +0200, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote, in part:
>I was told that in Europe an inventor must be very careful not
>to reveal his stuff in a public lecture or else he risks to have
>his idea to be regarded as available in the public domain and
>therefore not patentable by himself.
Yes, this is correct: in the U.S., an inventor is allowed one year to
apply for a patent after publishing his invention, but this is not
true in Europe.
John Savard (teneerf <-)
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: OTP using BBS generator?
Date: Mon, 7 Aug 2000 12:16:05 -0500
> It really doesn't provide any significant advantage - if
checking for short
> cycles were actually needed for BBS, that would cast doubt
on the security
> of every IFP-based cryptosystem, including RSA, Rabin,
etc.
You act as if there is no question of the security of those
systems. At work I have several papers called such things as
"Breaking RSA may not be equivalent to factoring." We have a
substantial body of evidence that the security of those very
systems is not as good as we would like. It has been proven
that using RSA with a small value for the public or private
key is flawed security, it has been proven that you can fake
signatures of either DSA or RSA given certain requirements.
We have established that there is reason to believe that
"the security of every IFP-based cryptosystem" may require
some skepticism, some examination of the actual threat
model, and a significant amount of examination of
literature, constantly maintained. From this I conclude that
we have reason to turn that statement around to "If there is
doubt of the security of IFP-based cryptosystems, there
should be corresponding doubt of the BBS pRNG" since we have
a small amount of doubt regarding IFP-based systems, we
should have a small amount of doubt about BBS.
Joe
------------------------------
From: Steve Weis <[EMAIL PROTECTED]>
Subject: Re: Coupon collector's problem - Proof
Date: Mon, 07 Aug 2000 12:23:34 -0700
"Artemios G. Voyiatzis" wrote:
> The problem states that if someone collects a coupon every day, out of N
> possible, then one needs N*H_n days to have at least 50% probability of
> collecting all N coupons. H_n is approximately lnN. In general, if one
> collects K coupons every day, the probability becomes lnK/( lnN-ln(N-K))
I'll use the "Bins & Balls" model for this:
Say that there are n bins (coupons) and n balls (days).
Each ball is tossed and lands into a specifc bin with probability 1/n.
Balls can stack in bins (people can get a coupon they already have).
The probability a specific bin is empty is the probability that every
ball tossed misses it and falls into another bin:
P(Bin i is empty) = (1-1/n)^n
For a large n, this is approximately (1/e) (e == euler's number).
If X is the number of empty bins:
E(X) = (# bins) * (P(Bin i is empty) = (n/e) = Expected number of empty
bins
Now, suppose m balls are thrown. m=k*n. Now the probability a bin is
empty is:
P = (1-1/n)^m = ((1-1/n)^n)^k = (1/e)^k
So, E(X) = (n/e^k).
If (k = lg n) then E(X) = 1 ..i.e. you only expect to see 1 empty bin.
You can arbitrarly multiply m by a constant to make this arbitrarily
small.
------------------------------
From: jungle <[EMAIL PROTECTED]>
Subject: Re: Secrets and Lies: New Book by Schneier
Date: Mon, 07 Aug 2000 15:25:35 -0400
you need to talk to amazon, they are not providing 30% but only 20% ...
Bruce Schneier wrote:
>
> Secrets and Lies: Digital Security in a Networked World
> I've written a new book.
====
> Order the book (at a 30% discount) from Amazon:
you need to talk to amazon, they are not providing 30% but only 20% ...
> <http://www.amazon.com/exec/obidos/ASIN/0471253111/counterpane/104-8286037-2313547>
------------------------------
From: jungle <[EMAIL PROTECTED]>
Subject: Re: 2 keys encryption algorithm?
Date: Mon, 07 Aug 2000 15:34:17 -0400
it is called secret sharing algorithm ...
you will create scheme that, let say, minimum 2 keys from 4 keys created are
needed to perform encryption ...
[EMAIL PROTECTED] wrote:
> Is there a solid 2 keys encryption system out there. What I mean by 2
> keys is the systems requires two keys to encrypt the data and then
> needs only one of the two to decrypt it.
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: OTP using BBS generator?
Date: Mon, 7 Aug 2000 12:34:00 -0500
> I have the impression that, excepting OTP, most cases of
'proven
> strength' seem to be just that.
While this is certainly off-subject, it deserves an answer.
When a proper proof of security is performed, there are a
set of assumptions that are made, either explicitly or
implicitly. When these assumptions are met, or they are
assumed to be true (FLT was given as an example in this
thread), then one can rely on the security proof. Take for
example one of the AES candidates, DFC, it offered proof of
security against a certain attack. There was no point in
attempting an attack form that method, because the
assumptions were and still are considered fairly proper,
however other flaws were found in the construction, and it
was summarily eliminated. The proof of security covered a
very narrow band of attack, the same applies here, Ritter
has claimed that you must determine that the proof of
security applies by taking further measures to eliminate the
short cycles, others have claimed that the likelihood of
finding a short cycle is sufficiently small enough that it
can be ignored. So basically all our security proofs are
proof against attack X, but offer nothing against attack Y.
Joe
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Discret Logarithm
Date: Mon, 07 Aug 2000 22:35:40 +0200
[EMAIL PROTECTED] wrote:
>
> Generalised Discret Logarithm Problem
>
> Given a finite cyclic group G of the order n, a generator a of G,
> and an element b of G find an integer x, 0 =< x =< n-1, such that
> a^x = b.
> Proposed solution can be found at
>
> www.alex-encryption.de
I think it is favourable that you say something here instead
of letting people to switch to web browser right away, i.e.
whether the problem is new, your solution is new, or both,
and some salient points of the material at least. Thanks.
M. K. Shen
------------------------------
From: "Ed Suominen" <[EMAIL PROTECTED]>
Subject: Re: 2 keys encryption algorithm?
Date: Mon, 7 Aug 2000 13:33:52 -0700
Just compute a secret shared key with DH key exchange - private exponents
a,b to known base g result in public keys g^a and g^b, with both parties
computing their shared key as g^ab, probably g^ab mod n. Then encrypt
everything to that shared key.
(90% ignorant about crypto 1 months ago, now only 75% ignorant, learning
fast...)
Ed Suominen
Registered Patent Agent
Web Site: http://eepatents.com
PGP Public Key: http://eepatents.com/key
<[EMAIL PROTECTED]> wrote in message news:8mmvsj$eso$[EMAIL PROTECTED]...
> Hi all,
>
> Is there a solid 2 keys encryption system out there. What I mean by 2
> keys is the systems requires two keys to encrypt the data and then
> needs only one of the two to decrypt it. An application for such system
> is a conversation recording system where the two parties encrypt the
> system and either of which can hear it later.
>
> I am not sure whether the concept of public and private keys apply here.
>
> Thank you very much for you time and effort.
>
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Applications for One-Way Function?
Date: Mon, 7 Aug 2000 13:31:41 -0500
I don't think it's impact would be all that significant.
Also given that description, there MUST be an inverse
function, since each input value maps to a unique output
value, there must exist a function that maps the output
values to a unique input value, whether it is inexpensive to
compute is another issue. This is effectively an issue of
unkeyed cryptography. However if instead you were to have
knowledge of a function of N*->N with various other
properties that hash function would be of significant
interest. Of course one could find a way to make the N->N
function behave as an N*->N function using feedback.
Joe
"Ed Suominen" <[EMAIL PROTECTED]> wrote in message
news:x0Ci5.24754$[EMAIL PROTECTED]...
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Assume the existence of a one-way function with the
following
> properties:
>
> 1. For any input value in the space {0,2^N}, there is a
unique but
> unpredictable output value in the same space, {0,2^N}.
> 2. Each output value corresponds to only one possible
input value (no
> collisions possible).
> 3. It is very easy (and very fast) to compute an output
value from an
> input value, but computationally infeasable (e.g., 2^128
> possibilities) to compute an input value from an output
value.
>
> What sort of crypto applications are there for such a
function,
> besides storing transformed passwords for verification
against input
> passwords?
>
> Ed Suominen
> Registered Patent Agent
> Web Site: http://eepatents.com
> PGP Public Key: http://eepatents.com/key
>
> -----BEGIN PGP SIGNATURE-----
> Version: PGP Personal Privacy 6.5.3
>
>
iQA/AwUBOYrsP6mKuMvNCWDGEQJQmQCfZ3LaJedvVdrLc99I2xbDi3MRJ2oA
n0c9
> q7oHhKUpN7HIXlve8ebUvPYm
> =Q86l
> -----END PGP SIGNATURE-----
>
>
>
>
>
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Digital Certificates and Key Lengths
Date: Mon, 7 Aug 2000 13:24:26 -0500
> Ok, this would not be a secure connection? Would it be
more, less,
> equally secure as a 512 CA issuing a 512 cert?
Sort of. The difficulties involved make it very difficult to
tell. Looking at it from a knowledge collision standpoint,
there are approximately 10^140 possible 512-bit RSA moduli.
A collision on a single cert is 1/10^140, a collision on 2
is 2/(10^140), both verify negligible, but by making the
second cert 1024 bit, you make it 1/(10^140)+1/(10^600),
which is significantly smaller. So from the collision of
knowledge standpoint (birthday paradox type attack) a
1024-bit cert is preferable.
An attacker is not going to take that route. An attacker
will instead break your public key, so lets look at which
one he will break, the valid cases are:
1 CA Cert, 0 Server certs = attacker breaks CA cert
1 CA Cert, 1 Server certs = Attacker will choose based on
ease of breaking CA vs breaking server
1 CA Cert, n Server certs = Attacker break CA cert
>From this we can say that given 1 CA, 1 Server, the attacker
will break the easier one, your maximum security is the
512-bit CA, issuing a 1024-bit cert from the 512-bit cert
wil increase the security of every valid transaction, so in
that respect will be stronger than the 512-512 version. So
under 2 different views of the problem, we get the same
answer, a 1024-bit cert would be marginally more secure, the
difference however should not be expressed as deltaX, and
even epsilon may be too strong, probably dx (from calculus
notation, basically referring to an infinitely small area)
would be the most accurate.
It is fairly obvious that you want your CA cert to be at
least as strong as your server certs. Since 512-bits has
been successfully factored, your CA cert is very much at
risk. I'd recommend making a new CA cert of at least
1024-bits.
Joe
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: OTP using BBS generator?
Date: Mon, 07 Aug 2000 20:37:01 GMT
Terry Ritter wrote:
>
> Bryan Olson wrote:
>
> >Terry Ritter wrote:
> >[...]
> >There's no reason to think (in fact it's false) that the
> >BB&S scheme _with_ the long-cycle check has no sets of keys
> >for which the generator can be efficiently predicted.
>
> That's a bit too abbreviated for my limited understanding. Perhaps
> you should give some examples to demonstrate your meaning.
Sure. If I publish a list of a hundred legal BBS keys, for
any key from that list there's a fast algorithm to predict
the generator.
> Clearly, N -- presumably part of "the key"
[...]
> Then, x0
[...]
Yes, that's what I'm calling the key.
> Do you understand that once the BB&S generator -- or, indeed, *any*
> RNG of any sort -- has traversed an entire cycle -- ANY cycle, short
> OR long -- the continuing sequence is no longer secure? How does that
> fit into your proofs?
That is one way a PRNG can fail and become predictable.
There are many, many others. The proof - without the long
cycle test - deals with _all_ algorithmic methods of
predicting the generator. The proof is a reduction from QR
(and later factoring) and thus it only shows the generator
hard to predict in the sense and in the cases in which
factoring is hard.
> >The
> >scheme without the long cycle test is secure in the same
> >sense as the scheme with the test.
>
> Nope.
>
> Part of keying BB&S is [...]
Which shows that if one follows the long cycle test, there
is one particular kind of failure that cannot happen - a
cycle in the generator state. There is still no general
proof that particular keys are strong.
[...]
> There is
> thus a distinct difference between using a short cycle and using a
> long one, yet both are treated in the same way in the security proofs.
> What is the meaning of a proof of strength when the system it
> describes is not secure?
The system is not the same as a particular key. If a proof
shows that a predictable generator is vanishingly unlikely
but not impossible, that's still a proof.
The BB&S proofs are of this form: if the chance of an
attacker being able to factor the modulus is vanishingly
small, then the chance of him predicting the generator is
vanishingly small. The long cycle test adds that there is
one particular attack - checking for a state cycle, that
cannot happen. It does not change the probabilistic nature
of the general proof.
> I suppose that one of the issues here might be the use of asymptotic
> proofs of strength, or statistical proofs of strength, to incorrectly
> imply strength in every case.
YES!!! The proof applies to the system including the
distribution of keys it selects.
> Perhaps a statistical proof can just
> mean *most* cases, which may mean that some cases which fit under the
> guarantee are not really secure. That would be an interesting
> definition of "proven strength."
It's somewhere in-between. Saying such proofs "just mean
*most*" loses the defining point of mathematical
probabilities: they _quantify_ such chances (in this case in
asymptotic terms and relative to an open mathematical
assumption). We can come to rigorous, certain results, even
when reasoning about chance and uncertainty.
Cryptographic proofs are generally probabilistic. The way
most protocol proofs argue security is based on a
"simulator". The simulator is an efficient algorithm the
adversary can run (without knowing the keys or seeing any
protocol messages) that produces the same distribution of
transcripts as does recording the actual protocol messages.
Note that this does not imply that the particular transcript
we do in fact generate will never help the attack. It does
show that carrying out the protocol is no more likely to
expose our secrets than is letting the adversary alone.
> >> I claim it is deceptive to call the reduced scheme BB&S. It is
also
> >> deceptive to claim that any system which we can make more secure by
> >> our own action is absolutely secure. Here we have a case where the
> >> security guarantee is factoring, but our own inaction can lead to
> >> allowing exactly that factoring.
> >
> >So should we check that our modulus is not in anyone's
> >public certificate? It's a non-zero chance; we can check
> >the pubic directories, and it would be weak to use a key for
> >which someone else already knows the factors.
>
> That is some other issue.
But within your "any system which we can make more secure...".
It's an absurd weakness to defend against because it happens
with negligible probability, just like the short cycle.
> My issue is that the original BB&S article showed how to do all this
> right, or at least it gave one way.
If you are saying the original BB&S article showed that the
particular chosen key would, in every case, resist attack,
they that's exactly the mistake you identified: using a
statistical proof of strength to imply strength for the
individual case.
[...]
> >The BB&S paper was the first important work on the x^2 mod
> >pq generator, but certainly not the last. The long-cycle
> >conditions, while arguably of interest, are not needed to
> >support the theorem.
>
> True, but irrelevant.
You've been saying that the reason most authors of crypto
references do not include the long-cycle test of BB&S is
that they didn't read and understand the entire paper.
Nonsense. They know more, not less.
--Bryan
--
email: bolson at certicom dot com
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Ed Suominen" <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp
Subject: Re: Proposal: Timestamping Roundtable w/ PGP Sigs.
Date: Mon, 7 Aug 2000 13:52:24 -0700
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
Excellent points, all. Thanks for the feedback. Here are some
responses:
1. Testimony as to one's signature on a document can be as simple as
signing an affidavit with the purportedly signed document attached as
an exhibit. The scenarios of getting flown all over the globe to
testify are simply unrealistic. I've asked several witnesses to
testify in various cases before the U.S. Patent Office, and all that
testimony has been in written, signed statements. The signer of the
statement can, if necessary, verify his own digital signature on an
electronic form of the message (presumably provided by the person
wanting his testimony) against what he knows to be his public key.
2. Regarding the "why didn't you just use a pay-for service in the
first place" comment, in many situations the probability that any
given time stamps will be relied on in dispute resolution is very
low. It is more feasable (in my view) to pay more later to validate
the evidence you really need. I'm a part-time inventor (four patents,
more pending) and get signatures on my invention disclosures all the
time, though now they're mostly digital signatures from friends
rather than ink. I trust those folks that I'll be able to get them to
testify as to their signatures 10-20 years later if I need to -
that's why I don't use one particular 87 year old friend for
signatures, much as I trust him.
3. Tom pointed out the basic public key authentication problem: "Who
will be doing the signing? Why should I trust them, what legal
binding oblication do they have to ensure a correct valid signature?"
This system will only work if you trust the people signing it and
somehow know that their private key is what's doing the time
stamping. It does no good to have your file time stamped by someone
who will never have anything to do with you again. Presumably, the
participants in the roundtable will know each other somewhat or will
get to know each other as they participate. Of course, they will want
to verify the public keys of the people time stamping their files, a
process that PGP addresses in their user's manuals. ("Hello, Tom, Ed
calling, what's your fingerprint, please....")
Now, who's willing to sign my original post on comp.security.pgp.test
and start things off? You've all pointed out legitimate concerns, and
I can't make *any* guarantees or warranties as to the efficacy,
technical or legal, of this scheme. But you can't argue with the
price!
Nothing in this message is to be construed as legal
advice, or the opinion of my firm or any client.
- - -------------------------------------
Ed Suominen
Registered Patent Agent
Web Site: http://eepatents.com
PGP Public Key: http://eepatents.com/key
=====BEGIN PGP SIGNATURE=====
Version: PGP Personal Privacy 6.5.3
iQA/AwUBOY8hVamKuMvNCWDGEQIygACg2qde1E6gWsSHpuTzwKuKnHMqSxwAoOeM
gout8+Fzf1VzC/rcFY6/wG7h
=ExTH
=====END PGP SIGNATURE=====
------------------------------
From: Roger Schlafly <[EMAIL PROTECTED]>
Subject: Re: Special RSA moduli
Date: Mon, 07 Aug 2000 14:03:08 -0700
Bob Silverman wrote:
> > I am looking for discussions on RSA moduli N of the
> > form N= p^r*q, where p, q are odd primes, and r is a
> > positive integer. I am particularly interested in security/
> > speedup tradeoffs for this kind of moduli.
>
> See the appendix in item #13 of:
> http://www.rsalabs.com/bulletins/index.html
That has a nice discussion of using 3 (or more) distinct factors,
but the query is about using a repeated factor.
As far as anyone knows, a modulus is not easier to factor just
because it has a repeated factor. But people don't trust such
systems anyway.
------------------------------
** 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
******************************
