Cryptography-Digest Digest #445, Volume #12 Tue, 15 Aug 00 02:13:00 EDT
Contents:
Re: chap authentication scheme? (Thomas Wu)
Re: chap authentication scheme? (Cryptocol)
Re: Proposal of drafting rules of conduct of posting ("Paul Pires")
Re: Crypto Related Professional Attitude (Eric Lee Green)
Re: Crypto Related Professional Attitude (Scott Contini)
Re: Big Brother Is Reading Your E-Mail (Michael Brown)
Re: 1-time pad is not secure... (Guy Macon)
Re: OTP using BBS generator? (Bryan Olson)
Re: 1-time pad is not secure... (Guy Macon)
Re: OTP using BBS generator? (Terry Ritter)
Re: 1-time pad is not secure... (Guy Macon)
Re: OTP using BBS generator? (Bryan Olson)
Re: Key in ASCII ?? (Guy Macon)
Re: OTP using BBS generator? (Terry Ritter)
----------------------------------------------------------------------------
From: Thomas Wu <[EMAIL PROTECTED]>
Subject: Re: chap authentication scheme?
Date: 14 Aug 2000 19:15:20 -0700
Okay, one last refinement here, and then I'll stop. :-)
0. Alice and Bob agree on g, p (DH parameters).
Alice knows the password r, Bob stores g^r (mod p).
1. Bob picks x, sends g^x
2. Alice picks y, sends g^y and S = H((g^x)^y || (g^x)^r)
To verify, Bob computes S' = H((g^y)^x || (g^r)^x) and sees if S == S'.
This is just a slightly more sneaky way of wrapping the Elgamal
authentication and the DH key exchange together. This should resist
passive dictionary attacks, allows the server to store the non-
password-equivalent g^r, and in addition doesn't reveal either r
or g^r to a fake server. Granted, a fake server can do dictionary
attacks, but we already know that's a given with two messages.
Thomas Wu <[EMAIL PROTECTED]> writes:
>
> Why not try a simple DH/Elgamal approach:
>
> 0. Alice and Bob agree on g, p (DH parameters).
> Alice knows the password r, Bob stores H(r).
>
> 1. Bob sends g^x
>
> 2. Alice sends g^y and S=r*(g^x)^y
>
> To verify, Bob computes r'=S/(g^y)^x and sees if H(r') == H(r).
>
> This just sends the password down the channel Elgamal encrypted with the
> DH session key. This naive approach is essentially what ssh user
> authentication does; it is totally vunlerable to fake server attacks,
> since an impersonated server gets the password, but if people don't
> notice this serious problem in ssh, you can probably "get away with it"
> as well in a CHAP variant.
--
Tom Wu * finger -l [EMAIL PROTECTED] for PGP key *
E-mail: [EMAIL PROTECTED] "Those who would give up their freedoms in
Phone: (650) 723-1565 exchange for security deserve neither."
http://www-cs-students.stanford.edu/~tjw/ http://srp.stanford.edu/srp/
------------------------------
From: [EMAIL PROTECTED] (Cryptocol)
Subject: Re: chap authentication scheme?
Date: 15 Aug 2000 02:48:30 GMT
Thomas Wu wrote:
>Okay, one last refinement here, and then I'll stop. :-)
>
>0. Alice and Bob agree on g, p (DH parameters).
> Alice knows the password r, Bob stores g^r (mod p).
>1. Bob picks x, sends g^x
>2. Alice picks y, sends g^y and S = H((g^x)^y || (g^x)^r)
>
>To verify, Bob computes S' = H((g^y)^x || (g^r)^x) and sees if S == S'.
>This is just a slightly more sneaky way of wrapping the Elgamal
>authentication and the DH key exchange together. This should resist
>passive dictionary attacks, allows the server to store the non-
>password-equivalent g^r, and in addition doesn't reveal either r
>or g^r to a fake server. Granted, a fake server can do dictionary
>attacks, but we already know that's a given with two messages.
Wonderful, but I think Alice and Bob need hard computations.
Finally, I would like to show my solution.
AA-CHAP:
Alice has v while Bob stores g^v.
1. Alice <-- g^x -- Bob
2. Alice -- g^y, h(g^xa) --> Bob
a : amplified password such that a = y + v
Bob verifies h((g^yg^v)^x) == h(g^x(y+v))
Both parties need two exponentiations.
AA-CHAP is secure against passive attack and server compromise, not against
fake Bob.
note: please refer to earlier article for detailed notations.
------------------------------
From: "Paul Pires" <[EMAIL PROTECTED]>
Subject: Re: Proposal of drafting rules of conduct of posting
Date: Mon, 14 Aug 2000 20:30:23 -0700
Trevor L. Jackson, III <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Paul Pires wrote:
>
> > tomstd <[EMAIL PROTECTED]> wrote in message
> > news:[EMAIL PROTECTED]...
> > > [EMAIL PROTECTED] (JPeschel) wrote:
> > > >Mok-Kong Shen [EMAIL PROTECTED] writes, in part:
> > > >
> > > >>Your opinion is certainly wellcome like any other. One
> > > >>of the underlying goal of the proposal is to find out
> > > >>what the majority of the group really thinks about some
> > > >>of the (in my view) very legere styles of discussions.
> > > >
> > > >You originally talked about "bad language" so I included
> > > >"damn" in my answer. I don't think many would object to
> > > >"damn," but some might. Do we ban it?
> > >
> > > The word 'super' offends me too... don't ask why.
> > >
> > > >One of the biggest problems in this sci.crypt, I think,
> > > >is name-calling: "idiot," "moron," "pompus jerk," and
> > > >a few more creative, but, still vacuous appellations.
> > > >Other kinds of personal attacks are useless to the group,
> > > >too. No one likes to be flamed, although, if you have
> > > >time on your hands, watching someone else's
> > > >flame war might be mildly amusing from time to time.
> > >
> > > Hey "Pompous Jerk" is most suiting to the arrogant people with
> > > alphabet soup that don't post here out of fear of discussion.
> >
> > I guess this is why they make youngsters so cute. It's so that you don't
> > just kill them out of hand.
> >
> > I have followed this thread and you are not offering this insult in
response
> > to some rude posting from the jerk but as an evaluation of the
motivation
> > behind their not posting. Strong language for an acusation based on
> > supposition. You even managed to disparage their accomplishments at the
same
> > time. At least Don Rickles is funny.
>
> It's about time for the bung. Comes from a theory of child development in
which
> all infants are encapsulated in a barrel at birth. One feeds them through
the
> bunghole (place the spigot goes). The insulates the rugrat and houseape
> phases. At age 18 you open the barrels containing females. For barrels
> containing males you hammer in the bung.
You are not a nice man.
I like it.
Paul
>
------------------------------
From: Eric Lee Green <[EMAIL PROTECTED]>
Subject: Re: Crypto Related Professional Attitude
Date: Tue, 15 Aug 2000 03:56:27 GMT
Mok-Kong Shen wrote:
> > intensity and perversity of the machinations. Being intelligent is only loosely
> > correlated with being rational.
>
> But being educated should fairly be correlated with being
> rational, I suppose.
Not really. The inventor of the transistor, a Mr. Shockley if I recall
correctly, spent many years of his life "proving" that Negros (his term)
were genetically inferior to Caucasians. Being educated in Physics and
Chemistry in no way led to rational thought in a field outside of his
specialty.
Similarly, a brilliant inventor recently "proved" that the gas chambers
at Auschwitz were never used to exterminate people. He has no training
in chemistry, but that did not stop him from saying that since he found
no cyanide in his scrapings, thus there were no people gassed there.
Education cannot provide wisdom. It only provides the opportunity for
wisdom, at best.
--
Eric Lee Green There is No Conspiracy
[EMAIL PROTECTED] http://www.badtux.org
------------------------------
From: [EMAIL PROTECTED] (Scott Contini)
Subject: Re: Crypto Related Professional Attitude
Date: 15 Aug 2000 04:24:26 GMT
In article <[EMAIL PROTECTED]>,
Eric Lee Green <[EMAIL PROTECTED]> wrote:
>Education cannot provide wisdom. It only provides the opportunity for
>wisdom, at best.
Or, as somebody else might say,
"You can lead a horse's..."
uh never mind.
Scott
------------------------------
From: Michael Brown <[EMAIL PROTECTED]>
Crossposted-To: alt.privacy,alt.security.pgp
Subject: Re: Big Brother Is Reading Your E-Mail
Date: Tue, 15 Aug 2000 16:50:32 +1200
Currently, I can do a 12 bit by hand, an I'm writing up a word documant
to be posted soon. If you want to see an old and not-complete version in
XL form go to:
http://members.fortunecity.com/mibro/rsa.xls
My copy of Netscape doesn't want to download it directly, but any
downloader such as GetRight or NetVampire does it fine.
There is still a bug not mentioned on the XL sheet. It's when the second
least significant bit is zero, and this is what I'm writing up at the
moment. However, you still can factorize a key of any size with the 2nd
LSB being one. Just add more boxes (se the sheet for details).
PS: Half the stuff on the sheet is probably very jumbled. This is why I
didn't release it sooner.
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: 1-time pad is not secure...
Date: 15 Aug 2000 04:49:27 GMT
JPeschel wrote:
>
>[EMAIL PROTECTED] (Guy Macon) writes:
>
>>I meant, of course, that I will put this this paper that he says
>>he hasn't gotten around to publishing on the net for him. Thus
>>he has no remaining excuse for not publishing it.
>
>Well, Guy, it's Gwyn's paper to do with as he wants.
>He may want to update the paper and seek journal
>publication. Not many journals or magazines are
>going to re-print articles that have already been
>published. Some publishers will pay for re-print
>rights, but they are few, and the pay is less.
>
>I'd like to see more of Gwyn's work in a centralized
>location on the web, too. (Guess where.)
>But Doug owned the copyright to the paper when
>he wrote it, so, again, the paper is his to do with
>as he pleases.
Of course it is. I was just responding to his comment that
he wishes that it was on the Internet but hasn't gotten
around to setting up a web page. If he changes his story
and says that he really doesn't want it on the Internet,
that's fine with me too. I was just offering to help.
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: OTP using BBS generator?
Date: Tue, 15 Aug 2000 04:38:08 GMT
Terry Ritter wrote:
[...]
> Next, in my view the assumption is *not* sufficient. Indeed, that is
> what started all this. Many people have assumed that short cycles
> simply could not exist in BB&S because factoring was assumed hard, and
> if short cycles existed, factoring could be easy.
I don't know what people you are talking about; of course
they exist. The proof shows that they must be sufficiently
unlikely that they do not increase the chance for an
attacker to factor a given modulus.
> But not only is there no proof that factoring is hard, we know very
> well that factoring will be pretty easy if the system somehow gives
> away our factors. To realistically assume that factoring is hard, we
> must build systems which do not expose our factors.
Use of BBS, (without cycle-length filtering) does not
increase the chance that the attacker can factor a given
modulus.
> So we *can* *assume* that factoring is hard, but if we then happen to
> select, use and traverse a short cycle, our assumption has become
> demonstrably false. In other words, a mere assumption is insufficient
> to protect us from the real defect of selecting and using a short
> cycle.
Nonsense. First you assume factoring is hard then you
assume you are in a case in which factoring is easy.
> Further, the failure of the assumption (factoring is hard) is
> associated with the details of a particular implementation, and that
> does not confront the fundamentals of mathematics. It is not true
> that a weak BB&S instance means that major math assumptions must be
> wrong. Reasoning that BB&S must be strong or major changes will be
> required in math is simply incorrect.
We've already identified the error: you are confusing the
security of the system with properties of individual keys.
[...]
> >the conclusion follows from the
> >premises; it doesn't help assure them.
>
> A cipher system is distinctly different from a theorem. The theorem
> would presumably "work" if a poorly implemented system sent the
> factors as plaintext, because then factoring would be easy.
No, that's a misunderstanding of the result. It's not just
that predicting BBS is no more likely than successful
factoring given help the output may provide. Predicting BBS
(with random starting point) is no more likely than
factoring the modulus _without_ being given the BBS output
(but given the modulus).
[...]
> If and when a short cycle is selected and traversed, that reveals a
> factor and the system is once again insecure. But here we have no
> system implementation problem, instead, we have a math problem: the
> entire structure of the BB&S system, including the short cycle
> weakness defects, is completely produced by the constructing math.
Again, that's a misunderstanding of the result. The
probability of the attacker factoring follows from the
probabilities of all the possible starting points. What you
seem to be talking about is the conditional probability of
the attacker factoring given some near-worst-case choice of
state. That's different, and the theorems say nothing about
it whether or not one filters out short cycles.
It's not a mathematical trick either. Particular keys,
without regard to their probabilities are not secure or
secret in any significant sense. For any specific key
there's a fast algorithm to break it.
> >If the attacker were more likely to be able to factor a
> >known modulus when given the generator output than when not
> >given the output, then you would have a point. But that's
> >not the case.
>
> Sure it is. When given the generator output over a short cycle
> factoring becomes possible and likely.
The "sure it is" is false; the sentence that follows it is
true.
Two claims both true: (1) Using BBS with a random starting
point does not increase the chance of factoring the given
modulus. (2) Given that the choice of key induces a short
cycle factoring becomes easy.
It's only a paradox is one does not understand conditional
probabilities. The theorem relates the chance of finding a
short cycle to the chance of factoring the modulus.
[...]
> The attacker can detect a cycle traversal when that occurs. Given
> that, he can factor.
Same mistake. The conditional probability, given a worst-case
choice of key is not what the result talks about.
--Bryan
--
email: bolson at certicom dot com
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: 1-time pad is not secure...
Date: 15 Aug 2000 04:54:40 GMT
Tim Tyler wrote:
>Except that it doesn't say any such thing. Completely deterministic
>interpretations of quantum theory exist, namely - for example - the MWI.
>
>Such interpretations make no use of random events - and are consistent
>with all observations to date.
Not suprising, considering that the MWI predicts that your experiments
will give you the exact same answers as you would have recieved if
randomness exists.
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: OTP using BBS generator?
Date: Tue, 15 Aug 2000 04:54:35 GMT
On 15 Aug 2000 01:00:23 -0000, in
<[EMAIL PROTECTED]>, in sci.crypt lcs Mixmaster
Remailer <[EMAIL PROTECTED]> wrote:
>Benjamin Goldberg wrote:
>> lcs Mixmaster Remailer wrote:
>> >
>> > If you can find short cycles, you can factor the value. You have
>> > x^2 = y^2 mod n, so (x^2 - y^2) = 0 mod n, so (x-y)(x+y) is a multiple
>> > of n, and if you take the gcd of x-y and/or x+y with n you have a good
>> > chance of finding a factor.
>> >
>> > In your example, you have that 46*46 = 1035*1035 = 1035, mod 1081.
>> > Now we can do the gcd of the modulus with 1035-46. gcd(1081,989)
>> > = 23, which is one of the factors! We've factored the modulus.
>>
>> But the attacker never sees 1035, only it's least significant bit,
>> repeated many times. The attacker doesn't see X[0], either, I don't
>> believe.
>
>The point is, if you can find a cycle of "X" values, you can factor.
>Terry Ritter's advice to choose X values which aren't on a cycle is
>useless, because it implies worrying that your modulus can be factored
>by mere guessing.
Since I have given no such advice, it may be time -- assuming your
distortion of my position is accidental -- for you to go back and
actually read my responses.
My interest is in the meaning and implications of cryptographic proof.
I have said many times that I do *not* regard short cycles as a BB&S
weakness in practice. Perhaps you have just missed reading each and
every one of those statements.
On the other hand, to the extent that someone practices BB&S on the
basis of the proof, with the goal being absolute confidence in having
an unbreakable cipher, a practical issue does exist. This is because
the proof offers no such confidence, even if, as we suspect, the major
math assumptions are absolutely true. A BB&S system can be weak in
many ways without damaging math as we know it.
>You are asking whether, given a cycle of just the LSBs, you can factor.
>The answer is yes, but it is more complicated and requires reference to
>the BBS paper and the follow-up literature which has been referred to
>in the recent discussions on sci.crypt.
I would like to see a list.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: 1-time pad is not secure...
Date: 15 Aug 2000 05:06:59 GMT
Tim Tyler wrote:
>I didn't like your suggestion that people who held the same views as
>me on this subject were being influenced by theology, and were unaware
>of the source of their ideas. Consequently I feel that you started it ;-)
Fair enough. Let's agree that I started it.
>I feel my views in this area are entirely rational. I think it is
>those who are convinced either that true randomness exists, or that
>true randomness does /not/ exist are those holding theological views.
Ah. I see the problem. I wasn't clear enough. Let me elaborate.
I do not think that your views are theological (nor do I share your
opinion that theology is nonrational, but that's another subject).
I believe that your view shares certain methods of memetic propagation
with theology, without drawing any inference that the merits of your
views are in any way related to the merits of any theological views.
The only link I see is simular propagation/replication mechanisms.
The opposing memeplex seems to use different propagation/replication
mechanisms, again without infering anything about the merits of the
opposing memeplex.
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: OTP using BBS generator?
Date: Tue, 15 Aug 2000 05:04:51 GMT
> Bryan Olson wrote:
>
> : Many times on sci.crypt people have objected to the proof of
> : perfect secrecy for the OTP based on the fact that the zero
> : vector is one of the possible keys. The false logic goes
> : something like: since the OTP is provably secure, and zero
> : is a legal key, then encrypting with the zero key must be
> : secure, and since it obviously isn't the proof must be
> : wrong.
>
> : The OTP theorem doesn't say that encrypting with a
> : particular key will maintain secrecy. It says choosing a
> : one-time key uniformly at random and exposing the resulting
> : ciphertext does not increase the chance of the attacker
> : determining the plaintext.
>
> This case still seems totally different from the case of
> using BBS with short cycles.
>
> Using the all-0 key in an OTP doesn't help the attacker
> get the message, since he has no way of knowing it has been used.
Not so. If in fact one does use the all zero key of
significant length, the attacker should win. He would
almost certainly think we were not in fact using a true one
time pad. There's nothing in the theorems that will stop
him from reading cleartext.
Using the OTP, the chance of any message given the
ciphertext is the same as the chance of that message when
not given the ciphertext. That follows from the uniform
keyspace; if you try instead the conditional probabilities
given specific keys, the secrecy of the system vanishes, as
Shannon warns up front.
An attacker's chance of factoring a known modulus given BBS
output (from a random starting point) is the same as his
chance without the generator output. Again, that follows
from the space of possible choices.
The two systems certainly are different, and the title of
this thread is unfortunate, since BBS has nothing to do with
the OTP. The issue that secrecy comes from the keyspace and
not the key applies to all secrecy systems.
--Bryan
--
email: bolson at certicom dot com
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Key in ASCII ??
Date: 15 Aug 2000 05:21:15 GMT
Trevor L. Jackson, III wrote:
> With respect to your dictionary search, single words are not English
> text. There is insufficient context to limit the information to a
> single bit per character. After all, there are far more than 256
> eight-letter words in English. However, a random sequence of
> eight-letter words is hardly English text.
Let me see if I amm getting this straight. Are you saying that
in the following text string:
"With respect to your dictionary search, single words are not English
text. There is insufficient context to limit the information to a
single bit per character. After all, there are far more than 256
eight-letter words in English. However, a random ******** of
eight-letter words is hardly English text.", that there are roughly
256 8 character words that can replace "********"? (In the general
case over many english text strings, of course.) I can see that.
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: OTP using BBS generator?
Date: Tue, 15 Aug 2000 05:53:31 GMT
On 15 Aug 2000 01:20:32 -0000, in
<[EMAIL PROTECTED]>, in sci.crypt lcs Mixmaster
Remailer <[EMAIL PROTECTED]> wrote:
Remember the following first sentence, since we will use it again
later:
>Terry Ritter writes:
>> As I have stated many times, I think shot cycles are not a weakness in
>> practice. Instead, I am most concerned with the meaning of
>> cryptographic proof. For, if we have an example where weakness can
>> occur, then, clearly, cryptographic proof has failed to prevent that
>> weakness.
>
>It's not a problem with "cryptographic proof" (so broad a category as
>to be meaningless). It's a problem with your understanding of what is
>proven in this particular case.
>
>BBS prediction reduces to factoring difficulty. But what does it mean
>that factoring is hard? It certaily doesn't mean that no numbers can be
>factored, ever. But sometimes in your comments you seem to be claiming
>that a "proof" ought to lead to this level of certainty.
I would say the problem is with *your* understanding, or lack of it:
In particular, a system using BB&S can be weak in many ways unrelated
to the usual BB&S assumptions. Multiple assumptions are involved.
Thus, a weak BB&S does not affect math itself unless we can show that
the assumption at fault is one of the major math assumptions. BB&S
with its' proof of strength can be just as weak as any other cipher if
we do not make sufficient assumptions.
In particular, if we want our "proof" of strength to cover even the
extremely rare event of using a short cycle, then we must have an
additional assumption such that we will not use or traverse a short
cycle. Of course, if we are willing to accept short cycles and
resulting loss of data as an extremely rare event, then we will not be
interested in the more comprehensive "proof." However, I think many
people would use BB&S specifically to obtain "proven" strength and so
would want the more comprehensive version. The point here is not
practical strength, but instead having a "proof" which would cover all
known problems that could be covered in such a proof.
>Factoring difficulty means a typical RSA modulus of appropriate size will
>take a long time to factor. But it doesn't mean that _every_ modulus
>will have that property. Many factoring algorithms are probabilistic,
>like Pollard's rho. There is a certain tiny chance that a random 1024
>bit RSA modulus will fall almost instantly to such algorithms.
I note that this situation is distinctly different from the BB&S case:
The weakness cited for RSA is that some factoring algorithm might find
a factor quickly. But that is not a special weakness in the modulus
itself, that is the attacker's chance. Saying that a factoring attack
may conclude quickly is like saying that a brute-force search on keys
may succeed quickly. And that is no more than what we always assume
about any cipher based on keys.
In contrast, the BB&S short-cycle case involves leaving an
*additional* weakness in the system *beyond* the weakness we always
expect from brute-force searching. The use and traversal of a short
cycle is a weakness which can be detected and avoided, or not.
>Suppose some naive person learns this fact, and immediately starts telling
>people that they shouldn't trust RSA unless they run their moduli through
>a battery of standard factoring algorithms to make sure they don't happen
>to split easily. Anything less than this, they say, is not "true" RSA.
>It is RSA with a known weakness.
>
>RSA, they suggest, is based on the difficulty of factoring. But if you
>don't check your modulus to make sure it isn't one that factors easily,
>you don't know that factoring it will be difficult! You are basing your
>security on a property your modulus doesn't have!
>
>Furthermore, doing this check can only strengthen the security of the
>system. It follows that not doing the check means that your system is
>not as secure as it could be. By this reasoning all the RSA public keys
>in use are not secure.
You seem to be dragging this much farther than I would go, with the
presumable intent being to tell me how crazy I am to say such a thing.
But I'm *not* saying it: *you* are.
>Doesn't this sound familiar? It is exactly analogous to what you are
>saying.
No, it is not.
>You are advising people to defend against a theoretical flaw
>which will never happen in practice.
No, I am not. In fact, you quoted my position at the top:
>> As I have stated many times, I think shot cycles are not a weakness in
>> practice.
Which part of "not a weakness in practice" do you not understand?
>You are claiming that systems that
>don't check for this theoretical problem are weak
No, I am not.
>and don't deserve to
>be called "true" BBS.
Finally, you got something right: Real BB&S uses the techniques in
the BB&S article to prevent short cycles. That is the definition of
BB&S. Everything else is what other people claim BB&S should have
been, in which case they should write their own paper, and get that
different system named after them. Using the different and lesser
system and calling it by the name of its better is deceptive.
>You are saying that failing to check for this
>problem leaves your system with weakness.
I would not say that.
I am saying that there can be no complete proof of strength which
allows a demonstrable weakness to exist. If we know a weakness may
exist, then, clearly, we do not have the kind of comprehensive proof
many people would like.
The reason to use slow BB&S rather than a conventional cipher is to
gain the comfort of the proof. But that comfort is rather limited
when one knows of a fault or weakness -- even if extremely rare --
which is not covered by that proof.
>These are exactly the points raised by our naive RSA alarmist. And yet
>no one follows his advice. No one wastes his time checking his RSA
>moduli with factoring algorithms. Not one standard crypto package,
>designed by experts in the field, includes this check. In fact to add
>such a test would totally discredit the implementation; it would brand
>it as utterly unprofessional.
Since I would not suggest doing that, I am glad to be confirmed in my
opinion.
Actually, I would say that it is more than a little unprofessional to
distort someone else's views, whether by premeditation, lack of
research, or even excitement of the moment. I have posted my views on
this in detail in many messages, and there is no excuse for
misrepresenting my views.
>And of course if anyone were ever so foolish as to follow Terry Ritter's
>advice in implementing BBS, they would appear equally amateurish.
I have given no such advice.
But, based on the content of this message, my advice would be to
ignore any author who for whatever reason frequently distorts someone
else's position as badly as this.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
** 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
******************************
