Fixing Strength Problems in Cipher Use

A Ciphers By Ritter Page

A sci.crypt conversation on fundamental problems in cryptography.

Introduction and Comments by Terry Ritter

There is no guarantee that any cipher will not fail, but we can use ciphers in ways which require multiple ciphers to fail before information is exposed.

We cannot know when our cipher has been broken, but we can use ciphers in ways which terminate any existing break and so protect our future messages.

We cannot know the capabilities of our opponents, but we can use ciphers in ways which force our opponents to make huge, continuing investments, just to keep up with us.

Introduction

In several ways, cryptography can be seen as a contest: First and most importantly, it is a contest between cryptographers and unknown opposing cryptanalysts. Next, it is a contest between "our" academic cryptanalysts and the unknown cryptanalysts. Then it is a contest between independent cryptographers and academic cryptanalysts. And, of course, it is also a contest between the academic cryptanalysts.

Seeing cryptography as contest can help clarify the uneven nature of these events.

• Cryptographers have no idea who their opponents are or what capabilities they may possess (except that they will be at least at the level of the current academic literature). Cryptographers also have no way to produce "unbreakable" ciphers, or to know the ultimate "strength" of a cipher with respect to unknown attacks. Since we do not know what our ciphers can withstand, nor what capabilities they confront, we have no way to judge the probability of cipher failure. We cannot even state that failure is "unlikely."

• Currently, cryptography depends upon academic cryptanalysis to provide a form of "validation." Cryptanalysis does provide an "upper bound" on strength: the effort involved in the current best-known attack. But our opponents are not interested in paying that expense, and they seek other ways to break our ciphers. We cannot rule out such attacks, because cryptanalysis does not tell us that any minimum amount of effort at all is required to break a cipher. Cryptanalysis does not provide a "lower bound" on cipher strength, no matter how much analysis that cipher may have had.

• Our opponents work in secrecy and presumably try very hard indeed to keep their successes secret. So even if our cipher is broken, we will not know that, and so will continue to use the broken cipher. Indeed, everyone else will also continue to use that same broken cipher, unless and until an academic cryptanalyst finds a similar attack. To the extent that our academic cryptanalysts do not find a weakness the opponents do find, they unknowingly lose face -- but we continue to use a weak cipher.

• Independent cryptographers present their cipher designs which academics occasionally bestir themselves to consider. The strongest designs do not produce academic results and so are not discussed in the literature. Designs which do have problems produce results which can be published in the name of academic fame. The literature results thus naturally show an inherent bias against independent designs, and in any case are not oriented toward improving those designs.

Trouble in Paradise

It has long been known that cryptography has very serious fundamental problems. Surely we all know that no cipher system is proven secure, yet we often think we can trust a cipher that has been around for a while. These positions are contradictory, and are examples of the "dirty little secrets" which most professionals know and ignore because it seems little can be done about them. Serious issues in cryptography include:

1. We do not know the "strength" of our ciphers
   ("Strength" is the minimum effort needed to expose protected data). Cryptanalysis does not testify to cipher strength unless it finds a "break," and then it only gives a upper bound. The lower bound is always zero: Any cipher can fail at any time.

   • We cannot "trust" any cipher
     Any trust we may have in a cipher is more self-delusion than science, based on our not being specifically told that our cipher failed. We interpret a lack of information as evidence of strength, and this is a serious error.

   • Older "seasoned" ciphers are not necessarily better
     Older, more mature ciphers are generally more trusted. They also have had more time to be attacked and broken in secret.

   • Any cipher may already be broken
     As long as our opponents do not blab that they have broken our cipher, we will probably continue to use it.

   • Having just a single cipher can lead to loss of all past and future data
     Any cipher can fail at any time.

2. We cannot know the capabilities of the opposing cryptanalysts
   If our opponents read the open literature they are at least as advanced as "our guys." But they often work for organizations which do their own research and do not share their results. Accordingly, the academic literature does not provide a rational basis for estimating the capabilities of our opponents.

   • As long as we continue to use the same cipher, we have no ability to terminate our opponents' success after they break that cipher
     And we will not be told when they do succeed.

3. We cannot estimate the chance that our ciphers may fail
   Our opponents work in secret and do not announce their successes. We know neither the number of attempted attacks, nor the number of their successes: We thus have no basis for constructing a probability of opponent success.

   • We cannot estimate failure from academic literature
     Negative academic results are generally not published: We do not know the number of attempted attacks. We also cannot extrapolate academic attacks to those mounted in secret by opponents with unknown resources.

   • Long use is not an indication of success
     We will not know when a cipher is broken for real. Ciphers in use for a long time may have been broken and ineffective for a long time.

Fix Proposals

The conversations archived here start from my proposals to "fix" some of these serious problems. They ran into a great deal of debate and dispute, apparently because these ideas run counter to the currently accepted philosophy of cryptography. Briefly, that philosophy is to have a few ciphers which are analyzed as intensely as possible; if they survive some unknown amount of time or effort, they then transition into use. And while there is a general acceptance of the idea that even well-analyzed ciphers may fail, there is a remarkable lack of protocols intended to prevent such failure, or even reduce the consequences. It appears that most professionals believe in the ciphers they use, which may be more a testimony of the intimidating role of academic cryptanalysis than of any factual basis for such belief.

Quick Entries into the Discussion

Fix Proposals

• 1999-04-02 Terry Ritter: the first fix proposal here
• 1999-04-18 Terry Ritter: a later summary
• 1999-04-19 Terry Ritter:
• 1999-04-19 Trevor Jackson, III:
• 1999-04-20 Jim Gillogly:
• 1999-04-21 Terry Ritter: including some description of how multi-ciphering would work

Note that there are repeated descriptions and arguments for this "fix package" throughout the discussion, but they do tend to be piece-by-piece rather than as a collected unit.

The Kerkhoff's Law Delusion

Kerhkoff's laws were intended to formalize the real situation of ciphers in the field. Basically, the more we use any particular cipher system, the more likely it is that it will "escape" into enemy hands. So we start out assuming that our opponents know "all the details" of the cipher system, except the key.

Part of the fix proposal is to have many different ciphers, and to select among them "at random" by a key. The particular cipher used is thus unknown to our opponents; they do know, of course, that our system uses many ciphers. And if they can simply try each possible cipher, there is not much protection (although, presumably, they could not break every cipher). But with a substantial number of ciphers (say, 1000), used in a 3-level "cascade" of multi-ciphering, we have over 10**9 different cipher possibilities. And each of these is stronger than any one cipher alone, because known plaintext and defined plaintext attacks are not possible on the individual component ciphers.

The first effect we see here is keyspace, and we already have plenty of keyspace. But the effect we really want is the partitioning and compartmentalization of our data so that a failure in one cipher means the exposure of only a small part of the data.

• 1999-04-09 Andrew Haley
• 1999-04-09 Patrick Juola

The Cipher Strength Delusion

It is well-known and universally accepted that any cipher might be weak. When ciphers have been extensively analyzed, this possibility has generally been thought unlikely. But examination of what we know and what we cannot know shows that we have no basis for estimating such a possibility: We thus have no grounds for assuming cipher failure to be "unlikely." The immediate consequence of such a realization is that we need to do something about this in real systems.

• 1999-04-16 Terry Ritter:
• 1999-04-21 Terry Ritter:

The Probability or Risk of Cipher Failure Delusion

• 1999-04-16 Patrick Juola:
• 1999-04-19 Terry Ritter:
• 1999-04-17 Terry Ritter:
• 1999-04-21 Terry Ritter:
• 1999-04-21 John Savard:
• 1999-04-21 Terry Ritter:
• 1999-04-21 Terry Ritter:

The Confidence and Trust Delusion

• 1999-04-20 Terry Ritter:

The "No Other Choice" Delusion

• 1999-04-18 H. Ellenberger:

The "Multi-Ciphering is Bad" Delusion

• 1999-04-26 Jerry Coffin:

The "It's Not What You Say, It's Who Your Are" Delusion

• 1999-04-16 Steven Alexander:
• 1999-04-17 Trevor Jackson, III:
• 1999-04-20 Terry Ritter:

Contents

• 1999-04-02 Terry Ritter: "One of the facts of ciphering life is that we cannot prove the strength of any cipher. Even NIST review and group-cryptanalysis does not give us proven strength in a cipher, so any cipher we select might be already broken, and we would not know. We cannot change this, but we can greatly improve our odds as a user, by multi-ciphering under different ciphers."
• 1999-04-02 Boris Kazak: "And how about a 'variable' cipher?"
• 1999-04-04 Lincoln Yeoh: "I'd go further- by having layers of many and not just 3 layers of encryption, and each layer not leaking any headers at all, the attacker's work will be very much harder, even if each layer is just 40 bit crypto."
• 1999-04-09 Andrew Haley: "Kerckhoff's maxim says that your attacker knows the cryptosystem you're using, but does not know the key. If you're using superencryption, your attacker knows which systems you're using."
• 1999-04-09 Terry Ritter: ". . . if the ciphers are dynamically selected by keying, or just dynamically selected frequently by communications under cipher, the attacker does *not* know "which systems you're using." Kerckhoff's maxim does not apply."
• 1999-04-09 Patrick Juola: "If you are taking a set of cyphers and reordering them, Kerchoff's maxim suggests that you have to assume that the attacker knows the set of cyphers and just doesn't know the order."
• 1999-04-09 Boris Kazak: "It all depends on the numbers in question."
• 1999-04-09 Terry Ritter: "Every cipher is only 'known' to the Opponents after they have identified it, acquired it, analyzed it, and, presumably, broken it. All this necessarily takes time, and this time works for the user and against the attacker."
• 1999-04-9 Harvey Rook: "By Kerchhoff's maxim, you have to assume your attacker has a copy of your deciphering machine. If he has a copy of your deciphering machine, the attacker can figure out the algorithm you use to select ciphers."
• 1999-04-09 Terry Ritter: "That is no more true than saying that the attacker can figure out the message key or the initialization vector. We assume the system has some reliable random source to make such values. Similar values select what ciphers to use in what order. And this should change frequently."
• 1999-04-9 Harvey Rook: "The reliable random source must be communicated to both the encryptor, and the decryptor. Because it's transmitted or shared, you must assume the attacker has intercepted it. Because the attacker has intercepted the it, the attacker knows what ciphers you are using." "Which would you rather trust, one well analyzed cipher with 140 bits of key, or 4096 ciphers that probably aren't well analyzed, 128 bits of key, and some mechanism to flip between the ciphers."
• 1999-04-10 Terry Ritter: "That is false. It is always necessary to transport keys in some way. But whatever way this is done -- by courier, multiple channels, or authenticated public key -- random message key value are known by both ends. That keying value can be used to select ciphers." "I take the 4096 ciphers, and I have explained why: First, the multi-cipher situation forces any Opponent whatsoever to keep up in a process which is vastly more expensive for them then for us. Next, we divide our total traffic among many different ciphers. So even if an Opponent breaks a cipher, the best they can hope for is 1/n of the traffic. And in the multi-ciphering case, they don't even get that."
• 1999-04-12 ssimpson@hertreg.ac.uk: "Make the cipher selection(s) dependant on additional key material?"
• 1999-04-09 Boris Kazak: ". . . what if we would initialize BLOWFISH not with the digits of 'pi', but with some other constant - e, sqrt(2), sin(1)...? How many different ciphers can we generate from the same base algorithm . . . ."
• 1999-04-12 ssimpson@hertreg.ac.uk: "Why not make cipher selection for the compound cipher part of the key?"
• 1999-04-12 Jerry Coffin: "If you're going to include code for a number of forms of encryption, from a viewpoint of security, you might as well just always use ALL the forms of encryption supported . . . ."
• 1999-04-22 Matthew Skala: "Speed."

• 1999-04-16 Sundial Services: "When I look at most publicly-available cryptographic algorithms, I see that nearly all of them consist of round upon round of simple operations . . . ."
• 1999-04-16 John Savard: ". . . an academic researcher isn't going to take time studying a cipher that is so big and complicated that there is no hope of coming away with an impressive result . . . ." ". . . what gives real confidence in a cipher design is that it has been studied by experts who have failed to crack it . . . ."
• 1999-04-16 Terry Ritter: "The truth is that we never know the 'real' strength of a cipher." "Any cipher can fail at any time."
• 1999-04-16 Steven Alexander: "If I(a nobody) create a new cryptosystem tommorrow, nobody will have any confidence in it." "Only after many people have analyzed and failed to break my cipher will people say..."his cipher has held up to five(ten) years of cryptanalysis by very knowledgeable cryptanalysts. We can assume with an adequate level of confidence that the cipher will protect our information.'"
• 1999-04-16 Terry Ritter: "The issue is not who makes a thing, but instead what the thing actually is." ". . . without a LOWER bound on strength, academics REALLY do not even know that ciphers work *at* *all*, let alone how." "Unfortunately, when we use a cipher, we are very rarely concerned whether academics can break our cipher or not."
• 1999-04-16 Steven Alexander: "We can however put more trust into an algorithm that has undergone more cryptanalysis and has been tested against the newest cryptanalytic techniques because we know what will not break the cipher."
• 1999-04-16 Terry Ritter: "Nope. Simply because 'we' cannot break it does not mean that others cannot break it."
• 1999-04-16 Steven Alexander: "What exactly is your suggestion for the creation of a cipher in which we can place our trust?"
• 1999-04-17 Terry Ritter: "Absent a theory or overall test of strength, there can be no trust in a cipher. All the trust one can have is delusion." ". . . the real issue is that while supposedly everyone knows that any cipher can be weak, there has been essentially no attention given to protocols which deal with this problem."
• 1999-04-18 John Savard: "A cipher should be designed conservatively . . . in the sense of having extra complexities in its design far beyond those needed . . . to frustrate known methods of attack."
• 1999-04-18 wtshaw: "A good trick is to telescope complexities into new primatives if you can."
• 1999-04-17 ybizmt: "Refresh my memory. What do you sell?"
• 1999-04-17 Terry Ritter: "Just the truth, lately."
• 1999-04-18 John Savard: ". . . choosing a cipher from a respected source is not 'superstition', and it is the kind of choice people make all the time: i.e., when shopping for a new computer."
• 1999-04-20 Terry Ritter: ". . . this situation is not a technical discussion between people of expertise but, rather, ordinary users who really have no choice but to rely upon promotion and rumor."
• 1999-04-20 wtshaw: "I wonder if the FTC has a role in determining if claims are reasonable. They would have to yield to NSA for expertise? Perhaps we can try to shift burden directly to government to prove strength, therefore making them show their hand."
• 1999-04-17 wtshaw: "What matters is whether a cipher is good, and it will be so regardless of confidence bestowed by some select group fixated on a remarkedly few, perhaps some wrong, design criteria."
• 1999-04-17 Trevor Jackson, III: "There's a name for this attitude. It's called the Aristotelean Fallacy -- the appeal to authority."
• 1999-04-18 wtshaw: "Maturation is not the enemy of creative, but wheeler-dealer, power-sponges, who imagine that everyone else must follow their lead, are."
• 1999-04-21 Leonard R. Budney: "When rigorous proof is not available, then the opinion of an expert constitutes the best information to be had."
• 1999-04-22 Sam Simpson: "Actually, certain instances of RSA cannot be equivalent to the underlying IFP (D.Boneh, R.Venkatesan, 'Breaking RSA may not be equivalent to factoring')."
• 1999-04-16 Patrick Juola: ". . . you're committing a grievious error if you think that something doesn't exist merely because you can't quantify it."
• 1999-04-16 Terry Ritter: "The issue is not the 'formalization' of something we know but cannot quantify, but rather something we actually do not know." ". . . you would have us assume that everyone knows that ciphers may be weak, and simply chooses to do nothing about it."
• 1999-04-17 ybizmt: "Nice rant. Where are you going with this and how does it sell your product?"
• 1999-04-17 Terry Ritter: "This is my bit for public education." "I have no modern products. I do offer cryptographic consulting time, and then I call it as I see it. I also own patented cryptographic technology which could be useful in a wide range of ciphers."
• 1999-04-18 John Savard: ". . . I think you can see why this design process actually increases the probability of a design which is strong against known attacks, but weak against a future attack someone might discover."
• 1999-04-18 John Savard: ". . . I do think that in the specific case of the AES, going back to the drawing board a bit would make quite a bit of sense. . . ."
• 1999-04-20 Terry Ritter: "You lost me on that one."
• 1999-04-21 John Savard: ". . . the cryptanalyst will find what he knows how to look for; and so, weaknesses beyond the reach of current cryptanalysis won't be found . . . ."
• 1999-04-21 Terry Ritter: "I claim the main use of cryptanalysis is in the give and take of a design process, not the end game of certification, which is what cryptanalysis cannot do."
• 1999-04-17 Patrick Juola: "I don't have proof that Pittsburgh won't be hit by a hurricane, but I can produce lots and lots of justification."
• 1999-04-17 Terry Ritter: "Which means to me that you have some understanding of the risk of hurricanes in Pittsburgh. You get this understanding from reported reality." "Unfortunately, neither you nor anyone else can have a similar understanding of the risk of cipher failure -- there is no reporting of cipher failure. There is instead every effort made to keep that information secret, and in fact to generate false reporting to buoy your unfounded delusion of strength."
• 1999-04-01 John Savard: ". . . what do we do if there is no way to obtain a lower bound on the strength of a cipher?" "Then it does make sense to look at the upper bound . . . ."
• 1999-04-20 Terry Ritter: "No. Completely false. I see no reason why the upper bound should have any correlation at all to the lower bound."
• 1999-04-21 John Savard: "Any security audit will have to include a disclaimer that the true security of the cipher systems used is essentially unknowable, but even real-world financial audits do routinely include various sorts of disclaimer."
• 1999-04-21 Terry Ritter: "We don't have financial disclaimers which say that the audit is 90 percent certain to be correct, which is the sort of thing you might like to think that cryptanalytic certification could at least do . . . ."
• 1999-04-21 John Savard: "Precisely because . . . we don't have a way to put a good lower bound on the effort required to break a cipher, I find it hard to think that I could achieve the goal . . . of making it 'as simple as possible, but no simpler'"
• 1999-04-17 wtshaw: "It's aways difficult to stop a wave, be it composed of hoards of combatants or algorithms."
• 1999-04-19 John Savard: "I agree with you that we don't have a way to prove that a cipher really is strong. But cryptanalysis still gives the best confidence currently available."
• 1999-04-20 Terry Ritter: "I guess I dispute 'confidence.' Confidence and Trust and Reliability are exactly what we do not have. I cannot say it more clearly: cryptanalysis gives us no lower bound to strength." "'Never underestimate your opponent.'"
• 1999-04-20 Mok-Kong Shen: "'There are no provable lower bounds for the amount of work of a cryptanalyst analyzing a public-key cryptosystem.'"
• 1999-04-23 Bryan G. Olson; CMSC (G): "This impression of the academic crypto community as a closed club that ignores the work of outsiders is flat out false." "The various attacks I've heard on academics are invariably by those whose work is simply not of the same caliber."
• 1999-04-23 John Savard: ". . . cryptography, like many other fields, has its cranks and quacks. "However, I don't think it's appropriate to automatically conclude that everyone who expresses concern about the way in which the public cryptography field is going is necessarily a crank."
• 1999-04-25 Bryan G. Olson; CMSC (G): "My counter is not the crypto community is right to generally ignore outsiders, but that in fact they do no such thing." "There is a situation worse than having all one's eggs in one basket." "What's worse is a system in which any one of many possible failures would be catastrophic."
• 1999-04-25 Sundial Services: "If you look at the design of these Feistel ciphers, well, to me they smack of Enigma, with its clockwork-like rotation of the cipher elements which ultimately proved its downfall."
• 1999-04-25 Sundial Services: "The layers in SIGABA are not all the same design. The layers in an n-round Feistel cipher are, literally by definition, all the same."
• 1999-04-25 Matthias Bruestle: "a 200kbit key would require about . . . 10 CPU hours. Would you want to wait 10 hours to read an email?"
• 1999-04-25 wtshaw: ". . . using several algorithms, it is reasonable to maximize security available not by living in fear of the weakest algorithm but working to make sure the strongest was included."
• 1999-04-24 wtshaw: ". . . specific information between individuals is not apt to pass but once or few times at the most."
• 1999-04-16 Medical Electronics Lab: "Some things which look really simple can have very complex mathematical relationships, and that's far more useful to a cipher design than something which appears complex but has a simple mathematical construction."
• 1999-04-17 wtshaw: "Then there are those designs that tend to impress people because they are overly complex in construction and perhaps made so for devious purposes."
• 1999-04-16 Boris Kazak: ". . . most published attacks against various ciphers are essentially attacking not as much the cipher per se, as its key schedule." "As a layman, I experimented with modular multiplication mod 2^32-1 and mod 2^32+1 . . . ." "BTW, I also experimented with multiplication mod 2^64+1 and 2^64-1."
• 1999-04-19 Jerry Coffin: ". . . 2^32-1 happens to be a prime number." "By contrast, 2^64-1 is what you might call extremely composite . . . ."
• 1999-04-19 Boris Kazak: "Sorry, 2^32-1 = 3*5*17*257*65537, but I have found nice ways to set up key-derived multipliers in this field. The maximum length of the multiplicative cycle is 65536 . . . ."
• 1999-04-20 Jerry Coffin: "Oops -- my bad. It's 2^31-1 which is a prime."
• 1999-04-20 Boris Kazak: "It is one of my 'essays' on the subject of *drunken* ciphers, where you set up a lot of S-boxes deriving them from the key, and then encrypt using the plaintext-dependent path through these S-boxes."
• 1999-04-20 Paul Rubin: "2^32-1 = . . . = 65537 *257 *17 *5 *3"
• 1999-04-17 wtshaw: ". . . cooperating to plow and plant the same furrow does not make lots of sense."
• 1999-04-17 Bruce Schneier: "Operations from the RISC subset are efficient on a wide variety of microprocessors."
• 1999-04-18: John Savard "Think FROG."
• 1999-04-18 wtshaw: "As I remember, the final pick is to be submitted to higher, political, authority for *approval*, which is apt not to be a technical decision based on purely scientific considerations."
• 1999-04-18 wtshaw: "You know, something easy to do knowing the key, and impractical not knowing it."
• 1999-04-18 wtshaw: "End decisions are to be made by political cronies."
• 1999-04-17 David A Molnar: "Most of the provable security I've seen comes in terms of statements like 'if this scheme is breakable, then factoring integers is easy . . . .'"
• 1999-04-17 Douglas A. Gwyn: "Simpler systems are, usually, easier to analyze more thoroughly. The more thoroughly we understand a class of systems, the more confident we can be that other analysts won't find some shortcut."
• 1999-04-17 Douglas A. Gwyn: "That is the reason for 'tiger teams', who act the part of bad guys. If your system hasn't been attacked by cryptanalysts who know *how* to mount such an attack, then it hasn't undergone sufficient Quality Control."
• 1999-04-17 Terry Ritter: "Even so, we still don't know that their guys aren't better, or even just luckier." ". . . if the goal was to get the best cipher, we would see a post-analysis re-design phase intended to fix known problems, with the final comparison being made between full-strength designs."
• 1999-04-18 wtshaw: "It would seem that the best use of the talent involved in the AES process would be to identify any new techniques that might have crept in, and see how these could be used to supplement the best of whatelse we know."
• 1999-04-17 Douglas A. Gwyn: "How could the design be conveyed to the implementor, then?"
• 1999-04-18 Douglas A. Gwyn: "The technical decision would already have been made, and any further process would be simply an approve/disapprove decision."
• 1999-04-18 H. Ellenberger: "Should we therfore stop analyzing existing ciphers?"
• 1999-04-18 Terry Ritter: "No. We should stop depending on any small set of ciphers, no matter how well analyzed."
• 1999-04-17 dscott@networkusa.net: ". . . you are right that most encryption methods use operations that are readily reversible. That is one reason I use as large an S-table that is possible in my encryption programs."
• 1999-04-18 wtshaw: ". . . the one thing that you highlight is something that perhaps is the biggest weakness in the utility of what you have done."
• 1999-04-18 dscott@networkusa.net: ". . . wrapped PCBC would add the 'all or nothing logic' to the AES candidates as well as solve the problem of handling files or sub files that are not made up of a number of bits that are a muliply of the block cipher size used."
• 1999-04-18 wtshaw: "There may be a fix to what you have done, making your encryption more acceptable to me, but you may not like the idea at first."
• 1999-04-19 dianelos@tecapro.com: "Whether you use simple or complex operations to describe a cipher is not relevant: a multiplication can be seen as a sequence of SHIFTs and ADDs . . . ."
• 1999-04-19 John Savard: "I think he was asking why block ciphers weren't more like FROG!"
• 1999-04-21 SCOTT19U.ZIP_GUY: "I think if one used a fixed block size of any size say 512 bytes. Then it would be easyer to study the cipher for its weak points."
• 1999-04-22 tomstdenis@my-dejanews.com: "If you had for example 24 rounds you could have 6 different P and S functions, each with 4 stagered rounds each."
• 1999-04-22 dianelos@tecapro.com: "I have often expressed the opinion that the biggest security risk in cipher design is the possible discovery of a catastrophic attack method against cipher designs considered strong today."
• 1999-04-22 John Savard: ". . . if we consider acceptable a design that was initially weak against known attacks, but which was modified later specifically to resist them, then we are . . . more likely to fall prey to *new* attacks than we would be with a design that was resistant to the known attacks right from the start."
• 1999-04-22 SCOTT19U.ZIP_GUY: "The AES contest is not about having secure encryption. The NSA would never allow a good common method to be blessed by the government for general use."
• 1999-04-24 wtshaw: "The best thing to be is open and honest, something government does not particularly like to do as it limits arbitrary power."
• 1999-04-25 wtshaw: ". . . if you only learn a few selected crypto primatives, those are the ones you are apt to utilize."
• 1999-04-25 bryan.olson@uptronics.com: "I (Bryan) only wrote that in quoting its author, John Savard."
• 1999-04-26 dianelos@tecapro.com: ". . . a good variable cipher protocol would hide the information about which cipher or cipher combination has been used."
• 1999-04-26 Jerry Coffin: ". . . when you combine two algorithms, you're basically designing a new cypher. If you're lucky, it'll combine the strengths of both the base cyphers, while negating some of the weaknesses of each."
• 1999-04-27 Trevor Jackson, III: "Can you show a real example? Are there any known weaknesses in combining any pair of the following: Blowfish, IDEA, 3DES?"
• 1999-04-27 Jerry Coffin: "Of course there are real facts. I've demonstrated how one trivial example shows up poorly . . . ."
• 1999-04-28 dianelos@tecapro.com: "Cascading ciphers does increase security in this sense. Schneier discusses this method in chapter 15.7 of the second edition of Applied Cryptography. There are also two papers by Maurer discussing the combination of block ciphers and of stream ciphers."
• 1999-04-17 Douglas A. Gwyn: ". . . if your tiger team is really good and experienced . . ., you can attain a certain degree of confidence based on their positive evaluation . . . ."
• 1999-04-18 Uri Blumenthal: "At least one publicly known cipher (GOST) uses ADD (a more complex operation)..."
• 1999-04-17 Douglas A. Gwyn: ". . . treating the whole message would be a problem in many applications where data is generated in a stream, for example a TELNET session."
• 1999-04-17 Geoff Thorpe: ". . . good ideas can quickly get buried in slop, or just unmasked as reactionary drivel as they seem (IMHO) to in Mr Ritter's post below ..." "I disagree - your point of view has some merit but is no more valid than the polar opposite statement." ". . . thousands of hobbyists and professionals all doing their damndest to break each others ciphers gives me personally some confidence in the value of 'standing the test of time'."
• 1999-04-17 Terry Ritter: "The strength value measured on academics cannot apply to the real problem." "I have shown several different approaches which are helpful for security even in an environment where we cannot assure ourselves of the strength of any particular cipher." "You do not know the probabilities, and you do not know the risk, yet you would have us manage the situation using exactly these quantities. That is mad." ". . . our Opponents operate in secrecy. That means we actually do not know when our ciphers fail. But unless we know about failure, we cannot assess risk." ". . . it is openly argued that 'uncertified' ciphers have more risk, without being able to quantify that risk. While I would hope every cipher would get as much analysis as it could get, the 'certification' of one cipher does not give us what we need."
• 1999-04-18 Douglas A. Gwyn: "Just so you know, I appreciate your work and especially your making useful information available via the Web."
• 1999-04-18 Terry Ritter: "Coming from you, that means a lot. Thanks."
• 1999-04-20 John Savard: "I will take the opportunity to acknowledge both that you have made contributions through your own work, as well as by representing a point of view that points in the direction of what I, also, feel is a correction needed by the cryptographic community."
• 1999-04-20 Terry Ritter: "I think it should be very disturbing to anyone actually trying to do Science to have to consider whether or not the conclusions they come to are a 'minority position.'"
• 1999-04-18 ovbxotm: "Guess its time to add an entry to my killfile."
• 1999-04-18 Geoff Thorpe: "Abstract, extremist, conspiracy-theoretic poppycock." "I don't agree but I can't PROVE you wrong. It does not mean you're right - and many people share MY point of view on this." "Do you insure your car? Do you know the probabilities or the risk? I take a look at my driving, most others' driving, the risk . . . and make a judgement call." "I certainly have no time for such cold-war style conspiracy theories - that somehow the knowledge present in military/intelligence agencies . . . is probably so . . . disimilar to what is available in the open as to make work, developments, and failures (to break ciphers) in the open completely irrelevant . . . ."
• 1999-04-19 Douglas A. Gwyn: "For many perfectly decent people, their own governments can become their enemies; history gives us many instances of this. "While the cryptanalytic bureaus of most third-world countries might not be very advanced, the one in the US certainly is."
• 1999-04-19 Geoff Thorpe: ". . . I was just taking issue with what I perceived to be the following idea: Until we actually break it, or *prove* it secure, we have no more measure of strength for it than for another (less 'investigated') one. I feel that quite the opposite is true - it IS a very appropriate statistical measure of strength, and moreover the only realistic one we have to work with."
• 1999-04-19 Terry Ritter: "In summary: 1) We cannot estimate the probability that an effective attack exists which we did not find; and 2) We cannot estimate the probability that even if such an attack does exist, our Opponents can find it and use it. I thus claim that we CAN know nothing of the probability of future cipher failure, and cannot even reason that this probability is 'small.' The practical consequence of this is that we cannot trust any cipher." "With respect to the problem of potential catastrophic failure from a single-cipher system, no amount of cryptanalysis can prevent such failure. Both untested ciphers and massively-tested ciphers are the same in the sense that neither can be trusted."
• 1999-04-21 Earth Wolf: "I'll trust DES a heck of a lot more than I trust ROT-13. And I'll trust 3DES a heck of a lot more than I trust DES." ". . . basic cryptography involves making your best estimate of your opponents' capabilities and desiging a cipher which, to the best of your knowledge, will be impervious to those capabilities for as long as it needs to be."
• 1999-04-21 Terry Ritter: "My position is that no rational extrapolation of past tests to future strength is possible. The lack of literature containing such a thesis is consistant with my position, and inconsistant with the alternative." "My guess would be that you "trust" DES because nobody has openly demonstrated that they can break it. So if you worry that your information will be stolen by academics, you *can* have some reasonable degree of trust in DES. "But if you use cryptography to protect your information from those who operate in secret and hide their successes, you have no data upon which to base trust." "Basic *social* cryptography . . . must concern itself with every non-military use for hiding data. "From this I conclude that the use of a single standard cipher throughout society would be an unthinkable risk."
• 1999-04-21 John Savard: "Here, you and I are in agreement. New attacks are being found against symmetric block ciphers, such as the boomerang attack and the slide attack. Also, one of the papers on the NIST site is called 'Future Resiliency', and it is a defense of that point of view."
• 1999-04-23 Douglas A. Gwyn: "The Japanese cleverly misled our intelligence analysts into believing that their fleet was still in home waters."
• 1999-04-19 Douglas A. Gwyn: "Generally speaking, Terry is right to be concerned over the unknown, but some risks are greater than others. The specific algorithms you mentioned previously are among the better risks."
• 1999-04-19 David A Molnar: ". . . it was known that knapsack public-key systems leaked bits of information long before any specific catastophic results were known. The single bit doesn't help much, but acts as a warning sign that something is wrong."
• 1999-04-20 Trevor Jackson, III: "Layered algorithms do not dictate expensive or complex operational requirements. The implementation of a layered cipher needs some care, but no more than any other secure system. This issue appears to be a red herring."
• 1999-04-20 Geoff Thorpe: "I may not design ciphers but I can definately slug it out with most people regarding probability theory, statistics, and logic. I also have to assist with various API designs and have been on the (l)using end of quite a few if we want to talk standards, picking algorithms, and covering butts (oh yeah, I've done quite a bit of Risk Management related stuff too)."
• 1999-04-20 Terry Ritter: "Recall that my position does not rest upon an estimation of someone else's capabilities. It is not my *opinion* that any cipher we have *might* possibly break -- that is fact. I assume the worst case, and propose systems to provide strength even then. "Your position, dare I state it, is that you *can* estimate the capabilities of your Opponents. You also say you can estimate the future strength of a cipher from past tests. But for all this claiming, we see no similar statements in the scientific literature. So these are simply your opinions, and I see no supporting facts."
• 1999-04-20 Geoff Thorpe: ". . . you assume the worst case. Whilst you certainly will never be accused of lacking precaution, why should I accept that your position the only appropriate one to adopt?" ". . . I still place a lot of stock in what *I* rank as ciphers of tested strength and wouldn't want any system of mine having too many 'new toy' ciphers creeping in." ". . . I have already said that my view (that a cipher not falling over despite some considerable efforts against it does merit some 'value') is not based on any exact science." "And in case you ask, no - I know of NO research paper to support this and have no interest in attempting to create some when I'm already satisfied."
• 1999-04-21 Terry Ritter: "In this case I agree with virtually the entire body of cryptanalytic literature in that one CANNOT know cipher strength. I also think it is fruitless to speculate on strength, or on the capabilities of our Opponents, and that we are better of spending our time protecting against failures which cryptanalysis cannot avoid." ". . . my 'contrary opinion' -- that the past history of the strength of a cipher does NOT tell us about its future strength -- again reflects the scientific literature. I am aware of no articles at all that show such a correlation. That is not *my* opinion, that is the prevailing scientific understanding." "In crypto, we do not have the same cues which support our understanding of risk in real life." "My point is precisely that cryptanalysis ("breaking") *cannot* tell us if a cipher is weak. My point is that we must assume weakness *without* having to break the cipher, if failure would be disastrous. Since that is my point, I hardly need do the opposite to make my argument." "I think unscientific arguments *would* be called 'incorrect.' You assume something trivial like extrapolating the strength of a cipher from its cryptanalytic testing -- something which does not exist in the scientific literature. "In contrast, I assume that any cipher may fail -- and this is the nearly universal scientific understanding. I would call that correct." "It is more than a matter of disagreement; it is a matter of you being wrong." "Will you find a cipher designer who will say in so many words that he or she *can* predict the strength of a cipher based on its cryptanalytic history? Will you find someone who will say they can predict the capabilities of future Opponents based on current academic results? I don't think so." "I support all the cryptanalysis we can get. But, in the end, we can trust neither cipher to remain unbroken. So, in that sense, new and old ciphers are both equal in their untrustability."
• 1999-04-21 Geoff Thorpe: ". . . if you are right, you need to find a better way of understanding my view and showing me constructively why it is definitively wrong if you want to get anywhere."
• 1999-04-22 John Savard: "While there will be pressure to adopt the standard ciphers for interoperability, such a system definitely does allow for a new cipher to become a new part of the set."
• 1999-04-20 Jim Gillogly: "I think Terry Ritter's right to be concerned about having essentially everyone move to a single new cipher." "I also agree with him that a careful concatenation of ciphers can help limit the damage." "However, I (like John Savard) think Terry overstates some issues." "These and similar remarks suggest that a conservative threat analysis must regard the opponents as god-like in their cryptanalytic capabilities."
• 1999-04-21 Terry Ritter: "As far as I can recall, the only people I have accused of being 'god-like' are the crypto gods who seem to be able to predict: 1) the future strength of a cipher, based on past tests; and 2) the capabilities of unknown Opponents, based on the capabilities of known academics." "But what *are* we to assume? Even a *modest* "value" for Opponent capabilities is also "not useful" to us." "So we first don't know the difficulty of the problem, and then don't know the capabilities our Opponents can bring to the solution." "I suggest that this whole line of inquiry (into cipher strength and Opponent strength) is a waste of time."
• 1999-04-20 Jim Gillogly: ". . . you can't expect to get expert analysis for free... ."
• 1999-04-21 Terry Ritter: ". . . you should agree that each user should have a similar power to make their own choices of cipher. That sounds just fine to me."
• 1999-04-21 Jim Gillogly: "We have wider areas of agreement than disagreement; I'm happy to leave it at that."
• 1999-04-21 Trevor Jackson, III: "Some clarification may be called for in that your statements can be construed as claims that cipher diversity solves the problem of inferior talent/resources/etcetera with respect to dark-side adversaries and future adversaries of all shades. I believe this absolutist position to be false."
• 1999-04-21 Terry Ritter: "I am not sure that I have made such a claim, which I also think is false." "I don't know what could be clearer than my repeated statement that we can trust no cipher. Cipher use cannot build trust in strength. Cryptanalysis cannot certify strength. We must always be aware that failure is a possibility, and we are even unable to estimate that probability. When the consequences of cipher failure are catastrophic, we simply cannot afford to depend on any one cipher."
• 1999-04-21 Trevor Jackson, III: "There's no need to assume perfection or god-like omniscience to motivate as conservative an approach as possible."
• 1999-04-20 Trevor Jackson, III: "Given that there are few ciphers that have survived "the gauntlet" for a respectable period of time compared to the many ciphers without that maturity, the odds look to me much as Ritter described them. If I pick a young cipher, it may be broken tomorrow. If I pick an elderly cipher it may be broken tomorrow." "The situation we face is that we have dozens of reasonably strong ciphers, whose relative strengths are immeasurable. We may theorize about their relative merits, but we can't measure their strength in any fundamental sense. Given this I believe it makes sense to reduce risk of catastrophic failure by using a composite of the strongest ciphers of which we are aware."
• 1999-04-25 H. Ellenberger: "If science could prove that a certain feasible algorithm is unbreakable, everybody could use it and there would be no need for annother one (and probably this algorithm would be a intelligent combination of various principles)." "Without such a proved algorithm it is indeed too risky to use a single algorithm. It is exposed to focused attacks from all sides, and in case it sould break, damages are too important."
• 1999-04-25 Geoff Thorpe: "I don't know if you were following the thread but I was just saying that certain established and unbroken (despite plentiful attempts) ciphers are worthy of more 'trust', 'strength', 'tested strength', 'confidence' or whatever than new-toy ciphers."
• 1999-04-19 Terry Ritter: "I spent some hours responding to this huge article, and only at the end realized (I assume correctly) that most of the controversy was about something which I consider peripheral to the main issue." "My main argument starts out that no matter how much analysis is done, there is always the possibility that a cipher may fail anyway. I doubt anyone disagrees with this." "Since cipher failure is possible, we need to look at the consequences of failure: If this is to be the one standard cipher for society, the results of such failure would be catastrophic. Again, hardly controversial stuff." "We can do something about this: We can innovate various procedures and protocols to avoid single-cipher failure. As a general concept, it is hard to imagine that even this is controversial. The actual technical details, of course, are arguable and changeable." "The package I have proposed includes compartmentalizing our data under different ciphers, thus reducing the amount of data at risk of any single cipher failure. (This virtually requires us to change ciphers frequently.) I also proposed multi-ciphering as a matter of course (reducing the likelihood of failure), and having a growing body of ciphers from which to choose. Other proposals can of course be made."
• 1999-04-19 Trevor Jackson, III: "I rise (type) to speak in support of the proposition." "The tendency of the market to focus on a single (or few) best product(s) is well established. The true operational basis for this is most often simple laziness."
• 1999-04-19 Gurripato (x=nospam): "There must be some reason why a product is well established, not necessarily quality."
• 1999-04-20 Trevor Jackson, III: "You are certainly free to disagree with the marketing theory that says mature markets are better. After all, I disagree with it too." "I find it especially unsuitable for the field of crypto."

Subject: Re: Announce - ScramDisk v2.02h
Date: Fri, 02 Apr 1999 19:03:38 GMT
From: ritter@io.com (Terry Ritter)
Message-ID: <3705141b.4312658@news.io.com>
References: <7e2vge$o82$1@nnrp1.dejanews.com>
   <7e2br4$7i3$1@nnrp1.dejanews.com>
Newsgroups: alt.security.pgp,sci.crypt
Lines: 58


On Fri, 02 Apr 1999 17:41:35 GMT, in
<7e2vge$o82$1@nnrp1.dejanews.com>, in sci.crypt ssimpson@hertreg.ac.uk
wrote:

>[...]
>The point of that section of the document was that an adversary is not aware
>of which algorithm you use....They have no method of detecting whether TEA,
>Blowfish, IDEA, 3DES etc is used.  Both PGPDisk & Bestcrypt plainly state the
>algorithm employed.
>
>So, to "brute force" a ScramDisk container an adversary has to effectively
>try all 10 ciphers, whereas to brute force other products containers they
>only have to try 1 cipher.  Is this snake oil?	No.

For some years I have been promoting the idea of using multiple
ciphers, but my argument is different:

1.  I see little keyspace (brute-force search) advantage with just a
few ciphers.  If we had a robust industry of replaceable cipher
modules, with tens of thousands of possibilities and growing all the
time, *then* we get some keyspace.  But with just 10 ciphers, the
keyspace advantage is lost in the noise of attacks which need 2**43
known-plaintexts.

2.  The big advantage of having a huge number of ciphers is the burden
it places on any Opponent, who necessarily must keep up.  Opponents
must distinguish each cipher, obtain it, break it, then construct
software and perhaps even hardware to automate the process.  Given a
continuous production of large numbers of new ciphers, I believe that
"keeping up" must have a terrible cost that not even a country can
afford.  

3.  The risk of using a single popular cipher (no matter how
extensively analyzed) is that a vast amount of information is
protected by one cipher.  This makes that cipher a special target -- a
contest with a payoff far beyond the games we normally play.  I think
we want to avoid using such a cipher.  

4.  To make the cost of multiple ciphers real, we cannot keep using
the same cipher, but instead must use different (new) ciphers
periodically.  We will want to use the same cipher-system, so our
system must support "clip-in" modules for ciphers which have not yet
been written.  

5.  One of the facts of ciphering life is that we cannot prove the
strength of any cipher.  Even NIST review and group-cryptanalysis does
not give us proven strength in a cipher, so any cipher we select might
be already broken, and we would not know.  We cannot change this, but
we can greatly improve our odds as a user, by multi-ciphering under
different ciphers.  Doing this means an Opponent must break *all* of
those ciphers -- not just one -- to expose our data.  I like the idea
of having three layers of different cipher, each with its own key.  

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


Subject: Re: Announce - ScramDisk v2.02h
Date: Fri, 02 Apr 1999 18:37:41 -0500
From: Boris Kazak <bkazak@worldnet.att.net>
Message-ID: <370554C5.156E@worldnet.att.net>
References: <3705141b.4312658@news.io.com>
Newsgroups: alt.security.pgp,sci.crypt
Lines: 65

Terry Ritter wrote:
> 

> >The point of that section of the document was that an adversary is not aware
> >of which algorithm you use....They have no method of detecting whether TEA,
> >Blowfish, IDEA, 3DES etc is used.  Both PGPDisk & Bestcrypt plainly state the
> >algorithm employed.
> >
> >So, to "brute force" a ScramDisk container an adversary has to effectively
> >try all 10 ciphers, whereas to brute force other products containers they
> >only have to try 1 cipher.  Is this snake oil? No.
>  /...../
> 2.  The big advantage of having a huge number of ciphers is the burden
> it places on any Opponent, who necessarily must keep up.  Opponents
> must distinguish each cipher, obtain it, break it, then construct
> software and perhaps even hardware to automate the process.  Given a
> continuous production of large numbers of new ciphers, I believe that
> "keeping up" must have a terrible cost that not even a country can
> afford.
--------------------
    And how about a "variable" cipher? The one which philosophy will
be based on 
            1. a *big* number of key-derived S-boxes
            2. a plaintext-dependent sequence of invocation
               for these S-boxes.
    In case where there will be enough plaintext-dependent variability,
no two plaintexts will be encrypted along the same sequence. This 
will be essentially equivalent to adding the plaintext space and the 
key space together. With all the additional effort for the attacker.
-----------------------
> 
> 3.  The risk of using a single popular cipher (no matter how
> extensively analyzed) is that a vast amount of information is
> protected by one cipher.  This makes that cipher a special target -- a
> contest with a payoff far beyond the games we normally play.  I think
> we want to avoid using such a cipher.
> 
> 4.  To make the cost of multiple ciphers real, we cannot keep using
> the same cipher, but instead must use different (new) ciphers
> periodically.  We will want to use the same cipher-system, so our
> system must support "clip-in" modules for ciphers which have not yet
> been written.
------------------------
  A long overdue problem - standard cipher-to-application interface.
------------------------
> 5.  One of the facts of ciphering life is that we cannot prove the
> strength of any cipher.  Even NIST review and group-cryptanalysis does
> not give us proven strength in a cipher, so any cipher we select might
> be already broken, and we would not know.  We cannot change this, but
> we can greatly improve our odds as a user, by multi-ciphering under
> different ciphers.  Doing this means an Opponent must break *all* of
> those ciphers -- not just one -- to expose our data.  I like the idea
> of having three layers of different cipher, each with its own key.
> 
------------------------
   Have a little pity for the export bureaucrats! They are kind enough
to allow exporting three different ciphers, and now you want to use 
their kindness to show all the world that their export regulations
can be circumvented and that they are not worth the paper they are 
printed on.
> ----------------------
> Terry Ritter   ritter@io.com   http://www.io.com/~ritter/
> Crypto Glossary   http://www.io.com/~ritter/GLOSSARY.HTM

    Best wishes                 BNK


Subject: Re: Announce - ScramDisk v2.02h
Date: Sun, 04 Apr 1999 03:46:48 GMT
From: lyeoh@pop.jaring.nospam.my (Lincoln Yeoh)
Message-ID: <3706da06.2109438@nntp.jaring.my>
References: <3705141b.4312658@news.io.com>
Newsgroups: alt.security.pgp,sci.crypt
Lines: 47

On Fri, 02 Apr 1999 19:03:38 GMT, ritter@io.com (Terry Ritter) wrote:

>5.  One of the facts of ciphering life is that we cannot prove the
>strength of any cipher.  Even NIST review and group-cryptanalysis does
>not give us proven strength in a cipher, so any cipher we select might
>be already broken, and we would not know.  We cannot change this, but
>we can greatly improve our odds as a user, by multi-ciphering under
>different ciphers.  Doing this means an Opponent must break *all* of
>those ciphers -- not just one -- to expose our data.  I like the idea
>of having three layers of different cipher, each with its own key.  

Yeah. I like the idea of superencryption too, and I don't know why so few
people seem to like it. So far I have not had a good answer to how an
attacker would know if he or she has succeeded. 

In fact I'd go further- by having layers of many and not just 3 layers of
encryption, and each layer not leaking any headers at all, the attacker's
work will be very much harder, even if each layer is just 40 bit crypto.

I would think if we use ciphers A, B, C in such a headerless manner, A.B.C
is unlikely to be weaker than either A or B or C alone, despite some FUD
about "cipher interaction", heck if such an effect was likely we'd see more
cryptographers encrypting stuff with various other ciphers to decrypt it.

Since no one can prove a single cipher is secure, it is hubris to assume
that one cipher is better than the rest or that one can even select a
single preferred one. For high confidentiality one could perhaps super
encrypt data with the top 6 AES contenders. 

As for cpu consumption, I'm wondering if chaining reduced round ciphers
together would be too risky. But your point about having a large pool of
ciphers can help here. With the number of possibilities, analysis could be
come prohibitive. The opponent may just have to resort to brute force -
trying out various keys with various ciphers. 

I'm wondering if cryptanalysis of plaintext encrypted with ABCDEFG be
different from analysis of AGDCBEF?

Have fun!

Link.

****************************
Reply to:     @Spam to
lyeoh at      @people@uu.net
pop.jaring.my @ 
*******************************


Subject: Re: Announce - ScramDisk v2.02h
Date: 9 Apr 1999 11:10:56 GMT
From: aph@cygnus.remove.co.uk (Andrew Haley)
Message-ID: <7ekn80$kc1$1@korai.cygnus.co.uk>
References: <3706da06.2109438@nntp.jaring.my>
Newsgroups: sci.crypt
Lines: 16

[ Newsgroups list trimmed ]

Lincoln Yeoh (lyeoh@pop.jaring.nospam.my) wrote:

: I like the idea of superencryption too, and I don't know why so few
: people seem to like it. So far I have not had a good answer to how
: an attacker would know if he or she has succeeded.

The answer is simple.  Kerckhoff's maxim says that your attacker knows
the cryptosystem you're using, but does not know the key.  If you're
using superencryption, your attacker knows which systems you're using.

Of course, your attacker must now analyze the compound cipher, which
is almost certainly harder to do than than attacking a single cipher.

Andrew.


Subject: Re: Announce - ScramDisk v2.02h
Date: Fri, 09 Apr 1999 17:10:12 GMT
From: ritter@io.com (Terry Ritter)
Message-ID: <370e33ea.2675997@news.io.com>
References: <7ekn80$kc1$1@korai.cygnus.co.uk>
Newsgroups: sci.crypt
Lines: 39


On 9 Apr 1999 11:10:56 GMT, in <7ekn80$kc1$1@korai.cygnus.co.uk>, in
sci.crypt aph@cygnus.remove.co.uk (Andrew Haley) wrote:

>[ Newsgroups list trimmed ]
>
>Lincoln Yeoh (lyeoh@pop.jaring.nospam.my) wrote:
>
>: I like the idea of superencryption too, and I don't know why so few
>: people seem to like it. So far I have not had a good answer to how
>: an attacker would know if he or she has succeeded.
>
>The answer is simple.  Kerckhoff's maxim says that your attacker knows
>the cryptosystem you're using, but does not know the key.  If you're
>using superencryption, your attacker knows which systems you're using.

That's fine if you always use the same ciphers in the same order.  But
if the ciphers are dynamically selected by keying, or just dynamically
selected frequently by communications under cipher, the attacker does
*not* know "which systems you're using."  Kerckhoff's maxim does not
apply.  

I suggest that each communication include a small encrypted control
channel, over which a continuous conversation of what ciphers to use
next takes place.  This would be an automatic negotiation, somewhat
like occurs in modern modems, from cipher selections approved by the
users (or their security people).  


>Of course, your attacker must now analyze the compound cipher, which
>is almost certainly harder to do than than attacking a single cipher.

Yes.  Even if each cipher used has known weaknesses, those may not be
exploitable in the multi-ciphering case.

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


Subject: Re: Announce - ScramDisk v2.02h
Date: 9 Apr 1999 13:16:35 -0500
From: juola@mathcs.duq.edu (Patrick Juola)
Message-ID: <7elg63$eeq$1@quine.mathcs.duq.edu>
References: <370e33ea.2675997@news.io.com>
Newsgroups: sci.crypt
Lines: 32

In article <370e33ea.2675997@news.io.com>, Terry Ritter <ritter@io.com> wrote:
>
>On 9 Apr 1999 11:10:56 GMT, in <7ekn80$kc1$1@korai.cygnus.co.uk>, in
>sci.crypt aph@cygnus.remove.co.uk (Andrew Haley) wrote:
>
>>[ Newsgroups list trimmed ]
>>
>>Lincoln Yeoh (lyeoh@pop.jaring.nospam.my) wrote:
>>
>>: I like the idea of superencryption too, and I don't know why so few
>>: people seem to like it. So far I have not had a good answer to how
>>: an attacker would know if he or she has succeeded.
>>
>>The answer is simple.  Kerckhoff's maxim says that your attacker knows
>>the cryptosystem you're using, but does not know the key.  If you're
>>using superencryption, your attacker knows which systems you're using.
>
>That's fine if you always use the same ciphers in the same order.  But
>if the ciphers are dynamically selected by keying, or just dynamically
>selected frequently by communications under cipher, the attacker does
>*not* know "which systems you're using."  Kerckhoff's maxim does not
>apply.  

Unfortunately, this isn't the case.

If the system is dynamically selected by keying, then the exact
selection becomes part of the key.  If you are taking a set of cyphers
and reordering them, Kerchoff's maxim suggests that you have to assume
that the attacker knows the set of cyphers and just doesn't know
the order.

	-kitten


Subject: Re: Announce - ScramDisk v2.02h
Date: Fri, 09 Apr 1999 18:06:51 -0400
From: Boris Kazak <bkazak@worldnet.att.net>
Message-ID: <370E79FB.5B1C@worldnet.att.net>
References: <7elg63$eeq$1@quine.mathcs.duq.edu>
Newsgroups: sci.crypt
Lines: 27

Patrick Juola wrote:
> 
> In article <370e33ea.2675997@news.io.com>, Terry Ritter <ritter@io.com> wrote:
> >But
> >if the ciphers are dynamically selected by keying, or just dynamically
> >selected frequently by communications under cipher, the attacker does
> >*not* know "which systems you're using."  Kerckhoff's maxim does not
> >apply.
> 
> Unfortunately, this isn't the case.
> 
> If the system is dynamically selected by keying, then the exact
> selection becomes part of the key.  If you are taking a set of cyphers
> and reordering them, Kerchoff's maxim suggests that you have to assume
> that the attacker knows the set of cyphers and just doesn't know
> the order.
> 
>         -kitten
---------------------
It all depends on the numbers in question.
  If there are 2,3,10, even 100 ciphers, you can afford an exhaustive
search, but what if there are 2^16 ciphers (or 2^16 variations of the
base cipher), what then? 
  Essentially you are adding together the key space and the ciphers
space, with the corresponding increase of problems for an attacker.

    Best wishes                  BNK


Subject: Re: Announce - ScramDisk v2.02h
Date: Fri, 09 Apr 1999 22:24:20 GMT
From: ritter@io.com (Terry Ritter)
Message-ID: <370e7e04.21648784@news.io.com>
References: <7elg63$eeq$1@quine.mathcs.duq.edu>
Newsgroups: sci.crypt
Lines: 47


On 9 Apr 1999 13:16:35 -0500, in <7elg63$eeq$1@quine.mathcs.duq.edu>,
in sci.crypt juola@mathcs.duq.edu (Patrick Juola) wrote:

>In article <370e33ea.2675997@news.io.com>, Terry Ritter <ritter@io.com> wrote:
>>
>>On 9 Apr 1999 11:10:56 GMT, in <7ekn80$kc1$1@korai.cygnus.co.uk>, in
>>sci.crypt aph@cygnus.remove.co.uk (Andrew Haley) wrote:
>>>[...]
>>>The answer is simple.  Kerckhoff's maxim says that your attacker knows
>>>the cryptosystem you're using, but does not know the key.  If you're
>>>using superencryption, your attacker knows which systems you're using.
>>
>>That's fine if you always use the same ciphers in the same order.  But
>>if the ciphers are dynamically selected by keying, or just dynamically
>>selected frequently by communications under cipher, the attacker does
>>*not* know "which systems you're using."  Kerckhoff's maxim does not
>>apply.  
>
>Unfortunately, this isn't the case.
>
>If the system is dynamically selected by keying, then the exact
>selection becomes part of the key.  

Which of course means that the dynamic selection is not subject to
Kerckhoff's maxim.  End case 1.

>If you are taking a set of cyphers
>and reordering them, Kerchoff's maxim suggests that you have to assume
>that the attacker knows the set of cyphers and just doesn't know
>the order.

First of all, this is not true if we have a dynamically-expanding set
of ciphers.  Every cipher is only "known" to the Opponents after they
have identified it, acquired it, analyzed it, and, presumably, broken
it.  All this necessarily takes time, and this time works for the user
and against the attacker.    

But even if The Opponents *do* know the set of existing ciphers, when
the ciphers used are selected by some periodic random selection, there
is secret information which is not exposed.  This is a sort of keying.
We cannot simply assume that it *is* exposed.  End case 2.

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


Subject: Re: Announce - ScramDisk v2.02h
Date: Fri, 9 Apr 1999 11:31:40 -0700
From: "Harvey Rook" <redrook@someyahoo.com>
Message-ID: <7elhhc$ic6@news.dns.microsoft.com>
References: <370e33ea.2675997@news.io.com>
Newsgroups: sci.crypt
Lines: 65


Terry Ritter <ritter@io.com> wrote in message
news:370e33ea.2675997@news.io.com...
>
> On 9 Apr 1999 11:10:56 GMT, in <7ekn80$kc1$1@korai.cygnus.co.uk>, in
> sci.crypt aph@cygnus.remove.co.uk (Andrew Haley) wrote:
>
> >The answer is simple.  Kerckhoff's maxim says that your attacker knows
> >the cryptosystem you're using, but does not know the key.  If you're
> >using superencryption, your attacker knows which systems you're using.
>
> That's fine if you always use the same ciphers in the same order.  But
> if the ciphers are dynamically selected by keying, or just dynamically
> selected frequently by communications under cipher, the attacker does
> *not* know "which systems you're using."  Kerckhoff's maxim does not
> apply.
>
This is incorrect. By Kerchhoff's maxim, you have to assume your attacker
has a copy of your deciphering machine. If he has a copy of your deciphering
machine, the attacker can figure out the algorithm you use to select
ciphers.
Once he knows the algorithm used to select ciphers, super-encipherment
only doubles or triples the amount of time needed to brute force. You'd
be much better off adding an extra byte to your key.

> I suggest that each communication include a small encrypted control
> channel, over which a continuous conversation of what ciphers to use
> next takes place.  This would be an automatic negotiation, somewhat
> like occurs in modern modems, from cipher selections approved by the
> users (or their security people).
>
> >Of course, your attacker must now analyze the compound cipher, which
> >is almost certainly harder to do than than attacking a single cipher.
>
> Yes.  Even if each cipher used has known weaknesses, those may not be
> exploitable in the multi-ciphering case.
>
It's only harder by one or two orders of magnitude. Computers built 3 years
from now
will have enough power to compensate for this difference. Adding an extra
byte
to your key makes the problem harder by 4 to 8 orders of magnitude. This is
much
harder to attack, yet it's simpler and cleaner to analyze. Simple clean
systems, are
much less likely to have holes.

Unexpected weaknesses in ciphers designed by good cryptographers (Say
Rivest, or Schneier)
are very unlikely to appear. Remember DES, after 25 years of analysis, is
still only
vulnerable to a brute force attack. I'd be willing to bet that RC-6 and
TwoFish will withstand
the same scrutiny.

Security breaks down because of bad passwords and poor protocols. Not
because of cipher
weakness. Plan your system accordingly, or you are deluding yourself.

Harv
RedRook At Zippy The Yahoo Dot Com
Remove the Zippy The to send email.


Subject: Re: Announce - ScramDisk v2.02h
Date: Fri, 09 Apr 1999 22:24:44 GMT
From: ritter@io.com (Terry Ritter)
Message-ID: <370e7e29.21686311@news.io.com>
References: <7elhhc$ic6@news.dns.microsoft.com>
Newsgroups: sci.crypt
Lines: 104


On Fri, 9 Apr 1999 11:31:40 -0700, in
<7elhhc$ic6@news.dns.microsoft.com>, in sci.crypt "Harvey Rook"
<redrook@someyahoo.com> wrote:

>Terry Ritter <ritter@io.com> wrote in message
>news:370e33ea.2675997@news.io.com...
>>
>> On 9 Apr 1999 11:10:56 GMT, in <7ekn80$kc1$1@korai.cygnus.co.uk>, in
>> sci.crypt aph@cygnus.remove.co.uk (Andrew Haley) wrote:
>>
>> >The answer is simple.  Kerckhoff's maxim says that your attacker knows
>> >the cryptosystem you're using, but does not know the key.  If you're
>> >using superencryption, your attacker knows which systems you're using.
>>
>> That's fine if you always use the same ciphers in the same order.  But
>> if the ciphers are dynamically selected by keying, or just dynamically
>> selected frequently by communications under cipher, the attacker does
>> *not* know "which systems you're using."  Kerckhoff's maxim does not
>> apply.
>>
>This is incorrect. By Kerchhoff's maxim, you have to assume your attacker
>has a copy of your deciphering machine. If he has a copy of your deciphering
>machine, the attacker can figure out the algorithm you use to select
>ciphers.

That is no more true than saying that the attacker can figure out the
message key or the initialization vector.  We assume the system has
some reliable random source to make such values.  Similar values
select what ciphers to use in what order.  And this should change
frequently.  


>Once he knows the algorithm used to select ciphers, super-encipherment
>only doubles or triples the amount of time needed to brute force. You'd
>be much better off adding an extra byte to your key.

The issue is far beyond increasing the keyspace, since that would take
a huge number of ciphers.  The issue instead is about spreading
messages among many different ciphers, thus forcing The Opponents to
"keep up" by identifying, acquiring, attacking, and breaking a
continuing flow of new ciphers.  This forces The Opponents to invest
far more, and breaking any of these gains them far less.  Note the
contrast to the current situation, where only a few main ciphers are
used, so only those need be broken.  

>>[...]
>> Yes.  Even if each cipher used has known weaknesses, those may not be
>> exploitable in the multi-ciphering case.
>>
>It's only harder by one or two orders of magnitude. 

Well, let's see:  Suppose we have about 4K ciphers.  By selecting 3 at
random so we have about 4k**3 selections.  This is somewhat larger
than "two orders of magnitude."

But, again, the issue is not really the increase in keyspace.  The
issue is that The Opponents have to increase their analysis budget by,
say, a factor of 1k.  And even when they are successful, they get at
most 1 message out of 1k.  And we reduce that to 1 in 1k*1k*1k by
using 3 layers of cipher.  


>Computers built 3 years
>from now
>will have enough power to compensate for this difference. Adding an extra
>byte
>to your key makes the problem harder by 4 to 8 orders of magnitude. This is
>much
>harder to attack, yet it's simpler and cleaner to analyze. Simple clean
>systems, are
>much less likely to have holes.

Using a layered structure is far, far simpler than trying to analyze a
cipher to the degree of predicting that one cipher is stronger than
another by n orders of magnitude.  Neither value is known, so we can
hardly compare them.  


>Unexpected weaknesses in ciphers designed by good cryptographers (Say
>Rivest, or Schneier)
>are very unlikely to appear. 

Sorry.  That is an insupportable statement (and of course unprovable).
Being a crypto god does not prevent mistakes.  

>Remember DES, after 25 years of analysis, is
>still only
>vulnerable to a brute force attack. 

Also insupportable:  DES may have a fast break right now, and if it
does, would those who have it have told you?  Yet you feel free to
assume that there is no break.  Good for you.  Now prove it.  

>I'd be willing to bet that RC-6 and
>TwoFish will withstand
>the same scrutiny.

But that is hardly science or even rational reasoning, is it?

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


Subject: Re: Announce - ScramDisk v2.02h
Date: Fri, 9 Apr 1999 18:58:49 -0700
From: "Harvey Rook" <redrook@someyahoo.com>
Message-ID: <7emb5m$iq2@news.dns.microsoft.com>
References: <370e7e29.21686311@news.io.com>
Newsgroups: sci.crypt
Lines: 161

My comments withing...
Terry Ritter <ritter@io.com> wrote in message
news:370e7e29.21686311@news.io.com...
>
> On Fri, 9 Apr 1999 11:31:40 -0700, in
> <7elhhc$ic6@news.dns.microsoft.com>, in sci.crypt "Harvey Rook"
> <redrook@someyahoo.com> wrote:
>
> >>
> >This is incorrect. By Kerchhoff's maxim, you have to assume your attacker
> >has a copy of your deciphering machine. If he has a copy of your
deciphering
> >machine, the attacker can figure out the algorithm you use to select
> >ciphers.
>
> That is no more true than saying that the attacker can figure out the
> message key or the initialization vector.  We assume the system has
> some reliable random source to make such values.  Similar values
> select what ciphers to use in what order.  And this should change
> frequently.
>

The reliable random source must be communicated to both the encryptor,
and the decryptor. Because it's transmitted or shared, you must assume
the attacker has intercepted it. Because the attacker has intercepted the
it, the attacker knows what ciphers you are using.

>
> >Once he knows the algorithm used to select ciphers, super-encipherment
> >only doubles or triples the amount of time needed to brute force. You'd
> >be much better off adding an extra byte to your key.
>
> The issue is far beyond increasing the keyspace, since that would take
> a huge number of ciphers.  The issue instead is about spreading
> messages among many different ciphers, thus forcing The Opponents to
> "keep up" by identifying, acquiring, attacking, and breaking a
> continuing flow of new ciphers.  This forces The Opponents to invest
> far more, and breaking any of these gains them far less.  Note the
> contrast to the current situation, where only a few main ciphers are
> used, so only those need be broken.
>

Good ciphers cannot be instantly generated. They must be individually
scrutinized and tested. If you don't do that, you are setting
yourself up for failure.

> >>[...]
> >> Yes.  Even if each cipher used has known weaknesses, those may not be
> >> exploitable in the multi-ciphering case.
> >>
> >It's only harder by one or two orders of magnitude.
>
> Well, let's see:  Suppose we have about 4K ciphers.  By selecting 3 at
> random so we have about 4k**3 selections.  This is somewhat larger
> than "two orders of magnitude."
>
> But, again, the issue is not really the increase in keyspace.  The
> issue is that The Opponents have to increase their analysis budget by,
> say, a factor of 1k.  And even when they are successful, they get at
> most 1 message out of 1k.  And we reduce that to 1 in 1k*1k*1k by
> using 3 layers of cipher.
>

Why is this not the same as increasing key space? The algorithms
you use to choose the ciphers, must be transmitted to the decriptor.
Once the attacker intercepts this, he can deduce the ciphers used.

Which would you rather trust, one well analyzed cipher with 140 bits of
key, or 4096 ciphers that probably aren't well analyzed, 128 bits of key,
and some mechanism to flip between the ciphers.

>
> >Computers built 3 years
> >from now
> >will have enough power to compensate for this difference. Adding an extra
> >byte
> >to your key makes the problem harder by 4 to 8 orders of magnitude. This
is
> >much
> >harder to attack, yet it's simpler and cleaner to analyze. Simple clean
> >systems, are
> >much less likely to have holes.
>
> Using a layered structure is far, far simpler than trying to analyze a
> cipher to the degree of predicting that one cipher is stronger than
> another by n orders of magnitude.  Neither value is known, so we can
> hardly compare them.
>
>
> >Unexpected weaknesses in ciphers designed by good cryptographers (Say
> >Rivest, or Schneier)
> >are very unlikely to appear.
>
> Sorry.  That is an insupportable statement (and of course unprovable).
> Being a crypto god does not prevent mistakes.
>

Correct. However, because many ciphers have a similar structure.
An advance in discreet mathematics needed to crack one well
designed cipher would most likely apply to many ciphers. If you
have some kind of scheme that allowed you to generate thousands of
ciphers, then it is very likely that the weakness would apply to all.

I think it's very unlikely that some one could generate 4096 ciphers that
don't share a common weakness, and still properly analyzed all of them.
Even if they did, the selection of which ciphers to use, is part of the key.
Brute forcing an N bit key plus K bits of which-cipher materical  takes
O(2^(N+K)) Bruit forcing an N+K bit key also takes O(2^(N+K+b))

See, for every cipher you add, there is an equivalent scheme with only
one cipher that has the same keys size.

I dare you to name a relevent security breakdown in the past
20 years that was not the result poor key managment, or poor protocol
design. We have good algorithms. Good security comes not form flipping
between the algorithms, but from using the algorithms properly.

> >Remember DES, after 25 years of analysis, is
> >still only
> >vulnerable to a brute force attack.
>
> Also insupportable:  DES may have a fast break right now, and if it
> does, would those who have it have told you?  Yet you feel free to
> assume that there is no break.  Good for you.  Now prove it.

In the same vein, prove to me that a significant percentage of your
4096 ciphers will be strong. Unless a cipher is widely scrutinized, by
many intelligent people, you must assume it is weak. A solid analysis
of 4096 ciphers would take decades. We need good security now.


It usually impossible to prove an impossibility. In the absense of
proof you have to bet on the evidence. We have evidence that a
few ciphers are strong. We also have evidence that most ciphers are
weak.

> >I'd be willing to bet that RC-6 and
> >TwoFish will withstand
> >the same scrutiny.
>
> But that is hardly science or even rational reasoning, is it?
>

The scientific prinipal is observe, hypothesize, experiment, repeat.
I can observe that one cipher looks strong. I can form hypothesis about
it's strengths and weaknesses. I can test these hypothesis, and I can repeat
until I trust.

With thousands of ciphers, I probably could not observe that they all
look strong. There are too many of them. The analysis would be
over whelming. How can I go from this state, to hypothesizing that
combining them would be secure?

Harv
RedRook At Some Yahoo Dot Com
Remove the Some to send email.


Subject: Re: Announce - ScramDisk v2.02h
Date: Sat, 10 Apr 1999 03:56:08 GMT
From: ritter@io.com (Terry Ritter)
Message-ID: <370ecbaa.2845710@news.io.com>
References: <7emb5m$iq2@news.dns.microsoft.com>
Newsgroups: sci.crypt
Lines: 252


On Fri, 9 Apr 1999 18:58:49 -0700, in
<7emb5m$iq2@news.dns.microsoft.com>, in sci.crypt "Harvey Rook"
<redrook@someyahoo.com> wrote:

>My comments withing...
>Terry Ritter <ritter@io.com> wrote in message
>news:370e7e29.21686311@news.io.com...
>>
>> On Fri, 9 Apr 1999 11:31:40 -0700, in
>> <7elhhc$ic6@news.dns.microsoft.com>, in sci.crypt "Harvey Rook"
>> <redrook@someyahoo.com> wrote:
>>
>> >>
>> >This is incorrect. By Kerchhoff's maxim, you have to assume your attacker
>> >has a copy of your deciphering machine. If he has a copy of your
>deciphering
>> >machine, the attacker can figure out the algorithm you use to select
>> >ciphers.
>>
>> That is no more true than saying that the attacker can figure out the
>> message key or the initialization vector.  We assume the system has
>> some reliable random source to make such values.  Similar values
>> select what ciphers to use in what order.  And this should change
>> frequently.
>>
>
>The reliable random source must be communicated to both the encryptor,
>and the decryptor. Because it's transmitted or shared, you must assume
>the attacker has intercepted it. Because the attacker has intercepted the
>it, the attacker knows what ciphers you are using.

That is false.  It is always necessary to transport keys in some way.
But whatever way this is done -- by courier, multiple channels, or
authenticated public key -- random message key value are known by both
ends.  That keying value can be used to select ciphers.

In practice, I would expect background negotiation between the cipher
programs to occur with each message transmission, and produce a new
cipher set with each message or every couple of messages.


>> >Once he knows the algorithm used to select ciphers, super-encipherment
>> >only doubles or triples the amount of time needed to brute force. You'd
>> >be much better off adding an extra byte to your key.
>>
>> The issue is far beyond increasing the keyspace, since that would take
>> a huge number of ciphers.  The issue instead is about spreading
>> messages among many different ciphers, thus forcing The Opponents to
>> "keep up" by identifying, acquiring, attacking, and breaking a
>> continuing flow of new ciphers.  This forces The Opponents to invest
>> far more, and breaking any of these gains them far less.  Note the
>> contrast to the current situation, where only a few main ciphers are
>> used, so only those need be broken.
>>
>
>Good ciphers cannot be instantly generated. They must be individually
>scrutinized and tested. If you don't do that, you are setting
>yourself up for failure.

Look around:  My guess is that we could probably point to hundreds of
cipher designs which now exist.  This is in an environment where there
is no recognition of the value of multiple ciphers, and no common
interface to handle plug-in cipher components.  Were the environment
to change, I think we could easily see 500 ciphers in a few years, and
tens of thousands of ciphers in a couple of decades.


>> >>[...]
>> >> Yes.  Even if each cipher used has known weaknesses, those may not be
>> >> exploitable in the multi-ciphering case.
>> >>
>> >It's only harder by one or two orders of magnitude.
>>
>> Well, let's see:  Suppose we have about 4K ciphers.  By selecting 3 at
>> random so we have about 4k**3 selections.  This is somewhat larger
>> than "two orders of magnitude."
>>
>> But, again, the issue is not really the increase in keyspace.  The
>> issue is that The Opponents have to increase their analysis budget by,
>> say, a factor of 1k.  And even when they are successful, they get at
>> most 1 message out of 1k.  And we reduce that to 1 in 1k*1k*1k by
>> using 3 layers of cipher.
>>
>
>Why is this not the same as increasing key space? The algorithms
>you use to choose the ciphers, must be transmitted to the decriptor.
>Once the attacker intercepts this, he can deduce the ciphers used.

Certainly, the cipher selection amounts to a sort of key, but this
would be a one-time message key or initialization vector, as opposed
to a repeatedly-used user key.  


>Which would you rather trust, one well analyzed cipher with 140 bits of
>key, or 4096 ciphers that probably aren't well analyzed, 128 bits of key,
>and some mechanism to flip between the ciphers.

I take the 4096 ciphers, and I have explained why:  First, the
multi-cipher situation forces any Opponent whatsoever to keep up in a
process which is vastly more expensive for them then for us.  Next, we
divide our total traffic among many different ciphers.  So even if an
Opponent breaks a cipher, the best they can hope for is 1/n of the
traffic.  And in the multi-ciphering case, they don't even get that.

As to "trust," you should be aware that there *is* no way to prove
strength, to measure strength, to build strength or test strength.
Any "trust" of a cipher is a delusion only.  For example, the best
cryptanalysis can do is find weakness, and this only helps if weakness
is actually found.  If no weakness is found, cryptanalysis does not
testify to strength.  

Personally, I think we are better off with user selection (e.g., "I
use what my friend uses," or "We bought a custom cipher subscription")
than any standard picked by a central authority.  


>> >Computers built 3 years
>> >from now
>> >will have enough power to compensate for this difference. Adding an extra
>> >byte
>> >to your key makes the problem harder by 4 to 8 orders of magnitude. This
>is
>> >much
>> >harder to attack, yet it's simpler and cleaner to analyze. Simple clean
>> >systems, are
>> >much less likely to have holes.
>>
>> Using a layered structure is far, far simpler than trying to analyze a
>> cipher to the degree of predicting that one cipher is stronger than
>> another by n orders of magnitude.  Neither value is known, so we can
>> hardly compare them.
>>
>>
>> >Unexpected weaknesses in ciphers designed by good cryptographers (Say
>> >Rivest, or Schneier)
>> >are very unlikely to appear.
>>
>> Sorry.  That is an insupportable statement (and of course unprovable).
>> Being a crypto god does not prevent mistakes.
>>
>
>Correct. However, because many ciphers have a similar structure.
>An advance in discreet mathematics needed to crack one well
>designed cipher would most likely apply to many ciphers. If you
>have some kind of scheme that allowed you to generate thousands of
>ciphers, then it is very likely that the weakness would apply to all.

Certainly any cipher designer will have his bag of tricks.  One might
expect that some of those tricks would be risky, but hardly all.  And
the vast number of designers would be using many different approaches.
It seems extremely *un*likely that a single breakthrough would affect
them all.  Indeed, the unexpected break would be far, far more likely
(and far, far more serious) if we have just one standard cipher.  


>I think it's very unlikely that some one could generate 4096 ciphers that
>don't share a common weakness, and still properly analyzed all of them.
>Even if they did, the selection of which ciphers to use, is part of the key.
>Brute forcing an N bit key plus K bits of which-cipher materical  takes
>O(2^(N+K)) Bruit forcing an N+K bit key also takes O(2^(N+K+b))
>
>See, for every cipher you add, there is an equivalent scheme with only
>one cipher that has the same keys size.

Only in the sense that the meta cipher has various components, but
these are unknown until they are written.  That meta cipher does not
exist until nobody is writing new ciphers anymore.  

>I dare you to name a relevent security breakdown in the past
>20 years that was not the result poor key managment, or poor protocol
>design. 

DES keyspace.

>We have good algorithms. Good security comes not form flipping
>between the algorithms, but from using the algorithms properly.

In the present tense, it is certain that this rarely happens now.  But
the opportunity is available for the future.


>> >Remember DES, after 25 years of analysis, is
>> >still only
>> >vulnerable to a brute force attack.
>>
>> Also insupportable:  DES may have a fast break right now, and if it
>> does, would those who have it have told you?  Yet you feel free to
>> assume that there is no break.  Good for you.  Now prove it.
>
>In the same vein, prove to me that a significant percentage of your
>4096 ciphers will be strong. Unless a cipher is widely scrutinized, by
>many intelligent people, you must assume it is weak. A solid analysis
>of 4096 ciphers would take decades. We need good security now.

First of all, ciphers should be selected by users, and your so-called
strength is up to them.  If a cipher is found weak in some academic
paper, the users may choose to disable that cipher from further use,
or not.  In contrast, if the one standard cipher is found weak, there
is no real alternative, and no process for making that change.  

Significant security is provided simply by partitioning the message
space into many different ciphers; by having a continuing flow of new
ciphers; and by making multi-ciphering an expected process.  This is
security added to any set of ciphers which may already exist.  

Any widely scrutinized cipher could be used in this process, and would
not be weakened by it.  The many-cipher situation can only improve
things, not weaken what is already there.  


>It usually impossible to prove an impossibility. In the absense of
>proof you have to bet on the evidence. We have evidence that a
>few ciphers are strong. We also have evidence that most ciphers are
>weak.

In the absence of proof of strength, it is foolish to bet that a
particular cipher is strong.  The best bet is to use multiple ciphers
at the same time, change ciphers often, and be prepared to disable
particular ciphers at the first sign of trouble.  


>> >I'd be willing to bet that RC-6 and
>> >TwoFish will withstand
>> >the same scrutiny.
>>
>> But that is hardly science or even rational reasoning, is it?
>>
>
>The scientific prinipal is observe, hypothesize, experiment, repeat.
>I can observe that one cipher looks strong. I can form hypothesis about
>it's strengths and weaknesses. I can test these hypothesis, and I can repeat
>until I trust.

No, you cannot test strength.  Neither can anyone else.  *That* is the
problem.  


>With thousands of ciphers, I probably could not observe that they all
>look strong. There are too many of them. The analysis would be
>over whelming. How can I go from this state, to hypothesizing that
>combining them would be secure?

By observing that any one cipher that you do accept can be part of
stack.  That would give you 2 changing ciphers, the ability to switch
to another if you get bad news, and the knowledge that any hidden
break to your favorite cipher is protected by the rest of the stack.

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


Subject: Re: Announce - ScramDisk v2.02h
Date: Mon, 12 Apr 1999 10:31:55 GMT
From: ssimpson@hertreg.ac.uk
Message-ID: <7esi2r$cct$1@nnrp1.dejanews.com>
References: <7elhhc$ic6@news.dns.microsoft.com>
Newsgroups: sci.crypt
Lines: 41

In article <7elhhc$ic6@news.dns.microsoft.com>,
  "Harvey Rook" <redrook@someyahoo.com> wrote:
>
> Terry Ritter <ritter@io.com> wrote in message
> news:370e33ea.2675997@news.io.com...
> >
> > On 9 Apr 1999 11:10:56 GMT, in <7ekn80$kc1$1@korai.cygnus.co.uk>, in
> > sci.crypt aph@cygnus.remove.co.uk (Andrew Haley) wrote:
> >
> > >The answer is simple.  Kerckhoff's maxim says that your attacker knows
> > >the cryptosystem you're using, but does not know the key.  If you're
> > >using superencryption, your attacker knows which systems you're using.
> >
> > That's fine if you always use the same ciphers in the same order.  But
> > if the ciphers are dynamically selected by keying, or just dynamically
> > selected frequently by communications under cipher, the attacker does
> > *not* know "which systems you're using."  Kerckhoff's maxim does not
> > apply.
> >
> This is incorrect. By Kerchhoff's maxim, you have to assume your attacker
> has a copy of your deciphering machine. If he has a copy of your deciphering
> machine, the attacker can figure out the algorithm you use to select
> ciphers.

Make the cipher selection(s) dependant on additional key material?


> Once he knows the algorithm used to select ciphers, super-encipherment
> only doubles or triples the amount of time needed to brute force. You'd
> be much better off adding an extra byte to your key.

Depends on the method of selection, range of ciphers and number we are willing
to employ to encrypt one message doesn't it?

Sam Simpson
Comms Analyst
-- http://www.scramdisk.clara.net/ for ScramDisk hard-drive encryption &
Delphi Crypto Components.  PGP Keys available at the same site.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    


Subject: Re: Announce - ScramDisk v2.02h
Date: Fri, 09 Apr 1999 18:28:10 -0400
From: Boris Kazak <bkazak@worldnet.att.net>
Message-ID: <370E7EFA.7BB2@worldnet.att.net>
References: <370e33ea.2675997@news.io.com>
Newsgroups: sci.crypt
Lines: 19

Terry Ritter wrote:
> .................
> >Of course, your attacker must now analyze the compound cipher, which
> >is almost certainly harder to do than than attacking a single cipher.
> 
> Yes.  Even if each cipher used has known weaknesses, those may not be
> exploitable in the multi-ciphering case.
> 
> ---
> Terry Ritter   ritter@io.com   http://www.io.com/~ritter/
> Crypto Glossary   http://www.io.com/~ritter/GLOSSARY.HTM
-----------------
  A practical suggestion: what if we would initialize BLOWFISH not 
with the digits of 'pi', but with some other constant - e, sqrt(2),
sin(1)...? How many different ciphers can we generate from the same 
base algorithm, and how big will be the additional effort to break
them all? Especially if dynamically selected...

   Best wishes               BNK


Subject: Re: Announce - ScramDisk v2.02h
Date: Mon, 12 Apr 1999 10:26:58 GMT
From: ssimpson@hertreg.ac.uk
Message-ID: <7eshpd$c28$1@nnrp1.dejanews.com>
References: <7ekn80$kc1$1@korai.cygnus.co.uk>
Newsgroups: sci.crypt
Lines: 39

Why not make cipher selection for the compound cipher part of the key?	The
first one or two bytes of the key could be used to select 3 (or whatever
number is desirable) ciphers out of a pool of equally good ciphers.


This sounds (imho) like a good idea - as long as there are no disastrously
weak combinations of ciphers.

Comments?



Sam Simpson Communications Analyst -- http://www.scramdisk.clara.net/ for
ScramDisk hard-drive encryption & Delphi Crypto Components.  PGP Keys
available at the same site.



In article <7ekn80$kc1$1@korai.cygnus.co.uk>,
  aph@cygnus.remove.co.uk (Andrew Haley) wrote:
> [ Newsgroups list trimmed ]
>
> Lincoln Yeoh (lyeoh@pop.jaring.nospam.my) wrote:
>
> : I like the idea of superencryption too, and I don't know why so few
> : people seem to like it. So far I have not had a good answer to how
> : an attacker would know if he or she has succeeded.
>
> The answer is simple.  Kerckhoff's maxim says that your attacker knows
> the cryptosystem you're using, but does not know the key.  If you're
> using superencryption, your attacker knows which systems you're using.
>
> Of course, your attacker must now analyze the compound cipher, which
> is almost certainly harder to do than than attacking a single cipher.
>
> Andrew.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    


Subject: Re: Announce - ScramDisk v2.02h
Date: Mon, 12 Apr 1999 15:30:03 -0600
From: jcoffin@taeus.com (Jerry Coffin)
Message-ID: <MPG.117bdb60312a13119899e2@news.rmi.net>
References: <7eshpd$c28$1@nnrp1.dejanews.com>
Newsgroups: sci.crypt
Lines: 16

In article <7eshpd$c28$1@nnrp1.dejanews.com>, ssimpson@hertreg.ac.uk 
says...
> Why not make cipher selection for the compound cipher part of the key?	The
> first one or two bytes of the key could be used to select 3 (or whatever
> number is desirable) ciphers out of a pool of equally good ciphers.
> 
> 
> This sounds (imho) like a good idea - as long as there are no disastrously
> weak combinations of ciphers.

This might optimize speed slightly, but I don't see it helping 
security. If you're going to include code for a number of forms of 
encryption, from a viewpoint of security, you might as well just 
always use ALL the forms of encryption supported, and use the entire
key as a key instead some of it as a key and some to select the 
method(s) of encryption to be used.


Subject: Re: Announce - ScramDisk v2.02h
Date: 22 Apr 1999 20:02:39 -0700
From: mskala@ansuz.sooke.bc.ca. (Matthew Skala)
Message-ID: <7fonsf$so3$1@ruby.ansuz.sooke.bc.ca>
References: <MPG.117bdb60312a13119899e2@news.rmi.net>
Newsgroups: sci.crypt
Lines: 18

In article <MPG.117bdb60312a13119899e2@news.rmi.net>,
Jerry Coffin <jcoffin@taeus.com> wrote:
>security. If you're going to include code for a number of forms of 
>encryption, from a viewpoint of security, you might as well just
>always use ALL the forms of encryption supported, and use the entire 

Speed.  If you use all the ciphers to encrypt the whole file, it may take
you a very long time.  But here's another idea: use some sort of
all-or-nothing scheme, so attackers have to attack the entire file at
once, and then encrypt say the first block with IDEA, the second block
with Blowfish, the third with 3DES, the fourth with SCOTT19U, and so on.  
I'm not fully up on how well all-or-nothing schemes work, but it seems
like it should be possible to require the attackers to break all the
ciphers, while still not having to do all the ciphers on all the blocks.
--
Matthew Skala  Ansuz BBS  (250) 472-3169  http://www.islandnet.com/~mskala/

                            GOD HATES SPAM


Subject: Thought question:  why do public ciphers use only simple ops like shift and XOR?
Date: Fri, 16 Apr 1999 07:31:40 -0700
From: Sundial Services <info@sundialservices.com>
Message-ID: <371749CC.4779@sundialservices.com>
Newsgroups: sci.crypt
Lines: 18

When I look at most publicly-available cryptographic algorithms, I see
that nearly all of them consist of round upon round of simple operations
like:  shift, exclusive-OR, and "bit-twiddling."  Most of these ops are
readily reversible.

About the only "original idea" I've seen, since reading discussions of
older machines like SIGABA, is Terry Ritter's "Dynamic Substitution"
patent.  At least he is using a more complex transformation than 99.9%
of the things I've seen ... since SIGABA ... and he's burying a lot more
information than most designs do.

My question is, aside from possible requirements for constructing their
ciphers in hardware, why do designers routinely limit themselves to
these simple bitwise operators in designing ciphers?  It seems to me as
a layman that the older, more complex designs were also far more secure
than what we have now, and that a computer program would have no
particular difficulty implementing them.  We are not building hardware
devices; we are not limited to LFSR's.


Subject: Re: Thought question:  why do public ciphers use only simple ops like shift and XOR?
Date: Fri, 16 Apr 1999 17:28:13 GMT
From: jsavard@tenMAPSONeerf.edmonton.ab.ca (John Savard)
Message-ID: <37176a30.4219613@news.prosurfr.com>
References: <371749CC.4779@sundialservices.com>
Newsgroups: sci.crypt
Lines: 111

Sundial Services <info@sundialservices.com> wrote, in part:

>When I look at most publicly-available cryptographic algorithms, I see
>that nearly all of them consist of round upon round of simple operations
>like:  shift, exclusive-OR, and "bit-twiddling."  Most of these ops are
>readily reversible.

Looking at this paragraph, and your title, my initial reaction was to say
that you were wrong - block cipher designers do recognize the importance of
nonlinearity, and thus in virtually every block cipher you will find an
S-box.

>About the only "original idea" I've seen, since reading discussions of
>older machines like SIGABA, is Terry Ritter's "Dynamic Substitution"
>patent.  At least he is using a more complex transformation than 99.9%
>of the things I've seen ... since SIGABA ... and he's burying a lot more
>information than most designs do.

Dynamic Substitution is a good idea, and an original one. And since I
consider the SIGABA to be an admirable design, I started to warm to you at
this point.

>My question is, aside from possible requirements for constructing their
>ciphers in hardware, why do designers routinely limit themselves to
>these simple bitwise operators in designing ciphers?  It seems to me as
>a layman that the older, more complex designs were also far more secure
>than what we have now, and that a computer program would have no
>particular difficulty implementing them.  We are not building hardware
>devices; we are not limited to LFSR's.

Now this is a question I've been asking myself.

But there are answers to it.

- For one thing, not everyone using cryptography is simply writing a
program to encipher E-mail. If, for that application, it is trivial to just
throw complexity at the problem to obtain security, then there's no money
to be made from designing a cipher which is secure in that
situation...anyone can do it. What about securely encrypting real-time
digital video?

- Also, since there are many insecure cipher designs floating around, one
can't just accept that a cipher is secure based on its designer's say-so.
Instead, what gives real confidence in a cipher design is that it has been
studied by experts who have failed to crack it, but who have come away from
their attempts with an understanding of the source of the design's
strengths.

But an academic researcher isn't going to take time studying a cipher that
is so big and complicated that there is no hope of coming away with an
impressive result - and so big and complicated that even trying to
understand it would consume an enormous amount of time and effort.

Thus, designs that are intentionally limited - to one basic type of round,
to one underlying principle - have an advantage over designs based on the
principle that security is the only goal. They might be less intrinsically
secure, but they have a better chance of being able to (appear to) _prove_
(indicate with some tendency to confidence) that they do have a certain
level of security.


Although I do understand the rationale behind the "recieved wisdom", that
doesn't mean I fully accept it. In practice, when using cryptography,
security is what counts; and advances are being made both in the theory of
cryptanalysis and in the speed and power of computer chips at a great rate.

Plus, the risk that one's adversary is a hacker of the future with a very
powerful desktop computer seems much greater than the risk that one's
adversary will be an accomplished cryptanalyst, able to exploit the most
subtle flaws in an over-elaborate design.

Hence, I have played with designs that don't just use "simple operations".
They do incorporate a lot from the designs of the real experts in the
field, compared to which I am a mere amateur, but they go on from there to
pile on a higher level of complication than seen in the well-known designs.

Take a look at my Quadibloc II and Quadibloc III designs, in

http://members.xoom.com/quadibloc/co040705.htm
http://members.xoom.com/quadibloc/co040705.htm

for example. I think they may address your concern - although they may not
go far enough.

One thing I _very definitely_ don't want to do is to go around like certain
posters on this NG, and claim that a cipher *must* be as complicated as
these designs of mine in order to be secure. That simply isn't true.

And it is also true that a strong cipher isn't a guarantee of security;
designing ciphers may be fun, but preventing data from leaking out the back
door is hard work.

While I respect the knowledge and ability of the acknowledged experts in
the field, where I think I part company with Bruce Schneier and others is
in the following:

I believe it to be possible and useful to develop a design methodology -
mainly involving the cutting and pasting of pieces from proven cipher
designs - to enable a reasonably qualified person who, however, falls short
of being a full-fleged cryptographer, to design his own block cipher, and
thereby obtain additional and significant benefits in resistance to
cryptanalytic attack by having an unknown and unique algorithm.

I don't deny that there are pitfalls looming in such an approach; if
something is left out of the methodology, or if it isn't conscientiously
used, people could easily wind up using weak designs and having a false
sense of security. I just think the problems can be addressed, and the
potential benefits are worth the attempt.

John Savard (teneerf is spelled backwards)
http://members.xoom.com/quadibloc/index.html


Subject: Re: Thought question:  why do public ciphers use only simple ops like shift and XOR?
Date: Fri, 16 Apr 1999 20:20:24 GMT
From: ritter@io.com (Terry Ritter)
Message-ID: <37179b67.12809750@news.io.com>
References: <37176a30.4219613@news.prosurfr.com>
Newsgroups: sci.crypt
Lines: 129


On Fri, 16 Apr 1999 17:28:13 GMT, in
<37176a30.4219613@news.prosurfr.com>, in sci.crypt
jsavard@tenMAPSONeerf.edmonton.ab.ca (John Savard) wrote:

>[...]
>- Also, since there are many insecure cipher designs floating around, one
>can't just accept that a cipher is secure based on its designer's say-so.
>Instead, what gives real confidence in a cipher design is that it has been
>studied by experts who have failed to crack it, but who have come away from
>their attempts with an understanding of the source of the design's
>strengths.

I dispute this.  This is essentially what Schneier would have us
believe, and it is false.

The truth is that we *never* know the "real" strength of a cipher.  No
matter how much review or cryptanalysis a cipher gets, we only have
the latest "upper bound" for strength.  The lower bound is zero:  Any
cipher can fail at any time.

Since we have only an upper bound for the strength of any cipher, any
confidence we may have is no more than our own delusion.  We wish and
hope for cipher strength, and -- absent a specific proof otherwise --
we gradually come to believe in it.  But that does not make it true.  

We would like to think that the more we use a cipher, the more
confidence we can have in it.  We *can* build confidence in a
ciphering program, as to whether or not it crashes and so on.  But
since our Opponents do not tell us of their success, we do not know
that our cipher was successful at hiding data.  And we cannot have
confidence in a result without knowing what that result is.


>[...]
>But an academic researcher isn't going to take time studying a cipher that
>is so big and complicated that there is no hope of coming away with an
>impressive result - and so big and complicated that even trying to
>understand it would consume an enormous amount of time and effort.

It is always nice to find something important which is easy to do.
That would be the academic equivalent of "Make Easy Money Now."  

It may be unfortunate for academic cryptographers that a wide variety
of new techniques are pioneered by non-academics.  But those
techniques exist nevertheless, and to the extent that academics do not
investigate them, those academics are not up with the state of the
art.  

It is not, frankly, the role of the innovator to educate the
academics, or even to serve technology to them on a silver platter.
In the end, academic reputation comes from reality, and the reality is
that many crypto academics avoid anything new which does not have an
academic source.  The consequence is that they simply do not have the
background to judge really new designs.  


>Thus, designs that are intentionally limited - to one basic type of round,
>to one underlying principle - have an advantage over designs based on the
>principle that security is the only goal. They might be less intrinsically
>secure, but they have a better chance of being able to (appear to) _prove_
>(indicate with some tendency to confidence) that they do have a certain
>level of security.

Upon encountering a new design, anyone may choose to simplify that
design and then report results from that simplification.  This is done
all the time.  It is not necessary for an innovator to make a
simplified design for this purpose.  

On the other hand, I have been pioneering the use of scalable
technology which, presumably, can be scaled down to a level which can
be investigated experimentally.  The last I heard, experimentation was
still considered a rational basis for the understanding of reality.
Indeed, one might argue that in the absence of theoretical strength
for *any* cipher, experimentation is about all we have.  But note how
little of it we see.  


>[...]
>Plus, the risk that one's adversary is a hacker of the future with a very
>powerful desktop computer seems much greater than the risk that one's
>adversary will be an accomplished cryptanalyst, able to exploit the most
>subtle flaws in an over-elaborate design.

But we don't know our Opponents!  If we have to estimate their
capabilities, I think we are necessarily forced into assuming that
they are more experienced, better equipped, have more time, are better
motivated, and -- yes -- are even smarter than we are.   There is
ample opportunity for them to exploit attacks of which we have no
inkling at all.  


>[...]
>While I respect the knowledge and ability of the acknowledged experts in
>the field, where I think I part company with Bruce Schneier and others is
>in the following:
>
>I believe it to be possible and useful to develop a design methodology -
>mainly involving the cutting and pasting of pieces from proven cipher
>designs - to enable a reasonably qualified person who, however, falls short
>of being a full-fleged cryptographer, to design his own block cipher, and
>thereby obtain additional and significant benefits in resistance to
>cryptanalytic attack by having an unknown and unique algorithm.

And in this way we can have hundreds or thousands of different
ciphers, with more on the way all the time.  That means that we can
divide the worth of our information into many different ciphers, so
that if any one fails, only a fraction of messages are exposed.  It
also means that *any* Opponent must keep up with new ciphers and
analyze and possibly break each, then design a program, or build new
hardware to exploit it.  We can make good new ciphers cheaper than
they can possibly be broken.  The result is that our Opponents must
invest far more to get far less, and this advantage does not depend
upon the delusion of strength which is all that cryptanalysis can
provide.


>I don't deny that there are pitfalls looming in such an approach; if
>something is left out of the methodology, or if it isn't conscientiously
>used, people could easily wind up using weak designs and having a false
>sense of security. I just think the problems can be addressed, and the
>potential benefits are worth the attempt.

Neat.

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


Subject: Re: Thought question:  why do public ciphers use only simple ops like shift and XOR?
Date: Fri, 16 Apr 1999 14:06:57 -0700
From: "Steven Alexander" <steve@cell2000.net>
Message-ID: <jKNR2.591$%L2.8044@news6.ispnews.com>
References: <37179b67.12809750@news.io.com>
Newsgroups: sci.crypt
Lines: 32



>>- Also, since there are many insecure cipher designs floating around, one
>>can't just accept that a cipher is secure based on its designer's say-so.
>>Instead, what gives real confidence in a cipher design is that it has been
>>studied by experts who have failed to crack it, but who have come away
from
>>their attempts with an understanding of the source of the design's
>>strengths.
>
>I dispute this.  This is essentially what Schneier would have us
>believe, and it is false.
>
>The truth is that we *never* know the "real" strength of a cipher.  No.....

I don't think that you understand the point that Schneier and others have
made.  If I(a nobody) create a new cryptosystem tommorrow, nobody will have
any confidence in it.  But, If I learn to break the ciphers of others and
use my experience to create a new cipher that others cannot break it will be
listened to because I am known to be knowledgeable in how ciphers work.
But, it will still not be trusted.  Only after many people have analyzed and
failed to break my cipher will people say..."his cipher has held up to
five(ten) years of cryptanalysis by very knowledgeable cryptanalysts.  We
can assume with an adequate level of confidence that the cipher will protect
our information."  However, it is still realized that  at any time someone
can invent a new cryptanalytic attack and my cipher will be rendered
useless.  Schneier and others have acknowledged that any cipher can be
broken at any time.

my $.02...-steven


Subject: Re: Thought question:  why do public ciphers use only simple ops like shift and XOR?
Date: Fri, 16 Apr 1999 22:32:57 GMT
From: ritter@io.com (Terry Ritter)
Message-ID: <3717ba72.20758328@news.io.com>
References: <jKNR2.591$%L2.8044@news6.ispnews.com>
Newsgroups: sci.crypt
Lines: 87


On Fri, 16 Apr 1999 14:06:57 -0700, in
<jKNR2.591$%L2.8044@news6.ispnews.com>, in sci.crypt "Steven
Alexander" <steve@cell2000.net> wrote:

>>[...]
>>I dispute this.  This is essentially what Schneier would have us
>>believe, and it is false.
>>
>>The truth is that we *never* know the "real" strength of a cipher.  No.....
>
>I don't think that you understand the point that Schneier and others have
>made.  
>If I(a nobody) create a new cryptosystem tommorrow, nobody will have
>any confidence in it.  

This is seriously disturbing:  The issue is not who makes a thing, but
instead what the thing actually is.  Deliberately judging a design in
the context of who made it is actually anti-scientific, and should be
widely denounced as the superstition it is.  


>But, If I learn to break the ciphers of others and
>use my experience to create a new cipher that others cannot break it will be
>listened to because I am known to be knowledgeable in how ciphers work.

Nonsense.  Knowing how to break some ciphers does not mean that you
know how ciphers work.  That idea *is* the point "that Schneier and
others have made" and it is a fantasy.  It is especially fantastic
when ciphers use technology which academics have ignored.  But in any
case, without a LOWER bound on strength, academics REALLY do not even
know that ciphers work *at* *all*, let alone how.


>But, it will still not be trusted.  Only after many people have analyzed and
>failed to break my cipher will people say...CRYPHTML.HTM"his cipher has held up to
>five(ten) years of cryptanalysis by very knowledgeable cryptanalysts.  

Nonsense.  There is no such conclusion.  Ciphers do not ripen like
cheese.

We first of all do not know how many attacks were made (if any), nor
how much effort was placed into them.  Attacks made by experienced,
well-paid, well-motivated teams with all the equipment they need are
quite different from those of single individuals working at a desk at
night and coming up with a new mathematical equation.  Not finding an
equation does not mean some team has not had success.  

We only know what success is reported in the academic literature.
Unfortunately, when we use a cipher, we are very rarely concerned
whether academics can break our cipher or not.  We are instead
concerned about "bad guys,"