Proof and Strength in the BB&S RNG

Terry Ritter

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: X_i+1 := X_i² 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.
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: <8mo5lk$apa$1@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: <8mo5lk$apa$1@nnrp1.deja.com>
Newsgroups: sci.crypt
Lines: 143


On Tue, 08 Aug 2000 05:26:14 GMT, in <8mo5lk$apa$1@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 <8iptlo$o3o$2@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: <8mpqhn$fca$1@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: <8mpqhn$fca$1@nnrp1.deja.com>
Newsgroups: sci.crypt
Lines: 26


On Tue, 08 Aug 2000 20:28:43 GMT, in <8mpqhn$fca$1@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: <8mt5u9$oek$1@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: <8mpqhn$fca$1@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: <8mu44q$554@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: <8mu44q$554@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: <8mvt37$pim$1@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: <8mvt37$pim$1@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: <8n6t30$hef$1@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: <8mvuln$qoq$1@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: <uAN$MRKAAHA.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: <8mpd53$kal$1@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: <8mpd53$kal$1@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: <8n6tfq$hoi$1@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: <8n6tfq$hoi$1@nnrp1.deja.com>
Newsgroups: sci.crypt
Lines: 40


On Sun, 13 Aug 2000 19:38:34 GMT, in <8n6tfq$hoi$1@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: <8n78lu$p39$1@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: <8n78lu$p39$1@nnrp1.deja.com>
Newsgroups: sci.crypt
Lines: 125


On Sun, 13 Aug 2000 22:49:35 GMT, in <8n78lu$p39$1@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: <8nahfh$5hv$1@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: <8n78lu$p39$1@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: <8n6tfq$hoi$1@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: <8mdjg9$27c$1@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: <8mdjg9$27c$1@nnrp1.deja.com>
Newsgroups: sci.crypt
Lines: 110


On Fri, 04 Aug 2000 05:14:50 GMT, in <8mdjg9$27c$1@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: <eHS$daKAAHA.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: <8mng0i$rpc$1@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: <8mng0i$rpc$1@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: <8mq27v$kdr$1@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: <8mng0i$rpc$1@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: <8naj1i$6ek$1@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: <8naj1i$6ek$1@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: <8nqo0l$m0r$1@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: <8nqo0l$m0r$1@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: <8nrp8t$s1f$1@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: <8nrp8t$s1f$1@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: <8ns0j5$5cs$1@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: <8ns0j5$5cs$1@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: <8nt07k$9rq$1@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: <8nt07k$9rq$1@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: <8nqm0c$jse$1@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: <8naj1i$6ek$1@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.84026$iI5.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: <8nqmp3$kpe$1@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: <8mn6ld$ki3$1@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
Proof and Strength in the BB&S RNG

Terry Ritter

A Ciphers By Ritter Page

The BB&S RNG

Security and Proof

Contents
