# Proof and Strength in the BB&S RNG

## A Ciphers By Ritter Page

Lenore Blum, Manuel Blum and Michael Shub (BB&S) are the authors of a famous mathematical article on the construction of an "unpredictable" random number generator (RNG), which we also call BB&S.

Blum, Blum and Shub. 1982. Comparison of Two Pseudo-Random Number Generators.
• Advances in Cryptology -- CRYPTO '82. 61-78. Plenum Press.
• SIAM Journal on Computing. 15(2): 364-383. (1986).

### The BB&S RNG

The BB&S construction consists of finding two "large" primes, each of which is equivalent to 3 mod 4. But the BB&S article gives various other requirements, such as the primes being "special," requirements which are avoided by the modern cryptographic community. (Prime P is "special" when P = 2P1 + 1 and P1 = 2P2 + 1 where P1 and P2 are odd primes; finding special primes thus takes considerably more effort than just finding primes.) Much of the discussion here is about whether the results of the simplified system are the same as the special primes construction of the BB&S article.

In BB&S, the product N of the two large special primes P, Q, is used as a modulo to reduce a squaring computation: Xi+1 := Xi2 mod N, (or X[i+1] := X[i]**2 mod N). This defines a mathematical system which always has multiple cycles, some of which will be shorter than the longest cycles, while others will be degenerate cycles with constant values. Choosing an initial X[0] thus chooses a particular cycle within the RNG (including, with very low probability, short and degenerate cycles) and thus a sequence of X values. The value reported out of the RNG is the least-significant bit (LSb) of X. Typically BB&S would be the RNG part of a conventional stream cipher. Any stream cipher confusion sequence which repeats in practice is appallingly weak, because -- after the first pass through the cycle -- it is absolutely predictable.

### Security and Proof

The conversation starts with an innocent question about using BB&S as the running-key generator in a one time pad (OTP). The mere mention of BB&S then triggers a massive confrontation apparently just waiting to happen. As in any huge conversation, there are various sub-issues, side comments and snide comments, but much of the discussion is directed at me.

In retrospect, some of the problem seems to develop from a re-definition within mathematical cryptography of both "security" and "proof." Now, the term "security" is well-understood, first because it is part of the universal human condition, and second because there is a vast array of fields associated with "security" outside of cryptography. In particular, it is widely recognized that security is only as strong as the weakest link. Thus, normally, we see "security" as being the mathematical minimum of of the various securities involved, which thus provides a guarantee of some minimum level of security.

Mathematical "proof" is also well-understood, typically resulting from a general math education that begins in high school and often continues through four or more years of college. In most of this education, "proof" is an absolute statement about some condition.

But, in mathematical cryptography, "security" has taken on a statistical meaning, and "proofs" are typically probabilistic. Mathematical cryptography not only does not provide an absolute guarantee of security, it does not even provide a "lower bound" so we can identify the "weakest link." Consequently, even well-educated security experts are prime candidates for being deceived by the "terms of art" used in mathematical cryptography.

In mathematical cryptography, proof of security need not mean that no weakness exists, but may mean merely that if such weakness exists, it is sufficiently rare in large constructions. (And the definition of what size is "large enough" is more controversial than one might think.) Most practitioners of mathematical cryptography seem content to have "proven secure" describe a real system with a known weakness, provided the weakness exists only with low probability (although the actual probability involved is never really mentioned). But normal security work might call that "a hole."

BB&S is a very slow RNG, and the only reason for using it is to achieve the "provably secure" label which is tossed about. Presumably the user is willing to pay for the apparent guarantee of "proven secure." But what they may get is an RNG known to have weak short cycles, any of which might be selected and used, if the user is simply "unlucky." This would be especially ironic if the main reason users seek mathematically-proven security is to avoid depending on luck.

### Contents

• 2000-08- 3 Grant Anderson: "I know there has been much discussion about (supposed) OTP ciphers and how most of them generally don't fulfil the OTP requirements. What I don't understand is why the use of the blum-blum-shub generator as the pad isn't acceptable?"
• 2000-08- 3 Mack: "The basic problem with the BBS is that it is very slow."
• 2000-08- 3 lordcow77: "Practically everyone accepts that choosing the factors of the modulus to be congruent to 3 mod 4 and picking a random starting point are enough to ensure that the resulting BBS sequence will be secure . . . ."
• 2000-08- 3 Mark Wooding: "Can you provide a reference?"
• 2000-08- 3 lordcow77: "A proof would be a surprise to me as well :-)"
• 2000-08- 3 Mok-Kong Shen: "For one that does not have expert knowledge in BBS, like me, it seems unfortunately to be difficult to know from the materials of past discussions in the group alone whether one party is absolutly right and the other absulutely wrong."
• 2000-08- 4 Bryan Olson: "So look it up. Surely anyone can recognize the utter slyness of the claims that the reason the major current references don't include the long-cycle test in their description of the generator is that the authors have simply not read the whole paper."
• 2000-08- 4 Mok-Kong Shen: "If only the simpler form is described in a book and nothing else, how can a reader recognize laziness/carelessness of its author or its opposite, excepting through reading the original article of BBS?"
• 2000-08- 8 Bryan Olson: "I suppose you are right that one will not be able to tell . . . ."
• 2000-08- 8 Mok-Kong Shen: "The real problem is that those, who are able to fully understand the original paper of BBS, probably wouldn't stay long with this thread and watch the heated debate . . . ."
• 2000-08- 3 Terry Ritter: "Using a short cycle is unarguably insecure. And, unless we specifically prevent it, using a short cycle is an unarguable possibility."
• 2000-08- 3 Paul Pires: "Well said. I wish that I could be that generous in defending against nonsensical attacks."
• 2000-08- 3 Joseph Ashwood: ". . . while Mr Ritter and I have been on differing sides of discussions before, I agree with him completely in this case."
• 2000-08- 4 Mack: "I agree with Terry Ritter also."
• 2000-08- 5 David Hopwood: "The probability of weakness is not changed significantly by applying the constraints that Ritter thinks are necessary . . . ."
• 2000-08- 6 Mok-Kong Shen: "Thus if, in analogy, we equate OTP to infinity, then BBS is a very large (but finite) number."
• 2000-08- 7 Terry Ritter: "Here is the summary again:
* It is INDISPUTABLE that short cycles do exist in BB&S.
* If the start value is selected purely at random, it is INDISPUTABLE that a short cycle might be selected.
* It is INDISPUTABLE that when a random number generator (RNG) cycle has been traversed, we can predict future values from the ones produced in the past."
• 2000-08- 8 Bryan Olson: "So once more you refuse to address what people are saying. You bleat yet again that if a short cycle happens it's weak, as if the post to which you respond had said otherwise."
• 2000-08- 8 Terry Ritter: "The post to which I responded implied that weakness could not exist, and did so in a slightly offensive manner. It was false, because there is weakness. It just happens rarely."
• 2000-08- 8 Bryan Olson: "I take a different view: I think showing the failure happens with negligible probability is a perfectly valid way to address the weakness."
• 2000-08- 8 Terry Ritter: "If Bryan wants to see it as a debating trick, he can do that just as long as he likes."
• 2000-08-10 Bryan Olson: "I thought we might actually make progress last time."
• 2000-08- 9 Benjamin Goldberg: "Weak keys have low probability, but when they occur, the system is wide open."
• 2000-08-10 lcs Mixmaster Remailer: ". . . if any of these things happen, the rsa modulus is easy to factor, with a proper program. But the chances of any of them happening are infinitisimal."
• 2000-08-12 Benjamin Goldberg: "No, BBS is not quite the same as RSA."
• 2000-08-10 David Hopwood: "A practical example is IDEA: this has a set of weak keys that occur with probability about 2^-96. As it happens I haven't written any applications for end-users that use IDEA, but if I did, I wouldn't consider it necessary to check for weak keys."
• 2000-08-12 lcs Mixmaster Remailer: "In general, if you can find short cycles, you can factor. Hence if you believe factoring is hard, you believe that short cycles can't be found."
• 2000-08-14 Benjamin Goldberg: "But the attacker never sees 1035, only it's least significant bit . . . ."
• 2000-08-15 lcs Mixmaster Remailer: "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."
• 2000-08-15 Terry Ritter: ". . . 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." "A BB&S system can be weak in many ways without damaging math as we know it."
• 2000-08-15 Mok-Kong Shen: "Excuse me for posing some presumably very dumb questions."
• 2000-08-15 Mark Wooding: "The proof of unpredictability is a two-step thing:"
• 2000-08-15 Mok-Kong Shen: "So it means that you only need to prove the unpredictability and the statistical perfectness 'automatically' follows."
• 2000-08-15 Mark Wooding: "We know that finding cycles *of the LSB* is no easier than factoring!" "Terry doesn't agree, but doesn't have any analysis of LSB period to back him up."
• 2000-08-15 Terry Ritter: "I would say that I do have such an analysis, and it does back me up: If we use the BB&S construction, we are *guaranteed* not to use a short cycle. If we don't, then we are just very, very *unlikely* to use a short cycle."
• 2000-08-15 Mok-Kong Shen: "Please correct me if I am wrong. I guess that you have investigated the cycle lengths of the direct output of the congruence relation but not the cycle lengths of the LSB, which could be comparatively much shorter."
• 2000-08-16 Terry Ritter: "No correction is needed, since you are right. I have no special information on the LSB question."
• 2000-08-16 Mok-Kong Shen: "Thank you for the answer. This means that the situation is much WORSE than what an quasi-observer of this thread like me up till now imagines."
• 2000-08-16 Mark Wooding: "Note that the period length of the parity sequence must be a factor of the period length of the sequence."
• 2000-08-16 Mok-Kong Shen: "So why not persuing it a bit further?"
• 2000-08-15 Mok-Kong Shen: "I conjecture that one has to be able to say something definite about the distribution of cycle lengths of LSB, if one can prove that finding cycles of the LSB is no easier than factoring."
• 2000-08-16 Mark Wooding: "The proof is much more general than that. It shows that *any* method of predicting the generator's output allows you to factor."
• 2000-08-16 Mok-Kong Shen: ". . . we can't simply through hand waving ignore the potential possibility that such patterns could also occur for LSB of moduli that are difficult to factor."
• 2000-08-15 Terry Ritter: "The construction as described in BB&S first guarantees that cycles of a given length must exist, and then shows how to check that x0 is on such a cycle. The check is thus absolute proof that a short cycle has not been selected."
• 2000-08-15 Mark Wooding: "No, it only shows the cycle length for the sequence , not the sequence of parity bits."
• 2000-08-15 Mok-Kong Shen: "Sorry, I am really confused. 'Parity bits' or 'LSB'?"
• 2000-08-16 Terry Ritter: "The "parity" property to which BB&S refers is "odd vs. even," which is also the least-significant-bit (LSB) in binary representation."
• 2000-08-16 David Hopwood: "Either (they are equally secure)."
• 2000-08-16 Mark Wooding: "That's interesting to know."
• 2000-08-17 David Hopwood: "Oops, no they aren't (or at least this is not proven)."
• 2000-08-16 Mok-Kong Shen: "Is there any concrete relation between the quadratic residuacity assumption and the assumption of hardness of factoring N?"
• 2000-08-17 Mok-Kong Shen: ". . . I don't see where the argument 'finding short cycles is equivalent to factoring' . . . ."
• 2000-08-17 Mark Wooding: "Finding cycles permits prediction, and *all* prediction methods reduce to solving QRP, so there's no problem here."
• 2000-08-17 Mok-Kong Shen: "Unpredictablility to the right seems to be actually more useful, isn't it?"
• 2000-08-17 Mark Wooding: "I think that both are useful."
• 2000-08-17 Mok-Kong Shen: "If the main theorem does not involve cycle length and has firmly established the security issue, why does one (in particular BBS) has to bother to consider subsequently the cycle length question at all?"
• 2000-08-18 Mark Wooding: "Some people keep on bringing the subject up without any particularly good reason. The security proof, such as it is, applies regardless of any considerations about cycle lengths."
• 2000-08-18 David Hopwood: "OTOH, I don't think that the cycle length issue is a good motivation for choosing factors of special form (either the method using Lim-Lee primes, or the "special primes" defined in the BBS paper)."
• 2000-08-18 Mok-Kong Shen: "If the main theorem does not involve cycle length and has firmly established the security issue, why does one (in particular BBS) have to bother to consider subsequently the cycle length question at all?"
• 2000-08-17 Terry Ritter: "To allow short cycles is to let them be our minimum guaranteed strength."
• 2000-08-18 David Hopwood: "Moreover, "always unpredictable" is not necessary and was never claimed."
• 2000-08-20 D. J. Bernstein: "If you want to apply the theorems, you need _much_ larger values of N."
• 2000-08-21 Mok-Kong Shen: "Thank you very much for the valuable information."
• 2000-08-21 Mark Wooding: "Oh, do you have a pointer to Alexi-Chor-Goldreich-Schnorr?"
• 2000-08-24 Tim Tyler: "FWIW: two /possible/ papers at:"
• 2000-08-16 John Savard: "Since the BBS modulus can't be a power of two, I don't think you have to worry about that."
• 2000-08-16 Mok-Kong Shen: "Do I understand correctly that you claim that the cycle length of equals the cycle length of the parity bits . . . ?"
• 2000-08-16 John Savard: ". . . if the cycle length for the generator as a whole is pq . . . it IS clear that no other cycle length for the parity bit less than pq is possible."
• 2000-08-16 Mark Wooding: "Yes, but it isn't: it's a factor of \lambda(\lambda(n))." "Indeed, the difficulty of prediction implies the lack of bias as a trivial corollary."
• 2000-08-16 Mok-Kong Shen: "There are two points. First is the terminology."
• 2000-08-19 Tim Tyler: "I for one don't see how the nature of the BBS modulus might help prevent cycles in the low bits."
• 2000-08-20 Mok-Kong Shen: "BBS states only that the cycle length of LSB must divide the first mentioned cycle length but leaves the exact relationship between the two to be an open question."
• 2000-08-21 Mark Wooding: "You missed the bit where I explained exactly how the nature of the BBS modulus can prevent short cycles in the parity bit."
• 2000-08-22 Tim Tyler: "Yes, I definitely did."
• 2000-08-22 Mark Wooding: "I can't expect that everyone here reads every message I post. I can't even be bothered to read most of them, so I can't see why anyone else should, really. ;-)"
• 2000-08-16 Terry Ritter: "I got carried away on the old issue. Sorry."
• 2000-08-15 Mok-Kong Shen: "Does the phrase 'cycles of a given length' refer to cycles of the direct output of the congruence relation or does it refer to cycles of LSB."
• 2000-08-16 Terry Ritter: "My mistake, I was answering the old question."
• 2000-08- 8 Mok-Kong Shen: "The cycle length of LSB of the output definitely cannot be longer but can very probably be much shorter than the cycle length of the output itself."
• 2000-08- 9 Terry Ritter: "The LSB of the x^2 mod N result *is* the output of BB&S." "To the extent that there is a proof of BB&S, that proof must cover this situation, because this *is* BB&S."
• 2000-08- 9 Mok-Kong Shen: "I should very much appreciate it, if some expert would confirm that the issue is indeed well taken care of in the article of BBS . . . ."
• 2000-08- 9 lcs Mixmaster Remailer: "This is correct. It is frustrating that you have come so close here to understanding the position of those who have been arguing against you for so many years."
• 2000-08-10 Trevor L. Jackson, III: ". . . the system without a short cycle check does not promise the same theoretical security as a system with the check."
• 2000-08-10 Mark Wooding: "If finding X by trying very hard is impractically difficult, then finding X by accidentally tripping over it must be at least as difficult."
• 2000-08-10 Doug Kuhlman: "I want that X..."
• 2000-08-10 Mark Wooding: "It already runs on millions of Unix boxes..."
• 2000-08-10 Terry Ritter: "This is not about an algorithm for an attack. It is about leaving weakness in the signal we send. Just as it would not be acceptable to leave plaintext between our impossible-to-break ciphertext, it is also not acceptable to every once in a while have a breakable result that we can prevent. Calling that "proven secure" is just adding insult to the injury."
• 2000-08-10 Trevor L. Jackson, III: "Two conterclaims:"
• 2000-08-11 Mark Wooding: "I'm confused by your terminology."
• 2000-08-11 Trevor L. Jackson, III: ". . . I'll let this one die."
• 2000-08-11 David Hopwood: ". . . the impracticality of finding one on purpose *implies* that there is negligable probability of selecting one by accident . . . ."
• 2000-08-10 Terry Ritter: "That logic is wrong. If there is a possibility of choosing a short cycle, that *will* happen, sooner or later. Then the attacker *can* factor N, which contradicts the assumption."
• 2000-08-10 Doug Kuhlman: "You consistently confuse possibility with probability and claim that one is the other."
• 2000-08-10 Terry Ritter: "Possibility and probability are statistical terms. If something is *possible* under random selection, it eventually *will* *happen*."
• 2000-08-15 Doug Kuhlman: "The possibility of landing on a short cycle is the least of my concerns (about BBS)."
• 2000-08-15 Trevor L. Jackson, III: "Can you provide some number/formulae that describe the incidence of short cycles for a typical BBS generator?"
• 2000-08-16 Terry Ritter: "One of the advantages of analysis is to address things which are too infrequent to be detected reliably from experiment." "Any system which allows use of short cycles cannot be guaranteed to have any more strength than a short cycle, no matter what other theoretical advances may occur."
• 2000-08-10 Terry Ritter: "I DO NOT ACCEPT that a cryptosystem which has a known potential weakness can legitimately be called "proven secure.""
• 2000-08-10 Mok-Kong Shen: "With n=209, a cycle of length 4 (which I fould on my second trial) gives the LSB of 0000! Now this is certainly a toy example. But it is on the other hand definitely a warning . . . ."
• 2000-08-10 Guy Macon: "Hmmm. Those very rare chances again."
• 2000-08-10 Mok-Kong Shen: "I got the suspicion from David Molnar's information that for non-BBS moduli, i.e. not of the form 3 mod 4, he [often] got 01010101.... . Now it seems to me to be very reasonable to think that for BBS moduli, the same could happen through maybe not so often."
• 2000-08-10 Terry Ritter: "For the purposes of discussion we are willing to assume that factoring is difficult. Yet even *with* that assumption, the reduced BB&S without short-cycle checks will be weak occasionally."
• 2000-08-10 Mok-Kong Shen: ". . . in GENERAL one should replace in crypto discussions the term 'provably secure' with the long phrase I proposed, in order to prevent 'general' mis-interpretations."
• 2000-08-10 Terry Ritter: ". . . even if we do that we can't "guarantee" a secure system, and if not, then why use BB&S at all?"
• 2000-08-11 Mok-Kong Shen: ". . . one could say that the decision to use the full version of BBS corresponds to checking weak keys in block ciphers and hence a user who opts for checking weak keys should use the full version of BBS, if he behaves consistently."
• 2000-08-11 Bryan Olson: ". . . even if one does filter out short state cycles, one still has not proven a long output cycle." Ed note: This is presumably in the context of the LSB's question. The BB&S paper does prove a long known cycle length via the special primes construction.
• 2000-08-11 Mok-Kong Shen: "If we KNEW the output cycle of LSB to be long! But it is unfortunate that we don't yet know."
• 2000-08-13 Bryan Olson: "We do not know if factoring is hard in most cases, and a short cycle in the bit output is one of arbitrarily many defects that might happen (in the sense that we have not proven it can't) if factoring the modulus turns out to be easy."
• 2000-08-11 David Hopwood: "Proofs in this area of cryptology are generally probabilistic, but they are *not* statistical . . . ."
• 2000-08-11 Terry Ritter: "A distribution of values (here weakness) is a statistical entity." "When x0 values are selected at random they are random variables, which are definitely statistical entities" "The effect of random sampling from a distribution is inherently statistical in nature."
• 2000-08-11 Mok-Kong Shen: ". . . 'security proved under certain assumptions' is better in my view."
• 2000-08-10 Mark Wooding: "The proof not statistical. It states that the output of a BBS generator cannot be distibguished from random data by any polynomial-time test by an adversary who cannot decide quadratic residuosity."
• 2000-08-10 Mok-Kong Shen: "Would a LSB sequence of 000000..... or 010101..... be indistinguishable from random data or distinguishable?"
• 2000-08-10 Terry Ritter: "What we have here is a construction which leaks the solution, unless explicitly prevented. So the failure does *not* impact math theories. Which also implies that those same theories cannot be depended upon for reasoning about strength in this and similar situations."
• 2000-08-11 Mark Wooding: "But the proof doesn't say that BBS is *secure*. It's says that it's *as secure as factoring*."
• 2000-08-10 Trevor L. Jackson, III: "Is it your position that there are repeating decimals that have cycles so long that they are are indistinguishable from irrationals?"
• 2000-08-11 Bryan Olson: "For those who spent a lot of effort trying to convince Mr. Ritter that the cycle-length test didn't change the nature of the theorem, I expect that's as close to a concession as we're going to get." "Will he ever understand the rest?"
• 2000-08-11 David Hopwood: "OK, in that case you must not accept that BBS is proven secure at all, under any assumptions, and with or without the cycle checks."
• 2000-08-11 Terry Ritter: "I don't really have a view about whether BB&S is secure." "On the other hand, I *know* that any random number generator is insecure when it has traversed a cycle, and I *know* that short cycles do exist in BB&S. Thus, I *know* that failing to prevent the use of a short cycle is a risk." "But I also *know* the prescription in BB&S will prevent the use of short cycles, which makes the short cycle problem an unnecessary and preventable risk. So I *know* that "real" BB&S is arguably "strong*er*" than the "reduced" or "simplified" BB&S which does not check for short cycles."
• 2000-08-10 Tony T. Warnock: "The question is not whether it's infeasible to find a short cycle, it's whether it's feasible to find a long one."
• 2000-08-10 David Hopwood: "If it is infeasible to find a short cycle, then there is negligable probability that one will be picked at random. Therefore we don't need to specifically find a guaranteed long cycle; we can just pick a seed at random . . . ."
• 2000-08-10 lcs Mixmaster Remailer: "First, thanks to the reference to Vazirani&Vazirani. We can dispense with the awkward claim that BBS reduces to quadratic reciduosity, and simply say that it reduces to factoring. If you think you need to check for short cycles, then you think your opponent can factor your modulus by guessing cycles."
• 2000-08-10 Terry Ritter: "It is not true that factoring is unconditionally hard. Factoring is easy when a factor is leaked. That is what the reduced BB&S does when it uses a short cycle. So if we want to depend upon factoring being hard, we had better arrange to not use a short cycle."
• 2000-08-10 John Myre: "If an event has sufficiently low probability, then it is perfectly sane and reasonable to design a system assuming it will never happen."
• 2000-08-10 Terry Ritter: "The issue is "proof," and to understand that we need to know what happens in *every* case, not just a handwave representing the majority of cases. Claiming that reduced BB&S is secure in every x0 selection is obviously just plain wrong. Knowing that, we can see that the most the proof can possibly mean is that in *other* cases, BB&S is strong." "In practice, the whole reason for using BB&S is to get a proof of strength; most people probably think means that there simply are no weaknesses. Yet here we have a case -- and there is no reason to think that short cycles are the only case -- where the system *is* *unarguably* *insecure*, and that case is known but not even checked for. In this situation, a claim of "proven secure" would be inappropriate." "I suggest "proven almost never weak."
• 2000-08-10 John Myre: "Since short cycles can exist, the BBS strength claim cannot be interpreted as a guarantee that the opponent can never break any particular sequence. There is a way to eliminate some "weak" cases (by selecting the BBS parameters in the careful way defined in the BBS paper). In doing so, however, we do not get any better guarantee of strength, in the sense of the proofs in the BBS paper. It might in fact be better, but the guarantee isn't any better."
• 2000-08-11 Terry Ritter: "There really is no math involved. The issue is what is being claimed. If you think that what is claimed is security in every case, then the claim is wrong with the reduced system. If you think that what is being claimed is a probability of strength -- "almost always" security -- then the claim is probably right."
• 2000-08-14 Benjamin Goldberg: ". . . in your short cycle example (PQ=1081, and the cycle length 11, I believe), how do we learn the factors of PQ from the LSBs of that cycle?"
• 2000-08-14 Terry Ritter: "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. Given one such example, we have to ask if more exist. If then the answer is "No, because that would break math," we have to ask how the original problem could possibly exist in the first place. I think we are now coming to a consensus position in which cryptographic proof has far less practical import than most of us previously thought." "After thinking about these issues for the last day or so, I think that part of our problem ultimately stems from a language ambiguity in the word "assumption." In reality there is not just one but many necessary assumptions."
• 2000-08-11 lcs Mixmaster Remailer: "Since we've already established that no such checking is necessary for the second RSA system, it follows that no such checking is necessary for BBS."
• 2000-08-11 Trevor L. Jackson, III: "Up to this point I follow your argument, but at this point there's a gap."
• 2000-08-12 Trevor L. Jackson, III: "If I understand this correctly it amounts to a claim that a rational attacker will not test for short cycles because the effort expended, when discounted by the odds of success, does not get him any closer to cracking the system than an equivalent amount of effort invested in a QR search."
• 2000-08-12 Mok-Kong Shen: "Is the science of crypto entirely separated from psychology?"
• 2000-08-14 David Hopwood: ". . . an attacker that uses an inefficient method of factoring will not have any greater success probability (for a given amount of work) than one that uses a more efficient method."
• 2000-08-14 Tim Tyler: "What if the attacker has a dedicated, parallel, short-cycle testing machine - built for some other purpose - but only a general purpose serial computer for use in factoring?"
• 2000-08-14 Trevor L. Jackson, III: "So we should ignore the irrational ones who will cover all bases and thus crack messages by finding short cycles we've overlooked. I'd rather not over look them."
• 2000-08-14 Tony T. Warnock: "If a long stretch of zeros (length to be determined later) occured in a OTP, I would assume the generator was broken."
• 2000-08-14 Trevor L. Jackson, III: "The point seems to be that finding a short cycle in a BBS generator is not the product of a broken mechanism, but a predictable consequence of the underlying math. Since those consequences can be contained (described and rendered negligible mathematically) in a way that broken RNGs cannot, they can be ignored while the threat of a broken RNG cannot ever be ignored."
• 2000-08-14 Mok-Kong Shen: "I tend to partake your view."
• 2000-08-12 lcs Mixmaster Remailer: "All this worry about seeds "leaking" the factors is absurd, which the present analysis is intended to show."
• 2000-08-15 lcs Mixmaster Remailer: "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." "And of course if anyone were ever so foolish as to follow Terry Ritter's advice in implementing BBS, they would appear equally amateurish."
• 2000-08-15 Terry Ritter: ". . . 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."" "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."
• 2000-08- 7 Joseph Ashwood: "You act as if there is no question of the security of those systems."
• 2000-08- 4 Mark Wooding: "This is excellent work, thoroughly worth reading."
• 2000-08- 6 Benjamin Goldberg: "Makeing the factors congruent to 3 mod 4 isn't a specific prevention of short cycles?"
• 2000-08- 7 Terry Ritter: "Short cycles appear to be inherent in the construction."
• 2000-08- 8 Benjamin Goldberg: "Perhaps there is some relationship between P and Q we can test for which will avoid short cycles, which isn't part of the current parameter choosing process."
• 2000-08- 8 David Hopwood: "The factors of the modulus must be congruent to 3 mod 4 in order for the proofs in the BBS paper to apply. Note that this is entirely independent of the issue of short cycles."
• 2000-08- 7 Mark Wooding: "Short cycles will exist. In particular, the values 0, 1, p, and q lead to cycles of period 1."
• 2000-08- 8 David A Molnar: "A long time ago I built a BBS generator in Scheme. I found that there were varying cycle lengths when using a modulus n = p q with p and q congruent to 3 mod 4. When p or q were congruent to 1 mod 4, or not actually prime, then I ended up with an alternating 0-1-0-1-0-1 output."
• 2000-08- 9 Mok-Kong Shen: "Would the LSB of BBS, i.e. with p and q of the form 3 mod 4, have, on the other hand, very good statistical quality?"
• 2000-08- 9 Mok-Kong Shen: "I have just do an example with p=11, q=19, n=209. There is a cycle of length 4: (38, 190, 152, 114). Taking the LSB, we have all 0's."
• 2000-08-10 Tim Tyler: "A potentially useful observation."
• 2000-08-12 Benjamin Goldberg: "Your q isn't a Blum Integer, I don't think."
• 2000-08-12 Mok-Kong Shen: "p=11=2*4+3; q=19=4*4+3; are both Blum integers. But my example was no good. Here a (large) cycle of length 12:"
• 2000-08- 3 Tim Tyler: "Being hard to predict is a different thing to being /impossible/ to predict - which is what an ideal OTP ought to be." "For example an attacker can guess a BBS seed. If they get it right, reams of plausible plaintext will spew out - while if they don't it is /extremely/ unlikely to. This attack is impossible with a real OTP."
• 2000-08- 4 Grant Anderson: "Therefore, a CSPRNG which passes all the random tests and is indistinguishable from a "real" random source should be suitable . . . ." [Ed. Note: I think the point was that no deterministic RNG could possibly replace an OTP generator.]
• 2000-08- 3 Mack: "The basic answer to your question is that yes BBS is secure." "It isn't generally used because it is slow."
• 2000-08- 3 Mark Wooding: "Breaking the BBS is as hard as deciding quadratic residuosity. That's certainly no harder than factoring, because you can use factoring to decide quadratic residuosity . . . ."
• 2000-08- 3 Terry Ritter: "But being "no harder than factoring" is meaningless when an approach *allows* factoring." "The BB&S structure inherently includes both long and short cycles. If an opponent encounters a short cycle and identifies a repetition, they know the cycle length and can proceed to factor. Thus, use of a short cycle can expose the system to factoring."
• 2000-08- 3 Mark Wooding: "The security warranty works regardless, as long as the modulus is a Blum integer."
• 2000-08- 3 Terry Ritter: "When factoring is easy, "breaking" BB&S is easy. And factoring *is* easy when someone uses a short cycle." "The "security warranty" is that BB&S is secure... AS LONG AS FACTORING IS HARD. But factoring is NOT always hard. For example, Factoring is not hard if we give away one of the factors. And that is exactly what we do when we use a short cycle."
• 2000-08- 3 Tim Tyler: "There are other ways to improve the security of this system, besides weeding out short cycles."
• 2000-08- 7 Terry Ritter: "The theoretical strength guarantees certainly do not prevent us from choosing or using a weak short cycle. At best, they just say that such an event is "unlikely." And they say that whether we have checked for short cycles or not. The theory is thus unresponsive to both the presence of a real risk, and its elimination. That means the theory cannot be relied upon as an indication of security."
• 2000-08- 7 Mok-Kong Shen: "Not infrequently proofs are based on yet unproved number theoretical conjectures."
• 2000-08-10 Tim Tyler: "Even /after/ any surgery to remove short cycles, the BBS is never going to become "absolutely secure" - and we will still be able to make it stronger by "our own action"."
• 2000-08-10 Mok-Kong Shen: "See my follow-up . . . ."
• 2000-08-10 Terry Ritter: "It is *not* sufficient that the assumptions be true: Even when the assumptions *are* true, BB&S *still* is weak every now and then."
• 2000-08-13 Bryan Olson: "When you allow the defect might appear, you allow that factoring might be easy and have contradicted the premise."
• 2000-08-13 Terry Ritter: "Since "pretend" BB&S does *not* check for short cycle operation, it allows the defect to occur. By not checking, it does not help assure that the assumption ("factoring is hard") holds, which means that "pretend" BB&S has the potential weakness of using a short cycle *in* *addition* to any other weaknesses it may have."
• 2000-08-13 Bryan Olson: "The BBS security assumption is that the attacker cannot factor the modulus when given the modulus. (Though in practice we would not give him the modulus.) Giving him generator output, starting from a random point, cannot increase the chance he could violate the assumption, since he can start generators at all the random points he wants."
• 2000-08-14 Terry Ritter: "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. But whether factoring is hard or not, short cycles do exist anyway." "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."
• 2000-08-15 Bryan Olson: "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."
• 2000-08-19 Tim Tyler: "As I understand it, we know that attempts to factor the modulus are a better attack on BBS than brute force seed search - so the system already falls short of what is possible in terms of security."
• 2000-08-19 Mok-Kong Shen: "Most instances of the so-called 'provable security' involve assumptions."
• 2000-08-14 Mok-Kong Shen: ". . . Since some large numbers are evidently easy to factor, what does an assumption of hardness of factoring (without further qualifications) imply?"
• 2000-08-14 Mark Wooding: "Depends who you talk to. Some will waffle on about strong primes' and suchlike; others will tell you just to generate random primes. I think that the random primes people are right."
• 2000-08-14 Mok-Kong Shen: "Could you conceive of any possibility of ever formally characterizing the 'most difficult sort of composite numbers'?"
• 2000-08-14 lordcow77: ". . . the products of two random primes of the same length."
• 2000-08-15 Mark Wooding: "Our understanding of what numbers are particularly hard to factor will change as we get better at factoring, and it will change in an unpredictable way."
• 2000-08- 4 Bryan Olson: "The scheme without the long cycle test is secure in the same sense as the scheme with the test."
• 2000-08- 7 Terry Ritter: "There is [. . .] 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?"
• 2000-08- 7 Mok-Kong Shen: "I have the impression that, excepting OTP, most cases of 'proven strength' seem to be just that."
• 2000-08- 7 Joseph Ashwood: 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 [. . .], then one can rely on the security proof."
• 2000-08- 7 Bryan Olson: "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."
• 2000-08- 8 Mok-Kong Shen: "You can point out the false logic here."
• 2000-08- 8 Bryan Olson: ". . . cryptographic security properties apply to the system with its key space, not to particular choices of key. Even if we obtain proof of the conjectures, that factoring is hard in general would not imply that every large number will be unfactorable."
• 2000-08-14 Tim Tyler: "This case still seems totally different from the case of using BBS with short cycles."
• 2000-08-14 Terry Ritter: "This whole discussion is theoretical, generally addressing the meaning of cryptographic proof. I'm unaware of any controversy about the idea that cycles theoretically could be detected easily."
• 2000-08-15 John Savard: "Since there is a 'mathematical proof' that the output of a BBS generator is "hard" to predict, in the same sense that breaking some public-key ciphers is known to be "hard" [...], I would, however, have to conclude that it is also a proof that a BBS generator cannot produce only a short cycle . . . ."
• 2000-08-16 David Hopwood: "There is no potential lead in."
• 2000-08-16 Terry Ritter: "Right."
• 2000-08-15 Bryan Olson: "The issue that secrecy comes from the keyspace and not the key applies to all secrecy systems."
• 2000-08-15 John Savard: "How can we take the undeniable truths of mathematics, and the practical facts of common-sense, and show that they don't really contradict each other?"
• 2000-08-15 Mok-Kong Shen: "I think that one has at this point remember that (an ideal) OTP is only a theoretical model and that in practice we adopt practical means that we (with more or less subjectivity) consider to be appropriate."
• 2000-08-17 Tim Tyler: "Imagine a rare spy, who - after landing in enemy territory - opens up his OTP and prepares to report that his espionage mission began successfully. Scanning the pages, he finds all the symbols are zeros. Imagine his dismay ;-)"
• 2000-08-17 Mok-Kong Shen: "Why? If the spy knows that his agency has given him a true OTP and he also happens to be a crypto theoretician, he will not hesitate a micro-second before applying the pad!"
• 2000-08-18 Trevor L. Jackson, III: "Is the message as secure if he does not calculate the ciphertext produced by the null pad and simply sends the plaintext?"
• 2000-08-19 Mok-Kong Shen: ". . . the spy, having FULL belief on the impeacability of the theory, should do his routine encryption processing with the pad and send the message."
• 2000-08-19 Trevor L. Jackson, III: "In principle, one can rely upon the source to produce the output it is designed to produce. But when one encouters an artifact, even an expected one, the urge to apply quality control to the output becomes intense."
• 2000-08-20 Mok-Kong Shen: "If we let the source generate a large amount of such sequences, we can see whether the distribution of these values sufficiently well correspond to that of an ideal random source. If we do the same for all statistical tests available, we can have indeed a quite good feeling of the quality of the source in my humble view."
• 2000-08-19 Douglas A. Gwyn: ". . . it is not the *data* that might be random, but the *process* that generates it. It is thus better to consider the property of "randomness" as meaning agreement with a specific source model."
• 2000-08-20 Mok-Kong Shen: "Right."
• 2000-08-20 Douglas A. Gwyn: ". . . for many people it might be *easier* to implement the algorithm and run some standard tests (e.g. Diehard), but that doesn't make it the best way to gain confidence in the patternlessness of the output from the algorithm."
• 2000-08-20 Mok-Kong Shen: ". . . a theory almost without exception is based on assumptions which are simplifications/approximations of the real world . . . ."
• 2000-08-21 Bryan Olson: "How could that ever hold?"
• 2000-08-21 Mok-Kong Shen: ". . . there be no practical means of knowing that a given source indeed produces an ideal OTP, as far as I am aware."
• 2000-08-21 Bryan Olson: "The question is how could it be zero."
• 2000-08-21 Mok-Kong Shen: ". . . before the timepoint where his huge neuronal network starts to compose the message, even the spy himself doesn't know what that message is. So I think that justifies to ascribe a probability 0.
• 2000-08-21 Bryan Olson: "That justifies "small" or even "negligible"." "Zero is wrong."
• 2000-08-21 Mok-Kong Shen: "Then kindly give me an example of yours that can serve to illustrate a probability of measure zero so that we could have a compararison."
• 2000-08-22 Bryan Olson: "Uh, O.K: Let m be any message space, and s the sum of the probabilities of all messages in m. Consider the probability that s does not equal one."
• 2000-08-22 Mok-Kong Shen: "First of all I don't yet see how you were answering to my question . . . ."
• 2000-08-21 Bryan Olson: ". . . claiming it's secure in the case when one chooses the zero key is wrong. It is not the individual cases that are secure - secrecy is only provable for the set of cases with their probabilities."
• 2000-08-17 Tim Tyler: " Another issue might be that rejecting short cycles appears to decrease the size of the keyspace. Has anyone yet proposed that rejecting these seeds is a cause of loss of strength? ;-)"
• 2000-08-16 Paul Pires: ". . . if you conceed that the occurance is exceedingly rare it does not seem as if it could be a meaningful reduction. A theoretical weakness without practical repercussions?"
• 2000-08-17 Mok-Kong Shen: "So it appears that in the proof of security of OTP one needs an additional assumption:"
• 2000-08-21 Bryan Olson: "The proof holds for the keyspace, so the assumption is the worst case and any violation can only hurt the attacker."
• 2000-08-18 David Hopwood: "I thought about that, and concluded that it doesn't."
• 2000-08-18 David Hopwood: "... except that the distribution of moduli is different, of course."
• 2000-08- 7 Bryan Olson: "The proof - without the long cycle test - deals with _all_ algorithmic methods of predicting the generator."
• 2000-08- 8 Mok-Kong Shen: "As someone has pointed out . . . , the term 'provable security' is misleading in almost all applied instances."
• 2000-08- 3 Mack: "BBS uses one squaring. RSA uses one squaring and one multiplication."
• 2000-08- 4 Tim Tyler: "It looks like you're both right ;-)"
• 2000-08- 3 Mark Wooding: "It *is* acceptable. The Blum-Goldwasser probabiliistic encryption algorithm is based on this very same idea."
• 2000-08- 3 Scott Nelson: ". . . a pad derived from BBS is just another stream cipher, and it shouldn't be called a one time pad."
• 2000-08- 3 Joseph Ashwood: "For a OTP the requirements are very strict, and generally unachievable. The most important one for this discussion is that each bit of the key stream must have an entropy content of 1 bit."

Subject: OTP using BBS generator?
Date: Thu, 03 Aug 2000 15:48:42 +1200
From: Grant Anderson <grant_anderson@supreme-overlord.com>
Message-ID: <3988EB99.29597754@supreme-overlord.com>
Newsgroups: sci.crypt
Lines: 28

I know there has been much discussion about (supposed) OTP ciphers and
how
most of them generally don't fulfil the OTP requirements. What I don't
understand is why the use of the blum-blum-shub generator as the  pad
isn't acceptable? I have read a great deal about the characteristics of
the BBS generator and it *seems* secure as "random-number" generators
go.

Assuming that each individual has a private key pair (two large primes)
p
and q and a public key n such that p x q = n, then the BBS generator
creates bits by:

x(i)=x^2 mod n for each i

Now obviously you can't use the same pad twice, so you would need to do
something like having a central repository (the keyserver for example)
which remembers the last "i" value for each user. So when you want to
encrypt for user A, you contact the keyserver and obtain their  public
key
(n) and the initialisation value i and start generating from i+1....

What is wrong with this solution?

Cheers,
Grant Anderson.

Subject: Re: OTP using BBS generator?
Date: 03 Aug 2000 05:18:06 GMT
From: macckone@aol.comnjunk123 (Mack)
Message-ID: <20000803011806.18934.00000762@ng-cl1.aol.com>
References: <3988EC4E.9555D120@supreme-overlord.com>
Newsgroups: sci.crypt
Lines: 6

The basic problem with the BBS
is that it is very slow.

Mack
Remove njunk123 from name to reply by e-mail

Bytes: 1216

Subject: Re: OTP using BBS generator?
Date: Thu, 03 Aug 2000 07:01:49 -0700
From: lordcow77 <london222NOloSPAM@netzero.com.invalid>
Message-ID: <0ebe7ce0.c2ca4460@usw-ex0105-040.remarq.com>
References: <39891A4E.110D7318@t-online.de>
<398912AD.1A01F46C@supreme-overlord.com>
<20000803011806.18934.00000762@ng-cl1.aol.com>
Newsgroups: sci.crypt
Lines: 27

Mok-Kong Shen <mok-kong.shen@t-online.de> wrote:
>BBS has been a recurring topic in this group. I have little
>knowledge in that but I have the impression that discussions
>about it never led to unanimously accepted results. You
>may try to look into old postings of this group.
>

Wrong. Practically everyone accepts that choosing the factors of
the modulus to be congruent to 3 mod 4 and picking a random
starting point are enough to ensure that the resulting BBS
sequence will be secure, based on the computational equivalence
of predicting BBS and deciding quadratic residuosity (and
therefore factoring). Terry Ritter is the only proponent of the
position that one must take elaborate steps to ensure that one
falls into a guaranteed long cycle on the basis of a
misunderstanding of the security proof given by Blum, Blum, and
Shub and a desire to assert that no cipher can be proven to be
secure under reasonable assumptions, such that he can promote
his own products that "stack" multiple patented algorithms
together.

-----------------------------------------------------------

Got questions?  Get answers over the phone at Keen.com.
Up to 100 minutes free!
http://www.keen.com

Subject: Re: OTP using BBS generator?
Date: 3 Aug 2000 16:51:50 GMT
From: mdw@nsict.org (Mark Wooding)
Message-ID: <slrn8oj8p6.26s.mdw@mull.ncipher.com>
References: <0ebe7ce0.c2ca4460@usw-ex0105-040.remarq.com>
Newsgroups: sci.crypt
Lines: 10

lordcow77 <london222NOloSPAM@netzero.com.invalid> wrote:

> based on the computational equivalence of predicting BBS and deciding
> quadratic residuosity (and therefore factoring).

I don't mean to detract from your main point, with which I agree, but I
wasn't aware that it was proven that factoring can polytime reduce to
QRP.  Can you provide a reference?

-- [mdw]

Subject: Re: OTP using BBS generator?
Date: Thu, 03 Aug 2000 10:27:22 -0700
From: lordcow77 <london222NOloSPAM@netzero.com.invalid>
Message-ID: <29f3bf00.9eba152b@usw-ex0103-018.remarq.com>
References: <slrn8oj8p6.26s.mdw@mull.ncipher.com>
Newsgroups: sci.crypt
Lines: 20

mdw@nsict.org (Mark Wooding) wrote:
>lordcow77 <london222NOloSPAM@netzero.com.invalid> wrote:
>
>I don't mean to detract from your main point, with which I
agree, but I
>wasn't aware that it was proven that factoring can polytime
reduce to
>QRP.  Can you provide a reference?
>

A proof would be a surprise to me as well :-) QRP polytime
reduces to IFP, although I haven't seen anything proven on a
polytime reduction from IFP to QRP.

-----------------------------------------------------------

Got questions?  Get answers over the phone at Keen.com.
Up to 100 minutes free!
http://www.keen.com

Subject: Re: OTP using BBS generator?
Date: Thu, 03 Aug 2000 18:52:29 +0200
From: Mok-Kong Shen <mok-kong.shen@t-online.de>
Message-ID: <3989A34D.A55FAC70@t-online.de>
References: <0ebe7ce0.c2ca4460@usw-ex0105-040.remarq.com>
Newsgroups: sci.crypt
Lines: 36

lordcow77 wrote:
>
> Mok-Kong Shen <mok-kong.shen@t-online.de> wrote:
> >BBS has been a recurring topic in this group. I have little
> >knowledge in that but I have the impression that discussions
> >about it never led to unanimously accepted results. You
> >may try to look into old postings of this group.
> >
>
> Wrong. Practically everyone accepts that choosing the factors of
> the modulus to be congruent to 3 mod 4 and picking a random
> starting point are enough to ensure that the resulting BBS
> sequence will be secure, based on the computational equivalence
> of predicting BBS and deciding quadratic residuosity (and
> therefore factoring). Terry Ritter is the only proponent of the
> position that one must take elaborate steps to ensure that one
> falls into a guaranteed long cycle on the basis of a
> misunderstanding of the security proof given by Blum, Blum, and
> Shub and a desire to assert that no cipher can be proven to be
> secure under reasonable assumptions, such that he can promote
> his own products that "stack" multiple patented algorithms
> together.

For one that does not have expert knowledge in BBS, like me,
it seems unfortunately to be difficult to know from the materials
of past discussions in the group alone whether one party is
absolutly right and the other absulutely wrong. Perhaps this is
a consequence of the fact that crypto is a subtle art. (BTW,
multiple encryption is not an invention of Terry Ritter but is
well-known since earlier times of cryptography. Shannon also
treated a series of three ciphers in one of his papers. There
seems to be no reason why one should neglect that potential
device of cryptography in my humble view.)

M. K. Shen

Subject: Re: OTP using BBS generator?
Date: Fri, 04 Aug 2000 05:42:07 GMT
From: Bryan Olson <bryanolson@my-deja.com>
Message-ID: <8mdl3f$3ah$1@nnrp1.deja.com>
References: <3989A34D.A55FAC70@t-online.de>
Newsgroups: sci.crypt
Lines: 26

Mok-Kong Shen
> For one that does not have expert knowledge in BBS, like me,
> it seems unfortunately to be difficult to know from the materials
> of past discussions in the group alone whether one party is
> absolutly right and the other absulutely wrong.

So look it up.  Surely anyone can recognize the utter
slyness of the claims that the reason the major current
references don't include the long-cycle test in their
description of the generator is that the authors have simply
not read the whole paper.  One could study the math and
understand why, for example HAC, describes the simpler form
of the generator; but only modest skill should enable one to
recognize that the author are not lazy nor careless, they do
understand the material, and that there's no evidence that
these allegations are other than fabrications.

--Bryan
--
email: bolson at certicom dot com

Sent via Deja.com http://www.deja.com/
Before you buy.

Subject: Re: OTP using BBS generator?
Date: Fri, 04 Aug 2000 11:49:35 +0200
From: Mok-Kong Shen <mok-kong.shen@t-online.de>
Message-ID: <398A91AF.51504A25@t-online.de>
References: <8mdl3f$3ah$1@nnrp1.deja.com>
Newsgroups: sci.crypt
Lines: 31

Bryan Olson wrote:
>
> Mok-Kong Shen wrote:
> > For one that does not have expert knowledge in BBS, like me,
> > it seems unfortunately to be difficult to know from the materials
> > of past discussions in the group alone whether one party is
> > absolutly right and the other absulutely wrong.
>
> So look it up.  Surely anyone can recognize the utter
> slyness of the claims that the reason the major current
> references don't include the long-cycle test in their
> description of the generator is that the authors have simply
> not read the whole paper.  One could study the math and
> understand why, for example HAC, describes the simpler form
> of the generator; but only modest skill should enable one to
> recognize that the author are not lazy nor careless, they do
> understand the material, and that there's no evidence that
> these allegations are other than fabrications.

I am afraid either the phrase 'but only modest skill should
enable one to recognize that the author are not lazy nor
careless' is not objective or you are demanding a skill that
you condider to be modest but actually is not for the average
people. If only the simpler form is described in a book and
nothing else, how can a reader recognize laziness/carelessness
of its author or its opposite, excepting through reading the
original article of BBS?

M. K. Shen

Subject: Re: OTP using BBS generator?
Date: Tue, 08 Aug 2000 04:19:51 GMT
From: Bryan Olson <bryanolson@my-deja.com>
Message-ID: <8mo1p4$8a9$1@nnrp1.deja.com>
References: <398A91AF.51504A25@t-online.de>
Newsgroups: sci.crypt
Lines: 22

Mok-Kong Shen wrote:
> Bryan Olson wrote:
> I am afraid either the phrase 'but only modest skill should
> enable one to recognize that the author are not lazy nor
> careless' is not objective or you are demanding a skill that
> you condider to be modest but actually is not for the average
> people.

I suppose you are right that one will not be able to tell,
given that he is both unwilling to deeply study the material
for himself, and cannot trust the consensus of experts if
there is one claim, even completely unsubstantiated, against
them.

--Bryan
--
email: bolson at certicom dot com

Sent via Deja.com http://www.deja.com/
Before you buy.

Subject: Re: OTP using BBS generator?
Date: Tue, 08 Aug 2000 08:25:20 +0200
From: Mok-Kong Shen <mok-kong.shen@t-online.de>
Message-ID: <398FA7D0.A06E656A@t-online.de>
References: <8mo1p4$8a9$1@nnrp1.deja.com>
Newsgroups: sci.crypt
Lines: 43

Bryan Olson wrote:
>
> Mok-Kong Shen wrote:
> > Bryan Olson wrote:
> > I am afraid either the phrase 'but only modest skill should
> > enable one to recognize that the author are not lazy nor
> > careless' is not objective or you are demanding a skill that
> > you condider to be modest but actually is not for the average
> > people.
>
> I suppose you are right that one will not be able to tell,
> given that he is both unwilling to deeply study the material
> for himself, and cannot trust the consensus of experts if
> there is one claim, even completely unsubstantiated, against
> them.

The real problem is that those, who are able to fully
understand the original paper of BBS, probably wouldn't
stay long with this thread and watch the heated debate
and those, who are not, can (by definition) get nothing
definite from a deep study, no matter how deeply they
try. As to trusting experts, there is the problem of
knowing who are the genuine experts and one risks being
involved in a 'religious' issue. (Indeed, there exists
at least one person on earth who by definition can't
err. But unfortunately he is not in our group.) If
there are two persons who have opposite opinions and
both claim to have expert knowledge, whom should one
trust??

BTW, BBS has been recurring many times in our group.
I sincerely hope that this time the experts discussing
here will conduct their disputes to a 'bitter end',
giving a CLEAR result for the observing non-experts
(with one party explictly conceding to be defeated),
such that, if anyone later once more posts questions
about BBS in the group, a simply pointer could be made
to that result. It's no longer fun reading the same
dispute stuff for the fifth or more times.

M. K. Shen

Subject: Re: OTP using BBS generator?
Date: Thu, 03 Aug 2000 19:06:19 GMT
From: ritter@io.com (Terry Ritter)
Message-ID: <3989c299.4078028@news.io.com>
References: <0ebe7ce0.c2ca4460@usw-ex0105-040.remarq.com>
Newsgroups: sci.crypt
Lines: 74

On Thu, 03 Aug 2000 07:01:49 -0700, in
<0ebe7ce0.c2ca4460@usw-ex0105-040.remarq.com>, in sci.crypt lordcow77
<london222NOloSPAM@netzero.com.invalid> wrote:

>Mok-Kong Shen <mok-kong.shen@t-online.de> wrote:
>>BBS has been a recurring topic in this group. I have little
>>knowledge in that but I have the impression that discussions
>>about it never led to unanimously accepted results. You
>>may try to look into old postings of this group.
>>
>
>Wrong. Practically everyone accepts that choosing the factors of
>the modulus to be congruent to 3 mod 4 and picking a random
>starting point are enough to ensure that the resulting BBS
>sequence will be secure, based on the computational equivalence
>of predicting BBS and deciding quadratic residuosity (and
>therefore factoring).

That is false on its face.  You can accept if you want, however.

It is true that using a short cycle would be extremely unlikely.  But
*when* that event occurs, all the math proofs you have will not save
you, since the resulting system is insecure.

Using a short cycle is unarguably insecure.  And, unless we
specifically prevent it, using a short cycle is an unarguable
possibility.

The only valid argument here is that using a short cycle would be
extremely unlikely, and that is no conflict, because I agree.

>Terry Ritter is the only proponent of the
>position that one must take elaborate steps to ensure that one
>falls into a guaranteed long cycle on the basis of a
>misunderstanding of the security proof given by Blum, Blum, and
>Shub and a desire to assert that no cipher can be proven to be
>secure under reasonable assumptions, such that he can promote
>his own products that "stack" multiple patented algorithms
>together.

Alas for the attempt at a personal attack, I have no current
"products" in that sense.  I do hold current patents which represent
fundamentally new cryptographic technology.  You can like that or you
can hate it, but I own the technology anyway.

Does the fact that I might make money out of improving technology
somehow make me suspect for pointing out the problems in other
approaches?  Finding the problems is why I have better approaches.
But I may be one of the few authors and designers who actively seeks
negative comments and then publishes those on my pages, as readers can
attest.

My stuff is not intended to replace BB&S or PK, but if they have
problems that I see, I'm going to say so, independent of whether I can
profit from that or not.

I have been doing this for the better part of a decade, and I don't
need to have my motives questioned.  By pointing out problems, others
can make their own informed choices about how to solve those problems
or perhaps use something else.  My patented technology provides
alternatives which others may weigh against the price of its use.

For free, I offer a 400K Crypto Glossary, plus a free Introduction to
Cryptography, Literature Surveys also free, plus lots of other stuff.
You don't have to buy a book to read my stuff, but if you want to read
it in a library, you can do that too, on any Web terminal.

---
Terry Ritter   ritter@io.com   http://www.io.com/~ritter/
Crypto Glossary   http://www.io.com/~ritter/GLOSSARY.HTM

Subject: Re: OTP using BBS generator?
Date: Thu, 3 Aug 2000 12:44:56 -0700
From: "Paul Pires" <diodude@got.net>
Message-ID: <5%ji5.14708\$GS1.250965@news-west.usenetserver.com>
References: <3989c299.4078028@news.io.com>
Newsgroups: sci.crypt
Lines: 88

Terry Ritter <ritter@io.com> wrote in message
news:3989c299.4078028@news.io.com...
>
> On Thu, 03 Aug 2000 07:01:49 -0700, in
> <0ebe7ce0.c2ca4460@usw-ex0105-040.remarq.com>, in sci.crypt lordcow77
> <london222NOloSPAM@netzero.com.invalid> wrote:
>
> >Mok-Kong Shen <mok-kong.shen@t-online.de> wrote:
> >>BBS has been a recurring topic in this group. I have little
> >>knowledge in that but I have the impression that discussions
> >>about it never led to unanimously accepted results. You
> >>may try to look into old postings of this group.
> >>
> >
> >Wrong. Practically everyone accepts that choosing the factors of
> >the modulus to be congruent to 3 mod 4 and picking a random
> >starting point are enough to ensure that the resulting BBS
> >sequence will be secure, based on the computational equivalence
> >of predicting BBS and deciding quadratic residuosity (and
> >therefore factoring).
>
> That is false on its face.  You can accept if you want, however.
>
> It is true that using a short cycle would be extremely unlikely.  But
> *when* that event occurs, all the math proofs you have will not save
> you, since the resulting system is insecure.
>
> Using a short cycle is unarguably insecure.  And, unless we
> specifically prevent it, using a short cycle is an unarguable
> possibility.
>
> The only valid argument here is that using a short cycle would be
> extremely unlikely, and that is no conflict, because I agree.
>
>
> >Terry Ritter is the only proponent of the
> >position that one must take elaborate steps to ensure that one
> >falls into a guaranteed long cycle on the basis of a
> >misunderstanding of the security proof given by Blum, Blum, and
> >Shub and a desire to assert that no cipher can be proven to be
> >secure under reasonable assumptions, such that he can promote
> >his own products that "stack" multiple patented algorithms
> >together.
>
> Alas for the attempt at a personal attack, I have no current
> "products" in that sense.  I do hold current patents which represent
> fundamentally new cryptographic technology.  You can like that or you
> can hate it, but I own the technology anyway.
>
> Does the fact that I might make money out of improving technology
> somehow make me suspect for pointing out the problems in other
> approaches?  Finding the problems is why I have better approaches.
> But I may be one of the few authors and designers who actively seeks
> negative comments and then publishes those on my pages, as readers can
> attest.
>
> My stuff is not intended to replace BB&S or PK, but if they have
> problems that I see, I'm going to say so, independent of whether I can
> profit from that or not.
>
> I have been doing this for the better part of a decade, and I don't
> need to have my motives questioned.  By pointing out problems, others
> can make their own informed choices about how to solve those problems
> or perhaps use something else.  My patented technology provides
> alternatives which others may weigh against the price of its use.
>
> For free, I offer a 400K Crypto Glossary, plus a free Introduction to
> Cryptography, Literature Surveys also free, plus lots of other stuff.
> You don't have to buy a book to read my stuff, but if you want to read
> it in a library, you can do that too, on any Web terminal.

Well said. I wish that I could be that generous in defending against
nonsensical attacks. The problem with taking the high ground in an argument
is that you must scale it first. I'll keep climbing.

Thanks for the example.

Paul

>
> ---
> Terry Ritter   ritter@io.com   http://www.io.com/~ritter/
> Crypto Glossary   http://www.io.com/~ritter/GLOSSARY.HTM
>
>

Subject: Re: OTP using BBS generator?
Date: Thu, 3 Aug 2000 14:12:01 -0700
From: "Joseph Ashwood" <ashwood@msn.com>
Message-ID: <O#qg39Y$$GA.585@cpmsnbbsa08> References: <3989c299.4078028@news.io.com> Newsgroups: sci.crypt Lines: 19 I know I'm arriving rather late to the party but, while Mr Ritter and I have been on differing sides of discussions before, I agree with him completely in this case. What he has suggested is to verify the lack of a short cycle, through a relatively cheap mechanism (certainly cheaper than the compromised security that could result is that check would have been failed). I find this to be solid reasoning, and something that should be done by anyone making use of BBS in this fashion. On a more personal note, I've noticed that this conversation has drifted towards being personal insults, please try to remember that Mr Ritter has been a long standing member of this group, and has build a quite solid, respected position, all you are doing is harming your credibiltity, as can be rather easily seen by looking at Mr Ritter's response, which was to the best of my knowledge completely factual, and dealt more with the issue at hand than his attacker. Joe Subject: Re: OTP using BBS generator? Date: 04 Aug 2000 00:43:36 GMT From: macckone@aol.comnjunk123 (Mack) Message-ID: <20000803204336.05175.00000707@ng-fe1.aol.com> References: <O#qg39Y$$GA.585@cpmsnbbsa08>
Newsgroups: sci.crypt
Lines: 36

>I know I'm arriving rather late to the party but, while Mr Ritter and I have
>been on differing sides of discussions before, I agree with him completely
>in this case. What he has suggested is to verify the lack of a short cycle,
>through a relatively cheap mechanism (certainly cheaper than the compromised
>security that could result is that check would have been failed). I find
>this to be solid reasoning, and something that should be done by anyone
>making use of BBS in this fashion.
>
>On a more personal note, I've noticed that this conversation has drifted
>towards being personal insults, please try to remember that Mr Ritter has
>been a long standing member of this group, and has build a quite solid,
>respected position, all you are doing is harming your credibiltity, as can
>be rather easily seen by looking at Mr Ritter's response, which was to the
>best of my knowledge completely factual, and dealt more with the issue at
>hand than his attacker.
>                Joe
>
>

I agree with Terry Ritter also.  There are several types of cycles
possible with the BBS generator.  It is important that the
primes used be "special".  In that case the cycle will be two or
we have found a multiple of a factor of N for a short cycle.  It is
easy to check for both of these conditions.

Using a single bit from each X increases the chance of the cycle
of the output being two by a great deal, does anyone have an
analysis of how often this occurs?

Mack
Remove njunk123 from name to reply by e-mail

Subject: Re: OTP using BBS generator?
Date: Sat, 05 Aug 2000 18:38:36 +0100
From: David Hopwood <hopwood@zetnet.co.uk>
Message-ID: <398C511C.77C8210D@zetnet.co.uk>
References: <O#qg39Y$$GA.585@cpmsnbbsa08> Newsgroups: sci.crypt Lines: 48 -----BEGIN PGP SIGNED MESSAGE----- Joseph Ashwood wrote: > I know I'm arriving rather late to the party but, while Mr Ritter and I have > been on differing sides of discussions before, I agree with him completely > in this case. What he has suggested is to verify the lack of a short cycle, > through a relatively cheap mechanism (certainly cheaper than the compromised > security that could result is that check would have been failed). It's not particularly cheap in terms of the speed of parameter generation, and it has been proven that short cycles happen with negligable probability, if the parameter sizes are such that factoring is hard. The probability of weakness is not changed significantly by applying the constraints that Ritter thinks are necessary; as has been pointed out repeatedly, his arguments are based on a misunderstanding of the BBS security proofs. > I find this to be solid reasoning, and something that should be done by > anyone making use of BBS in this fashion. 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. - -- David Hopwood <hopwood@zetnet.co.uk> Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/ RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01 Nothing in this message is intended to be legally binding. If I revoke a public key but refuse to specify why, it is because the private key has been seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv iQEVAwUBOYxQ5jkCAxeYt5gVAQGerAgAr0jXT3fyZFVkFZVdCoXu2AR4Ur+BdIzt 0F1gYbwODTSpFjeovdJTKwT18blRYwiHZyZL+z6H8ob/XYJS0OH67szO8IJbWzBL Ulchhw60m5wExA617AQ6JOwheKTkfxJsUErhY62b3ojFWOmviI/Z6M2HpQ3gz0bP yTb1IOoGNuikKcqt6xCqG51vswGtp5FX+Lpv34fW8AApD/Um+GR4jrbYAyHUgB8z 18g0Dg67TlLMDdQsxqy50VBzgWF/tJEyz4YoWj142Dzeh8GQhoZd/Aoygar4cJ2x an3agDB4WQUFjGQCSJ0xBAuONP7U6x7mdAMZqBnY1EOEcynmypUDwg== =AqMi -----END PGP SIGNATURE----- Subject: Re: OTP using BBS generator? Date: Sun, 06 Aug 2000 19:51:57 +0200 From: Mok-Kong Shen <mok-kong.shen@t-online.de> Message-ID: <398DA5BD.73A73CE@t-online.de> References: <398C511C.77C8210D@zetnet.co.uk> Newsgroups: sci.crypt Lines: 33 David Hopwood wrote: > > Joseph Ashwood wrote: > > I know I'm arriving rather late to the party but, while Mr Ritter and I have > > been on differing sides of discussions before, I agree with him completely > > in this case. What he has suggested is to verify the lack of a short cycle, > > through a relatively cheap mechanism (certainly cheaper than the compromised > > security that could result is that check would have been failed). > > It's not particularly cheap in terms of the speed of parameter generation, > and it has been proven that short cycles happen with negligable probability, > if the parameter sizes are such that factoring is hard. > > The probability of weakness is not changed significantly by applying the > constraints that Ritter thinks are necessary; as has been pointed out > repeatedly, his arguments are based on a misunderstanding of the BBS > security proofs. Scott Nelson said in his follow-up: One Time Pad is more a theoretical than practical encryption. To be theoretically perfect, it requires perfect random numbers for the pad. BBS is at best pseudo random, therefore can, at best, offer pseudo security. Thus if, in analogy, we equate OTP to infinity, then BBS is a very large (but finite) number. Subtracting a small number from a very large number gives still a very large (but finite) number. Does this analogy capture the essence of what you said? Thanks. M. K. Shen Subject: Re: OTP using BBS generator? Date: Mon, 07 Aug 2000 04:50:14 GMT From: ritter@io.com (Terry Ritter) Message-ID: <398e3fa2.1683088@news.io.com> References: <398C511C.77C8210D@zetnet.co.uk> Newsgroups: sci.crypt Lines: 84 On Sat, 05 Aug 2000 18:38:36 +0100, in <398C511C.77C8210D@zetnet.co.uk>, in sci.crypt David Hopwood <hopwood@zetnet.co.uk> wrote: >-----BEGIN PGP SIGNED MESSAGE----- > >Joseph Ashwood wrote: >> I know I'm arriving rather late to the party but, while Mr Ritter and I have >> been on differing sides of discussions before, I agree with him completely >> in this case. What he has suggested is to verify the lack of a short cycle, >> through a relatively cheap mechanism (certainly cheaper than the compromised >> security that could result is that check would have been failed). > >It's not particularly cheap in terms of the speed of parameter generation, >and it has been proven that short cycles happen with negligable probability, >if the parameter sizes are such that factoring is hard. BB&S short cycles are unlikely to be a *practical* weakness. But this *is* a practical *issue*, since the whole point of using slow BB&S in practice is to gain proven strength. If the proof does not hold for every cycle we may select, then BB&S may be weak in normal use, which means there is no point in using BB&S. Here is the summary again: * It is INDISPUTABLE that short cycles do exist in BB&S. * If the start value is selected purely at random, it is INDISPUTABLE that a short cycle might be selected. * It is INDISPUTABLE that when a random number generator (RNG) cycle has been traversed, we can predict future values from the ones produced in the past. Every deterministic RNG must repeat eventually, and when it does, it becomes insecure no matter how many security proofs it has. If a system is designed such that a short cycle may be selected, it can have no guarantee of security. >The probability of weakness is not changed significantly by applying the >constraints that Ritter thinks are necessary; as has been pointed out >repeatedly, his arguments are based on a misunderstanding of the BBS >security proofs. To the contrary, I would say that it is you and the others who seriously overestimate cryptographic proof in general, and have a significant misunderstanding of random number generators (RNG's) in particular. This argument has progressed to the point that my issues are virtually unassailable: they are easily understood and obviously correct, independent of any claim you may make. If you really have a result which conflicts with these points, it is time to re-think your math. You may have other issues, and I may or may not dispute them, but saying that I misunderstand is strange. Clearly you don't let a mere lack of context stop you from presenting your preconceptions. Because these issues are in simple form, most people reading here can understand that they are true, whether math guys agree with that or not. Presumably, those on the other side will find some semantic argument to claim they were right all along -- despite disputing my points time and time again. And that will demonstrate just how much we can trust what math guys say about crypto security. >> I find this to be solid reasoning, and something that should be done by >> anyone making use of BBS in this fashion. > >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 have misstated the weakness at issue. See above. --- Terry Ritter ritter@io.com http://www.io.com/~ritter/ Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM Subject: Re: OTP using BBS generator? Date: Tue, 08 Aug 2000 05:26:14 GMT From: Bryan Olson <bryanolson@my-deja.com> Message-ID: <8mo5lkapa1@nnrp1.deja.com> References: <398e3fa2.1683088@news.io.com> Newsgroups: sci.crypt Lines: 40 Terry Ritter wrote: > David Hopwood > This argument has progressed to the point that my issues are virtually > unassailable: they are easily understood and obviously correct, > independent of any claim you may make. If you really have a result > which conflicts with these points, it is time to re-think your math. So once more you refuse to address what people are saying. You bleat yet again that if a short cycle happens it's weak, as if the post to which you respond had said otherwise. Care to try? Where is the proof that if one _does_ reject short cycles one must, with probability one, get a particular instance that is not predictable by an attacker (given that general factoring is intractable)? We know that such an attack cannot be based on a short cycle of the generator state; you need not point that out again. > You may have other issues, and I may or may not dispute them, but > saying that I misunderstand is strange. Clearly you don't let a mere > lack of context stop you from presenting your preconceptions. There's no question that you misunderstood the BB&S proof. Check out: http://x64.deja.com/getdoc.xp?AN=637286423 where you state what you assumed the proofs guaranteed. --Bryan -- email: bolson at certicom dot com Sent via Deja.com http://www.deja.com/ Before you buy. Subject: Re: OTP using BBS generator? Date: Tue, 08 Aug 2000 16:29:13 GMT From: ritter@io.com (Terry Ritter) Message-ID: <399034e8.4865622@news.io.com> References: <8mo5lkapa1@nnrp1.deja.com> Newsgroups: sci.crypt Lines: 143 On Tue, 08 Aug 2000 05:26:14 GMT, in <8mo5lkapa1@nnrp1.deja.com>, in sci.crypt Bryan Olson <bryanolson@my-deja.com> wrote: >Terry Ritter wrote: >> David Hopwood > >> This argument has progressed to the point that my issues are virtually >> unassailable: they are easily understood and obviously correct, >> independent of any claim you may make. If you really have a result >> which conflicts with these points, it is time to re-think your math. > >So once more you refuse to address what people are >saying. You bleat yet again that if a short >cycle happens it's weak, as if the post to which >you respond had said otherwise. The post to which I responded implied that weakness could not exist, and did so in a slightly offensive manner. It was false, because there is weakness. It just happens rarely. There is a remarkable lack of desire to address this known weakness, even though we know how to do that. This means the math guys are perfectly happy to leave a preventable weakness in a cryptosystem, something which I think none of us should accept as reasonable. But what *really* happens is that every time I assume Bryan might be capable of reasoned discourse, he proves me wrong. >Care to try? Where is the proof that if one _does_ reject >short cycles one must, with probability one, get a >particular instance that is not predictable by an attacker >(given that general factoring is intractable)? That would be more your proof than mine. I do not champion the use of BB&S. Instead, I expose the fact that "proven strength" is a mathematical term-of-art which implies things which are not at all what a non-mathematician might expect. Basically, a large portion of the crypto and non-crypto population is being deceived by the use of technical terms about proof and strength which do not really mean what a lesser being might think. Moreover, the theory itself has a real problem: Any state-based Random Number Generator (RNG) of whatever design has some cycle length. Whenever that cycle length is exceeded, the sequence becomes predictable. But nowhere in the proof -- as far as I know -- is a limit proposed for generator use. So, sort-cycle or long-cycle, eventually the cycle *will* be traversed (in theory), and the system *will* become insecure. As proven, the system is always *in*secure, except for one cycle traversal at the start. The only thing that prevents this in practice is the size of the values and so the size of the cycles, but even huge values will have some limit, and the theory does not take that into account. I would say that the theory is insufficient as it stands. >We know that >such an attack cannot be based on a short cycle of the >generator state; you need not point that out again. Since short cycles are weak and preventing short cycles is possible yet not done, the situation obviously needs to be pointed out as frequently as possible. I can't spend as much time on line as I used to; perhaps someone else will help take up the cause. >> You may have other issues, and I may or may not dispute them, but >> saying that I misunderstand is strange. Clearly you don't let a mere >> lack of context stop you from presenting your preconceptions. > >There's no question that you misunderstood the BB&S >proof. Check out: > > >http://x64.deja.com/getdoc.xp?AN=637286423 And here it is! |On 21 Jun 2000 08:16:56 GMT, in <8iptloo3o2@bambi.zdv.Uni-Mainz.DE>, | in sci.crypt pom@imsd.uni-mainz.de (Klaus Pommerening) wrote: | | >In <394fa82d.6283727@news.io.com> Terry Ritter wrote: | >> * We *can* build a generator which does not use short cycles. | >> | >BTW the BBS generator outputs the LSB of its internal state | >x_i for each step. (x_i = x_{i-1}^2 mod n) | >Is there any known result that some choice of parameters in BBS | >guarantees that the LSBs don't give short cycles? | |Not that I know of. I never even thought of investigating such a |thing on my small models. I guess I assumed that sort of thing |was exactly what the proofs guaranteed. > >where you state what you assumed the proofs guaranteed. This is exactly the reason that I have in the past stopped conversing with Bryan, and now will do so again. It is not because he has found an error in my reasoning, or a change in my position, or a hypocrisy in my comments. It is because he is unwilling or unable to accept comments in their appropriate context. There are a lot of people who respond, a lot of points made, and a lot of words flying around; it is easy to find something which might be taken out of context. I note that as usual he does not actually include the quote; personally, I think he just expects that most people won't look it up. This sort of thing happens repeatedly, and simply is not acceptable behavior. With respect my comment about what the proofs guarantee, it was a specific response to the last question, which is about Least-Significant-Bits (LSB's) in particular, not short cycles in general. I never investigated whether the LSB's form short cycles, even though I have investigated short cycles in the BB&S system. My response was that this sort of peculiar special case is exactly what should be covered by a proof, and in his recent message, Bryan seemed to indicate just that: >The proof - without the long >cycle test - deals with _all_ algorithmic methods of >predicting the generator. I take that to mean that predicting bits -- in particular LSB's -- is also thought to be hard. Which is what I expect from the proof. Which is consistent with what I have said and will say on this subject. I am not a BB&S proof expert. I do not promote the use of BB&S. But if one is to use BB&S, one should at least know what one is getting. The failure to exclude short cycles means that a "proven secure" system has a preventable weakness which is not being excluded. Sure, it almost never happens, but almost never is not never. Suppose a new cipher were invented which could prevent the weakness of an opponent choosing the correct key -- it would absolutely prevent brute force attacks on the key. That would close a weakness of similar probability to the BB&S short cycles, and I think it would be widely acclaimed. In BB&S we have a weakness of similar import, yet the math guys want us to ignore it. I find that odd. --- Terry Ritter ritter@io.com http://www.io.com/~ritter/ Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM Subject: Re: OTP using BBS generator? Date: Tue, 08 Aug 2000 20:28:43 GMT From: Bryan Olson <bryanolson@my-deja.com> Message-ID: <8mpqhnfca1@nnrp1.deja.com> References: <399034e8.4865622@news.io.com> Newsgroups: sci.crypt Lines: 201 Terry Ritter wrote: > Bryan Olson wrote: > >So once more you refuse to address what people are > >saying[...] > The post to which I responded implied that weakness could not exist, > and did so in a slightly offensive manner. It was false, because > there is weakness. It just happens rarely. No, in that post David Hopwood got it right: | it has been proven that short cycles happen with negligible | probability, if the parameter sizes are such that factoring | is hard > There is a remarkable lack of desire to address this known weakness, > even though we know how to do that. I take a different view: I think showing the failure happens with negligible probability is a perfectly valid way to address the weakness. [...] > But what *really* happens is that every time I assume Bryan might be > capable of reasoned discourse, he proves me wrong. > > >Care to try? Where is the proof that if one _does_ reject > >short cycles one must, with probability one, get a > >particular instance that is not predictable by an attacker > >(given that general factoring is intractable)? > > That would be more your proof than mine. I do not champion the use of > BB&S. (Nor do I incidentally.) > Instead, I expose the fact that "proven strength" is a > mathematical term-of-art which implies things which are not at all > what a non-mathematician might expect. Could this be progress? I've been saying that the scheme without the long cycle test is secure in the same sense as the scheme with the test. In neither case are individual choices of parameters proven strong. Are you now agreeing? > Basically, a large portion of the crypto and non-crypto population is > being deceived by the use of technical terms about proof and strength > which do not really mean what a lesser being might think. What population of the community understands probabilistic arguments I cannot say. But to those who do really understand them, they're persuasive. For a particular choice of parameters, and I must use a particular choice when the time comes to encrypt, I don't know that the parameters cannot be broken, or even that the chance that they'll be broken is negligible. So I work from what I do know: if I choose the parameters from the probability space and encrypt, then the chance of the system falling is negligible. Strength is in the keyspace, not the key. Dependence on probability appears throughout science and engineering. Where cryptology specifically falls short is in theorems premised on open conjectures. > Moreover, the theory itself has a real problem: Any state-based > Random Number Generator (RNG) of whatever design has some cycle > length. Whenever that cycle length is exceeded, the sequence becomes > predictable. But nowhere in the proof -- as far as I know -- is a > limit proposed for generator use. So, sort-cycle or long-cycle, > eventually the cycle *will* be traversed (in theory), and the system > *will* become insecure. As proven, the system is always *in*secure, > except for one cycle traversal at the start. The only thing that > prevents this in practice is the size of the values and so the size of > the cycles, but even huge values will have some limit, and the theory > does not take that into account. I would say that the theory is > insufficient as it stands. The theory assumes that the parameters are chosen to be large enough that factoring is intractable. Given that we cannot do enough computation to factor with non-negligible probability, we also cannot do enough to get through the cycle with non-negligible probability. > >There's no question that you misunderstood the BB&S > >proof. Check out: > > > > > >http://x64.deja.com/getdoc.xp?AN=637286423 > > And here it is! > [Klaus Pommerening]: > | >BTW the BBS generator outputs the LSB of its internal state > | >x_i for each step. (x_i = x_{i-1}^2 mod n) > | >Is there any known result that some choice of parameters in BBS > | >guarantees that the LSBs don't give short cycles? [Ritter:] > |Not that I know of. I never even thought of investigating such a > |thing on my small models. I guess I assumed that sort of thing > |was exactly what the proofs guaranteed. Yes, exactly the kind of thing I've pointed out both before and after that post: the long cycle filter doesn't imply there's no case in which particular parameters fail (though I don't know if this kind of failure is possible). But why, after reading the paper, citing the paper, and accusing everyone else of not reading the whole paper, were you still _assuming_ what the proofs guaranteed? > This is exactly the reason that I have in the past stopped conversing > with Bryan, and now will do so again. No, what you've done is a debating trick where you alternate between claiming that you don't respond to my posts and responding to them. > It is not because he has found > an error in my reasoning, or a change in my position, or a hypocrisy > in my comments. It is because he is unwilling or unable to accept > comments in their appropriate context. Has your position changed? Do I understand correctly that the significant issue to you is that proof of strength ought to imply strength against all crypt-analytic attacks for every choice of key? I've been saying that with or without the cycle length test, the generator is only strong in the probabilistic sense, as a property of the key space and not a particular key (and subject to the open assumption). Do we now have agreement? > There are a lot of people who > respond, a lot of points made, and a lot of words flying around; it is > easy to find something which might be taken out of context. I note > that as usual he does not actually include the quote; personally, I > think he just expects that most people won't look it up. This sort of > thing happens repeatedly, and simply is not acceptable behavior. You object to the link? I particularly did not want to take anything out of context, so I provided a link to the whole post which further links to the threaded history. [...] > With respect my comment about what the proofs guarantee, it was a > specific response to the last question, which is about > Least-Significant-Bits (LSB's) in particular, not short cycles in > general. I never investigated whether the LSB's form short cycles, > even though I have investigated short cycles in the BB&S system. My > response was that this sort of peculiar special case is exactly what > should be covered by a proof, and in his recent message, Bryan seemed > to indicate just that: > > >The proof - without the long > >cycle test - deals with _all_ algorithmic methods of > >predicting the generator. True, and a good example of out-of-context quoting. The sentence that immediately follows in the same paragraph: | 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. You keep saying how deceptive people are to call these things proofs of security. Then when I carefully explain the cases and sense in which the proof applies, you chop that off, making it into the kind you call deceptive. But since this is still a technical group, I'll get back to the point of that entire paragraph: the BBS generator proof of security against all algorithmic attacks is a result about the key space and not any particular key. BB&S added that keys can be chosen to bring the chance of one particular form of failure from negligible to zero. The crypto community has judged the general argument much more interesting and important than the extra resistance to one particular attack. The major flaw in the BBS proof remains the reliance on an open conjecture. --Bryan -- email: bolson at certicom dot com Sent via Deja.com http://www.deja.com/ Before you buy. Subject: Re: OTP using BBS generator? Date: Tue, 08 Aug 2000 21:37:01 GMT From: ritter@io.com (Terry Ritter) Message-ID: <39907b79.3479797@news.io.com> References: <8mpqhnfca1@nnrp1.deja.com> Newsgroups: sci.crypt Lines: 26 On Tue, 08 Aug 2000 20:28:43 GMT, in <8mpqhnfca1@nnrp1.deja.com>, in sci.crypt Bryan Olson <bryanolson@my-deja.com> wrote: >Terry Ritter wrote: >[...] >> This is exactly the reason that I have in the past stopped conversing >> with Bryan, and now will do so again. > >No, what you've done is a debating trick where you alternate >between claiming that you don't respond to my posts and >responding to them. I guess when one tries to give a guy another chance in the ridiculous hope that he has changed his spots, one deserves just that sort of response! If Bryan wants to see it as a debating trick, he can do that just as long as he likes. As far as I am concerned, he is interested in "winning"; not participating in a discussion of reality. That can look like discussion, but is not really, and neither is this. --- Terry Ritter ritter@io.com http://www.io.com/~ritter/ Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM Subject: Re: OTP using BBS generator? Date: Thu, 10 Aug 2000 03:01:29 GMT From: Bryan Olson <bryanolson@my-deja.com> Message-ID: <8mt5u9oek1@nnrp1.deja.com> References: <39907b79.3479797@news.io.com> Newsgroups: sci.crypt Lines: 56 Terry Ritter wrote: > Bryan Olson wrote: > >Terry Ritter wrote: > >> This is exactly the reason that I have in the past > >> stopped conversing > >> with Bryan, and now will do so again. > > > >No, what you've done is a debating trick where you alternate > >between claiming that you don't respond to my posts and > >responding to them. > > I guess when one tries to give a guy another chance in the ridiculous > hope that he has changed his spots, one deserves just that sort of > response! > > If Bryan wants to see it as a debating trick, he can do that just as > long as he likes. Well, I was confused as to what to make of it. The first time I heard of it was in January, when you wrote in a response to someone else that you no longer debate with me. The next day you followed up one of my posts, quoting my points and making yours. And the day after that, I read that you no longer participate in discussions with me. > As far as I am concerned, he is interested in > "winning"; not participating in a discussion of reality. That can > look like discussion, but is not really, and neither is this. If you don't think this issue of whether you converse with me belongs in the discussion, *you* didn't have to bring it up. Why not respond instead to my entirely technical post http://www.deja.com/getdoc.xp?AN=655556392 or to any of the technical points from this strand? I thought we might actually make progress last time. Can we agree that BBS generator with or without the cycle length filter does not ensure (even if factoring is usually hard) that each individual key will induce unpredictable output? If so we can move on to whether proofs that apply to the key proofs of security, (as I argued they can and I gather you hold they cannot). --Bryan -- email: bolson at certicom dot com Sent via Deja.com http://www.deja.com/ Before you buy. Subject: Re: OTP using BBS generator? Date: Wed, 09 Aug 2000 19:49:44 GMT From: Benjamin Goldberg <goldbb2@earthlink.net> Message-ID: <3990A233.8D403CF3@earthlink.net> References: <8mpqhnfca1@nnrp1.deja.com> Newsgroups: sci.crypt Lines: 64 Bryan Olson wrote: [snip] > No, in that post David Hopwood got it right: > > | it has been proven that short cycles happen with negligible > | probability, if the parameter sizes are such that factoring > | is hard > > > There is a remarkable lack of desire to address this known weakness, > > even though we know how to do that. > > I take a different view: I think showing the failure happens > with negligible probability is a perfectly valid way to > address the weakness. Suppose we have a block cipher with big keys. Further suppose that a small number of those keys give the identity transformation, and all other keys are VERY secure. Also, suppose that there's no known way to find those weak keys without doing a trial encryption, but a trial encryption is trivial. Weak keys have low probability, but when they occur, the system is wide open. With BBS, short cycles occur with low probability, and the system is very secure when we don't have a short cycle. There's no known way to detect weather short cycles will occur without explicit testing, but explicit testing is trivial. If a short cycle does occur, the system is wide open. Does anyone see a similarity? Would anyone use the described block cipher without testing for the identity transformation? Assume that the identity transformation occurs as often as short BBS cycles. Personally, I think there exists some kind of futher restriction on the parameters to BBS which will eliminate short cycles entirely, but we haven't found it yet. That would be better than explicit testing for short cycles. [snip] > [Klaus Pommerening]: > > | >BTW the BBS generator outputs the LSB of its internal state > > | >x_i for each step. (x_i = x_{i-1}^2 mod n) > > | >Is there any known result that some choice of parameters in BBS > > | >guarantees that the LSBs don't give short cycles? > [Ritter:] > > |Not that I know of. I never even thought of investigating such a > > |thing on my small models. I guess I assumed that sort of thing > > |was exactly what the proofs guaranteed. > > Yes, exactly the kind of thing I've pointed out both before > and after that post: the long cycle filter doesn't imply > there's no case in which particular parameters fail (though I > don't know if this kind of failure is possible). But why, > after reading the paper, citing the paper, and accusing > everyone else of not reading the whole paper, were you still > _assuming_ what the proofs guaranteed? What it seems that Ritter is saying is that he's assuming that if there are no short cycles in the state then there will be short cycles in the LSB of the state. You're response to that seems confused. Or else my understanding of your response is confused. Subject: Re: OTP using BBS generator? Date: 10 Aug 2000 01:40:16 -0000 From: lcs Mixmaster Remailer <mix@anon.lcs.mit.edu> Message-ID: <20000810014016.17567.qmail@nym.alias.net> References: <3990A233.8D403CF3@earthlink.net> Newsgroups: sci.crypt Lines: 22 Benjamin Goldberg writes: > With BBS, short cycles occur with low probability, and the system is > very secure when we don't have a short cycle. There's no known way to > detect weather short cycles will occur without explicit testing, but > explicit testing is trivial. If a short cycle does occur, the system is > wide open. The same reasoning applies to accidentally choosing easy-to-guess primes. What if you are so unlucky as to choose a prime which exactly matches the ASCII representation of a Shakespeare sonnet? Or what if it turns out to be one more than a power of two? Or what if p/q happens to be very close to a simple rational fraction? The point is, if any of these things happen, the rsa modulus is easy to factor, with a proper program. But the chances of any of them happening are infinitisimal. And the same is true with choosing a seed that leads to a short cycle. Don't forget: if *you* could find a short-cycle seed, so could someone else. And if he can, he can break your RSA modulus, and all bets are off. If you truly think short cycles are a problem, you should conclude that RSA is not safe. Subject: Re: OTP using BBS generator? Date: Sat, 12 Aug 2000 03:54:43 GMT From: Benjamin Goldberg <goldbb2@earthlink.net> Message-ID: <39935C9B.F0590173@earthlink.net> References: <20000810014016.17567.qmail@nym.alias.net> Newsgroups: sci.crypt Lines: 76 lcs Mixmaster Remailer wrote: > > Benjamin Goldberg writes: > > With BBS, short cycles occur with low probability, and the system is > > very secure when we don't have a short cycle. There's no known way > > to detect weather short cycles will occur without explicit testing, > > but explicit testing is trivial. If a short cycle does occur, the > > system is wide open. > > The same reasoning applies to accidentally choosing easy-to-guess > primes. What if you are so unlucky as to choose a prime which exactly > matches the ASCII representation of a Shakespeare sonnet? Or what if > it turns out to be one more than a power of two? Or what if p/q > happens to be very close to a simple rational fraction? That's entirely different. What your describing is like saying "Suppose I search for my primes by testing each N bit number up to sqrt(pq), in random order, for being one of the primes, and BY RANDOM CHANCE, I happen to get it as my guess". If PQ has some property such as you describe, it would be non-trivial [*very* difficult] to discover that it is so. I'm saying, you've picked some PQ, and some X[0]. The X[i] values go through a short cycle and repeat. Perhaps the cycle length is 1, and the keystream is then either all 0's or all 1's. If this has occured, there is 100% chance of it being noticable. > The point is, if any of these things happen, the rsa modulus is easy > to factor, with a proper program. But the chances of any of them > happening are infinitisimal. And the same is true with choosing a > seed that leads to a short cycle. Erm. "What if you are so unlucky as to choose a prime which exactly matches the ASCII representation of a Shakespeare sonnet?" Sure, I suppose that it would be easy to find a program that tests for that specific modulus, and that program would of course already have the factors. It's a bit like saying, I've generated X many private key/public key pairs, and I want to try factor person Z's public key by testing if it's in my list. "Or what if it turns out to be one more than a power of two?" Supposing PQ is N bits long, you've the same likelyhood of P or Q happening to be 2^N+1, as you have of finding PQ on a list of N known products of pairs of big primes. "Or what if p/q happens to be very close to a simple rational fraction?" I don't see how this would help us factor PQ. > Don't forget: if *you* could find a short-cycle seed, so could someone > else. And if he can, he can break your RSA modulus, and all bets are > off. If you truly think short cycles are a problem, you should > conclude that RSA is not safe. Bzzt! No, BBS is not quite the same as RSA. Here's a BBS example of a short cycle: P is 23, Q is 47, X[0] is 46. X[i+1]=X[i]^2%PQ The short cycle that occurs is that for X[1] onward, the value is 1035. This means [assuming we use the lowest bit] that the keystream is all 1's, and the plaintext message can be seen by XORing 1 with every bit. HE'S FOUND THE MESSAGE! Now suppose we're using RSA, with some P and Q and message M and encryption exponent E with the same properties as the BBS example: that means X[0]=M, X[i+1]=X[i]^E%(PQ) and we've somehow got a message that degenerates into a short cycle: all X[i] where i>=1 are the same as X[1]. We've encrypted M, which mean's we've got (and sent) X[1]. Our opponent might learn that X[2] and X[3] and X[4], etc happen to all be the same as X[1], but that tells him nothing about X[0]. HE DOESN'T HAVE THE MESSAGE! See the difference? Opponent has message vs. opponent doesn't have message. Simple. -- Galibrath's Law of Human Nature: "Faced with the choice between changing one's mind and proving that there is no need to do so, almost everybody gets busy on the proof."-Vejita/Joel on #afd Subject: Re: OTP using BBS generator? Date: Thu, 10 Aug 2000 17:15:22 +0100 From: David Hopwood <hopwood@zetnet.co.uk> Message-ID: <3992D519.825F2C13@zetnet.co.uk> References: <3990A233.8D403CF3@earthlink.net> Newsgroups: sci.crypt Lines: 152 -----BEGIN PGP SIGNED MESSAGE----- Benjamin Goldberg wrote: > Bryan Olson wrote: > [snip] > > No, in that post David Hopwood got it right: > > > > | it has been proven that short cycles happen with negligible > > | probability, if the parameter sizes are such that factoring > > | is hard > > > > > There is a remarkable lack of desire to address this known weakness, > > > even though we know how to do that. > > > > I take a different view: I think showing the failure happens > > with negligible probability is a perfectly valid way to > > address the weakness. > > Suppose we have a block cipher with big keys. Further suppose that a > small number of those keys give the identity transformation, and all > other keys are VERY secure. Also, suppose that there's no known way to > find those weak keys without doing a trial encryption, but a trial > encryption is trivial. Weak keys have low probability, but when they > occur, the system is wide open. To be as generous as possible to your argument, let's assume that there is a proof, under assumptions that are as reasonable as the intractability of factoring, that there are no other significant weaknesses in the cipher (if there is no such proof, then this example is clearly not comparable to BBS). If the probability of a weak key is low enough to be considered negligable (the decision as to what is negligable is up to whoever is applying the security proof), then such a system would be considered secure in most probabilistic models of security, under the assumption that keys are selected at random. The system is also secure in practice, if keys are selected by a good RNG. So, the conclusions derived from the security model match what we need in the real world, as well as they can be expected to (and modulo the possibility of attacks that fall outside most formal security models, e.g. power analysis, fault analysis, etc.) There is the issue that keys might not in practice be selected at random, but that is something that in most cases can be analysed independently of the cipher. However, note that some constructions for hashes, etc. based on block ciphers (e.g. Davies-Meyer), are secure only if very strong assumptions are made about a cipher's key scheduling; they are insecure when used with ciphers that have even fairly minor key scheduling weaknesses. I tend to avoid these constructions entirely - I just don't trust that the assumptions will be satisfied. Another important caveat is that if you are put in the position of selecting a cipher that will be used for a very large range of applications (AES is an extreme example of this), then it would be a bad idea to select an algorithm that had weak keys, however unlikely. This is because there's no way to be sure that the random-key assumption will hold for all applications that use the cipher. > With BBS, short cycles occur with low probability, and the system is > very secure when we don't have a short cycle. There's no known way to > detect weather short cycles will occur without explicit testing, but > explicit testing is trivial. If a short cycle does occur, the system is > wide open. > > Does anyone see a similarity? Yes, of course; they are quite similar cases (with the caveats mentioned above, and the one below about the cost of testing for weakness). > Would anyone use the described block cipher without testing for the > identity transformation? Assume that the identity transformation occurs > as often as short BBS cycles. I would, if I was confident that the weak keys weren't a symptom of some other hidden weakness. If I wasn't confident of that, I probably wouldn't use the cipher at all. A practical example is IDEA: this has a set of weak keys that occur with probability about 2^-96. As it happens I haven't written any applications for end-users that use IDEA, but if I did, I wouldn't consider it necessary to check for weak keys. OTOH, note that testing for an identity permutation is much cheaper and less complex than testing for short BBS cycles, so it would also be a reasonable and consistent position to argue for testing in that case, but against testing cycle length in BBS. > Personally, I think there exists some kind of further restriction on the > parameters to BBS which will [provably] eliminate short cycles entirely, > but we haven't found it yet. I think that's unlikely, because I can't see any approach to proving the open question mentioned below. Given that it's 18 years since the BBS paper was published, probably one of the following is true: - not many people have looked at this question (which I doubt given the amount of research into bit-security of IFP-based cryptosystems), - there is a published proof that I'm not aware of, - it is difficult to prove, - it is false. [snip] > > [Klaus Pommerening]: > > > | >Is there any known result that some choice of parameters in BBS > > > | >guarantees that the LSBs don't give short cycles? > > [Ritter:] > > > |Not that I know of. I never even thought of investigating such a > > > |thing on my small models. I guess I assumed that sort of thing > > > |was exactly what the proofs guaranteed. > > > > Yes, exactly the kind of thing I've pointed out both before > > and after that post: the long cycle filter doesn't imply > > there's no case in which particular parameters fail (though I > > don't know if this kind of failure is possible). But why, > > after reading the paper, citing the paper, and accusing > > everyone else of not reading the whole paper, were you still > > _assuming_ what the proofs guaranteed? > > What it seems that Ritter is saying is that he's assuming that if there > are no short cycles in the state then there will be [no??] short cycles > in the LSB of the state. Well, the BBS paper is quite clear about what the state of public knowledge on this was in 1982 - it's posed as an open question just after Theorem 10 (and AFAIK it is still an open question). - -- David Hopwood <hopwood@zetnet.co.uk> Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/ RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01 Nothing in this message is intended to be legally binding. If I revoke a public key but refuse to specify why, it is because the private key has been seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv iQEVAwUBOZLTZTkCAxeYt5gVAQGxJAgAuLCoUTitQOxGAJzK76iBt03jqUI7XLN1 iyDwV2zgLDSBZ97cgHo4R/lR9vGi6FhvLx5olkixYRg9s1JHt/dJOG38yzHdiOc7 0R4IMOcFZXpENtevDBoJEUTm3+9stGK30ablyeXRj8IuSFeGO0goAXK6FqKlt4jK MYDfiJ/KY59yq8vCLe9wMTv5erP6fA3KWUcCX2no7O5DwUeL25YbaTzqpzzoYKLo aF1P+h6ak7Ve6DB/69awjMTTx9dGr78Mi5T9oB6udgGyFfDFdCAotJ9qgbG3oac1 CX6cj4kuurIPzJMLzYCvOIIs0vejPVCWf+gkqLqH39G6+FmFV+kPcA== =cVB+ -----END PGP SIGNATURE----- Subject: Re: OTP using BBS generator? Date: 12 Aug 2000 07:20:02 -0000 From: lcs Mixmaster Remailer <mix@anon.lcs.mit.edu> Message-ID: <20000812072002.17618.qmail@nym.alias.net> References: <3990A233.8D403CF3@earthlink.net> Newsgroups: sci.crypt Lines: 28 Benjamin Goldberg writes: > Here's a BBS example of a short cycle: P is 23, Q is 47, X[0] is 46. > X[i+1]=X[i]^2%PQ The short cycle that occurs is that for X[1] onward, > the value is 1035. This means [assuming we use the lowest bit] that the > keystream is all 1's, and the plaintext message can be seen by XORing 1 > with every bit. HE'S FOUND THE MESSAGE! > > Now suppose we're using RSA, with some P and Q and message M and > encryption exponent E with the same properties as the BBS example: that > means X[0]=M, X[i+1]=X[i]^E%(PQ) and we've somehow got a message that > degenerates into a short cycle: all X[i] where i>=1 are the same as > X[1]. We've encrypted M, which mean's we've got (and sent) X[1]. Our > opponent might learn that X[2] and X[3] and X[4], etc happen to all be > the same as X[1], but that tells him nothing about X[0]. HE DOESN'T > HAVE THE MESSAGE! 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. In general, if you can find short cycles, you can factor. Hence if you believe factoring is hard, you believe that short cycles can't be found. That's the bottom line. Subject: Re: OTP using BBS generator? Date: Mon, 14 Aug 2000 21:18:59 GMT From: Benjamin Goldberg <goldbb2@earthlink.net> Message-ID: <39986246.48CD65C0@earthlink.net> References: <20000812072002.17618.qmail@nym.alias.net> Newsgroups: sci.crypt Lines: 34 lcs Mixmaster Remailer wrote: > [snip] > > 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. > In general, if you can find short cycles, you can factor. Hence if > you believe factoring is hard, you believe that short cycles can't be > found. > That's the bottom line. -- "There's a mathematical reason not to trust Christians... The Buddhists believe that human lives repeat. The atheists believe that human lives terminate. That means that the Christians must believe that humans are irrational." - Matt Katinas "Not necessarily... they could think that humans are imaginary." - Rob Pease, in response to the above "Of course Christians think humans are irrational: They believe humans are transcendental, and all transcendentals are irrational. I suppose that all we can be certain of is that humans are complex." - Me, in response the the above Subject: Re: OTP using BBS generator? Date: 15 Aug 2000 01:00:23 -0000 From: lcs Mixmaster Remailer <mix@anon.lcs.mit.edu> Message-ID: <20000815010023.5170.qmail@nym.alias.net> References: <3990A233.8D403CF3@earthlink.net> Newsgroups: sci.crypt Lines: 28 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. 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. Subject: Re: OTP using BBS generator? Date: Tue, 15 Aug 2000 04:54:35 GMT From: ritter@io.com (Terry Ritter) Message-ID: <3998ccfc.1499602@news.io.com> References: <20000815010023.5170.qmail@nym.alias.net> Newsgroups: sci.crypt Lines: 54 On 15 Aug 2000 01:00:23 -0000, in <20000815010023.5170.qmail@nym.alias.net>, in sci.crypt lcs Mixmaster Remailer <mix@anon.lcs.mit.edu> 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 ritter@io.com http://www.io.com/~ritter/ Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM Subject: Re: OTP using BBS generator? Date: Tue, 15 Aug 2000 12:53:00 +0200 From: Mok-Kong Shen <mok-kong.shen@t-online.de> Message-ID: <3999210C.ADF47018@t-online.de> References: <20000815010023.5170.qmail@nym.alias.net> Newsgroups: sci.crypt Lines: 56 lcs Mixmaster Remailer wrote: > > 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. > > 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. Excuse me for posing some presumably very dumb questions. But the volume of materials in the present thread has become so huge that I find myself almost completely lost. (1) Does BBS give any result of the (frequency) distribution of the cycle lengths of LSB sequences so that one can have a 'concrete' feeling of how likely one gets a long/short cycle? (BTW, how much is exactly 'long' or 'short', in relation to p, q or n?) (2) David Hopwood pointed out that the BBS article left open the question of the relationship between the cylce lengths of LSB and the cycle lengths of the direct output of the congruence relation. Does this theory 'gap' have any effect on the proof of the unpredictability of the LSB sequences? If not, what's the (global/rough) reason? (Note that a cycle length of 1 or 2 of LSB would certainly be actually predictable.) (3) Does the 'check' being disputed really prevent a certian lower bound of the cycle lengths of the LSB sequences (not the direct output of the congruence relation) of being inadvertently 'under-run' or does the check only do that in a probabilistic sense (i.e. with certain probability not equal to 1)? What is that lower bound actually (in relation to p and q)? (4) Does the mathematics of BBS really gaurantee that there is absolutely no bias or serial correlations etc. in the LSB sequences? Has that been explicitly proven in the BBS article? (Note that it is inconceivable that any 'other' PRNG that has statistical defects qualifies for use in secure crypto applications. So I believe that BBS must somehow show that the LSB sequences are statistically impeacable.) Many thanks in advance. (Please give pointers to paragraphs of the original BBS article, if possible, so that one could read them up eventually.) M. K. Shen Subject: Re: OTP using BBS generator? Date: 15 Aug 2000 12:16:43 GMT From: mdw@nsict.org (Mark Wooding) Message-ID: <slrn8pid5b.glm.mdw@mull.ncipher.com> References: <3999210C.ADF47018@t-online.de> Newsgroups: sci.crypt Lines: 59 Mok-Kong Shen <mok-kong.shen@t-online.de> wrote: > (1) Does BBS give any result of the (frequency) distribution > of the cycle lengths of LSB sequences so that one can have > a 'concrete' feeling of how likely one gets a long/short > cycle? (BTW, how much is exactly 'long' or 'short', in > relation to p, q or n?) Not that I recall. > (2) David Hopwood pointed out that the BBS article left open > the question of the relationship between the cylce lengths > of LSB and the cycle lengths of the direct output of the > congruence relation. Does this theory 'gap' have any effect > on the proof of the unpredictability of the LSB sequences? > If not, what's the (global/rough) reason? (Note that a > cycle length of 1 or 2 of LSB would certainly be actually > predictable.) No. The proof of unpredictability is a two-step thing: * firstly, it shows that, if you can predict a BBS generator with probability 1/2 + \epsilon then you can also decide quadratic residuosity with probability 1/2 + \epsilon; * and secondly, it gives a simple algorithm for amplifying' advantage in deciding quadratic residuosity so that small biases can be used to efficiently solve QRP completely, in expected polynomial time. > (3) Does the 'check' being disputed really prevent a certian > lower bound of the cycle lengths of the LSB sequences > (not the direct output of the congruence relation) of > being inadvertently 'under-run' or does the check only > do that in a probabilistic sense (i.e. with certain > probability not equal to 1)? What is that lower bound > actually (in relation to p and q)? It doesn't do anything of the kind. > (4) Does the mathematics of BBS really gaurantee that there > is absolutely no bias or serial correlations etc. in > the LSB sequences? Has that been explicitly proven in > the BBS article? (Note that it is inconceivable that > any 'other' PRNG that has statistical defects qualifies > for use in secure crypto applications. So I believe > that BBS must somehow show that the LSB sequences are > statistically impeacable.) It shows that BBS output is indistinguishable from random data by *any* polynomial-time test, assuming the intracability of the QRP. The above are all polynomial time, so, yes, it covers them. > Many thanks in advance. (Please give pointers to paragraphs > of the original BBS article, if possible, so that one could > read them up eventually.) I don't have the article here: it's on a CD at home. -- [mdw] Subject: Re: OTP using BBS generator? Date: Tue, 15 Aug 2000 16:48:18 +0200 From: Mok-Kong Shen <mok-kong.shen@t-online.de> Message-ID: <39995832.FD8ABC4C@t-online.de> References: <slrn8pid5b.glm.mdw@mull.ncipher.com> Newsgroups: sci.crypt Lines: 80 Mark Wooding wrote: > > Mok-Kong Shen <mok-kong.shen@t-online.de> wrote: > > > (1) Does BBS give any result of the (frequency) distribution > > of the cycle lengths of LSB sequences so that one can have > > a 'concrete' feeling of how likely one gets a long/short > > cycle? (BTW, how much is exactly 'long' or 'short', in > > relation to p, q or n?) > > Not that I recall. I that case, I wonder, since one is using the LSB, what is the sense of disputing long vs. short cycles. (We have NO idea at all of the probability of getting cycles of LSB of any given magnitudes. Is that right?) > > > (2) David Hopwood pointed out that the BBS article left open > > the question of the relationship between the cylce lengths > > of LSB and the cycle lengths of the direct output of the > > congruence relation. Does this theory 'gap' have any effect > > on the proof of the unpredictability of the LSB sequences? > > If not, what's the (global/rough) reason? (Note that a > > cycle length of 1 or 2 of LSB would certainly be actually > > predictable.) > > No. The proof of unpredictability is a two-step thing: > > * firstly, it shows that, if you can predict a BBS generator with > probability 1/2 + \epsilon then you can also decide quadratic > residuosity with probability 1/2 + \epsilon; > > * and secondly, it gives a simple algorithm for amplifying' advantage > in deciding quadratic residuosity so that small biases can be used > to efficiently solve QRP completely, in expected polynomial time. Does that refer to the LSB? I guess that this is certainly the case. But then how can it be that there is a 'gap' mentioned above without causing any consequneces in the proof of the unpredictablity of LSB? Note what I wrote in parentheses. > > > (3) Does the 'check' being disputed really prevent a certian > > lower bound of the cycle lengths of the LSB sequences > > (not the direct output of the congruence relation) of > > being inadvertently 'under-run' or does the check only > > do that in a probabilistic sense (i.e. with certain > > probability not equal to 1)? What is that lower bound > > actually (in relation to p and q)? > > It doesn't do anything of the kind. Again, what is then the sense of arguing about long vs. short cycles? > > > (4) Does the mathematics of BBS really gaurantee that there > > is absolutely no bias or serial correlations etc. in > > the LSB sequences? Has that been explicitly proven in > > the BBS article? (Note that it is inconceivable that > > any 'other' PRNG that has statistical defects qualifies > > for use in secure crypto applications. So I believe > > that BBS must somehow show that the LSB sequences are > > statistically impeacable.) > > It shows that BBS output is indistinguishable from random data by *any* > polynomial-time test, assuming the intracability of the QRP. The above > are all polynomial time, so, yes, it covers them. So it means that you only need to prove the unpredictability and the statistical perfectness 'automatically' follows. Is that correct? A tiny toy example of mine indicates, however, that LSB of BBS could have poor statistical properties, though unfortunately the size of the example doesn't allow much to be said concretely/strongly. M. K. Shen Subject: Re: OTP using BBS generator? Date: 15 Aug 2000 15:06:47 GMT From: mdw@nsict.org (Mark Wooding) Message-ID: <slrn8pin46.glm.mdw@mull.ncipher.com> References: <39995832.FD8ABC4C@t-online.de> Newsgroups: sci.crypt Lines: 57 Mok-Kong Shen <mok-kong.shen@t-online.de> wrote: > I that case, I wonder, since one is using the LSB, what is the sense > of disputing long vs. short cycles. (We have NO idea at all of the > probability of getting cycles of LSB of any given magnitudes. Is that > right?) We know that finding cycles *of the LSB* is no easier than factoring! > > No. The proof of unpredictability is a two-step thing: > > > > * firstly, it shows that, if you can predict a BBS generator with > > probability 1/2 + \epsilon then you can also decide quadratic > > residuosity with probability 1/2 + \epsilon; > > > > * and secondly, it gives a simple algorithm for amplifying' advantage > > in deciding quadratic residuosity so that small biases can be used > > to efficiently solve QRP completely, in expected polynomial time. > > Does that refer to the LSB? Yes. > I guess that this is certainly the case. But then how can it be that > there is a 'gap' mentioned above without causing any consequneces in > the proof of the unpredictablity of LSB? Note what I wrote in > parentheses. Either finding such cycles, either by accident or malice, is neglibly difficult, or factoring is surprisingly easy. There is no gap'. > Again, what is then the sense of arguing about long vs. short > cycles? The don't check' people know that checking is redundant because we have the reduction to factoring which says that prediction is impractical for large n. Terry doesn't agree, but doesn't have any analysis of LSB period to back him up. > So it means that you only need to prove the unpredictability and the > statistical perfectness 'automatically' follows. Is that correct? Yes. Strictly, *any* advantage in predicting the output of a BBS generator is a polynomially-amplifiable advantage in solving a problem we assume is hard. > A tiny toy example of mine indicates, however, that LSB of BBS could > have poor statistical properties, though unfortunately the size of the > example doesn't allow much to be said concretely/strongly. That's because your modulus is too small. Your test is (and cannot be) polynomial time, and allows you to factor the toy modulus. But we know that's easy anyway, so the test tells us nothing new. -- [mdw] Subject: Re: OTP using BBS generator? Date: Tue, 15 Aug 2000 16:55:17 GMT From: ritter@io.com (Terry Ritter) Message-ID: <39997554.901854@news.io.com> References: <slrn8pin46.glm.mdw@mull.ncipher.com> Newsgroups: sci.crypt Lines: 28 On 15 Aug 2000 15:06:47 GMT, in <slrn8pin46.glm.mdw@mull.ncipher.com>, in sci.crypt mdw@nsict.org (Mark Wooding) wrote: >Mok-Kong Shen <mok-kong.shen@t-online.de> wrote: >[...] >> Again, what is then the sense of arguing about long vs. short >> cycles? > >The don't check' people know that checking is redundant because we have >the reduction to factoring which says that prediction is impractical for >large n. > >Terry doesn't agree, but doesn't have any analysis of LSB period to back >him up. I would say that I do have such an analysis, and it does back me up: If we use the BB&S construction, we are *guaranteed* not to use a short cycle. If we don't, then we are just very, very *unlikely* to use a short cycle. To me, the distinction is the essence of what we want from a proof of strength. If we were willing to accept a little weakness here and there, it seems unlikely that we would have much interest in cryptographic proof. --- Terry Ritter ritter@io.com http://www.io.com/~ritter/ Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM Subject: Re: OTP using BBS generator? Date: Tue, 15 Aug 2000 21:21:28 +0200 From: Mok-Kong Shen <mok-kong.shen@t-online.de> Message-ID: <39999838.EC383DF8@t-online.de> References: <39997554.901854@news.io.com> Newsgroups: sci.crypt Lines: 22 Terry Ritter wrote: > > I would say that I do have such an analysis, and it does back me up: > If we use the BB&S construction, we are *guaranteed* not to use a > short cycle. If we don't, then we are just very, very *unlikely* to > use a short cycle. To me, the distinction is the essence of what we > want from a proof of strength. If we were willing to accept a little > weakness here and there, it seems unlikely that we would have much > interest in cryptographic proof. Please correct me if I am wrong. I guess that you have investigated the cycle lengths of the direct output of the congruence relation but not the cycle lengths of the LSB, which could be comparatively much shorter. Further there seems to be no 'apriori' reason that there should exist a neat and simple relation between these two types of cycle lengths. M. K. Shen Subject: Re: OTP using BBS generator? Date: Wed, 16 Aug 2000 03:21:26 GMT From: ritter@io.com (Terry Ritter) Message-ID: <399a086b.573577@news.io.com> References: <39999838.EC383DF8@t-online.de> Newsgroups: sci.crypt Lines: 31 On Tue, 15 Aug 2000 21:21:28 +0200, in <39999838.EC383DF8@t-online.de>, in sci.crypt Mok-Kong Shen <mok-kong.shen@t-online.de> wrote: >Terry Ritter wrote: >> > >> I would say that I do have such an analysis, and it does back me up: >> If we use the BB&S construction, we are *guaranteed* not to use a >> short cycle. If we don't, then we are just very, very *unlikely* to >> use a short cycle. To me, the distinction is the essence of what we >> want from a proof of strength. If we were willing to accept a little >> weakness here and there, it seems unlikely that we would have much >> interest in cryptographic proof. > >Please correct me if I am wrong. I guess that you have >investigated the cycle lengths of the direct output of >the congruence relation but not the cycle lengths of >the LSB, which could be comparatively much shorter. >Further there seems to be no 'apriori' reason that there >should exist a neat and simple relation between these >two types of cycle lengths. No correction is needed, since you are right. I have no special information on the LSB question. --- Terry Ritter ritter@io.com http://www.io.com/~ritter/ Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM Subject: Re: OTP using BBS generator? Date: Wed, 16 Aug 2000 10:30:05 +0200 From: Mok-Kong Shen <mok-kong.shen@t-online.de> Message-ID: <399A510D.BD6D51E9@t-online.de> References: <399a086b.573577@news.io.com> Newsgroups: sci.crypt Lines: 106 Terry Ritter wrote: > > <mok-kong.shen@t-online.de> wrote: > > >Terry Ritter wrote: > >> > > > >> I would say that I do have such an analysis, and it does back me up: > >> If we use the BB&S construction, we are *guaranteed* not to use a > >> short cycle. If we don't, then we are just very, very *unlikely* to > >> use a short cycle. To me, the distinction is the essence of what we > >> want from a proof of strength. If we were willing to accept a little > >> weakness here and there, it seems unlikely that we would have much > >> interest in cryptographic proof. > > > >Please correct me if I am wrong. I guess that you have > >investigated the cycle lengths of the direct output of > >the congruence relation but not the cycle lengths of > >the LSB, which could be comparatively much shorter. > >Further there seems to be no 'apriori' reason that there > >should exist a neat and simple relation between these > >two types of cycle lengths. > > No correction is needed, since you are right. I have no special > information on the LSB question. Thank you for the answer. This means that the situation is much WORSE than what an quasi-observer of this thread like me up till now imagines. Namely, if we don't take measures to ensure having large cycles of the direct output of the congruence relation (as you have emphatically argued for), then we have even much LESS chance of being able to obtain large cycles of the LSB!! As you pointed out previously, this implies an ESSENTIAL weakness that the analyst could exploit. More explicitly, I have said that if the cycles are mostly very small, then finding these would be easy (instead of needing 'exponential time' or what not) and further that in the extreme case, cycles of length of 1 and 2 would mean that the bit sequence is perfectly determined and trivial! I have moreover posed the question of whether BBS have provided certain definite informations on the distribution of the cycle lengths of LSB. From the responses of the experts I got till now, it seems that BBS have not even given informations on the distribution of the cycle lengths of the direct output of the congruence relation! These facts, together with David Hopwood's information that BBS left 'explicitly' open the question of the relationship between the said two types of cycles lengths, seem to sufficiently justify the conjecture that there is somewhere a theory GAP in BBS's proof of security, in my guess probably on the path from the difficulty of predicting the direct output to the congruence relation to the difficulty of predicting the LSB. (There is, as far I am aware, NO clear-cut and useful relationship between these two types of entities in general!) Of course, due to my humble math knowledge, I could only conjecture. I like however to sincerely appeal to ALL the experts on BBS who have participated in this thread to carefully examine whether the above arguments do have (undeniable) logical weights and (in case of my misunderstanding and error) eventually clearly dispose of these not only with a bit concrete and easily understandable explanations but also provide pointers to the paragraphs of the original BBS article so that one could find more supporting materials, if needed. This issue is evidently EXTREMELY important, for otherwise the 'provably security' of BBS would have been a simple FICTION! I like to take this opportunity to once again point out the importance of experimentally checking the statistical properties of the LSB of BBS, in ways EXACTLY as every other PRNG ever used in practice has been checked. (What qualifies BBS to be an 'exception' in this??) My tiny example of a LSB sequence showing the poor quality in respect of serial correlations might have been a pure chance effect, being with some probability an extremely rare occurence among the ensemble of LSB sequences generated, but UNTIL this has been confirmed (theoretically or experimantally) to be indeed the case, the result MUST be considered as an ESSENTIAL evidence for doubting the usability of BBS in any crypto applications. I sincerely hope that this thread will produce a final clarification of the (long since questioned and many times heatedly disputed) issue on BBS and not be 'diverted' to a sink of 'nil' through being 'distracted' by another thread (appeared yesterday) which falsely claimed that agreement had already been reached in this thread. In fact, NO general agreement of the sort mentioned in that thread has yet been reached, but it seems that we are really emerging from the fog and finally on a clear path to the goal of finding out whether BBS REALLY provides the fabulous 'provable security' or not. Many thanks in advance. M. K. Shen --------------------------- http://home.t-online.de/home/mok-kong.shen Subject: Re: OTP using BBS generator? Date: 16 Aug 2000 09:42:26 GMT From: mdw@nsict.org (Mark Wooding) Message-ID: <slrn8pkofr.glm.mdw@mull.ncipher.com> References: <399A510D.BD6D51E9@t-online.de> Newsgroups: sci.crypt Lines: 71 Mok-Kong Shen <mok-kong.shen@t-online.de> wrote: > These facts, together with David Hopwood's information that BBS left > 'explicitly' open the question of the relationship between the said > two types of cycles lengths, seem to sufficiently justify the > conjecture that there is somewhere a theory GAP in BBS's proof of > security, in my guess probably on the path from the difficulty of > predicting the direct output to the congruence relation to the > difficulty of predicting the LSB. (There is, as far I am aware, NO > clear-cut and useful relationship between these two types of entities > in general!) There is a useful relationship between the two types. Note that the period length of the parity sequence must be a factor of the period length of the <x_i> sequence. A thought has struck me. Please stop me if it turns out to be hopelessy wrong. If it isn't, it will (a) sort out the parity sequence period, and (b) reduce the effort required to find BBS moduli with long periods. I can't believe that nobody's trodden this ground before: my abilities as a number theorist are somewhat limited. My inspiration is the work of Lim and Lee on attacking discrete log systems over GF(p). \newcommand{\pimax}{\pi_{\mathrm{max}}} The <x_i> period, usually notated as \pi, we know to be a factor of \pimax = \lambda(\lambda(n)) = \lambda(\lcm(p - 1, q - 1)). Let p = 2 p_0 p_1 p_2 ... p_k + 1 and q = 2 q_0 q_1 q_2 ... q_l + 1 be two prime numbers, where the p_i and q_i are primes greater than some given threshold t_0. Primes of such a form can be found fairly readily, by constructing a pool of smaller primes and analysing the products of all appropriately sized combinations, as described in Lim and Lee's paper. Then \lcm(p - 1, q - 1) = 2 p_0 p_1 p_2 ... p_k q_0 q_1 q_2 ... q_l. Going down another level, choose each of the p_i and q_i to be Sophie-Germain or Lim-Lee primes as well (depending on how small your numbers are by this point): ensure that each p_i has the form 2 \prod r_i + 1, where the r_i are all greater than some threshold t_1. We end up in the situation that \pimax is twice the product of a number of primes whose minimum size is strictly greater than our bound t_1. We know that the period \pi any *parity* sequence must be a factor of \pimax. But the only small prime factor of \pimax is 2, and we can easily check for periods of length 2. By choosing t_1 = 2^{128}, for example, we can ensure that a cycle found either has period 2 or longer than 2^{128}, which is obviously impractical to traverse. I still think it's a waste of time trying, by the way. I'm just trying to clarify the field a little. > This issue is evidently EXTREMELY important, for otherwise the > 'provably security' of BBS would have been a simple FICTION! No. You've misunderstood the proof almost completely. > I like to take this opportunity to once again point out the importance > of experimentally checking the statistical properties of the LSB of > BBS, in ways EXACTLY as every other PRNG ever used in practice has > been checked. > (What qualifies BBS to be an 'exception' in this??) The fact that breaking it is reducible to factoring the modulus. -- [mdw] Subject: Re: OTP using BBS generator? Date: Wed, 16 Aug 2000 14:32:00 +0200 From: Mok-Kong Shen <mok-kong.shen@t-online.de> Message-ID: <399A89C0.9B28A036@t-online.de> References: <slrn8pkofr.glm.mdw@mull.ncipher.com> Newsgroups: sci.crypt Lines: 106 Mark Wooding wrote: > > Mok-Kong Shen <mok-kong.shen@t-online.de> wrote: > > > These facts, together with David Hopwood's information that BBS left > > 'explicitly' open the question of the relationship between the said > > two types of cycles lengths, seem to sufficiently justify the > > conjecture that there is somewhere a theory GAP in BBS's proof of > > security, in my guess probably on the path from the difficulty of > > predicting the direct output to the congruence relation to the > > difficulty of predicting the LSB. (There is, as far I am aware, NO > > clear-cut and useful relationship between these two types of entities > > in general!) > > There is a useful relationship between the two types. Note that the > period length of the parity sequence must be a factor of the period > length of the <x_i> sequence. > > A thought has struck me. Please stop me if it turns out to be hopelessy > wrong. If it isn't, it will (a) sort out the parity sequence period, > and (b) reduce the effort required to find BBS moduli with long periods. > I can't believe that nobody's trodden this ground before: my abilities > as a number theorist are somewhat limited. > > My inspiration is the work of Lim and Lee on attacking discrete log > systems over GF(p). > > \newcommand{\pimax}{\pi_{\mathrm{max}}} > > The <x_i> period, usually notated as \pi, we know to be a factor of > \pimax = \lambda(\lambda(n)) = \lambda(\lcm(p - 1, q - 1)). > > Let p = 2 p_0 p_1 p_2 ... p_k + 1 and q = 2 q_0 q_1 q_2 ... q_l + 1 be > two prime numbers, where the p_i and q_i are primes greater than some > given threshold t_0. Primes of such a form can be found fairly readily, > by constructing a pool of smaller primes and analysing the products of > all appropriately sized combinations, as described in Lim and Lee's > paper. Then \lcm(p - 1, q - 1) = 2 p_0 p_1 p_2 ... p_k q_0 q_1 q_2 > ... q_l. > > Going down another level, choose each of the p_i and q_i to be > Sophie-Germain or Lim-Lee primes as well (depending on how small your > numbers are by this point): ensure that each p_i has the form 2 \prod > r_i + 1, where the r_i are all greater than some threshold t_1. > > We end up in the situation that \pimax is twice the product of a number > of primes whose minimum size is strictly greater than our bound t_1. We > know that the period \pi any *parity* sequence must be a factor of > \pimax. But the only small prime factor of \pimax is 2, and we can > easily check for periods of length 2. By choosing t_1 = 2^{128}, for > example, we can ensure that a cycle found either has period 2 or longer > than 2^{128}, which is obviously impractical to traverse. > > I still think it's a waste of time trying, by the way. I'm just trying > to clarify the field a little. I am (at least at the moment) not in a position to comment. From superficial look it does seem interesting. So why not persuing it a bit further? Could you please give a pointer to the paper of Lim and Lee? > > This issue is evidently EXTREMELY important, for otherwise the > > 'provably security' of BBS would have been a simple FICTION! > > No. You've misunderstood the proof almost completely. Only IF the connection from the 'difficulty' pertaining to the output of the cogruence relation to the 'difficulty' pertaining to LSB is seamless logically. I don't know yet for sure whether this is true. I said previously that my math knowledge is very unlikly to be sufficient to properly understand the original article of BBS. (So my 'misunderstanding' isn't a issue here.) But I do want an expert to explicitly confirm that there is no gap, notwithstanding the fact pointed out by David Hopwood. > > I like to take this opportunity to once again point out the importance > > of experimentally checking the statistical properties of the LSB of > > BBS, in ways EXACTLY as every other PRNG ever used in practice has > > been checked. > > > (What qualifies BBS to be an 'exception' in this??) > > The fact that breaking it is reducible to factoring the modulus. We have to be careful, don't we? At least one (or perhaps more) of the experts in the group has admitted that he hasn't read/mastered BBS's article in full. Should we 'believe' the math there is o.k., simply because BBS have big names?? Hundreds of proofs of FLT were found to be wrong, among them many by professors. (I happen to possess one 'proof' formally published in a big publishing company before WWII by a math prof of the Univ of Berlin.) If no one has yet done an extensive series of checks on the statistical qualities (not only cycle length!) of LSB of BBS, then it is HIGH time to have someone to do it! We people in crypto have to be especially prudent, don't we? (BTW, wasn't you that said in another thread to the effect that it isn't entirely sure from the outset that some posts in the group bearing the names of certain specialists are really from them?) M. K. Shen Subject: Re: OTP using BBS generator? Date: Tue, 15 Aug 2000 21:21:23 +0200 From: Mok-Kong Shen <mok-kong.shen@t-online.de> Message-ID: <39999833.B425E6B8@t-online.de> References: <slrn8pin46.glm.mdw@mull.ncipher.com> Newsgroups: sci.crypt Lines: 81 Mark Wooding wrote: > > Mok-Kong Shen <mok-kong.shen@t-online.de> wrote: > > > I that case, I wonder, since one is using the LSB, what is the sense > > of disputing long vs. short cycles. (We have NO idea at all of the > > probability of getting cycles of LSB of any given magnitudes. Is that > > right?) > > We know that finding cycles *of the LSB* is no easier than factoring! My problem is in knowing the (rough) path of attaining that knowledge, without having to deeply study the BBS article which I guess is way beyond my capability. My thought is this: BBS must proceed from the properties of the congruence relation to that of the LSB. They presumably could have first established that finding cycles of the direct output of the congruence relation is no easier than factoring. Since there is a gap in proceeding from the cycles of this kind to the cycles of LSB, I conjecture there could be some difficulties of continuing from the above point to establish that finding cycles of LSB is no easier than factoring. Looking from another perspective, what does 'finding cycles in LSB' mean? If the distribution of cycles lengths of LSB is (of course I don't know) is such that the majority of cycles are very short, then encountering a cycle would be easy. So I conjecture that one has to be able to say something definite about the distribution of cycle lengths of LSB, if one can prove that finding cycles of the LSB is no easier than factoring. > > > > No. The proof of unpredictability is a two-step thing: > > > > > > * firstly, it shows that, if you can predict a BBS generator with > > > probability 1/2 + \epsilon then you can also decide quadratic > > > residuosity with probability 1/2 + \epsilon; > > > > > > * and secondly, it gives a simple algorithm for amplifying' advantage > > > in deciding quadratic residuosity so that small biases can be used > > > to efficiently solve QRP completely, in expected polynomial time. > > > > Does that refer to the LSB? > > Yes. > > > I guess that this is certainly the case. But then how can it be that > > there is a 'gap' mentioned above without causing any consequneces in > > the proof of the unpredictablity of LSB? Note what I wrote in > > parentheses. > > Either finding such cycles, either by accident or malice, is neglibly > difficult, or factoring is surprisingly easy. There is no gap'. Why is it then, as David Hopwood said, that BBS leave the issue of the connection between the cycles of the direct output of the congruence relation and the cycles of LSB explicitly to be an open question? I surmise that that gap or open question must have some non-trivial bearing on the present issue. [snip] > > A tiny toy example of mine indicates, however, that LSB of BBS could > > have poor statistical properties, though unfortunately the size of the > > example doesn't allow much to be said concretely/strongly. > > That's because your modulus is too small. Your test is (and cannot be) > polynomial time, and allows you to factor the toy modulus. But we know > that's easy anyway, so the test tells us nothing new. If a bit sequence has grave statistical defects, then that can be readily exploited by the opponent, he wouldn't then need any 'polynomial' time or what not for doing the analysis. Or am I missing something? M. K. Shen Subject: Re: OTP using BBS generator? Date: 16 Aug 2000 09:52:14 GMT From: mdw@nsict.org (Mark Wooding) Message-ID: <slrn8pkp2e.glm.mdw@mull.ncipher.com> References: <39999833.B425E6B8@t-online.de> Newsgroups: sci.crypt Lines: 55 Mok-Kong Shen <mok-kong.shen@t-online.de> wrote: > My problem is in knowing the (rough) path of attaining that knowledge, > without having to deeply study the BBS article which I guess is way > beyond my capability. My thought is this: BBS must proceed from the > properties of the congruence relation to that of the LSB. They > presumably could have first established that finding cycles of the > direct output of the congruence relation is no easier than factoring. The BBS paper establishes the reduction to the quadratic residuosity problem only, not to factoring. The reduction to factoring was done afterwards by Vazirani and Vazirani (Crypto '84, I think). > Since there is a gap in proceeding from the cycles of this kind to the > cycles of LSB, I conjecture there could be some difficulties of > continuing from the above point to establish that finding cycles of > LSB is no easier than factoring. > > Looking from another perspective, what does 'finding cycles in LSB' > mean? If the distribution of cycles lengths of LSB is (of course I > don't know) is such that the majority of cycles are very short, then > encountering a cycle would be easy. So I conjecture that one has to be > able to say something definite about the distribution of cycle lengths > of LSB, if one can prove that finding cycles of the LSB is no easier > than factoring. No. The proof is much more general than that. It shows that *any* method of predicting the generator's output allows you to factor. [There is no gap'.] > Why is it then, as David Hopwood said, that BBS leave the issue of the > connection between the cycles of the direct output of the congruence > relation and the cycles of LSB explicitly to be an open question? I > surmise that that gap or open question must have some non-trivial > bearing on the present issue. Not really. The actual cycle analysis is interesting but fundamentally unimportant. (Although see my other article which shows how to obtain a lower bound on parity cycle lengths and generate moduli without the expense of finding the special' numbers.) The analysis of cycle lengths and distributions is *independent* of the proof that prediction of the generator is as hard as factoring. > If a bit sequence has grave statistical defects, then that can be > readily exploited by the opponent, he wouldn't then need any > 'polynomial' time or what not for doing the analysis. Or am I missing > something? Hence the proof shows that *either* factoring is surprisingly easy *or* a BBS generator has no such defects. In your toy examples, factoring is too easy. -- [mdw] Subject: Re: OTP using BBS generator? Date: Wed, 16 Aug 2000 14:32:08 +0200 From: Mok-Kong Shen <mok-kong.shen@t-online.de> Message-ID: <399A89C8.A3CC58B7@t-online.de> References: <slrn8pkp2e.glm.mdw@mull.ncipher.com> Newsgroups: sci.crypt Lines: 79 Mark Wooding wrote: > > Mok-Kong Shen <mok-kong.shen@t-online.de> wrote: > > > My problem is in knowing the (rough) path of attaining that knowledge, > > without having to deeply study the BBS article which I guess is way > > beyond my capability. My thought is this: BBS must proceed from the > > properties of the congruence relation to that of the LSB. They > > presumably could have first established that finding cycles of the > > direct output of the congruence relation is no easier than factoring. > > The BBS paper establishes the reduction to the quadratic residuosity > problem only, not to factoring. The reduction to factoring was done > afterwards by Vazirani and Vazirani (Crypto '84, I think). > > > Since there is a gap in proceeding from the cycles of this kind to the > > cycles of LSB, I conjecture there could be some difficulties of > > continuing from the above point to establish that finding cycles of > > LSB is no easier than factoring. > > > > Looking from another perspective, what does 'finding cycles in LSB' > > mean? If the distribution of cycles lengths of LSB is (of course I > > don't know) is such that the majority of cycles are very short, then > > encountering a cycle would be easy. So I conjecture that one has to be > > able to say something definite about the distribution of cycle lengths > > of LSB, if one can prove that finding cycles of the LSB is no easier > > than factoring. > > No. The proof is much more general than that. It shows that *any* > method of predicting the generator's output allows you to factor. > > [There is no gap'.] I am certainly ready to acknowledge your expertise. But, being conservative (see what I wrote in a parallel follow-up answering you), I like to see at least one another expert confirming that the connection from the difficulty of finding short cycles of LSB to the difficulty of factoring is 'completely' seamless. BTW, I questioned previously what does 'short' in 'finding short cycles' mean. Could you say something about that now, for that concept is essential here, isn't it? > > > Why is it then, as David Hopwood said, that BBS leave the issue of the > > connection between the cycles of the direct output of the congruence > > relation and the cycles of LSB explicitly to be an open question? I > > surmise that that gap or open question must have some non-trivial > > bearing on the present issue. > > Not really. The actual cycle analysis is interesting but fundamentally > unimportant. (Although see my other article which shows how to obtain a > lower bound on parity cycle lengths and generate moduli without the > expense of finding the special' numbers.) > > The analysis of cycle lengths and distributions is *independent* of the > proof that prediction of the generator is as hard as factoring. > > > If a bit sequence has grave statistical defects, then that can be > > readily exploited by the opponent, he wouldn't then need any > > 'polynomial' time or what not for doing the analysis. Or am I missing > > something? > > Hence the proof shows that *either* factoring is surprisingly easy *or* > a BBS generator has no such defects. In your toy examples, factoring is > too easy. It is the strange (simple) pattern in there that troubles me. For we can't simply through hand waving ignore the potential possibility that such patterns could also occur for LSB of moduli that are difficult to factor. (Any grave defects in serial correlations could have severe/fatal consequences.) M. K. Shen Subject: Re: OTP using BBS generator? Date: Tue, 15 Aug 2000 16:47:36 GMT From: ritter@io.com (Terry Ritter) Message-ID: <399973de.527036@news.io.com> References: <slrn8pid5b.glm.mdw@mull.ncipher.com> Newsgroups: sci.crypt Lines: 25 On 15 Aug 2000 12:16:43 GMT, in <slrn8pid5b.glm.mdw@mull.ncipher.com>, in sci.crypt mdw@nsict.org (Mark Wooding) wrote: >Mok-Kong Shen <mok-kong.shen@t-online.de> wrote: >[...] >> (3) Does the 'check' being disputed really prevent a certian >> lower bound of the cycle lengths of the LSB sequences >> (not the direct output of the congruence relation) of >> being inadvertently 'under-run' or does the check only >> do that in a probabilistic sense (i.e. with certain >> probability not equal to 1)? What is that lower bound >> actually (in relation to p and q)? > >It doesn't do anything of the kind. That's a wrong answer: The construction as described in BB&S first guarantees that cycles of a given length must exist, and then shows how to check that x0 is on such a cycle. The check is thus absolute proof that a short cycle has not been selected. --- Terry Ritter ritter@io.com http://www.io.com/~ritter/ Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM Subject: Re: OTP using BBS generator? Date: 15 Aug 2000 16:54:32 GMT From: mdw@nsict.org (Mark Wooding) Message-ID: <slrn8pite8.glm.mdw@mull.ncipher.com> References: <399973de.527036@news.io.com> Newsgroups: sci.crypt Lines: 11 Terry Ritter <ritter@io.com> wrote: > That's a wrong answer: The construction as described in BB&S first > guarantees that cycles of a given length must exist, and then shows > how to check that x0 is on such a cycle. The check is thus absolute > proof that a short cycle has not been selected. No, it only shows the cycle length for the sequence <x_i>, not the sequence of parity bits. -- [mdw] Subject: Re: OTP using BBS generator? Date: Tue, 15 Aug 2000 21:21:38 +0200 From: Mok-Kong Shen <mok-kong.shen@t-online.de> Message-ID: <39999842.85DF1E6E@t-online.de> References: <slrn8pite8.glm.mdw@mull.ncipher.com> Newsgroups: sci.crypt Lines: 17 Mark Wooding wrote: > > Terry Ritter <ritter@io.com> wrote: > > > That's a wrong answer: The construction as described in BB&S first > > guarantees that cycles of a given length must exist, and then shows > > how to check that x0 is on such a cycle. The check is thus absolute > > proof that a short cycle has not been selected. > > No, it only shows the cycle length for the sequence <x_i>, not the > sequence of parity bits. Sorry, I am really confused. 'Parity bits' or 'LSB'? Thanks. M. K. Shen Subject: Re: OTP using BBS generator? Date: Wed, 16 Aug 2000 03:30:16 GMT From: ritter@io.com (Terry Ritter) Message-ID: <399a0ab1.1156182@news.io.com> References: <39999842.85DF1E6E@t-online.de> Newsgroups: sci.crypt Lines: 31 On Tue, 15 Aug 2000 21:21:38 +0200, in <39999842.85DF1E6E@t-online.de>, in sci.crypt Mok-Kong Shen <mok-kong.shen@t-online.de> wrote: >Mark Wooding wrote: >> >> Terry Ritter <ritter@io.com> wrote: >> >> > That's a wrong answer: The construction as described in BB&S first >> > guarantees that cycles of a given length must exist, and then shows >> > how to check that x0 is on such a cycle. The check is thus absolute >> > proof that a short cycle has not been selected. >> >> No, it only shows the cycle length for the sequence <x_i>, not the >> sequence of parity bits. > >Sorry, I am really confused. 'Parity bits' or 'LSB'? Thanks. The "parity" property to which BB&S refers is "odd vs. even," which is also the least-significant-bit (LSB) in binary representation. We might call it <x_i> mod 2. BB&S mathematical "parity" is different from the usual coding and data-communications usage, where "parity" represents whether the number of 1-bits in a code or data value is odd or even. --- Terry Ritter ritter@io.com http://www.io.com/~ritter/ Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM Subject: Re: OTP using BBS generator? Date: Wed, 16 Aug 2000 15:08:26 +0100 From: David Hopwood <hopwood@zetnet.co.uk> Message-ID: <399AA05A.41856731@zetnet.co.uk> References: <39999842.85DF1E6E@t-online.de> Newsgroups: sci.crypt Lines: 42 -----BEGIN PGP SIGNED MESSAGE----- Mok-Kong Shen wrote: > Mark Wooding wrote: > > Terry Ritter <ritter@io.com> wrote: > > > > > That's a wrong answer: The construction as described in BB&S first > > > guarantees that cycles of a given length must exist, and then shows > > > how to check that x0 is on such a cycle. The check is thus absolute > > > proof that a short cycle has not been selected. > > > > No, it only shows the cycle length for the sequence <x_i>, not the > > sequence of parity bits. > > Sorry, I am really confused. 'Parity bits' or 'LSB'? Thanks. Either (they are equally secure). - -- David Hopwood <hopwood@zetnet.co.uk> Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/ RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01 Nothing in this message is intended to be legally binding. If I revoke a public key but refuse to specify why, it is because the private key has been seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv iQEVAwUBOZqgODkCAxeYt5gVAQFy7Qf8DMMjwqJqMpuQmSuGsb7FS1trtTcScY79 CxAntnlOjhlaR/oIIwIGpF4AlbrxMd7A1HBbnfp+R8DBkjdtzO+t2+3inRfiIpfF 1CEsuwMgwc3Y1rC6MuhIbqOjcO+gjUFyuCQVY4ny/19BL23WnfQOxtubCMTIkFOy nFkd+lT2EqfZcQ6qSdNOYHUK758dVOGdyI7iHt+j82b1t6robUGu6zNbMckWztBG nW4uSD9ubLI7CbuW/17W9dV/mskcgjO5oInj7MhWkY6VHSF6CNCLQ47JuZjSg7Os 3HdIQ3PbjWy7OIxToVqoQWXk3lsc9Vbhu9TM/zR8KygcZ+oyTCZsAg== =jefP -----END PGP SIGNATURE----- Subject: Re: OTP using BBS generator? Date: 16 Aug 2000 16:17:09 GMT From: mdw@nsict.org (Mark Wooding) Message-ID: <slrn8plfk5.glm.mdw@mull.ncipher.com> References: <399AA05A.41856731@zetnet.co.uk> Newsgroups: sci.crypt Lines: 14 David Hopwood <hopwood@zetnet.co.uk> wrote: > > Sorry, I am really confused. 'Parity bits' or 'LSB'? Thanks. The least significant bit is often called the parity bit' by mathematicians, since it represents the number's parity -- its oddness or evenness. It is this sense of the word parity' used by Blum, Blum and Shub in their 1982 paper. > Either (they are equally secure). That's interesting to know. -- [mdw] Subject: Re: OTP using BBS generator? Date: Thu, 17 Aug 2000 01:46:07 +0100 From: David Hopwood <hopwood@zetnet.co.uk> Message-ID: <399B35CF.5A3FFAB3@zetnet.co.uk> References: <slrn8plfk5.glm.mdw@mull.ncipher.com> Newsgroups: sci.crypt Lines: 47 -----BEGIN PGP SIGNED MESSAGE----- Mark Wooding wrote: > David Hopwood <hopwood@zetnet.co.uk> wrote: > > Mok-Kong Shen wrote: > > > Sorry, I am really confused. 'Parity bits' or 'LSB'? Thanks. > > The least significant bit is often called the parity bit' by > mathematicians, since it represents the number's parity -- its oddness > or evenness. It is this sense of the word parity' used by Blum, Blum > and Shub in their 1982 paper. > > > Either (they are equally secure). Oops, no they aren't (or at least this is not proven). > That's interesting to know. I had made a mistake in interpreting the "XOR-Condition" from the Vazirani paper. The XOR of the least significant log log N bits is secure, but this doesn't extend to the XOR of all the bits (i.e. the parity in the sense probably meant by Mok-Kong Shen). - -- David Hopwood <hopwood@zetnet.co.uk> Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/ RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01 Nothing in this message is intended to be legally binding. If I revoke a public key but refuse to specify why, it is because the private key has been seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv iQEVAwUBOZsnRzkCAxeYt5gVAQGiawf/R25A1a4G5pbkbfkcx7A3ydKw8p0bIps5 OOuvqVWLac+igD4RIB6ki/tSxux2OU2GEHaEXfkzJh5u28IAcGsfznZUeZceWN5B x+GaENh6YE/fbxQZRGz7Anv3JSloa5Y6XTW3OM/2JpqJ95pd9Oawlq26QzkAYmY0 aF/a9XEh0q+r9v2SuWCc5OwRjttLZO/PCUmbMeRSPsX7tjIHmB2luUP3vHv/xxa8 D+kU0FY8F/OWMtqa28ym8Pi4nWrwAUExQjLC/36q/jMS4TizsmOLY2yrMlSgOaYP YgdYzfOFoIbiRGehUpb0sUarYr1Q/D0rdt/FUhQP3OIRTpSXoG4+sA== =Q8Vd -----END PGP SIGNATURE----- Subject: Re: OTP using BBS generator? Date: Wed, 16 Aug 2000 19:41:31 +0200 From: Mok-Kong Shen <mok-kong.shen@t-online.de> Message-ID: <399AD24B.EC2AFCD8@t-online.de> References: <399AA05A.41856731@zetnet.co.uk> Newsgroups: sci.crypt Lines: 25 David Hopwood wrote: > > Mok-Kong Shen wrote: > > Sorry, I am really confused. 'Parity bits' or 'LSB'? Thanks. > > Either (they are equally secure). Intuitively I would think that the parity bit (in the common term, i.e. count of 1's) is at least as secure as LSB but I don't see any way of proving that. I have finally been able to obtain a copy of the BBS paper. The result of interest here says that modulo the quadratic residuacity assumption, the x^2 mon N is polynomial-time unpredictable to the left. Is there any concrete relation between the quadratic residuacity assumption and the assumption of hardness of factoring N? Thanks. M. K. Shen Subject: Re: OTP using BBS generator? Date: Thu, 17 Aug 2000 13:02:54 +0200 From: Mok-Kong Shen <mok-kong.shen@t-online.de> Message-ID: <399BC65E.783F90F@t-online.de> References: <399AD24B.EC2AFCD8@t-online.de> Newsgroups: sci.crypt Lines: 74 Mok-Kong Shen wrote: > > I have finally been able to obtain a copy of the BBS > paper. The result of interest here says that modulo the > quadratic residuacity assumption, the x^2 mon N is > polynomial-time unpredictable to the left. Is there > any concrete relation between the quadratic residuacity > assumption and the assumption of hardness of factoring N? I like to request the experts on BBS to kindly help me out in some additional difficulties detailed below: From the global structure of the paper (i.e. without understanding the details), I don't see where the argument 'finding short cycles is equivalent to factoring', which seems to be one of the points repeatedly stressed in this thread, is actually used in the paper. Am I missing something? If (I don't yet know) there is no definite (quantifiable) relation between QRA and the hardness of factoring, then one practical issue would be how to select the size of the modulus of BBS, i.e. how large should N be such that its output is safe for use. Note that the theorem contains in parentheses the phrase 'for sufficiently large n', which means that n (which appraently affects the size of N) is a function of delta and t and that function is unknown, at least not given in the paper. Wouldn't that simply mean that if we use very very large N then we are safe, without however saying what that 'very very large' exactly is? The theorem seems in fact not to directly (formally) involve the issue of cycle length that has been much disputed in this thread till the present. Does QRA, which is the assumption used in the theorem, involve the issue of cycle length? I don't see any material in the paper about that. But then the paper does devote a whole section to cycle length. Thus the motivation of this seems to be unclear. Further it says in that section: 'Since the x^2 mod N generator is an unpredictable pseudo-random sequence generator (modulo QRA), it follows that on the average, pi(x_0) [the period] will be long'. This seems to be a rather vague conclusion. I mean it appears to be not entirely evident why unpredictability necessarily leads to long periods, excepting extremely short periods, of course. Note that what is 'long' is itself a vague concept. The section does treat on the other hand special cases for which the cycle length can be computed from N. But even for these, the period is for x_i, not for LSB. So there can't be direct utility of the results. (The relationship between the two types of periods is stated in the paper as an open question.) The theorem concerns unpredictability to the left. Why 'to the left' and not 'to the right'? Does the one implies the other or is 'to the right' of no use in practice? The paper employs the term 'probabilistic poly-time statistical test'. Is this a theoretical concept like the Kolmogorov complexity or does there exist a conrete implementation of such a test or at least a practically realizable specification of it? Many thanks in advance. M. K. Shen ------------------------------ http://home.t-online.de/home/mok-kong.shen Subject: Re: OTP using BBS generator? Date: 17 Aug 2000 11:25:29 GMT From: mdw@nsict.org (Mark Wooding) Message-ID: <slrn8pnit5.glm.mdw@mull.ncipher.com> References: <399BC65E.783F90F@t-online.de> Newsgroups: sci.crypt Lines: 122 Mok-Kong Shen <mok-kong.shen@t-online.de> wrote: > > I have finally been able to obtain a copy of the BBS paper. The > > result of interest here says that modulo the quadratic residuacity > > assumption, the x^2 mon N is polynomial-time unpredictable to the > > left. Is there any concrete relation between the quadratic > > residuacity assumption and the assumption of hardness of factoring > > N? Yes. There is a polytime reduction from factoring to QRP. Since the quadratic residuosity problem is easy modulo a prime number (we have x^{(p - 1)/2} = 1 (mod p) iff x is a quadratic residue mod p) we can decide quadratic residuosity mod each factor of n separately. There is no proven reduction in the other direction. However, we don't have any algorithm which can decide quadratic residuosity mod n = p q with probability better than 1/2 without factoring n. This doesn't mean that no such algorithm can exist. The result is then that factoring is at least as difficult as QRP. > I like to request the experts on BBS to kindly help me out in some > additional difficulties detailed below: > > From the global structure of the paper (i.e. without understanding the > details), I don't see where the argument 'finding short cycles is > equivalent to factoring', which seems to be one of the points > repeatedly stressed in this thread, is actually used in the paper. Am > I missing something? Firstly: in 1984, Vazirani and Vazirani showed that predicting the output of the x^2 mod N generator reduced to factoring n. Since traversing a cycle evidently permits prediction of the generator's output, it must therefore also reduce to factoring n. If we stick with the original 1982 paper by Blum, Blum and Shub, they prove that any advantage in predicting the generator reduces to deciding quadratic residuosity with the same advantage (except that the advantage here is amplifiable). With this result, we see that traversing a cycle allows prediction of the generator's output with advantage 1/2 (i.e., probability 1) and hence immediately reduces to determining quadratic residuosity with advantage 1/2. > If (I don't yet know) there is no definite (quantifiable) relation > between QRA and the hardness of factoring, then one practical issue > would be how to select the size of the modulus of BBS, i.e. how large > should N be such that its output is safe for use. Make N large enough that factoring N is impractical. > Note that the theorem contains in parentheses the phrase 'for > sufficiently large n', which means that n (which appraently affects > the size of N) If you read the paper, n = |N| = \lceil \log_2 N \rceil is the bit length of N. It is n, the length of N, which is the parameter for the polynomial bounds described in the paper. > The theorem seems in fact not to directly (formally) involve the issue > of cycle length that has been much disputed in this thread till the > present. Does QRA, which is the assumption used in the theorem, > involve the issue of cycle length? I don't see any material in the > paper about that. No, the subject of period lengths doesn't occur in the main proof. It's irrelevant. Finding cycles permits prediction, and *all* prediction methods reduce to solving QRP, so there's no problem here. > But then the paper does devote a whole section to cycle length. Thus > the motivation of this seems to be unclear. Further it says in that > section: 'Since the x^2 mod N generator is an unpredictable > pseudo-random sequence generator (modulo QRA), it follows that on the > average, pi(x_0) [the period] will be long'. This seems to be a rather > vague conclusion. > I mean it appears to be not entirely evident why unpredictability > necessarily leads to long periods, excepting extremely short periods, > of course. I can't believe that this is really causing you difficulty. If cycles are short enough to traverse, then you can predict the generator's output very easily. Since the generator is unpredictable, such cycles, if they exist, must be very difficult to find. > Note that what is 'long' is itself a vague concept. The section does > treat on the other hand special cases for which the cycle length can > be computed from N. But even for these, the period is for x_i, not for > LSB. > So there can't be direct utility of the results. (The relationship > between the two types of periods is stated in the paper as an open > question.) Not that open. The parity sequence period must be a factor of the <x_i> period. If the <x_i> period has only large prime factors then the parity sequence period must be large. If the <x_i> sequence has prime period then the parity sequence period must be the same. Then see my own work, elsewhere in this group, about efficient choice of parameters for ensuring large period for the parity sequence. Please, if anyone else knows any other work along these lines could someone send me a reference! Otherwise, I'm rather tempted to write something up formally. > The theorem concerns unpredictability to the left. Why 'to the left' > and not 'to the right'? Does the one implies the other or is 'to the > right' of no use in practice? This puzzles me too. I've certainly seen (e.g., in HAC) claims that BBS is unpredictable in both directions, so there's certainly been some work done here. > The paper employs the term 'probabilistic poly-time statistical > test'. Is this a theoretical concept like the Kolmogorov complexity or > does there exist a conrete implementation of such a test or at least a > practically realizable specification of it? It's the name for a (large) class of statistical tests. It does what it says on the tin. -- [mdw] Subject: Re: OTP using BBS generator? Date: Thu, 17 Aug 2000 16:16:47 +0200 From: Mok-Kong Shen <mok-kong.shen@t-online.de> Message-ID: <399BF3CF.902095F@t-online.de> References: <slrn8pnit5.glm.mdw@mull.ncipher.com> Newsgroups: sci.crypt Lines: 75 Mark Wooding wrote: > > Mok-Kong Shen <mok-kong.shen@t-online.de> wrote: > > > > I have finally been able to obtain a copy of the BBS paper. The > > > result of interest here says that modulo the quadratic residuacity > > > assumption, the x^2 mon N is polynomial-time unpredictable to the > > > left. Is there any concrete relation between the quadratic > > > residuacity assumption and the assumption of hardness of factoring > > > N? > > Yes. There is a polytime reduction from factoring to QRP. Since the > quadratic residuosity problem is easy modulo a prime number (we have > x^{(p - 1)/2} = 1 (mod p) iff x is a quadratic residue mod p) we can > decide quadratic residuosity mod each factor of n separately. > > There is no proven reduction in the other direction. However, we don't > have any algorithm which can decide quadratic residuosity mod n = p q > with probability better than 1/2 without factoring n. This doesn't mean > that no such algorithm can exist. > > The result is then that factoring is at least as difficult as QRP. > > > I like to request the experts on BBS to kindly help me out in some > > additional difficulties detailed below: > > > > From the global structure of the paper (i.e. without understanding the > > details), I don't see where the argument 'finding short cycles is > > equivalent to factoring', which seems to be one of the points > > repeatedly stressed in this thread, is actually used in the paper. Am > > I missing something? > > Firstly: in 1984, Vazirani and Vazirani showed that predicting the > output of the x^2 mod N generator reduced to factoring n. Since > traversing a cycle evidently permits prediction of the generator's > output, it must therefore also reduce to factoring n. Sorry, doesn't this result of Vazirani and Vazirani conflict with the sentence 'There is no proven reduction in the other direction' above, or have I understood your text entirely in the wrong manner? Could you please say a bit more? > Then see my own work, elsewhere in this group, about efficient choice of > parameters for ensuring large period for the parity sequence. I hope that this efficient choice does not result in severe reduction of the space of N. > > The theorem concerns unpredictability to the left. Why 'to the left' > > and not 'to the right'? Does the one implies the other or is 'to the > > right' of no use in practice? > > This puzzles me too. I've certainly seen (e.g., in HAC) claims that BBS > is unpredictable in both directions, so there's certainly been some > work done here. Unpredictablility to the right seems to be actually more useful, isn't it? > > The paper employs the term 'probabilistic poly-time statistical > > test'. Is this a theoretical concept like the Kolmogorov complexity or > > does there exist a conrete implementation of such a test or at least a > > practically realizable specification of it? > > It's the name for a (large) class of statistical tests. It does what it > says on the tin. But to be meaningul one needs to know what that large class of tests is, or more exactly one should have a practical way of determining whether a given test belongs to that set. Is there any availble information/literature to that effect? M. K. Shen Subject: Re: OTP using BBS generator? Date: 17 Aug 2000 14:36:17 GMT From: mdw@nsict.org (Mark Wooding) Message-ID: <slrn8pnu30.glm.mdw@mull.ncipher.com> References: <399BF3CF.902095F@t-online.de> Newsgroups: sci.crypt Lines: 49 Mok-Kong Shen <mok-kong.shen@t-online.de> wrote: > Sorry, doesn't this result of Vazirani and Vazirani conflict with the > sentence 'There is no proven reduction in the other direction' above, > or have I understood your text entirely in the wrong manner? Could you > please say a bit more? You've misunderstood. We have QRP <=_P IFP, but we *don't* have IFP <=_P QRP. The BBS paper shows QRP <=_P BBS. The V&V paper shows IFP <=_P BBS, which doesn't contradict the previous statements: we have QRP <=_P IFP <=_P BBS. If someone had shown that BBS <=_P QRP then that would have been interesting. > I hope that this efficient choice does not result in severe > reduction of the space of N. No. It offers a *much* larger space of N than any other method I know of for obtaining guaranteed cycle bounds, including the special' primes which Ritter likes so much. Indeed, it's the increase of the space for N which makes the method efficient. I'll try to get an implementation of my method and offer a few examples of numbers chosen using my method. > Unpredictablility to the right seems to be actually more useful, isn't > it? I think that both are useful. This is just a gap in my knowledge or understanding -- I'm sure that this property has actually been proven somewhere. > But to be meaningul one needs to know what that large class of tests > is, or more exactly one should have a practical way of determining > whether a given test belongs to that set. Is there any availble > information/literature to that effect? There's the name of the class. It's rather precise. Probabilistic statistical tests are the usual sort. They have a probability of failure, and there are two types of failures: type I (which misidentify random things as being nonrandom) and type II (which misidentify nonrandom thins as being random). The poly-time' qualifier just limits the range of tests to those taking an amount of time bounded by a polynomial in the size (bit-length) of the BBS modulus. -- [mdw] Subject: Re: OTP using BBS generator? Date: Thu, 17 Aug 2000 19:35:59 +0200 From: Mok-Kong Shen <mok-kong.shen@t-online.de> Message-ID: <399C227F.5EE0DE4C@t-online.de> References: <slrn8pnu30.glm.mdw@mull.ncipher.com> Newsgroups: sci.crypt Lines: 52 Mark Wooding wrote: > > Mok-Kong Shen <mok-kong.shen@t-online.de> wrote: > > > Sorry, doesn't this result of Vazirani and Vazirani conflict with the > > sentence 'There is no proven reduction in the other direction' above, > > or have I understood your text entirely in the wrong manner? Could you > > please say a bit more? > > You've misunderstood. > > We have QRP <=_P IFP, but we *don't* have IFP <=_P QRP. The BBS paper > shows QRP <=_P BBS. The V&V paper shows IFP <=_P BBS, which doesn't > contradict the previous statements: we have QRP <=_P IFP <=_P BBS. > > If someone had shown that BBS <=_P QRP then that would have been > interesting. Excuse me. Could you please explain your notation '<=_P' and IFP? > > > I hope that this efficient choice does not result in severe > > reduction of the space of N. > > No. It offers a *much* larger space of N than any other method I know > of for obtaining guaranteed cycle bounds, including the special' primes > which Ritter likes so much. Indeed, it's the increase of the space for > N which makes the method efficient. > > I'll try to get an implementation of my method and offer a few examples > of numbers chosen using my method. Sorry, I like to repeat a question, for I doubt that I have fully understood the issue. If the main theorem does not involve cycle length and has firmly established the security issue, why does one (in particular BBS) has to bother to consider subsequently the cycle length question at all? A remark in this connection is that, as I argued in connection with an issue of OTP, one should in practice conservatively apply tests to all bit sequence generated or at least have sufficient amount of experimental results on the generation process (for the size of parameters used) to gain some confidence (belief), noting that BBS is a PRNG and is not comparable to an adeal OTP in theory, as Scott Nelson stressed. M. K. Shen Subject: Re: OTP using BBS generator? Date: 18 Aug 2000 09:13:38 GMT From: mdw@nsict.org (Mark Wooding) Message-ID: <slrn8ppvi2.4et.mdw@mull.ncipher.com> References: <399C227F.5EE0DE4C@t-online.de> Newsgroups: sci.crypt Lines: 46 Mok-Kong Shen <mok-kong.shen@t-online.de> wrote: > > > Mark Wooding wrote: > > > > Mok-Kong Shen <mok-kong.shen@t-online.de> wrote: > > > > > Sorry, doesn't this result of Vazirani and Vazirani conflict with the > > > sentence 'There is no proven reduction in the other direction' above, > > > or have I understood your text entirely in the wrong manner? Could you > > > please say a bit more? > > > > You've misunderstood. > > > > We have QRP <=_P IFP, but we *don't* have IFP <=_P QRP. The BBS paper > > shows QRP <=_P BBS. The V&V paper shows IFP <=_P BBS, which doesn't > > contradict the previous statements: we have QRP <=_P IFP <=_P BBS. > > > > If someone had shown that BBS <=_P QRP then that would have been > > interesting. > > Excuse me. Could you please explain your notation '<=_P' > and IFP? IFP is the Integer Factorization Problem. I believe that the usual phrasing of this as a decision problem is: Given an integer n and an interval [i_0, i_1], does n have a factor in the interval?' <=_P' is a less-than-or-equal sign with a subscript P'. It means poly-time reduces to'. In simple terms, it means is as easy as'. > Sorry, I like to repeat a question, for I doubt that I have fully > understood the issue. If the main theorem does not involve cycle > length and has firmly established the security issue, why does one (in > particular BBS) has to bother to consider subsequently the cycle > length question at all? * It's interesting to mathematicians, and it keeps them off the streets. This is important: have you ever seen a rampaging mob of mathematicians? Not a pretty sight... * Some people keep on bringing the subject up without any particularly good reason. The security proof, such as it is, applies regardless of any considerations about cycle lengths. -- [mdw] Subject: Re: OTP using BBS generator? Date: Fri, 18 Aug 2000 05:31:54 +0100 From: David Hopwood <hopwood@zetnet.co.uk> Message-ID: <399CBC3A.8FD19409@zetnet.co.uk> References: <399BF3CF.902095F@t-online.de> Newsgroups: sci.crypt Lines: 100 -----BEGIN PGP SIGNED MESSAGE----- Mok-Kong Shen wrote: > Mark Wooding wrote: > > Firstly: in 1984, Vazirani and Vazirani showed that predicting the > > output of the x^2 mod N generator reduced to factoring n. Since > > traversing a cycle evidently permits prediction of the generator's > > output, it must therefore also reduce to factoring n. > > Sorry, doesn't this result of Vazirani and Vazirani conflict > with the sentence 'There is no proven reduction in the other > direction' above, No. We have the following reductions: predicting_BBS ^ | | | v v IFP -----> QRA where ---> means "polynomially reduces to", IFP is the Integer Factorisation Problem, and all three problems are taken to be over the same distribution of moduli. This is all perfectly consistent; it means that the QRA could in principle be easier than predicting BBS or factoring. > > Then see my own work, elsewhere in this group, about efficient choice of > > parameters for ensuring large period for the parity sequence. > > I hope that this efficient choice does not result in severe > reduction of the space of N. If the distribution from which factors are chosen is changed, then the assumption needed to prove security is that the IFP is hard for this easier or harder than the IFP when factors are chosen as random primes. I don't see any reason in practice why constructing N in the way described in Mark Wooding's post would be expected to result in any weakness, provided t_1 is large enough (at least 2^128). Since it chooses p-1 and q-1 to be of special form, the "p-1" factoring method needs to be considered, but AFAICS that method will require O(t_1) work in this case, which should be OK. OTOH, I don't think that the cycle length issue is a good motivation for choosing factors of special form (either the method using Lim-Lee primes, or the "special primes" defined in the BBS paper). > > > The theorem concerns unpredictability to the left. Why 'to the left' > > > and not 'to the right'? Does the one implies the other or is 'to the > > > right' of no use in practice? Yao's theorem (referenced in the BBS paper) can be used to show that unpredictability to the left implies that the generator passes every probabilistic polynomial-time test (and hence is unpredictable to the right). [...] > > > The paper employs the term 'probabilistic poly-time statistical > > > test'. Is this a theoretical concept like the Kolmogorov complexity or > > > does there exist a conrete implementation of such a test or at least a > > > practically realizable specification of it? > > > > It's the name for a (large) class of statistical tests. It does what it > > says on the tin. > > But to be meaningful one needs to know what that large class of tests is, Roughly speaking, it means "any" possible poly-time test. Such a test corresponds to a way of feasibly predicting the generator; if there are no such tests (as the paper proves, under the QRA), then the generator output is indistinguishable from random. [Note that the above paragraph is somewhat imprecise, for mathematical rigour, refer to the "Theory and Applications of Trapdoor Functions" paper by Yao that is referenced by BBS.] - -- David Hopwood <hopwood@zetnet.co.uk> Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/ RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01 Nothing in this message is intended to be legally binding. If I revoke a public key but refuse to specify why, it is because the private key has been seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv iQEVAwUBOZy7NDkCAxeYt5gVAQE3zQf9H3AqXKD58uXUWrJlG2SZ57udAE5KTT3b sZ8EVNALk/3pxXa83fM0+5Pq1MvYyx1ejyqWfPojf0td3uAK1MdaHvTbN4KZTj0P C1Qr78hfA3nJf1dv/exy8zJANu4cmuiYGMYFT4Lo/K99MU4WC7mRu71ISdTtOBF7 Hb7mhHNQ0oTnfz5oJAAoyNX8ZrCOOTl7re4TozQaFip5AKIaNUe4x1FlVY/JCHQZ gu9UPlEmhwPKHiB+LqnWtWJ8sYGll/7E1ejVURLMlYGDGUdElePWy3n0UgKxoI29 uUh0oeSJxrron/dS4E041N4GRhfBu3anTn8+wcdUA+cY7zv856lRlw== =4fT9 -----END PGP SIGNATURE----- Subject: Re: OTP using BBS generator? Date: Fri, 18 Aug 2000 07:52:34 +0200 From: Mok-Kong Shen <mok-kong.shen@t-online.de> Message-ID: <399CCF22.FBF1945A@t-online.de> References: <399CBC3A.8FD19409@zetnet.co.uk> Newsgroups: sci.crypt Lines: 25 David Hopwood wrote: > [snip] > OTOH, I don't think that the cycle length issue is a good motivation for > choosing factors of special form (either the method using Lim-Lee primes, > or the "special primes" defined in the BBS paper). Thank you very much for providing very clear answers to my questions. I believe that I have now almost understood the whole issue of BBS (though not the details of math in it), excepting one question posted previously and a literature pointer: (1) If the main theorem does not involve cycle length and has firmly established the security issue, why does one (in particular BBS) have to bother to consider subsequently the cycle length question at all? (2) Which paper of Lim-Lie is the one referred to? Thanks. M. K. Shen Subject: Re: OTP using BBS generator? Date: Thu, 17 Aug 2000 16:15:31 GMT From: ritter@io.com (Terry Ritter) Message-ID: <399c0f00.2457606@news.io.com> References: <slrn8pnit5.glm.mdw@mull.ncipher.com> Newsgroups: sci.crypt Lines: 32 On 17 Aug 2000 11:25:29 GMT, in <slrn8pnit5.glm.mdw@mull.ncipher.com>, in sci.crypt mdw@nsict.org (Mark Wooding) wrote: >[...] >If cycles >are short enough to traverse, then you can predict the generator's >output very easily. Since the generator is unpredictable, such cycles, >if they exist, must be very difficult to find. Here, "unpredictable" is apparently mathematical exaggeration for effect: for, if the use of short cycles is *not* prohibited, a short cycle *might* be chosen, in which case the generator output would be predictable (as stated). So, when short cycles are *not* prohibited, what we have really is "almost always unpredictable." We don't get to "unpredictable" until we eliminate the use of short cycles. Thus, if we want the comfort of "unpredictable" instead of "almost always unpredictable," we need to additionally avoid short cycles. The above also tracks the strength argument, where even if we have no global guarantee of strength, we certainly cannot claim strength beyond the weakest possible configuration we support. To allow short cycles is to let them be our minimum guaranteed strength. --- Terry Ritter ritter@io.com http://www.io.com/~ritter/ Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM Subject: Re: OTP using BBS generator? Date: Fri, 18 Aug 2000 02:45:36 +0100 From: David Hopwood <hopwood@zetnet.co.uk> Message-ID: <399C9540.6D311304@zetnet.co.uk> References: <399c0f00.2457606@news.io.com> Newsgroups: sci.crypt Lines: 36 -----BEGIN PGP SIGNED MESSAGE----- Terry Ritter wrote: > Thus, if we want the comfort of "unpredictable" instead of "almost > always unpredictable," we need to additionally avoid short cycles. Avoiding short cycles still gets you "almost always unpredictable" [*], not "always unpredictable". Moreover, "always unpredictable" is not necessary and was never claimed. [*] where "almost always" means "except with negligable probability". - -- David Hopwood <hopwood@zetnet.co.uk> Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/ RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01 Nothing in this message is intended to be legally binding. If I revoke a public key but refuse to specify why, it is because the private key has been seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv iQEVAwUBOZyVFzkCAxeYt5gVAQHazwf/RtA1Hd5Ycp4diKCTSHIKHN/IB5LAjhA6 fySjAY0Lg8QtIQXErhJns4UwBarjpJNbEIqmzeFuOotRV1bNL6oiO+Th1nvi0M4M WVUlWcYYXfXavz/LYzkNCYMRN9A8WDeKFfxhGyuC7YxVsYI1RMwgUbTsJqV4A/+s yPixGxP9TqbwIf3f2rbRghdiKEt63qu+sUKcH9lmFx65DnA4/CMdMtcTPJEchmjj IJkvQVzpZUzcfcoZ4ylLZfM6sM1DmhtZA8rXdRKUTnCeV5zk2DCmYCkwQKNuR+6K pEEBoDdamFthaWm59zYOkbkpuFIXKkJpZa624J3RPCh7R/q5ZJ9Dmg== =h17m -----END PGP SIGNATURE----- Subject: Re: OTP using BBS generator? Date: 20 Aug 2000 20:28:21 GMT From: djb@cr.yp.to (D. J. Bernstein) Message-ID: <2000Aug2020.28.21.26309@cr.yp.to> References: <slrn8pnit5.glm.mdw@mull.ncipher.com> Newsgroups: sci.crypt Lines: 19 Mark Wooding <mdw@nsict.org> wrote: > Make N large enough that factoring N is impractical. Where do people get this idea? If you want to apply the theorems, you need _much_ larger values of N. Consider, for example, the Alexi-Chor-Goldreich-Schnorr theorem, which tells you how to factor N using 10^54 (lg N)^3 applications of an algorithm that has a 1/1000 chance of seeing a pattern in a billion bits produced by a BBS generator mod N. The theorem doesn't say that predicting the generator is as hard as factoring N; it allows a ratio of speeds as large as 10^54 (lg N)^3. This tells you nothing if you merely assume that the attacker needs practically forever to factor N. You have to assume that the attacker needs 10^54 (lg N)^3 times practically forever. That assumption is false if N has, say, 3000 digits. ---Dan Subject: Re: OTP using BBS generator? Date: Mon, 21 Aug 2000 10:50:41 +0200 From: Mok-Kong Shen <mok-kong.shen@t-online.de> Message-ID: <39A0ED61.D8E9E073@t-online.de> References: <2000Aug2020.28.21.26309@cr.yp.to> Newsgroups: sci.crypt Lines: 77 "D. J. Bernstein" wrote: > > Mark Wooding <mdw@nsict.org> wrote: > > Make N large enough that factoring N is impractical. > > Where do people get this idea? If you want to apply the theorems, you > need _much_ larger values of N. > > Consider, for example, the Alexi-Chor-Goldreich-Schnorr theorem, which > tells you how to factor N using 10^54 (lg N)^3 applications of an > algorithm that has a 1/1000 chance of seeing a pattern in a billion bits > produced by a BBS generator mod N. The theorem doesn't say that > predicting the generator is as hard as factoring N; it allows a ratio of > speeds as large as 10^54 (lg N)^3. > > This tells you nothing if you merely assume that the attacker needs > practically forever to factor N. You have to assume that the attacker > needs 10^54 (lg N)^3 times practically forever. That assumption is false > if N has, say, 3000 digits. Thank you very much for the valuable information. Having only humble math knowledge, I find it often very difficult to really comprehend certain modern literatures in cryptology, where much math knowledge is assumed, the argumentation is very condensed, quite a lot is based on other publications of equally high level and (probably) the implications of certain assumptions being made are not sufficiently heavily stressed by the authors. I conjecture, however, that I am not the single person in the group facing such difficulties. That the topic BBS has frequently recurred and each time resulted in voluminous discussions is a clear indication of this, I suppose. How are those like myself having difficulties with very deep literatures going to do? I guess that there are three ways. The first is to catch up with the high math. That's certainly the best. But that can take time and presumably not everyone is good at that. (At least I doubt very much my ability in this direction.) The second is to rely completely on the claims of the experts. But this is by nature not very satisfying and sounds like plain religious belief. The third is to take a conservative standpoint in applying the results that are based on theories that one has not been able to completely understand. I believe that this last is probably a sufficiently practical and realistic path that the majority of persons of the category delineated above could advantageously follow. This means in the particular context of the present thread that we conduct sufficient amount of tests on the bit sequences obtained with test methods that are known and available and feasible to us, in order to compensate the potential (unkown) risk of insecurity resulting from eventual misunderstanding or inappropriate application of the theories involved. This may be considered to be another essential reason supporting my suggestion in previous follow-ups of having extensive statistical tests done before BBS is used in one's own applications. I have the (maybe wrong) impression that hardly anyone of us has currently very essential practical experiences with BBS. While this thread is now seemingly approaching its quiesence point, I like to take the opportunity to express my humble and sincere hope to be able to hear from experts reporting on their experiences in real-life applications, in particular results of investigations of various statistical qualities of LSB of the generator, when someday BBS is once again on the agenda of the group. M. K. Shen -------------------------- http://home.t-online.de/home/mok-kong.shen Subject: Re: OTP using BBS generator? Date: 21 Aug 2000 10:07:09 GMT From: mdw@nsict.org (Mark Wooding) Message-ID: <slrn8q1vqd.4et.mdw@mull.ncipher.com> References: <2000Aug2020.28.21.26309@cr.yp.to> Newsgroups: sci.crypt Lines: 17 D. J. Bernstein <djb@cr.yp.to> wrote: > Consider, for example, the Alexi-Chor-Goldreich-Schnorr theorem, which > tells you how to factor N using 10^54 (lg N)^3 applications of an > algorithm that has a 1/1000 chance of seeing a pattern in a billion bits > produced by a BBS generator mod N. The theorem doesn't say that > predicting the generator is as hard as factoring N; it allows a ratio of > speeds as large as 10^54 (lg N)^3. Is this a hard upper bound on the potential silliness (degree, size of coefficients) of the polynomial relationship between factoring time and prediction difficulty? If not, I think I'll claim that the proofs aren't actually very useful in practice anyway. Oh, do you have a pointer to Alexi-Chor-Goldreich-Schnorr? -- [mdw] Subject: Re: OTP using BBS generator? Date: Thu, 24 Aug 2000 09:40:29 GMT From: Tim Tyler <tt@cryogen.com> Message-ID: <FzsIvH.1Jr@bath.ac.uk> References: <slrn8q1vqd.4et.mdw@mull.ncipher.com> Newsgroups: sci.crypt Lines: 19 Mark Wooding <mdw@nsict.org> wrote: : Oh, do you have a pointer to Alexi-Chor-Goldreich-Schnorr? FWIW: two /possible/ papers at: http://www.informatik.uni-trier.de/~ley/db/indices/a-tree/s/Schnorr:Claus=Peter.html Alexi, W.; Chor, B.; Goldreich, O.; Schnorr, C. P.: RSA/Rabin Bits are 1/2 + 1/poly(\logN) Secure. 25th Annual Symposium on Foundations of Computer Science (FOCS84). Singer Island, Fla., USA, 1984. 449-457. W. Alexi, B. Chor, O. Goldreich, and C.P. Schnorr, RSA and Rabin functions: Certain parts are as hard as the whole, SIAM Journal of Computing (2) 17 (1988), 194-209. -- __________ http://alife.co.uk/ http://mandala.co.uk/ |im |yler tt@cryogen.com http://hex.org.uk/ http://atoms.org.uk/ Subject: Re: OTP using BBS generator? Date: Wed, 16 Aug 2000 01:46:21 GMT From: jsavard@fNrOeSePnAeMt.edmonton.ab.ca (John Savard) Message-ID: <3999f249.247190@news.ecn.ab.ca> References: <slrn8pite8.glm.mdw@mull.ncipher.com> Newsgroups: sci.crypt Lines: 17 On 15 Aug 2000 16:54:32 GMT, mdw@nsict.org (Mark Wooding) wrote, in part: >Terry Ritter <ritter@io.com> wrote: >> That's a wrong answer: The construction as described in BB&S first >> guarantees that cycles of a given length must exist, and then shows >> how to check that x0 is on such a cycle. The check is thus absolute >> proof that a short cycle has not been selected. >No, it only shows the cycle length for the sequence <x_i>, not the >sequence of parity bits. Since the BBS modulus can't be a power of two, I don't think you have to worry about that. John Savard http://home.ecn.ab.ca/~jsavard/crypto.htm Subject: Re: OTP using BBS generator? Date: Wed, 16 Aug 2000 10:32:33 +0200 From: Mok-Kong Shen <mok-kong.shen@t-online.de> Message-ID: <399A51A1.3A79640E@t-online.de> References: <3999f249.247190@news.ecn.ab.ca> Newsgroups: sci.crypt Lines: 24 John Savard wrote: > > On 15 Aug 2000 16:54:32 GMT, mdw@nsict.org (Mark Wooding) wrote, in > part: > >Terry Ritter <ritter@io.com> wrote: > > >> That's a wrong answer: The construction as described in BB&S first > >> guarantees that cycles of a given length must exist, and then shows > >> how to check that x0 is on such a cycle. The check is thus absolute > >> proof that a short cycle has not been selected. > > >No, it only shows the cycle length for the sequence <x_i>, not the > >sequence of parity bits. > > Since the BBS modulus can't be a power of two, I don't think you have > to worry about that. Do I understand correctly that you claim that the cycle length of <x_i> equals the cycle length of the parity bits (either the normal definition or LSB)? Thanks. M. K. Shen Subject: Re: OTP using BBS generator? Date: Wed, 16 Aug 2000 10:48:07 GMT From: jsavard@fNrOeSePnAeMt.edmonton.ab.ca (John Savard) Message-ID: <399a7032.454165@news.ecn.ab.ca> References: <399A51A1.3A79640E@t-online.de> Newsgroups: sci.crypt Lines: 44 On Wed, 16 Aug 2000 10:32:33 +0200, Mok-Kong Shen <mok-kong.shen@t-online.de> wrote, in part: >John Savard wrote: >> On 15 Aug 2000 16:54:32 GMT, mdw@nsict.org (Mark Wooding) wrote, in >> part: >> >Terry Ritter <ritter@io.com> wrote: >> >> That's a wrong answer: The construction as described in BB&S first >> >> guarantees that cycles of a given length must exist, and then shows >> >> how to check that x0 is on such a cycle. The check is thus absolute >> >> proof that a short cycle has not been selected. >> >No, it only shows the cycle length for the sequence <x_i>, not the >> >sequence of parity bits. >> Since the BBS modulus can't be a power of two, I don't think you have >> to worry about that. >Do I understand correctly that you claim that the cycle >length of <x_i> equals the cycle length of the parity bits >(either the normal definition or LSB)? Thanks. I believe I do, or at least I make a weaker claim that still shows the cycle length of the parity bits has to be long. Essentially, since the modulus is the product of odd primes or an odd prime, or something like that, and the parity bit has two possible values, and the seed is not allowed to be zero, it follows that certain cycle lengths are not possible. Now, if the cycle length for the generator as a whole is pq, for p and q prime, proving that the parity bit can't have a cycle length of p or a cycle length of q would require advanced math, it IS clear that no other cycle length for the parity bit less than pq is possible. That the parity bit will be unbiased would also require advanced math to show, but since it's been proven "hard to predict", that would imply that such a proof does exist. John Savard http://home.ecn.ab.ca/~jsavard/crypto.htm Subject: Re: OTP using BBS generator? Date: 16 Aug 2000 11:38:39 GMT From: mdw@nsict.org (Mark Wooding) Message-ID: <slrn8pkv9u.glm.mdw@mull.ncipher.com> References: <399a7032.454165@news.ecn.ab.ca> Newsgroups: sci.crypt Lines: 25 John Savard <jsavard@fNrOeSePnAeMt.edmonton.ab.ca> wrote: > <mok-kong.shen@t-online.de> wrote, in part: > > >Do I understand correctly that you claim that the cycle length of > ><x_i> equals the cycle length of the parity bits (either the normal > >definition or LSB)? Thanks. > > I believe I do, or at least I make a weaker claim that still shows the > cycle length of the parity bits has to be long. I believe this assertion to be incorrect. > it follows that certain cycle lengths are not possible. Now, if the > cycle length for the generator as a whole is pq, for p and q prime, Yes, but it isn't: it's a factor of \lambda(\lambda(n)). > That the parity bit will be unbiased would also require advanced math > to show, but since it's been proven "hard to predict", that would > imply that such a proof does exist. Indeed, the difficulty of prediction implies the lack of bias as a trivial corollary. -- [mdw] Subject: Re: OTP using BBS generator? Date: Wed, 16 Aug 2000 14:32:12 +0200 From: Mok-Kong Shen <mok-kong.shen@t-online.de> Message-ID: <399A89CC.53B06A65@t-online.de> References: <399a7032.454165@news.ecn.ab.ca> Newsgroups: sci.crypt Lines: 42 John Savard wrote: > > <mok-kong.shen@t-online.de> wrote, in part: > >John Savard wrote: > >> Since the BBS modulus can't be a power of two, I don't think you have > >> to worry about that. > > >Do I understand correctly that you claim that the cycle > >length of <x_i> equals the cycle length of the parity bits > >(either the normal definition or LSB)? Thanks. > > I believe I do, or at least I make a weaker claim that still shows the > cycle length of the parity bits has to be long. > > Essentially, since the modulus is the product of odd primes or an odd > prime, or something like that, > > and the parity bit has two possible values, > > and the seed is not allowed to be zero, > > it follows that certain cycle lengths are not possible. Now, if the > cycle length for the generator as a whole is pq, for p and q prime, > proving that the parity bit can't have a cycle length of p or a cycle > length of q would require advanced math, it IS clear that no other > cycle length for the parity bit less than pq is possible. > > That the parity bit will be unbiased would also require advanced math > to show, but since it's been proven "hard to predict", that would > imply that such a proof does exist. There are two points. First is the terminology. Do you use the normal term, i.e. counting the number of 1's in <x_i>, or do you use LSB for 'parity'? Second, do you negate the possiblity of the cycle length of 'parity' (according to one of the definitions above) being smaller than the cycle length of <x_i>? Thanks. M. K. Shen Subject: Re: OTP using BBS generator? Date: Sat, 19 Aug 2000 22:44:25 GMT From: Tim Tyler <tt@cryogen.com> Message-ID: <FzK9u0.Lo0@bath.ac.uk> References: <3999f249.247190@news.ecn.ab.ca> Newsgroups: sci.crypt Lines: 29 John Savard <jsavard@fnroesepnaemt.edmonton.ab.ca> wrote: : (Mark Wooding) wrote, in part: :>Terry Ritter <ritter@io.com> wrote: :>> That's a wrong answer: The construction as described in BB&S first :>> guarantees that cycles of a given length must exist, and then shows :>> how to check that x0 is on such a cycle. The check is thus absolute :>> proof that a short cycle has not been selected. :>No, it only shows the cycle length for the sequence <x_i>, not the :>sequence of parity bits. : Since the BBS modulus can't be a power of two, I don't think you have : to worry about that. Other contributors seem to think that the possibility of short cycles in the low bits remains. I for one don't see how the nature of the BBS modulus might help prevent cycles in the low bits. Perhaps you're thinking about the type of cycles caused in something like an LCG when the modulus is a power of two. I beleive that this is not the only possible cause of a short cycle in the low bits. -- __________ Lotus Artificial Life http://alife.co.uk/ tt@cryogen.com |im |yler The Mandala Centre http://mandala.co.uk/ Namaste. Subject: Re: OTP using BBS generator? Date: Sun, 20 Aug 2000 04:13:45 +0200 From: Mok-Kong Shen <mok-kong.shen@t-online.de> Message-ID: <399F3ED9.FC81CAF5@t-online.de> References: <FzK9u0.Lo0@bath.ac.uk> Newsgroups: sci.crypt Lines: 31 Tim Tyler wrote: > > I for one don't see how the nature of the BBS modulus might help prevent > cycles in the low bits. I suppose you mean short cycles. BBS's paper has a section devoted to special types of moduli where the cycle length of the output of the congruence relation can be computed from the modulus. BBS states only that the cycle length of LSB must divide the first mentioned cycle length but leaves the exact relationship between the two to be an open question. Thus it seems that one can currently say very little about the cycle length of LSB (even for the special types of moduli), which conforms to what you wrote above. But the proof of the main theorem about the security of BBS (under the assumption of QRA and with proper interpretation of the claim of the theorem) doesn't involve the cycle length of LSB (as far as I can see). So I suppose one could say that BBS's unnecessary investigation of cycle length in their paper has caused confusion that led to much discussions in this thread. The cycle length of LSB of BBS is as a statistical feature on the other hand certainly of interest, if one accepts my humble viewpoint that all bit sequences used in serious applications should conservatively pass all statistical tests available/feasible to the communication partners. M. K. Shen Subject: Re: OTP using BBS generator? Date: 21 Aug 2000 09:35:16 GMT From: mdw@nsict.org (Mark Wooding) Message-ID: <slrn8q1tuk.4et.mdw@mull.ncipher.com> References: <399F3ED9.FC81CAF5@t-online.de> Newsgroups: sci.crypt Lines: 22 Mok-Kong Shen <mok-kong.shen@t-online.de> wrote: > Tim Tyler wrote: > > > > I for one don't see how the nature of the BBS modulus might help prevent > > cycles in the low bits. You missed the bit where I explained exactly how the nature of the BBS modulus can prevent short cycles in the parity bit. Remember that the cycle length of the parity bits must be a factor of the cycle length for the residue sequence, which in turn we know to be a factor of \pimax = \lambda(\lambda(n)). By choosing n appropriately, we can ensure that \pimax is twice the product of some large primes (larger than some chosen bound t). Then, by rejecting a seed which leads to a cycle of length 2, we know that the parity cycle length must be at least t. > BBS states only that the cycle length of LSB must divide the first > mentioned cycle length I don't recall that it actually mentions this. It is an obvious consequence, though. -- [mdw] Subject: Re: OTP using BBS generator? Date: Tue, 22 Aug 2000 09:14:59 GMT From: Tim Tyler <tt@cryogen.com> Message-ID: <FzosCz.H19@bath.ac.uk> References: <slrn8q1tuk.4et.mdw@mull.ncipher.com> Newsgroups: sci.crypt Lines: 25 Mark Wooding <mdw@nsict.org> wrote: :> Tim Tyler wrote: :> > I for one don't see how the nature of the BBS modulus might help prevent :> > cycles in the low bits. : You missed the bit where I explained exactly how the nature of the BBS : modulus can prevent short cycles in the parity bit. Yes, I definitely did. : Remember that the cycle length of the parity bits must be a factor of : the cycle length for the residue sequence, which in turn we know to be : a factor of \pimax = \lambda(\lambda(n)). By choosing n appropriately, : we can ensure that \pimax is twice the product of some large primes : (larger than some chosen bound t). Then, by rejecting a seed which : leads to a cycle of length 2, we know that the parity cycle length must : be at least t. Apart from the fact that cycles of length 1 also apppear to be a possibility to my mind, this sounds very much as though you know what you're talking about ;-) -- __________ http://alife.co.uk/ http://mandala.co.uk/ |im |yler tt@cryogen.com http://hex.org.uk/ http://atoms.org.uk/ Subject: Re: OTP using BBS generator? Date: 22 Aug 2000 09:58:27 GMT From: mdw@nsict.org (Mark Wooding) Message-ID: <slrn8q4jln.4et.mdw@mull.ncipher.com> References: <FzosCz.H19@bath.ac.uk> Newsgroups: sci.crypt Lines: 47 Tim Tyler <tt@cryogen.com> wrote: > Mark Wooding <mdw@nsict.org> wrote: > :> Tim Tyler wrote: > > :> > I for one don't see how the nature of the BBS modulus might help > :> > prevent cycles in the low bits. > > : You missed the bit where I explained exactly how the nature of the > : BBS modulus can prevent short cycles in the parity bit. > > Yes, I definitely did. Fair enough. I can't expect that everyone here reads every message I post. I can't even be bothered to read most of them, so I can't see why anyone else should, really. ;-) Anyway, the article in question is: : From: mdw@nsict.org (Mark Wooding) : Newsgroups: sci.crypt : Subject: Re: OTP using BBS generator? : Date: 16 Aug 2000 09:42:26 GMT : Organization: National Society for the Inversion of Cuddly Tigers : Message-ID: <slrn8pkofr.glm.mdw@mull.ncipher.com> [snip maths] > Apart from the fact that cycles of length 1 also apppear to be a > possibility to my mind, this sounds very much as though you know > what you're talking about ;-) Hmmm. If x = x^2 (mod n) then (taking logs) k = 2 k (mod \lambda(n)). Let's divide through by g = \gcd(k, \lambda(n)). Let k' = k/g, and l = \lambda(n)/g. Then k' = 2 k' (mod l) and \gcd(k', l) = 1. If k' =/= 0 (mod l) then we can multiply by k'^{-1} and we get 1 = 2 (mod l) which won't work. So k is a multiple of \lambda(n). But the antilog of a multiple of \lambda(n) is 1. Hence the only seed with a cycle length of 1 is the multiplicative identity itself. Besides, testing for a period of length 2 will catch a period of length 1 as well. -- [mdw] Subject: Re: OTP using BBS generator? Date: Wed, 16 Aug 2000 03:22:35 GMT From: ritter@io.com (Terry Ritter) Message-ID: <399a08ce.673273@news.io.com> References: <slrn8pite8.glm.mdw@mull.ncipher.com> Newsgroups: sci.crypt Lines: 20 On 15 Aug 2000 16:54:32 GMT, in <slrn8pite8.glm.mdw@mull.ncipher.com>, in sci.crypt mdw@nsict.org (Mark Wooding) wrote: >Terry Ritter <ritter@io.com> wrote: > >> That's a wrong answer: The construction as described in BB&S first >> guarantees that cycles of a given length must exist, and then shows >> how to check that x0 is on such a cycle. The check is thus absolute >> proof that a short cycle has not been selected. > >No, it only shows the cycle length for the sequence <x_i>, not the >sequence of parity bits. Yes. I got carried away on the old issue. Sorry. --- Terry Ritter ritter@io.com http://www.io.com/~ritter/ Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM Subject: Re: OTP using BBS generator? Date: Tue, 15 Aug 2000 21:21:32 +0200 From: Mok-Kong Shen <mok-kong.shen@t-online.de> Message-ID: <3999983C.6C0942DE@t-online.de> References: <399973de.527036@news.io.com> Newsgroups: sci.crypt Lines: 32 Terry Ritter wrote: > > mdw@nsict.org (Mark Wooding) wrote: > > >Mok-Kong Shen <mok-kong.shen@t-online.de> wrote: > >[...] > >> (3) Does the 'check' being disputed really prevent a certian > >> lower bound of the cycle lengths of the LSB sequences > >> (not the direct output of the congruence relation) of > >> being inadvertently 'under-run' or does the check only > >> do that in a probabilistic sense (i.e. with certain > >> probability not equal to 1)? What is that lower bound > >> actually (in relation to p and q)? > > > >It doesn't do anything of the kind. > > That's a wrong answer: The construction as described in BB&S first > guarantees that cycles of a given length must exist, and then shows > how to check that x0 is on such a cycle. The check is thus absolute > proof that a short cycle has not been selected. Excuse me for being hardnecked in asking questions. Does the phrase 'cycles of a given length' refer to cycles of the direct output of the congruence relation or does it refer to cycles of LSB. If it is the former case, then the fact mentioned by David Hopwood implies that one doesn't get results applicable to the cycles of LSB and one would have a problem. M. K. Shen Subject: Re: OTP using BBS generator? Date: Wed, 16 Aug 2000 03:32:41 GMT From: ritter@io.com (Terry Ritter) Message-ID: <399a0b1e.1265156@news.io.com> References: <3999983C.6C0942DE@t-online.de> Newsgroups: sci.crypt Lines: 40 On Tue, 15 Aug 2000 21:21:32 +0200, in <3999983C.6C0942DE@t-online.de>, in sci.crypt Mok-Kong Shen <mok-kong.shen@t-online.de> wrote: >Terry Ritter wrote: >> >> mdw@nsict.org (Mark Wooding) wrote: >> >> >Mok-Kong Shen <mok-kong.shen@t-online.de> wrote: >> >[...] >> >> (3) Does the 'check' being disputed really prevent a certian >> >> lower bound of the cycle lengths of the LSB sequences >> >> (not the direct output of the congruence relation) of >> >> being inadvertently 'under-run' or does the check only >> >> do that in a probabilistic sense (i.e. with certain >> >> probability not equal to 1)? What is that lower bound >> >> actually (in relation to p and q)? >> > >> >It doesn't do anything of the kind. >> >> That's a wrong answer: The construction as described in BB&S first >> guarantees that cycles of a given length must exist, and then shows >> how to check that x0 is on such a cycle. The check is thus absolute >> proof that a short cycle has not been selected. > >Excuse me for being hardnecked in asking questions. Does >the phrase 'cycles of a given length' refer to cycles of >the direct output of the congruence relation or does it >refer to cycles of LSB. If it is the former case, then >the fact mentioned by David Hopwood implies that one >doesn't get results applicable to the cycles of LSB and >one would have a problem. My mistake, I was answering the old question. --- Terry Ritter ritter@io.com http://www.io.com/~ritter/ Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM Subject: Re: OTP using BBS generator? Date: Tue, 08 Aug 2000 23:55:46 +0200 From: Mok-Kong Shen <mok-kong.shen@t-online.de> Message-ID: <399081E2.72945BA8@t-online.de> References: <399034e8.4865622@news.io.com> Newsgroups: sci.crypt Lines: 31 Terry Ritter wrote: > [snip] > Basically, a large portion of the crypto and non-crypto population is > being deceived by the use of technical terms about proof and strength > which do not really mean what a lesser being might think. See also my follow-up of 08 Aug 2000 15:57:03 +0200 in this thread. [snip] > With respect my comment about what the proofs guarantee, it was a > specific response to the last question, which is about > Least-Significant-Bits (LSB's) in particular, not short cycles in > general. I never investigated whether the LSB's form short cycles, > even though I have investigated short cycles in the BB&S system. My > response was that this sort of peculiar special case is exactly what > should be covered by a proof, and in his recent message, Bryan seemed > to indicate just that: The cycle length of LSB of the output definitely cannot be longer but can very probably be much shorter than the cycle length of the output itself. If BBS's article has no treatment of that, then one is in effect using something not yet fully understood, when one uses LSB of BBS in one's applications. This point should not be forgotten, if ever on a future occasion BBS is again discussed in the group. M. K. Shen Subject: Re: OTP using BBS generator? Date: Wed, 09 Aug 2000 00:05:18 GMT From: ritter@io.com (Terry Ritter) Message-ID: <3990a002.1905423@news.io.com> References: <399081E2.72945BA8@t-online.de> Newsgroups: sci.crypt Lines: 64 On Tue, 08 Aug 2000 23:55:46 +0200, in <399081E2.72945BA8@t-online.de>, in sci.crypt Mok-Kong Shen <mok-kong.shen@t-online.de> wrote: >Terry Ritter wrote: >> >[snip] >> Basically, a large portion of the crypto and non-crypto population is >> being deceived by the use of technical terms about proof and strength >> which do not really mean what a lesser being might think. > >See also my follow-up of 08 Aug 2000 15:57:03 +0200 in this >thread. I would find it much easier to understand your position if you would post a SHORT summary, and then a true message ID, instead of date and time. >[snip] >> With respect my comment about what the proofs guarantee, it was a >> specific response to the last question, which is about >> Least-Significant-Bits (LSB's) in particular, not short cycles in >> general. I never investigated whether the LSB's form short cycles, >> even though I have investigated short cycles in the BB&S system. My >> response was that this sort of peculiar special case is exactly what >> should be covered by a proof, and in his recent message, Bryan seemed >> to indicate just that: > >The cycle length of LSB of the output definitely cannot be >longer but can very probably be much shorter than the cycle >length of the output itself. If BBS's article has no treatment >of that, then one is in effect using something not yet fully >understood, when one uses LSB of BBS in one's applications. The LSB of the x^2 mod N result *is* the output of BB&S. If a cycle of LSB's could be shorter than the cycle itself, BB&S would be seriously damaged. To the extent that there is a proof of BB&S, that proof must cover this situation, because this *is* BB&S. I demonstrated that short cycles do exist in BB&S a decade ago, and that result is now widely accepted. BB&S of course knew all about it, but my work was based directly on an attempt to understand what the latter 2/3 of the BB&S article could possibly be about. I guess it must be just a coincidence that the last part of the article shows how to avoid the short-cycle problem. My take on that is that BB&S themselves considered it very important. >This point should not be forgotten, if ever on a future occasion >BBS is again discussed in the group. If this discussion has not presented you with sufficient information from which to understand the situation and make a decision, it seems quite unlikely that any future discussion will do any better. You can work out the structure of x * x mod N, for N = P * Q = 23 * 47 = 1081 as well as anyone else; you just have to take the time to do it. Then you would not have to believe anyone but yourself. --- Terry Ritter ritter@io.com http://www.io.com/~ritter/ Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM Subject: Re: OTP using BBS generator? Date: Wed, 09 Aug 2000 09:16:42 +0200 From: Mok-Kong Shen <mok-kong.shen@t-online.de> Message-ID: <3991055A.D5559DBD@t-online.de> References: <3990a002.1905423@news.io.com> Newsgroups: sci.crypt Lines: 52 Terry Ritter wrote: > > <mok-kong.shen@t-online.de> wrote: > > >Terry Ritter wrote: > >> > >[snip] > >> Basically, a large portion of the crypto and non-crypto population is > >> being deceived by the use of technical terms about proof and strength > >> which do not really mean what a lesser being might think. > > > >See also my follow-up of 08 Aug 2000 15:57:03 +0200 in this > >thread. > > I would find it much easier to understand your position if you would > post a SHORT summary, and then a true message ID, instead of date and > time. Sorry, but I am ignorant of how to get the message ID (I use Netscape with Window 98). Could someone please tell me that? > > >[snip] > >> With respect my comment about what the proofs guarantee, it was a > >> specific response to the last question, which is about > >> Least-Significant-Bits (LSB's) in particular, not short cycles in > >> general. I never investigated whether the LSB's form short cycles, > >> even though I have investigated short cycles in the BB&S system. My > >> response was that this sort of peculiar special case is exactly what > >> should be covered by a proof, and in his recent message, Bryan seemed > >> to indicate just that: > > > >The cycle length of LSB of the output definitely cannot be > >longer but can very probably be much shorter than the cycle > >length of the output itself. If BBS's article has no treatment > >of that, then one is in effect using something not yet fully > >understood, when one uses LSB of BBS in one's applications. > > The LSB of the x^2 mod N result *is* the output of BB&S. If a cycle > of LSB's could be shorter than the cycle itself, BB&S would be > seriously damaged. To the extent that there is a proof of BB&S, that > proof must cover this situation, because this *is* BB&S. I should very much appreciate it, if some expert would confirm that the issue is indeed well taken care of in the article of BBS, giving the page number for others to look at. This is EXTREMELY important, for otherwise BBS would be strongly devaluated in its application. M. K. Shen Subject: Re: OTP using BBS generator? Date: 9 Aug 2000 21:20:03 -0000 From: lcs Mixmaster Remailer <mix@anon.lcs.mit.edu> Message-ID: <20000809212003.18231.qmail@nym.alias.net> References: <3990a002.1905423@news.io.com> Newsgroups: sci.crypt Lines: 30 Terry Ritter writes: > The LSB of the x^2 mod N result *is* the output of BB&S. If a cycle > of LSB's could be shorter than the cycle itself, BB&S would be > seriously damaged. To the extent that there is a proof of BB&S, that > proof must cover this situation, because this *is* BB&S. This is correct. It is frustrating that you have come so close here to understanding the position of those who have been arguing against you for so many years. You need only expand your argument to say, that if a cycle of outputs were short enough to be found in practice, BB&S would be seriously damaged. And then, as you say, "To the extent that there is a proof of BB&S, that proof must cover this situation, because this *is* BB&S." The point being, that if anyone could feasibly find short cycles when using intractably large RSA moduli (other than trivial cases like x=1 or -1), that would invalidate the BB&S proofs. But by the proof, we know that this is impossible (assuming that quadratic reciduosity is hard, which virtually everyone agrees with). (Actually, previous discussions on sci.crypt have shown that short cycles are infeasible to find even assuming the factoring problem, which everyone who uses RSA agrees is intractable.) One other point, because it keeps coming up. The toy example of 1081 = 23*47 is meaningless in evaluating the *tractability* of finding short cycles. Factoring 1081 is trivial. Hence the proof which reduces finding cycles to factoring will not apply, because factoring a number of this size is not difficult. You might as well try to evaluate the security of AES by cutting it down to something with a 10 bit key. Subject: Re: OTP using BBS generator? Date: Thu, 10 Aug 2000 00:11:06 -0400 From: "Trevor L. Jackson, III" <fullmoon@aspi.net> Message-ID: <39922B5A.516EC185@aspi.net> References: <20000809212003.18231.qmail@nym.alias.net> Newsgroups: sci.crypt Lines: 39 lcs Mixmaster Remailer wrote: > Terry Ritter writes: > > The LSB of the x^2 mod N result *is* the output of BB&S. If a cycle > > of LSB's could be shorter than the cycle itself, BB&S would be > > seriously damaged. To the extent that there is a proof of BB&S, that > > proof must cover this situation, because this *is* BB&S. > > This is correct. It is frustrating that you have come so close here to > understanding the position of those who have been arguing against you > for so many years. > > You need only expand your argument to say, that if a cycle of outputs were > short enough to be found in practice, BB&S would be seriously damaged. > And then, as you say, "To the extent that there is a proof of BB&S, > that proof must cover this situation, because this *is* BB&S." > > The point being, that if anyone could feasibly find short cycles when > using intractably large RSA moduli (other than trivial cases like x=1 or > -1), that would invalidate the BB&S proofs. Interesting verb: "find". AFAICT the issue is not finding short cycles by searching for them, but finding a short cycle in the "oops" sense of having inadvertently selected one for use. The practical impossibility of finding one on purpose is independent of the theoretical possibility of finding one by accident. The purpose of the BBS proofs is to show that the opponent is in all cases faced with the impracticality of finding the factors. If the checks for short cycles are ignored then the security of the system relies upon the insignificance of the odds of accidentally selecting a short cycle. But the odds of selecting a short cycle are _not_ as long as the odds of finding the factors of a long cycle. Thus the system without a short cycle check does not promise the same theoretical security as a system with the check. It may offer the same practical security if the odds of selecting a short cycle are of the once-in-the-life-of-the-universe kind. But though the odds are small in both cases they aren't the same. Subject: Re: OTP using BBS generator? Date: 10 Aug 2000 11:01:17 GMT From: mdw@nsict.org (Mark Wooding) Message-ID: <slrn8p52rt.ti5.mdw@mull.ncipher.com> References: <39922B5A.516EC185@aspi.net> Newsgroups: sci.crypt Lines: 19 Trevor L. Jackson, III <fullmoon@aspi.net> wrote: > Interesting verb: "find". AFAICT the issue is not finding short > cycles by searching for them, but finding a short cycle in the "oops" > sense of having inadvertently selected one for use. The practical > impossibility of finding one on purpose is independent of the > theoretical possibility of finding one by accident. Errr... no. If finding X by trying very hard is impractically difficult, then finding X by accidentally tripping over it must be at least as difficult. Otherwise, I have the algorithm for finding X by trying very hard: pick possible values at random and hope to trip over one by accident. This must work unless X can read minds and is deliberately perverse. -- [mdw] Subject: Re: OTP using BBS generator? Date: Thu, 10 Aug 2000 08:50:54 -0500 From: Doug Kuhlman <dougk@labs.mot.com> Message-ID: <3992B33E.475D9439@labs.mot.com> References: <slrn8p52rt.ti5.mdw@mull.ncipher.com> Newsgroups: sci.crypt Lines: 26 Mark Wooding wrote: > > Trevor L. Jackson, III <fullmoon@aspi.net> wrote: > > > Interesting verb: "find". AFAICT the issue is not finding short > > cycles by searching for them, but finding a short cycle in the "oops" > > sense of having inadvertently selected one for use. The practical > > impossibility of finding one on purpose is independent of the > > theoretical possibility of finding one by accident. > > Errr... no. > > If finding X by trying very hard is impractically difficult, then > finding X by accidentally tripping over it must be at least as > difficult. Otherwise, I have the algorithm for finding X by trying very > hard: pick possible values at random and hope to trip over one by > accident. This must work unless X can read minds and is deliberately > perverse. > > -- [mdw] I want that X...the deliberately perverse one! ;-) Doug Subject: Re: OTP using BBS generator? Date: 10 Aug 2000 15:03:24 GMT From: mdw@nsict.org (Mark Wooding) Message-ID: <slrn8p5h1s.ti5.mdw@mull.ncipher.com> References: <3992B33E.475D9439@labs.mot.com> Newsgroups: sci.crypt Lines: 7 Doug Kuhlman <dougk@labs.mot.com> wrote: > I want that X...the deliberately perverse one! ;-) It already runs on millions of Unix boxes... -- [mdw] Subject: Re: OTP using BBS generator? Date: Thu, 10 Aug 2000 17:48:36 GMT From: ritter@io.com (Terry Ritter) Message-ID: <3992eae4.3949738@news.io.com> References: <slrn8p52rt.ti5.mdw@mull.ncipher.com> Newsgroups: sci.crypt Lines: 46 On 10 Aug 2000 11:01:17 GMT, in <slrn8p52rt.ti5.mdw@mull.ncipher.com>, in sci.crypt mdw@nsict.org (Mark Wooding) wrote: >Trevor L. Jackson, III <fullmoon@aspi.net> wrote: > >> Interesting verb: "find". AFAICT the issue is not finding short >> cycles by searching for them, but finding a short cycle in the "oops" >> sense of having inadvertently selected one for use. The practical >> impossibility of finding one on purpose is independent of the >> theoretical possibility of finding one by accident. > >Errr... no. > >If finding X by trying very hard is impractically difficult, then >finding X by accidentally tripping over it must be at least as >difficult. "Errr... no" yourself: Difficulty is not the issue. There is no difficulty for an opponent, just waiting. There is no difficulty for us either: we just choose. When we choose at random there is always the chance of choosing the improbable. That's what "improbable" means as distinguished from "impossible." If short cycles are not excluded, they will be chosen, sooner or later. Then we are using weakness, even if we assume factoring is hard. So the assumption has not bought us what we wanted it to. >Otherwise, I have the algorithm for finding X by trying very >hard: pick possible values at random and hope to trip over one by >accident. This must work unless X can read minds and is deliberately >perverse. No. This is not about an algorithm for an attack. It is about leaving weakness in the signal we send. Just as it would not be acceptable to leave plaintext between our impossible-to-break ciphertext, it is also not acceptable to every once in a while have a breakable result that we can prevent. Calling that "proven secure" is just adding insult to the injury. --- Terry Ritter ritter@io.com http://www.io.com/~ritter/ Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM Subject: Re: OTP using BBS generator? Date: Thu, 10 Aug 2000 15:27:54 -0400 From: "Trevor L. Jackson, III" <fullmoon@aspi.net> Message-ID: <3993023A.C4303749@aspi.net> References: <slrn8p52rt.ti5.mdw@mull.ncipher.com> Newsgroups: sci.crypt Lines: 31 Mark Wooding wrote: > Trevor L. Jackson, III <fullmoon@aspi.net> wrote: > > > Interesting verb: "find". AFAICT the issue is not finding short > > cycles by searching for them, but finding a short cycle in the "oops" > > sense of having inadvertently selected one for use. The practical > > impossibility of finding one on purpose is independent of the > > theoretical possibility of finding one by accident. > > Errr... no. > > If finding X by trying very hard is impractically difficult, then > finding X by accidentally tripping over it must be at least as > difficult. Otherwise, I have the algorithm for finding X by trying very > hard: pick possible values at random and hope to trip over one by > accident. This must work unless X can read minds and is deliberately > perverse. Two conterclaims: 1) The space of short cycles is _larger_ than the space of factors to evaluate. This it is not as hard to pick a bad (short) key as it is to find the factors of a long cycle. I'm interested in detailed refutations of this claim if you are able to mention any. 2) The proposed algorithm fails because "tripping over X" works by finding _any_ short X rather than _the_ X selected. This appears obvious. Am I being stupid? Subject: Re: OTP using BBS generator? Date: 11 Aug 2000 10:11:15 GMT From: mdw@nsict.org (Mark Wooding) Message-ID: <slrn8p7ka3.ti5.mdw@mull.ncipher.com> References: <3993023A.C4303749@aspi.net> Newsgroups: sci.crypt Lines: 38 Trevor L. Jackson, III <fullmoon@aspi.net> wrote: > Mark Wooding wrote: > > > Trevor L. Jackson, III <fullmoon@aspi.net> wrote: > > > > > Interesting verb: "find". AFAICT the issue is not finding short > > > cycles by searching for them, but finding a short cycle in the "oops" > > > sense of having inadvertently selected one for use. The practical > > > impossibility of finding one on purpose is independent of the > > > theoretical possibility of finding one by accident. > > > > Errr... no. > > > > If finding X by trying very hard is impractically difficult, then > > finding X by accidentally tripping over it must be at least as > > difficult. Otherwise, I have the algorithm for finding X by trying very > > hard: pick possible values at random and hope to trip over one by > > accident. This must work unless X can read minds and is deliberately > > perverse. > > Two conterclaims: > > 1) The space of short cycles is _larger_ than the space of factors to > evaluate. This it is not as hard to pick a bad (short) key as it is > to find the factors of a long cycle. I'm interested in detailed > refutations of this claim if you are able to mention any. I'm confused by your terminology. What is a bad (short) key' here? What are the factors of a long cycle'? > 2) The proposed algorithm fails because "tripping over X" works by > finding _any_ short X rather than _the_ X selected. This appears > obvious. Am I being stupid? In the above, in both cases, X' is any element of Q_n which lies on a short cycle'. Who do you think is doing the selection of _the_ X'? -- [mdw] Subject: Re: OTP using BBS generator? Date: Fri, 11 Aug 2000 15:50:32 -0400 From: "Trevor L. Jackson, III" <fullmoon@aspi.net> Message-ID: <39945908.74800E3D@aspi.net> References: <slrn8p7ka3.ti5.mdw@mull.ncipher.com> Newsgroups: sci.crypt Lines: 44 I think the other message regarding terminology is the more fruitful discussion, so I'll let this one die. Mark Wooding wrote: > Trevor L. Jackson, III <fullmoon@aspi.net> wrote: > > Mark Wooding wrote: > > > > > Trevor L. Jackson, III <fullmoon@aspi.net> wrote: > > > > > > > Interesting verb: "find". AFAICT the issue is not finding short > > > > cycles by searching for them, but finding a short cycle in the "oops" > > > > sense of having inadvertently selected one for use. The practical > > > > impossibility of finding one on purpose is independent of the > > > > theoretical possibility of finding one by accident. > > > > > > Errr... no. > > > > > > If finding X by trying very hard is impractically difficult, then > > > finding X by accidentally tripping over it must be at least as > > > difficult. Otherwise, I have the algorithm for finding X by trying very > > > hard: pick possible values at random and hope to trip over one by > > > accident. This must work unless X can read minds and is deliberately > > > perverse. > > > > Two conterclaims: > > > > 1) The space of short cycles is _larger_ than the space of factors to > > evaluate. This it is not as hard to pick a bad (short) key as it is > > to find the factors of a long cycle. I'm interested in detailed > > refutations of this claim if you are able to mention any. > > I'm confused by your terminology. What is a bad (short) key' here? > What are the factors of a long cycle'? > > > 2) The proposed algorithm fails because "tripping over X" works by > > finding _any_ short X rather than _the_ X selected. This appears > > obvious. Am I being stupid? > > In the above, in both cases, X' is any element of Q_n which lies on a > short cycle'. Who do you think is doing the selection of _the_ X'? > > -- [mdw] Subject: Re: OTP using BBS generator? Date: Fri, 11 Aug 2000 04:49:56 +0100 From: David Hopwood <hopwood@zetnet.co.uk> Message-ID: <399377E4.5E701376@zetnet.co.uk> References: <39922B5A.516EC185@aspi.net> Newsgroups: sci.crypt Lines: 92 -----BEGIN PGP SIGNED MESSAGE----- "Trevor L. Jackson, III" wrote: > lcs Mixmaster Remailer wrote: > > Terry Ritter writes: > > > The LSB of the x^2 mod N result *is* the output of BB&S. If a cycle > > > of LSB's could be shorter than the cycle itself, BB&S would be > > > seriously damaged. To the extent that there is a proof of BB&S, that > > > proof must cover this situation, because this *is* BB&S. > > > > This is correct. It is frustrating that you have come so close here to > > understanding the position of those who have been arguing against you > > for so many years. > > > > You need only expand your argument to say, that if a cycle of outputs were > > short enough to be found in practice, BB&S would be seriously damaged. > > And then, as you say, "To the extent that there is a proof of BB&S, > > that proof must cover this situation, because this *is* BB&S." > > > > The point being, that if anyone could feasibly find short cycles when > > using intractably large RSA moduli (other than trivial cases like x=1 or > > -1), that would invalidate the BB&S proofs. > > Interesting verb: "find". AFAICT the issue is not finding short cycles by > searching for them, but finding a short cycle in the "oops" sense of having > inadvertently selected one for use. The practical impossibility of finding > one on purpose is independent of the theoretical possibility of finding one by > accident. No; the impracticality of finding one on purpose *implies* that there is negligable probability of selecting one by accident, because we can assume without loss of generality that the attacker is able to test sequences for short cycles at at least the same rate as a legitimate user can select and use sequences. IOW, if the user has a non-negligable probability of selecting a short cycle, then the attacker has a non-negligable probability of finding one, and that would contradict the assumption that factoring moduli of the size being used is intractible. Note that the proofs in the BBS paper (and in the Crypto '84 paper by Vazirani and Vazirani proving a reduction to factoring) are all asymptotic, so unfortunately we can't make stronger statements relating the exact probability of being able to distinguish the BBS output from random with a specific amount of work, to the probability of being able to factor or solve the QRP with a similar amount of work (at least, not based on those proofs). But if the underlying question being debated in this thread is about the general validity of probabilistic proof, rather than its application to BBS in particular, then there are plenty of other cryptosystems for which exact reductions have been proven. > The purpose of the BBS proofs is to show that the opponent is in > all cases faced with the impracticality of finding the factors. If the checks > for short cycles are ignored then the security of the system relies upon the > insignificance of the odds of accidentally selecting a short cycle. But the > odds of selecting a short cycle are _not_ as long as the odds of finding the > factors of a long cycle. Yes they are. In practice attackers are able to use factoring methods that are much more efficient than finding cycles, but even if they could not, we would need to assume that an attacker can test seeds much faster than a legitimate user can. In that case, the odds of selecting a short cycle must be longer than the odds of this attacker finding such a cycle. If the attacker is assumed to be as fast as all the users of the system in aggregate (i.e. we can choose a modulus length that would be secure against factoring by such an attacker), than a similar statement can be made about the odds of *any* user selecting a short cycle. - -- David Hopwood <hopwood@zetnet.co.uk> Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/ RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01 Nothing in this message is intended to be legally binding. If I revoke a public key but refuse to specify why, it is because the private key has been seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv iQEVAwUBOZLjeDkCAxeYt5gVAQHCBwf+JWT0synF1Fa4jpdb37y1q0BSn5Gct5RF 2yBBfcxIcJ94uTXNpVhoOCgYRTYqd1nrk38GDI5DYwX2TvaKsTpX5n8HoetGkviy tVAE5531VfBZvJbpKvJyMZaQeTTYgvgciAgvgdvx/tbn4tAm84dGlNIkHxNaNMRb sGEeyp6XScXcbH6xXdsc7wz0NHbfO5DvqDE6G9wX87Bhawpgj5S7WuiobRDGbHrE neu5hUWuPOOlWKbilIezHAM0sqETWVmuWRTDtB5aGDXgz10dF62hBA8QmyBaDDW7 c9Q0RlArne5JWz/FOTR6+8gIOSn41l2VovrZWHwWFdo6CIolk5wCYw== =3Kle -----END PGP SIGNATURE----- Subject: Re: OTP using BBS generator? Date: Thu, 10 Aug 2000 17:54:18 GMT From: ritter@io.com (Terry Ritter) Message-ID: <3992ec0b.4245145@news.io.com> References: <399377E4.5E701376@zetnet.co.uk> Newsgroups: sci.crypt Lines: 83 On Fri, 11 Aug 2000 04:49:56 +0100, in <399377E4.5E701376@zetnet.co.uk>, in sci.crypt David Hopwood <hopwood@zetnet.co.uk> wrote: >-----BEGIN PGP SIGNED MESSAGE----- > >"Trevor L. Jackson, III" wrote: >> lcs Mixmaster Remailer wrote: >> > Terry Ritter writes: >> > > The LSB of the x^2 mod N result *is* the output of BB&S. If a cycle >> > > of LSB's could be shorter than the cycle itself, BB&S would be >> > > seriously damaged. To the extent that there is a proof of BB&S, that >> > > proof must cover this situation, because this *is* BB&S. >> > >> > This is correct. It is frustrating that you have come so close here to >> > understanding the position of those who have been arguing against you >> > for so many years. >> > >> > You need only expand your argument to say, that if a cycle of outputs were >> > short enough to be found in practice, BB&S would be seriously damaged. >> > And then, as you say, "To the extent that there is a proof of BB&S, >> > that proof must cover this situation, because this *is* BB&S." >> > >> > The point being, that if anyone could feasibly find short cycles when >> > using intractably large RSA moduli (other than trivial cases like x=1 or >> > -1), that would invalidate the BB&S proofs. >> >> Interesting verb: "find". AFAICT the issue is not finding short cycles by >> searching for them, but finding a short cycle in the "oops" sense of having >> inadvertently selected one for use. The practical impossibility of finding >> one on purpose is independent of the theoretical possibility of finding one by >> accident. > >No; the impracticality of finding one on purpose *implies* that there is >negligable probability of selecting one by accident, because we can assume >without loss of generality that the attacker is able to test sequences for >short cycles at at least the same rate as a legitimate user can select and >use sequences. No; a "negligable probability" means that some probability remains. And with random selection, that result will eventually occur. >IOW, if the user has a non-negligable probability of selecting a short cycle, >then the attacker has a non-negligable probability of finding one, and that >would contradict the assumption that factoring moduli of the size being used >is intractible. That logic is wrong. If there is a possibility of choosing a short cycle, that *will* happen, sooner or later. Then the attacker *can* factor N, which contradicts the assumption. It is *not* difficult to factor N . . . if we give a factor away. To even attempt to assume that factoring is difficult *implies* that the system be constructed in such a way as to not give away the secret. And a proper construction happens with BB&S (as far as I know), only when short cycles are excluded from use. >Note that the proofs in the BBS paper (and in the Crypto '84 paper by Vazirani >and Vazirani proving a reduction to factoring) are all asymptotic, so >unfortunately we can't make stronger statements relating the exact probability >of being able to distinguish the BBS output from random with a specific amount >of work, to the probability of being able to factor or solve the QRP with a >similar amount of work (at least, not based on those proofs). But if the >underlying question being debated in this thread is about the general validity >of probabilistic proof, rather than its application to BBS in particular, then >there are plenty of other cryptosystems for which exact reductions have been >proven. I have no problem with a probabilistic proof. But what we can get from it is that something is "almost always secure." The very reason we don't have an ordinary proof is that we *know* that sometimes the system is weak. Were this to be explained as it really is, I doubt that many users would be happy with the phrase "proven secure." --- Terry Ritter ritter@io.com http://www.io.com/~ritter/ Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM Subject: Re: OTP using BBS generator? Date: Thu, 10 Aug 2000 13:51:58 -0500 From: Doug Kuhlman <dougk@labs.mot.com> Message-ID: <3992F9CD.221E5588@labs.mot.com> References: <3992ec0b.4245145@news.io.com> Newsgroups: sci.crypt Lines: 32 Terry Ritter wrote: > <SNIP> > > No; a "negligable probability" means that some probability remains. > And with random selection, that result will eventually occur. > You should know better than that. The probability that the sound of air coming through a naturally shaped tunnel will play the entire VeggieTales collection is non-zero, but it's not gonna happen in the lifetime of the universe. Same thing applies here. > > That logic is wrong. If there is a possibility of choosing a short > cycle, that *will* happen, sooner or later. Then the attacker *can* > factor N, which contradicts the assumption. > You consistently confuse possibility with probability and claim that one is the other. Read above. > > Were this to be explained as it really is, I doubt that many users > would be happy with the phrase "proven secure." > Well, if the other issues could be cleaned up (like how the size of the overall cycle corresponds with that of the LSB cycle), I think almost everyone would, if they really understood what "neglible" likelihood meant. Doug Subject: Re: OTP using BBS generator? Date: Thu, 10 Aug 2000 21:02:16 GMT From: ritter@io.com (Terry Ritter) Message-ID: <3993182c.2178426@news.io.com> References: <3992F9CD.221E5588@labs.mot.com> Newsgroups: sci.crypt Lines: 59 On Thu, 10 Aug 2000 13:51:58 -0500, in <3992F9CD.221E5588@labs.mot.com>, in sci.crypt Doug Kuhlman <dougk@labs.mot.com> wrote: >Terry Ritter wrote: >> ><SNIP> >> >> No; a "negligable probability" means that some probability remains. >> And with random selection, that result will eventually occur. >> >You should know better than that. The probability that the sound of air >coming through a naturally shaped tunnel will play the entire >VeggieTales collection is non-zero, but it's not gonna happen in the >lifetime of the universe. Same thing applies here. Sorry, but *you* should know better than that. None of this is about weakness in practice, it is about falsely appearing to claim strength on the basis of mathematical proof. The short-cycle weakness is a theoretical weakness in the sense that it almost never occurs in practice. But it is a practical weakness in the sense that the reason to use BB&S in practice is to achieve the results of the theoretical claim. But theoretically, if long cycle operation is not guaranteed, short cycle operation will occur, and the "proven secure" system will be insecure, sooner or later. >> That logic is wrong. If there is a possibility of choosing a short >> cycle, that *will* happen, sooner or later. Then the attacker *can* >> factor N, which contradicts the assumption. >> >You consistently confuse possibility with probability and claim that one >is the other. Read above. Nope, that seems to be *your* problem: Possibility and probability are statistical terms. If something is *possible* under random selection, it eventually *will* *happen*. This concept is important and you need to understand it. The same concept occurs in computer programming. >> Were this to be explained as it really is, I doubt that many users >> would be happy with the phrase "proven secure." >> >Well, if the other issues could be cleaned up (like how the size of the >overall cycle corresponds with that of the LSB cycle), I think almost >everyone would, if they really understood what "neglible" likelihood >meant. So, basically, you are fine with changing the current description of "proven secure," to "proven to have a negligible likelihood of weakness." That's not as straightforward as "almost always secure," but it is an improvement. --- Terry Ritter ritter@io.com http://www.io.com/~ritter/ Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM Subject: Re: OTP using BBS generator? Date: Tue, 15 Aug 2000 13:40:38 -0500 From: Doug Kuhlman <dougk@labs.mot.com> Message-ID: <39998EA6.B1E31BBD@labs.mot.com> References: <3993182c.2178426@news.io.com> Newsgroups: sci.crypt Lines: 57 Terry Ritter wrote: > > On Thu, 10 Aug 2000 13:51:58 -0500, in > <3992F9CD.221E5588@labs.mot.com>, in sci.crypt Doug Kuhlman > <dougk@labs.mot.com> wrote: > > >Terry Ritter wrote: > >> > ><SNIP> > >> > >> No; a "negligable probability" means that some probability remains. > >> And with random selection, that result will eventually occur. > >> > >You should know better than that. The probability that the sound of air > >coming through a naturally shaped tunnel will play the entire > >VeggieTales collection is non-zero, but it's not gonna happen in the > >lifetime of the universe. Same thing applies here. > > Sorry, but *you* should know better than that. None of this is about > weakness in practice, it is about falsely appearing to claim strength > on the basis of mathematical proof. The short-cycle weakness is a > theoretical weakness in the sense that it almost never occurs in > practice. But it is a practical weakness in the sense that the reason > to use BB&S in practice is to achieve the results of the theoretical > claim. But theoretically, if long cycle operation is not guaranteed, > short cycle operation will occur, and the "proven secure" system will > be insecure, sooner or later. > <SNIP> > Nope, that seems to be *your* problem: Possibility and probability > are statistical terms. If something is *possible* under random > selection, it eventually *will* *happen*. This concept is important > and you need to understand it. The same concept occurs in computer > programming. > > First you argue that you're not claiming it's a weakness in practice and less than a page later, you're trying to claim that it will happen. Which is it? Can you pick the right atom of the Earth in the exact millisecond of the day? Your odds of landing on a short cycle are worse. "Can happen" is not the same as "will happen". Lots of things can happen, very few actually do or even will happen. > <SNIP> > So, basically, you are fine with changing the current description of > "proven secure," to "proven to have a negligible likelihood of > weakness." That's not as straightforward as "almost always secure," > but it is an improvement. > Sure! Always a chance of weakness. Maybe some hotshot will figure out how to factor arbitrarily large numbers in constant time. All kinds of things are potential weaknesses. The possibility of landing on a short cycle is the least of my concerns (about BBS). Doug Subject: Re: OTP using BBS generator? Date: Tue, 15 Aug 2000 18:34:08 -0400 From: "Trevor L. Jackson, III" <fullmoon@aspi.net> Message-ID: <3999C560.3105C927@aspi.net> References: <39998EA6.B1E31BBD@labs.mot.com> Newsgroups: sci.crypt Lines: 49 Doug Kuhlman wrote: > Terry Ritter wrote: > > > > On Thu, 10 Aug 2000 13:51:58 -0500, in > > <3992F9CD.221E5588@labs.mot.com>, in sci.crypt Doug Kuhlman > > <dougk@labs.mot.com> wrote: > > > > >Terry Ritter wrote: > > >> > > ><SNIP> > > >> > > >> No; a "negligable probability" means that some probability remains. > > >> And with random selection, that result will eventually occur. > > >> > > >You should know better than that. The probability that the sound of air > > >coming through a naturally shaped tunnel will play the entire > > >VeggieTales collection is non-zero, but it's not gonna happen in the > > >lifetime of the universe. Same thing applies here. > > > > Sorry, but *you* should know better than that. None of this is about > > weakness in practice, it is about falsely appearing to claim strength > > on the basis of mathematical proof. The short-cycle weakness is a > > theoretical weakness in the sense that it almost never occurs in > > practice. But it is a practical weakness in the sense that the reason > > to use BB&S in practice is to achieve the results of the theoretical > > claim. But theoretically, if long cycle operation is not guaranteed, > > short cycle operation will occur, and the "proven secure" system will > > be insecure, sooner or later. > > <SNIP> > > Nope, that seems to be *your* problem: Possibility and probability > > are statistical terms. If something is *possible* under random > > selection, it eventually *will* *happen*. This concept is important > > and you need to understand it. The same concept occurs in computer > > programming. > > > > > First you argue that you're not claiming it's a weakness in practice and > less than a page later, you're trying to claim that it will happen. > Which is it? > Can you pick the right atom of the Earth in the exact millisecond of the > day? Your odds of landing on a short cycle are worse. Can you provide some number/formulae that describe the incidence of short cycles for a typical BBS generator? Subject: Re: OTP using BBS generator? Date: Wed, 16 Aug 2000 04:19:52 GMT From: ritter@io.com (Terry Ritter) Message-ID: <399a1640.4114901@news.io.com> References: <39998EA6.B1E31BBD@labs.mot.com> Newsgroups: sci.crypt Lines: 104 On Tue, 15 Aug 2000 13:40:38 -0500, in <39998EA6.B1E31BBD@labs.mot.com>, in sci.crypt Doug Kuhlman <dougk@labs.mot.com> wrote: >Terry Ritter wrote: >> >> On Thu, 10 Aug 2000 13:51:58 -0500, in >> <3992F9CD.221E5588@labs.mot.com>, in sci.crypt Doug Kuhlman >> <dougk@labs.mot.com> wrote: >> >> >Terry Ritter wrote: >> >> >> ><SNIP> >> >> >> >> No; a "negligable probability" means that some probability remains. >> >> And with random selection, that result will eventually occur. >> >> >> >You should know better than that. The probability that the sound of air >> >coming through a naturally shaped tunnel will play the entire >> >VeggieTales collection is non-zero, but it's not gonna happen in the >> >lifetime of the universe. Same thing applies here. >> >> Sorry, but *you* should know better than that. None of this is about >> weakness in practice, it is about falsely appearing to claim strength >> on the basis of mathematical proof. The short-cycle weakness is a >> theoretical weakness in the sense that it almost never occurs in >> practice. But it is a practical weakness in the sense that the reason >> to use BB&S in practice is to achieve the results of the theoretical >> claim. But theoretically, if long cycle operation is not guaranteed, >> short cycle operation will occur, and the "proven secure" system will >> be insecure, sooner or later. >> <SNIP> >> Nope, that seems to be *your* problem: Possibility and probability >> are statistical terms. If something is *possible* under random >> selection, it eventually *will* *happen*. This concept is important >> and you need to understand it. The same concept occurs in computer >> programming. >> >> >First you argue that you're not claiming it's a weakness in practice and >less than a page later, you're trying to claim that it will happen. >Which is it? Both. >Can you pick the right atom of the Earth in the exact millisecond of the >day? Your odds of landing on a short cycle are worse. "Can happen" is >not the same as "will happen". Lots of things can happen, very few >actually do or even will happen. I guess we need to step back a bit and take a look at the larger context of all this: One of the advantages of analysis is to address things which are too infrequent to be detected reliably from experiment. But even low probability things do in fact happen; if not, they would be "impossible," instead of "rare." We typically think of cryptographic strength as the minimum effort needed for any possible attack to expose the protected information or keys. Cryptographic strength is thus concerned with statements about guaranteed minimum strength, instead of strength on average. Such statements are not usually available with conventional ciphers, which is a major motivation for mathematical proofs of strength. It now appears that current cryptographic proofs do not give us realistic lower bounds on strength even in the best possible case. But short cycles present a clear and known weakness. Any system which allows use of short cycles cannot be guaranteed to have any more strength than a short cycle, no matter what other theoretical advances may occur. So, "merely" by arranging to not use a short cycle, we can at least say that we know of no weakness significantly lower than the strength we get from long cycles. In the context of grasping for whatever guarantees we can get, a guarantee to not use short cycles, and so not have a known weakness at that level, is a serious advantage. >> <SNIP> >> So, basically, you are fine with changing the current description of >> "proven secure," to "proven to have a negligible likelihood of >> weakness." That's not as straightforward as "almost always secure," >> but it is an improvement. >> >Sure! Always a chance of weakness. Maybe some hotshot will figure out >how to factor arbitrarily large numbers in constant time. All kinds of >things are potential weaknesses. The possibility of landing on a short >cycle is the least of my concerns (about BBS). Because short cycles are typically very hard to find, they probably do not represent a significant weakness in practice. However, allowing the possibility of using short cycles in BB&S does represent a lack of will to address a known weakness and prevent that from happening. The best possible guarantee of strength for such a system is the weakness of a short cycle. --- Terry Ritter ritter@io.com http://www.io.com/~ritter/ Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM Subject: Re: OTP using BBS generator? Date: Thu, 10 Aug 2000 05:07:21 GMT From: ritter@io.com (Terry Ritter) Message-ID: <399237c5.6176029@news.io.com> References: <20000809212003.18231.qmail@nym.alias.net> Newsgroups: sci.crypt Lines: 107 On 9 Aug 2000 21:20:03 -0000, in <20000809212003.18231.qmail@nym.alias.net>, in sci.crypt lcs Mixmaster Remailer <mix@anon.lcs.mit.edu> wrote: >Terry Ritter writes: >> The LSB of the x^2 mod N result *is* the output of BB&S. If a cycle >> of LSB's could be shorter than the cycle itself, BB&S would be >> seriously damaged. To the extent that there is a proof of BB&S, that >> proof must cover this situation, because this *is* BB&S. > >This is correct. It is frustrating that you have come so close here to >understanding the position of those who have been arguing against you >for so many years. On the contrary, I think I understand that position well, while you clearly have serious problems understanding mine: The very fact that you are willing to trust a "proof" which overlooks a known and demonstrated (if infrequent) weakness, leads me to believe that we do not have the same understanding of what "proven secure" should mean in cryptography. I DO NOT ACCEPT that a cryptosystem which has a known potential weakness can legitimately be called "proven secure." >You need only expand your argument to say, that if a cycle of outputs were >short enough to be found in practice, BB&S would be seriously damaged. >And then, as you say, "To the extent that there is a proof of BB&S, >that proof must cover this situation, because this *is* BB&S." False. We are not interested in the case of an opponent trying to break the system by finding short cycles. That is indeed unlikely to be successful. Instead, the situation of interest occurs *after* a short cycle has been selected for use. When a short cycle is been selected, the system may be insecure, despite claims of a mathematical proof of strength. That is a contradiction. From my point of view, the whole reason for a proof is to absolutely guarantee something. The sort of proof we have been discussing simply does not do that, presumably because it is not really the same sort of "proof" that students learn in algebra. I assume that what we really have is a *statistical* proof, which is *not* just a different form of proof and just as good, but instead a *lesser* *standard* of proof. With a statistical approach, we might prove that something "almost always works." That's a fine goal; I have no problem with that sort of proof. My problem is with implying that "proven almost always secure" means "proven secure." It does not. A far better description would be "a statistical proof of security." And we have yet another problem: How can we believe that the short cycle insecurity is the *only* one which this proof allows to exist? We *can* prevent the short-cycle insecurity, because we know about it. But we *can't* prevent other security problems about which we know nothing. >The point being, that if anyone could feasibly find short cycles when >using intractably large RSA moduli (other than trivial cases like x=1 or >-1), that would invalidate the BB&S proofs. But by the proof, we know >that this is impossible (assuming that quadratic reciduosity is hard, >which virtually everyone agrees with). (Actually, previous discussions >on sci.crypt have shown that short cycles are infeasible to find even >assuming the factoring problem, which everyone who uses RSA agrees >is intractable.) For the purposes of this discussion, I believe we have all accepted factoring security. More generally, I am less confident. >One other point, because it keeps coming up. The toy example of 1081 = >23*47 is meaningless in evaluating the *tractability* of finding short >cycles. Of course. >Factoring 1081 is trivial. Hence the proof which reduces >finding cycles to factoring will not apply, because factoring a number >of this size is not difficult. You might as well try to evaluate the >security of AES by cutting it down to something with a 10 bit key. Tiny versions of any scalable cipher are generally not secure, so one might ask, "What good are they?" Well, tiny versions provide valid insight into the structure of a complex system at a size that humans can approach. Such a system actually can be measured and analyzed experimentally, to either verify or refute assertions made from theory alone. Many comments here have pointed out how difficult it is to find short cycles. If all we had to experiment with was a full-size BB&S system, we might not even *know* about short cycles. Yet a tiny version of BB&S exposes this structure in an irrefutable way. In fact, a tiny version of a scalable cipher can support an exhaustive experimental analysis which is actually *impossible* on the full-size system. In this context, 1081 is neither trivial nor meaningless. Instead, it is a way for us to see the structure of a valid BB&S system at a size which humans can investigate. Since we build the large system from exactly the same formula as the small one, we expect to find inherent structural similarities, and we do. --- Terry Ritter ritter@io.com http://www.io.com/~ritter/ Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM Subject: Re: OTP using BBS generator? Date: Thu, 10 Aug 2000 11:05:14 +0200 From: Mok-Kong Shen <mok-kong.shen@t-online.de> Message-ID: <3992704A.BD1E3D93@t-online.de> References: <399237c5.6176029@news.io.com> Newsgroups: sci.crypt Lines: 55 Terry Ritter wrote: > > With a statistical approach, we might prove that something "almost > always works." That's a fine goal; I have no problem with that sort > of proof. My problem is with implying that "proven almost always > secure" means "proven secure." It does not. A far better description > would be "a statistical proof of security." In another follow-up I have argued for a replacement of the term 'provable security' without having considered statistics. Here is a modified version: 'existence of a rigorous security proof of statistical nature contigent on fulfillment of certain assumptions' > > And we have yet another problem: How can we believe that the short > cycle insecurity is the *only* one which this proof allows to exist? > We *can* prevent the short-cycle insecurity, because we know about it. > But we *can't* prevent other security problems about which we know > nothing. In another follow-up I have used an example to demostrate that the strange behaviour that David Molnar found for non-BBS modulus can also happen in BBS. With n=209, a cycle of length 4 (which I fould on my second trial) gives the LSB of 0000! Now this is certainly a toy example. But it is on the other hand definitely a warning indicating that the statistical qualties (note that cycle length is not 'everything' of statistics!) should be carefully investigated, as I also suggested in the other follow-up (at that time rather intuitively). For what the toy example shows might not be, unless demonstrated to the contrary, a very rare chance happending but could well be the tip of an iceberg. Further, as David Hopgood pointed out and probably ignored by most experts till present, the BBS paper left open the issue of the relationship between the cycle length of the numbers from the congruence relation and the cycle length of the LSBs. As Terry Ritter has pointed out, the cycle length of the LSB is however something that really matters. From all these I believe that the commonly confered etiquette of 'provable security' (despite my comments to the previous paragraph) on BBS should be temporarily suspended, much like the case currently with a type of supersonic aircraft that has produced a yet unclarified catastrophe. M. K. Shen ------------------------------- http://home.t-online.de/home/mok-kong.shen Subject: Re: OTP using BBS generator? Date: 10 Aug 2000 11:36:58 GMT From: guymacon@deltanet.com (Guy Macon) Message-ID: <8mu44q554@dispatch.concentric.net> References: <3992704A.BD1E3D93@t-online.de> Newsgroups: sci.crypt Lines: 9 Mok-Kong Shen wrote: >a very rare chance happending but could well be the tip of an iceberg. Hmmm. Those very rare chances again. Sort of like the very rare but nonzero chance that your hardware RNG might randomly put out a couple of million zeros in a row and thus turn your one time pad into sending the plaintext in the clear... Subject: Re: OTP using BBS generator? Date: Thu, 10 Aug 2000 19:57:52 +0200 From: Mok-Kong Shen <mok-kong.shen@t-online.de> Message-ID: <3992ED20.ABE285E0@t-online.de> References: <8mu44q554@dispatch.concentric.net> Newsgroups: sci.crypt Lines: 59 Guy Macon wrote: > > Mok-Kong Shen wrote: > > >a very rare chance happending but could well be the tip of an iceberg. > > Hmmm. Those very rare chances again. Sort of like the very rare but > nonzero chance that your hardware RNG might randomly put out a couple > of million zeros in a row and thus turn your one time pad into sending > the plaintext in the clear... How rare are these? Have you ever tried? I got in my example with my 2nd trial. You have to show mathematically that they are indeed rare, if experiment indicates that is probably not that rare. Or do you simply 'wish' that they are rare? Note that I got the suspicion from David Molnar's information that for non-BBS moduli, i.e. not of the form 3 mod 4, he [often] got 01010101.... . Now it seems to me to be very reasonable to think that for BBS moduli, the same could happen through maybe not so often. I was indeed very surprised, when I got the example so easily. Note that the phenomenon with LSB is well known with linear congruential generators. Such generators can have namely very large period length, but the LSB alternates between 0 and 1. Now, such extremly bad patterns are actually not belonging to stuffs that one normally NEED to check, for a reasonably good generator shouldn't by definition have these patterns. A generator is therefore normally checked more carefully with comparatively sophisticated means, i.e. with tests like FIPS-140-1, the serial tests with different lags, the Maurer's universtatistical test, etc. It is in retrospect indeed extremely odd, that nobody has (as far as I am aware from literatures) ever done such tests on BBS and yet many persons say offhand that BBS is 'provably secure'. Probably this comes from the circumstance that BBS was presented with lots of high mathematics (partly difficult to understand for non-mathematicians) and one simply 'believes' that, where high mathematics is, everything 'must' be o.k. David Hopwood reported that the BBS article left entirely open the issue of the link between the cycle length of the numbers from the congruence relation and the cycle length of LSB. That this very essential fact has obviously excaped the attention of many people that claimed to have to do with BBS appears to be quite understandable from this psychological interpretation. M. K. Shen --------------------------- http://home.t-online.de/home/mok-kong.shen M M. K. Shen M. K. Shen Subject: Re: OTP using BBS generator? Date: Thu, 10 Aug 2000 17:55:22 GMT From: ritter@io.com (Terry Ritter) Message-ID: <3992ec78.4353838@news.io.com> References: <3992704A.BD1E3D93@t-online.de> Newsgroups: sci.crypt Lines: 26 On Thu, 10 Aug 2000 11:05:14 +0200, in <3992704A.BD1E3D93@t-online.de>, in sci.crypt Mok-Kong Shen <mok-kong.shen@t-online.de> wrote: >[...] >In another follow-up I have argued for a replacement of the >term 'provable security' without having considered statistics. >Here is a modified version: > > 'existence of a rigorous security proof of statistical > nature contigent on fulfillment of certain assumptions' I think that hides the true situation. For the purposes of discussion we are willing to assume that factoring is difficult. Yet even *with* that assumption, the reduced BB&S without short-cycle checks will be weak occasionally. Here "occasionally" means "ALMOST never," instead of the absolute "never" we would like to see. The issue, then, is *not* the assumption, but instead the construction of the system to be secure when the assumption is true. --- Terry Ritter ritter@io.com http://www.io.com/~ritter/ Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM Subject: Re: OTP using BBS generator? Date: Thu, 10 Aug 2000 21:10:13 +0200 From: Mok-Kong Shen <mok-kong.shen@t-online.de> Message-ID: <3992FE15.6C0E8D32@t-online.de> References: <3992ec78.4353838@news.io.com> Newsgroups: sci.crypt Lines: 75 Terry Ritter wrote: > > <mok-kong.shen@t-online.de> wrote: > >In another follow-up I have argued for a replacement of the > >term 'provable security' without having considered statistics. > >Here is a modified version: > > > > 'existence of a rigorous security proof of statistical > > nature contigent on fulfillment of certain assumptions' > > I think that hides the true situation. For the purposes of discussion > we are willing to assume that factoring is difficult. Yet even *with* > that assumption, the reduced BB&S without short-cycle checks will be > weak occasionally. Here "occasionally" means "ALMOST never," instead > of the absolute "never" we would like to see. > > The issue, then, is *not* the assumption, but instead the construction > of the system to be secure when the assumption is true. You are concerning some issues of the present thread with its 'specialities'. What I meant is that in GENERAL one should replace in crypto discussions the term 'provably secure' with the long phrase I proposed, in order to prevent 'general' mis-interpretations. BTW, I like to take this opportunity to repeat a few points: (1) If indeed one could (though I doubt) quantitatively investigate the distribution of the cycle lengths of the output of the congruence relation, then one could assess the difference between the 'reduced' and the 'full' version in quantitative terms and hence allows the user to do his choice. Apparently, however, there is no way of doing that in theory conveniently, let alone in practice. (2) As David Hopwood pointed out, BBS left entirely open the issue of the relation between the cycle lengths of the output of the congruence relation and the cycle length of LSB of that. Since one IS using the LSB, NOT the direct output of the congruence relation, there is NO sense to claim having profited from 'provable security' of BBS at all while employing the LSB, as long as this very essential issue is not clarified. Indeed, it seems to be more 'economical' to wait for the clarification of that before further persuing discussion of the issue of reduced vs. full version. For, if LSB of BBS turns out to have mostly very short cycle lengths (even if the output of the congruence relation does not) or if LSB has very poor OTHER statistical qualities, e.g. failing to be uniform or failing the serial tests, then one can 'forget' BBS from the outset. (3) As I suggested in a previous follow-up (before I came up with the example leading to LSB of 0000.....), one MUST do an amount of statistical tests on BBS, just like ANY PRNG that is used in numerical computations (not necessarily crypto) has to be tested. I am not aware of any such PRNG (excepting BBS) that has been 'exempted' from tests simply because theory says that it must be good. This work, though presumably not simple/convenient, MUST be done, if BBS is to be applied in practice. Otherwise, one is not acting according to scientific ways and is cheating oneself or believing religious doctrines. (There seems to be no easily discernable relation between the cycle length of the output of a PRNG in general and the LSB. For certain linear congruential PRNGs it is well-known that the LSB always alternates between 0 and 1, i.e. has a cycle length of 2 and is thus entirely independent of the cycle length of the output of the congruence relation, which may be huge under circumstances.) M. K. Shen ----------------------------- http://home.t-online.de/home/mok-kong.shen Subject: Re: OTP using BBS generator? Date: Thu, 10 Aug 2000 21:05:33 GMT From: ritter@io.com (Terry Ritter) Message-ID: <399318a2.2296207@news.io.com> References: <3992FE15.6C0E8D32@t-online.de> Newsgroups: sci.crypt Lines: 28 On Thu, 10 Aug 2000 21:10:13 +0200, in <3992FE15.6C0E8D32@t-online.de>, in sci.crypt Mok-Kong Shen <mok-kong.shen@t-online.de> wrote: >[...] >(1) If indeed one could (though I doubt) quantitatively >investigate the distribution of the cycle lengths of the >output of the congruence relation, then one could assess >the difference between the 'reduced' and the 'full' version >in quantitative terms and hence allows the user to do his >choice. Apparently, however, there is no way of doing that >in theory conveniently, let alone in practice. I think the math to do that does exist, for any particular N, and that presumably can be generalized into a distribution for "N" in general. But even if we do that we can't "guarantee" a secure system, and if not, then why use BB&S at all? I personally object to building ciphers with this sort of weakness, for then we are depending upon randomness to not produce a particular result when we know it might. That is weakness under our control; we can't blame the opponent if we make it easy. --- Terry Ritter ritter@io.com http://www.io.com/~ritter/ Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM Subject: Re: OTP using BBS generator? Date: Fri, 11 Aug 2000 00:09:24 +0200 From: Mok-Kong Shen <mok-kong.shen@t-online.de> Message-ID: <39932814.38DE5ABA@t-online.de> References: <399318a2.2296207@news.io.com> Newsgroups: sci.crypt Lines: 61 Terry Ritter wrote: > > <mok-kong.shen@t-online.de> wrote: > > >[...] > >(1) If indeed one could (though I doubt) quantitatively > >investigate the distribution of the cycle lengths of the > >output of the congruence relation, then one could assess > >the difference between the 'reduced' and the 'full' version > >in quantitative terms and hence allows the user to do his > >choice. Apparently, however, there is no way of doing that > >in theory conveniently, let alone in practice. > > I think the math to do that does exist, for any particular N, and that > presumably can be generalized into a distribution for "N" in general. > But even if we do that we can't "guarantee" a secure system, and if > not, then why use BB&S at all? > > I personally object to building ciphers with this sort of weakness, > for then we are depending upon randomness to not produce a particular > result when we know it might. That is weakness under our control; we > can't blame the opponent if we make it easy. In another follow-up I have tried to roughly compare the issue here with weak keys, e.g. in DES. But I am not sure how far such a comparison is appropriate, because I don't know the magnitudes of the probabilities involved. If indeed the two cases are comparable, then one could say that the decision to use the full version of BBS corresponds to checking weak keys in block ciphers and hence a user who opts for checking weak keys should use the full version of BBS, if he behaves consistently. (In the other case, he uses the reduces version.) I want on the other hand once again to stress that the short (or long) cycles being very heatedly disputed up till now in this thread are those of the direct output of the congruence relation and NOT of the LSB. There need not necessarily exist a mathematically definite and practically useful relationship between these two types of cycle lengths. Since the user is using LSB, ONLY the cycle length of LSB is of interest to him. I sincerely hope therefore that the energy of the discussion partners will in future be largely spent on the cycle length of LSB (rather than on the cycle length of the direct output of the congruence relation) and, what is at least of equal importance, on the remaining statistical qualities of LSB, e.g. bias, correlations, etc. For, a user can sensibly apply the BBS device in his applications only if such knowldege is available. Otherwise, even if we could tell him exactly what cycle length of the direct output of the congruence relation is for each and every configuration of BBS he happens to choose, he can make NO use of our information at all. I'll very much appreciate to be able to see posts about all the statistical qualities of LSB of BBS in the near future in this thread. M. K. Shen Subject: Re: OTP using BBS generator? Date: Fri, 11 Aug 2000 03:48:55 GMT From: Bryan Olson <bryanolson@my-deja.com> Message-ID: <8mvt37pim1@nnrp1.deja.com> References: <39932814.38DE5ABA@t-online.de> Newsgroups: sci.crypt Lines: 29 Mok-Kong Shen wrote: [...] > I want on the other hand once again to stress that the > short (or long) cycles being very heatedly disputed up > till now in this thread are those of the direct output of > the congruence relation and NOT of the LSB. There need > not necessarily exist a mathematically definite and > practically useful relationship between these two types > of cycle lengths. Since the user is using LSB, ONLY the > cycle length of LSB is of interest to him. The reductions from QR and factoring holds for the unpredictability of the least significant bit (and a few other bits at the low end according to more recent results). All that the open question means is that even if one does filter out short state cycles, one still has not proven a long output cycle. This is only a problem for those who thought the state-cycle test would prove security for each possible key, and that would be nonsense even if we knew the output cycle to be long. --Bryan -- email: bolson at certicom dot com Sent via Deja.com http://www.deja.com/ Before you buy. Subject: Re: OTP using BBS generator? Date: Fri, 11 Aug 2000 11:13:06 +0200 From: Mok-Kong Shen <mok-kong.shen@t-online.de> Message-ID: <3993C3A2.1DAA83B@t-online.de> References: <8mvt37pim1@nnrp1.deja.com> Newsgroups: sci.crypt Lines: 36 Bryan Olson wrote: > > Mok-Kong Shen wrote: > [...] > > I want on the other hand once again to stress that the > > short (or long) cycles being very heatedly disputed up > > till now in this thread are those of the direct output of > > the congruence relation and NOT of the LSB. There need > > not necessarily exist a mathematically definite and > > practically useful relationship between these two types > > of cycle lengths. Since the user is using LSB, ONLY the > > cycle length of LSB is of interest to him. > > The reductions from QR and factoring holds for the > unpredictability of the least significant bit (and a few > other bits at the low end according to more recent results). > All that the open question means is that even if one does > filter out short state cycles, one still has not proven a > long output cycle. This is only a problem for those who > thought the state-cycle test would prove security for each > possible key, and that would be nonsense even if we knew the > output cycle to be long. Exactly. If we KNEW the output cycle of LSB to be long! But it is unfortunate that we don't yet know. It is important to realize this point, independent of what the reality (which we don't yet know) is. (Before FLT was proved, there were speculations that it were wrong. Now we know that FLT is right. It could have come out the other way, though.) This is why I pleaded to do some extensive experiments, if a theoretical study of the issue is difficult. M. K. Shen Subject: Re: OTP using BBS generator? Date: Sun, 13 Aug 2000 19:31:43 GMT From: Bryan Olson <bryanolson@my-deja.com> Message-ID: <8n6t30hef1@nnrp1.deja.com> References: <3993C3A2.1DAA83B@t-online.de> Newsgroups: sci.crypt Lines: 34 Mok-Kong Shen wrote: > Bryan Olson wrote: > > The reductions from QR and factoring holds for the > > unpredictability of the least significant bit (and a few > > other bits at the low end according to more recent results). > > All that the open question means is that even if one does > > filter out short state cycles, one still has not proven a > > long output cycle. This is only a problem for those who > > thought the state-cycle test would prove security for each > > possible key, and that would be nonsense even if we knew the > > output cycle to be long. > > Exactly. If we KNEW the output cycle of LSB to be long! And exactly as things are. We do not know if factoring is hard in most cases, and a short cycle in the bit output is one of arbitrarily many defects that might happen (in the sense that we have not proven it can't) if factoring the modulus turns out to be easy. There's no particular reason to obsess over this one possible defect, though if you think you might learn something interesting by looking for cycles in the least significant bit, by all means carry on. --Bryan -- email: bolson at certicom dot com Sent via Deja.com http://www.deja.com/ Before you buy. Subject: Re: OTP using BBS generator? Date: Fri, 11 Aug 2000 13:59:44 +0100 From: David Hopwood <hopwood@zetnet.co.uk> Message-ID: <3993F8C0.F33CB0AF@zetnet.co.uk> References: <3992704A.BD1E3D93@t-online.de> Newsgroups: sci.crypt Lines: 101 -----BEGIN PGP SIGNED MESSAGE----- Mok-Kong Shen wrote: > Terry Ritter wrote: > > > With a statistical approach, we might prove that something "almost > > always works." That's a fine goal; I have no problem with that sort > > of proof. My problem is with implying that "proven almost always > > secure" means "proven secure." It does not. A far better description > > would be "a statistical proof of security." > > In another follow-up I have argued for a replacement of the > term 'provable security' without having considered statistics. > Here is a modified version: > > 'existence of a rigorous security proof of statistical > nature contigent on fulfillment of certain assumptions' Proofs in this area of cryptology are generally probabilistic, but they are *not* statistical (there are no "statistical tests" involved). Probability theory is a lot less fuzzy and has a sounder mathematical basis than does most interpretation of statistical results (for example reporting bias, of which an example is given below, is a very serious problem in that context). In any case, a phrase of the length suggested above is far too much of a mouthful to expect anyone to use it in practice. Personally, I would prefer something like "security supported by proof". > > And we have yet another problem: How can we believe that the short > > cycle insecurity is the *only* one which this proof allows to exist? > > We *can* prevent the short-cycle insecurity, because we know about it. > > But we *can't* prevent other security problems about which we know > > nothing. > > In another follow-up I have used an example to demostrate > that the strange behaviour that David Molnar found for > non-BBS modulus can also happen in BBS. With n=209, a > cycle of length 4 (which I found on my second trial) > gives the LSB of 0000! I wouldn't read anything into this - a cycle of length 4 will be 0000 with probability 1/16, which can hardly be considered extremely unlikely. Also, you would presumably have considered 1111 just as surprising, and you only found this on your second trial. Finally, there is a reporting bias in the sense that if the result had not been "surprising", you probably wouldn't have posted the example, since it wouldn't support your argument. The nature of Usenet tends to amplify this kind of reporting bias - we don't know how many people tested BBS (or more generally looked for unusual output characteristics for any cryptosystem), and found nothing at all to suggest non-randomness. [...] > Now this is certainly a toy > example. But it is on the other hand definitely a > warning indicating that the statistical qualties (note > that cycle length is not 'everything' of statistics!) > should be carefully investigated, as I also suggested > in the other follow-up (at that time rather intuitively). > For what the toy example shows might not be, unless > demonstrated to the contrary, a very rare chance > happending but could well be the tip of an iceberg. > Further, as David Hopgood Hopwood > pointed out and probably > ignored by most experts till present, the BBS paper > left open the issue of the relationship between the > cycle length of the numbers from the congruence > relation and the cycle length of the LSBs. I'm sure that anyone who read the paper in full was aware of this. However, it doesn't really matter to the security of BBS; the proof that the LSBs (not the x_i values) are indistinguishable from random except with negligable probability and under the assumption that factoring is intractable, does not depend on any unproven conjectures about cycle length. - -- David Hopwood <hopwood@zetnet.co.uk> Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/ RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01 Nothing in this message is intended to be legally binding. If I revoke a public key but refuse to specify why, it is because the private key has been seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv iQEVAwUBOZPcETkCAxeYt5gVAQENBAgAhvu40tLv4RReBc/TBj3TjJzsYoOMemyM WgXarnJ9ivojlP+CvBAGNiFaAFs1RoA527DNh01yqpUN3XI4OFaQCAQ+Dxja9NUP JSq2HsO5ny4qK2hUYqZvHRRu5n8vH3jyXQCd3jQrAKpQS5hEiNL+DrwCYuV23MQj 9BnWIx+3WjtCmleyhOVKRWBwazlFqZdi9Wt6iO/3XGbCV4tcubWVqdrXIwfNDCrt 25CQwwGBgy9XhQpaRR2/SbZCUIrZwzKRyA+52YdfvB5MP6e9W4j8Y8Kj01DlPvo9 l/jFh0WIYViLq0i9WasjwLUGSnYNXbAJUUVpfOIPCbRqxUrPiunFwA== =c8pG -----END PGP SIGNATURE----- Subject: Re: OTP using BBS generator? Date: Fri, 11 Aug 2000 04:47:20 GMT From: ritter@io.com (Terry Ritter) Message-ID: <39938548.16954494@news.io.com> References: <3993F8C0.F33CB0AF@zetnet.co.uk> Newsgroups: sci.crypt Lines: 26 On Fri, 11 Aug 2000 13:59:44 +0100, in <3993F8C0.F33CB0AF@zetnet.co.uk>, in sci.crypt David Hopwood <hopwood@zetnet.co.uk> wrote: >[...] >Proofs in this area of cryptology are generally probabilistic, but they are >*not* statistical A distribution of values (here weakness) is a statistical entity. When x0 values are selected at random they are random variables, which are definitely statistical entities The effect of random sampling from a distribution is inherently statistical in nature. >(there are no "statistical tests" involved). Right. So? --- Terry Ritter ritter@io.com http://www.io.com/~ritter/ Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM Subject: Re: OTP using BBS generator? Date: Fri, 11 Aug 2000 11:13:31 +0200 From: Mok-Kong Shen <mok-kong.shen@t-online.de> Message-ID: <3993C3BB.A0470ADA@t-online.de> References: <3993F8C0.F33CB0AF@zetnet.co.uk> Newsgroups: sci.crypt Lines: 73 David Hopwood wrote: > > In any case, a phrase of the length suggested above is far too much of a > mouthful to expect anyone to use it in practice. Personally, I would prefer > something like "security supported by proof". Well, 'security proved under certain assumptions' is better in my view. > The nature > of Usenet tends to amplify this kind of reporting bias - we don't know > how many people tested BBS (or more generally looked for unusual output > characteristics for any cryptosystem), and found nothing at all to suggest > non-randomness. I should be very grateful, if my post, however inappropriate or wrong it may later turn out to be, serves the purpose to cause a lot of people to test BBS and verify its quality, so that the users can more easily have confidence on it. (I mean readers that have difficulties to fully understand BBS' paper.) Sofar, there is yet no follow-up containing any result of actual tests, however. > [...] > > Further, as David Hopgood > > Hopwood > > > pointed out and probably > > ignored by most experts till present, the BBS paper > > left open the issue of the relationship between the > > cycle length of the numbers from the congruence > > relation and the cycle length of the LSBs. > > I'm sure that anyone who read the paper in full was aware of this. > However, it doesn't really matter to the security of BBS; the > proof that the LSBs (not the x_i values) are indistinguishable from > random except with negligable probability and under the assumption that > factoring is intractable, does not depend on any unproven conjectures > about cycle length. If there is a gap (in the theory presented) between the two types of cycle lengths but the security of LSB can nonetheless be established, I wonder why (as far as I learned here) BBS did the trouble at all to investigate cases where the cycle length of the direct output of the congruence (not that of the LSB) could somehow be avoided to have short cycles. (This cycle length is the point that has lead to long discussions here till now.) Note, however, what Terry Ritter pointed out. If the cycle of LSB is extremely short, then the bit sequence is evidently not useful in crypto anyway, isn't it? (We need only consider an example of say, a period length of 10, to see the point.) That is, in that case we wouldn't NEED to care if there is or is not any connection with the hardness of factoring or what not. The exclusion of use of BBS would then simply be a purely 'practical' issue quite independent of the high math. Now, apparently we don't at the current moment know much about the probability of occurrence of very short cycles of LSB (but only some, I suppose, about the cycles of the direct output of the congruence relation). That's why we need to investigate that through performing extensive tests in my humble view, unless we have a clear-cut theory on the cycle length of LSB. M. K. Shen Subject: Re: OTP using BBS generator? Date: 10 Aug 2000 15:01:56 GMT From: mdw@nsict.org (Mark Wooding) Message-ID: <slrn8p5gv4.ti5.mdw@mull.ncipher.com> References: <399237c5.6176029@news.io.com> Newsgroups: sci.crypt Lines: 64 Terry Ritter <ritter@io.com> wrote: > From my point of view, the whole reason for a proof is to absolutely > guarantee something. The sort of proof we have been discussing simply > does not do that, presumably because it is not really the same sort of > "proof" that students learn in algebra. I assume that what we really > have is a *statistical* proof, which is *not* just a different form of > proof and just as good, but instead a *lesser* *standard* of proof. Errr... no. The proof not statistical. It states that the output of a BBS generator cannot be distibguished from random data by any polynomial-time test by an adversary who cannot decide quadratic residuosity. And this is the way that security proofs work in cryptography: we prove relationships between solving different types of problems. It's a strict relationship, rigorously proven. > And we have yet another problem: How can we believe that the short > cycle insecurity is the *only* one which this proof allows to exist? > We *can* prevent the short-cycle insecurity, because we know about it. > But we *can't* prevent other security problems about which we know > nothing. Actually, this is wrong. If there's a distinguisher for the BBS, then either it's not polynomial time, or we can solve the QRP in polynomial time. The former would be quite interesting; the latter would be an extremely important result. The proof is not statistical: these are the only two possible outcomes. > For the purposes of this discussion, I believe we have all accepted > factoring security. More generally, I am less confident. > > > >One other point, because it keeps coming up. The toy example of 1081 = > >23*47 is meaningless in evaluating the *tractability* of finding short > >cycles. > > Of course. > > >Factoring 1081 is trivial. Hence the proof which reduces > >finding cycles to factoring will not apply, because factoring a number > >of this size is not difficult. You might as well try to evaluate the > >security of AES by cutting it down to something with a 10 bit key. > > Tiny versions of any scalable cipher are generally not secure, so one > might ask, "What good are they?" Well, tiny versions provide valid > insight into the structure of a complex system at a size that humans > can approach. Such a system actually can be measured and analyzed > experimentally, to either verify or refute assertions made from theory > alone. You must be careful when you do this sort of analysis. Examining one example is not good enough. Even looking at lots (as you did, if I remember from your article) isn't useful if you analyse the data in the wrong way. For example, how is the cycle length related to the size (log_2) of the modulus? Is the relationship polynomial or (sub)exponential? In the latter case, we've not found anything interesting, because we always knew we could distinguish BBS with greater-than-polytime tests; in the former, yes, that's interesting. -- [mdw] Subject: Re: OTP using BBS generator? Date: Thu, 10 Aug 2000 19:57:57 +0200 From: Mok-Kong Shen <mok-kong.shen@t-online.de> Message-ID: <3992ED25.ACB0ADC1@t-online.de> References: <slrn8p5gv4.ti5.mdw@mull.ncipher.com> Newsgroups: sci.crypt Lines: 26 Mark Wooding wrote: > > Terry Ritter <ritter@io.com> wrote: > > > From my point of view, the whole reason for a proof is to absolutely > > guarantee something. The sort of proof we have been discussing simply > > does not do that, presumably because it is not really the same sort of > > "proof" that students learn in algebra. I assume that what we really > > have is a *statistical* proof, which is *not* just a different form of > > proof and just as good, but instead a *lesser* *standard* of proof. > > Errr... no. The proof not statistical. It states that the output of a > BBS generator cannot be distibguished from random data by any > polynomial-time test by an adversary who cannot decide quadratic > residuosity. > > And this is the way that security proofs work in cryptography: we prove [snip] Would a LSB sequence of 000000..... or 010101..... be indistinguishable from random data or distinguishable? M. K. Shen Subject: Re: OTP using BBS generator? Date: Thu, 10 Aug 2000 18:07:21 GMT From: ritter@io.com (Terry Ritter) Message-ID: <3992ef33.5053138@news.io.com> References: <slrn8p5gv4.ti5.mdw@mull.ncipher.com> Newsgroups: sci.crypt Lines: 109 On 10 Aug 2000 15:01:56 GMT, in <slrn8p5gv4.ti5.mdw@mull.ncipher.com>, in sci.crypt mdw@nsict.org (Mark Wooding) wrote: >Terry Ritter <ritter@io.com> wrote: > >> From my point of view, the whole reason for a proof is to absolutely >> guarantee something. The sort of proof we have been discussing simply >> does not do that, presumably because it is not really the same sort of >> "proof" that students learn in algebra. I assume that what we really >> have is a *statistical* proof, which is *not* just a different form of >> proof and just as good, but instead a *lesser* *standard* of proof. > >Errr... no. The proof not statistical. It states that the output of a >BBS generator cannot be distibguished from random data by any >polynomial-time test by an adversary who cannot decide quadratic >residuosity. That is simply false when a short cycle is used. Unless you absolutely prevent such a thing, you cannot assume in your reasoning that it has not occurred. On the contrary, if something *might* occur, you must assume that it *has* occurred, and reason the consequences from there. >And this is the way that security proofs work in cryptography: we prove >relationships between solving different types of problems. It's a >strict relationship, rigorously proven. Saying something is "proven" is no advantage unless we need the object of the proof. Here the issue is *not* whether BB&S is secure; the issue is whether the reduced version -- including short cycles -- is secure even if we assume factoring is hard. I am happy to agree that reduced BB&S is *almost* always secure, but since we can prevent the short-cycle weakness completely, almost always is not good enough. And claiming that *must* be secure because the math says so is just wrong. Using an insecure system is not secure. >> And we have yet another problem: How can we believe that the short >> cycle insecurity is the *only* one which this proof allows to exist? >> We *can* prevent the short-cycle insecurity, because we know about it. >> But we *can't* prevent other security problems about which we know >> nothing. > >Actually, this is wrong. If there's a distinguisher for the BBS, then >either it's not polynomial time, or we can solve the QRP in polynomial >time. The former would be quite interesting; the latter would be an >extremely important result. The proof is not statistical: these are the >only two possible outcomes. Then the proof is wrong. For we *absolutely* *know* that using a short cycle can be weak (when we traverse the cycle). Actually, it is your consequence that is wrong: Most problems are easy to solve when the solution is leaked. What we have here is a construction which leaks the solution, unless explicitly prevented. So the failure does *not* impact math theories. Which also implies that those same theories cannot be depended upon for reasoning about strength in this and similar situations. >> For the purposes of this discussion, I believe we have all accepted >> factoring security. More generally, I am less confident. >> >> >> >One other point, because it keeps coming up. The toy example of 1081 = >> >23*47 is meaningless in evaluating the *tractability* of finding short >> >cycles. >> >> Of course. >> >> >Factoring 1081 is trivial. Hence the proof which reduces >> >finding cycles to factoring will not apply, because factoring a number >> >of this size is not difficult. You might as well try to evaluate the >> >security of AES by cutting it down to something with a 10 bit key. >> >> Tiny versions of any scalable cipher are generally not secure, so one >> might ask, "What good are they?" Well, tiny versions provide valid >> insight into the structure of a complex system at a size that humans >> can approach. Such a system actually can be measured and analyzed >> experimentally, to either verify or refute assertions made from theory >> alone. > >You must be careful when you do this sort of analysis. Examining one >example is not good enough. Even looking at lots (as you did, if I >remember from your article) isn't useful if you analyse the data in the >wrong way. > >For example, how is the cycle length related to the size (log_2) of the >modulus? Is the relationship polynomial or (sub)exponential? In the >latter case, we've not found anything interesting, because we always >knew we could distinguish BBS with greater-than-polytime tests; in the >former, yes, that's interesting. One can always question experimental design. But only a scalable cipher allows us to run comprehensive experiments in the first place. Trying to understand a cipher from experiments on a real-size system is generally hopeless, unless there are such massive errors that incredibly sparse sampling would detect them. On a tiny cipher we expect to have examples of the same sorts of errors, which implies that they will be represented with greater probability. That is great, because if the problems were represented with their real-size probability, we would not even detect them. --- Terry Ritter ritter@io.com http://www.io.com/~ritter/ Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM Subject: Re: OTP using BBS generator? Date: 11 Aug 2000 09:57:11 GMT From: mdw@nsict.org (Mark Wooding) Message-ID: <slrn8p7jfm.ti5.mdw@mull.ncipher.com> References: <3992ef33.5053138@news.io.com> Newsgroups: sci.crypt Lines: 81 Terry Ritter <ritter@io.com> wrote: > > On 10 Aug 2000 15:01:56 GMT, in <slrn8p5gv4.ti5.mdw@mull.ncipher.com>, > in sci.crypt mdw@nsict.org (Mark Wooding) wrote: > > >Errr... no. The proof not statistical. It states that the output of > >a BBS generator cannot be distibguished from random data by any > >polynomial-time test by an adversary who cannot decide quadratic > >residuosity. > > That is simply false when a short cycle is used. Unless you > absolutely prevent such a thing, you cannot assume in your reasoning > that it has not occurred. On the contrary, if something *might* > occur, you must assume that it *has* occurred, and reason the > consequences from there. Now you're just being deliberately stupid. I made a clear statement about the nature of the BBS proof. The output of a BBS generator *cannot* be distinguished from random data in *polynomial time* by an adversary *unable to decide quadratic residuosity*. If a short cycle is used, then adversaries can factor the modulus and decide quadratic residuosity. The proof *still applies*. Those adversaries are allowed through by the proof's hypotheses. > Saying something is "proven" is no advantage unless we need the object > of the proof. Here the issue is *not* whether BB&S is secure; the > issue is whether the reduced version -- including short cycles -- is > secure even if we assume factoring is hard. Yes, of course it is. The proof still stands. Your assumption might look a bit iffy, but that doesn't invalidate the proof. It might make the proof less useful or relevant, but it doesn't make it *wrong*. > I am happy to agree that reduced BB&S is *almost* always secure, but > since we can prevent the short-cycle weakness completely, almost > always is not good enough. And claiming that *must* be secure because > the math says so is just wrong. Using an insecure system is not > secure. But the proof doesn't say that BBS is *secure*. It's says that it's *as secure as factoring*. I'm smelling disingenuousness again. > >Actually, this is wrong. If there's a distinguisher for the BBS, > >then either it's not polynomial time, or we can solve the QRP in > >polynomial time. The former would be quite interesting; the latter > >would be an extremely important result. The proof is not > >statistical: these are the only two possible outcomes. > > Then the proof is wrong. For we *absolutely* *know* that using a > short cycle can be weak (when we traverse the cycle). The proof says nothing about *weakness* or *strength*. It *compares* difficuulties of doing two things: on the one hand, predicting the output of a BBS generator, and on the other, factoring composite integers. > >For example, how is the cycle length related to the size (log_2) of > >the modulus? Is the relationship polynomial or (sub)exponential? In > >the latter case, we've not found anything interesting, because we > >always knew we could distinguish BBS with greater-than-polytime > >tests; in the former, yes, that's interesting. > > One can always question experimental design. But only a scalable > cipher allows us to run comprehensive experiments in the first place. > Trying to understand a cipher from experiments on a real-size system > is generally hopeless, unless there are such massive errors that > incredibly sparse sampling would detect them. On a tiny cipher we > expect to have examples of the same sorts of errors, which implies > that they will be represented with greater probability. That is > great, because if the problems were represented with their real-size > probability, we would not even detect them. This entirely fails to answer the question. One less charitable than myself might believe it to be a dodge. -- [mdw] Subject: Re: OTP using BBS generator? Date: Thu, 10 Aug 2000 15:38:14 -0400 From: "Trevor L. Jackson, III" <fullmoon@aspi.net> Message-ID: <399304A6.3B5A626E@aspi.net> References: <slrn8p5gv4.ti5.mdw@mull.ncipher.com> Newsgroups: sci.crypt Lines: 20 Mark Wooding wrote: > Terry Ritter <ritter@io.com> wrote: > > > From my point of view, the whole reason for a proof is to absolutely > > guarantee something. The sort of proof we have been discussing simply > > does not do that, presumably because it is not really the same sort of > > "proof" that students learn in algebra. I assume that what we really > > have is a *statistical* proof, which is *not* just a different form of > > proof and just as good, but instead a *lesser* *standard* of proof. > > Errr... no. The proof not statistical. It states that the output of a > BBS generator cannot be distibguished from random data by any > polynomial-time test by an adversary who cannot decide quadratic > residuosity. Is it your position that there are repeating decimals that have cycles so long that they are are indistinguishable from irrationals? Subject: Re: OTP using BBS generator? Date: Fri, 11 Aug 2000 04:15:53 GMT From: Bryan Olson <bryanolson@my-deja.com> Message-ID: <8mvulnqoq1@nnrp1.deja.com> References: <399237c5.6176029@news.io.com> Newsgroups: sci.crypt Lines: 28 Terry Ritter wrote [...] > And we have yet another problem: How can we believe that the short > cycle insecurity is the *only* one which this proof allows to exist? > We *can* prevent the short-cycle insecurity, because we know about it. > But we *can't* prevent other security problems about which we know > nothing. Well, that was a long time coming. For those who spent a lot of effort trying to convince Mr. Ritter that the cycle-length test didn't change the nature of the theorem, I expect that's as close to a concession as we're going to get. Will he ever understand the rest? The important results on the BBS generator is that it covers _any_ algorithmic method of predicting the output, whether we know about that method or not. Any security problem that happens would imply we've run into a case where someone can factor. --Bryan -- email: bolson at certicom dot com Sent via Deja.com http://www.deja.com/ Before you buy. Subject: Re: OTP using BBS generator? Date: Fri, 11 Aug 2000 13:59:33 +0100 From: David Hopwood <hopwood@zetnet.co.uk> Message-ID: <3993F8B5.A1CFDAA0@zetnet.co.uk> References: <399237c5.6176029@news.io.com> Newsgroups: sci.crypt Lines: 53 -----BEGIN PGP SIGNED MESSAGE----- Terry Ritter wrote: > lcs Mixmaster Remailer <mix@anon.lcs.mit.edu> wrote: > >Terry Ritter writes: > >> The LSB of the x^2 mod N result *is* the output of BB&S. If a cycle > >> of LSB's could be shorter than the cycle itself, BB&S would be > >> seriously damaged. To the extent that there is a proof of BB&S, that > >> proof must cover this situation, because this *is* BB&S. > > > >This is correct. It is frustrating that you have come so close here to > >understanding the position of those who have been arguing against you > >for so many years. > > On the contrary, I think I understand that position well, while you > clearly have serious problems understanding mine: > > The very fact that you are willing to trust a "proof" which overlooks > a known and demonstrated (if infrequent) weakness, leads me to believe > that we do not have the same understanding of what "proven secure" > should mean in cryptography. > > I DO NOT ACCEPT that a cryptosystem which has a known potential > weakness can legitimately be called "proven secure." OK, in that case you must not accept that BBS is proven secure at all, under any assumptions, and with or without the cycle checks. It might clarify the argument if you could confirm whether or not that is actually your view. - -- David Hopwood <hopwood@zetnet.co.uk> Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/ RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01 Nothing in this message is intended to be legally binding. If I revoke a public key but refuse to specify why, it is because the private key has been seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv iQEVAwUBOZPQTzkCAxeYt5gVAQFsZggAy5Se5eEzK/B1YIKFXcVe5RjXNPPKjW79 ey/CGBF4uI2iT9UOplpLZTZb6Sf8Kq/zNp5zZil1ZAsc2U9/OOuMQ5SOFd/287Fr 4bB7sK4jNtlH39nglqKYtqXEK98WaG40pbLJRq3FYs955fkq7QP8rDEGTyyidHZp yAf1hCDXllUB8iLbDJIqJEvl3vNfWM2XfJepIYMb6z507YYkr4PkPTucVMVjAhQU ILmWLZPW5FEf28/hGhBJwVBEGXrzuZu72RBVIC6u64vDT4Use/Jb16Q5Ex1I9xkr FPFme9+mYJFqp0ooj7NrqMQPDY3DqKVxWnAQp29LbuGWzNoRjFiUkQ== =M7K1 -----END PGP SIGNATURE----- Subject: Re: OTP using BBS generator? Date: Fri, 11 Aug 2000 04:32:09 GMT From: ritter@io.com (Terry Ritter) Message-ID: <399381ae.16032279@news.io.com> References: <3993F8B5.A1CFDAA0@zetnet.co.uk> Newsgroups: sci.crypt Lines: 38 On Fri, 11 Aug 2000 13:59:33 +0100, in <3993F8B5.A1CFDAA0@zetnet.co.uk>, in sci.crypt David Hopwood <hopwood@zetnet.co.uk> wrote: >-----BEGIN PGP SIGNED MESSAGE----- > >Terry Ritter wrote: >> [...] >> I DO NOT ACCEPT that a cryptosystem which has a known potential >> weakness can legitimately be called "proven secure." Well, "preventable" weakness. >OK, in that case you must not accept that BBS is proven secure at all, >under any assumptions, and with or without the cycle checks. > >It might clarify the argument if you could confirm whether or not that is >actually your view. I don't really have a view about whether BB&S is secure. On the other hand, I *know* that any random number generator is insecure when it has traversed a cycle, and I *know* that short cycles do exist in BB&S. Thus, I *know* that failing to prevent the use of a short cycle is a risk. But I also *know* the prescription in BB&S will prevent the use of short cycles, which makes the short cycle problem an unnecessary and preventable risk. So I *know* that "real" BB&S is arguably "strong*er*" than the "reduced" or "simplified" BB&S which does not check for short cycles. --- Terry Ritter ritter@io.com http://www.io.com/~ritter/ Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM Subject: Re: OTP using BBS generator? Date: Thu, 10 Aug 2000 04:37:12 -0600 From: "Tony T. Warnock" <u091889@cic-mail.lanl.gov> Message-ID: <399285D8.129D0502@cic-mail.lanl.gov> References: <20000809212003.18231.qmail@nym.alias.net> Newsgroups: sci.crypt Lines: 16 lcs Mixmaster Remailer wrote: > The point being, that if anyone could feasibly find short cycles when > using intractably large RSA moduli (other than trivial cases like x=1 or > -1), that would invalidate the BB&S proofs. But by the proof, we know > that this is impossible (assuming that quadratic reciduosity is hard, > which virtually everyone agrees with). (Actually, previous discussions > on sci.crypt have shown that short cycles are infeasible to find even > assuming the factoring problem, which everyone who uses RSA agrees > is intractable.) Isn't this the converse of the problem. We are not looking for short cycles, we are looking to avoid them. The question is not whether it's infeasible to find a short cycle, it's whether it's feasible to find a long one. Subject: Re: OTP using BBS generator? Date: Thu, 10 Aug 2000 17:11:16 +0100 From: David Hopwood <hopwood@zetnet.co.uk> Message-ID: <3992D424.3D8900A5@zetnet.co.uk> References: <399285D8.129D0502@cic-mail.lanl.gov> Newsgroups: sci.crypt Lines: 60 -----BEGIN PGP SIGNED MESSAGE----- "Tony T. Warnock" wrote: > lcs Mixmaster Remailer wrote: > > > The point being, that if anyone could feasibly find short cycles when > > using intractably large RSA moduli (other than trivial cases like x=1 or > > -1), that would invalidate the BB&S proofs. But by the proof, we know > > that this is impossible (assuming that quadratic reciduosity is hard, > > which virtually everyone agrees with). (Actually, previous discussions > > on sci.crypt have shown that short cycles are infeasible to find even > > assuming the factoring problem, which everyone who uses RSA agrees > > is intractable.) > > Isn't this the converse of the problem. We are not looking for short > cycles, we are looking to avoid them. > The question is not whether it's infeasible to find a short cycle, it's > whether it's feasible to find a long one. If it is infeasible to find a short cycle, then there is negligable probability that one will be picked at random. Therefore we don't need to specifically find a guaranteed long cycle; we can just pick a seed at random from Z*_N [*], and this will result in a system that is secure except with negligable probability. Since that was all that the BBS proofs attempted to show (under some assumptions) in the first place, this should not make us any less confident of the resulting security, either in theory or in practice. If we want a system that has zero probability of weakness, then BBS will not do, and neither will any other known cryptosystem that is not information- theoretically secure. [*] Actually it would also be sufficient to choose a seed from Z_N, because (N - |Z*_N|)/N is negligable. - -- David Hopwood <hopwood@zetnet.co.uk> Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/ RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01 Nothing in this message is intended to be legally binding. If I revoke a public key but refuse to specify why, it is because the private key has been seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv iQEVAwUBOZK3wDkCAxeYt5gVAQFaXAgAwFu5p8tzKOX2xq55JlOoJE9L7BFQUbBn s3vyVC5ByeOXKZTYblkGizzRos/TMtli3XIL1l+2GBlV9W9xzojEkkOTJ0U10NFW WeLj0LpxNhJ3ePAQh/+Q8TWvhd4EUsrYrND5sMAqJQk70lTIcRpLZaR8BXlqHBZc py2zUC+Jot7CGEO+4hrB2ncCMFjxgHly0dClwK6WPg/Gyye83bViFHOk4C4HYgG5 7CdsUr18CwlsCAU82se52R9IbK5f1SULzq9w/xbKXj7tdPrNwZlL38b56rb3/Jt8 3/S7K/n9v5rM/lhPKD7K3+WT5kB/5d2f5KTO8LlWFbrOi+AyIGegzw== =rbe0 -----END PGP SIGNATURE----- Subject: Re: OTP using BBS generator? Date: 10 Aug 2000 18:00:25 -0000 From: lcs Mixmaster Remailer <mix@anon.lcs.mit.edu> Message-ID: <20000810180025.3829.qmail@nym.alias.net> References: <3990a002.1905423@news.io.com> Newsgroups: sci.crypt Lines: 33 David Hopwood writes: > Note that the proofs in the BBS paper (and in the Crypto '84 paper by Vazirani > and Vazirani proving a reduction to factoring) are all asymptotic, so > unfortunately we can't make stronger statements relating the exact probability > of being able to distinguish the BBS output from random with a specific amount > of work, to the probability of being able to factor or solve the QRP with a > similar amount of work (at least, not based on those proofs). But if the > underlying question being debated in this thread is about the general validity > of probabilistic proof, rather than its application to BBS in particular, then > there are plenty of other cryptosystems for which exact reductions have been > proven. First, thanks to the reference to Vazirani&Vazirani. We can dispense with the awkward claim that BBS reduces to quadratic reciduosity, and simply say that it reduces to factoring. If you think you need to check for short cycles, then you think your opponent can factor your modulus by guessing cycles. However, you have made one very unfortunate misstatement, which is that the proofs are asymptotic. This is not true, at least for the commonly understood meaning, which would be that they are asymptotic in N, the modulus, and so don't apply in general to any specific N. The proofs are NOT asymptotic in N. BBS/Vazirani shows very clearly that for ANY modulus, if you have an epsilon advantage for guessing the BBS sequence, you can factor THAT modulus. (Furthermore, as was shown here, the ability to find short cycles by guessing immediately leads to factoring in a much simpler way.) Terry Ritter has claimed in the past that BBS is only an asymptotic result, part of his general campaign to spread doubt on the technology. This is completely mistaken and I am sorry to see you add credence to his misconceptions. Subject: Re: OTP using BBS generator? Date: Thu, 10 Aug 2000 18:53:54 GMT From: ritter@io.com (Terry Ritter) Message-ID: <3992fa09.7827726@news.io.com> References: <20000810180025.3829.qmail@nym.alias.net> Newsgroups: sci.crypt Lines: 92 On 10 Aug 2000 18:00:25 -0000, in <20000810180025.3829.qmail@nym.alias.net>, in sci.crypt lcs Mixmaster Remailer <mix@anon.lcs.mit.edu> wrote: >David Hopwood writes: >> Note that the proofs in the BBS paper (and in the Crypto '84 paper by Vazirani >> and Vazirani proving a reduction to factoring) are all asymptotic, so >> unfortunately we can't make stronger statements relating the exact probability >> of being able to distinguish the BBS output from random with a specific amount >> of work, to the probability of being able to factor or solve the QRP with a >> similar amount of work (at least, not based on those proofs). But if the >> underlying question being debated in this thread is about the general validity >> of probabilistic proof, rather than its application to BBS in particular, then >> there are plenty of other cryptosystems for which exact reductions have been >> proven. > >First, thanks to the reference to Vazirani&Vazirani. We can dispense >with the awkward claim that BBS reduces to quadratic reciduosity, and >simply say that it reduces to factoring. If you think you need to check >for short cycles, then you think your opponent can factor your modulus >by guessing cycles. Obviously false: *I* think we all need to check for short cycles (if we are going to claim proven security) AND *I* don't think an opponent can factor N by guessing. The need to check for short cycles is to avoid actually *using* a short cycle and traversing that cycle, which is UNARGUABLY weak. Let me say that again: * THERE IS NO QUESTION that short cycles do exist in BB&S. * THERE IS NO QUESTION that if we select x0 at random, sooner or later we *WILL* select a short cycle. * THERE IS NO QUESTION but that if we use and traverse a short cycle, that *IS* insecure. But none of this gives the opponent an advantage in guessing cycles. One might think you hadn't even been following along. >However, you have made one very unfortunate misstatement, which is that >the proofs are asymptotic. This is not true, at least for the commonly >understood meaning, which would be that they are asymptotic in N, the >modulus, and so don't apply in general to any specific N. The proofs >are NOT asymptotic in N. BBS/Vazirani shows very clearly that for ANY >modulus, if you have an epsilon advantage for guessing the BBS sequence, >you can factor THAT modulus. > >(Furthermore, as was shown here, the ability to find short cycles by >guessing immediately leads to factoring in a much simpler way.) > >Terry Ritter has claimed in the past that BBS is only an asymptotic >result, Actually, I have given several alternatives which might explain the reality we see: On the one hand, mathematics claims proven security, and on the other, experimental evidence shows that insecurity exists. Experimental evidence always wins. It is now necessary to explain why the math does not agree. If you have a better explanation, we have yet to see it. >part of his general campaign to spread doubt on the technology. Questioning my motives is not addressing the issue; it is instead attempting to "win" by implying that you are more worth listening to than I. Disturbing, and embarrassing, really, because my arguments do not depend upon trusting me. The arguments can be understood on their own by anyone who has even a modest understanding of random number generators. >This is completely mistaken and I am sorry to see you add credence to >his misconceptions. The misconceptions are yours, and apparently you will do anything you can to avoid being forced to think about this. You have your idea and you will not be moved. Your idea is wrong. It is not true that factoring is unconditionally hard. Factoring is easy when a factor is leaked. That is what the reduced BB&S does when it uses a short cycle. So if we want to depend upon factoring being hard, we had better arrange to not use a short cycle. --- Terry Ritter ritter@io.com http://www.io.com/~ritter/ Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM Subject: Re: OTP using BBS generator? Date: Thu, 10 Aug 2000 13:47:13 -0600 From: John Myre <jmyre@sandia.gov> Message-ID: <399306C1.CE625234@sandia.gov> References: <3992fa09.7827726@news.io.com> Newsgroups: sci.crypt Lines: 15 Terry Ritter wrote: <snip> > * THERE IS NO QUESTION that if we select x0 at random, sooner or > later we *WILL* select a short cycle. <snip> No. If an event has sufficiently low probability, then it is perfectly sane and reasonable to design a system assuming it will never happen. The system will have a finite lifetime. Depending on the actual probabilities, it is certainly possible that the unlikely will in fact fail to happen at all. JM Subject: Re: OTP using BBS generator? Date: Thu, 10 Aug 2000 21:12:06 GMT From: ritter@io.com (Terry Ritter) Message-ID: <39931a77.2765864@news.io.com> References: <399306C1.CE625234@sandia.gov> Newsgroups: sci.crypt Lines: 44 On Thu, 10 Aug 2000 13:47:13 -0600, in <399306C1.CE625234@sandia.gov>, in sci.crypt John Myre <jmyre@sandia.gov> wrote: >Terry Ritter wrote: ><snip> >> * THERE IS NO QUESTION that if we select x0 at random, sooner or >> later we *WILL* select a short cycle. ><snip> > >No. > >If an event has sufficiently low probability, then it is perfectly >sane and reasonable to design a system assuming it will never >happen. The system will have a finite lifetime. Depending on >the actual probabilities, it is certainly possible that the >unlikely will in fact fail to happen at all. No. This discussion has not been concerned with practical weakness per se, but instead the claim that such a system is "proven secure." The examples have amply demonstrated that such a system may be weak. So we find that the "proven strength" did not in fact imply strength in every case, just in most cases. The issue is "proof," and to understand that we need to know what happens in *every* case, not just a handwave representing the majority of cases. Claiming that reduced BB&S is secure in every x0 selection is obviously just plain wrong. Knowing that, we can see that the most the proof can possibly mean is that in *other* cases, BB&S is strong. In practice, the whole reason for using BB&S is to get a proof of strength; most people probably think means that there simply are no weaknesses. Yet here we have a case -- and there is no reason to think that short cycles are the only case -- where the system *is* *unarguably* *insecure*, and that case is known but not even checked for. In this situation, a claim of "proven secure" would be inappropriate. I suggest "proven almost never weak." --- Terry Ritter ritter@io.com http://www.io.com/~ritter/ Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM Subject: Re: OTP using BBS generator? Date: Thu, 10 Aug 2000 16:44:20 -0600 From: John Myre <jmyre@sandia.gov> Message-ID: <39933044.1B8AEF20@sandia.gov> References: <39931a77.2765864@news.io.com> Newsgroups: sci.crypt Lines: 100 Terry Ritter wrote: > > On Thu, 10 Aug 2000 13:47:13 -0600, in <399306C1.CE625234@sandia.gov>, > in sci.crypt John Myre <jmyre@sandia.gov> wrote: > > >Terry Ritter wrote: > ><snip> > >> * THERE IS NO QUESTION that if we select x0 at random, sooner or > >> later we *WILL* select a short cycle. > ><snip> > > > >No. > > > >If an event has sufficiently low probability, then it is perfectly > >sane and reasonable to design a system assuming it will never > >happen. The system will have a finite lifetime. Depending on > >the actual probabilities, it is certainly possible that the > >unlikely will in fact fail to happen at all. > > No. This discussion has not been concerned with practical weakness > per se, but instead the claim that such a system is "proven secure." That may be the overall discussion, but I snipped stuff for a reason. I wanted merely to caution readers that the one statement Terry made at the top was simply false. That caution does not prove that BBS is secure; in fact I was not referring specifically to BBS at all. This thread is a debate. Most of the posters seem to think they know what the correct conclusions are. I am addressing myself to those readers who are just trying to decide what to believe. I think it is reasonable to single out a statement within a debate when the statement is incorrect, without attempting to replace the statement or reformulate an entire argument. No doubt some consider that I am using a debating trick; I seem to recall that term cropping up. No doubt some people make decisions on what to believe based entirely on cut-out pieces of a debate, without actually thinking it through. Nonetheless, I deem it proper to contribute comments on details. > The examples have amply demonstrated that such a system may be weak. > So we find that the "proven strength" did not in fact imply strength > in every case, just in most cases. > > The issue is "proof," and to understand that we need to know what > happens in *every* case, not just a handwave representing the majority > of cases. Claiming that reduced BB&S is secure in every x0 selection > is obviously just plain wrong. I don't see anyone actually claiming that. Maybe there are some. What I've seen in this thread is a claim that the security of BBS, and the nature of the "proof", makes individual x0 properties irrelevant. That is, the claim is that the probability of "weakness" is "negligible", which is to say, a "weak" x0 will happen so seldom that there is no point in worrying about it. The theoretical arguments merely make this technically precise. > Knowing that, we can see that the most > the proof can possibly mean is that in *other* cases, BB&S is strong. > In practice, the whole reason for using BB&S is to get a proof of > strength; most people probably think means that there simply are no > weaknesses. That may be so, but I'm not convinced that the short cycles have much to do with this. See below on terminology. > Yet here we have a case -- and there is no reason to > think that short cycles are the only case -- where the system *is* > *unarguably* *insecure*, and that case is known but not even checked > for. In this situation, a claim of "proven secure" would be > inappropriate. > > I suggest "proven almost never weak." <snip> There are really two, almost independant, problems here. One is the problem of terminology. Claims of "proven strength" are, of course, problematic when we assume that the decision maker does not actually understand what the BBS paper "proves". It is reasonable to try to explain it in "layman's terms". I disagree, however, that "proven almost never weak" is any better. It still contains the terms that generate the confusion in the first place ("prove" and "strong/weak"). Second, there is the problem of whether the known short cycles are relevant for the technical claims made for BBS. I don't understand the math well enough to judge for myself. Still, I find the arguments in favor of ignoring the short cycles convincing: the actual claims made for BBS strength do not depend on eliminating short cycles. Since short cycles can exist, the BBS strength claim cannot be interpreted as a guarantee that the opponent can never break any particular sequence. There is a way to eliminate some "weak" cases (by selecting the BBS parameters in the careful way defined in the BBS paper). In doing so, however, we do not get any better guarantee of strength, in the sense of the proofs in the BBS paper. It might in fact be better, but the guarantee isn't any better. JM Subject: Re: OTP using BBS generator? Date: Fri, 11 Aug 2000 02:19:48 GMT From: ritter@io.com (Terry Ritter) Message-ID: <3993627c.8044956@news.io.com> References: <39933044.1B8AEF20@sandia.gov> Newsgroups: sci.crypt Lines: 141 On Thu, 10 Aug 2000 16:44:20 -0600, in <39933044.1B8AEF20@sandia.gov>, in sci.crypt John Myre <jmyre@sandia.gov> wrote: >Terry Ritter wrote: >> >> On Thu, 10 Aug 2000 13:47:13 -0600, in <399306C1.CE625234@sandia.gov>, >> in sci.crypt John Myre <jmyre@sandia.gov> wrote: >> >> >Terry Ritter wrote: >> ><snip> >> >> * THERE IS NO QUESTION that if we select x0 at random, sooner or >> >> later we *WILL* select a short cycle. >> ><snip> >> > >> >No. >> > >> >If an event has sufficiently low probability, then it is perfectly >> >sane and reasonable to design a system assuming it will never >> >happen. The system will have a finite lifetime. Depending on >> >the actual probabilities, it is certainly possible that the >> >unlikely will in fact fail to happen at all. >> >> No. This discussion has not been concerned with practical weakness >> per se, but instead the claim that such a system is "proven secure." > >That may be the overall discussion, but I snipped stuff for a >reason. I wanted merely to caution readers that the one statement >Terry made at the top was simply false. My statement is correct. As I have said many, many times, this is a theoretical analysis, and not a description of problems in practical use. I note that you make your assertion, then fail to supply reason to believe it. In analysis, we must assume that any random selection which is not actually prevented may occur. Indeed, if we run enough systems long enough the statistics assures us that such a thing *will* occur, such being the meaning of probability. There is a reason we call selecting a short cycle "improbable," and do not call it "impossible": that reason is that selecting a short cycle *is* possible, just unlikely. Moreover, whether the event actually occurs is governed completely by chance, and in chance any value can come up next -- even a bad value. To say this is unlikely misses the point. Now, if the user gets the BB&S system, and it happens to select a short cycle, and the data then traverse that cycle, the system is insecure. That is simply indisputable. But what does the user say about the math proof then? Has it helped him, or deceived him? >There are really two, almost independant, problems here. One is >the problem of terminology. Claims of "proven strength" are, of >course, problematic when we assume that the decision maker does >not actually understand what the BBS paper "proves". It is >reasonable to try to explain it in "layman's terms". I disagree, >however, that "proven almost never weak" is any better. It still >contains the terms that generate the confusion in the first place >("prove" and "strong/weak"). There is no problem with the word "proof" until something less that a complete proof is also called "proof." But when we have something less, we can just use a modifier and say, for example, "statistical proof," or whatever. In this discussion, I am not aware of a problem with "strong/weak." I think we agree that a traversed cycle is weak. Other than that case, which is the discussion, we are assuming the generator to be strong. Perhaps the only problem is exactly as above, the use of "strong" to mean "statistically strong." >Second, there is the problem of whether the known short cycles are >relevant for the technical claims made for BBS. I don't >understand the math well enough to judge for myself. There really is no math involved. The issue is what is being claimed. If you think that what is claimed is security in every case, then the claim is wrong with the reduced system. If you think that what is being claimed is a probability of strength -- "almost always" security -- then the claim is probably right. My problem with this has always been the improper, casual and misleading description of the claim as "proven secure." A true proof is not really discussable: it is a fact. So we often have seen that claim of proof waved around to avoid discussion of possible BB&S weakness. If we have an absolute claim that BB&S is secure -- even when not constructed as described in BB&S -- all it takes is one case to disprove that claim. That case exists and is short cycles. Of course, we would not even have that case if shortcuts were not taken from the real BB&S construction by failing to eliminate the use of short cycles. If we have some lesser claim to BB&S security, it is time to start describing and treating it as a lesser claim, subject not only to major math assumptions, but also to misuse by shortcut. >Still, I >find the arguments in favor of ignoring the short cycles >convincing: the actual claims made for BBS strength do not depend >on eliminating short cycles. Since short cycles can exist, the >BBS strength claim cannot be interpreted as a guarantee that the >opponent can never break any particular sequence. Right. >There is a way >to eliminate some "weak" cases (by selecting the BBS parameters >in the careful way defined in the BBS paper). Right. >In doing so, however, >we do not get any better guarantee of strength, in the sense of >the proofs in the BBS paper. It might in fact be better, but the >guarantee isn't any better. I would say that we guarantee a lack of short-cycle weakness. Then, if that is really the only weakness, we have improved the strength. If we define strength as the minimum effort in any possible attack, and if some other weakness exists, I suppose that avoiding short-cycle problems might not improve things. But the proofs are supposed to assure that other weaknesses (other than basic math assumptions) do *not* exist. The short-cycle problem seems like a special case because it was explicitly prevented in the BB&S article. The short-cycle problem here can't really be exploited by attack; instead, the opponent must wait for the user to use a short cycle (which we could call a weak key), and then traverse that cycle. The problem seems more like a very rare mistaken release of plaintext or not-fully-ciphered ciphertext or something like that. It is a fault in the design which the opponent could exploit when it occurs. --- Terry Ritter ritter@io.com http://www.io.com/~ritter/ Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM Subject: Re: OTP using BBS generator? Date: Mon, 14 Aug 2000 21:11:21 GMT From: Benjamin Goldberg <goldbb2@earthlink.net> Message-ID: <39985D86.762C209C@earthlink.net> References: <3992fa09.7827726@news.io.com> Newsgroups: sci.crypt Lines: 42 Terry Ritter wrote: [snip] > The need to check for short cycles is to avoid actually *using* a > short cycle and traversing that cycle, which is UNARGUABLY weak. Let > me say that again: > * THERE IS NO QUESTION that short cycles do exist in BB&S. Agreed. > * THERE IS NO QUESTION that if we select x0 at random, sooner or > later we *WILL* select a short cycle. Agreed. But, will it happen in the lifetime of the universe? > * THERE IS NO QUESTION but that if we use and traverse a short cycle, > that *IS* insecure. Agreed. But, if it occurs two universe-lifetimes from now, should I worry? [snip] > Your idea is wrong. It is not true that factoring is unconditionally > hard. Factoring is easy when a factor is leaked. That is what the > reduced BB&S does when it uses a short cycle. So if we want to depend > upon factoring being hard, we had better arrange to not use a short > cycle. Hmm, in your short cycle example (PQ=1081, and the cycle length 11, I believe), how do we learn the factors of PQ from the LSBs of that cycle? -- "There's a mathematical reason not to trust Christians... The Buddhists believe that human lives repeat. The atheists believe that human lives terminate. That means that the Christians must believe that humans are irrational." - Matt Katinas "Not necessarily... they could think that humans are imaginary." - Rob Pease, in response to the above "Of course Christians think humans are irrational: They believe humans are transcendental, and all transcendentals are irrational. I suppose that all we can be certain of is that humans are complex." - Me, in response the the above Subject: Re: OTP using BBS generator? Date: Mon, 14 Aug 2000 23:07:47 GMT From: ritter@io.com (Terry Ritter) Message-ID: <39987b81.7486389@news.io.com> References: <39985D86.762C209C@earthlink.net> Newsgroups: sci.crypt Lines: 85 On Mon, 14 Aug 2000 21:11:21 GMT, in <39985D86.762C209C@earthlink.net>, in sci.crypt Benjamin Goldberg <goldbb2@earthlink.net> wrote: >Terry Ritter wrote: >[snip] >> The need to check for short cycles is to avoid actually *using* a >> short cycle and traversing that cycle, which is UNARGUABLY weak. Let >> me say that again: > >> * THERE IS NO QUESTION that short cycles do exist in BB&S. >Agreed. > >> * THERE IS NO QUESTION that if we select x0 at random, sooner or >> later we *WILL* select a short cycle. >Agreed. But, will it happen in the lifetime of the universe? > >> * THERE IS NO QUESTION but that if we use and traverse a short cycle, >> that *IS* insecure. >Agreed. But, if it occurs two universe-lifetimes from now, should >I worry? 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. Given one such example, we have to ask if more exist. If then the answer is "No, because that would break math," we have to ask how the original problem could possibly exist in the first place. I think we are now coming to a consensus position in which cryptographic proof has far less practical import than most of us previously thought. >[snip] >> Your idea is wrong. It is not true that factoring is unconditionally >> hard. Factoring is easy when a factor is leaked. That is what the >> reduced BB&S does when it uses a short cycle. So if we want to depend >> upon factoring being hard, we had better arrange to not use a short >> cycle. > >Hmm, in your short cycle example (PQ=1081, and the cycle length 11, I >believe), how do we learn the factors of PQ from the LSBs of that cycle? Bryan Olson has made that claim repeatedly, and I accepted that. But even if short cycles do not expose factoring, they certainly do expose the sequence. When a sequence repeats we can predict it. So if we can predict without being able to factor we have yet another interesting situation with respect to proof claims. After thinking about these issues for the last day or so, I think that part of our problem ultimately stems from a language ambiguity in the word "assumption." In reality there is not just one but many necessary assumptions. I would call "factoring is hard" a "major" assumption, because it is directly connected to extensive math reasoning. But other, *additional*, assumptions are *also* necessary, like "do not broadcast the factors" or "do not allow the system to expose the factors." I would call these "minor" assumptions, because they are connected with particular implementations and use. The distinction makes sense, because, obviously, a system can fail without impacting all of math. The ambiguity I see is that secure operation depends upon *all* the assumptions, major and minor. So if we have a situation where BB&S is weak, it is simply false to say it must mean that we can now prove a major math assumption is wrong: Since *all* assumptions are required for security, the lack of *any* *one* may be the cause of failure. It is simply incorrect reasoning to say that a BB&S system must be secure because we believe in the major math assumption. One implication of this is that we do not -- and presumably *can* not -- have a comprehensive list of minor assumptions. Yet until we have such a list, we cannot verify that all needed assumptions have been met. This situation has an uncanny resemblance to conventional cryptography, where if we just knew every problem that could occur, we could fix them all and have a "provably" secure cipher. Ciphers both with and without proof may have similar problems in practice. --- Terry Ritter ritter@io.com http://www.io.com/~ritter/ Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM Subject: Re: OTP using BBS generator? Date: 11 Aug 2000 01:00:14 -0000 From: lcs Mixmaster Remailer <mix@anon.lcs.mit.edu> Message-ID: <20000811010014.13179.qmail@nym.alias.net> References: <3990a002.1905423@news.io.com> Newsgroups: sci.crypt Lines: 52 Terry Ritter writes: > It is *not* difficult to factor N . . . if we give a factor away. To > even attempt to assume that factoring is difficult *implies* that the > system be constructed in such a way as to not give away the secret. > And a proper construction happens with BB&S (as far as I know), only > when short cycles are excluded from use. You are mixing up two things: the difficulty of factoring, and the proper construction of the BBS RNG. Factoring difficulty depends only on the choice of the factors. Nothing you do after that will affect how hard it is to factor them. Consider two RSA creators. One chooses an RSA modulus and lets the attacker try to factor it. The other chooses an RSA modulus and then sends random large integers to the attacker, which the attacker may use to try to help him with factoring. It should be clear that the second system is not any weaker than the first one. It cannot leak any information about the RSA factors merely by sending random data. If it could, then the first system's attacker could achieve the same strength simply by using a source of random values to aid its efforts. In particular, there is no reason for the second system to filter or check the random values that it sends in any way. Since these values cannot aid the attacker, there is no reason to worry that one of them may happen to reveal a factor of the RSA modulus. If circumstances were such that that could happen, the attacker could find the same information himself by running his own RNG. The second system, without any checks, still has security equal to that of the first. Its security is that of factoring an RSA modulus. The second system is very similar to the BBS RNG, in that we choose an RSA modulus and then we choose an independent random value to be the seed. Terry Ritter is worried that this seed could lead to a short cycle. It has been proven that if this happens, the RSA modulus could be factored. Therefore, if checking seeds to avoid those that lead to factorization is necessary, as Terry Ritter argues, it follows that in the second system above, it is also necessary to check the random values which are sent in order to make sure that none of them could lead to factors. The information which is being revealed in each case as the same effect. Since we've already established that no such checking is necessary for the second RSA system, it follows that no such checking is necessary for BBS. BBS has all the security of the factoring problem, even when its seeds are not checked for any special properties. They only have to be randomly chosen. This is what is proven in BBS and the subsequent literature. Subject: Re: OTP using BBS generator? Date: Fri, 11 Aug 2000 16:03:52 -0400 From: "Trevor L. Jackson, III" <fullmoon@aspi.net> Message-ID: <39945C28.5C00E778@aspi.net> References: <20000811010014.13179.qmail@nym.alias.net> Newsgroups: sci.crypt Lines: 67 lcs Mixmaster Remailer wrote: > Terry Ritter writes: > > > It is *not* difficult to factor N . . . if we give a factor away. To > > even attempt to assume that factoring is difficult *implies* that the > > system be constructed in such a way as to not give away the secret. > > And a proper construction happens with BB&S (as far as I know), only > > when short cycles are excluded from use. > > You are mixing up two things: the difficulty of factoring, and the > proper construction of the BBS RNG. > > Factoring difficulty depends only on the choice of the factors. > Nothing you do after that will affect how hard it is to factor them. > > Consider two RSA creators. One chooses an RSA modulus and lets the > attacker try to factor it. The other chooses an RSA modulus and then > sends random large integers to the attacker, which the attacker may > use to try to help him with factoring. Up to this point I follow your argument, but at this point there's a gap. It sounds to me that the "random larger integers" sent to the second attacker are, for exampe, RSA ciphertexts produced by the second creator. Is this correct or did you mean "random large integers" literally? > > > It should be clear that the second system is not any weaker than the > first one. It cannot leak any information about the RSA factors merely > by sending random data. If it could, then the first system's attacker > could achieve the same strength simply by using a source of random values > to aid its efforts. If the above interpretation is correct the first attack cannot send himself ciphertexts because he lacks the private key retained by the first creator. > > > In particular, there is no reason for the second system to filter or > check the random values that it sends in any way. Since these values > cannot aid the attacker, there is no reason to worry that one of them > may happen to reveal a factor of the RSA modulus. If circumstances > were such that that could happen, the attacker could find the same > information himself by running his own RNG. > > The second system, without any checks, still has security equal to that > of the first. Its security is that of factoring an RSA modulus. > > The second system is very similar to the BBS RNG, in that we choose an RSA > modulus and then we choose an independent random value to be the seed. > Terry Ritter is worried that this seed could lead to a short cycle. > It has been proven that if this happens, the RSA modulus could be > factored. > > Therefore, if checking seeds to avoid those that lead to factorization > is necessary, as Terry Ritter argues, it follows that in the second > system above, it is also necessary to check the random values which are > sent in order to make sure that none of them could lead to factors. > The information which is being revealed in each case as the same effect. > > Since we've already established that no such checking is necessary for the > second RSA system, it follows that no such checking is necessary for BBS. > BBS has all the security of the factoring problem, even when its seeds > are not checked for any special properties. They only have to be randomly > chosen. This is what is proven in BBS and the subsequent literature. Subject: Re: OTP using BBS generator? Date: Sat, 12 Aug 2000 02:56:48 -0400 From: "Trevor L. Jackson, III" <fullmoon@aspi.net> Message-ID: <3994F530.8E4B68C1@aspi.net> References: <20000811010014.13179.qmail@nym.alias.net> Newsgroups: sci.crypt Lines: 76 Since you answered my first response with a clarification I'm returning to your previous message to continue trying to interpret it. lcs Mixmaster Remailer wrote: > Terry Ritter writes: > > > It is *not* difficult to factor N . . . if we give a factor away. To > > even attempt to assume that factoring is difficult *implies* that the > > system be constructed in such a way as to not give away the secret. > > And a proper construction happens with BB&S (as far as I know), only > > when short cycles are excluded from use. > > You are mixing up two things: the difficulty of factoring, and the > proper construction of the BBS RNG. > > Factoring difficulty depends only on the choice of the factors. > Nothing you do after that will affect how hard it is to factor them. > > Consider two RSA creators. One chooses an RSA modulus and lets the > attacker try to factor it. The other chooses an RSA modulus and then > sends random large integers to the attacker, which the attacker may > use to try to help him with factoring. > > It should be clear that the second system is not any weaker than the > first one. It cannot leak any information about the RSA factors merely > by sending random data. If it could, then the first system's attacker > could achieve the same strength simply by using a source of random values > to aid its efforts. > > In particular, there is no reason for the second system to filter or > check the random values that it sends in any way. Since these values > cannot aid the attacker, there is no reason to worry that one of them > may happen to reveal a factor of the RSA modulus. If circumstances > were such that that could happen, the attacker could find the same > information himself by running his own RNG. > > The second system, without any checks, still has security equal to that > of the first. Its security is that of factoring an RSA modulus. > > The second system is very similar to the BBS RNG, in that we choose an RSA > modulus and then we choose an independent random value to be the seed. > Terry Ritter is worried that this seed could lead to a short cycle. > It has been proven that if this happens, the RSA modulus could be > factored. > > Therefore, if checking seeds to avoid those that lead to factorization > is necessary, as Terry Ritter argues, it follows that in the second > system above, it is also necessary to check the random values which are > sent in order to make sure that none of them could lead to factors. > The information which is being revealed in each case as the same effect. > > Since we've already established that no such checking is necessary for the > second RSA system, it follows that no such checking is necessary for BBS. > BBS has all the security of the factoring problem, even when its seeds > are not checked for any special properties. They only have to be randomly > chosen. This is what is proven in BBS and the subsequent literature. If I understand this correctly it amounts to a claim that a rational attacker will not test for short cycles because the effort expended, when discounted by the odds of success, does not get him any closer to cracking the system than an equivalent amount of effort invested in a QR search. So those who advocate checking for BBS short cycles do so out of superstition rather than rationality. Is this a fair conclusion? If so, it is similar to the reasons why one need not check for long stretches of zeros in an OTP key. The odds of a significant fraction of the pad being zero are so long that a sane attacker will not even inspect the ciphertext. Of course an attacker who does notice a long stretch of intelligible cipher text could argue that the odds against the text appearing accidentally are so long that a null key pad is the simplest explanation. Are all opponents sane? Subject: Re: OTP using BBS generator? Date: Sat, 12 Aug 2000 09:47:34 +0200 From: Mok-Kong Shen <mok-kong.shen@t-online.de> Message-ID: <39950116.5C41B065@t-online.de> References: <3994F530.8E4B68C1@aspi.net> Newsgroups: sci.crypt Lines: 20 "Trevor L. Jackson, III" wrote: > > If so, it is similar to the reasons why one need not check for long stretches > of zeros in an OTP key. The odds of a significant fraction of the pad being > zero are so long that a sane attacker will not even inspect the ciphertext. > Of course an attacker who does notice a long stretch of intelligible cipher > text could argue that the odds against the text appearing accidentally are so > long that a null key pad is the simplest explanation. > > Are all opponents sane? I am interested to see the result of discussions on the above issue, though I have nothing to contribute myself. A question that occurs to me though is: Is the science of crypto entirely separated from psychology? M. K. Shen Subject: Re: OTP using BBS generator? Date: Mon, 14 Aug 2000 02:59:52 +0100 From: David Hopwood <hopwood@zetnet.co.uk> Message-ID: <39975298.56217BF@zetnet.co.uk> References: <3994F530.8E4B68C1@aspi.net> Newsgroups: sci.crypt Lines: 47 -----BEGIN PGP SIGNED MESSAGE----- "Trevor L. Jackson, III" wrote: > lcs Mixmaster Remailer wrote: [...] > > BBS has all the security of the factoring problem, even when its seeds > > are not checked for any special properties. They only have to be randomly > > chosen. This is what is proven in BBS and the subsequent literature. > > If I understand this correctly it amounts to a claim that a rational attacker > will not test for short cycles because the effort expended, when discounted by > the odds of success, does not get him any closer to cracking the system than > an equivalent amount of effort invested in a QR search. Yes. [...] > Are all opponents sane? No, but that doesn't matter - an attacker that uses an inefficient method of factoring will not have any greater success probability (for a given amount of work) than one that uses a more efficient method. - -- David Hopwood <hopwood@zetnet.co.uk> Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/ RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01 Nothing in this message is intended to be legally binding. If I revoke a public key but refuse to specify why, it is because the private key has been seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv iQEVAwUBOZdSiTkCAxeYt5gVAQE9+QgAzU88NptJnMejmiiATlxT2e4NcMFuod6U y4Wy2o3gxL5guHCZlCL6t7y51bLdXekHYDKs4exy1Uenu01CLHayyy4XBvNmT6XH kunIFGxCqe3VZ/A+67cYKH61vtkLl6hp4zcJJJiFV/Gu/mrWywmYK+izWq7cm46Z XoCe0VIJ3btGRtMj/O6PSdqu58YzIbdTJfZweO6UJ8ik9YXENpZC3KCWjdVZPlGH 4LuDCJ80sQUZJjbUOmKQiCJYAbHw+VS8f2Td/OIP454mat2cZmlMkD0bNAbsiue9 Dr7V9p2d9GDi2XVIZEb//nSKedrJcue8Fv5BmpOFJ7nwa5VcgrxC3A== =HNf2 -----END PGP SIGNATURE----- Subject: Re: OTP using BBS generator? Date: Mon, 14 Aug 2000 11:14:43 GMT From: Tim Tyler <tt@cryogen.com> Message-ID: <FzA4KI.IMF@bath.ac.uk> References: <3994F530.8E4B68C1@aspi.net> Newsgroups: sci.crypt Lines: 33 Trevor L. Jackson, III <fullmoon@aspi.net> wrote: [snip far too much] : If I understand this correctly it amounts to a claim that a rational attacker : will not test for short cycles because the effort expended, when discounted by : the odds of success, does not get him any closer to cracking the system than : an equivalent amount of effort invested in a QR search. [...] *If* so, the argument does not appear very convincing. What if the attacker has a dedicated, parallel, short-cycle testing machine - built for some other purpose - but only a general purpose serial computer for use in factoring? It appears that such an asymmetry could skew his best strategy significantly in favour of looking for short cycles rather than factoring - in which case eliminating short cycles might genuinely help. This is what I believe Ritter calls an "additional" weakness. : If so, it is similar to the reasons why one need not check for long stretches : of zeros in an OTP key. [...] I don't like this analogy. I think it has great potential to mislead :-/ : Are all opponents sane? Perhaps not - but its probably not sane to concern yourself overly much with any insane ones ;-) -- __________ Lotus Artificial Life http://alife.co.uk/ tt@cryogen.com |im |yler The Mandala Centre http://mandala.co.uk/ Namaste. Subject: Re: OTP using BBS generator? Date: Mon, 14 Aug 2000 10:00:40 -0400 From: "Trevor L. Jackson, III" <fullmoon@aspi.net> Message-ID: <3997FB88.F0903BFC@aspi.net> References: <FzA4KI.IMF@bath.ac.uk> Newsgroups: sci.crypt Lines: 43 Tim Tyler wrote: > Trevor L. Jackson, III <fullmoon@aspi.net> wrote: > > [snip far too much] > > : If I understand this correctly it amounts to a claim that a rational attacker > : will not test for short cycles because the effort expended, when discounted by > : the odds of success, does not get him any closer to cracking the system than > : an equivalent amount of effort invested in a QR search. [...] > > *If* so, the argument does not appear very convincing. What if the > attacker has a dedicated, parallel, short-cycle testing machine - built > for some other purpose - but only a general purpose serial computer > for use in factoring? > > It appears that such an asymmetry could skew his best strategy > significantly in favour of looking for short cycles rather than > factoring - in which case eliminating short cycles might > genuinely help. > > This is what I believe Ritter calls an "additional" weakness. > > : If so, it is similar to the reasons why one need not check for long stretches > : of zeros in an OTP key. [...] > > I don't like this analogy. I think it has great potential to mislead :-/ I was trying very hard to avoid calling it a statistical conclusion. > > > : Are all opponents sane? > > Perhaps not - but its probably not sane to concern yourself overly much > with any insane ones ;-) So we should ignore the irrational ones who will cover all bases and thus crack messages by finding short cycles we've overlooked. I'd rather not over look them. ;-) Subject: Re: OTP using BBS generator? Date: Mon, 14 Aug 2000 20:27:40 -0600 From: "Tony T. Warnock" <u091889@cic-mail.lanl.gov> Message-ID: <3998AA9C.4C668A06@cic-mail.lanl.gov> References: <3994F530.8E4B68C1@aspi.net> Newsgroups: sci.crypt Lines: 18 "Trevor L. Jackson, III" wrote: > If so, it is similar to the reasons why one need not check for long stretches > of zeros in an OTP key. The odds of a significant fraction of the pad being > zero are so long that a sane attacker will not even inspect the ciphertext. > Of course an attacker who does notice a long stretch of intelligible cipher > text could argue that the odds against the text appearing accidentally are so > long that a null key pad is the simplest explanation. > > Are all opponents sane? If a long stretch of zeros (length to be determined later) occured in a OTP, I would assume the generator was broken. Rare events rarely happen. At some point one decides that the probablity of a cooked generator is greater than that of getting a string of zeros. The number is somewhere between 1 zero and 100 zeros. Subject: Re: OTP using BBS generator? Date: Mon, 14 Aug 2000 14:08:48 -0400 From: "Trevor L. Jackson, III" <fullmoon@aspi.net> Message-ID: <399835B0.154BBD94@aspi.net> References: <3998AA9C.4C668A06@cic-mail.lanl.gov> Newsgroups: sci.crypt Lines: 49 "Tony T. Warnock" wrote: > "Trevor L. Jackson, III" wrote: > > > If so, it is similar to the reasons why one need not check for long stretches > > of zeros in an OTP key. The odds of a significant fraction of the pad being > > zero are so long that a sane attacker will not even inspect the ciphertext. > > Of course an attacker who does notice a long stretch of intelligible cipher > > text could argue that the odds against the text appearing accidentally are so > > long that a null key pad is the simplest explanation. > > > > Are all opponents sane? > > If a long stretch of zeros (length to be determined later) occured in a OTP, I > would assume the generator was broken. Rare events rarely happen. At some point > one decides that the probablity of a cooked generator is greater than that of > getting a string of zeros. The number is somewhere between 1 zero and 100 zeros. OK, I'll bite on the bait. The red-zone alarm threshold may be a very personal thing. Mine is probably around the middle of the range you mentioned. How many random bits do I expect to use in my lifetime? And we need not recap years of discussion of whether to accept or reject sequences in the yellow zone of suspicious lengths. The best way to monitor an RNG is not to check for sequences of length > reject threshold, but to monitor the frequency sequences that are "near" the rejection threshold. In re parallels between BBS and OPT, the premise seems to be that a null OTP pad is probably indicative of an flawed RNG rather than a statistical artifact. So far so good. The point seems to be that finding a short cycle in a BBS generator is not the product of a broken mechanism, but a predictable consequence of the underlying math. Since those consequences can be contained (described and rendered negligible mathematically) in a way that broken RNGs cannot, they can be ignored while the threat of a broken RNG cannot ever be ignored. The conclusion can be disputed though. Consider a BBS generator fed subtly flawed RNG outputs (same cause -- broken RNG). Can we rely upon the proven BBS strength to protect us? I think not. The assumptions of the BBS proof are that factoring is "hard" and the seeds are "random". If either assumption is violated the proof still stands, but the conclusions based upon it do not. Thus given a suitably flawed (*) BBS seed generator the incidence of short cycles may be higher than expected -- it may no longer be negligible. (*) some number N of flaws to be named later ;-) Subject: Re: OTP using BBS generator? Date: Mon, 14 Aug 2000 21:40:38 +0200 From: Mok-Kong Shen <mok-kong.shen@t-online.de> Message-ID: <39984B36.4A2C9F03@t-online.de> References: <3998AA9C.4C668A06@cic-mail.lanl.gov> Newsgroups: sci.crypt Lines: 28 "Tony T. Warnock" wrote: > > "Trevor L. Jackson, III" wrote: > > > If so, it is similar to the reasons why one need not check for long stretches > > of zeros in an OTP key. The odds of a significant fraction of the pad being > > zero are so long that a sane attacker will not even inspect the ciphertext. > > Of course an attacker who does notice a long stretch of intelligible cipher > > text could argue that the odds against the text appearing accidentally are so > > long that a null key pad is the simplest explanation. > > > > Are all opponents sane? > > If a long stretch of zeros (length to be determined later) occured in a OTP, I > would assume the generator was broken. Rare events rarely happen. At some point > one decides that the probablity of a cooked generator is greater than that of > getting a string of zeros. The number is somewhere between 1 zero and 100 zeros. I tend to partake your view. An error of the cipher operator could also not be entirely neglected. A readable and reasonable text is very surely plaintext (though it could be steganography and the like). Further, how can the analyst 'really' know that the sender employs OTP (independent of the issue that ideal OTP doesn't exist (or determinable to exist) in practice)? M. K. Shen Subject: Re: OTP using BBS generator? Date: 12 Aug 2000 01:20:18 -0000 From: lcs Mixmaster Remailer <mix@anon.lcs.mit.edu> Message-ID: <20000812012018.21456.qmail@nym.alias.net> References: <3990a002.1905423@news.io.com> Newsgroups: sci.crypt Lines: 21 Trevor Jackson wrote: > lcs Mixmaster Remailer wrote: > > Consider two RSA creators. One chooses an RSA modulus and lets the > > attacker try to factor it. The other chooses an RSA modulus and then > > sends random large integers to the attacker, which the attacker may > > use to try to help him with factoring. > > Up to this point I follow your argument, but at this point there's a gap. It > sounds to me that the "random larger integers" sent to the second attacker > are, for exampe, RSA ciphertexts produced by the second creator. Is this > correct or did you mean "random large integers" literally? No, "random large integers" was meant literally. That's exactly what the BBS seed is. It's not chosen with knowledge of the factors of the RSA modulus. You can do BBS just fine by forgetting the factors as soon as you've generated the modulus. All this worry about seeds "leaking" the factors is absurd, which the present analysis is intended to show. To reiterate, users need not worry about a random integer leaking their RSA factors. For the same reason, they need not worry about a random BBS seed leading to a short cycle, or to a predictable sequence. Subject: Re: OTP using BBS generator? Date: 15 Aug 2000 01:20:32 -0000 From: lcs Mixmaster Remailer <mix@anon.lcs.mit.edu> Message-ID: <20000815012032.19114.qmail@nym.alias.net> References: <3990a002.1905423@news.io.com> Newsgroups: sci.crypt Lines: 54 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. 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. 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. Doesn't this sound familiar? It is exactly analogous to what you are saying. You are advising people to defend against a theoretical flaw which will never happen in practice. You are claiming that systems that don't check for this theoretical problem are weak and don't deserve to be called "true" BBS. You are saying that failing to check for this problem leaves your system with weakness. 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. And of course if anyone were ever so foolish as to follow Terry Ritter's advice in implementing BBS, they would appear equally amateurish. Subject: Re: OTP using BBS generator? Date: Tue, 15 Aug 2000 05:53:31 GMT From: ritter@io.com (Terry Ritter) Message-ID: <3998da00.4832073@news.io.com> References: <20000815012032.19114.qmail@nym.alias.net> Newsgroups: sci.crypt Lines: 161 On 15 Aug 2000 01:20:32 -0000, in <20000815012032.19114.qmail@nym.alias.net>, in sci.crypt lcs Mixmaster Remailer <mix@anon.lcs.mit.edu> 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 ritter@io.com http://www.io.com/~ritter/ Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM Subject: Re: OTP using BBS generator? Date: Mon, 7 Aug 2000 12:16:05 -0500 From: "Joseph Ashwood" <ashwood@msn.com> Message-ID: <uANMRKAAHA.347@cpmsnbbsa08> References: <398C511C.77C8210D@zetnet.co.uk> Newsgroups: sci.crypt Lines: 28 > 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 Subject: Re: OTP using BBS generator? Date: 4 Aug 2000 12:56:57 GMT From: mdw@nsict.org (Mark Wooding) Message-ID: <slrn8olfcm.ti5.mdw@mull.ncipher.com> References: <3989c299.4078028@news.io.com> Newsgroups: sci.crypt Lines: 24 Terry Ritter <ritter@io.com> wrote: > But I may be one of the few authors and designers who actively seeks > negative comments and then publishes those on my pages, as readers can > attest. > > My stuff is not intended to replace BB&S or PK, but if they have > problems that I see, I'm going to say so, independent of whether I can > profit from that or not. True, and most praiseworthy. > For free, I offer a 400K Crypto Glossary, plus a free Introduction to > Cryptography, Literature Surveys also free, plus lots of other stuff. > You don't have to buy a book to read my stuff, but if you want to read > it in a library, you can do that too, on any Web terminal. Indeed. This is excellent work, thoroughly worth reading. I honestly don't wish to detract from your great contribution to cryptography in general, and sci.crypt in particular, over the years. I'll respond to your technical points in a separate article. -- [mdw] Subject: Re: OTP using BBS generator? Date: Sun, 06 Aug 2000 23:10:25 GMT From: Benjamin Goldberg <goldbb2@earthlink.net> Message-ID: <398C8DEC.DB275765@earthlink.net> References: <3989c299.4078028@news.io.com> Newsgroups: sci.crypt Lines: 84 Terry Ritter wrote: > > On Thu, 03 Aug 2000 07:01:49 -0700, in > <0ebe7ce0.c2ca4460@usw-ex0105-040.remarq.com>, in sci.crypt lordcow77 > <london222NOloSPAM@netzero.com.invalid> wrote: > > >Mok-Kong Shen <mok-kong.shen@t-online.de> wrote: > >>BBS has been a recurring topic in this group. I have little > >>knowledge in that but I have the impression that discussions > >>about it never led to unanimously accepted results. You > >>may try to look into old postings of this group. > > > >Wrong. Practically everyone accepts that choosing the factors of > >the modulus to be congruent to 3 mod 4 and picking a random > >starting point are enough to ensure that the resulting BBS > >sequence will be secure, based on the computational equivalence > >of predicting BBS and deciding quadratic residuosity (and > >therefore factoring). > > That is false on its face. You can accept if you want, however. > > It is true that using a short cycle would be extremely unlikely. But > *when* that event occurs, all the math proofs you have will not save > you, since the resulting system is insecure. I'm confused... a) If the factors of the modulus ARE congruent to 3 mod 4, then are short cycles likely, unlikely, possible, or impossible? b) If the factors of the modulus AREN'T congruent to 3 mod 4, then what? That is, what does that conguency gain, if not (complete?) avoidance of short cycles? > Using a short cycle is unarguably insecure. And, unless we > specifically prevent it, using a short cycle is an unarguable > possibility. Makeing the factors congruent to 3 mod 4 isn't a specific prevention of short cycles? > The only valid argument here is that using a short cycle would be > extremely unlikely, and that is no conflict, because I agree. > > >Terry Ritter is the only proponent of the > >position that one must take elaborate steps to ensure that one > >falls into a guaranteed long cycle on the basis of a > >misunderstanding of the security proof given by Blum, Blum, and > >Shub and a desire to assert that no cipher can be proven to be > >secure under reasonable assumptions, such that he can promote > >his own products that "stack" multiple patented algorithms > >together. > > Alas for the attempt at a personal attack, I have no current > "products" in that sense. I do hold current patents which represent > fundamentally new cryptographic technology. You can like that or you > can hate it, but I own the technology anyway. > > Does the fact that I might make money out of improving technology > somehow make me suspect for pointing out the problems in other > approaches? Finding the problems is why I have better approaches. > But I may be one of the few authors and designers who actively seeks > negative comments and then publishes those on my pages, as readers can > attest. > > My stuff is not intended to replace BB&S or PK, but if they have > problems that I see, I'm going to say so, independent of whether I can > profit from that or not. > > I have been doing this for the better part of a decade, and I don't > need to have my motives questioned. By pointing out problems, others > can make their own informed choices about how to solve those problems > or perhaps use something else. My patented technology provides > alternatives which others may weigh against the price of its use. > > For free, I offer a 400K Crypto Glossary, plus a free Introduction to > Cryptography, Literature Surveys also free, plus lots of other stuff. > You don't have to buy a book to read my stuff, but if you want to read > it in a library, you can do that too, on any Web terminal. > > --- > Terry Ritter ritter@io.com http://www.io.com/~ritter/ > Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM Subject: Re: OTP using BBS generator? Date: Mon, 07 Aug 2000 04:51:21 GMT From: ritter@io.com (Terry Ritter) Message-ID: <398e402c.1820399@news.io.com> References: <398C8DEC.DB275765@earthlink.net> Newsgroups: sci.crypt Lines: 61 On Sun, 06 Aug 2000 23:10:25 GMT, in <398C8DEC.DB275765@earthlink.net>, in sci.crypt Benjamin Goldberg <goldbb2@earthlink.net> wrote: >[...] >I'm confused... >a) If the factors of the modulus ARE congruent to 3 mod 4, then are >short cycles likely, unlikely, possible, or impossible? Short cycles appear to be inherent in the construction. >b) If the factors of the modulus AREN'T congruent to 3 mod 4, then what? Presumably there would be no advantage in doing that. >That is, what does that conguency gain, if not (complete?) avoidance of >short cycles? If you are implying that congruency *does* avoid short cycles, the only thing I can say is that you don't have to sit back and trust what any of us says: You can check it yourself, and in fact you should. From my Cryptologia article: http://www.io.com/~ritter/ARTS/CRNG2ART.HTM#Sect4.4 'As an illustration, consider the x^2 mod N system of P = 23, Q = 47 (N = 1081), a system specifically given as an example "of the prescribed form" (p. 378): Starting with x[0] = 46 we get 1035, then 1035 repeatedly; a degenerate cycle. Starting with x[0] = 47, we get 47 again; another degenerate cycle. Starting with x[0] = 48, we get 142, 706, 95, 377, 518, 236, 565, 330, 800, and 48; a 10-state cycle. And starting with x[0] = 24, we get 576, 990, 714, 645, 921, 737, 507, 852, 553, 967, and 24; an 11-state cycle. Other cycles include another 10-state cycle (x[0] = 94), three more 11-state cycles (x[0] = 437, 484 and 529), and a couple of much more desirable 110-state cycles (x[0] = 2 and 3).' >> Using a short cycle is unarguably insecure. And, unless we >> specifically prevent it, using a short cycle is an unarguable >> possibility. > >Makeing the factors congruent to 3 mod 4 isn't a specific prevention of >short cycles? You don't have to ask; check it out: 23 is congruent to what, mod 4? 47 is congruent to what, mod 4? Is 46 relatively prime to 1081? --- Terry Ritter ritter@io.com http://www.io.com/~ritter/ Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM Subject: Re: OTP using BBS generator? Date: Tue, 08 Aug 2000 01:43:46 GMT From: Benjamin Goldberg <goldbb2@earthlink.net> Message-ID: <398F6581.D61DA863@earthlink.net> References: <398e402c.1820399@news.io.com> Newsgroups: sci.crypt Lines: 30 Terry Ritter wrote: [snip] > > From my Cryptologia article: > > http://www.io.com/~ritter/ARTS/CRNG2ART.HTM#Sect4.4 > > 'As an illustration, consider the x^2 mod N system of P = 23, Q = 47 > (N = 1081), a system specifically given as an example "of the > prescribed form" (p. 378): Starting with x[0] = 46 we get 1035, then > 1035 repeatedly; a degenerate cycle. Starting with x[0] = 47, we get > 47 again; another degenerate cycle. Starting with x[0] = 48, we get > 142, 706, 95, 377, 518, 236, 565, 330, 800, and 48; a 10-state cycle. > And starting with x[0] = 24, we get 576, 990, 714, 645, 921, 737, 507, > 852, 553, 967, and 24; an 11-state cycle. Other cycles include > another 10-state cycle (x[0] = 94), three more 11-state cycles (x[0] = > 437, 484 and 529), and a couple of much more desirable 110-state > cycles (x[0] = 2 and 3).' I think I see... Perhaps there is some relationship between P and Q we can test for which will avoid short cycles, which isn't part of the current parameter choosing process. I would point out that, in your particular example, Q = 2P + 1; perhaps this relation is irrelevant, and short cycles may still hold if it were false, but there might, nonetheless, be *something* we can test to avoid short cycles without doing an explicit search. Also, some of your starting seeds had close relationships to the primes: Your cycles started with {P+1, 2P, Q, Q+1, 2Q, 19P, 21P+1, 23P} as values for x[0]. I'm not sure if this is relevant, though. Subject: Re: OTP using BBS generator? Date: Tue, 08 Aug 2000 11:49:08 +0100 From: David Hopwood <hopwood@zetnet.co.uk> Message-ID: <398FE5A4.61763380@zetnet.co.uk> References: <398e402c.1820399@news.io.com> Newsgroups: sci.crypt Lines: 38 -----BEGIN PGP SIGNED MESSAGE----- Terry Ritter wrote: > On Sun, 06 Aug 2000 23:10:25 GMT, in > <398C8DEC.DB275765@earthlink.net>, in sci.crypt Benjamin Goldberg > <goldbb2@earthlink.net> wrote: > >b) If the factors of the modulus AREN'T congruent to 3 mod 4, then what? > > Presumably there would be no advantage in doing that. The factors of the modulus must be congruent to 3 mod 4 in order for the proofs in the BBS paper to apply. Note that this is entirely independent of the issue of short cycles. - -- David Hopwood <hopwood@zetnet.co.uk> Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/ RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01 Nothing in this message is intended to be legally binding. If I revoke a public key but refuse to specify why, it is because the private key has been seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv iQEVAwUBOY/liTkCAxeYt5gVAQG9ygf+I0Qo7hUQI67YnDwLA1Jj7fE01NTwx+Dp TxQKLS4KsKul7cg3Irev8c2qGCArj5zu8pe6rKOiRiDSzBrkuDo7aFr74TuqTqhr 24w5ogoYg0tHoEhPfM4qX86WeU75+PKDPX2JcBZIgomIRQO5oFSfwuQnUSLVPA/x FWZMoGXGFIwjjSmAOiyOkphiWRK+YMPrJGtdGKiqf4vOk5WPKF7oSKy43Tf9p+pL q880WBrGzgRLdf5WOPHNHMFlgYv2KJJ/Km4oveZkVn5h4Xe4+eXDk0D/OQQFMtVR RB9RCmEi8keES0hZw0qzjC562rGPbe9MPDbucdt1HJ3qLbc1obaU2Q== =9H8l -----END PGP SIGNATURE----- Subject: Re: OTP using BBS generator? Date: 7 Aug 2000 13:53:29 GMT From: mdw@nsict.org (Mark Wooding) Message-ID: <slrn8otfqo.ti5.mdw@mull.ncipher.com> References: <398C8DEC.DB275765@earthlink.net> Newsgroups: sci.crypt Lines: 91 Benjamin Goldberg <goldbb2@earthlink.net> wrote: > Terry Ritter wrote: > > > > On Thu, 03 Aug 2000 07:01:49 -0700, in > > <0ebe7ce0.c2ca4460@usw-ex0105-040.remarq.com>, in sci.crypt lordcow77 > > <london222NOloSPAM@netzero.com.invalid> wrote: > > > > >Mok-Kong Shen <mok-kong.shen@t-online.de> wrote: > > >>BBS has been a recurring topic in this group. I have little > > >>knowledge in that but I have the impression that discussions > > >>about it never led to unanimously accepted results. You > > >>may try to look into old postings of this group. > > > > > >Wrong. Practically everyone accepts that choosing the factors of > > >the modulus to be congruent to 3 mod 4 and picking a random > > >starting point are enough to ensure that the resulting BBS > > >sequence will be secure, based on the computational equivalence > > >of predicting BBS and deciding quadratic residuosity (and > > >therefore factoring). > > > > That is false on its face. You can accept if you want, however. > > > > It is true that using a short cycle would be extremely unlikely. But > > *when* that event occurs, all the math proofs you have will not save > > you, since the resulting system is insecure. > > I'm confused... > a) If the factors of the modulus ARE congruent to 3 mod 4, then are > short cycles likely, unlikely, possible, or impossible? Short cycles will exist. In particular, the values 0, 1, p, and q lead to cycles of period 1. These are the only four values for which x^2 = x (mod n). (Note that the equation x(x - 1) = 0 has two solutions x = 0 and x = 1 in any field, such as GF(p). The four values given correspond to combining the two solutions to the equation mod p and mod q using the Chinese Remainder Theorem.) If the primes are *large* (e.g., 512 bits each) then traversing an entire cycle of x^2 mod n will allow you to factor n. This isn't an efficient way of factoring large numbers, and the most efficient way of factoring numbers of that size is impractical, accidently *finding* a cycle long enough to be traversed is negligibly likely. At this point, the nature of the primes mod 4 isn't relevant... > b) If the factors of the modulus AREN'T congruent to 3 mod 4, then > what? Then the relationship between predicting the generator's output and the quadratic residuosity problem doesn't work properly and the proofs given in the paper don't apply. > That is, what does that conguency gain, if not (complete?) avoidance of > short cycles? It gains the relationship between predicting the generator's output and solving quadratic residuosity. Since traversing a cycle enables factoring, and factoring enables deciding quadratic residuosity, we know that finding a short cycle is at least as hard as ANY OTHER METHOD OF BREAKING THE GENERATOR. > > Using a short cycle is unarguably insecure. And, unless we > > specifically prevent it, using a short cycle is an unarguable > > possibility. > > Makeing the factors congruent to 3 mod 4 isn't a specific prevention of > short cycles? No. There are two approaches: * Acknowledge that finding a traversable cycle is impractical even if you try really hard, and just choose random primes. Note that any weakness due to choice of random primes also occurs in RSA, Rabin- Williams, and many other IFP-based cryptosystems. * Be very paranoid about cycles, choose your modulus very carefully, choose your seed very carefully too, and be unable to take advantage of the public-key nature of the generator[1]. I prefer the former approach. Terry prefers the latter. Read the arguments and take your pick. [1] My Springer CD has now arrived, containing, among other things, the BBS paper. I note that they explicitly suggest the use of the x^2 mod n generator as a public-key encryption algorithm. It's clearly impossible to use the generator in this way and choose the seed x_0 carefully to avoid short cycles. This can, I believe, be interpreted as clear evidence that the authors weren't particularly truobled by cycle lengths. -- [mdw] Subject: Re: OTP using BBS generator? Date: 8 Aug 2000 16:40:03 GMT From: David A Molnar <dmolnar@fas.harvard.edu> Message-ID: <8mpd53kal1@news.fas.harvard.edu> References: <398C8DEC.DB275765@earthlink.net> Newsgroups: sci.crypt Lines: 17 Benjamin Goldberg <goldbb2@earthlink.net> wrote: > I'm confused... > a) If the factors of the modulus ARE congruent to 3 mod 4, then are > short cycles likely, unlikely, possible, or impossible? > b) If the factors of the modulus AREN'T congruent to 3 mod 4, then what? A long time ago I built a BBS generator in Scheme. I found that there were varying cycle lengths when using a modulus n = p q with p and q congruent to 3 mod 4. When p or q were congruent to 1 mod 4, or not actually prime, then I ended up with an alternating 0-1-0-1-0-1 output. You can try this yourself if you have a favorite programming language with bignums; building a BBS generator doesn't even require modular inversion. -David Subject: Re: OTP using BBS generator? Date: Wed, 09 Aug 2000 19:23:25 +0200 From: Mok-Kong Shen <mok-kong.shen@t-online.de> Message-ID: <3991938D.C3A6B6FD@t-online.de> References: <8mpd53kal1@news.fas.harvard.edu> Newsgroups: sci.crypt Lines: 44 David A Molnar wrote: > > Benjamin Goldberg <goldbb2@earthlink.net> wrote: > > > I'm confused... > > a) If the factors of the modulus ARE congruent to 3 mod 4, then are > > short cycles likely, unlikely, possible, or impossible? > > b) If the factors of the modulus AREN'T congruent to 3 mod 4, then what? > > A long time ago I built a BBS generator in Scheme. I found that > there were varying cycle lengths when using a modulus n = p q with p and q > congruent to 3 mod 4. When p or q were congruent to 1 mod 4, or not > actually prime, then I ended up with an alternating 0-1-0-1-0-1 output. > You can try this yourself if you have a favorite programming language > with bignums; building a BBS generator doesn't even require modular > inversion. I find the phenomenon you observed fairly interesting. It means that in this case there is a (sufficiently long) sub-sequence of the output with numbers alternating between even and odd. Wouldn't it be conceivable that there be also (sufficiently long) sub-sequences of all even numbers or all odd numbers, giving rise to 00000.... or 11111...., though these has not been observed in your experiments? Anyway, in any such situation the statisticl quality of the bit sequence could evidently be considered to be very poor. Would the LSB of BBS, i.e. with p and q of the form 3 mod 4, have, on the other hand, very good statistical quality? The period length issue of the LBS sequence is yet to be confirmed (see a previous follow-up of mine in this thread). But the question of whether it does not contain sufficiently long sub-sequences of the above mentioned or similar genre seems to require elucidation too. I suppose one should probably do some amount of experiments with the serial tests and Maurer's universal statistical test. Until some such informations are available it seems to be rather risky to use BBS in my humble view. M. K. Shen --------------------------- http://home.t-online.de/home/mok-kong.shen Subject: Re: OTP using BBS generator? Date: Wed, 09 Aug 2000 23:39:31 +0200 From: Mok-Kong Shen <mok-kong.shen@t-online.de> Message-ID: <3991CF93.1C0646C4@t-online.de> References: <3991938D.C3A6B6FD@t-online.de> Newsgroups: sci.crypt Lines: 50 Mok-Kong Shen wrote: > > David A Molnar wrote: > > > > Benjamin Goldberg <goldbb2@earthlink.net> wrote: > > > > > I'm confused... > > > a) If the factors of the modulus ARE congruent to 3 mod 4, then are > > > short cycles likely, unlikely, possible, or impossible? > > > b) If the factors of the modulus AREN'T congruent to 3 mod 4, then what? > > > > A long time ago I built a BBS generator in Scheme. I found that > > there were varying cycle lengths when using a modulus n = p q with p and q > > congruent to 3 mod 4. When p or q were congruent to 1 mod 4, or not > > actually prime, then I ended up with an alternating 0-1-0-1-0-1 output. > > You can try this yourself if you have a favorite programming language > > with bignums; building a BBS generator doesn't even require modular > > inversion. > > I find the phenomenon you observed fairly interesting. It > means that in this case there is a (sufficiently long) > sub-sequence of the output with numbers alternating between > even and odd. Wouldn't it be conceivable that there be also > (sufficiently long) sub-sequences of all even numbers or > all odd numbers, giving rise to 00000.... or 11111...., > though these has not been observed in your experiments? > Anyway, in any such situation the statisticl quality of the > bit sequence could evidently be considered to be very poor. > > Would the LSB of BBS, i.e. with p and q of the form 3 mod 4, > have, on the other hand, very good statistical quality? The > period length issue of the LBS sequence is yet to be confirmed > (see a previous follow-up of mine in this thread). But the > question of whether it does not contain sufficiently long > sub-sequences of the above mentioned or similar genre seems > to require elucidation too. I suppose one should probably do > some amount of experiments with the serial tests and Maurer's > universal statistical test. Until some such informations are > available it seems to be rather risky to use BBS in my humble > view. I have just do an example with p=11, q=19, n=209. There is a cycle of length 4: (38, 190, 152, 114). Taking the LSB, we have all 0's. Isn't this extremely predictable? Would some experts please comment on this? Many thanks in advance. M. K. Shen Subject: Re: OTP using BBS generator? Date: Thu, 10 Aug 2000 23:28:05 GMT From: Tim Tyler <tt@cryogen.com> Message-ID: <Fz3nut.AEr@bath.ac.uk> References: <3991CF93.1C0646C4@t-online.de> Newsgroups: sci.crypt Lines: 10 Mok-Kong Shen <mok-kong.shen@t-online.de> wrote: : I have just do an example with p=11, q=19, n=209. There is : a cycle of length 4: (38, 190, 152, 114). Taking the LSB, : we have all 0's. [...] A potentially useful observation. Next, the "special" issue ;-) -- __________ Lotus Artificial Life http://alife.co.uk/ tt@cryogen.com |im |yler The Mandala Centre http://mandala.co.uk/ Namaste. Subject: Re: OTP using BBS generator? Date: Sat, 12 Aug 2000 03:54:47 GMT From: Benjamin Goldberg <goldbb2@earthlink.net> Message-ID: <39935EF2.9653208E@earthlink.net> References: <3991CF93.1C0646C4@t-online.de> Newsgroups: sci.crypt Lines: 15 Mok-Kong Shen wrote: [snip] > I have just do an example with p=11, q=19, n=209. There is > a cycle of length 4: (38, 190, 152, 114). Taking the LSB, > we have all 0's. Isn't this extremely predictable? Would > some experts please comment on this? Many thanks in advance. Your q isn't a Blum Integer, I don't think. -- Galibrath's Law of Human Nature: "Faced with the choice between changing one's mind and proving that there is no need to do so, almost everybody gets busy on the proof."-Vejita/Joel on #afd Subject: Re: OTP using BBS generator? Date: Sat, 12 Aug 2000 09:05:55 +0200 From: Mok-Kong Shen <mok-kong.shen@t-online.de> Message-ID: <3994F753.7086EB3A@t-online.de> References: <39935EF2.9653208E@earthlink.net> Newsgroups: sci.crypt Lines: 20 Benjamin Goldberg wrote: > > Your q isn't a Blum Integer, I don't think. p=11=2*4+3; q=19=4*4+3; are both Blum integers. But my example was no good. Here a (large) cycle of length 12: (4, 16, 47, 119, 158, 93, 80, 130, 180, 5, 25, 207) that gives rise to LBS of 001101000111 which seems to indicate that there is substantial correlations. Note however that a single example shows nothing definite but leads merely to a conjecture. What one needs is some amount of statistical tests on moduli that are bigger but small enough to readily reveal salient statistical features in the LSB, if there are indeed any. M. K. Shen Subject: Re: OTP using BBS generator? Date: Thu, 3 Aug 2000 17:31:19 GMT From: Tim Tyler <tt@cryogen.com> Message-ID: <Fyq8o7.n4F@bath.ac.uk> References: <398912AD.1A01F46C@supreme-overlord.com> <20000803011806.18934.00000762@ng-cl1.aol.com> Newsgroups: sci.crypt Lines: 23 Grant Anderson <grant_anderson@supreme-overlord.com> wrote: : The key thing for me is finding out if there is a good reason why this : isn't secure? There are proofs for BBS that prove it is as difficult as : factoring whereas almost all other schemes (RSA etc) don't have a prove Being hard to predict is a different thing to being /impossible/ to predict - which is what an ideal OTP ought to be. For example an attacker can guess a BBS seed. If they get it right, reams of plausible plaintext will spew out - while if they don't it is /extremely/ unlikely to. This attack is impossible with a real OTP. If you use PRNG output and call the resulting system an OTP, people will not think you're serious. Also, being "as hard as factoring" may not say very much in security terms. QC advocates seem to think factoring is about to turn out to be "not as hard as had previously been thought". -- __________ Lotus Artificial Life http://alife.co.uk/ tt@cryogen.com |im |yler The Mandala Centre http://mandala.co.uk/ VIPAR GAMMA GUPPY. Subject: Re: OTP using BBS generator? Date: Fri, 04 Aug 2000 09:23:51 +1200 From: Grant Anderson <grant_anderson@supreme-overlord.com> Message-ID: <3989E2E6.79F2BB62@supreme-overlord.com> References: <Fyq8o7.n4F@bath.ac.uk> Newsgroups: sci.crypt Lines: 41 Tim Tyler wrote: > Grant Anderson <grant_anderson@supreme-overlord.com> wrote: > > : The key thing for me is finding out if there is a good reason why this > : isn't secure? There are proofs for BBS that prove it is as difficult as > : factoring whereas almost all other schemes (RSA etc) don't have a prove > > Being hard to predict is a different thing to being /impossible/ > to predict - which is what an ideal OTP ought to be. > > For example an attacker can guess a BBS seed. If they get it right, > reams of plausible plaintext will spew out - while if they don't it is > /extremely/ unlikely to. This attack is impossible with a real OTP. > > If you use PRNG output and call the resulting system an OTP, people will > not think you're serious. > > Also, being "as hard as factoring" may not say very much in security terms. > > QC advocates seem to think factoring is about to turn out to be > "not as hard as had previously been thought". Yeah that was the basis of my question. There are a few good generators which can be shown to exhibit the randomness of purely random sources (or pass all the randomness tests at least). And a OTP needs a non-resuable PAD of random bits. Therefore, a CSPRNG which passes all the random tests and is indistinguishable from a "real" random source should be suitable as long as: 1) You NEVER use the same pad twice 2) You follow the BBS implementation requirements as discussed But many people don't consider a generator to be a random source. This is the bit I don't understand... Cheers, Grant. Subject: Re: OTP using BBS generator? Date: 03 Aug 2000 08:04:17 GMT From: macckone@aol.comnjunk123 (Mack) Message-ID: <20000803040417.24929.00000332@ng-cl1.aol.com> References: <398912AD.1A01F46C@supreme-overlord.com> Newsgroups: sci.crypt Lines: 51 >Yeah I'm aware of that, but there it isn't too slow to be usable on any >Pentium-III or greater system. Usually the other computer is a server. Sure a computer can handle one instance with no problem. But what happens when the same computer is processing 20,000 instances of the same RNG? Even RC4 can bog down under that kind of load. With BBS it is impossible to handle. > >The key thing for me is finding out if there is a good reason why this >isn't secure? There are proofs for BBS that prove it is as difficult as >factoring whereas almost all other schemes (RSA etc) don't have a prove >just a belief... The proofs that show BBS is as secure as factoring make a number of assumptions. In this case it is that the discrete logarithm problem is 'hard'. And that the quadratic residuosity problem is 'hard'. RSA has proofs that follow from similar assumptions. The BBS and RSA are very similar. BBS requires that the primes be of special form. RSA is a bit more liberal although for longest period they should probably be of the same form. BBS is a bit more efficient than the RSA generator (one multiplication). The basic answer to your question is that yes BBS is secure. It isn't generally used because it is slow. The RSA PRNG isn't generally used for the same reason. RC4 may not be absolutely secure but it is fast and of course Alleged RC4 is interoperable. There is also ISSAC which is fast with no Copyright, Trade Mark or Trade Secret problems attached. > >Cheers, >Grant. > >Mack wrote: > >> The basic problem with the BBS >> is that it is very slow. >> >> Mack >> Remove njunk123 from name to reply by e-mail > > Mack Remove njunk123 from name to reply by e-mail Subject: Re: OTP using BBS generator? Date: 3 Aug 2000 13:27:03 GMT From: mdw@nsict.org (Mark Wooding) Message-ID: <slrn8oisp7.26s.mdw@mull.ncipher.com> References: <20000803040417.24929.00000332@ng-cl1.aol.com> Newsgroups: sci.crypt Lines: 45 Mack <macckone@aol.comnjunk123> wrote: > >The key thing for me is finding out if there is a good reason why > >this isn't secure? There are proofs for BBS that prove it is as > >difficult as factoring whereas almost all other schemes (RSA etc) > >don't have a prove just a belief... > > The proofs that show BBS is as secure as factoring make a number of > assumptions. In this case it is that the discrete logarithm problem > is 'hard'. And that the quadratic residuosity problem is 'hard'. RSA > has proofs that follow from similar assumptions. Breaking the BBS is as hard as deciding quadratic residuosity. That's certainly no harder than factoring, because you can use factoring to decide quadratic residuosity, and indeed this is the only way we know for doing this. The quadratic residuosity problem (QRP) is old and well-known; however, we don't know that it's actually as dificult as factoring. By contrast, we know that breaking RSA is as difficult as solving the RSA problem (RSAP). This isn't helpful -- it's just a restatement of the same thing. We've no idea whether RSAP is actually difficult. Again, the only way we know for solving the general RSAP is to factor. On the other hand, RSAP is new. > The BBS and RSA are very similar. BBS requires that the primes > be of special form. RSA is a bit more liberal The form for a Blum modulus isn't very special: the primes p and q must each be congruent to 3 (mod 4); i.e., the bottom two bits of each should be set. The other stuff with (p - 1)/2 being prime and so on isn't particularly important unless you don't understand the security warranty on the BBS generator. > although for longest period they should probably be of the same form. Can you justify this statement? I can't offhand see why an RSA modulus would need to be a Blum integer for this. > BBS is a bit more efficient than the RSA generator (one > multiplication). One squaring, in fact. Squaring is faster than multiplication. -- [mdw] Subject: Re: OTP using BBS generator? Date: Thu, 03 Aug 2000 14:15:13 GMT From: ritter@io.com (Terry Ritter) Message-ID: <39897e04.3117621@news.io.com> References: <slrn8oisp7.26s.mdw@mull.ncipher.com> Newsgroups: sci.crypt Lines: 99 On 3 Aug 2000 13:27:03 GMT, in <slrn8oisp7.26s.mdw@mull.ncipher.com>, in sci.crypt mdw@nsict.org (Mark Wooding) wrote: >Mack <macckone@aol.comnjunk123> wrote: > >> >The key thing for me is finding out if there is a good reason why >> >this isn't secure? There are proofs for BBS that prove it is as >> >difficult as factoring whereas almost all other schemes (RSA etc) >> >don't have a prove just a belief... >> >> The proofs that show BBS is as secure as factoring make a number of >> assumptions. In this case it is that the discrete logarithm problem >> is 'hard'. And that the quadratic residuosity problem is 'hard'. RSA >> has proofs that follow from similar assumptions. > >Breaking the BBS is as hard as deciding quadratic residuosity. That's >certainly no harder than factoring, because you can use factoring to >decide quadratic residuosity, and indeed this is the only way we know >for doing this. The quadratic residuosity problem (QRP) is old and >well-known; however, we don't know that it's actually as dificult as >factoring. But being "no harder than factoring" is meaningless when an approach *allows* factoring. The BB&S structure inherently includes both long and short cycles. If an opponent encounters a short cycle and identifies a repetition, they know the cycle length and can proceed to factor. Thus, use of a short cycle can expose the system to factoring. The BB&S paper shows how to construct a "special primes" system with cycles of a known long length, and then to certify that one has selected such a cycle, thus eliminating use of short cycles. But that takes fairly arduous computation. See, for example: http://www.io.com/~ritter/ARTS/CRNG2ART.HTM#Sect4.4 The alternative is to not use a "special primes" construction, and simply not check for having selected a short cycle. The probability of selecting a short cycle at random is extremely low, but not zero. So where BB&S could argue that their scheme was provably secure, the reduced scheme *might* not be secure, and that is a weakness. 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. Any key-based ciphering whatsoever always has some probability of opponents selecting the correct key at random, and so has inherent weakness. We can't prevent that. But the use of a reduced X^2 mod N structure has *additional* weakness which we *can* prevent. It is a shame to say that is equivalent to the true BB&S design. >By contrast, we know that breaking RSA is as difficult as solving the >RSA problem (RSAP). This isn't helpful -- it's just a restatement of >the same thing. We've no idea whether RSAP is actually difficult. >Again, the only way we know for solving the general RSAP is to factor. >On the other hand, RSAP is new. > >> The BBS and RSA are very similar. BBS requires that the primes >> be of special form. RSA is a bit more liberal > >The form for a Blum modulus isn't very special: the primes p and q must >each be congruent to 3 (mod 4); i.e., the bottom two bits of each should >be set. The other stuff with (p - 1)/2 being prime and so on isn't >particularly important unless you don't understand the security warranty >on the BBS generator. The security warranty from the real Blum, Blum & Shub paper is based upon composites of large primes of a form which they call "special." But now we have people using the part of BB&S they like, and throwing out what they don't like. Do we really think the authors of the paper did not see that possibility and decide against it? Please. >> although for longest period they should probably be of the same form. > >Can you justify this statement? I can't offhand see why an RSA modulus >would need to be a Blum integer for this. I have seen various recommendations that RSA really should be using special primes. Bob Eachus made one, as far as I remember. >> BBS is a bit more efficient than the RSA generator (one >> multiplication). > >One squaring, in fact. Squaring is faster than multiplication. --- Terry Ritter ritter@io.com http://www.io.com/~ritter/ Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM Subject: Re: OTP using BBS generator? Date: 3 Aug 2000 16:19:48 GMT From: mdw@nsict.org (Mark Wooding) Message-ID: <slrn8oj6t3.26s.mdw@mull.ncipher.com> References: <39897e04.3117621@news.io.com> Newsgroups: sci.crypt Lines: 107 [Oh, \deity, not this again.] Terry Ritter <ritter@io.com> wrote: > But being "no harder than factoring" is meaningless when an approach > *allows* factoring. You're cleverer than this. Put your brain in gear. Breaking the system is no harder than factoring. Doing foo lets us factor. Then breaking the system is no harder than doing foo. > The alternative is to not use a "special primes" construction, and > simply not check for having selected a short cycle. The probability > of selecting a short cycle at random is extremely low, but not zero. > So where BB&S could argue that their scheme was provably secure, the > reduced scheme *might* not be secure, and that is a weakness. No! You've failed to understand. The security warranty works regardless, as long as the modulus is a Blum integer. Time to bring out Blum-Goldwasser again. It's a public-key system. Important points: * The private key is a pair of primes p and q, with p = q = 3 (mod 4). * The public key n is the product of p and q. * Encryption is done by someone who knows the public key, but not the private key. He chooses a random seed value and XORs the plaintext with the output of the BBS generator modulo n with the seed he chose. He appends the final state value to the ciphertext. * The sender doesn't know the public key. He can't choose his seed to have order, well, anything in particular. If you can compute the orders of elements mod n, you can factor n. * Blum-Goldwasser is semantically secure. This means that no polynomially-bounded adversary who can't decide quadratic residuosity mod n can compute anything about a plaintext given its ciphertext that couldn't be computed without the ciphertext anyway. The security of Blum-Goldwasser is entirely based on the difficulty of predicting the output of a BBS generator *with a random seed*. Semantic security is an extremely strong property, so this is an extremely important result. > I claim it is deceptive to call the reduced scheme BB&S. I don't see it as deceptive. In fact > It is also deceptive to claim that any system which we can make more > secure by our own action is absolutely secure. Did anyone else hear someone claim that the BBS was absolutely secure? I certainly didn't. > Here we have a case where the security guarantee is factoring, but our > own inaction can lead to allowing exactly that factoring. No. Again, see Blum-Goldwasser. Your own web page explains that that you must choose the seed value carefully in order to find a long cycle. Choosing the primes carefully doesn't guarantee you'll always find long cycles, just that one will exist: you then have to find it. In the Blum-Goldwasser scenario, the modulus is known to the adversary, and if he can, by trying as hard as he can, find a short cycle, then he's broken the system. > Any key-based ciphering whatsoever always has some probability of > opponents selecting the correct key at random, and so has inherent > weakness. We can't prevent that. But the use of a reduced X^2 mod N > structure has *additional* weakness which we *can* prevent. It is a > shame to say that is equivalent to the true BB&S design. But it's *not* additional weakness. It's *exactly the same* weakness, with a different hat on. > The security warranty from the real Blum, Blum & Shub paper is based > upon composites of large primes of a form which they call "special." No. It's based on the difficulty of the quadratic residuosity problem (QRP) modulo a Blum integer. And *nothing else*. > But now we have people using the part of BB&S they like, and throwing > out what they don't like. Do we really think the authors of the paper > did not see that possibility and decide against it? Please. You don't consider that it's possible for mathematicians to prove additional properties of a system they've devised, just through interest? Oh, well. > I have seen various recommendations that RSA really should be using > special primes. Bob Eachus made one, as far as I remember. My software generates strong primes for RSA (and BBS, for that matter), using Gordon's algorithm. I'm not really sure why I bother: I believe the arguments by Bob Silverman and many other experts that it's a waste of effort. (But it doesn't take much longer, it doesn't introduce weaknesses, and the code's there...) But, basically, I accept that it's unnecessary. Note that we can use cycle-finding to factor RSA moduli too: the result that a cycle has a high probability of finding a pair of square roots holds even when the modulus isn't a Blum integer. I see a particular lack of interest in exploiting this as an attack against RSA. -- [mdw] Subject: Re: OTP using BBS generator? Date: Thu, 03 Aug 2000 19:43:50 GMT From: ritter@io.com (Terry Ritter) Message-ID: <3989caf4.6216782@news.io.com> References: <slrn8oj6t3.26s.mdw@mull.ncipher.com> Newsgroups: sci.crypt Lines: 198 On 3 Aug 2000 16:19:48 GMT, in <slrn8oj6t3.26s.mdw@mull.ncipher.com>, in sci.crypt mdw@nsict.org (Mark Wooding) wrote: >[Oh, \deity, not this again.] > >Terry Ritter <ritter@io.com> wrote: > >> But being "no harder than factoring" is meaningless when an approach >> *allows* factoring. > >You're cleverer than this. Put your brain in gear. Frankly, I'm not nearly as clever as I would like to be. But I think this issue is crystal clear. >Breaking the system is no harder than factoring. Doing foo lets us >factor. Then breaking the system is no harder than doing foo. It does seem odd that you are repeating my argument as though it were yours: When factoring is easy, "breaking" BB&S is easy. And factoring *is* easy when someone uses a short cycle. If you are now saying "we should take the effort to not use a short cycle if we want provable strength," you have joined my position. >> The alternative is to not use a "special primes" construction, and >> simply not check for having selected a short cycle. The probability >> of selecting a short cycle at random is extremely low, but not zero. >> So where BB&S could argue that their scheme was provably secure, the >> reduced scheme *might* not be secure, and that is a weakness. > >No! You've failed to understand. The security warranty works >regardless, as long as the modulus is a Blum integer. Sure. The "security warranty" works in the sense that its assumptions have not been met, so the warranty does not apply. The "security warranty" is that BB&S is secure... AS LONG AS FACTORING IS HARD. But factoring is NOT always hard. For example, Factoring is not hard if we give away one of the factors. And that is exactly what we do when we use a short cycle. >Time to bring out Blum-Goldwasser again. It's a public-key system. >Important points: > > * The private key is a pair of primes p and q, with p = q = 3 (mod 4). > > * The public key n is the product of p and q. > > * Encryption is done by someone who knows the public key, but not the > private key. He chooses a random seed value and XORs the plaintext > with the output of the BBS generator modulo n with the seed he > chose. He appends the final state value to the ciphertext. > > * The sender doesn't know the public key. He can't choose his seed to > have order, well, anything in particular. If you can compute the > orders of elements mod n, you can factor n. > > * Blum-Goldwasser is semantically secure. This means that no > polynomially-bounded adversary who can't decide quadratic > residuosity mod n can compute anything about a plaintext given its > ciphertext that couldn't be computed without the ciphertext anyway. > >The security of Blum-Goldwasser is entirely based on the difficulty of >predicting the output of a BBS generator *with a random seed*. Semantic >security is an extremely strong property, so this is an extremely >important result. The probability of using a short cycle is very small. But that possibility is *in* *addition* to the inherent weakness of any cipher to brute-force keysearch. If we use a short cycle, we have provided an *additional* way into the cipher. And if the opponents realize our error, that new way will be rather easy indeed. The possibility of using a short cycle is preventable, if we will just take the effort to do it, and that will not affect at all the probability of choosing the correct key. >> I claim it is deceptive to call the reduced scheme BB&S. > >I don't see it as deceptive. Right. That's the problem. >In fact > >> It is also deceptive to claim that any system which we can make more >> secure by our own action is absolutely secure. > >Did anyone else hear someone claim that the BBS was absolutely secure? >I certainly didn't. Please. >> Here we have a case where the security guarantee is factoring, but our >> own inaction can lead to allowing exactly that factoring. > >No. Again, see Blum-Goldwasser. Your own web page explains that that >you must choose the seed value carefully in order to find a long cycle. So you are now -- finally -- agreeing that it is necessary to choose the seed to be on a long cycle to guarantee strength? Congratulations! What a fine idea! You should tell BB&S, they will be amazed. >Choosing the primes carefully doesn't guarantee you'll always find long >cycles, just that one will exist: you then have to find it. In the >Blum-Goldwasser scenario, the modulus is known to the adversary, and if >he can, by trying as hard as he can, find a short cycle, then he's >broken the system. > >> Any key-based ciphering whatsoever always has some probability of >> opponents selecting the correct key at random, and so has inherent >> weakness. We can't prevent that. But the use of a reduced X^2 mod N >> structure has *additional* weakness which we *can* prevent. It is a >> shame to say that is equivalent to the true BB&S design. > >But it's *not* additional weakness. It's *exactly the same* weakness, >with a different hat on. No, it is an *additional* weakness. An opponent can *also* try any key, *in* *addition* to checking for a short cycle. Conversely, if the system is using a short cycle, we do not have to try any keys, so it is hardly the same weakness, unless you wish to argue that anything which is broken is "the same" in its weakness. >> The security warranty from the real Blum, Blum & Shub paper is based >> upon composites of large primes of a form which they call "special." > >No. It's based on the difficulty of the quadratic residuosity problem >(QRP) modulo a Blum integer. And *nothing else*. Nonsense. It is the special primes construction which provides cycles of known long length, so we can check that we are on a long cycle by stepping around that cycle exponentially. There may be better ways to assure being on a long cycle, but selecting and using a long cycle is clearly needed to guarantee that the system we have will not be weak. >> But now we have people using the part of BB&S they like, and throwing >> out what they don't like. Do we really think the authors of the paper >> did not see that possibility and decide against it? Please. > >You don't consider that it's possible for mathematicians to prove >additional properties of a system they've devised, just through >interest? Oh, well. Possible, yes. Happened in this case, no. >> I have seen various recommendations that RSA really should be using >> special primes. Bob Eachus made one, as far as I remember. > >My software generates strong primes for RSA (and BBS, for that matter), >using Gordon's algorithm. I'm not really sure why I bother: I believe >the arguments by Bob Silverman and many other experts that it's a waste >of effort. (But it doesn't take much longer, it doesn't introduce >weaknesses, and the code's there...) But, basically, I accept that it's >unnecessary. > >Note that we can use cycle-finding to factor RSA moduli too: the result >that a cycle has a high probability of finding a pair of square roots >holds even when the modulus isn't a Blum integer. I see a particular >lack of interest in exploiting this as an attack against RSA. Short cycles are not really an attack: they are a potential weakness. A BB&S system which chooses at random will *ALMOST* never choose a short cycle. But it *might*, and if it *does* choose a short cycle, an unexpected exposure will occur, which opponents may use. As I have said many times, this is not a serious practical risk, but it does point out a fundamental problem in our thinking about cryptographic proof: Here we have a proof, which I assume is correct, and we can *still* get a weak system simply by not meeting the proof assumptions. The assumption that factoring is hard seems obvious, but factoring is *not* always hard: factoring is only hard if we do things right. In particular, factoring is only hard if we do not choose x0 on a short cycle. The ease with which one can accidentally make cryptographic proof not apply should be a revealing insight. --- Terry Ritter ritter@io.com http://www.io.com/~ritter/ Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM Subject: Re: OTP using BBS generator? Date: Thu, 3 Aug 2000 23:18:14 GMT From: Tim Tyler <tt@cryogen.com> Message-ID: <FyqoqE.ALH@bath.ac.uk> References: <39897e04.3117621@news.io.com> Newsgroups: sci.crypt Lines: 20 Terry Ritter <ritter@io.com> wrote: : 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. [...] AFAICS, nobody's claiming this for it in the first place. They're claiming that it's provably as hard as a known math problem. In this instance I believe factoring the modulus is usually a more powerful attack than a brute force search through the possible seeds, (assuming these are of equivalent size). There are other ways to improve the security of this system, besides weeding out short cycles. XOR with another strong PRNG using the same seed is quite likely to work. Then - /even/ if the modulus is factored - the generator may still be able to resist attack. -- __________ Lotus Artificial Life http://alife.co.uk/ tt@cryogen.com |im |yler The Mandala Centre http://mandala.co.uk/ Breast is best. Subject: Re: OTP using BBS generator? Date: Mon, 07 Aug 2000 04:46:06 GMT From: ritter@io.com (Terry Ritter) Message-ID: <398e3f08.1528820@news.io.com> References: <FyqoqE.ALH@bath.ac.uk> Newsgroups: sci.crypt Lines: 120 On Thu, 3 Aug 2000 23:18:14 GMT, in <FyqoqE.ALH@bath.ac.uk>, in sci.crypt Tim Tyler <tt@cryogen.com> wrote: >[...] >In this instance I believe factoring the modulus is usually a more >powerful attack than a brute force search through the possible seeds, >(assuming these are of equivalent size). Are you following along? Is that another issue? It is certainly not the problem I identify: Basically we are talking about the BB&S sequence itself. We assume that the opponents can record values in the BB&S sequence and want to know if those can be used to predict the rest of the sequence. But "prediction" is obvious as soon as the cycle starts to repeat, and then the system is insecure. With "reduced" BB&S, every once in a long while the user's system may select a short cycle. This is the sender, not the opponent; it is a weakness which the sender may or may not expose. When a system with this weakness is used beyond the cycle length, the opponent "only" need find the repetition to break the system. This weakness is entirely due to the mathematical structure of the system; it is not like someone blabbing the secret, which has no math guarantee. Furthermore, this weakness was identified and appropriate measures given in the *original* BB&S article. The weakness can be prevented by assuring that long cycles exist and checking that we are on one. But the "reduced" BB&S system does not check. Using a short cycle is a weakness: When a cycle repeats, the opponent can know the cycle length, which should help to factor N. None of this requires the opponent to do a brute force search through seeds. >Terry Ritter <ritter@io.com> wrote: > >: 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. [...] > >AFAICS, nobody's claiming this for it in the first place. >They're claiming that it's provably as hard as a known math problem. We find "BB&S" on p. 417 of Schneier's Applied Cryptography, 2nd Ed., and there is no mention of "special" primes, or cycle length. We find "BB&S" on p. 186 (section 5.5.2) of the Handbook of Applied Cryptography, essentially as above. Both of these systems instruct that x0 should be chosen relatively prime to N. But that does not guarantee a long cycle. Here on sci.crypt there is still argument that the reduced system is just as strong as -- and so deserves the same name as -- the system described in BB&S. I don't know how that could be more clear. But the reduced system is *not* BB&S, and does not carry the same guarantee. Claiming the reduced system to *be* BB&S when it does not have the BB&S guarantee seems pretty deceptive to me, since the main reason to use BB&S is to get the guarantee. The summary is: * It is INDISPUTABLE that short cycles do exist in BB&S systems. * If the start value x0 is chosen at random, it is INDISPUTABLE that a short cycle might be selected. * It is INDISPUTABLE that any RNG of any sort becomes weak when it traverses *any* full cycle. For, as soon as the sequence starts to repeat, we can predict the future from the known past. This is an inherent limitation to any RNG strength guarantee whatsoever. Normally, the idea that we could traverse an entire BB&S cycle would be ridiculous. That idea is less ridiculous when a short cycle has been selected. How short? BB&S inherently includes "degenerate" or 1-state "cycles" which are "traversed" in one operation. In addition to some "long" cycles, multiple shorter cycles also exist. I am unaware of any lower bound for the length of non-degenerate short cycles. And we don't care if short cycles are "usually" long enough; for a *proof* of strength, we need to guarantee a worst case length for every possible cycle we may select. The theoretical strength guarantees certainly do not prevent us from choosing or using a weak short cycle. At best, they just say that such an event is "unlikely." And they say that whether we have checked for short cycles or not. The theory is thus unresponsive to both the presence of a real risk, and its elimination. That means the theory cannot be relied upon as an indication of security. >There are other ways to improve the security of this system, besides >weeding out short cycles. XOR with another strong PRNG using the same >seed is quite likely to work. Then - /even/ if the modulus is factored >- the generator may still be able to resist attack. Well, there are all kinds of things which can be tacked on. This discussion as basically an extension of "what cryptographic 'proof' really means," which I've been talking about in various ways for years. It is nice to get an example exposed in a way which almost anyone can understand. It is particularly interesting to see a cryptographic proof of strength carry hidden assumptions which prevent even mathematicians -- to say nothing of the rest of us -- from seeing that those assumptions may not be met in a real design. The implications for blind belief in mathematical assurance should be obvious. --- Terry Ritter ritter@io.com http://www.io.com/~ritter/ Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM Subject: Re: OTP using BBS generator? Date: Mon, 07 Aug 2000 11:53:18 +0200 From: Mok-Kong Shen <mok-kong.shen@t-online.de> Message-ID: <398E870E.3CBD69D0@t-online.de> References: <398e3f08.1528820@news.io.com> Newsgroups: sci.crypt Lines: 19 Terry Ritter wrote: > > It is particularly interesting to see a cryptographic proof of > strength carry hidden assumptions which prevent even mathematicians -- > to say nothing of the rest of us -- from seeing that those assumptions > may not be met in a real design. The implications for blind belief in > mathematical assurance should be obvious. Not infrequently proofs are based on yet unproved number theoretical conjectures. These might indeed all be true, see e.g. the example of FLT, which has been proved after a time lag of three centuries. But one should anyway keep in mind of the nature of the foundation on which the proofs are built, if one really wants to rigorously talk about theoretically perfect security (instead of 'practical' security), I believe. M. K. Shen Subject: Re: OTP using BBS generator? Date: Thu, 10 Aug 2000 09:11:59 GMT From: Tim Tyler <tt@cryogen.com> Message-ID: <Fz2K7z.73s@bath.ac.uk> References: <398e3f08.1528820@news.io.com> Newsgroups: sci.crypt Lines: 35 Terry Ritter <ritter@io.com> wrote: : [...] in sci.crypt Tim Tyler <tt@cryogen.com> wrote: :>[...] :>In this instance I believe factoring the modulus is usually a more :>powerful attack than a brute force search through the possible seeds, :>(assuming these are of equivalent size). : Are you following along? Is that another issue? I hope so - and possibly. : It is certainly not the problem I identify: It has nothing to do with short cycles. It *does* however appear to relate to the claim - in the post I was responding to - that: It is also deceptive to claim that any system which we can make more secure by our own action is absolutely secure.'' AFAICS, BBS was never suppsed to be "absolutely secure" in the first place. Saying a problem is as hard as factoring does not provide any sort of "absolute security". Also, I believe factoring the modulus is a faster attack than brute force seed-space search - so BBS /immediately/ fails to be as strong as we would *like* a PRNG to be - namely that the best known attack is brute force. Even /after/ any surgery to remove short cycles, the BBS is never going to become "absolutely secure" - and we will still be able to make it stronger by "our own action". -- __________ Lotus Artificial Life http://alife.co.uk/ tt@cryogen.com |im |yler The Mandala Centre http://mandala.co.uk/ Namaste. Subject: Re: OTP using BBS generator? Date: Thu, 10 Aug 2000 13:20:33 +0200 From: Mok-Kong Shen <mok-kong.shen@t-online.de> Message-ID: <39929001.7D3FFFB7@t-online.de> References: <Fz2K7z.73s@bath.ac.uk> Newsgroups: sci.crypt Lines: 12 Tim Tyler wrote: > > Even /after/ any surgery to remove short cycles, the BBS is never going to > become "absolutely secure" - and we will still be able to make it stronger > by "our own action". See my follow-up, posted 11:05 today, for sources of doubt. M. K. Shen Subject: Re: OTP using BBS generator? Date: Thu, 10 Aug 2000 18:12:16 GMT From: ritter@io.com (Terry Ritter) Message-ID: <3992f041.5322672@news.io.com> References: <Fz2K7z.73s@bath.ac.uk> Newsgroups: sci.crypt Lines: 21 On Thu, 10 Aug 2000 09:11:59 GMT, in <Fz2K7z.73s@bath.ac.uk>, in sci.crypt Tim Tyler <tt@cryogen.com> wrote: >[...] >AFAICS, BBS was never suppsed to be "absolutely secure" in the >first place. Saying a problem is as hard as factoring does not >provide any sort of "absolute security". The assumption is made that factoring is hard, so in that situation, BB&S should be "proven absolutely secure." Yet it is not. That is a contradiction. What we actually have is: "proven almost always secure." It is *not* sufficient that the assumptions be true: Even when the assumptions *are* true, BB&S *still* is weak every now and then. --- Terry Ritter ritter@io.com http://www.io.com/~ritter/ Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM Subject: Re: OTP using BBS generator? Date: Sun, 13 Aug 2000 19:38:34 GMT From: Bryan Olson <bryanolson@my-deja.com> Message-ID: <8n6tfqhoi1@nnrp1.deja.com> References: <3992f041.5322672@news.io.com> Newsgroups: sci.crypt Lines: 32 Terry Ritter wrote: > Tim Tyler wrote: > > >[...] > >AFAICS, BBS was never suppsed to be "absolutely secure" in the > >first place. Saying a problem is as hard as factoring does not > >provide any sort of "absolute security". > > The assumption is made that factoring is hard, so in that situation, > BB&S should be "proven absolutely secure." Yet it is not. That is a > contradiction. What we actually have is: "proven almost always > secure." False. Factoring is easy in some cases, and has some non-zero probability of being efficient in any case. Those are the cases in which BBS may be predictable. > It is *not* sufficient that the assumptions be true: Even when the > assumptions *are* true, BB&S *still* is weak every now and then. Nope. When you allow the defect might appear, you allow that factoring might be easy and have contradicted the premise. --Bryan -- email: bolson at certicom dot com Sent via Deja.com http://www.deja.com/ Before you buy. Subject: Re: OTP using BBS generator? Date: Sun, 13 Aug 2000 21:08:16 GMT From: ritter@io.com (Terry Ritter) Message-ID: <39970da9.12616229@news.io.com> References: <8n6tfqhoi1@nnrp1.deja.com> Newsgroups: sci.crypt Lines: 40 On Sun, 13 Aug 2000 19:38:34 GMT, in <8n6tfqhoi1@nnrp1.deja.com>, in sci.crypt Bryan Olson <bryanolson@my-deja.com> wrote: >Terry Ritter wrote: >[...] >> It is *not* sufficient that the assumptions be true: Even when the >> assumptions *are* true, BB&S *still* is weak every now and then. > >Nope. When you allow the defect might appear, you allow >that factoring might be easy and have contradicted the >premise. And that, of course, is my point precisely, as it has been for some time: Since "pretend" BB&S does *not* check for short cycle operation, it allows the defect to occur. By not checking, it does not help assure that the assumption ("factoring is hard") holds, which means that "pretend" BB&S has the potential weakness of using a short cycle *in* *addition* to any other weaknesses it may have. In contrast, real BB&S *does* check for short cycles, so the defect cannot occur, and the assumption ("factoring is hard") *is* protected (for those cases), so no short cycle weakness can exist. Since I am unaware of any other specific way in which the mathematical structure can expose factoring information, closing that hole would seem to be a desirable goal. The difference, while probably not a significant weakness in practice, is the difference between zero chance and a sweepstakes chance. But the practical distinction is between an absolute guarantee of no short cycle weakness, and the lack of such a guarantee. Not only do I prefer the guarantee, I view the absence as a design defect. Note the correspondence between this view and the reply above. --- Terry Ritter ritter@io.com http://www.io.com/~ritter/ Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM Subject: Re: OTP using BBS generator? Date: Sun, 13 Aug 2000 22:49:35 GMT From: Bryan Olson <bryanolson@my-deja.com> Message-ID: <8n78lup391@nnrp1.deja.com> References: <39970da9.12616229@news.io.com> Newsgroups: sci.crypt Lines: 71 Terry Ritter wrote: > > Bryan Olson wrote: > > >Terry Ritter wrote: > >[...] > >> It is *not* sufficient that the assumptions be true: Even when the > >> assumptions *are* true, BB&S *still* is weak every now and then. > > > >Nope. When you allow the defect might appear, you allow > >that factoring might be easy and have contradicted the > >premise. > > And that, of course, is my point precisely, as it has been for some > time: Then you should not have disagreed with Tim Tyler's point, and what you wrote in the quote above about the assumption not being sufficient is wrong. > Since "pretend" BB&S does *not* check for short cycle operation, it > allows the defect to occur. By not checking, it does not help assure > that the assumption ("factoring is hard") holds That's a theorem works: the conclusion follows from the premises; it doesn't help assure them. 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. The BBS security assumption is that the attacker cannot factor the modulus when given the modulus. (Though in practice we would not give him the modulus.) Giving him generator output, starting from a random point, cannot increase the chance he could violate the assumption, since he can start generators at all the random points he wants. [...] > Since I am > unaware of any other specific way in which the mathematical structure > can expose factoring information, closing that hole would seem to be a > desirable goal. The point of the proof is to close all the holes, not just the one's of which you and I are aware. Does the proof succeed? Well, it does show that all the possible holes are at most as likely as successful factoring. [...] > The difference, while probably not a significant weakness in practice, > is the difference between zero chance and a sweepstakes chance. It's covered by the factoring reduction anyway. More importantly, this is only a zero chance for one particular weakness. The point of the proof is to eliminate all algorithmic methods of prediction, which it does in the sense and cases in which factoring is intractable. --Bryan -- email: bolson at certicom dot com Sent via Deja.com http://www.deja.com/ Before you buy. Subject: Re: OTP using BBS generator? Date: Mon, 14 Aug 2000 03:58:31 GMT From: ritter@io.com (Terry Ritter) Message-ID: <39976e64.3673765@news.io.com> References: <8n78lup391@nnrp1.deja.com> Newsgroups: sci.crypt Lines: 125 On Sun, 13 Aug 2000 22:49:35 GMT, in <8n78lup391@nnrp1.deja.com>, in sci.crypt Bryan Olson <bryanolson@my-deja.com> wrote: >Terry Ritter wrote: >> >> Bryan Olson wrote: >> >> >Terry Ritter wrote: >> >[...] >> >> It is *not* sufficient that the assumptions be true: Even when the >> >> assumptions *are* true, BB&S *still* is weak every now and then. >> > >> >Nope. When you allow the defect might appear, you allow >> >that factoring might be easy and have contradicted the >> >premise. >> >> And that, of course, is my point precisely, as it has been for some >> time: > >Then you should not have disagreed with Tim Tyler's point, >and what you wrote in the quote above about the assumption >not being sufficient is wrong. First, I have no idea what "Tim Tyler's point" (if he even had just one point) was. 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. But whether factoring is hard or not, short cycles do exist anyway. 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. 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. 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. >> Since "pretend" BB&S does *not* check for short cycle operation, it >> allows the defect to occur. By not checking, it does not help assure >> that the assumption ("factoring is hard") holds > >That's a theorem works: 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. Of course the system would be insecure, which is what we hoped to avoid by our proofs and assumptions. 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. >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 BBS security assumption is that the attacker cannot >factor the modulus when given the modulus. (Though in >practice we would not give him the modulus.) Giving him >generator output, starting from a random point, cannot >increase the chance he could violate the assumption, since >he can start generators at all the random points he wants. The attacker can detect a cycle traversal when that occurs. Given that, he can factor. >[...] >> Since I am >> unaware of any other specific way in which the mathematical structure >> can expose factoring information, closing that hole would seem to be a >> desirable goal. > >The point of the proof is to close all the holes, not just >the one's of which you and I are aware. Does the proof >succeed? Well, it does show that all the possible holes are >at most as likely as successful factoring. But factoring is *not* hard if the mathematical structure of the system itself exposes factors. And that is why one might wish to avoid using short cycles. >[...] >> The difference, while probably not a significant weakness in practice, >> is the difference between zero chance and a sweepstakes chance. > >It's covered by the factoring reduction anyway. More >importantly, this is only a zero chance for one particular >weakness. The point of the proof is to eliminate all >algorithmic methods of prediction, which it does in the >sense and cases in which factoring is intractable. But factoring is *not* intractable when the mathematical structure of the system itself exposes factors. --- Terry Ritter ritter@io.com http://www.io.com/~ritter/ Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM Subject: Re: OTP using BBS generator? Date: Tue, 15 Aug 2000 04:38:08 GMT From: Bryan Olson <bryanolson@my-deja.com> Message-ID: <8nahfh5hv1@nnrp1.deja.com> References: <39976e64.3673765@news.io.com> Newsgroups: sci.crypt Lines: 117 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. Subject: Re: OTP using BBS generator? Date: Sat, 19 Aug 2000 01:40:26 GMT From: Tim Tyler <tt@cryogen.com> Message-ID: <FzInBE.IAv@bath.ac.uk> References: <8n78lup391@nnrp1.deja.com> Newsgroups: sci.crypt Lines: 33 Bryan Olson <bryanolson@my-deja.com> wrote: : Terry Ritter wrote: :> Bryan Olson wrote: :>Then you should not have disagreed with Tim Tyler's point [...] : First, I have no idea what "Tim Tyler's point" [...] was. Backtracking, Bryan almost certainly refers to: TT> AFAICS, BBS was never suppsed to be "absolutely secure" in the TT> first place. Saying a problem is as hard as factoring does not TT> provide any sort of "absolute security". TR> The assumption is made that factoring is hard, so in that situation, TR> BB&S should be "proven absolutely secure." [...] If "proven absolutely secure" has any meaning at all for a pseudo random number generator, I would hope that it means that no algorithm works better than a brute force key search through all possible seeds. As I understand it, we know that attempts to factor the modulus are a better attack on BBS than brute force seed search - so the system already falls short of what is possible in terms of security. Besides, you can hardly rest an "absolute" proof on something unproven, such as the difficulty of factoring. Factoring is /believed/ to be hard - but there's no absolute proof. Indeed, the quantum computation cheerleaders would have us believe that factoring may soon prove to be much, much easier than people had previously thought. -- __________ http://alife.co.uk/ http://mandala.co.uk/ |im |yler tt@cryogen.com http://hex.org.uk/ http://atoms.org.uk/ Subject: Re: OTP using BBS generator? Date: Sat, 19 Aug 2000 09:01:00 +0200 From: Mok-Kong Shen <mok-kong.shen@t-online.de> Message-ID: <399E30AC.6131996A@t-online.de> References: <FzInBE.IAv@bath.ac.uk> Newsgroups: sci.crypt Lines: 17 Tim Tyler wrote: > > Besides, you can hardly rest an "absolute" proof on something unproven, > such as the difficulty of factoring. Factoring is /believed/ to be hard - > but there's no absolute proof. Indeed, the quantum computation > cheerleaders would have us believe that factoring may soon prove to be > much, much easier than people had previously thought. Most instances of the so-called 'provable security' involve assumptions. Hence the term could under circumstances be misleading. That's why I suggested in another follow-up to replace it with a (unfortunately long-winded) phrase. M. K. Shen Subject: Re: OTP using BBS generator? Date: Mon, 14 Aug 2000 10:39:58 +0200 From: Mok-Kong Shen <mok-kong.shen@t-online.de> Message-ID: <3997B05E.2F27A247@t-online.de> References: <8n6tfqhoi1@nnrp1.deja.com> Newsgroups: sci.crypt Lines: 24 Bryan Olson wrote: > > Terry Ritter wrote: [snip] > Nope. When you allow the defect might appear, you allow > that factoring might be easy and have contradicted the > premise. Two dumb questions: (1) Isn't it that in employing a product of two large primes for PK one has to check that there are certain properties other than size that are to be fulfilled? (2) Since some large numbers are evidently easy to factor, what does an assumption of hardness of factoring (without further qualifications) imply? I mean one probably has to characterize theryby the type of numbers being considered (namely those that are hard to factor according to some definite quantifiable measure) that one assumes to be dealing with for the presentation containing that assumption. M. K. Shen Subject: Re: OTP using BBS generator? Date: 14 Aug 2000 13:44:16 GMT From: mdw@nsict.org (Mark Wooding) Message-ID: <slrn8pftte.glm.mdw@mull.ncipher.com> References: <3997B05E.2F27A247@t-online.de> Newsgroups: sci.crypt Lines: 43 Mok-Kong Shen <mok-kong.shen@t-online.de> wrote: > Two dumb questions: (1) Isn't it that in employing a product of two > large primes for PK one has to check that there are certain properties > other than size that are to be fulfilled? Depends who you talk to. Some will waffle on about strong primes' and suchlike; others will tell you just to generate random primes. I think that the random primes people are right. The purpose of strong primes' is to protect against a (known) few special-purpose factoring algorithms which work well when the factors have certain special (but actually rather rare) forms. There's not a lot of point in doing this sort of protection, because the general number field sieve, which has been our best factoring algorithm for quite a while now, doesn't care about the forms of the factors, just how large the product you're trying to factor actually is. It may be the case that we find new useful special-purpose factoring algorithms which attack factors of particular (but nonetheless relatively common) forms. In this case, we might want to use strong' primes, but the strength properties we'll want probably won't be the ones we ensured in our old strong' primes. > (2) Since some large numbers are evidently easy to factor, what does > an assumption of hardness of factoring (without further > qualifications) imply? I mean one probably has to characterize theryby > the type of numbers being considered (namely those that are hard to > factor according to some definite quantifiable measure) that one > assumes to be dealing with for the presentation containing that > assumption. In the current environment, random primes are no worse than any others of the same size, so we really do just think about the size of the factors. In general, though, I suppose we should consider the strength of cryptosystems based on the integer factorization problem by the difficulty of factoring the most difficult sorts of composite numbers available, and then try to choose those sorts of composites. Currently, those really are just the products of pairs of random primes. -- [mdw] Subject: Re: OTP using BBS generator? Date: Mon, 14 Aug 2000 21:40:52 +0200 From: Mok-Kong Shen <mok-kong.shen@t-online.de> Message-ID: <39984B44.1C4EE5BA@t-online.de> References: <slrn8pftte.glm.mdw@mull.ncipher.com> Newsgroups: sci.crypt Lines: 15 Mark Wooding wrote: > > In general, though, I suppose we should consider the strength of > cryptosystems based on the integer factorization problem by the > difficulty of factoring the most difficult sorts of composite numbers > available, and then try to choose those sorts of composites. Currently, > those really are just the products of pairs of random primes. Could you conceive of any possibility of ever formally characterizing the 'most difficult sort of composite numbers'? Intuitively, I rather doubt that that could be done. Thanks. M. K. Shen Bytes: 889 Subject: Re: OTP using BBS generator? Date: Mon, 14 Aug 2000 14:46:48 -0700 From: lordcow77 <london222NOloSPAM@netzero.com.invalid> Message-ID: <00ab31c8.5ca314db@usw-ex0102-014.remarq.com> References: <39984B44.1C4EE5BA@t-online.de> Newsgroups: sci.crypt Lines: 29 Mok-Kong Shen <mok-kong.shen@t-online.de> wrote: > > >Mark Wooding wrote: >> >> In general, though, I suppose we should consider the strength of >> cryptosystems based on the integer factorization problem by the >> difficulty of factoring the most difficult sorts of composite numbers >> available, and then try to choose those sorts of composites. Currently, >> those really are just the products of pairs of random primes. > >Could you conceive of any possibility of ever formally >characterizing the 'most difficult sort of composite numbers'? >Intuitively, I rather doubt that that could be done. Thanks. > Just what Mark Wooding stated; the products of two random primes of the same length. ----------------------------------------------------------- Got questions? Get answers over the phone at Keen.com. Up to 100 minutes free! http://www.keen.com Subject: Re: OTP using BBS generator? Date: 15 Aug 2000 11:13:08 GMT From: mdw@nsict.org (Mark Wooding) Message-ID: <slrn8pi9e3.glm.mdw@mull.ncipher.com> References: <39992117.73615E6D@t-online.de> <00ab31c8.5ca314db@usw-ex0102-014.remarq.com> Newsgroups: sci.crypt Lines: 18 Mok-Kong Shen <mok-kong.shen@t-online.de> wrote: > So we know the size of these. But what useful implications do they > have in this context (i.e. concerning 'difficulty'), if these are not > otherwise made definite/clear? BTW, do we have sort of 'meter' for > rigorously quantifying that 'difficulty'? Thanks. No. I left my description deliberately vague. Our understanding of what numbers are particularly hard to factor will change as we get better at factoring, and it will change in an unpredictable way. Currently, our best general-ish factoring method takes time related only to the size of the number being factored. So we just choose big' numbers. This might change. It might not. -- [mdw] Subject: Re: OTP using BBS generator? Date: Fri, 04 Aug 2000 05:14:50 GMT From: Bryan Olson <bryanolson@my-deja.com> Message-ID: <8mdjg927c1@nnrp1.deja.com> References: <39897e04.3117621@news.io.com> Newsgroups: sci.crypt Lines: 52 Terry Ritter wrote: [...] > The alternative is to not use a "special primes" construction, and > simply not check for having selected a short cycle. And one gets a system that is secure in the same sense as the original BB&S scheme. > The probability > of selecting a short cycle at random is extremely low, but not zero. > So where BB&S could argue that their scheme was provably secure, the > reduced scheme *might* not be secure, and that is a weakness. 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. The scheme without the long cycle test is secure in the same sense as the scheme with the test. > 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. [...] > The security warranty from the real Blum, Blum & Shub paper is based > upon composites of large primes of a form which they call "special." > > But now we have people using the part of BB&S they like, and throwing > out what they don't like. Do we really think the authors of the paper > did not see that possibility and decide against it? Please. 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. --Bryan -- email: bolson at certicom dot com Sent via Deja.com http://www.deja.com/ Before you buy. Subject: Re: OTP using BBS generator? Date: Mon, 07 Aug 2000 04:48:28 GMT From: ritter@io.com (Terry Ritter) Message-ID: <398e3f87.1656232@news.io.com> References: <8mdjg927c1@nnrp1.deja.com> Newsgroups: sci.crypt Lines: 110 On Fri, 04 Aug 2000 05:14:50 GMT, in <8mdjg927c1@nnrp1.deja.com>, in sci.crypt Bryan Olson <bryanolson@my-deja.com> wrote: >Terry Ritter wrote: >[...] >> The alternative is to not use a "special primes" construction, and >> simply not check for having selected a short cycle. > >And one gets a system that is secure in the same sense as >the original BB&S scheme. > >> The probability >> of selecting a short cycle at random is extremely low, but not zero. >> So where BB&S could argue that their scheme was provably secure, the >> reduced scheme *might* not be secure, and that is a weakness. > >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. Clearly, N -- presumably part of "the key" -- is the composite product of two large primes. BB&S would have us use "special" primes; is not doing that what you mean by a "predictable key"? Then, x0 -- also arguably part of "the key" -- selects some cycle. BB&S would have us test that to guarantee that it is a long cycle; there may be easier ways to do that. Is the use of a short cycle what you mean by using a "predictable key"? It certainly is predictable after we go around once! 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? >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 selecting an x0, the starting value. x0 always selects a cycle of some length, and usually selects a cycle of long length. But -- unless prevented -- x0 *may* select a short cycle, and when that cycle has been traversed it is no longer secure. 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? This is not something "outside" the system; it is inherent in the mathematical structure itself. 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. 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." >> 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. My issue is that the original BB&S article showed how to do all this right, or at least it gave one way. Anyone who actually read and understood that article should know about the problem and the BB&S solution. The subsequent reduction of their prescription to not check for cycle length is repeated throughout cryptography. One can avoid the weakness "simply" by arranging to use a long cycle which that system will not traverse. Yet the math apparently does not distinguish the two cases. >[...] >> The security warranty from the real Blum, Blum & Shub paper is based >> upon composites of large primes of a form which they call "special." >> >> But now we have people using the part of BB&S they like, and throwing >> out what they don't like. Do we really think the authors of the paper >> did not see that possibility and decide against it? Please. > >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. If we give away a factor, a strength guarantee based on inability to factor obviously does not apply. If we use any RNG past its cyclic length, no strength guarantee can apply. --- Terry Ritter ritter@io.com http://www.io.com/~ritter/ Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM Subject: Re: OTP using BBS generator? Date: Mon, 07 Aug 2000 11:53:33 +0200 From: Mok-Kong Shen <mok-kong.shen@t-online.de> Message-ID: <398E871D.E67A5BAA@t-online.de> References: <398e3f87.1656232@news.io.com> Newsgroups: sci.crypt Lines: 17 Terry Ritter wrote: > > 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. 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." Maybe I am entirely misled by my poor knowledge and low IQ. But I have the impression that, excepting OTP, most cases of 'proven strength' seem to be just that. M. K. Shen Subject: Re: OTP using BBS generator? Date: Mon, 7 Aug 2000 12:34:00 -0500 From: "Joseph Ashwood" <ashwood@msn.com> Message-ID: <eHSdaKAAHA.138@cpmsnbbsa08> References: <398E871D.E67A5BAA@t-online.de> Newsgroups: sci.crypt Lines: 26 > 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 Subject: Re: OTP using BBS generator? Date: Mon, 07 Aug 2000 23:16:36 GMT From: Bryan Olson <bryanolson@my-deja.com> Message-ID: <8mng0irpc1@nnrp1.deja.com> References: <398E871D.E67A5BAA@t-online.de> Newsgroups: sci.crypt Lines: 40 Mok-Kong Shen wrote: > > Terry Ritter wrote: > > > > 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. 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." > > Maybe I am entirely misled by my poor knowledge and low IQ. But > I have the impression that, excepting OTP, most cases of 'proven > strength' seem to be just that. In the sense that it's true, it even applies to the OTP. 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. --Bryan -- email: bolson at certicom dot com Sent via Deja.com http://www.deja.com/ Before you buy. Subject: Re: OTP using BBS generator? Date: Tue, 08 Aug 2000 08:25:50 +0200 From: Mok-Kong Shen <mok-kong.shen@t-online.de> Message-ID: <398FA7EE.89D30F5A@t-online.de> References: <8mng0irpc1@nnrp1.deja.com> Newsgroups: sci.crypt Lines: 38 Bryan Olson wrote: > > Mok-Kong Shen wrote: > > > > Terry Ritter wrote: > > > > > > 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. 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." > > > > Maybe I am entirely misled by my poor knowledge and low IQ. But > > I have the impression that, excepting OTP, most cases of 'proven > > strength' seem to be just that. > > In the sense that it's true, it even applies to the OTP. > 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. You can point out the false logic here. But in case a mathematicalproof assumes explicitly/implicitly (directly/ indirctly), say, the extended Riemann hypothesis and is logically perfect, you have nothing to point out excepting that there is an unproved assumption the truth value of which nobody yet knows, don't you? M. K. Shen Subject: Re: OTP using BBS generator? Date: Tue, 08 Aug 2000 22:40:00 GMT From: Bryan Olson <bryanolson@my-deja.com> Message-ID: <8mq27vkdr1@nnrp1.deja.com> References: <398FA7EE.89D30F5A@t-online.de> Newsgroups: sci.crypt Lines: 37 Mok-Kong Shen wrote: > Bryan Olson wrote: > > In the sense that it's true, it even applies to the OTP. > > 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. > > You can point out the false logic here. But in case a > mathematicalproof assumes explicitly/implicitly (directly/ > indirctly), say, the extended Riemann hypothesis and is > logically perfect, you have nothing to point out excepting > that there is an unproved assumption the truth value of which > nobody yet knows, don't you? I think we're talking about different issues. Certainly a proof which rests on an open conjecture is a slippery sort of theorem. But the issue I understand here is different: cryptographic security properties apply to the system with its key space, not to particular choices of key. Even if we obtain proof of the conjectures, that factoring is hard in general would not imply that every large number will be unfactorable. --Bryan -- email: bolson at certicom dot com Sent via Deja.com http://www.deja.com/ Before you buy. Subject: Re: OTP using BBS generator? Date: Mon, 14 Aug 2000 11:00:47 GMT From: Tim Tyler <tt@cryogen.com> Message-ID: <FzA3xB.I2p@bath.ac.uk> References: <8mng0irpc1@nnrp1.deja.com> Newsgroups: sci.crypt Lines: 38 Bryan Olson <bryanolson@my-deja.com> 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. Using a short cycle in a BBS generator, by contrast provides the attacker with information about the message he did not previously posess. One problem appears to be whether an attacker can identify a short cycle. If he sees "123412341234..." in the low bits is he safe to assume the generator is in a cycle? It seems unlikely - since the next digits /might/ be 8, 5, 9 and 4. It appears that if the observed pattern is longer than the langth of the key, the possibility of mis-identifying a cycle diminishes rapidly. If Terry Ritter is correct - and detecting short cycles is possible - it appears that any analogy between "weak keys" in an OTP and "weak seeds" in a BBS generator absolutely breaks down. -- __________ Lotus Artificial Life http://alife.co.uk/ tt@cryogen.com |im |yler The Mandala Centre http://mandala.co.uk/ Namaste. Subject: Re: OTP using BBS generator? Date: Mon, 14 Aug 2000 23:07:53 GMT From: ritter@io.com (Terry Ritter) Message-ID: <39987bc5.7555304@news.io.com> References: <FzA3xB.I2p@bath.ac.uk> Newsgroups: sci.crypt Lines: 40 On Mon, 14 Aug 2000 11:00:47 GMT, in <FzA3xB.I2p@bath.ac.uk>, in sci.crypt Tim Tyler <tt@cryogen.com> wrote: >[...] >One problem appears to be whether an attacker can identify a short cycle. >If he sees "123412341234..." in the low bits is he safe to assume the >generator is in a cycle? It seems unlikely - since the next digits >/might/ be 8, 5, 9 and 4. It appears that if the observed pattern is >longer than the langth of the key, the possibility of mis-identifying >a cycle diminishes rapidly. > >If Terry Ritter is correct - and detecting short cycles is possible - it >appears that any analogy between "weak keys" in an OTP and "weak seeds" >in a BBS generator absolutely breaks down. As usual, our large conversation has included many different assumptions and arguments. Normally, if we are talking about "weakness" in a generator, I think the opponents have access to the output of the generator. That can be reasonable, because many such generators are used in additive stream ciphers, so with a known-plaintext attack the generator output is exposed. In BB&S we don't get the full state output, but we do get a bit of it, and if we record that sequence and compare it to the incoming data, presumably we can find a match. (There is a potential lead-in prior to getting on a cycle, but I think that is limited to a single step.) Presumably, after we get a few hundred successive bit matches, we can reasonably believe we have found a cycle. Then, with just a little more data, we can probably narrow down the cycle length to within a few bits, which should be more than good enough to try them all. This whole discussion is theoretical, generally addressing the meaning of cryptographic proof. I'm unaware of any controversy about the idea that cycles theoretically could be detected easily. --- Terry Ritter ritter@io.com http://www.io.com/~ritter/ Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM Subject: Re: OTP using BBS generator? Date: Tue, 15 Aug 2000 12:22:16 GMT From: jsavard@fNrOeSePnAeMt.edmonton.ab.ca (John Savard) Message-ID: <399934cb.581533@news.ecn.ab.ca> References: <39987bc5.7555304@news.io.com> Newsgroups: sci.crypt Lines: 27 On Mon, 14 Aug 2000 23:07:53 GMT, ritter@io.com (Terry Ritter) wrote, in part: >This whole discussion is theoretical, generally addressing the meaning >of cryptographic proof. I'm unaware of any controversy about the idea >that cycles theoretically could be detected easily. No, and neither is it controversial that a PRNG that produces a short cycle is insecure cryptographically, at least if the cycle is sufficiently short (I'm assuming something you've said in a post elsewhere in this thread refers to "short" in another sense - short compared with the maximum possible output, but not short compared to the length of messages). Since there is a 'mathematical proof' that the output of a BBS generator is "hard" to predict, in the same sense that breaking some public-key ciphers is known to be "hard" (it could be easy, but only if a better method of factoring is discovered than any we now know of), I would, however, have to conclude that it is also a proof that a BBS generator cannot produce only a short cycle (when used in the manner the proof refers to: i.e., its output is not hard to predict if the seed is zero). Otherwise, the proof would have to be flawed, I would think. John Savard http://home.ecn.ab.ca/~jsavard/crypto.htm Subject: Re: OTP using BBS generator? Date: Wed, 16 Aug 2000 06:57:40 +0100 From: David Hopwood <hopwood@zetnet.co.uk> Message-ID: <399A2D54.6355858@zetnet.co.uk> References: <39987bc5.7555304@news.io.com> Newsgroups: sci.crypt Lines: 34 -----BEGIN PGP SIGNED MESSAGE----- Terry Ritter wrote: > In BB&S we don't get the full state output, but we do get a bit of it, > and if we record that sequence and compare it to the incoming data, > presumably we can find a match. (There is a potential lead-in prior > to getting on a cycle, but I think that is limited to a single step.) There is no potential lead in. If x is the seed then the first bit output is the LSB of x^2 mod N, not the LSB of x. Since x^2 is a quadratic residue, it falls on a cycle. - -- David Hopwood <hopwood@zetnet.co.uk> Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/ RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01 Nothing in this message is intended to be legally binding. If I revoke a public key but refuse to specify why, it is because the private key has been seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv iQEVAwUBOZllKDkCAxeYt5gVAQHW0QgAnIPrQA0pudhmiGrtRseBYRusP1cEVgQ5 PCNtgUt29NWM0cI8I/ywIFSG3yBrb8hG6QZA5NtjchjSPy3eEOnc2oPWVt8TenI7 SmQCVwEzCX7rXbEZVf/S5Vh26PPZFH9++2lGmTDua30pdJYQP7UhBpZk3H2D/4H5 qFCOJB4KUCoeiZ7fRHX75pcsVoNvpymFo3CHRxPbjt+ArVDjnqqK94FlKfD+6Ddo 4D2t0TiCTNwmTnOz9sTkQYhhdqfT34HEN9z19FzxuAzcNh5k4rhlvGDb5gbR3OoR Jt2JZxo1ocauy12w+zeyYbRXIy7XOPNlFySYfRiyzZqtbBet4unNeg== =owO+ -----END PGP SIGNATURE----- Subject: Re: OTP using BBS generator? Date: Wed, 16 Aug 2000 03:44:02 GMT From: ritter@io.com (Terry Ritter) Message-ID: <399a0dea.1981488@news.io.com> References: <399A2D54.6355858@zetnet.co.uk> Newsgroups: sci.crypt Lines: 23 On Wed, 16 Aug 2000 06:57:40 +0100, in <399A2D54.6355858@zetnet.co.uk>, in sci.crypt David Hopwood <hopwood@zetnet.co.uk> wrote: >-----BEGIN PGP SIGNED MESSAGE----- > >Terry Ritter wrote: >> In BB&S we don't get the full state output, but we do get a bit of it, >> and if we record that sequence and compare it to the incoming data, >> presumably we can find a match. (There is a potential lead-in prior >> to getting on a cycle, but I think that is limited to a single step.) > >There is no potential lead in. If x is the seed then the first bit output >is the LSB of x^2 mod N, not the LSB of x. Since x^2 is a quadratic >residue, it falls on a cycle. Right. --- Terry Ritter ritter@io.com http://www.io.com/~ritter/ Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM Subject: Re: OTP using BBS generator? Date: Tue, 15 Aug 2000 05:04:51 GMT From: Bryan Olson <bryanolson@my-deja.com> Message-ID: <8naj1i6ek1@nnrp1.deja.com> References: <FzA3xB.I2p@bath.ac.uk> Newsgroups: sci.crypt Lines: 55 > 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. Subject: Re: OTP using BBS generator? Date: Tue, 15 Aug 2000 12:43:33 GMT From: jsavard@fNrOeSePnAeMt.edmonton.ab.ca (John Savard) Message-ID: <3999365a.980293@news.ecn.ab.ca> References: <8naj1i6ek1@nnrp1.deja.com> Newsgroups: sci.crypt Lines: 119 On Tue, 15 Aug 2000 05:04:51 GMT, Bryan Olson <bryanolson@my-deja.com> wrote, in part: >> 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. Well, I haven't "objected to the proof of perfect secrecy for the OTP", but I have noted that people might be tempted to reject the all-zero key, despite the fact that this, from a theoretical point of view, is wrong. I even went as far as to defend this practice as being not all that bad. Perhaps this makes me a heretic, but I don't think it goes against truth in the practical sense. >> : 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. quoting somebody else: >> 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. This is true in a theoretical sense. >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. I agree with that. So how do we *reconcile* these two points of view? How can we take the undeniable truths of mathematics, and the practical facts of common-sense, and show that they don't really contradict each other? Hint 1: Let's say someone went further, and decided to apply a binary OTP to a message in 8-bit ASCII characters. However, to make it simple to avoid an all-zero pad, the OTP was modified so that *no byte in the pad was ever 00000000*. Clearly, this _would_ compromise security. >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. Now, this doesn't seem to say more than that even the OTP is not secure if the attacker _knows_ the key, so that doesn't seem to be germane. Whatever the problem is, it isn't that the attacker *knew* you were going to use an OTP with 000...000 on it. >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. But that is what the *other* poster said, in effect. The fact that the OTP value didn't *have* to be zero is claimed to give secrecy - even in the case where the key happened to be zero. As you note, though, the real problem is that the attacker will see the message, and assume that it was sent in the clear because it looks like plaintext. Besides rejecting the all-zero pad, how far should one go, though? Presumably, on the basis that the attacker does not know that an OTP is being used, but will consider other, lesser, systems, one should (!) reject all pads that correspond to any XOR stream cipher that could be solved on the basis of a single message of the same size as the pad. (!) Thus, for example, a pad consisting entirely of a short, repeated, sequence of bytes should also be rejected. But if we keep going on like this, we have made the keyspace smaller than the message. So if the attacker knows what we're doing, he clearly can derive *some* information about the message. Of course, we will, even in a fairly extreme case, reject _less than half_ of the possible keypads, and so the information about the message will amount to no more than *a single bit*. So, if anyone is nervous about spoiling the theoretical security of the OTP based on rejecting patterned keypads, there is an easy cure. Add 56 random bits to the start of the message - and encipher the rest of it in DES with that key. Now, since there are 2^56 possible inputs to the OTP process that contain the same message, knowing one bit of the input to the OTP process won't help you - you have to know the equivalent of 56 bits before you can even start learning anything about the real plaintext. (And, of course, you would have to know 56 + 64 bits before doing so became "easy", or rather trivial, but knowing fewer bits than that will, at least if they're in the right places, allow some cryptanalysis.) John Savard http://home.ecn.ab.ca/~jsavard/crypto.htm Subject: Re: OTP using BBS generator? Date: Tue, 15 Aug 2000 16:48:13 +0200 From: Mok-Kong Shen <mok-kong.shen@t-online.de> Message-ID: <3999582D.88A876B6@t-online.de> References: <3999365a.980293@news.ecn.ab.ca> Newsgroups: sci.crypt Lines: 39 John Savard wrote: > > Besides rejecting the all-zero pad, how far should one go, though? > > Presumably, on the basis that the attacker does not know that an OTP > is being used, but will consider other, lesser, systems, one should > > (!) > reject all pads that correspond to any XOR stream cipher that could be > solved on the basis of a single message of the same size as the pad. > (!) > > Thus, for example, a pad consisting entirely of a short, repeated, > sequence of bytes should also be rejected. > > But if we keep going on like this, we have made the keyspace smaller > than the message. So if the attacker knows what we're doing, he > clearly can derive *some* information about the message. Of course, we > will, even in a fairly extreme case, reject _less than half_ of the > possible keypads, and so the information about the message will amount > to no more than *a single bit*. I think that one has at this point remember that (an ideal) OTP is only a theoretical model and that in practice we adopt practical means that we (with more or less subjectivity) consider to be appropriate. One way of filtering candidate bit sequences could be this, I suppose: Apply all statistical tests that are available to us. If a sequence passes them all, then use it. On the assumption that the opponent doesn't have better and more statistical tests to discern the non-randomness (that we are unable to discern) and hence is not able to exploit that, we are safe, aren't we? M. K. Shen ----------------------------- http://home.t-online.de/home/mok-kong.shen Subject: Re: OTP using BBS generator? Date: Thu, 17 Aug 2000 00:56:09 GMT From: Tim Tyler <tt@cryogen.com> Message-ID: <FzEvxL.87H@bath.ac.uk> References: <3999365a.980293@news.ecn.ab.ca> Newsgroups: sci.crypt Lines: 18 John Savard <jsavard@fnroesepnaemt.edmonton.ab.ca> wrote: : Well, I haven't "objected to the proof of perfect secrecy for the : OTP", but I have noted that people might be tempted to reject the : all-zero key, despite the fact that this, from a theoretical point of : view, is wrong. : I even went as far as to defend this practice as being not all that : bad. Perhaps this makes me a heretic, but I don't think it goes : against truth in the practical sense. Imagine a rare spy, who - after landing in enemy territory - opens up his OTP and prepares to report that his espionage mission began successfully. Scanning the pages, he finds all the symbols are zeros. Imagine his dismay ;-) -- __________ Lotus Artificial Life http://alife.co.uk/ tt@cryogen.com |im |yler The Mandala Centre http://mandala.co.uk/ Namaste. Subject: Re: OTP using BBS generator? Date: Thu, 17 Aug 2000 15:39:55 +0200 From: Mok-Kong Shen <mok-kong.shen@t-online.de> Message-ID: <399BEB2B.2ED66E31@t-online.de> References: <FzEvxL.87H@bath.ac.uk> Newsgroups: sci.crypt Lines: 61 Tim Tyler wrote: > > Imagine a rare spy, who - after landing in enemy territory - opens up > his OTP and prepares to report that his espionage mission began > successfully. Scanning the pages, he finds all the symbols are zeros. > Imagine his dismay ;-) Why? If the spy knows that his agency has given him a true OTP and he also happens to be a crypto theoretician, he will not hesitate a micro-second before applying the pad! BTW, if the process is automatic, he (and his colleagues who oversee the OTP generation at the agency) shouldn't have visual contact with the pad at all. In a follow-up (responding to John Savard) I said that one should take a practical standpoint and apply ALL available (as far as resources permit) statistical tests to filter any bit sequences generated for use. For, on the assumption that the opponent doesn't have better means than us, we are safe. (If the opponent is omnipotent, then we lose anyway.) The conceptual difficulty involved in the present issue is in my opinion attributable to the fact that theory is only a model of the reality and hence uses assumptions that are idealized forms of reality. Since these idealized things never actually occur in practice, the existece of paradoxes don't mean that the theory is any wrong, only that we should be constantly aware of the underlying assumptions when applying it. To support this view, I like to provide the anecdote (a true history that I personally experienced!) attached below. M. K. Shen ----------------------------------- In the theory of elasticity there is a rather simple problem concerning a thin (two-dimentional) wedge that extends to infinity. If a certain type of load is applied on the wedge, then the stress and strain in the wedge can be obtained via solution of a partial differential equation. This solution becomes however singular for a particular value of the angle of the wedge, so that in that case infinitely large stress is the result. In a laboratory an assistant was doing an experiment trying to see how the general solution obtained in theory agrees with the practice for different values of the wedge angle. His professor cautioned him, saying 'Be very careful when you approach the critical value of the angle, for the wedge could explode!' Of course, the wedge didn't explode. This is because the theory assumes the Hooke's law, which is a linear relationship between stress and strain, an idealization that never actually exactly obtains in reality. (Further, there is never a two dimentional, only a three dimentional wedge and there is no wedge that extends to infinity.) So paradoxes can happen when theory makes idealized assumptions. Subject: Re: OTP using BBS generator? Date: Fri, 18 Aug 2000 23:16:40 -0400 From: "Trevor L. Jackson, III" <fullmoon@aspi.net> Message-ID: <399DFC18.8E779911@aspi.net> References: <399BEB2B.2ED66E31@t-online.de> Newsgroups: sci.crypt Lines: 37 Mok-Kong Shen wrote: > Tim Tyler wrote: > > > > Imagine a rare spy, who - after landing in enemy territory - opens up > > his OTP and prepares to report that his espionage mission began > > successfully. Scanning the pages, he finds all the symbols are zeros. > > Imagine his dismay ;-) > > Why? If the spy knows that his agency has given him a > true OTP and he also happens to be a crypto theoretician, > he will not hesitate a micro-second before applying the > pad! Is the message as secure if he does not calculate the ciphertext produced by the null pad and simply sends the plaintext? > BTW, if the process is automatic, he (and his > colleagues who oversee the OTP generation at the agency) > shouldn't have visual contact with the pad at all. Does looking at the pad influence the security of the system? I.e., is there an observer effect? In addition to the obviousness of the all-zeros pad, there are a slew of pads that produce trivial transforms. What should the spy do if he notices that the pad only changes the upper/lower case of letters (and space to a punctuation mark). Can he decide that the tedium of encryption is unnecessary (he's got a manual system) and it's safe to send the original text? Does skipping the trivial encryption step count as "using" the keypad? If not, the spy can not use the same key over and over. This system may have interesting possibilities -- it just needs good marketing. Where is Szopa when we need him? Subject: Re: OTP using BBS generator? Date: Sat, 19 Aug 2000 08:53:49 +0200 From: Mok-Kong Shen <mok-kong.shen@t-online.de> Message-ID: <399E2EFD.3C092B39@t-online.de> References: <399DFC18.8E779911@aspi.net> Newsgroups: sci.crypt Lines: 79 "Trevor L. Jackson, III" wrote: > > Mok-Kong Shen wrote: > > > Tim Tyler wrote: > > > > > > Imagine a rare spy, who - after landing in enemy territory - opens up > > > his OTP and prepares to report that his espionage mission began > > > successfully. Scanning the pages, he finds all the symbols are zeros. > > > Imagine his dismay ;-) > > > > Why? If the spy knows that his agency has given him a > > true OTP and he also happens to be a crypto theoretician, > > he will not hesitate a micro-second before applying the > > pad! > > Is the message as secure if he does not calculate the ciphertext produced by > the null pad and simply sends the plaintext? In the time of science and technology, one always operates with a fair amount of 'belief', just as in ancient times. If one boards an airplane, is the flight secure? If you beieve the techniques, including all stuffs under automatic computer control, then yes. If you don't believe, then no. A belief can be pretty wrong though, see the recent catastrophe of a supersonic aircraft. So under the assumptions I made, the spy, having FULL belief on the impeacability of the theory, should do his routine encryption processing with the pad and send the message. Not doing the processing and sending the plaintext is a plain violation of the instructions he got from the agency. Whether the effect turns out to be the same is not an issue. As I said, he should not have visual contact with the pad, if processing is automatic. If he nonetheless examines it, there is an strong indication of a probability that he is not sure whether the pad is indeed an ideal OTP. In that case, his belief is in question and the assumptions are not fulfilled. > > > BTW, if the process is automatic, he (and his > > colleagues who oversee the OTP generation at the agency) > > shouldn't have visual contact with the pad at all. > > Does looking at the pad influence the security of the system? I.e., is there > an observer effect? > > In addition to the obviousness of the all-zeros pad, there are a slew of pads > that produce trivial transforms. What should the spy do if he notices that > the pad only changes the upper/lower case of letters (and space to a > punctuation mark). Can he decide that the tedium of encryption is unnecessary > (he's got a manual system) and it's safe to send the original text? > > Does skipping the trivial encryption step count as "using" the keypad? If > not, the spy can not use the same key over and over. > > This system may have interesting possibilities -- it just needs good > marketing. Where is Szopa when we need him? To put the assumptions explicit: (1) The agency CAN make an ideal OTP. (2) His colleagues make no errors. (3) The apriori probability of the opponent guessing the message is zero. (4) He applies the pad correctly. (5) He is an ABSOLUTE adherent of theoretical cryptology, is full confident that he has mastered the theory. If I were at his position, I would have decided otherwise, for condition (5) is unfortunately not fulfilled. That's why I pleaded (in the part you snipped) to conservatively apply statistical tests to all bit sequences in serious applications, whether these be from (quasi-) OTP, BBS, any other so-called 'provably secure' PRNGs, or simply a mundane PRNG. M. K. Shen -------------------------- http://home.t-online.de/home/mok-kong.shen Subject: Re: OTP using BBS generator? Date: Sat, 19 Aug 2000 17:05:24 -0400 From: "Trevor L. Jackson, III" <fullmoon@aspi.net> Message-ID: <399EF694.6661F72E@aspi.net> References: <399E2EFD.3C092B39@t-online.de> Newsgroups: sci.crypt Lines: 90 Mok-Kong Shen wrote: > "Trevor L. Jackson, III" wrote: > > > > Mok-Kong Shen wrote: > > > > > Tim Tyler wrote: > > > > > > > > Imagine a rare spy, who - after landing in enemy territory - opens up > > > > his OTP and prepares to report that his espionage mission began > > > > successfully. Scanning the pages, he finds all the symbols are zeros. > > > > Imagine his dismay ;-) > > > > > > Why? If the spy knows that his agency has given him a > > > true OTP and he also happens to be a crypto theoretician, > > > he will not hesitate a micro-second before applying the > > > pad! > > > > Is the message as secure if he does not calculate the ciphertext produced by > > the null pad and simply sends the plaintext? > > In the time of science and technology, one always operates > with a fair amount of 'belief', just as in ancient times. > If one boards an airplane, is the flight secure? If you > beieve the techniques, including all stuffs under automatic > computer control, then yes. If you don't believe, then no. > A belief can be pretty wrong though, see the recent > catastrophe of a supersonic aircraft. So under the > assumptions I made, the spy, having FULL belief on the > impeacability of the theory, should do his routine > encryption processing with the pad and send the message. > Not doing the processing and sending the plaintext > is a plain violation of the instructions he got from > the agency. Whether the effect turns out to be the same > is not an issue. As I said, he should not have visual > contact with the pad, if processing is automatic. If he > nonetheless examines it, there is an strong indication > of a probability that he is not sure whether the pad is > indeed an ideal OTP. In that case, his belief is in > question and the assumptions are not fulfilled. We know better than to test for the randomness of a sequence (as opposed to a source), but do we know better than to test for the orderliness of a sequence rather than a source? In principle, one can rely upon the source to produce the output it is designed to produce. But when one encouters an artifact, even an expected one, the urge to apply quality control to the output becomes intense. > > > > > > > BTW, if the process is automatic, he (and his > > > colleagues who oversee the OTP generation at the agency) > > > shouldn't have visual contact with the pad at all. > > > > Does looking at the pad influence the security of the system? I.e., is there > > an observer effect? > > > > In addition to the obviousness of the all-zeros pad, there are a slew of pads > > that produce trivial transforms. What should the spy do if he notices that > > the pad only changes the upper/lower case of letters (and space to a > > punctuation mark). Can he decide that the tedium of encryption is unnecessary > > (he's got a manual system) and it's safe to send the original text? > > > > Does skipping the trivial encryption step count as "using" the keypad? If > > not, the spy can not use the same key over and over. > > > > This system may have interesting possibilities -- it just needs good > > marketing. Where is Szopa when we need him? > > To put the assumptions explicit: (1) The agency CAN make an > ideal OTP. (2) His colleagues make no errors. (3) The apriori > probability of the opponent guessing the message is zero. > (4) He applies the pad correctly. (5) He is an ABSOLUTE > adherent of theoretical cryptology, is full confident > that he has mastered the theory. > > If I were at his position, I would have decided otherwise, > for condition (5) is unfortunately not fulfilled. That's > why I pleaded (in the part you snipped) to conservatively > apply statistical tests to all bit sequences in serious > applications, whether these be from (quasi-) OTP, BBS, > any other so-called 'provably secure' PRNGs, or simply > a mundane PRNG. > > M. K. Shen > -------------------------- > http://home.t-online.de/home/mok-kong.shen Subject: Re: OTP using BBS generator? Date: Sun, 20 Aug 2000 03:30:23 +0200 From: Mok-Kong Shen <mok-kong.shen@t-online.de> Message-ID: <399F34AF.91947965@t-online.de> References: <399EF694.6661F72E@aspi.net> Newsgroups: sci.crypt Lines: 41 "Trevor L. Jackson, III" wrote: > > We know better than to test for the randomness of a sequence (as opposed to a > source), but do we know better than to test for the orderliness of a sequence rather > than a source? > > In principle, one can rely upon the source to produce the output it is designed to > produce. But when one encouters an artifact, even an expected one, the urge to > apply quality control to the output becomes intense. In statistical tests, one tests in essence the presence of certain amount of patterns (orderliness). If that amount is lower than a threshold, it means the sequence is sufficiently random (with respect to the type of patterns examined). A test gives for one sequence only one value (result), the test statistic. If we let the source generate a large amount of such sequences, we can see whether the distribution of these values sufficiently well correspond to that of an ideal random source. If we do the same for all statistical tests available, we can have indeed a quite good feeling of the quality of the source in my humble view. On the other hand, one can let a single sequence that is actually used in the encryption process be subject to the diverse tests. If all tests are passed, then, on the assumption that the opponent doesn't have more/better tests, we can say that he can't discern any non-randomness (patterns) in it (since we can't) and hence the sequence is o.k. It is my humble opinion that on using ANY new source this procedure should always be applied until (hopefully) one collects sufficient amount of good experience with it such that one could with confidence dispense with the tests in order to save computing resources. M. K. Shen Subject: Re: OTP using BBS generator? Date: Sat, 19 Aug 2000 21:49:17 -0400 From: "Douglas A. Gwyn" <DAGwyn@null.net> Message-ID: <399F391D.E075F85@null.net> References: <399F34AF.91947965@t-online.de> Newsgroups: sci.crypt Lines: 45 Mok-Kong Shen wrote: > In statistical tests, one tests in essence the presence of > certain amount of patterns (orderliness). If that amount > is lower than a threshold, it means the sequence is > sufficiently random (with respect to the type of patterns > examined). As has been observed before, it is not the *data* that might be random, but the *process* that generates it. It is thus better to consider the property of "randomness" as meaning agreement with a specific source model. Then the test merely measures the degree of deviation from the model behavior. Some small fraction of the time, even a perfectly functioning true random generator *will* produce a highly patterned stretch of output data. When it does, the statistical test will flag the deviation; such occasional misdiagnosis is unavoidable. There is a trade-off between minimizing the chance that a valid source is rejected, and minimizing the chance that an malfunctioning source is accepted. Tests should be designed to make an appropriate trade-off. > A test gives for one sequence only one value (result), the > test statistic. If we let the source generate a large > amount of such sequences, we can see whether the distribution > of these values sufficiently well correspond to that of an > ideal random source. That is merely a different ("batched") kind of single test. > If we do the same for all statistical tests available, we > can have indeed a quite good feeling of the quality of the > source in my humble view. "All" tests available is an essentially unbounded number. It would be best to use tests designed specially for detecting the most likely kinds of deviation from the model, which for the most part requires analyzing the structure of the generator and its likely failure modes. This entire business is a well-established branch of statistics, and there are professionals who are paid to set up such tests. It's best to employ an expert than to try to "wing it" and end up with unwarranted confidence in a defective system due to poor test design. Subject: Re: OTP using BBS generator? Date: Sun, 20 Aug 2000 14:06:31 +0200 From: Mok-Kong Shen <mok-kong.shen@t-online.de> Message-ID: <399FC9C7.14D38BFD@t-online.de> References: <399F391D.E075F85@null.net> Newsgroups: sci.crypt Lines: 85 "Douglas A. Gwyn" wrote: > > Mok-Kong Shen wrote: > > In statistical tests, one tests in essence the presence of > > certain amount of patterns (orderliness). If that amount > > is lower than a threshold, it means the sequence is > > sufficiently random (with respect to the type of patterns > > examined). > > As has been observed before, it is not the *data* that might > be random, but the *process* that generates it. It is thus > better to consider the property of "randomness" as meaning > agreement with a specific source model. Then the test merely > measures the degree of deviation from the model behavior. > > Some small fraction of the time, even a perfectly functioning > true random generator *will* produce a highly patterned > stretch of output data. When it does, the statistical test > will flag the deviation; such occasional misdiagnosis is > unavoidable. There is a trade-off between minimizing the > chance that a valid source is rejected, and minimizing the > chance that an malfunctioning source is accepted. Tests > should be designed to make an appropriate trade-off. Right. Thanks for elaboration of the proper interpretation of tests which I pleaded to be always carried out in practice. > > > A test gives for one sequence only one value (result), the > > test statistic. If we let the source generate a large > > amount of such sequences, we can see whether the distribution > > of these values sufficiently well correspond to that of an > > ideal random source. > > That is merely a different ("batched") kind of single test. For that test (with the corresponding pattern being tested) it shows how the source deviates from an ideal source. Since it is a 'single' (type) of test, it is not sufficient. Consequently we need more, in fact a more or less complete spectrum of these. See also below. > > > If we do the same for all statistical tests available, we > > can have indeed a quite good feeling of the quality of the > > source in my humble view. > > "All" tests available is an essentially unbounded number. > It would be best to use tests designed specially for > detecting the most likely kinds of deviation from the model, > which for the most part requires analyzing the structure of > the generator and its likely failure modes. I meant by 'all available' what one knows and can afford to do (always with respect to economy, necessity, etc.), not 'all' that exist or will ever be invented in this world. There is of course an issue of intelligent choice of tests, our work being limited by the available resources, as is always the case in life. In fact one is involved in a 'game' here. For, if the opponent has better resources (tests) and is hence able to detect non-randomness that we can't, then we lose. If we are confident that he is not very 'rich', we could even opt to do less. > > This entire business is a well-established branch of > statistics, and there are professionals who are paid to > set up such tests. It's best to employ an expert than to > try to "wing it" and end up with unwarranted confidence in > a defective system due to poor test design. That the tests employed should be proper ones established in the mathematical science and that in serious applications trained statisticians should be engaged to do the job seem to be self-evident. It is true, though, that these are sometimes neglected in practice by the project managers. Once again I like to stress the need of practical tests, which should not be simply 'exempted' by the 'fame' of some mathematical 'proofs' (in particular those that do not in fact claim perfect security on a par with the ideal OTP) in connection with the sources being used. M. K. Shen Subject: Re: OTP using BBS generator? Date: Sun, 20 Aug 2000 12:56:21 -0400 From: "Douglas A. Gwyn" <DAGwyn@null.net> Message-ID: <39A00DB5.EF698419@null.net> References: <399FC9C7.14D38BFD@t-online.de> Newsgroups: sci.crypt Lines: 31 Mok-Kong Shen wrote: > Once again I like to stress the need of practical tests, > which should not be simply 'exempted' by the 'fame' of > some mathematical 'proofs' (in particular those that do > not in fact claim perfect security on a par with the > ideal OTP) in connection with the sources being used. ? That sounds like you're suggesting empirical tests to check *theoretical* properties, not correct functioning of the implementation. That could also be done theoretically, which would give a more reliable measure than a finite amount of testing. Of course, for many people it might be *easier* to implement the algorithm and run some standard tests (e.g. Diehard), but that doesn't make it the best way to gain confidence in the patternlessness of the output from the algorithm. Suppose I have an ideal PRNG that passes all standard statistical tests, and I embed it into an algorithm as follows: toggle = 0 forever: pick uniform random integer P in (100,150) generate P outputs from PRNG output toggle toggle = 1 - toggle That introduces a bias that is very hard to detect unless you suspect that an algorithm like that is being used and devise a test specifically for that kind of bias. In fact this sort of thing has been important in cracking some systems in the past. (Sorry, no details.) Subject: Re: OTP using BBS generator? Date: Sun, 20 Aug 2000 21:21:34 +0200 From: Mok-Kong Shen <mok-kong.shen@t-online.de> Message-ID: <39A02FBE.3A12E061@t-online.de> References: <39A00DB5.EF698419@null.net> Newsgroups: sci.crypt Lines: 77 "Douglas A. Gwyn" wrote: > > Mok-Kong Shen wrote: > > Once again I like to stress the need of practical tests, > > which should not be simply 'exempted' by the 'fame' of > > some mathematical 'proofs' (in particular those that do > > not in fact claim perfect security on a par with the > > ideal OTP) in connection with the sources being used. > > ? That sounds like you're suggesting empirical tests to > check *theoretical* properties, not correct functioning > of the implementation. That could also be done > theoretically, which would give a more reliable measure > than a finite amount of testing. Of course, for many > people it might be *easier* to implement the algorithm > and run some standard tests (e.g. Diehard), but that > doesn't make it the best way to gain confidence in the > patternlessness of the output from the algorithm. > > Suppose I have an ideal PRNG that passes all standard > statistical tests, and I embed it into an algorithm as > follows: > toggle = 0 > forever: > pick uniform random integer P in (100,150) > generate P outputs from PRNG > output toggle > toggle = 1 - toggle > That introduces a bias that is very hard to detect unless > you suspect that an algorithm like that is being used and > devise a test specifically for that kind of bias. In fact > this sort of thing has been important in cracking some > systems in the past. (Sorry, no details.) Checking the validity of theory in practice has always been the routine in all applied sciences, from medicine to aerospace engineering. This is because a theory almost without exception is based on assumptions which are simplifications/approximations of the real world and hence one needs to verify that the error thereby involved is indeed negligible or tolerable. That tests are imperfect and themselves involve the reliability/accuracy issue is well-known but is not relevant in the present context. Statistical tests are BTW by nature never 'perfect' (in the sense of giving absolute answers), otherwise the term 'confidence interval' would not exist. Some of them have better 'power' in that they are more sensitive than the others in certain issues. It can well be that in certain circumstances what the theory can easily tell about the existence of some defects is not (yet) discernable by any currently existing tests. But this does not distract from my theme that one should always COMPLEMENT theoretical assertions with checks of practical nature (in our case statistical tests). It is noteworthy that in papers in numerical mathematics, where e.g. certain new solution methods are developed with solid sophisticated theoretical foundations, examples of computational results are almost invariable given, providing confidence that the theory indeed fulfills what has been expected of it. On the other hand, an essential shift in the kind/nature of tests can be observed in many fields of science and engineering. In automobile industry, for example, a large proportion of field tests have nowadays been replaced by numerical simulations, though real old-style field tests continue to be carried out. What I actually like to warn is against a potential 'vanity' of believing that having a (presumably) perfect theory with an impeacable proof is 'everything', thus being blind of the fact that the truth of many theorems are contigent on the fulfillment of their respective assumptions, leading consequently under circumstances to regretful disasters. M. K. Shen Subject: Re: OTP using BBS generator? Date: Mon, 21 Aug 2000 08:07:58 GMT From: Bryan Olson <bryanolson@my-deja.com> Message-ID: <8nqo0lm0r1@nnrp1.deja.com> References: <399E2EFD.3C092B39@t-online.de> Newsgroups: sci.crypt Lines: 17 Mok-Kong Shen wrote: > To put the assumptions explicit: [...] > (3) The apriori > probability of the opponent guessing the message is zero. How could that ever hold? --Bryan -- email: bolson at certicom dot com Sent via Deja.com http://www.deja.com/ Before you buy. Subject: Re: OTP using BBS generator? Date: Mon, 21 Aug 2000 10:50:52 +0200 From: Mok-Kong Shen <mok-kong.shen@t-online.de> Message-ID: <39A0ED6C.7344AD3D@t-online.de> References: <8nqo0lm0r1@nnrp1.deja.com> Newsgroups: sci.crypt Lines: 22 Bryan Olson wrote: > > Mok-Kong Shen wrote: > > > To put the assumptions explicit: > [...] > > (3) The apriori > > probability of the opponent guessing the message is zero. > > How could that ever hold? You are right in questioning that. A contrived 'theoretical' case is that the spy cast a perfect die to determine (out of the blue) what he wants to talk to his colleagues. Note that the condition (1) that the agency CAN generate an ideal OTP is also purely hypothetical, there be no practical means of knowing that a given source indeed produces an ideal OTP, as far as I am aware. M. K. Shen Subject: Re: OTP using BBS generator? Date: Mon, 21 Aug 2000 17:35:26 GMT From: Bryan Olson <bryanolson@my-deja.com> Message-ID: <8nrp8ts1f1@nnrp1.deja.com> References: <39A0ED6C.7344AD3D@t-online.de> Newsgroups: sci.crypt Lines: 34 Mok-Kong Shen wrote: > > Bryan Olson wrote: > > > > Mok-Kong Shen wrote: > > > > > To put the assumptions explicit: > > [...] > > > (3) The apriori > > > probability of the opponent guessing the message is zero. > > > > How could that ever hold? > > You are right in questioning that. A contrived 'theoretical' > case is that the spy cast a perfect die to determine (out > of the blue) what he wants to talk to his colleagues. So in that case the guessing chance is 1 / (number of sides on die). The question is how could it be zero. The only was I see it happening is if the attacker has such bad disinformation about our message space that he assigns zero probability to ever message that is in fact possible. --Bryan -- email: bolson at certicom dot com Sent via Deja.com http://www.deja.com/ Before you buy. Subject: Re: OTP using BBS generator? Date: Mon, 21 Aug 2000 21:05:32 +0200 From: Mok-Kong Shen <mok-kong.shen@t-online.de> Message-ID: <39A17D7C.B1F9E05B@t-online.de> References: <8nrp8ts1f1@nnrp1.deja.com> Newsgroups: sci.crypt Lines: 53 Bryan Olson wrote: > > Mok-Kong Shen wrote: > > > > Bryan Olson wrote: > > > > > > Mok-Kong Shen wrote: > > > > > > > To put the assumptions explicit: > > > [...] > > > > (3) The apriori > > > > probability of the opponent guessing the message is zero. > > > > > > How could that ever hold? > > > > You are right in questioning that. A contrived 'theoretical' > > case is that the spy cast a perfect die to determine (out > > of the blue) what he wants to talk to his colleagues. > > So in that case the guessing chance is > > 1 / (number of sides on die). > > The question is how could it be zero. The only was I see it > happening is if the attacker has such bad disinformation > about our message space that he assigns zero probability to > ever message that is in fact possible. > First of all the 'zero' is understood in the sense of probability theory not in the sense of number theory. At the time the spy makes up a list for casting a die, he has free choice out of a practically unlimited topics to be mapped to the die. The die may also be cast a multiple times (thus having a larger event space) to render the probability you mentioned arbitrarily small. Once the topic is selected, he has yet a free choice of messages (content). So before the timepoint where his huge neuronal network starts to compose the message, even the spy himself doesn't know what that message is. So I think that justifies to ascribe a probability 0. (There 'could' be on the other hand a means for the opponent to guess this message: through 'reading' his mind at distance, an action claimed to be possible by persons of a certain psychology-related field in which I have unfortunately no confidence at all. An article I happened to read long time ago reported namely that the well-known agency BGK and its famous counterpart both conducted experiments in that field.) M. K. Shen Subject: Re: OTP using BBS generator? Date: Mon, 21 Aug 2000 19:40:25 GMT From: Bryan Olson <bryanolson@my-deja.com> Message-ID: <8ns0j55cs1@nnrp1.deja.com> References: <39A17D7C.B1F9E05B@t-online.de> Newsgroups: sci.crypt Lines: 55 Mok-Kong Shen wrote: > > Bryan Olson wrote: > > > > Mok-Kong Shen wrote: > > > > > > Bryan Olson wrote: > > > > > > > > Mok-Kong Shen wrote: > > > > > > > > > To put the assumptions explicit: > > > > [...] > > > > > (3) The apriori > > > > > probability of the opponent guessing the message is zero. > > > > > > > > How could that ever hold? > > > > > > You are right in questioning that. A contrived 'theoretical' > > > case is that the spy cast a perfect die to determine (out > > > of the blue) what he wants to talk to his colleagues. > > > > So in that case the guessing chance is > > > > 1 / (number of sides on die). > > > > The question is how could it be zero. The only was I see it > > happening is if the attacker has such bad disinformation > > about our message space that he assigns zero probability to > > ever message that is in fact possible. > > > > First of all the 'zero' is understood in the sense of > probability theory not in the sense of number theory. > At the time the spy makes up a list for casting a die, > he has free choice out of a practically unlimited topics > to be mapped to the die. The die may also be cast a > multiple times (thus having a larger event space) to > render the probability you mentioned arbitrarily small. > Once the topic is selected, he has yet a free choice > of messages (content). So before the timepoint where > his huge neuronal network starts to compose the message, > even the spy himself doesn't know what that message is. > So I think that justifies to ascribe a probability 0. That justifies "small" or even "negligible". Zero is wrong. --Bryan -- email: bolson at certicom dot com Sent via Deja.com http://www.deja.com/ Before you buy. Subject: Re: OTP using BBS generator? Date: Mon, 21 Aug 2000 22:57:58 +0200 From: Mok-Kong Shen <mok-kong.shen@t-online.de> Message-ID: <39A197D6.96C4B69B@t-online.de> References: <8ns0j55cs1@nnrp1.deja.com> Newsgroups: sci.crypt Lines: 61 Bryan Olson wrote: > > Mok-Kong Shen wrote: > > > > Bryan Olson wrote: > > > > > > Mok-Kong Shen wrote: > > > > > > > > Bryan Olson wrote: > > > > > > > > > > Mok-Kong Shen wrote: > > > > > > > > > > > To put the assumptions explicit: > > > > > [...] > > > > > > (3) The apriori > > > > > > probability of the opponent guessing the message is zero. > > > > > > > > > > How could that ever hold? > > > > > > > > You are right in questioning that. A contrived 'theoretical' > > > > case is that the spy cast a perfect die to determine (out > > > > of the blue) what he wants to talk to his colleagues. > > > > > > So in that case the guessing chance is > > > > > > 1 / (number of sides on die). > > > > > > The question is how could it be zero. The only was I see it > > > happening is if the attacker has such bad disinformation > > > about our message space that he assigns zero probability to > > > ever message that is in fact possible. > > > > > > > First of all the 'zero' is understood in the sense of > > probability theory not in the sense of number theory. > > At the time the spy makes up a list for casting a die, > > he has free choice out of a practically unlimited topics > > to be mapped to the die. The die may also be cast a > > multiple times (thus having a larger event space) to > > render the probability you mentioned arbitrarily small. > > Once the topic is selected, he has yet a free choice > > of messages (content). So before the timepoint where > > his huge neuronal network starts to compose the message, > > even the spy himself doesn't know what that message is. > > So I think that justifies to ascribe a probability 0. > > That justifies "small" or even "negligible". > Zero is wrong. Then kindly give me an example of yours that can serve to illustrate a probability of measure zero so that we could have a compararison. BTW, I did forget an additional assumption that is essential: (6) The encryption is performed in a tempest-proof enviroment. Otherwise, the opponent has an easy job. M. K. Shen Subject: Re: OTP using BBS generator? Date: Tue, 22 Aug 2000 04:40:23 GMT From: Bryan Olson <bryanolson@my-deja.com> Message-ID: <8nt07k9rq1@nnrp1.deja.com> References: <39A197D6.96C4B69B@t-online.de> Newsgroups: sci.crypt Lines: 35 Mok-Kong Shen wrote: > Bryan Olson wrote: > > Mok-Kong Shen wrote: > > > First of all the 'zero' is understood in the sense of > > > probability theory not in the sense of number theory. > > > At the time the spy makes up a list for casting a die, > > > he has free choice out of a practically unlimited topics > > > to be mapped to the die. The die may also be cast a > > > multiple times (thus having a larger event space) to > > > render the probability you mentioned arbitrarily small. > > > Once the topic is selected, he has yet a free choice > > > of messages (content). So before the timepoint where > > > his huge neuronal network starts to compose the message, > > > even the spy himself doesn't know what that message is. > > > So I think that justifies to ascribe a probability 0. > > > > That justifies "small" or even "negligible". > > Zero is wrong. > > Then kindly give me an example of yours that can > serve to illustrate a probability of measure zero > so that we could have a compararison. Uh, O.K: Let m be any message space, and s the sum of the probabilities of all messages in m. Consider the probability that s does not equal one. --Bryan -- email: bolson at certicom dot com Sent via Deja.com http://www.deja.com/ Before you buy. Subject: Re: OTP using BBS generator? Date: Tue, 22 Aug 2000 11:14:26 +0200 From: Mok-Kong Shen <mok-kong.shen@t-online.de> Message-ID: <39A24472.6B4D72E7@t-online.de> References: <8nt07k9rq1@nnrp1.deja.com> Newsgroups: sci.crypt Lines: 73 Bryan Olson wrote: > > Mok-Kong Shen wrote: > > Bryan Olson wrote: > > > Mok-Kong Shen wrote: > > > > First of all the 'zero' is understood in the sense of > > > > probability theory not in the sense of number theory. > > > > At the time the spy makes up a list for casting a die, > > > > he has free choice out of a practically unlimited topics > > > > to be mapped to the die. The die may also be cast a > > > > multiple times (thus having a larger event space) to > > > > render the probability you mentioned arbitrarily small. > > > > Once the topic is selected, he has yet a free choice > > > > of messages (content). So before the timepoint where > > > > his huge neuronal network starts to compose the message, > > > > even the spy himself doesn't know what that message is. > > > > So I think that justifies to ascribe a probability 0. > > > > > > That justifies "small" or even "negligible". > > > Zero is wrong. > > > > Then kindly give me an example of yours that can > > serve to illustrate a probability of measure zero > > so that we could have a compararison. > > Uh, O.K: Let m be any message space, and s the sum > of the probabilities of all messages in m. Consider > the probability that s does not equal one. First of all I don't yet see how you were answering to my question, i.e. that that provides an example of the kind I requested. Anyway, s, the sum of all probabilities is by definition equal to one, isn't it? We are doing 'hair-splitting' here. But never mind to continue, as far I am concerned. I claim that there is an infinite number of topics possible. Could you accept that? If yes, then the probability of apriori determining a message (by our imaginary and imaginative than any epsilon that you care to give. One counter- argument that you could validly raise is that the brain consists of a finite number of neurons and that that system cannot possibly generate an infinite number of entities in any finite time. But now we are apparently beginning to touch on the so-called mind and body issue, which is not yet resolved, as far as I am aware. Anyway, for our purpose, is there a 'limit' to one's (creative) thought? Is thought realized by a process carried out by these finite number of neurons? A tiny step further would then, I am afraid, be the question of what is consciousness after all. How (through what mechanism) could one ever be conscious? Am I really conscious of the existence of myself and the world? In fact in an analogous vein you could also argue that the number infinity does not exist and hence should be excluded from consideration, for any number one could 'think' of must have a finite number of digits, however large. Or that the Eulidean geometry is nonsense, because any point must have a finite dimension, etc. I am afraid that we would be heavily flamed for wasting bandwidth. But I am ready and interested to continue discussing with you on a path which in my humble view is no longer crypto but philosophical (maybe pseudo- philosophical) via e-mail, even though I know that my knowledge is fairly poor and am hence likely to be beaten by anyone who knows more. M. K. Shen Subject: Re: OTP using BBS generator? Date: Mon, 21 Aug 2000 07:33:33 GMT From: Bryan Olson <bryanolson@my-deja.com> Message-ID: <8nqm0cjse1@nnrp1.deja.com> References: <3999365a.980293@news.ecn.ab.ca> Newsgroups: sci.crypt Lines: 71 John Savard wrote: > Bryan Olson wrote, in part: > >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. > > Now, this doesn't seem to say more than that even the OTP is not > secure if the attacker _knows_ the key, so that doesn't seem to be > germane. Whatever the problem is, it isn't that the attacker *knew* > you were going to use an OTP with 000...000 on it. Even if we accept that the attacker doesn't get any information on the choice we make, we lose the proof of secrecy. The attacker knowing the distribution from which the key was drawn is no longer the worst-case assumption. > >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. > > But that is what the *other* poster said, in effect. The fact that the > OTP value didn't *have* to be zero is claimed to give secrecy - even > in the case where the key happened to be zero. But claiming it's secure in the case when one chooses the zero key is wrong. It is not the individual cases that are secure - secrecy is only provable for the set of cases with their probabilities. The belief that each key is equally likely is not a limitation that we get to impose upon the attacker as some seemed to think. It is, when considering the uniform keyspace, the worst-case assumption and thus our system is as secure no matter what the believes the keyspace to be. > Besides rejecting the all-zero pad, how far should one go, though? > > Presumably, on the basis that the attacker does not know that an OTP > is being used, but will consider other, lesser, systems, one should > > (!) > reject all pads that correspond to any XOR stream cipher that could be > solved on the basis of a single message of the same size as the pad. > (!) > > Thus, for example, a pad consisting entirely of a short, repeated, > sequence of bytes should also be rejected. No, no, no. Choose the keys uniformly. One might well reject the generator on this basis, but equally probable keys are the ideal. --Bryan -- email: bolson at certicom dot com Sent via Deja.com http://www.deja.com/ Before you buy. Subject: Re: OTP using BBS generator? Date: Thu, 17 Aug 2000 00:42:09 GMT From: Tim Tyler <tt@cryogen.com> Message-ID: <FzEvA9.7vu@bath.ac.uk> References: <8naj1i6ek1@nnrp1.deja.com> Newsgroups: sci.crypt Lines: 72 Bryan Olson <bryanolson@my-deja.com> wrote: :> 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. Doesn't this violate the assumption that the attacker has full knowledge of the cyphermachinery? Anyway, the cases still seem significantly different: *if* the attacker knows what machinery has been used, the chance use of a zero key in an OTP gives the attacker no information about the plaintext, while the chance use of a short cycle in a rng-based stream may completely give the game away - *assuming* the attacker is generally running a short cycle check, based on known plaintext for some reason. : 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. Essentially, I agree with this. I suspect, however that it assumes that any hardware used for checking for short cycles may also - in principle - be used to factor the modulus. This is probably a very reasonable assumption - but I doubt it's necessarily always true. If looking for short cycles in the output is easy, while (say) generating output and then looking for short cycles is not, this may create an asymmetry, which might mean that short cycles in the output /do/ represent what Ritter has called an "additional" weakness. The assumptions here may be rather contrived however... Normally, looking for short cycles in this system would probably be a waste of time and resources. It would not be the best way to attack. However, if it's being done /anyway/, for some other reason (say to detect the use of occasional messages in another cypher), then this too might cause short cycles to be an actual source of weakness. <giggles> Another issue might be that rejecting short cycles appears to decrease the size of the keyspace. Has anyone yet proposed that rejecting these seeds is a cause of loss of strength? ;-) This post is a little speculative - but I've not seen these issues raised elsewhere. I'd be interested to know if this line of reasoning has any substance. -- __________ Lotus Artificial Life http://alife.co.uk/ tt@cryogen.com |im |yler The Mandala Centre http://mandala.co.uk/ Namaste. Subject: Re: OTP using BBS generator? Date: Wed, 16 Aug 2000 18:47:02 -0700 From: "Paul Pires" <diodude@got.net> Message-ID: <FwHm5.84026iI5.1232336@news-west.usenetserver.com> References: <FzEvA9.7vu@bath.ac.uk> Newsgroups: sci.crypt Lines: 88 Tim Tyler <tt@cryogen.com> wrote in message news:FzEvA9.7vu@bath.ac.uk... > Bryan Olson <bryanolson@my-deja.com> wrote: > :> 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. > > Doesn't this violate the assumption that the attacker has full knowledge > of the cyphermachinery? > > Anyway, the cases still seem significantly different: *if* the attacker > knows what machinery has been used, the chance use of a zero key in an OTP > gives the attacker no information about the plaintext, while the chance > use of a short cycle in a rng-based stream may completely give the game > away - *assuming* the attacker is generally running a short cycle check, > based on known plaintext for some reason. > > : 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. > > Essentially, I agree with this. I suspect, however that it assumes that > any hardware used for checking for short cycles may also - in principle > - be used to factor the modulus. This is probably a very reasonable > assumption - but I doubt it's necessarily always true. > > If looking for short cycles in the output is easy, while (say) generating > output and then looking for short cycles is not, this may create an > asymmetry, which might mean that short cycles in the output /do/ represent > what Ritter has called an "additional" weakness. > > The assumptions here may be rather contrived however... > > Normally, looking for short cycles in this system would probably be a > waste of time and resources. It would not be the best way to attack. > However, if it's being done /anyway/, for some other reason (say to detect > the use of occasional messages in another cypher), then this too might > cause short cycles to be an actual source of weakness. > > <giggles> Another issue might be that rejecting short cycles appears to > decrease the size of the keyspace. Has anyone yet proposed that rejecting > these seeds is a cause of loss of strength? ;-) Good point. I've been trying to follow this conversation and it seems to me that this is the essense of Bryan Olson's point (don't shoot, Im running as fast as I can). But if you conceed that the occurance is exceedingly rare it does not seem as if it could be a meaningful reduction. A theoretical weakness without practical repercussions? Now here is the leap, are we just rying to figure out which miniscule, non-optimal effect is worse? > > This post is a little speculative - but I've not seen these issues raised > elsewhere. I'd be interested to know if this line of reasoning has any > substance. > -- > __________ Lotus Artificial Life http://alife.co.uk/ tt@cryogen.com > |im |yler The Mandala Centre http://mandala.co.uk/ Namaste. Subject: Re: OTP using BBS generator? Date: Thu, 17 Aug 2000 15:39:49 +0200 From: Mok-Kong Shen <mok-kong.shen@t-online.de> Message-ID: <399BEB25.12EC384C@t-online.de> References: <FzEvA9.7vu@bath.ac.uk> Newsgroups: sci.crypt Lines: 52 Tim Tyler wrote: > > :> 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. > > Doesn't this violate the assumption that the attacker has full knowledge > of the cyphermachinery? > > Anyway, the cases still seem significantly different: *if* the attacker > knows what machinery has been used, the chance use of a zero key in an OTP > gives the attacker no information about the plaintext, while the chance > use of a short cycle in a rng-based stream may completely give the game > away - *assuming* the attacker is generally running a short cycle check, > based on known plaintext for some reason. So it appears that in the proof of security of OTP one needs an additional assumption: The opponent knows (and is convinced) that the sender uses an OTP. It also shows the essential role played by psychology (the belief) in crypto, as I recently mentioned. M. K. Shen Subject: Re: OTP using BBS generator? Date: Mon, 21 Aug 2000 07:46:47 GMT From: Bryan Olson <bryanolson@my-deja.com> Message-ID: <8nqmp3kpe1@nnrp1.deja.com> References: <399BEB25.12EC384C@t-online.de> Newsgroups: sci.crypt Lines: 19 Mok-Kong Shen wrote: > So it appears that in the proof of security of OTP one > needs an additional assumption: > > The opponent knows (and is convinced) that the > sender uses an OTP. The proof holds for the keyspace, so the assumption is the worst case and any violation can only hurt the attacker. --Bryan -- email: bolson at certicom dot com Sent via Deja.com http://www.deja.com/ Before you buy. Subject: Re: OTP using BBS generator? Date: Fri, 18 Aug 2000 02:54:21 +0100 From: David Hopwood <hopwood@zetnet.co.uk> Message-ID: <399C974D.E1302F03@zetnet.co.uk> References: <FzEvA9.7vu@bath.ac.uk> Newsgroups: sci.crypt Lines: 35 -----BEGIN PGP SIGNED MESSAGE----- Tim Tyler wrote: > Another issue might be that rejecting short cycles appears to > decrease the size of the keyspace. Has anyone yet proposed that rejecting > these seeds is a cause of loss of strength? ;-) I thought about that, and concluded that it doesn't. (An amusing proof is to use the fact that the short cycle checks have no effect except with negligable probability :-) - -- David Hopwood <hopwood@zetnet.co.uk> Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/ RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01 Nothing in this message is intended to be legally binding. If I revoke a public key but refuse to specify why, it is because the private key has been seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv iQEVAwUBOZyXBzkCAxeYt5gVAQHKVAgAl/yqQwAP1GmG2G3yoquW8uJOvefYdMFj W8fKARvtLQNV0ju+axRU9RJfY1V8Ysq/GTjXzD0TBlMjbu5YKab+/IhDHxdnsXqK 770koD1Jj/OjHMayPpUR5p0ulTd6uD90HK3ep+Z3IslYYDadAoluDp61vBY031E8 Q+IdK8T0MNBKCSyoKY65mrl2XkPGdWjXcoHNjmupHfK87kDeiwnGl+lO2oIVZeFT uFVfUv8XHxJDT4oEulQDuF3N0BPtO2s/vmd34LCxvkk5owS+gKcWeba2WfWEw4ki 6u9/egmvP6l9JLdYPt3eEebp6nKmvv8pkHFDqcIza+DhUAS9daPlow== =5Amf -----END PGP SIGNATURE----- Subject: Re: OTP using BBS generator? Date: Fri, 18 Aug 2000 05:45:11 +0100 From: David Hopwood <hopwood@zetnet.co.uk> Message-ID: <399CBF56.42B0F43@zetnet.co.uk> References: <399C974D.E1302F03@zetnet.co.uk> Newsgroups: sci.crypt Lines: 37 -----BEGIN PGP SIGNED MESSAGE----- David Hopwood wrote: > Tim Tyler wrote: > > Another issue might be that rejecting short cycles appears to > > decrease the size of the keyspace. Has anyone yet proposed that rejecting > > these seeds is a cause of loss of strength? ;-) > > I thought about that, and concluded that it doesn't. (An amusing proof is to > use the fact that the short cycle checks have no effect except with negligable > probability :-) ... except that the distribution of moduli is different, of course. - -- David Hopwood <hopwood@zetnet.co.uk> Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/ RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01 Nothing in this message is intended to be legally binding. If I revoke a public key but refuse to specify why, it is because the private key has been seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv iQEVAwUBOZy/LTkCAxeYt5gVAQHu8gf+J1MKbtaCzWDum9YjrBXYLUhO8Neguyee rIurOw9p46p4N4yBGy8qCI4YloMOKcFaPWkhP2ZHPjye8XjTlpoptcoSwiUbBHWa gdlbCbumsJwtT8ePHTh0a4LU8q1URrYm8hB5E4/zM9N1ocEecY0vb1XRkv0Xe2Gl uLVCB8yU9lbnY8+KV8g1x9R3AQhNDEa+1kUQ5H0JtkptwQkL//KHAbvpyz440mcM YeHNignst5y4/CIPHyiu2RQ+yDOrwGMfWnuIqbEb+7Fd2OPnjlSyA/aFH2btmMT0 Q8w/FjcqxEE5nqPzh58XSh5QAokuY1bTN2SnYld44U19kWJ6k7i0XQ== =W2mo -----END PGP SIGNATURE----- Subject: Re: OTP using BBS generator? Date: Mon, 07 Aug 2000 20:37:01 GMT From: Bryan Olson <bryanolson@my-deja.com> Message-ID: <8mn6ldki31@nnrp1.deja.com> References: <398e3f87.1656232@news.io.com> Newsgroups: sci.crypt Lines: 158 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 > 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. Subject: Re: OTP using BBS generator? Date: Tue, 08 Aug 2000 15:57:03 +0200 From: Mok-Kong Shen <mok-kong.shen@t-online.de> Message-ID: <399011AF.D8C83B15@t-online.de> References: <398e3f87.1656232@news.io.com> Newsgroups: sci.crypt Lines: 31 Terry Ritter wrote: > > 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. 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." > As someone has pointed out (I don't remember whether in this thread or not), the term 'provable security' is misleading in almost all applied instances. For it carries the easily misinterpreted connotation that a certain algorithm being referred to by the term provides absolute security and that that fact has been UNCONDITIONALLY proved. What actually happens, however, in such cases is that there exists a rigorous, logically impacable proof leading from certain assumptions to the conclusion of perfect security or some quantifiable approximation of perfect security. There is no more nor less. So the term 'provable security' should be replaced by 'existence of a rigorous security proof contigent on fulfillment of certain assumptions'. The replacement string is unfortunately rather long but we have to use it in order to avoid catastrophical misunderstandings of lots of people. M. K. Shen Subject: Re: OTP using BBS generator? Date: 03 Aug 2000 17:20:05 GMT From: macckone@aol.comnjunk123 (Mack) Message-ID: <20000803132005.24871.00000325@ng-fe1.aol.com> References: <slrn8oisp7.26s.mdw@mull.ncipher.com> Newsgroups: sci.crypt Lines: 57 >Mack <macckone@aol.comnjunk123> wrote: > >> >The key thing for me is finding out if there is a good reason why >> >this isn't secure? There are proofs for BBS that prove it is as >> >difficult as factoring whereas almost all other schemes (RSA etc) >> >don't have a prove just a belief... >> >> The proofs that show BBS is as secure as factoring make a number of >> assumptions. In this case it is that the discrete logarithm problem >> is 'hard'. And that the quadratic residuosity problem is 'hard'. RSA >> has proofs that follow from similar assumptions. > >Breaking the BBS is as hard as deciding quadratic residuosity. That's >certainly no harder than factoring, because you can use factoring to >decide quadratic residuosity, and indeed this is the only way we know >for doing this. The quadratic residuosity problem (QRP) is old and >well-known; however, we don't know that it's actually as dificult as >factoring. > >By contrast, we know that breaking RSA is as difficult as solving the >RSA problem (RSAP). This isn't helpful -- it's just a restatement of >the same thing. We've no idea whether RSAP is actually difficult. >Again, the only way we know for solving the general RSAP is to factor. >On the other hand, RSAP is new. > >> The BBS and RSA are very similar. BBS requires that the primes >> be of special form. RSA is a bit more liberal > >The form for a Blum modulus isn't very special: the primes p and q must >each be congruent to 3 (mod 4); i.e., the bottom two bits of each should >be set. The other stuff with (p - 1)/2 being prime and so on isn't >particularly important unless you don't understand the security warranty >on the BBS generator. > >> although for longest period they should probably be of the same form. > >Can you justify this statement? I can't offhand see why an RSA modulus >would need to be a Blum integer for this. > The period of the RSA generator should be findable using the same method as BBS. I don't have a proof of period but it can't really hurt can it? >> BBS is a bit more efficient than the RSA generator (one >> multiplication). > >One squaring, in fact. Squaring is faster than multiplication. > No, one multiplication. BBS uses one squaring. RSA uses one squaring and one multiplication. >-- [mdw] > Mack Remove njunk123 from name to reply by e-mail Subject: Re: OTP using BBS generator? Date: Fri, 4 Aug 2000 07:55:12 GMT From: Tim Tyler <tt@cryogen.com> Message-ID: <FyrCo0.M39@bath.ac.uk> References: <20000803132005.24871.00000325@ng-fe1.aol.com> Newsgroups: sci.crypt Lines: 16 Mack <macckone@aol.comnjunk123> wrote: :mdw wrote: :>Mack <macckone@aol.comnjunk123> wrote: :>> BBS is a bit more efficient than the RSA generator (one :>> multiplication). :> :>One squaring, in fact. Squaring is faster than multiplication. : No, one multiplication. BBS uses one squaring. RSA uses one : squaring and one multiplication. It looks like you're both right ;-) -- __________ Lotus Artificial Life http://alife.co.uk/ tt@cryogen.com |im |yler The Mandala Centre http://mandala.co.uk/ Breast is best. Subject: Re: OTP using BBS generator? Date: 3 Aug 2000 13:17:05 GMT From: mdw@nsict.org (Mark Wooding) Message-ID: <slrn8ois6g.26s.mdw@mull.ncipher.com> References: <3988EC4E.9555D120@supreme-overlord.com> Newsgroups: sci.crypt Lines: 66 Grant Anderson <grant_anderson@supreme-overlord.com> wrote: [Five times! Please don't post articles more than once. Pretty, pretty please, with a cherry on top. Or I'll have to start complaining to admins.] > I know there has been much discussion about (supposed) OTP ciphers and > how most of them generally don't fulfil the OTP requirements. What I > don't understand is why the use of the blum-blum-shub generator as the > pad isn't acceptable? I have read a great deal about the > characteristics of the BBS generator and it *seems* secure as > "random-number" generators go. It *is* acceptable. The Blum-Goldwasser probabiliistic encryption algorithm is based on this very same idea. I'll describe it below. It's been proven to be semantically secure against polynomially-bounded adversaries under the assumption of the difficulty of the quadratic residuosity problem. This is essentially a polynomially-bounded version of the security you get from a one-time pad. > Assuming that each individual has a private key pair (two large > primes) p and q and a public key n such that p x q = n, then the BBS > generator creates bits by: > > x(i)=x^2 mod n for each i > > Now obviously you can't use the same pad twice, so you would need to > do something like having a central repository (the keyserver for > example) which remembers the last "i" value for each user. So when you > want to encrypt for user A, you contact the keyserver and obtain their > public key (n) and the initialisation value i and start generating > from i+1.... > > What is wrong with this solution? Assume that I can see all the ciphertext messages. I keep polling the key server and finding out where the counter is for my chosen victim. When the counter changes, and a ciphertext arrives, I use the saved counter to decrypt the message in exactly the same way that you encrypted it. Note that there's no particular use for the modulus factors in your system, and they're the only secrets in it. A better idea would be to choose a *random* starting point: n is large, so this isn't a great problem. Let's call the starting point x_0. Then I encrypt with the least significant lg lg n bits of x_{i+1} = x_i^2 mod n until the message is done. I'm left with x_N at the end of this. If I append x_N to my ciphertext message, then the recipient, knowing N and the factors p, q of n can recover x_1 (not x_0, because that might not be a quadratic residue). Here's how: * Firstly, note that if p = 3 (mod 4) then ((x^2)^{(p+1)/4})^2 = x^2 (mod n). (x^2 here is just some quadratic residue.) To see this, just multiply it all out: p + 1 is multiple of 4, and p + 1 = 2 (mod p - 1). * Now compute y = x_N^{((p + 1)/4)^N mod (p - 1)} mod p and z = x_N^{((q + 1)/4)^N mod (q - 1)} mod q. Combine y and z to find a square root of x_1 mod n, using the Chinese Remainder Theorem. *This* is Blum-Goldwasser probabilistic encryption. It's vulnerable to a chosen ciphertext attack, by the way. You can learn two square-roots for a value mod n, and hence factor the modulus. -- [mdw] Subject: Re: OTP using BBS generator? Date: Thu, 03 Aug 2000 15:21:02 GMT From: scott@helsbreth.org (Scott Nelson) Message-ID: <398988f6.936761@news.inreach.com> References: <3988EB99.29597754@supreme-overlord.com> Newsgroups: sci.crypt Lines: 26 On 03 Aug 2000 Grant Anderson <grant_anderson@supreme-overlord.com> wrote: >I know there has been much discussion about (supposed) OTP ciphers and >how >most of them generally don't fulfil the OTP requirements. What I don't >understand is why the use of the blum-blum-shub generator as the pad >isn't acceptable? > For most practical applications it is acceptable. But for most practical applications, so are a large number of conventional ciphers, and they're all easier to use than a Pseudo-OTP system. One Time Pad is more a theoretical than practical encryption. To be theoretically perfect, it requires perfect random numbers for the pad. BBS is at best pseudo random, therefore can, at best, offer pseudo security. In other words, a pad derived from BBS is just another stream cipher, and it shouldn't be called a one time pad. (Even if it's used only once.) If a pad is created by a repeatable method it should be called a pseudo one time pad. Scott Nelson <scott@helsbreth.org> Subject: Re: OTP using BBS generator? Date: Thu, 3 Aug 2000 11:39:04 -0700 From: "Joseph Ashwood" <ashwood@msn.com> Message-ID: <#z5BbvX$$GA.420@cpmsnbbsa08>
References: <3988EC4E.9555D120@supreme-overlord.com>
Newsgroups: sci.crypt
Lines: 49

The difference lies in the requirements for a OTP. For a OTP the
requirements are very strict, and generally unachievable. The most important
one for this discussion is that each bit of the key stream must have an
entropy content of 1 bit.

Take your favorite keyed pRNG, with a key of size k. Now let's startg the
examination under the best assumptions for the generator. Obviously for the
first bit the generator is good, after all there are k bits of entropy and
only 1 bit of pad generated. For each bit n generated, it also must consume
1 bit of entropy from the pool, so the total entropy used by getting to that
bit is n. When n=k, we have reached the limit of the key, and by encrypting
just 1 more bit we violate the rule for OTP that I gave above. That is why a
pRNG can't be used for a OTP, it's entropy pool is not infinite, so n > k is
unavoidable. Now the requirements for a stream cipher are different, and BBS
may be usable for that.
Joe

"Grant Anderson" <grant_anderson@supreme-overlord.com> wrote in message
news:3988EC4E.9555D120@supreme-overlord.com...
> I know there has been much discussion about (supposed) OTP ciphers and
> how
> most of them generally don't fulfil the OTP requirements. What I don't
> understand is why the use of the blum-blum-shub generator as the  pad
> isn't acceptable? I have read a great deal about the characteristics of
> the BBS generator and it *seems* secure as "random-number" generators
> go.
>
> Assuming that each individual has a private key pair (two large primes)
> p
> and q and a public key n such that p x q = n, then the BBS generator
> creates bits by:
>
> x(i)=x^2 mod n for each i
>
> Now obviously you can't use the same pad twice, so you would need to do
> something like having a central repository (the keyserver for example)
> which remembers the last "i" value for each user. So when you want to
> encrypt for user A, you contact the keyserver and obtain their  public
> key
> (n) and the initialisation value i and start generating from i+1....
>
> What is wrong with this solution?
>
> Cheers,
> Grant Anderson.
>
>



Terry Ritter, his current address, and his top page.

Last updated: 2001-06-12