Risks of Relying on Cryptography Discussion

Terry Ritter

A Ciphers By Ritter Page

This Usenet discussion starts with a rather innocuous article by Bruce Schneier, essentially stating that true security implies more than just a cipher. Because the AES project was running at the time, many of the conversations concerned AES. Often there was a desire to have more than one recognized winner of AES, so as to provide a fall-back position if the chosen cipher eventually was found to have some weaknesses. This is where I come in, because I have for some time promoted the use of multiple ciphers -- and multiple ciphering -- to hide weaknesses we do not currently recognize.

In these discussions, my major postings include:

• 1999-10-14: Here I lay out some of the logic for using multiple ciphers and multiciphering. This is not the origin of these thoughts, but is instead just yet another episode of a continuing issue which has been addressed many times, including a recent formal article in IEEE Computer. See, for example:
  • The IEEE Computer article and discussion, Sep 1999. Improving trust in ciphers through multi-ciphering and multiple ciphers.
  • The earlier discussion, Apr 1999. Multiple ciphers and multi-ciphering; background negotiation under cipher.
  • Multiple ciphers for E-mail, Mar 1996. Multiple ciphers with background negotiation.
• 1999-10-15: A standard cipher does not ensure interoperability; indeed, the reason ciphers have keys is to prevent interoperability.
• 1999-10-17: Trying to correct the typical outrageous exaggerations of my position.
• 1999-10-17: The odd situation of AES, which demanded that I provide an option on my patents -- without compensation -- simply to participate, to eventually obtain a cipher free for use worldwide, for which, nevertheless, most users must pay.
• 1999-10-17: We don't need a standard cipher; we need a standard cipher interface.
• 1999-10-17: Because we cannot measure cipher strength, we have no basis for a belief in cipher strength. Believing a cipher is strong is the historic basis for cryptographic disaster.
• 1999-10-17: The academic community cannot provide reassurance about the strength of a cipher. All that can be done is to say that academics do not know how to break the cipher. But if the opponents can read, they know at least as much as the academics, and probably have significant additional insights of their own.
• 1999-10-20: The start of a sad discussion based, as far as I can tell, on the premise that a simple cipher negotiation protocol is simply not possible. No proof is presented, of course.
• 1999-10-23: A detailed analysis of some of the problems inherent in a far-too-simple model of ciphering. Also see: 1999-10-29.
• 1999-10-30: The negotiation cipher needs to be different than the data cipher.

These postings are not in date sequence, but are essentially a depth-first traversal of the discussion tree. This places postings with the same issue close together despite posting date, but can be confusing. One possibility is to get to the terminal node we want, then follow that to the root or start, using the links implemented in each header, then back out in sequence using the browser "back" command. A modern 32-bit browser is probably required to handle the hundreds of internal links used here.

Contents

• 1999-10-10 Bruce Schneier: "Defending against these unknown attacks is impossible, but the risk can be mitigated with good system design."
• 1999-10-10 Mok-Kong Shen: "I like only to mention that some complementary and apparently also useful additional viewpoints may be found in the following reference: T. Ritter, Cryptography. IEEE Computer, Aug. 1999, p.94-95."
• 1999-10-10 DJohn37050: "Multiple encryption using different ciphers was also mentioned in my submission to the 2nd AES conference entitled "Future Resiliency: A Possible New AES Criterion" and is available from NIST AES web site."
• 1999-10-11 Mok-Kong Shen: "I believe that a part of the posts to a recent thread on Terry Ritter's paper could have been spared, were your paper known to the participants at that time."
• 1999-10-11 Sundial Services: "The essential point that Bruce mentions is that, if you build an immensely strong bank-vault door to your home, but beside it is an open window ... then your home is -worse- than insecure."
• 1999-10-11 Mok-Kong Shen: "What do you have against e.g. multiple encrpytion with the top three algorithms of the final round of AES instead of with the winner of AES alone?"
• 1999-10-11 Trevor Jackson, III: "Is it your positiom that there is no circumstance justifying multi-level encryption?"
• 1999-10-12 Bruce Schneier: "Of course not."
• 1999-10-12 Trevor Jackson, III: "3DES may be too slow for many (?) applications, but it might also be fast enough for many (?) applications."
• 1999-10-12 Brian Gladman: "So let me understand this - those who advocate controlled diversity of algorithm choice through multiple AES winners are driving a single stake in the ground while those who advocate a single AES winner are building a broad palisade."
• 1999-10-12 DJohn37050: "Yes, sometimes the value of the message is so high that it is appropriate to use encrytion with multiple algorithms, just in case one would break."
• 1999-10-12 Mok-Kong Shen: "I warmly recommend those of the group who haven't yet read Don Johnson's paper to do so (access via AES of NIST)."
• 1999-10-12 DJohn37050: "And if you want to see my thoughts on future resiliency from an asymmetric algorithm viewpoint, see my presentation and paper made at PKS '99 at www.certicom.com"
• 1999-10-12 Brian Gladman: ". . . I now see from this and other posts that you are not denying the existence of situations where multiple sequential encryption using different algorithms will have a positive security value."
• 1999-10-13 John Savard: "The author of this proposal has had many useful ideas . . . but without appreciating or acknowledging the value of the 'conventional' point of view . . . it will certainly lead to the merits of his ideas not getting a fair hearing."
• 1999-10-14 Terry Ritter: "If we could believe that any one cipher is forever unbreakable, we would need no more than that. Our problem is that there is no such evidence." "The point of having many "cipherings" is *not* to increase keyspace per se, but instead to give us the frequent opportunity to change from one ciphering to another, thus terminating any break which may have occurred."
• 1999-10-15 John Savard: "It's obviously wrong if you jump from "no cipher is proven secure" to "all ciphers are equally bad"." "To be "part of the solution", however, one has to be more than a "voice crying in the wilderness". And that involves paying the conventional wisdom its due, and recognizing that due."
• 1999-10-17 Terry Ritter: "I don't believe that, I doubt I ever said it, and find it hard to imagine that anyone could reasonably interpret my words to have that meaning." "No matter how many clear unambiguous statements I make, however, it is rather easy for you to misstate my position, as you yourself did in your earlier posting . . . ." "There is no "due." The conventional wisdom *caused* the situation by failing to practice the Science they claim to support. Nor are they in any hurry to correct their error despite the fact that society will actually depend upon this stuff. That hardly deserves respect."
• 1999-10-17 John Savard: "The specific part of the conventional wisdom at issue here is the importance of extensive study and testing of any cipher."
• 1999-10-16 bryan.olson@uptronics.com: "His summary was fine; your claim above is simply non responsive."
• 1999-10-12 Dan Day: "We pulled a similar dodge back when I was in college..."
• 1999-10-11 Trevor Jackson, III: "This is almost exactly the technique used to crack multics . . . ."
• 1999-10-11 Brian Gladman: "The principle of using two different algorithms in sequence to achieve a degree of protection against any individual weaknesses that they might have is a well established technique . . . ."
• 1999-10-11 DJohn37050: "Brian says it so well."
• 1999-10-14 Brian Gladman: "There are at least three reasons for wanting more than one winner . . . ."
• 1999-10-14 Bruce Schneier: "In software it's no problem adding another algorithm, but it is in hardware." "My primary worry is that a system that has a choice of algorithms will, operationally, be as secure as the weakest."
• 1999-10-14 Brian Gladman: "While we should, of course, take the concerns of hardware suppliers into account, we should also recognise that other suppliers will be able to provide algorithm diversity without great difficulty and will see market advantages in doing so (as they do now)." "I agree that there are engineering issues involved in using mutiple algorithms that can cause problems but these are not necesarily difficult to overcome."
• 1999-10-14 Mok-Kong Shen: "If we'll have 3AES, then it certainly wouldn't be a big step in my humble opinion to employ instead the three top ones in the final round of AES contest for multiple encryption."
• 1999-10-14 Roger Schlafly: "What do the bankers mean by the term "future resiliency"? That the AES winner not be broken in the future?"
• 1999-10-15 Peter Galbavy: ". . . is there a mandatory surrender of those rights required to complete ?"
• 1999-10-16 David A Molnar: "Not to compete, but the winner must be freely available to all in the same fashion as DES and DSA are."
• 1999-10-17 Terry Ritter: "To compete, one first had to give up rights *if* one's entry was chosen by NIST. That is called an *option* on rights, and options are not normally free, yet there was no compensation for meeting this requirement." "Oddly, "free" does not mean free to the end user: Software using AES is not required to be free. Hardware using AES is not required to be free. Apparently, "free" means that the manufacturers get some of their raw materials free, so they can have higher profits."
• 1999-10-19 Tim Tyler: "There is no such thing as a non-military cryptographer: Business is war (Japaneese proverb)."
• 1999-10-14 Bob Silverman: "By allowing multiple algorithms you are certain to guarantee that there will be some users who can't talk to others."
• 1999-10-14 Brian Gladman: "True, but also true if a single AES winner is chosen since we are not to my knowledge insisting that everyone uses it."
• 1999-10-15 Patrick Juola: "The individual participant/employees of the companies involved are probably not going to be able to "dynamically select" their encryption scheme; they will use what's on their desk."
• 1999-10-15 Roger Schlafly: "When they put in fax and email standards, they didn't deliberately introduce incompatible formats for diversity purposes."
• 1999-10-15 DJohn37050: " . . . In fact there are multiple fax transmission protocols, each vendor came up with one and then cross licensed with others."
• 1999-10-15 Roger Schlafly: "Yes, there were multiple protocols until a standard was adopted."
• 1999-10-20 Patrick Juola: "One of the major methods the British used to crack the (difficult) German cyphers was by using or even creating known-plaintext in other cyphers."
• 1999-10-20 Tim Tyler: "I was talking about changing cyphers at regular intervals . . . ."
• 1999-10-19 Mok-Kong Shen: ". . . one can manage to live with some non-interoperability."
• 1999-10-14 Brian Gladman: "Its a good security principle to have (a) defence in breadth, (b) defence in depth, and (c) a fall back plan for when things go wrong. Algorithm diversity is about (c) and to some extent (b)."
• 1999-10-14 Roger Schlafly: "The AES candidates all offer a choice of keys -- those are your options."
• 1999-10-15 Brian Gladman: ". . . the need for resiliance requires that we increase the number of algorithms."
• 1999-10-15 Brian Gladman: "I have a high level of trust in the AES process but since I have a lot at stake I want a fall back position in case things go wrong."
• 1999-10-15 Roger Schlafly: "No, you are asking for a triple-AES solution because you don't trust AES."
• 1999-10-15 Mok-Kong Shen: "Triple DES standard doesn't burden those that use single DES, as far as I am aware."
• 1999-10-16 Roger Schlafly: "Sure it does -- they don't interoperate."
• 1999-10-16 Mok-Kong Shen: "People that use triple DES don't use single DES and vice versa. So there is no need of inperoperability."
• 1999-10-16 Roger Schlafly: "Exactly. No interoperability."
• 1999-10-16 Jerry Coffin: "I would keep in mind, however, that using the same algorithm doesn't guarantee interoperability, and having two (or more) algorithms available doesn't prevent it." "I doubt it takes more than 100 lines of code on average to implement the AES finalist algorithms."
• 1999-10-16 David Wagner: "In software, it's easy; in hardware, it's a huge added cost."
• 1999-10-16 Trevor Jackson, III: "A single-chip implementation of just the cipher might sustain a 100% or so increase in cost. But an appliance will see only a few percent increase in cost."
• 1999-10-17 Jerry Coffin: "The TwoFish FPGA implementation uses an equivalent of roughly 28,000 gates." "In a modern .18 micron fabrication, 200,000 gates should fit in less than 4.5 square millimeters, which can be fabricated in reasonable quantities at a cost of approximately one dollar per chip."
• 1999-10-18 David Wagner: "And yet, the hardware folks seem to disagree strongly."
• 1999-10-19 David Wagner: "Do your comments apply to small resource-starved devices, such as cellphones?"
• 1999-10-19 Jerry Coffin: "A cell phone would generally be an _ideal_ candidate for a software implementation."
• 1999-10-19 David Wagner: "I've heard some complaints that, at least for some of the AES finalists, software just won't offer good enough performance."
• 1999-10-20 Andrew Haley: "I imagine that a FPGA implementation of the Shrinking Generator with reasonable register lengths could be done with hundreds of gates, and almost certainly less than 1000."
• 1999-10-17 Terry Ritter: "It is not much of a leap to talk about a stand-alone ciphering chip which takes as its state a flash of various ciphers which it can then execute."
• 1999-10-18 Bruce Schneier: "Think of the applications where crypto is going to be used by the masses: smart cards, routers, cellphones. These are hardware devices, and adding a second algorithm is a great burden."
• 1999-10-18 Bruce Schneier: "If I developed a pay-TV application, for example, and use DES in all the transmitters and set-top boxes, switching to triple-DES is a very large burden."
• 1999-10-19 Mok-Kong Shen: ". . . there is no reason to say that the (parallel) existence of the triple-DES standard leads to disadvantages of those using single DES (those who don't want, don't need and don't care to use triple DES)."
• 1999-10-16 Brian Gladman: "I have a high level of trust in the AES process and I am very confident that the probability that a single winner will later be found to have a serious flaw is very, very small. But I don't have absolute trust in the winner because this probability cannot be shown to be zero."
• 1999-10-16 Patrick Juola: ". . . the whole point of computer -- or more generally, communications -- networks is to permit communication between widely distant and possibly unfamilar parties."
• 1999-10-17 Mok-Kong Shen: "Highly secure communication is different from public communication . . . ."
• 1999-10-17 DJohn37050: "Just want to point out that the idea of multiple encryption using diff. algs (Super AES), etc. is fairly obvious."
• 1999-10-17 Terry Ritter: "And, if there were a standard cipher *interface*, anytime you needed to use a different cipher to "interoperate," you could just plug that cipher in."
• 1999-10-15 Terry Ritter: "The use of *keys* limits interoperability -- to those who have the right keys. We now do arrange to transfer keys as needed. We could arrange to transfer the name of the cipher to be used, or even the cipher itself."
• 1999-10-15 Roger Schlafly: ". . . diversity for the sake of diversity would not have helped htem much, and might have even hurt them because the alternative ciphers might be more easily broken.."
• 1999-10-15 DJohn37050: ". . . the best groups PLANNED to have their ciphers go away, they figured that they were broken after being in use for some time even if they were not."
• 1999-10-15 Mok-Kong Shen: "I suppose it is (generally) assumed in the current discussion that the top three candidates in the final round of AES contest are approximately of the same quality . . . ."
• 1999-10-17 Terry Ritter: "In contrast, we *know* what happens when someone is convinced their cipher is strong enough: the classic examples are Germany and Japan in WWII."
• 1999-10-16 David A Molnar: You (or anyone else reading) may want to look at this master's thesis on "Self-Describing Cryptography" . . . ."
• 1999-10-18 Bruce Schneier: "Ciphers like this generally have lots of weak keys--they are as secure as the weakest transformation in the family--and are usually stronger without the secondary key."
• 1999-10-18 Bruce Schneier: "IPsec is much less secure because of all the options it has. Complexity is security's worst enemy."
• 1999-10-18 Brian Gladman: "I consider Twofish to be a more complex algorithm than RC6 but I don't judge this to mean that RC6 is necessarily more secure than Twofish. There is more to it than that."
• 1999-10-15 Mok-Kong Shen: "Remember that triple DES IS a seperate standard from single DES."
• 1999-10-15 Trevor Jackson, III: "Two standards doe snot mean ero standards. Two standards means two standards. 2 != 0."
• 1999-10-15 Trevor Jackson, III: "It isn't ideal. It's reality."
• 1999-10-16 John Savard: "The AES entrants only promised to allow free use of their ciphers if their own cipher was _the_ winner of the AES process."
• 1999-10-18 Bruce Schneier: "Heh. It's probably against the rules, though."
• 1999-10-12 John Savard: "If one encrypts with a separate box with, say, a little 68HC11 inside of it, one can keep those keys locked away rather better."
• 1999-10-12 Bruce Schneier: "E-mail encryption is a perfect application where cascades are reasonable."
• 1999-10-15 dianelos@tecapro.com: "Much of this thread has been about cascading ciphers as a way to increase security. What I find interesting is that only a few months ago many in this newsgroup thought that this is a bad idea."
• 1999-10-16 John Savard: ". . . sometimes we don't *know* all the shortcomings of a cipher. So, if we pile up several _very different_ ciphers, we do have an additional degree of reassurance."
• 1999-10-17 Terry Ritter: "I claim that we *never* know "all the shortcomings of a cipher," absent some sort of mathematically provable security in practice."
• 1999-10-15 Patrick Juola: ". . . we should make sure that all telephones interoperate."
• 1999-10-11 wtshaw: "Basic Security 101, or ought to be."
• 1999-10-14 Anonymous: "Could you please explain what you mean by multiple algorithms or ciphers."
• 1999-10-14 Mok-Kong Shen: "I would assume (1) n cipers are selected, n = constant, (2) these are ordered, (3) these have the same block size, (4) each block is sequentially enciphered by the n ciphers, (5) there is no chaining."
• 1999-10-18 DJohn37050: "No one is saying that an implementation cannot choose one algorithm, just allow the ones that want to (for whatever reason) to be allowed to implement more than one and do this in the context of the standard."
• 1999-10-18 Roger Schlafly: "Bankers are not the best ones to be making communications security decisions."
• 1999-10-19 Bob Silverman: "Then it is no longer "a standard"."
• 1999-10-19 DJohn37050: "To be perfectly clear, there were really 2 votes at X9F1 on Future Resiliency."
• 1999-10-19 Roger Schlafly: "It sounds to me that you got a meaningless resolution passed, and now you are pretending that it was an endorsement of your ideas."
• 1999-10-20 Roger Schlafly: "If I were on the committee, I would vote AGAINST any proposal that NIST name multiple winners."
• 1999-10-20 Rich Ankney: "I was at this meeting. IIRC, the vote was to suggest to NIST that multiple algorithms should be allowed for AES."
• 1999-10-21 DJohn37050: "Yes, Roger refuses to be convinced, so I keep clarifying, and he keeps refusing."
• 1999-10-20 Roger Schlafly: "If Don thinks that the text of the motion supports his case, let him post it."
• 1999-10-19 Trevor Jackson, III: "There is no problem having multiple "standard ciphers"."
• 1999-10-18 Trevor Jackson, III: "If we select a single AES "winner" the switch to VAES will be extremely painful."
• 1999-10-19 DJohn37050: "The "Future Resiliency" presentation I made to X9F1 was EXACTLY the paper I submitted to 2nd AES, namely that there should be more than one winner . . . ."
• 1999-10-18 Roger Schlafly: "I think you are flattering yourself."
• 1999-10-19 Brian Gladman: "If you don't believe me check with NIST."
• 1999-10-19 DJohn37050: ". . . it was a vote on what action, if any, to make as X9F1 to NIST in regards to this issue."
• 1999-10-19 Roger Schlafly: "So post the text of the motion . . . ."
• 1999-10-15 Bob Silverman: ". . . hardware vendors are not going to build AES based devices with multiple algorithms."
• 1999-10-15 DJohn37050: ". . . there will be systems which need to choose just one algorithm . . . ."
• 1999-10-17 Terry Ritter: "Modern "hardware" systems often consist of embedded processors and "firmware" based in flash."
• 1999-10-17 Roger Schlafly: ". . . I am sure that they would rather devote those resources to something more useful . . . ."
• 1999-10-18 Trevor Jackson, III: "Basic point is not to have multiple ciphers in the router, but to have multiple ciphers from which to choose when building the router."
• 1999-10-18 Roger Schlafly: "Cisco is not going out of business because it only offers AES/Rijndahl and the competition is supplementing it with one of the AES rejects."
• 1999-10-23 Tim Tyler: "That statement is /so/ strong it is almost certain to be wrong."
• 1999-10-24 A [Temporary] Dog: ". . . always read "never" as "for the foreseeable future"."
• 1999-10-24 Trevor Jackson, III: "In English never means not ever; and NEVER means not-ever-and-I-really-mean-it!"
• 1999-10-24 A [Temporary] Dog: "BTW, we're doing dueling aphorisms here - what's your contribution?"
• 1999-10-28 Tim Tyler: "These people need to dictionaries for Christmas . . . ."
• 1999-10-16 DJohn37050: ". . . NIST has ALWAYS said there may be one or more winners."
• 1999-10-18 Bruce Schneier: "Correct. I remember Miles saying something like "we will choose approximately one winner.""
• 1999-10-18 DJohn37050: "I recall Miles being very clear on the fact that there might be multiple winners."
• 1999-10-18 Trevor Jackson, III: "Should we then blindly follow this process or should we point out the foolishness it implies."
• 1999-10-18 Trevor Jackson, III: ". . . GM was one of the organizations that dissed hybrid drive designs with similar logic."
• 1999-10-19 DJohn37050: "It is REQUIRED to put 2 independent BRAKE systems in EVERY CAR. This is for safety."
• 1999-10-19 Johnny Bravo: "LOL, not quite the case."
• 1999-10-19 Johnny Bravo: "I would hardly call such an ineffective system a backup."
• 1999-10-19 Mok-Kong Shen: "It is not whether one 'can' or 'cannot' use more than one AES candidates . . . ."
• 1999-10-19 John Savard: "Actually, that's already been done."
• 1999-10-19 Mok-Kong Shen: "Simply to have a NIST spokesman say some words in that direction at a press conference is certainly not enough."
• 1999-10-20 DJohn37050: "What I want is for NIST to certify that a few AES algorithms are allowed for federal gov't use."
• 1999-10-19 DJohn37050: "In my AES paper, I used the term future resiliency to mean the ability to not depend on only one algorithm."
• 1999-10-19 Bruce Schneier: ". . . adding more encryption algorithms necessarily makes the system weaker."
• 1999-10-19 John Savard: "I've been *strongly* critical of Terry Ritter for wording some of his posts in ways that imply his multi-ciphering proposal is _everything_, and the confidence we get in ciphers from their study and analysis is _nothing_."
• 1999-10-19 wtshaw: "If either cipher or both are as good as you think, you have to break both to solve the message."
• 1999-10-20 John Savard: ". . . what I've described - albeit with emphasis on the precautions I think are important - is Terry Ritter's proposal, not mine."
• 1999-10-20 wtshaw: "That is the way of course, to keep things decipherable."
• 1999-10-20 Brian Gladman: "If implemented correctly, sequential encryption using different algorithms can provide protection in a situation where one of the algorithms being used contains an as yet undiscovered weakness."
• 1999-10-20 Mok-Kong Shen: "Has anybody made serious thought of the possibility of extracting some of the good ideas from each submitted AES candidate . . . ."
• 1999-10-20 Brian Gladman: ". . . I am rather uncertain that those who have the knowledge to do this would want to repeat the process of algorithm development . . . ."
• 1999-10-20 DJohn37050: "I think the reason to standardize on a block cipher are . . . ."
• 1999-10-20 Vernon Schryver: "All protocols that involve the parties agreeing on one choice out of two or more alternatives have major problems in the real world."
• 1999-10-20 Terry Ritter: "Modern modems have many modes, speeds, and parameters, and yet do manage to exchange them in real time to good effect."
• 1999-10-20 Vernon Schryver: "How can you point to modems as a good example of the wonders of negotiating protocols?"
• 1999-10-23 Terry Ritter: "I think the real world applies: We have such modems. We use them. They work. End of story."
• 1999-10-23 Roger Schlafly: "I don't think NIST was planning on standardizing a cipher negotiation protocol . . . ."
• 1999-10-23 Terry Ritter: "I see no reason why the negotiation protocol must be "cryptographic" . . . ."
• 1999-10-26 David Wagner: "If you have a non-cryptographic negotiation protocol, you might end up with the weakest of the ciphers supported by both ends, rather than the strongest of them."
• 1999-10-26 SCOTT19U.ZIP_GUY: "This is why organizations should not trust browsers to automatically encrypt there data before it is sent out on the net."
• 1999-10-26 John Savard: "By making the use of a "strong" cipher mandatory, as I've advocated, if worst comes to worst the weak ciphers are still adding to strength, by supplying whitening, at the least, for the strong ciphers."
• 1999-10-29 Terry Ritter: "I suppose TCP/IP might be called "cumbersome and impractical" -- until one starts to feel the advantages." "The dynamically changing cipher scheme may be complicated for some people to think about, but that is mainly an issue for implementors."
• 1999-10-29 Vernon Schryver: ". . . TCP/IP's detractors did not complain that it was "cumbersome and impractical" but "simplistic and impractical.""
• 1999-10-29 Terry Ritter: ". . . if you don't change your cipher you might *also* end up using the weakest of the ciphers *AND* never changing it."
• 1999-10-28 David Wagner: "The difference is who chooses your ciphers."
• 1999-10-29 Terry Ritter: "I have never heard -- and certainly never made -- a suggestion that the adversary will choose the cipher. On the contrary, I have suggested that each user be able to create a list of ciphers they will accept, and then negotiate agreement -- automatically, in the background, and secretly, under the cover of cipher." "Picking a cipher -- necessarily without proof of strength -- and then using it forever would seem to be the weakest possible way to employ any cipher, and yet you continue to support this."
• 1999-10-29 Jerry Coffin: "IMO, to maintain any hope of improving security, you need to ensure that the cipher used in the negotiation phase is _different_ from any of the ciphers that can be selected by the negotiation."
• 1999-10-29 Vernon Schryver: "A man in the middle who has broken the initial cipher could prevent what the PPP community calls "convergence" on choosing the next cipher."
• 1999-11-03 Vernon Schryver: "If you can detect any and all men in the middle who have broken the initially "secure and certified" link, then there less reason to negotiate additional ciphers."
• 1999-11-03 John Savard: "But the idea is that one could use something on the order of heptuple-AES as the initial cipher, and now that the algorithms are *variable*, one could get by with _mere_ triple encryption thereafter."
• 1999-10-30 Terry Ritter: "One possibility is to use an *additional* cipher on the negotiation data."
• 1999-10-29 Trevor Jackson, III: "Rather than create a global namespace for ciphers, one could simply reserve cipher zero for plain text."
• 1999-10-30 Terry Ritter: "The distinction I wish to draw is between the complexity of common cryptographic protocols, versus a basic selection and handshake."
• 1999-10-30 Trevor Jackson, III: "Why deliver only one when you can deliver a list?"
• 1999-10-30 John Savard: ". . . I think the intent was to state that the protocol need not be an elaborate one with special properties . . . ."
• 1999-11-03 ritter@io.com: "Do you seriously suggest that one would build a cipher system *without* (effectively) having error-detection on the plaintext or ciphertext?"
• 1999-11-02 bryan.olson@uptronics.com: "Yes, you failed to consider the chosen cipher attack . . . ."
• 1999-11-04 Terry Ritter: "A "chosen cipher attack" would imply that the opponent could choose the cipher to be used. That is not possible here. "
• 1999-11-05 bryan.olson@uptronics.com: "One side can certainly make a random choice, but your method calls for them to agree, and thus the choice must be influenced by messages between them."
• 1999-11-08 Terry Ritter: "Whatever cipher system has been established will authenticate received messages in some way (often with a hash of the plaintext), and thus will detect "any" attempt by an attacker to "modify the messages." This is very well known technology, and -- again -- there should be little need to describe it in detail."
• 1999-11-11 bryan.olson@uptronics.com: "This authentication was completely missing from your suggestion before others pointed out the problem."
• 1999-11-11 Terry Ritter: "Your peculiar concentration on "authentication" obscures the real problem, and that problem is that the original cipher must be secure in many ways, including algorithm, key, and implementation."
• 1999-11-12 bryan.olson@uptronics.com: "Suppose all parties are given an authentic certificate for Bob's public key. Alice sends her list of ciphers to Bob, encrypted under Bob's public key. Fred blocks the message from Alice and substitutes his own list . . . ."
• 1999-11-13 Terry Ritter: "There is something seriously wrong with a cipher system which allows messages to be substituted by anyone who happens to have a non-secret public key." "This is not an issue for the cipher-change protocol. It *is* an issue which must be considered in every public-key design."
• 1999-11-15 bryan.olson@uptronics.com: "I point out that ciphers imply secrecy, but not authentication, and thus the attacker can influence the choice of cipher."
• 1999-11-01 Stefek Zaba: "The resulting cipher negotiation process is, while not "minimal", pretty small - it passes the "back-of-the-envelope" test . . . ."
• 1999-11-02 dianelos@tecapro.com: "If I send a message containing my information, it should be I who defines how to encrypt it - not the other party in some way. Security should not be negotiable."
• 1999-11-02 SCOTT19U.ZIP_GUY: "I know I am getting in this late but if one person has his heart set on 3DES and another AES_! why not allow them to use both in series so that both methods can be used at once."
• 1999-11-02 Trevor Jackson, III: ". . . I suspect you still need to resolve the original issue, selecting ciphers dynamically, because I may decide that to change the cipher that I selected."
• 1999-11-02 dianelos@tecapro.com: "Well, if I trust 3DES and don't trust AES1 then I should be able encrypt my messages with 3DES only."
• 1999-11-03 Trevor Jackson, III: "Why would you want to choose? It would normally be completely automatic to the point of transparency. All you have to do is order (sort or prioritize) your own list."
• 1999-10-23 Vernon Schryver: "A cipher negotiating protocol that failed as often as modems fail today in real life would not be something I'd want to trust my phone bill to, not to mention something that matters."
• 1999-10-24 Terry Ritter: "Cipher negotiation is not in itself cryptographic. It can and should occur under the current cipher(s) and should be a straightforward selection. This negotiation occurs is not in the part of the chain which is affected by noise, line levels, or other dynamic qualities." ". . . I only wish to say that cipher negotiation is realistic and possible in real systems; it can hardly be opposed out of hand as "impossible" technology."
• 1999-10-24 Vernon Schryver: "What I have been saying is that the inevitiable complications of cipher negotiating are inevitably both large and problematic. Worse, those inevitiable problems will include breaks in security." "I agree changing ciphers is an interesting idea. However, at best you demonstrate traits unbecoming a "practicing engineer" when you describe negotiating ciphers as "modest additional complexity." Good engineers don't pronounce on things they know nothing about, and they don't lie about things they do know about." And after that, of course, we have nothing more to discuss . . . .
• 1999-10-25 Vernon Schryver: "No, please do not bother responding."
• 1999-10-24 Vernon Schryver: "You're evidently as much of a "practicing engineer" as Terry Ritter."
• 1999-10-24 vjs@calcite.rhyolite.com: "You're evidently as much of a "practicing engineer" as Terry Ritter."
• 1999-10-25 Trevor Jackson, III: "Do you have an issue that you think will be difficult to solve or not? Are you simply raining on a parade or are you actually presenting a rational argument?"
• 1999-10-25 Vernon Schryver: "My impression of you is of a teenager typing in his grandfather's shop." "I'm sorry, but I do not believe that you have ever seen much DECnet or any other network code."
• 1999-10-25 Trevor Jackson, III: "Do you have an issue that you think will be difficult to solve or not? Are you simply raining on a parade or are you actually presenting a rational argument?"
• 1999-10-25 wtshaw: "To change cryptosystems, just do it; at the other end, detection falls out of lock as the current system fails to recover reasonable output, and go back to checking the various algorithms, getting the new system, locking until unlocked."
• 1999-10-25 jgfunj@vgrknf.arg: "To change cryptosystems, just do it; at the other end, detection falls out of lock as the current system fails to recover reasonable output, and go back to checking the various algorithms, getting the new system, locking until unlocked."
• 1999-10-25 Vernon Schryver: "The worst result of the compression negotiation complications . . . is that you can't count on your PPP data being compressed. The equivalent result for negotiating ciphers, not being able to count on your data being encrypted, strikes me as a little more serious."
• 1999-10-25 vjs@calcite.rhyolite.com: "The worst result of the compression negotiation complications . . . is that you can't count on your PPP data being compressed. The equivalent result for negotiating ciphers, not being able to count on your data being encrypted, strikes me as a little more serious."
• 1999-10-25 wtshaw: "It does not follow that if you pick a sending cipher, from a list that you are ready to use, that you worry about your data not being encrypted."
• 1999-10-25 Trevor Jackson, III: "This becomes trivial if the initial message contains a standard plaintext."
• 1999-10-26 wtshaw: "As you say, putting encrypted text at the beginning makes algorithm verification reasonable."
• 1999-10-29 Terry Ritter: "Either end could and should have their own list. Either end could propose a cipher from that list, or send the whole list. When the other end accepts, or sends back a cipher name that can be accepted, the cipher changes." "Also I would support a different cipher in each direction, thus simplifying the negotiation process."
• 1999-10-26 dianelos@tecapro.com: "In a world that is interconnected and software driven, you don't have to physically add code, just point to a place where certified code can be downloaded from (as you say just "name" it). If the code is in Java you have a solution that is global in scope and flexible."
• 1999-10-20 Mok-Kong Shen: ". . . I would like to see one or two competent professionals undertaking the task of carefully surveying all the submitted candidates and extracting out what is most valuable in each of them such that these knowledges could be appreciated and understood by all having interest in cryptology."
• 1999-10-21 John Savard: "Well, I've gone beyond *thinking* about it. Look at Quadibloc II through Quadibloc VI on my web site."
• 1999-10-20 Mok-Kong Shen: "It is the underlying idea (basic principle) that one needs."
• 1999-10-22 Mok-Kong Shen: "I can well inmagine that it is true that the number of rounds should increase with the key size . . . ."
• 1999-10-20 Jonathan Lundell: ". . . what we have here is a breakdown of the "weak link" metaphor."
• 1999-10-19 DJohn37050: "First group says: Anything is better than nothing which is about what we have now, so lets make it simple and choose one. Second group says: Hey, not so fast, what if one breaks? . . . "
• 1999-10-20 Mok-Kong Shen: "If a cipher has weakness that can be exploited . . . a very large key space alone doesn't necessarily give one a very good and comfortable feeling of security . . . ."
• 1999-10-20 DJohn37050: "Jerry, you have a GREAT reason to have more than one AES winner, in a satellite, the cost of more than one is small, but the cost of another satellite is huge."
• 1999-10-19 Trevor Jackson, III: "What would happen if a suspicion were cast over "the" single AES winner?"
• 1999-10-20 bryan.olson@uptronics.com: "For truly serious privacy systems, how easily we can replace it if we find it's broken is far from the greatest of our worries."
• 1999-10-20 Trevor Jackson, III: "For those very serious situations I'd suggest multiple encipherment."
• 1999-10-20 Jerry Coffin: "On one hand, I agree that having some sort of backup in a satellite is a good idea."
• 1999-10-20 Roger Schlafly: "I think they oppose standards for ideological or business reasons. Most of these arguments could be used against any standard."
• 1999-10-21 Jerry Coffin: "This sounds suspiciously similar to the scenarios you describe as an undesirable result of having more than one winner in the AES competition."
• 1999-10-21 Mok-Kong Shen: "In one point Mr. Schneier has clearly and definitely erred, namely concerning his phrase about randomly choosing a cipher."
• 1999-10-21 Brian Gladman: "If there are, say, two ciphers to choose from then 1-bit is necessary to make this choice so it is reasonable to ask which would be stronger when this scheme using n-bit ciphers is compared with the use of a single cipher with an (n+1)-bit key."
• 1999-10-22 Trevor Jackson, III: "How can you form quantitative risk estimates?"
• 1999-10-22 Mok-Kong Shen: "Because of the inherent difficulty of quantifying crypto strength, I believe it will be much more difficult to rank the top three AES candidates than to rank three cars of the same price category."
• 1999-10-23 Terry Ritter: ". . . it is NOT "reasonable" to ask which cipher would be stronger -- if one also expects a reply." "The primary advantage of choosing among multiple ciphers is NOT to provide keyspace, but instead to allow changing to a new cipher."
• 1999-10-23 John Savard: ". . . I did just that recently in response to an article in a recent issue of Crypto-Gram."
• 1999-10-24 Mok-Kong Shen: "You can apply a load to a beam until it crashes and anyone can do the same and obtain the same result. How do you apply 'something' in the first place to a component of a cipher until it is broken?"
• 1999-10-25 jgfunj@vgrknf.arg: "Ah..so much depends on the meaning of strength."
• 1999-10-24 dianelos@tecapro.com: "Interestingly enough, I discussed precisely this question in an older post . . . ."
• 1999-10-24 Terry Ritter: "Using a random message key value to select a cipher sounds rather similar to using a random value to select a cipher."
• 1999-10-25 dianelos@tecapro.com: "Well, I meant this: If you choose ciphers from the pool in a way that depends on the key then, by definition, the attacker will not know a priori which cipher is being used for each block."
• 1999-10-25 Mok-Kong Shen: "Using variable keys as proposed by me in another thread, such attacks presumably have to be considered in a different perspective."
• 1999-10-25 mok-kong.shen@t-online.de: "Using variable keys as proposed by me in another thread, such attacks presumably have to be considered in a different perspective."
• 1999-10-25 Trevor Jackson, III: "If the plaintext space is so well defined that it is the difference between plaintext and noise is detectable than an inadequate compression has been used."
• 1999-10-25 fullmoon@aspi.net: "If the plaintext space is so well defined that it is the difference between plaintext and noise is detectable than an inadequate compression has been used."
• 1999-10-26 dianelos@tecapro.com: "If the plaintext is compressed then you decompress it and see if it is intellible."
• 1999-10-28 dianelos@tecapro.com: "By cascading two ciphers you greatly increase the cost of most known attacks but there is a chance that in the future a new attack will work even against the cascade. Using two ciphers in random sequence wipes out whole classes of attacks."
• 1999-10-24 Roger Schlafly: "Even if your analysis is correct, it is stronger by only a trivial amount."
• 1999-10-24 Terry Ritter: "Using different ciphers is not an attempt to gain more keyspace." "By changing the cipher we thus terminate any existing break which we cannot expect to know about anyway."
• 1999-10-24 dianelos@tecapro.com: "If my analysis is correct then it shows that it does make sense to use a pool of independent ciphers because it increases security (against any attack) without decreasing the speed of the system."
• 1999-10-26 David Wagner: "The problem is that it is very challenging to ensure that all of the resulting ciphers truly are "independent" of each other."
• 1999-10-27 dianelos@tecapro.com: "Very challenging indeed. Any ideas about how it could be done?"
• 1999-10-28 wtshaw: "Strangely, the answer might be in another thread, some sort of compression to work against *sameness* . . . ."
• 1999-10-26 David Wagner: "Why do you assume that the complexity of attack is linear in the keylength?"
• 1999-10-27 dianelos@tecapro.com: "It seems to me that if an attack's complexity grows slower than linear in the key length then the argument becomes stronger . . . ."
• 1999-10-22 Paul Crowley: "If one cipher has an attack requiring 2^20 plaintexts and 2^50 work, and the other 2^30 plaintexts and 2^30 work, then an attacker will be able to recover messages providing they can mount *either* attack, thus making the overall system weaker than either cipher used on its own." "Cipher strength is not measured on a single linear scale."
• 1999-10-22 Mok-Kong Shen: "The bigger problem is there is no exact scale at all, not even a non-linear scale that is scientifically rigorously sound like the scale to measure distance."
• 1999-10-23 Terry Ritter: "The alternative to using a variety of ciphers, of course, is to depend upon something which explicitly cannot be depended upon."
• 1999-10-21 Brian Gladman: "On what experience base do you assert that satellites are a 'moronic example' of the practical use of encryption?"
• 1999-10-21 Roger Schlafly: "I'm sorry, but I agree with Bruce. It is a moronic example."
• 1999-10-21 Jerry Coffin: "So, if I'm understanding this correctly, when you say "I agree with Bruce" you really mean "Bruce's conclusion was right, but his reasoning was completely wrong from beginning to end.""
• 1999-10-21 Roger Schlafly: "The system will have many portions."
• 1999-10-22 Trevor Jackson, III: "Are you speaking Ex Cathedra or are we permitted to know the reasoning behind your pronouncement?"
• 1999-10-22 Jerry Coffin: ". . . having multiple hard-coded algorithms DOES provide a credible solution to at least most of the problem.
• 1999-10-22 David Wagner: "You seem to assume that you will know when someone breaks your algorithm." "History suggests that this is unlikely -- the adversaries who are most likely to spend a lot of effort patiently searching for weaknesses are also the ones who are least likely to tell you when they break your cipher."
• 1999-10-22 Jerry Coffin: "Your suggestion seems to be that since you MAY not know when you have a problem, that it's best to stick your head in the sand and simply assume that you'll never have a problem, at least in this area."
• 1999-10-22 DJohn37050: "Yes, the effect of having multiple algs increasing the cost/benefit ratio to an attacker was mentioned in my AES paper."
• 1999-10-22 David Wagner: "In scenario #2, if we have dozens of conversations about the impending buyout, we can be sure that at least one of those conversations will have used "the lemon" and thus will be exposed."
• 1999-10-22 Jerry Coffin: "This bears no relationship to what I proposed at all."
• 1999-10-22 David Wagner: "My preference would be to have exactly one MUST-implement "AES winner"."
• 1999-10-23 Mok-Kong Shen: "I conjecture that this is acceptable to the majority."
• 1999-10-23 Mok-Kong Shen: ". . . I believe one could be satisfied with a compromise."
• 1999-10-24 Mok-Kong Shen: "Since all implementations have the MUST algorithm, all users can at least communicate with that and the issue of interoperability vanishes."
• 1999-10-23 Trevor Jackson, III: "The AES contest is not defined to be an interoperability issue. It is defined to be a threshold test for USG acceptance of security products."
• 1999-10-23 Roger Schlafly: "All other things being equal, interoperability is a good thing."
• 1999-10-23 Trevor Jackson, III: "A single selection is vastly less valuable (to the USG as well as the security world) than a set of ciphers."
• 1999-10-23 DJohn37050: "Yes, my take is that NIST should say there are multiples winners and let the market sort it out."
• 1999-10-23 Roger Schlafly: "Why should NIST even be involved at all?"
• 1999-10-23 wtshaw: "The opponent will likely not tell, and will seek to cover information recovered with another and believable source."
• 1999-10-23 Trevor Jackson, III: "I am forced to agree. The "output" of hte AES contest chold be a set of ciphers."
• 1999-10-22 Trevor Jackson, III: "#2 is not a valid summary of his suggestion."
• 1999-10-23 Mok-Kong Shen: "Question: Why did you use 'at most' and 'at least' in the first paragraph . . . ?"
• 1999-10-24 Patrick Juola: "It gets worse. The exposed messages in situation #2 will provide cribs for unexposed messages and make the cryptanalysis of those messages much easier."
• 1999-10-25 Paul Crowley: "David Wagner's model assumes that only one of the five ciphers used is weak . . . ."
• 1999-10-23 Mok-Kong Shen: "If one randomly choose from a set of algorithms of different strength, then one has a chance of (sometimes) using the weakest algorithm."
• 1999-10-22 Brian Gladman: "As I said in my previous post, the satellite example is unrepresentative of typical encryption use but to characterise it as 'moronic' goes too far. IMHO the use of such an emotive term says more about those who choose to use it than it ever does about the person (Don Johnson?) who first suggested the satellite example."
• 1999-10-21 DJohn37050: "I did not come up with the satellite example, but I thot it a good one."
• 1999-10-21 Roger Schlafly: "But worrying about weaknesses in the AES block cipher -- NOT."
• 1999-10-22 Brian Gladman: "Precisely why should I ignore this particular possibility while considering all others? I can only assume that you are guessing that the probability of failure is sufficiently low to be ignored. Given the history of cryptography I prefer to take a more cautious approach."
• 1999-10-22 Paul Crowley: "OK, so satellites have the crypto hard-wired. This doesn't preclude the possibility of implementing a fix in software if a weakness is found in the cipher . . . ."
• 1999-10-23 Terry Ritter: ". . . any cipher system designed for mass use should be built so that alternate ciphers can be used. And to reassure ourselves that this feature remains available, it should be used regularly."
• 1999-10-22 David Wagner: "3. It's better to focus all our cryptanalysis resources on one cipher, rather than to split it up among ciphers."
• 1999-10-22 Trevor Jackson, III: "Consider that concentrating all available effort on a single candidate might backfire."
• 1999-10-23 Trevor Jackson, III: "I response to the above referenced paper, my only comment is that the model you've proposed lacks any characterization of the dilution effect of multiple ciphers upon adversarial resource allocation."
• 1999-10-26 David Wagner: "Yes, you're absolutely right. I had in mind the implicit assumption that that adversary's analysis resources would be so much larger than ours that they could be considered essentially infinite . . ."
• 1999-10-23 Terry Ritter: "This appears to be the same old stuff to which I have already replied in detail. Oddly, you do not seem to give the opposing arguments equal space on your web page. You thus leave the false impression that the only serious opposition arguments were those you addressed, and you did not quote those arguments."
• 1999-10-26 David Wagner: "As to the rest of your comments in this post, we've already discussed them in detail, as you say, so I'm not convinced that replying will really advance the discussion much."

Subject: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Sun, 10 Oct 1999 15:25:38 GMT
From: schneier@counterpane.com (Bruce Schneier)
Message-ID: <3804ae80.2804726@news.visi.com>
Newsgroups: sci.crypt
Lines: 101

Inside Risks #112

CACM vol. 42, no. 10, October 1999. 

Risks of Relying on Cryptography
Bruce Schneier

Cryptography is often treated as if it were magic security dust:
"sprinkle some on your system, and it is secure; then, you're secure
as long as the key length is large enough--112 bits, 128 bits, 256
bits" (I've even seen companies boast of 16,000 bits.)  "Sure, there
are always new developments in cryptanalysis, but we've never seen an
operationally useful cryptanalytic attack against a standard
algorithm.  Even the analyses of DES aren't any better than brute
force in most operational situations.  As long as you use a
conservative published algorithm, you're secure."

This just isn't true.  Recently we've seen attacks that hack into the
mathematics of cryptography and go beyond traditional cryptanalysis,
forcing cryptography to do something new, different, and unexpected.
For example:

* Using information about timing, power consumption, and radiation of
a device when it executes a cryptographic algorithm, cryptanalysts
have been able to break smart cards and other would-be secure tokens.
These are called ``side-channel attacks.''

* By forcing faults during operation, cryptanalysts have been able to
break even more smart cards.  This is called ``failure analysis.''
Similarly, cryptanalysts have been able to break other algorithms
based on how systems respond to legitimate errors.

* One researcher was able to break RSA-signed messages when formatted
using the PKCS standard.  He did not break RSA, but rather the way it
was used.  Just think of the beauty: we don't know how to factor large
numbers effectively, and we don't know how to break RSA.  But if you
use RSA in a certain common way, then in some implementations it is
possible to break the security of RSA ... without breaking RSA.

* Cryptanalysts have analyzed many systems by breaking the
pseudorandom number generators used to supply cryptographic keys.  The
cryptographic algorithms might be secure, but the key-generation
procedures were not.  Again, think of the beauty: the algorithm is
secure, but the method to produce keys for the algorithm has a
weakness, which means that there aren't as many possible keys as there
should be.

* Researchers have broken cryptographic systems by looking at the way
different keys are related to each other.  Each key might be secure,
but the combination of several related keys can be enough to
cryptanalyze the system.

The common thread through all of these exploits is that they've all
pushed the envelope of what constitutes cryptanalysis by using
out-of-band information to determine the keys.  Before side-channel
attacks, the open crypto community did not think about using
information other than the plaintext and the ciphertext to attack
algorithms.  After the first paper, researchers began to look at
invasive side channels, attacks based on introducing transient and
permanent faults, and other side channels.  Suddenly there was a whole
new way to do cryptanalysis.

Several years ago I was talking with an NSA employee about a
particular exploit.  He told about how a system was broken; it was a
sneaky attack, one that I didn't think should even count.  "That's
cheating," I said.  He looked at me as if I'd just arrived from
Neptune.

"Defense against cheating" (that is, not playing by the *assumed*
rules) is one of the basic tenets of security engineering.
Conventional engineering is about making things work.  It's the
genesis of the term "hack,"' as in "he worked all night and hacked the
code together."  The code works; it doesn't matter what it looks like.
Security engineering is different; it's about making sure things don't
do something they shouldn't.  It's making sure security isn't broken,
even in the presence of a malicious adversary who does everything in
his power to make sure that things don't work in the worst possible
way at the worst possible times.  A good attack is one that the
engineers never even thought about.

Defending against these unknown attacks is impossible, but the risk
can be mitigated with good system design.  The mantra of any good
security engineer is: "Security is a not a product, but a process."
It's more than designing strong cryptography into a system; it's
designing the entire system such that all security measures, including
cryptography, work together.  It's designing the entire system so that
when the unexpected attack comes from nowhere, the system can be
upgraded and resecured.  It's never a matter of "if a security flaw is
found," but "when a security flaw is found."

This isn't a temporary problem.  Cryptanalysts will forever be pushing
the envelope of attacks.  And whenever crypto is used to protect
massive financial resources (especially with world-wide master keys),
these violations of designers' assumptions can be expected to be used
more aggressively by malicious attackers.  As our society becomes more
reliant on a digital infrastructure, the process of security must be
designed in from the beginning.
**********************************************************************
Bruce Schneier, President, Counterpane Systems     Phone: 612-823-1098
101 E Minnehaha Parkway, Minneapolis, MN  55419      Fax: 612-823-1590
           Free crypto newsletter.  See:  http://www.counterpane.com


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Sun, 10 Oct 1999 18:11:10 +0200
From: Mok-Kong Shen <mok-kong.shen@t-online.de>
Message-ID: <3800BA9E.8F12A758@t-online.de>
References: <3804ae80.2804726@news.visi.com>
Newsgroups: sci.crypt
Lines: 45

Bruce Schneier wrote:
> 
> The common thread through all of these exploits is that they've all
> pushed the envelope of what constitutes cryptanalysis by using
> out-of-band information to determine the keys.  Before side-channel
> attacks, the open crypto community did not think about using
> information other than the plaintext and the ciphertext to attack
> algorithms.  After the first paper, researchers began to look at
> invasive side channels, attacks based on introducing transient and
> permanent faults, and other side channels.  Suddenly there was a whole
> new way to do cryptanalysis.
....................................

> Defending against these unknown attacks is impossible, but the risk
> can be mitigated with good system design.  The mantra of any good
> security engineer is: "Security is a not a product, but a process."
> It's more than designing strong cryptography into a system; it's
> designing the entire system such that all security measures, including
> cryptography, work together.  It's designing the entire system so that
> when the unexpected attack comes from nowhere, the system can be
> upgraded and resecured.  It's never a matter of "if a security flaw is
> found," but "when a security flaw is found."
> 
> This isn't a temporary problem.  Cryptanalysts will forever be pushing
> the envelope of attacks.  And whenever crypto is used to protect
> massive financial resources (especially with world-wide master keys),
> these violations of designers' assumptions can be expected to be used
> more aggressively by malicious attackers.  As our society becomes more
> reliant on a digital infrastructure, the process of security must be
> designed in from the beginning.

I appreciate very much your arguments. I believe the above paragraphs 
are entirely true and extremely valuable. I like only to mention that
some complementary and apparently also useful additional viewpoints 
may be found in the following reference:

     T. Ritter, Cryptography. IEEE Computer, Aug. 1999, p.94-95.

where, among others, the advantage of multiple encryption using
a number of (changing) ciphers is discussed. (This is an application 
of the general principle of variability in my humble view.)

M. K. Shen
-----------------------------
http://home.t-online.de/home/mok-kong.shen


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: 10 Oct 1999 21:45:50 GMT
From: djohn37050@aol.com (DJohn37050)
Message-ID: <19991010174550.05076.00000677@ng-cl1.aol.com>
References: <3800BA9E.8F12A758@t-online.de>
Newsgroups: sci.crypt
Lines: 4

Multiple encryption using different ciphers was also mentioned in my submission
to the 2nd AES conference entitled "Future Resiliency: A Possible New AES
Criterion" and is available from NIST AES web site.
Don Johnson


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Mon, 11 Oct 1999 17:14:24 +0200
From: Mok-Kong Shen <mok-kong.shen@t-online.de>
Message-ID: <3801FED0.1FF9D640@t-online.de>
References: <19991010174550.05076.00000677@ng-cl1.aol.com>
Newsgroups: sci.crypt
Lines: 58

DJohn37050 wrote:
> 
> Multiple encryption using different ciphers was also mentioned in my submission
> to the 2nd AES conference entitled "Future Resiliency: A Possible New AES
> Criterion" and is available from NIST AES web site.

I am very happy to be able to read your paper. I believe that
a part of the posts to a recent thread on Terry Ritter's paper
could have been spared, were your paper known to the participants
at that time. The eloquence, with which you advance your arguments 
and to which I whole-heartedly agree, is simply admirable.
However, to be honest, I have considerable doubt as to whether 
even your highly convincing article succeeds to shaken the time-
honoured, deep-rooted conservatism of the bureaucrats. (I suppose 
here that the one-winner criterion is an expression of that 
all-pervasive conservatism, which, by the way, I believe is even 
shared by part of the professionals and academics and which Terry
Ritter recently apparently attempted to oppose with his (feeble) 
one-man campaign.)

I want to highlight a tiny point which is certainly implicitly also
contained in your paper: Even for a fixed set of n algorithms
there are n! ways of combination to build a compound cipher. This
combinatorial explosion alone is an effective defense against
analysis.

The one-winner criterion is in fact absurd if one remembers that
in Olympic games there are conferred to the sportsmen besides
gold medals also ones made of silver and bronze.

I like to cite one sentence from your paper for the readers of this
group:

    If there are a small handful of good algorithms with different
    attributes, then NIST should sanction those algorithms and
    let the market decide.

I believe that one should clearly realize that the 'war' between 
defenders and aggressors of information security is non-ending. 
It's much like one between physicians and microbes. Several decades 
ago, when penicillin was discovered, plently people believed that 
infections could soon be totally put under control. Today scientists 
struggle to find remedies against AIDS. Eventually scientists will 
win against AIDS, but surely some new diseases will surge up after 
that. Mr. Schneier mentioned in his post that the discovery of power
analysis etc. suddenly poses an new (unexpected) menace. But I 
vaguely remember someone claiming there are some effective means of 
protecting against that (which others then surely would attempt to 
circumvent). Like playing chess, each move of a player will be 
responded to by his opponents. Or, to draw an analogy from warfare: 
After missiles are used there are developed anti-missiles. I am 
sure there are also anti-anti-missiles and anti-anti-anti- ..... 
ad infinitum. It's pure vanity to assume that one single (fixed)
cipher could provide secure communications for the entire world.

M. K. Shen
------------------------
http://home.t-online.de/home/mok-kong.shen


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Mon, 11 Oct 1999 10:26:25 -0700
From: Sundial Services <info@sundialservices.com>
Message-ID: <38021DC1.500D@sundialservices.com>
References: <3801FED0.1FF9D640@t-online.de>
Newsgroups: sci.crypt
Lines: 49

Mok-Kong Shen wrote:
>
> I want to highlight a tiny point which is certainly implicitly also
> contained in your paper: Even for a fixed set of n algorithms
> there are n! ways of combination to build a compound cipher. This
> combinatorial explosion alone is an effective defense against
> analysis.
> 

The essential point that Bruce mentions is that, if you build an
immensely strong bank-vault door to your home, but beside it is an open
window ... then your home is -worse- than insecure.  It's wide open but
you THINK it's safe -- you ASSUME it's safe.

When I look at the crypto algorithms that come out today, it seems to me
that for all practical civilian purposes all of them are quite strong
enough, and have been for some time.  True, someone -might- come against
them with all the arsenal that Wile E. Coyote sometimes arrayed against
the Roadrunner (a few good Dr. Seuss comics also come to mind) ... but
everyone else is going to look for some way to go -around- that
impregnable doorway, not through it.

The key, or the key-scheduling algorithm, is an obvious choice.  While
algorithms cannot be broken using brute-force, perhaps the key can...
there is usually a "phrase you can easily remember" and so on.  The list
of ingenious methods people can use is just as big as the list of
ingenious methods other people use to try to protect things.

Strategies like choosing from among 'n' different cipher algorithms,
mixing them up in various ways or applying several of them in various
ways ... will layer more sheets of bulletproof iron on top of the door
we already have.  It will not eliminate that open window if it exists.

I've found that, the more clever you think you are in creating the
protection scheme you put in place -- the more easily you can overlook
"another, obvious-now-that-I-see-it" possibility for going completely
around it.

For instance, at one university I tried to sysop for, I couldn't sleep
one night so I tried to log in... and couldn't!  Five minutes later my
password worked -- and lo, "root" was logged on elsewhere.  It turns out
that students, who also couldn't sleep, discovered that the password
file was unprotected.  They simply replaced it, logged on, quickly moved
it back.  The fact that I discovered the hole was quite by accident. 
Not a good analogy, I realize, but the point is that the possibility of
this "move the iron door out of the way, go inside, put the iron door
back" attack had simply never occurred to me.  Much less that people
were doing it.  I changed root-passwords all the time and deceived
-myself- into thinking the system was secure.


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Mon, 11 Oct 1999 22:19:41 +0200
From: Mok-Kong Shen <mok-kong.shen@t-online.de>
Message-ID: <3802465D.FAA2412F@t-online.de>
References: <38021DC1.500D@sundialservices.com>
Newsgroups: sci.crypt
Lines: 45

Sundial Services wrote:
> 
> Mok-Kong Shen wrote:
> >
> > I want to highlight a tiny point which is certainly implicitly also
> > contained in your paper: Even for a fixed set of n algorithms
> > there are n! ways of combination to build a compound cipher. This
> > combinatorial explosion alone is an effective defense against
> > analysis.
> >
> 
> The essential point that Bruce mentions is that, if you build an
> immensely strong bank-vault door to your home, but beside it is an open
> window ... then your home is -worse- than insecure.  It's wide open but
> you THINK it's safe -- you ASSUME it's safe.
> 
> When I look at the crypto algorithms that come out today, it seems to me
> that for all practical civilian purposes all of them are quite strong
> enough, and have been for some time.  True, someone -might- come against
> them with all the arsenal that Wile E. Coyote sometimes arrayed against
> the Roadrunner (a few good Dr. Seuss comics also come to mind) ... but
> everyone else is going to look for some way to go -around- that
> impregnable doorway, not through it.
> 
> The key, or the key-scheduling algorithm, is an obvious choice.  While
> algorithms cannot be broken using brute-force, perhaps the key can...
> there is usually a "phrase you can easily remember" and so on.  The list
> of ingenious methods people can use is just as big as the list of
> ingenious methods other people use to try to protect things.
> 
> Strategies like choosing from among 'n' different cipher algorithms,
> mixing them up in various ways or applying several of them in various
> ways ... will layer more sheets of bulletproof iron on top of the door
> we already have.  It will not eliminate that open window if it exists.
> 
> I've found that, the more clever you think you are in creating the
> protection scheme you put in place -- the more easily you can overlook
> "another, obvious-now-that-I-see-it" possibility for going completely
> around it.

What do you have against e.g. multiple encrpytion with the top three
algorithms of the final round of AES instead of with the winner
of AES alone?

M. K. Shen


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Mon, 11 Oct 1999 23:05:53 -0400
From: "Trevor Jackson, III" <fullmoon@aspi.net>
Message-ID: <3802A591.A94449EB@aspi.net>
References: <38055ece.2545892@news.visi.com>
   <3802465D.FAA2412F@t-online.de>
Newsgroups: sci.crypt
Lines: 30

Bruce Schneier wrote:

> On Mon, 11 Oct 1999 22:19:41 +0200, Mok-Kong Shen
> <mok-kong.shen@t-online.de> wrote:
> >What do you have against e.g. multiple encrpytion with the top three
> >algorithms of the final round of AES instead of with the winner
> >of AES alone?
>
> It completely misses the point.

There isn't just one.

>  It's like putting an enormous stake
> in the ground and hoping the enemy runs right into it, instead of
> building a broad palisade.
>
> Certainly, if you have the time to wait, encrypt with a cascade of
> three algorithms.  But this solution isn't going to help anyone
> writing Internet protocols, for example.

Nor implementors of smartcards, record-level database encryption, etc.
The list of inappropriate uses of any cipher is larger than the list of
appropriate uses.  In this instance, multi-level encryption, one would
need a justification for spending the extra time/cost/effort involved.
But given that justification it's a reasonable answer.

Is it your positiom that there is no circumstance justifying multi-level
encryption?




Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Tue, 12 Oct 1999 14:45:33 GMT
From: schneier@counterpane.com (Bruce Schneier)
Message-ID: <3803493a.1800228@news.visi.com>
References: <3802A591.A94449EB@aspi.net>
Newsgroups: sci.crypt
Lines: 23

On Mon, 11 Oct 1999 23:05:53 -0400, "Trevor Jackson, III"
<fullmoon@aspi.net> wrote:
>Nor implementors of smartcards, record-level database encryption, etc.
>The list of inappropriate uses of any cipher is larger than the list of
>appropriate uses.  In this instance, multi-level encryption, one would
>need a justification for spending the extra time/cost/effort involved.
>But given that justification it's a reasonable answer.

Indeed.

>Is it your positiom that there is no circumstance justifying multi-level
>encryption?

Of course not.  That would be a rather stupid position.  I just didn't
see many real-world applications where that was a good solution.  Even
triple-DES--a perfect example of multi-level encryption--was too slow
for many applications.

Bruce
**********************************************************************
Bruce Schneier, President, Counterpane Systems     Phone: 612-823-1098
101 E Minnehaha Parkway, Minneapolis, MN  55419      Fax: 612-823-1590
           Free crypto newsletter.  See:  http://www.counterpane.com


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Tue, 12 Oct 1999 12:46:28 -0400
From: "Trevor Jackson, III" <fullmoon@aspi.net>
Message-ID: <380365E4.75BDDC00@aspi.net>
References: <3803493a.1800228@news.visi.com>
Newsgroups: sci.crypt
Lines: 31

Bruce Schneier wrote:

> On Mon, 11 Oct 1999 23:05:53 -0400, "Trevor Jackson, III"
> <fullmoon@aspi.net> wrote:
> >Nor implementors of smartcards, record-level database encryption, etc.
> >The list of inappropriate uses of any cipher is larger than the list of
> >appropriate uses.  In this instance, multi-level encryption, one would
> >need a justification for spending the extra time/cost/effort involved.
> >But given that justification it's a reasonable answer.
>
> Indeed.
>
> >Is it your positiom that there is no circumstance justifying multi-level
> >encryption?
>
> Of course not.  That would be a rather stupid position.  I just didn't
> see many real-world applications where that was a good solution.  Even
> triple-DES--a perfect example of multi-level encryption--was too slow
> for many applications.

I guess it depends on what you mean by "many".

3DES may be too slow for many (?) applications, but it might also be fast
enough for many (?) applications.  You may not have found many (?) real-world
applications where it is a good solution, but that may be sampling error.

I doubt anyone would criticize you for concentrating your efforts on areas
where you and your company can make a difference/contribution/profit.  I
doubt that finding uses for 3DES ranks high on your personal or corporate
agenda.



Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Tue, 12 Oct 1999 09:11:38 +0100
From: "Brian Gladman" <gladman@seven77.demon.co.uk>
Message-ID: <939715842.16902.0.nnrp-10.c2de6a96@news.demon.co.uk>
References: <38055ece.2545892@news.visi.com>
   <3802465D.FAA2412F@t-online.de>
Newsgroups: sci.crypt
Lines: 24


Bruce Schneier <schneier@counterpane.com> wrote in message
news:38055ece.2545892@news.visi.com...
> On Mon, 11 Oct 1999 22:19:41 +0200, Mok-Kong Shen
> <mok-kong.shen@t-online.de> wrote:
> >What do you have against e.g. multiple encrpytion with the top three
> >algorithms of the final round of AES instead of with the winner
> >of AES alone?
>
> It completely misses the point.  It's like putting an enormous stake
> in the ground and hoping the enemy runs right into it, instead of
> building a broad palisade.

So let me understand this - those who advocate controlled diversity of
algorithm choice through multiple AES winners are driving a single stake in
the ground while those who advocate a single AES winner are building a broad
palisade.

Funny that, but I rather thought that it was the other way round.

         Brian Gladman





Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: 12 Oct 1999 11:50:52 GMT
From: djohn37050@aol.com (DJohn37050)
Message-ID: <19991012075052.28722.00000022@ng-cq1.aol.com>
References: <939715842.16902.0.nnrp-10.c2de6a96@news.demon.co.uk>
Newsgroups: sci.crypt
Lines: 8

Yes, sometimes the value of the message is so high that it is appropriate to
use encrytion with multiple algorithms, just in case one would break.  I do not
see how the previous statement could be controversial to anyone.

I again like Brian's point.  For small systems we may need to choose one
algorithm to do a particular job, but for large systems, it is much better to
go for algorithm independence, etc.
Don Johnson


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Tue, 12 Oct 1999 18:23:10 +0200
From: Mok-Kong Shen <mok-kong.shen@t-online.de>
Message-ID: <3803606E.67BB7C2C@t-online.de>
References: <19991012075052.28722.00000022@ng-cq1.aol.com>
Newsgroups: sci.crypt
Lines: 18

DJohn37050 wrote:
> 
> Yes, sometimes the value of the message is so high that it is appropriate to
> use encrytion with multiple algorithms, just in case one would break.  I do not
> see how the previous statement could be controversial to anyone.
> 
> I again like Brian's point.  For small systems we may need to choose one
> algorithm to do a particular job, but for large systems, it is much better to
> go for algorithm independence, etc.

I warmly recommend those of the group who haven't yet read 
Don Johnson's paper to do so (access via AES of NIST). The arguments 
made there for what is termed 'future resiliency perspective' are in 
my humble opinion entirely sound and extremely convincing.

M. K. Shen
------------------------
http://home.t-online.de/home/mok-kong.shen


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: 12 Oct 1999 21:16:41 GMT
From: djohn37050@aol.com (DJohn37050)
Message-ID: <19991012171641.05056.00000181@ng-co1.aol.com>
References: <3803606E.67BB7C2C@t-online.de>
Newsgroups: sci.crypt
Lines: 6

All right!!!!! 

 And if you want to see my thoughts on future resiliency from an asymmetric
algorithm viewpoint, see my presentation and paper made at PKS '99 at
www.certicom.com
Don Johnson


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Tue, 12 Oct 1999 23:13:20 +0100
From: "Brian Gladman" <gladman@seven77.demon.co.uk>
Message-ID: <939766335.5121.0.nnrp-01.c2de6a96@news.demon.co.uk>
References: <3804499e.1899628@news.visi.com>
   <939715842.16902.0.nnrp-10.c2de6a96@news.demon.co.uk>
Newsgroups: sci.crypt
Lines: 46


Bruce Schneier <schneier@counterpane.com> wrote in message
news:3804499e.1899628@news.visi.com...
> On Tue, 12 Oct 1999 09:11:38 +0100, "Brian Gladman"
> <gladman@seven77.demon.co.uk> wrote:
>
> >
> >Bruce Schneier <schneier@counterpane.com> wrote in message
> >news:38055ece.2545892@news.visi.com...
> >> On Mon, 11 Oct 1999 22:19:41 +0200, Mok-Kong Shen
> >> <mok-kong.shen@t-online.de> wrote:
> >> >What do you have against e.g. multiple encrpytion with the top three
> >> >algorithms of the final round of AES instead of with the winner
> >> >of AES alone?
> >>
> >> It completely misses the point.  It's like putting an enormous stake
> >> in the ground and hoping the enemy runs right into it, instead of
> >> building a broad palisade.
> >
> >So let me understand this - those who advocate controlled diversity of
> >algorithm choice through multiple AES winners are driving a single stake
in
> >the ground while those who advocate a single AES winner are building a
broad
> >palisade.
>
> No.  I am talking about encrypting with multiple algorithms as opposed
> to encrypting with a single algorithm.  I am not talking about how
> many algorithms win AES.  Mok-Kong's question asked about "multiple
> encryption with the top three algorithms of the final round" as
> opposed to the single "winner of the AES."

Thanks for the clarification - I thought that you were making a more general
point on which I would have to disagree but I now see from this and other
posts that you are not denying the existence of situations where multiple
sequential encryption using different algorithms will have a positive
security value.

So all we need now is a good way of meeting ***these*** requirements in the
future using open standard algorithms that have secured the widespread
support of the cryptographic R&D community.

     Brian Gladman





Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Wed, 13 Oct 1999 22:33:50 GMT
From: jsavard@tenMAPSONeerf.edmonton.ab.ca (John Savard)
Message-ID: <3805076f.1326616@news.prosurfr.com>
References: <939715842.16902.0.nnrp-10.c2de6a96@news.demon.co.uk>
Newsgroups: sci.crypt
Lines: 38

"Brian Gladman" <gladman@seven77.demon.co.uk> wrote, in part:
>Bruce Schneier <schneier@counterpane.com> wrote in message
>news:38055ece.2545892@news.visi.com...

>> It completely misses the point.  It's like putting an enormous stake
>> in the ground and hoping the enemy runs right into it, instead of
>> building a broad palisade.

>So let me understand this - those who advocate controlled diversity of
>algorithm choice through multiple AES winners are driving a single stake in
>the ground while those who advocate a single AES winner are building a broad
>palisade.

>Funny that, but I rather thought that it was the other way round.

It isn't the idea of having two or three AES winners that Bruce was
referring to, but the idea of relying on a system that is based on the
principle that, since *no* cipher is proven secure, one needs
_thousands_ of ciphers, chosen at random by one's encryption
program...

with the problem that of those thousands of ciphers, only a handful
recieved any serious analysis.

The use of multiple encryption, where at least one well-analyzed
cipher, like an AES finalist, is among those used, was sort of
grudgingly accepted as a possible supplement to the idea by its
advocate.

This is the proposal that's been criticized as 'driving a stake in the
ground', and I can see why that example has been chosen. The author of
this proposal has had many useful ideas, but without appreciating or
acknowledging the value of the 'conventional' point of view, whether
or not this has led to real drawbacks in any idea of his, it will
certainly lead to the merits of his ideas not getting a fair hearing.

John Savard ( teneerf<- )
http://www.ecn.ab.ca/~jsavard/crypto.htm


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Thu, 14 Oct 1999 02:55:39 GMT
From: ritter@io.com (Terry Ritter)
Message-ID: <380545dc.11389503@news.io.com>
References: <3805076f.1326616@news.prosurfr.com>
Newsgroups: sci.crypt
Lines: 107


On Wed, 13 Oct 1999 22:33:50 GMT, in
<3805076f.1326616@news.prosurfr.com>, in sci.crypt
jsavard@tenMAPSONeerf.edmonton.ab.ca (John Savard) wrote:

>"Brian Gladman" <gladman@seven77.demon.co.uk> wrote, in part:
>>Bruce Schneier <schneier@counterpane.com> wrote in message
>>news:38055ece.2545892@news.visi.com...
>
>>> It completely misses the point.  It's like putting an enormous stake
>>> in the ground and hoping the enemy runs right into it, instead of
>>> building a broad palisade.
>
>>So let me understand this - those who advocate controlled diversity of
>>algorithm choice through multiple AES winners are driving a single stake in
>>the ground while those who advocate a single AES winner are building a broad
>>palisade.
>
>>Funny that, but I rather thought that it was the other way round.
>
>It isn't the idea of having two or three AES winners that Bruce was
>referring to, but the idea of relying on a system that is based on the
>principle that, since *no* cipher is proven secure, one needs
>_thousands_ of ciphers, chosen at random by one's encryption
>program...

It seems odd to me that you know what is on Schneier's mind, but your
summary is wrong:  If we could believe that any one cipher is forever
unbreakable, we would need no more than that.  Our problem is that
there is no such evidence.  We are ever so casually asked to risk the
whole of our information society on mere opinion that, in a very real
sense, can have no expertise behind it.  Our experts simply cannot
know what our opponents may do.  

We only add ciphers to reduce the risk inherent in the conventional
wisdom.  The advantage begins with the very first additional cipher.  

To the extent that any one cipher is a risk, using two different
ciphers in sequence tends to protect both.  And when we use three
different ciphers, then even if one is completely broken, the opponent
still does not have known-plaintext for either of the other two.  

Beyond that, we can also increase the number of ciphers.  

Or perhaps you will offer a better alternative . . . .  


>with the problem that of those thousands of ciphers, only a handful
>recieved any serious analysis.

Thousands?  The number of "cipherings" (distinct 3-level cipher
stacks) is the cube of the number of ciphers.  Surely we can all agree
that there are currently hundreds of different ciphers, all
constructed in a climate which does not encourage a profusion of
ciphers.  It seems to me that rather quickly we could have something
like 10**6 different cipher stacks available.  

The point of having many "cipherings" is *not* to increase keyspace
per se, but instead to give us the frequent opportunity to change from
one ciphering to another, thus terminating any break which may have
occurred.  We do want to have enough cipherings so that we can support
a few broken combinations which expose only a small fraction of our
data.  Probably thousands is enough.  

But if we dynamically increase the working set of ciphers (explicitly
avoiding any which are known weak, of course), we can force our
opponents to support an extremely costly process of detection,
acquisition and analysis for every new cipher.  This is to our
advantage.  


>The use of multiple encryption, where at least one well-analyzed
>cipher, like an AES finalist, is among those used, was sort of
>grudgingly accepted as a possible supplement to the idea by its
>advocate.

Using a particular cipher necessarily reduces the number of different
cipher stacks to the square of the number of ciphers, instead of the
cube.  This is some degree of loss, and the only reason to do it is if
someone is convinced that a particular cipher is unbreakable.  But
there will be many different opinions about which particular cipher
that should be.  How much different is this from a random selection?  


>This is the proposal that's been criticized as 'driving a stake in the
>ground', and I can see why that example has been chosen. The author of
>this proposal has had many useful ideas, but without appreciating or
>acknowledging the value of the 'conventional' point of view, whether
>or not this has led to real drawbacks in any idea of his, it will
>certainly lead to the merits of his ideas not getting a fair hearing.

First of all, we are discussing a security flaw at the heart of
conventional cryptography.  We do not pussyfoot around with serious
public issues.  

Also note that I have in the past presented various ideas at a
somewhat lower key, only to see those ideas explicitly avoided by
those many trust to provide a complete survey of cryptography.  So
I've "been there," and "done that."  My experience is that those who
support the conventional wisdom will avoid anything fundamentally new
and disturbing at almost any cost.  And if you are not part of the
solution, you are part of the problem.  

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


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Fri, 15 Oct 1999 19:07:15 GMT
From: jsavard@tenMAPSONeerf.edmonton.ab.ca (John Savard)
Message-ID: <38077871.14251584@news.prosurfr.com>
References: <380545dc.11389503@news.io.com>
Newsgroups: sci.crypt
Lines: 37

ritter@io.com (Terry Ritter) wrote, in part:

>It seems odd to me that you know what is on Schneier's mind,

I can only assume that it was something like your proposal he was
criticizing, because such a criticism wouldn't make sense applied to
what Brian Gladman was talking about.

Your proposal at least appeared to have serious weaknesses, the way
people understood it at first. (I certainly grant that you had a right
not to be amused at some of the things that happened as the thread
went along; you clarified some of the details of what you were
proposing as the result of questions, and the response was "how do we
know you didn't just steal the idea our question implied".)

>My experience is that those who
>support the conventional wisdom will avoid anything fundamentally new
>and disturbing at almost any cost.  And if you are not part of the
>solution, you are part of the problem.  

It's obviously wrong if you jump from "no cipher is proven secure" to
"all ciphers are equally bad". You may rightly protest that you never
jumped to that kind of conclusion, but at times you allowed it to
appear that this was the basis of your multi-ciphering proposal.

The "conventional wisdom" in cryptography, as in other fields, did not
arise simply by whim or prejudice, but came about as the result of
knowledge and experience. That doesn't mean it doesn't have its
limitations and omissions - many of which I feel you have correctly
located, and are attempting to address.

To be "part of the solution", however, one has to be more than a
"voice crying in the wilderness". And that involves paying the
conventional wisdom its due, and recognizing that due.

John Savard ( teneerf<- )
http://www.ecn.ab.ca/~jsavard/crypto.htm


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Sun, 17 Oct 1999 15:41:11 GMT
From: ritter@io.com (Terry Ritter)
Message-ID: <3809ee12.4602146@news.io.com>
References: <38077871.14251584@news.prosurfr.com>
Newsgroups: sci.crypt
Lines: 112


On Fri, 15 Oct 1999 19:07:15 GMT, in
<38077871.14251584@news.prosurfr.com>, in sci.crypt
jsavard@tenMAPSONeerf.edmonton.ab.ca (John Savard) wrote:

>ritter@io.com (Terry Ritter) wrote, in part:
>
>>It seems odd to me that you know what is on Schneier's mind,
>
>I can only assume that it was something like your proposal he was
>criticizing, because such a criticism wouldn't make sense applied to
>what Brian Gladman was talking about.
>
>Your proposal at least appeared to have serious weaknesses, the way
>people understood it at first. (I certainly grant that you had a right
>not to be amused at some of the things that happened as the thread
>went along; you clarified some of the details of what you were
>proposing as the result of questions, and the response was "how do we
>know you didn't just steal the idea our question implied".)

We had a big discussion based on my proposals in April 1999, some of
which is archived on my pages (see:

   http://www.io.com/~ritter/NEWS4/LIMCRYPT.HTM

).  And I have had various public discussions about parts of this over
several years (see from 1996, for example:

   http://www.io.com/~ritter/CRYPTWAR.HTM

for example: 

   http://www.imc.org/workshop/mail-archive/0233.html

).  But I think it was just within the last year that I realized how
important it was for people to see this before locking AES alone into
all future systems.


>>My experience is that those who
>>support the conventional wisdom will avoid anything fundamentally new
>>and disturbing at almost any cost.  And if you are not part of the
>>solution, you are part of the problem.  
>
>It's obviously wrong if you jump from "no cipher is proven secure" to
>"all ciphers are equally bad". 

I don't believe that, I doubt I ever said it, and find it hard to
imagine that anyone could reasonably interpret my words to have that
meaning.  

No matter how many clear unambiguous statements I make, however, it is
rather easy for you to misstate my position, as you yourself did in
your earlier posting:  

>>It isn't the idea of having two or three AES winners that Bruce was
>>referring to, but the idea of relying on a system that is based on the
>>principle that, since *no* cipher is proven secure, one needs
>>_thousands_ of ciphers, chosen at random by one's encryption
>>program...

It is wrong to imply that there is no improvement wrought from each
dimension:  multiple level ciphering, dynamically changing ciphers,
and having many ciphers to choose from.  Insisting that the weakness
of the proposal is that we don't have many "good" ciphers misstates
the situation.  The real weakness is that we don't know that we have
*one* "good" cipher; now what do we do about it?  The problem we have
is *not* the proposals, but instead the way things are currently done.

Yet we see continued slanted misstatements, despite whole reams of
archived messages and summaries which lay it all out.  

>You may rightly protest that you never
>jumped to that kind of conclusion, but at times you allowed it to
>appear that this was the basis of your multi-ciphering proposal.

I "allowed it to appear"?  You say I deliberately allowed a
misconception because it would improve my position?  No.  Nonsense.
That did not happen.  

I don't answer every message, of course.  (Currently, even this amount
of time is unsustainable for me.)  Sometimes I misstate, and sometimes
I do make mistakes.  But intentionally leaving a false impression?
No.  Why would I do that?  The underlying position is solid and
correct.  I have no need for misconceptions, and I feel no particular
need to "win" at any such cost.  

This is not about me winning.  This is about solving a serious problem
on the horizon at a time when the solution cost is relatively small.
If we wait for AES-only to get wired-in, we will have a very serious
and costly situation indeed.  


>The "conventional wisdom" in cryptography, as in other fields, did not
>arise simply by whim or prejudice, but came about as the result of
>knowledge and experience. That doesn't mean it doesn't have its
>limitations and omissions - many of which I feel you have correctly
>located, and are attempting to address.
>
>To be "part of the solution", however, one has to be more than a
>"voice crying in the wilderness". And that involves paying the
>conventional wisdom its due, and recognizing that due.

There is no "due."  The conventional wisdom *caused* the situation by
failing to practice the Science they claim to support.  Nor are they
in any hurry to correct their error despite the fact that society will
actually depend upon this stuff.  That hardly deserves respect.  

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


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: 17 Oct 99 19:33:32 GMT
From: jsavard@ecn.ab.ca ()
Message-ID: <380a248c.0@ecn.ab.ca>
References: <3809ee12.4602146@news.io.com>
Newsgroups: sci.crypt
Lines: 67

Terry Ritter (ritter@io.com) wrote:
: On Fri, 15 Oct 1999 19:07:15 GMT, in
: <38077871.14251584@news.prosurfr.com>, in sci.crypt
: jsavard@tenMAPSONeerf.edmonton.ab.ca (John Savard) wrote:

: >It's obviously wrong if you jump from "no cipher is proven secure" to
: >"all ciphers are equally bad". 

: I don't believe that, I doubt I ever said it, and find it hard to
: imagine that anyone could reasonably interpret my words to have that
: meaning.  

: >You may rightly protest that you never
: >jumped to that kind of conclusion, but at times you allowed it to
: >appear that this was the basis of your multi-ciphering proposal.

: I "allowed it to appear"?  You say I deliberately allowed a
: misconception because it would improve my position?  No.  Nonsense.
: That did not happen.  

I agree. When I said "allowed it to appear", I did not mean that you
_deliberately_ promoted any misconceptions.

It's just that there were flaws in your proposal as it originally
appeared, but that, although you did address those flaws (with multiple
layers of encryption), you still managed to leave the impression that
those measures were less than critical, or that they were an afterthought.
And that impression has led to the other impression: that the whole idea
is based on faulty reasoning.

: This is not about me winning.  This is about solving a serious problem
: on the horizon at a time when the solution cost is relatively small.
: If we wait for AES-only to get wired-in, we will have a very serious
: and costly situation indeed.  

Be assured that AES-only will get wired in to a number of systems, but
that encryption will also be done elsewhere in software in a multitude of
ways.

: >The "conventional wisdom" in cryptography, as in other fields, did not
: >arise simply by whim or prejudice, but came about as the result of
: >knowledge and experience. That doesn't mean it doesn't have its
: >limitations and omissions - many of which I feel you have correctly
: >located, and are attempting to address.

: >To be "part of the solution", however, one has to be more than a
: >"voice crying in the wilderness". And that involves paying the
: >conventional wisdom its due, and recognizing that due.

: There is no "due."  The conventional wisdom *caused* the situation by
: failing to practice the Science they claim to support.  Nor are they
: in any hurry to correct their error despite the fact that society will
: actually depend upon this stuff.  That hardly deserves respect.  

Of course, I do not agree. The specific part of the conventional wisdom at
issue here is the importance of extensive study and testing of any cipher.
As cipher designs have a large "infant mortality", and it gets harder and
harder to find flaws in those ciphers that have survived longer, this
isn't unscientific.

You have pointed out a problem that needs correcting, and a way to correct
it: but that isn't enough. It also has to be made clear that the proposed
method of correcting matters won't make things worse. I think I can see
that this can be avoided, but I also understand why quite a few people are
remaining unconvinced.

John Savard


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Sat, 16 Oct 1999 01:23:21 GMT
From: bryan.olson@uptronics.com
Message-ID: <7u8k22$g32$1@nnrp1.deja.com>
References: <380545dc.11389503@news.io.com>
Newsgroups: sci.crypt
Lines: 129

Terry Ritter wrote:
> John Savard wrote:

> >It isn't the idea of having two or three AES winners that Bruce was
> >referring to, but the idea of relying on a system that is based on
the
> >principle that, since *no* cipher is proven secure, one needs
> >_thousands_ of ciphers, chosen at random by one's encryption
> >program...
>
> It seems odd to me that you know what is on Schneier's mind,

Isn't that what this reading and writing thing is all about?

> but your
> summary is wrong:  If we could believe that any one cipher is forever
> unbreakable, we would need no more than that.

His summary was fine; your claim above is simply non responsive.

> Our problem is that
> there is no such evidence.  We are ever so casually asked to risk the
> whole of our information society on mere opinion that, in a very real
> sense, can have no expertise behind it.  Our experts simply cannot
> know what our opponents may do.

We are on shaky ground relying on the scientific method
to resolve mathematical questions, but so far it's the
best we have figured out how to do.

> We only add ciphers to reduce the risk inherent in the conventional
> wisdom.  The advantage begins with the very first additional cipher.

In terms of provable, quantifiable, security, they are
tied at squat.  No advantage there.

> To the extent that any one cipher is a risk, using two different
> ciphers in sequence tends to protect both.  And when we use three
> different ciphers, then even if one is completely broken, the opponent
> still does not have known-plaintext for either of the other two.

Ah, _relative_ security.  We have proofs of that.


> Beyond that, we can also increase the number of ciphers.
>
> Or perhaps you will offer a better alternative . . . .

The point is that the conventional wisdom is already
a better alternative than this per-message change of
ciphers.

> The point of having many "cipherings" is *not* to increase keyspace
> per se, but instead to give us the frequent opportunity to change from
> one ciphering to another, thus terminating any break which may have
> occurred.

And opening one where previously blocked.

> We do want to have enough cipherings so that we can support
> a few broken combinations which expose only a small fraction of our
> data.  Probably thousands is enough.

A small chance of exposing all my plaintext is far
better than a large chance of exposing a small
portion.  The many-cipher system offers a bad trade.

> But if we dynamically increase the working set of ciphers (explicitly
> avoiding any which are known weak, of course), we can force our
> opponents to support an extremely costly process of detection,
> acquisition and analysis for every new cipher.  This is to our
> advantage.

The attacker can just go after the low-hanging fruit.
He gets a bigger advantage than we do.  He can also
propose ciphers that he can break.  How do you know
not to use them?

> >The use of multiple encryption, where at least one well-analyzed
> >cipher, like an AES finalist, is among those used, was sort of
> >grudgingly accepted as a possible supplement to the idea by its
> >advocate.
>
> Using a particular cipher necessarily reduces the number of different
> cipher stacks to the square of the number of ciphers, instead of the
> cube.  This is some degree of loss, and the only reason to do it is if
> someone is convinced that a particular cipher is unbreakable.  But
> there will be many different opinions about which particular cipher
> that should be.  How much different is this from a random selection?

Very.  It puts a lower limit on the strength of the
combinations.  It protects us in the face of attacks
on the selection process - what we might call the
"chosen cipher" attack.

> First of all, we are discussing a security flaw at the heart of
> conventional cryptography.  We do not pussyfoot around with serious
> public issues.

I don't know exactly what constitutes "pussyfooting", but
you continue to ignore the devastating flaws in the per
-message cipher choice.

> Also note that I have in the past presented various ideas at a
> somewhat lower key, only to see those ideas explicitly avoided by
> those many trust to provide a complete survey of cryptography.  So
> I've "been there," and "done that."

Been where and done what?  According to your posts, you've
been a crypto consultant over the years when DES, the only
real standard, was dying.  How many of these hundred-cipher
systems have you built?  How many are in use?

Those who are trusted have an obligation to avoid techniques
they believe are inferior.

> My experience is that those who
> support the conventional wisdom will avoid anything fundamentally new
> and disturbing at almost any cost.

A look at the course cryptography has taken since the
"New Directions" paper should disabuse one of the notion
that the field rejects new and disturbing ideas.

--Bryan


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


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Tue, 12 Oct 1999 00:33:57 GMT
From: dcd@firstnethou.com (Dan Day)
Message-ID: <38087cc1.7586514@news.globalcenter.net>
References: <38021DC1.500D@sundialservices.com>
Newsgroups: sci.crypt
Lines: 62

On Mon, 11 Oct 1999 10:26:25 -0700, Sundial Services <info@sundialservices.com>
wrote:
>For instance, at one university I tried to sysop for, I couldn't sleep
>one night so I tried to log in... and couldn't!  Five minutes later my
>password worked -- and lo, "root" was logged on elsewhere.  It turns out
>that students, who also couldn't sleep, discovered that the password
>file was unprotected.  They simply replaced it, logged on, quickly moved
>it back.  The fact that I discovered the hole was quite by accident. 
>Not a good analogy, I realize, but the point is that the possibility of
>this "move the iron door out of the way, go inside, put the iron door
>back" attack had simply never occurred to me.  Much less that people
>were doing it.  I changed root-passwords all the time and deceived
>-myself- into thinking the system was secure.

We pulled a similar dodge back when I was in college...  On a
PDP 11/70 with the RSTS/E timesharing system, the following properties
held:
   1.  Only a "privileged" account could set the bit on an executable
       file which enabled the executable to perform privileged operations 
       even when run by a non-privileged user.  (This is how a lot of
       the system software and features were implemented.)
   2.  If a non-privileged user tried to compile a new (rogue) executable
       "into" the existing "priviledged-bit-on" executable, the system
       wisely turned off the "privileged bit".

Sounds reasonably secure, no?  No.

One day, I hit upon the following simple scheme to crack the system
wide open:
   1.  Compile program "A", which would perform any nefarious act
       I wanted to perform if only the "privilege bit" were set.
   2.  Search the system for any privileged executable that had the
       read-write flags enabled, and that was at least as large
       as program "A".  Call this program "B".
   3.  Write a quickie "BASIC" program that opened "B" as a data
       file and copied all of its bytes to temporary file "C".
   4.  Use the same BASIC program to copy the byte contents of
       "A" into "B".  This, amazingly enough, left the privileged
       bit of "B" still on.

I now had my own rogue program existing under name "B", and privileged,
and could perform absolutely any operation of which the system was
capable, including creating my own privileged login.

Once I opened the door, it was a simple matter to then get the original
contents of "B" out of temporary copy "C" and stuff them back into
"B" where they belonged, leaving the system as it had been originally
(more or less...)

Clearly, this was *not* something that the system developers had
counted on...  They were apparently under the misconception that
only the compiler would be writing to executable files.

Sadly, I lacked the dishonest nature which would have enabled me
to change my grades, or put myself on the college payroll system,
so it was little more than an academic exercise, but still...


--
   "How strangely will the Tools of a Tyrant pervert the 
plain Meaning of Words!"
   --Samuel Adams (1722-1803), letter to John Pitts, January 21, 1776


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Mon, 11 Oct 1999 23:13:09 -0400
From: "Trevor Jackson, III" <fullmoon@aspi.net>
Message-ID: <3802A745.41AF101B@aspi.net>
References: <38087cc1.7586514@news.globalcenter.net>
Newsgroups: sci.crypt
Lines: 70

Dan Day wrote:

> On Mon, 11 Oct 1999 10:26:25 -0700, Sundial Services <info@sundialservices.com>
> wrote:
> >For instance, at one university I tried to sysop for, I couldn't sleep
> >one night so I tried to log in... and couldn't!  Five minutes later my
> >password worked -- and lo, "root" was logged on elsewhere.  It turns out
> >that students, who also couldn't sleep, discovered that the password
> >file was unprotected.  They simply replaced it, logged on, quickly moved
> >it back.  The fact that I discovered the hole was quite by accident.
> >Not a good analogy, I realize, but the point is that the possibility of
> >this "move the iron door out of the way, go inside, put the iron door
> >back" attack had simply never occurred to me.  Much less that people
> >were doing it.  I changed root-passwords all the time and deceived
> >-myself- into thinking the system was secure.
>
> We pulled a similar dodge back when I was in college...  On a
> PDP 11/70 with the RSTS/E timesharing system, the following properties
> held:
>    1.  Only a "privileged" account could set the bit on an executable
>        file which enabled the executable to perform privileged operations
>        even when run by a non-privileged user.  (This is how a lot of
>        the system software and features were implemented.)
>    2.  If a non-privileged user tried to compile a new (rogue) executable
>        "into" the existing "priviledged-bit-on" executable, the system
>        wisely turned off the "privileged bit".
>
> Sounds reasonably secure, no?  No.
>
> One day, I hit upon the following simple scheme to crack the system
> wide open:
>    1.  Compile program "A", which would perform any nefarious act
>        I wanted to perform if only the "privilege bit" were set.
>    2.  Search the system for any privileged executable that had the
>        read-write flags enabled, and that was at least as large
>        as program "A".  Call this program "B".
>    3.  Write a quickie "BASIC" program that opened "B" as a data
>        file and copied all of its bytes to temporary file "C".
>    4.  Use the same BASIC program to copy the byte contents of
>        "A" into "B".  This, amazingly enough, left the privileged
>        bit of "B" still on.

This is almost exactly the technique used to crack multics, which was designed from
the ground up to be secure including hardware memory protection.  The only
difference is that the multics crack used a hole in the memory protection hardware
to create trojans out of privileged programs.  When a user activated a trojan it
would first ransacked the users file space looking for top secret files and then
copy the original progam overitself to perform the requested operation..

>
>
> I now had my own rogue program existing under name "B", and privileged,
> and could perform absolutely any operation of which the system was
> capable, including creating my own privileged login.
>
> Once I opened the door, it was a simple matter to then get the original
> contents of "B" out of temporary copy "C" and stuff them back into
> "B" where they belonged, leaving the system as it had been originally
> (more or less...)
>
> Clearly, this was *not* something that the system developers had
> counted on...  They were apparently under the misconception that
> only the compiler would be writing to executable files.
>
> Sadly, I lacked the dishonest nature which would have enabled me
> to change my grades, or put myself on the college payroll system,
> so it was little more than an academic exercise, but still...





Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Mon, 11 Oct 1999 17:41:15 +0100
From: "Brian Gladman" <gladman@seven77.demon.co.uk>
Message-ID: <939660019.585.0.nnrp-06.c2de6a96@news.demon.co.uk>
References: <3801f648.290065@news.visi.com>
   <19991010174550.05076.00000677@ng-cl1.aol.com>
Newsgroups: sci.crypt
Lines: 46

Bruce Schneier <schneier@counterpane.com> wrote in message
news:3801f648.290065@news.visi.com...
> On 10 Oct 1999 21:45:50 GMT, djohn37050@aol.com (DJohn37050) wrote:
>
> >Multiple encryption using different ciphers was also mentioned in my
submission
> >to the 2nd AES conference entitled "Future Resiliency: A Possible New AES
> >Criterion" and is available from NIST AES web site.
>
> Yes.  In general, I find it uninteresting to talk about encryption
> when there are no constraints.  Of course you can use multiple
> encryption using different ciphers, if you have the time/gates/etc.
> Of course it's more secure, as is almost everything if you throw
> enough rounds at it.
>
> Where it really matters, and where real cryptography comes into play,
> is when you have to deal with real-world performance decisions.  I
> almost never have clients who can devote an arbitrary amount of
> computing resources to the encryption process.  This is why AES is
> important.

The principle of using two different algorithms in sequence to achieve a
degree of protection against any individual weaknesses that they might have
is a well established technique that is often used where very long term
protection is needed (i.e over decades).   This does not need an arbitrary
amount of computing resource but, for similar algorithms, about twice the
direct resources that only one would require.  Moreover, in many situations
the cost of the symmetric encryption process will be small compared with
other processing costs so this overhead will not be large.

I agree that AES is important (a) in establishing a set of secure
algorithms, and (b) in removing excessive diversity of choice.  In my view,
however, we need more than one winner since this will allow a degree of
choice in dedicated, closed applications, a worthwhile degree of diversity
in open applications (which already typically offer a choice of algorithms)
and the ability to employ multiple, sequential encryption using different
(but still open standard) algorithms where the requirement justifies this.

Moreover, I am assured that the choice between a single and multiple AES
winners remains open so the issue is an important one that is worthy of
debate.

            Brian Gladman





Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: 11 Oct 1999 16:50:03 GMT
From: djohn37050@aol.com (DJohn37050)
Message-ID: <19991011125003.11994.00000127@ng-cl1.aol.com>
References: <939660019.585.0.nnrp-06.c2de6a96@news.demon.co.uk>
Newsgroups: sci.crypt
Lines: 2

Brian says it so well.
Don Johnson


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Thu, 14 Oct 1999 12:33:11 +0100
From: "Brian Gladman" <gladman@seven77.demon.co.uk>
Message-ID: <939900926.22743.0.nnrp-12.c2de6a96@news.demon.co.uk>
References: <7u41at$1acd@enews1.newsguy.com>
   <38052703.45FB@sundialservi