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@sundialservices.com>
Newsgroups: sci.crypt
Lines: 23


Roger Schlafly <real@ieee.org> wrote in message
news:7u41at$1acd@enews1.newsguy.com...
> Sundial Services <info@sundialservices.com> wrote in message
> news:38052703.45FB@sundialservices.com...

> Yes, that's right. Those who subscribe to the theory that
> it is better to use your own homebrew combination of
> ciphers can just use the AES finalists. Everyone else will
> just use the AES winner.

The arguments for multiple AES winners cannot be dismissed so easily.  There
are at least three reasons for wanting more than one winner: (1) to provide
a degree of choice in dedicated, closed applications, (2) to provide a
degree of diversity in open applications (a well established practice), and
(3) to meet requirements that benefit from the sequential application of
different encryption algortithms (again an established practice).

         Brian Gladman






Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Thu, 14 Oct 1999 14:35:38 GMT
From: schneier@counterpane.com (Bruce Schneier)
Message-ID: <3807e932.1387860@news.visi.com>
References: <939900926.22743.0.nnrp-12.c2de6a96@news.demon.co.uk>
Newsgroups: sci.crypt
Lines: 48

On Thu, 14 Oct 1999 12:33:11 +0100, "Brian Gladman"
<gladman@seven77.demon.co.uk> wrote:

>
>Roger Schlafly <real@ieee.org> wrote in message
>news:7u41at$1acd@enews1.newsguy.com...
>> Sundial Services <info@sundialservices.com> wrote in message
>> news:38052703.45FB@sundialservices.com...
>
>> Yes, that's right. Those who subscribe to the theory that
>> it is better to use your own homebrew combination of
>> ciphers can just use the AES finalists. Everyone else will
>> just use the AES winner.
>
>The arguments for multiple AES winners cannot be dismissed so easily.  There
>are at least three reasons for wanting more than one winner: (1) to provide
>a degree of choice in dedicated, closed applications, (2) to provide a
>degree of diversity in open applications (a well established practice), and
>(3) to meet requirements that benefit from the sequential application of
>different encryption algortithms (again an established practice).

(3) doesn't make sense to me.  Whether there is one winner or several,
those that want to cascade multiple algorithms will do so.  They do so
now, and there's no problem.

I disagree with (2) also, primarily from a hardware perspective.  I've
gone to Ascend, Cisco, and other companies to discuss AES.  The first
thing they are concerned about is how they will be able to fit the
algorithms into their hardware.  Multiple algorithms means more chip
real estate; they hate that.  In software it's no problem adding
another algorithm, but it is in hardware.

As to (1), why does it make sense to give people without the expertise
to make a choice a choice?  If we, as the world's non-military
cryptographers, cannot choose an algorithm, why should we expect
others to?

My primary worry is that a system that has a choice of algorithms
will, operationally, be as secure as the weakest.  If that is the
case, diversity is necessarily bad.  And we will always have a backup
algorithm: triple-DES.  I see no benefit from NIST passing the buck
and not making a decision.

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: Thu, 14 Oct 1999 21:00:15 +0100
From: "Brian Gladman" <gladman@seven77.demon.co.uk>
Message-ID: <939931146.26204.0.nnrp-11.c2de6a96@news.demon.co.uk>
References: <3807e932.1387860@news.visi.com>
Newsgroups: sci.crypt
Lines: 81

Bruce Schneier <schneier@counterpane.com> wrote in message
news:3807e932.1387860@news.visi.com...
> On Thu, 14 Oct 1999 12:33:11 +0100, "Brian Gladman"
> <gladman@seven77.demon.co.uk> wrote:
>
[snip]
> >The arguments for multiple AES winners cannot be dismissed so
easily.There
> >are at least three reasons for wanting more than one winner: (1) to
provide
> >a degree of choice in dedicated, closed applications, (2) to provide a
> >degree of diversity in open applications (a well established practice),
and
> >(3) to meet requirements that benefit from the sequential application of
> >different encryption algortithms (again an established practice).
>
> (3) doesn't make sense to me.  Whether there is one winner or several,
> those that want to cascade multiple algorithms will do so.  They do so
> now, and there's no problem.

I am inclined to believe that five algorithms provides too much diversity
and this might be the result of choosing just one winner.  I have less of a
concern if we eliminate two and choose a winner from the remaining three but
we would need to ensure that all three that remain are free of all IPR
constraints.

> I disagree with (2) also, primarily from a hardware perspective.  I've
> gone to Ascend, Cisco, and other companies to discuss AES.  The first
> thing they are concerned about is how they will be able to fit the
> algorithms into their hardware.  Multiple algorithms means more chip
> real estate; they hate that.  In software it's no problem adding
> another algorithm, but it is in hardware.

AFAIK no-one is saying that an application must offer multiple algorithms.
And I don't see hardware suppliers going out of business in a multiple
algorithm environment - if this is a requirement I am completely confident
that they will meet it.

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).

> As to (1), why does it make sense to give people without the expertise
> to make a choice a choice?  If we, as the world's non-military
> cryptographers, cannot choose an algorithm, why should we expect
> others to?

One reason is that they may have more information than we have when they
make their choice.  It is quite possible that after the single AES winner
has been selected more information will come to light that will cast doubt
on its security performance.  The provision of limited algorithm diversity
(on the lines proposed by Don Johnson) provides a degree of protection
against this possibility.  In simple terms its not good security practice to
put all our eggs in one basket, especially so when we cannot be certain that
the basket does not have holes in it.

> My primary worry is that a system that has a choice of algorithms
> will, operationally, be as secure as the weakest.  If that is the
> case, diversity is necessarily bad.  And we will always have a backup
> algorithm: triple-DES.  I see no benefit from NIST passing the buck
> and not making a decision.

I agree that there are engineering issues involved in using mutiple
algorithms that can cause problems but these are not necesarily difficult to
overcome.  In any event we already have a great deal of practical experience
here since many internet protocols already employ such features.

And I don't see a very convincing reason to use an interim algorithm with a
64 bit block length as a backup when some of the world's best cryptographers
have provided five carefully designed algorithms from which to make our
choice.

Nor do I see multiple algorithm choice by NIST as passing the buck - its
about ensuring that the AES programme delivers what is needed instead of
assuming that what was right last time is still right now.

    Brian Gladman





Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Thu, 14 Oct 1999 22:57:23 +0200
From: Mok-Kong Shen <mok-kong.shen@t-online.de>
Message-ID: <380643B3.660859EE@t-online.de>
References: <939931146.26204.0.nnrp-11.c2de6a96@news.demon.co.uk>
Newsgroups: sci.crypt
Lines: 36

Brian Gladman wrote:
> 

> AFAIK no-one is saying that an application must offer multiple algorithms.
> And I don't see hardware suppliers going out of business in a multiple
> algorithm environment - if this is a requirement I am completely confident
> that they will meet it.
................

> One reason is that they may have more information than we have when they
> make their choice.  It is quite possible that after the single AES winner
> has been selected more information will come to light that will cast doubt
> on its security performance.  The provision of limited algorithm diversity
> (on the lines proposed by Don Johnson) provides a degree of protection
> against this possibility.  In simple terms its not good security practice to
> put all our eggs in one basket, especially so when we cannot be certain that
> the basket does not have holes in it.

> I agree that there are engineering issues involved in using mutiple
> algorithms that can cause problems but these are not necesarily difficult to
> overcome.  In any event we already have a great deal of practical experience
> here since many internet protocols already employ such features.
.....................
> 
> Nor do I see multiple algorithm choice by NIST as passing the buck - its
> about ensuring that the AES programme delivers what is needed instead of
> assuming that what was right last time is still right now.


I guess it could perhaps also be useful to know the raison de etre 
of 3DES after DES has come out. 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.

M. K. Shen


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Thu, 14 Oct 1999 23:07:57 -0700
From: "Roger Schlafly" <real@ieee.org>
Message-ID: <7u6g9a$hl1@enews3.newsguy.com>
References: <19991014205614.19168.00000326@ng-fo1.aol.com>
   <380643B3.660859EE@t-online.de>
Newsgroups: sci.crypt
Lines: 14

DJohn37050 <djohn37050@aol.com> wrote in message
news:19991014205614.19168.00000326@ng-fo1.aol.com...
> BTW, when I made my presentation to ANSI X9F1, the consensus by a large
margin
> was to ask NIST to include "future resiliency" as an AES criterion.

What do the bankers mean by the term "future resiliency"? That
the AES winner not be broken in the future?

These are the same folks who want "strong" keys for RSA. Do
they also want strong keys for AES? <g>





Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: 15 Oct 1999 09:18:32 GMT
From: peter@office.knowledge.com (Peter Galbavy)
Message-ID: <slrn80dsb7.bi6.peter@office.knowledge.com>
References: <939931146.26204.0.nnrp-11.c2de6a96@news.demon.co.uk>
Newsgroups: sci.crypt
Lines: 24

In article <939931146.26204.0.nnrp-11.c2de6a96@news.demon.co.uk>,
Brian Gladman wrote:
>I am inclined to believe that five algorithms provides too much diversity
>and this might be the result of choosing just one winner.  I have less of a
>concern if we eliminate two and choose a winner from the remaining three but
>we would need to ensure that all three that remain are free of all IPR
>constraints.

Should I, in all seriousness, be thankful that the AES contest is
being undertaken in the US ? In the UK, I can guarentee you the
outcome: The winner would be the company holding the most profitable
IPR that then subsequently employs the government miniter(s)
responsible for the selection, after they leave parliment.

What safeguards are there to prevent this ? I remember reading that
most participants will give out "free" licenses if their contestant is
chosen - but is there a mandatory surrender of those rights required
to complete ? (Kudos to those who are entering non-IPR laden entries).

Regards,
-- 
Peter Galbavy
Knowledge Matters Ltd
http://www.knowledge.com/


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: 16 Oct 1999 17:30:59 GMT
From: David A Molnar <dmolnar@fas.harvard.edu>
Message-ID: <7uacoj$sva$1@news.fas.harvard.edu>
References: <slrn80dsb7.bi6.peter@office.knowledge.com>
Newsgroups: sci.crypt
Lines: 8

Peter Galbavy <peter@office.knowledge.com> wrote:
> chosen - but is there a mandatory surrender of those rights required
> to complete ? (Kudos to those who are entering non-IPR laden entries).

Not to compete, but the winner must be freely available to all in the same
fashion as DES and DSA are. 




Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Sun, 17 Oct 1999 17:04:28 GMT
From: ritter@io.com (Terry Ritter)
Message-ID: <380a0172.9562959@news.io.com>
References: <7uacoj$sva$1@news.fas.harvard.edu>
Newsgroups: sci.crypt
Lines: 29


On 16 Oct 1999 17:30:59 GMT, in <7uacoj$sva$1@news.fas.harvard.edu>,
in sci.crypt David A Molnar <dmolnar@fas.harvard.edu> wrote:

>Peter Galbavy <peter@office.knowledge.com> wrote:
>> chosen - but is there a mandatory surrender of those rights required
>> to complete ? (Kudos to those who are entering non-IPR laden entries).
>
>Not to compete, but the winner must be freely available to all in the same
>fashion as DES and DSA are. 

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.  Of course, those who had no rights were not
inconvenienced at all.  

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.  Everybody
gets to make money, except for cipher designers.  Which of course
tends to prevent the establishment of an industry of cipher design,
something I assume the government would like to avoid.  

---
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: Tue, 19 Oct 1999 19:08:17 GMT
From: Tim Tyler <tt@cryogen.com>
Message-ID: <FJv6Ht.Jss@bath.ac.uk>
References: <3807e932.1387860@news.visi.com>
Newsgroups: sci.crypt
Lines: 13

Bruce Schneier <schneier@counterpane.com> wrote:

: If we, as the world's non-military cryptographers, cannot choose an
: algorithm, why should we expect others to?

There is no such thing as a non-military cryptographer:

Business is war (Japaneese proverb).
-- 
__________
 |im |yler  The Mandala Centre  http://www.mandala.co.uk/  tt@cryogen.com

Imagination is the only weapon in the war against reality.


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Thu, 14 Oct 1999 17:07:03 GMT
From: Bob Silverman <bobs@rsa.com>
Message-ID: <7u52ja$t8e$1@nnrp1.deja.com>
References: <939900926.22743.0.nnrp-12.c2de6a96@news.demon.co.uk>
Newsgroups: sci.crypt
Lines: 35

In article <939900926.22743.0.nnrp-12.c2de6a96@news.demon.co.uk>,
  "Brian Gladman" <gladman@seven77.demon.co.uk> wrote:
>
> The arguments for multiple AES winners cannot be dismissed so easily.

Yes it can.  By one word.  The word is:

interoperability.

By allowing multiple algorithms you are certain to guarantee that there
will be some users who can't talk to others.



 There
> are at least three reasons for wanting more than one winner: (1) to
provide
> a degree of choice in dedicated, closed applications, (2) to provide a
> degree of diversity in open applications

Why does everyone use TCP/IP?

Repeat after me:

A Standard allows interoperability.



--
Bob Silverman
"You can lead a horse's ass to knowledge, but you can't make him think"


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: Thu, 14 Oct 1999 19:48:47 +0100
From: "Brian Gladman" <gladman@seven77.demon.co.uk>
Message-ID: <939926885.15815.0.nnrp-13.c2de6a96@news.demon.co.uk>
References: <7u52ja$t8e$1@nnrp1.deja.com>
Newsgroups: sci.crypt
Lines: 39

Bob Silverman <bobs@rsa.com> wrote in message
news:7u52ja$t8e$1@nnrp1.deja.com...
> In article <939900926.22743.0.nnrp-12.c2de6a96@news.demon.co.uk>,
>   "Brian Gladman" <gladman@seven77.demon.co.uk> wrote:
> >
> > The arguments for multiple AES winners cannot be dismissed so easily.
>
> Yes it can.  By one word.  The word is:
>
> interoperability.

But the domain of crytographic use includes systems for which
interoperability is not a requirement.

> By allowing multiple algorithms you are certain to guarantee that there
> will be some users who can't talk to others.

True, but also true if a single AES winner is chosen since we are not to my
knowledge insisting that everyone uses it.

>  There
> > are at least three reasons for wanting more than one winner: (1) to
> provide
> > a degree of choice in dedicated, closed applications, (2) to provide a
> > degree of diversity in open applications
>
> Why does everyone use TCP/IP?

Why do most internet security protocols provide for dynamic algorithm
negotiation?

> A Standard allows interoperability.

where interoperability is needed.

   Brian Gladman





Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: 15 Oct 1999 09:42:23 -0400
From: juola@mathcs.duq.edu (Patrick Juola)
Message-ID: <7u7avv$d60$1@quine.mathcs.duq.edu>
References: <3806845E.16D4C14F@aspi.net>
   <7u52ja$t8e$1@nnrp1.deja.com>
Newsgroups: sci.crypt
Lines: 35

In article <3806845E.16D4C14F@aspi.net>,
Trevor Jackson, III <fullmoon@aspi.net> wrote:
>Bob Silverman wrote:
>
>> In article <939900926.22743.0.nnrp-12.c2de6a96@news.demon.co.uk>,
>>   "Brian Gladman" <gladman@seven77.demon.co.uk> wrote:
>> >
>> > The arguments for multiple AES winners cannot be dismissed so easily.
>>
>> Yes it can.  By one word.  The word is:
>>
>> interoperability.
>>
>> By allowing multiple algorithms you are certain to guarantee that there
>> will be some users who can't talk to others.
>
>No.  This is an invalid conclusion.
>
>Any users desiring to communicate will be able to select a mechanism to do
>so.  Any analysis dismissing the active participation of the users in the
>dynamic selection of their channel properties from amoug the telephone, fax,
>and email is trivially flawed.

Nonsense.  The Three-Initial-Corp. decides to use XYZ encryption for
all it's communication needs and invests several billion dollars in XYZ-
compliant mailers, routers, telephones, and so forth.  The Even-Larger-
Five-Initial-Corp., independently, decides to invest in PQ encryption
and spends similarly huge amounts on its scrambler phone.

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.  And what's going to happen
when ELFIC buys TIC?

	-kitten


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Fri, 15 Oct 1999 13:41:02 -0700
From: "Roger Schlafly" <real@ieee.org>
Message-ID: <7u83ep$1gep@enews3.newsguy.com>
References: <380760A1.BB7D356F@aspi.net>
   <7u7h2m$dcs$1@quine.mathcs.duq.edu>
Newsgroups: sci.crypt
Lines: 11

Trevor Jackson, III <fullmoon@aspi.net> wrote in message
news:380760A1.BB7D356F@aspi.net...
> By this reasoning we should only use telephones and avoid fax and email
channels?
> After all it would reduce the tooling costs, right?

When they put in fax and email standards, they didn't deliberately
introduce incompatible formats for diversity purposes.





Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: 15 Oct 1999 22:33:17 GMT
From: djohn37050@aol.com (DJohn37050)
Message-ID: <19991015183317.04628.00000020@ng-fq1.aol.com>
References: <7u83ep$1gep@enews3.newsguy.com>
Newsgroups: sci.crypt
Lines: 11

Roger, In fact there are multiple fax transmission protocols, each vendor came
up with one and then cross licensed with others.  But at first each fax would
only talk to another from the same vendor (for example).  Fax machines now do a
negotiation.  

And we all know about competing email formats, etc.

Talk to the Irish about potato monoculture.  That is why there are more
Irish-decendents in USA than in Ireland.  Dependence on one thing is fine, AS
LONG AS IT WORKS.
Don Johnson


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Fri, 15 Oct 1999 21:11:00 -0700
From: "Roger Schlafly" <real@ieee.org>
Message-ID: <7u8tqq$21q0@enews3.newsguy.com>
References: <19991015183317.04628.00000020@ng-fq1.aol.com>
Newsgroups: sci.crypt
Lines: 21

DJohn37050 <djohn37050@aol.com> wrote in message
news:19991015183317.04628.00000020@ng-fq1.aol.com...
> Roger, In fact there are multiple fax transmission protocols, each vendor
came
> up with one and then cross licensed with others.  But at first each fax
would
> only talk to another from the same vendor (for example).  Fax machines now
do a
> negotiation.

Yes, there were multiple protocols until a standard was adopted.
The standard sure didn't add protocols for the sake of diversity.

> Talk to the Irish about potato monoculture.

You've lost me here. Is there some Irish position on potato
standardization that I should know about? <g>






Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: 20 Oct 1999 08:32:54 -0400
From: juola@mathcs.duq.edu (Patrick Juola)
Message-ID: <7ukcpm$nad$1@quine.mathcs.duq.edu>
References: <FJv7r5.LD8@bath.ac.uk>
   <38127c13.21178922@news.visi.com>
   <19991015183317.04628.00000020@ng-fq1.aol.com>
Newsgroups: sci.crypt
Lines: 29

In article <FJv7r5.LD8@bath.ac.uk>, Tim Tyler  <tt@cryogen.com> wrote:
>Bruce Schneier <schneier@counterpane.com> wrote:
>: On 15 Oct 1999 22:33:17 GMT, djohn37050@aol.com (DJohn37050) wrote:
>
>:>Talk to the Irish about potato monoculture.  That is why there are more
>:>Irish-decendents in USA than in Ireland.  Dependence on one thing is fine,
>:>AS LONG AS IT WORKS.
>
>: And security is one of the places where it works.  Security is a
>: chain, generally as secure as the weakest link.  Diversity is fine in
>: the potato crop, but a disaster in security.
>
>German WWII could be portrayed as the failure of a monoculture in
>cryptography (though there was more than one "crop").
>
>Diversity *can* be a disaster in security - if the same message winds up
>being encoded using different crypto-systems, with different strengths.

Interesting that you should write these two paragraphs in tandem with
each other.... 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.  For example, sowing mines in a particular area so
that a warning would have to be sent both to the submarines and
the surface ships.

Why are we sure that the same trick wouldn't work for multiple AES
winners?

	-kitten


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Wed, 20 Oct 1999 17:58:29 GMT
From: Tim Tyler <tt@cryogen.com>
Message-ID: <FJwxxH.I9H@bath.ac.uk>
References: <7ukcpm$nad$1@quine.mathcs.duq.edu>
Newsgroups: sci.crypt
Lines: 38

Patrick Juola <juola@mathcs.duq.edu> wrote:
: In article <FJv7r5.LD8@bath.ac.uk>, Tim Tyler  <tt@cryogen.com> wrote:
:>Bruce Schneier <schneier@counterpane.com> wrote:
:>: On 15 Oct 1999 22:33:17 GMT, djohn37050@aol.com (DJohn37050) wrote:

[cypher monoculture]

:>: And security is one of the places where it works.  Security is a
:>: chain, generally as secure as the weakest link.  Diversity is fine in
:>: the potato crop, but a disaster in security.

[snip "German WWII could be portrayed as the failure of a monoculture"]

:>Diversity *can* be a disaster in security - if the same message winds up
:>being encoded using different crypto-systems, with different strengths.

: Interesting that you should write these two paragraphs in tandem with
: each other.... 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.

Yes - I an aware of the history.

: Why are we sure that the same trick wouldn't work for multiple AES
: winners?

I'm not advocating using multiple cyphers at the same time.  I was
talking about changing cyphers at regular intervals, and the need for
reprogrammable cyphermachines.

*Even* when changing cyphers there's increased risk of plaintext attack.

However *NOT* changing cyphers at all is probably an even worse strategy.
-- 
__________
 |im |yler  The Mandala Centre  http://www.mandala.co.uk/  tt@cryogen.com

Love is grand; divorce, forty grand.


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Tue, 19 Oct 1999 00:09:29 +0200
From: Mok-Kong Shen <mok-kong.shen@t-online.de>
Message-ID: <380B9A99.3BA612BB@t-online.de>
References: <38117b17.20927257@news.visi.com>
   <3806845E.16D4C14F@aspi.net>
   <7u52ja$t8e$1@nnrp1.deja.com>
Newsgroups: sci.crypt
Lines: 18

Bruce Schneier wrote:
> 

> This is a great theory.  When is it going to happen in the U.S.
> cellphone industry.  Phone interoperability is actually something
> important, not like security; I can't buy a phone that allows me to
> dynamically select among different digital standards, and none of the
> serious vendors are moving in this direction.
> 
> The theory may be a Good Thing (tm), but it often doesn't work in
> practice.

It nonetheless shows that one can manage to live with some
non-interoperability. I indicated elsewhere that there are a
number of programming language standards, resulting in some 
(apparently yet tolerable) non-interoperability.

M. K. Shen


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Thu, 14 Oct 1999 21:50:49 +0100
From: "Brian Gladman" <gladman@seven77.demon.co.uk>
Message-ID: <939934178.27828.0.nnrp-11.c2de6a96@news.demon.co.uk>
References: <7u54g2$1huj@enews3.newsguy.com>
   <939900926.22743.0.nnrp-12.c2de6a96@news.demon.co.uk>
Newsgroups: sci.crypt
Lines: 63

Roger Schlafly <real@ieee.org> wrote in message
news:7u54g2$1huj@enews3.newsguy.com...
> Brian Gladman <gladman@seven77.demon.co.uk> wrote in message
> news:939900926.22743.0.nnrp-12.c2de6a96@news.demon.co.uk...
> > The arguments for multiple AES winners cannot be dismissed so easily.
> There
> > are at least three reasons for wanting more than one winner: (1) to
> provide
> > a degree of choice in dedicated, closed applications, (2) to provide a
> > degree of diversity in open applications (a well established practice),
> and
> > (3) to meet requirements that benefit from the sequential application of
> > different encryption algortithms (again an established practice).
>
> You are just saying that one algorithm won't be good enough for
> some reason. But what is the reason? Why is diversity/choice
> good?

Because we simply don't have a way of knowing what will happen in future.
You may believe that the open cryptographic community can be certain that a
particular algorithm does not have as yet undetected weaknesses but I am not
convinced of this. I hence do not want to be forced by lack of diversity in
the market to put all my eggs in one basket.  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).

I also think its wrong to assume that the diversity of algorithms in
existing applications is there in the absense of any market demand for it.

> There is diversity in practice because there is disagreement
> about what is best. If it turns out that the five finalists are all
> more or less equally good, then there may never be a consensus
> about what to use unless someone like NIST declares one to
> be the standard.

Nearly all practical standards offer a host of options so it is quite wrong
to suggest that we cannot meet most interoperability needs while also
meeting the need for controlled algorithm diversity - I can list a large
number of internet protocol standards, all of which are designed to
accommodate algorithm diversity.

So its quite wrong to suggest that we cannot meet most interoperability
needs without imposing an 'algorithmic monoculture' on the whole of the
world.

A lot of people like standards. Those who
> don't can do whatever they want anyway.

That's dangerously close to saying I don't care a stuff about your needs as
long as mine are met.  If you really hold this view there's not much point
in continuing this debate.

I, too, like standards and I have worked pretty hard to help ensure that the
AES standard will succeed. But whether or not we have a standard is quite
different from deciding whether or not the standard should support
requirements for controlled algorithm diversity.

      Brian Gladman






Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Thu, 14 Oct 1999 22:40:53 -0700
From: "Roger Schlafly" <real@ieee.org>
Message-ID: <7u6emi$gfv@enews3.newsguy.com>
References: <939934178.27828.0.nnrp-11.c2de6a96@news.demon.co.uk>
Newsgroups: sci.crypt
Lines: 52

Brian Gladman <gladman@seven77.demon.co.uk> wrote in message
news:939934178.27828.0.nnrp-11.c2de6a96@news.demon.co.uk...
> Because we simply don't have a way of knowing what will happen in future.
> You may believe that the open cryptographic community can be certain that
a
> particular algorithm does not have as yet undetected weaknesses but I am
not
> convinced of this. I hence do not want to be forced by lack of diversity
in
> the market to put all my eggs in one basket.  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).

I think what you are really arguing for is cipher complexity. There is
a school of thought that says complexity in a cipher is a good thing.
If a complex cipher is built from many components, then it is more
secure because it is less susceptible to the failure of one component.
Or so the theory goes. But if so, that is just an argument that the
AES winner should be a complex cipher. (Some of the candidates
are more complex than others.)

> Nearly all practical standards offer a host of options so it is quite
wrong
> to suggest that we cannot meet most interoperability needs while also
> meeting the need for controlled algorithm diversity - I can list a large
> number of internet protocol standards, all of which are designed to
> accommodate algorithm diversity.

The AES candidates all offer a choice of keys -- those are your
options.

Can you name any internet protocol standards which designed in
algorithm diversity just because of a theory that such diversity is
a good thing? Usually the diversity is for interoperability with
existing system. The AES diversity you are proposing is contrary
to interoperability interests.

> > A lot of people like standards. Those who
> > don't can do whatever they want anyway.
>
> That's dangerously close to saying I don't care a stuff about your needs
as
> long as mine are met.  If you really hold this view there's not much point
> in continuing this debate.

I think a single AES standard can meet your needs. I just don't think
you need algorithm diversity.





Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Fri, 15 Oct 1999 10:22:50 +0100
From: "Brian Gladman" <gladman@seven77.demon.co.uk>
Message-ID: <939980369.732.0.nnrp-14.c2de6a96@news.demon.co.uk>
References: <7u6emi$gfv@enews3.newsguy.com>
Newsgroups: sci.crypt
Lines: 110

Roger Schlafly <real@ieee.org> wrote in message
news:7u6emi$gfv@enews3.newsguy.com...
> Brian Gladman <gladman@seven77.demon.co.uk> wrote in message
> news:939934178.27828.0.nnrp-11.c2de6a96@news.demon.co.uk...
> > Because we simply don't have a way of knowing what will happen in
future.
> > You may believe that the open cryptographic community can be certain
that
> a
> > particular algorithm does not have as yet undetected weaknesses but I am
> not
> > convinced of this. I hence do not want to be forced by lack of diversity
> in
> > the market to put all my eggs in one basket.  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).
>
> I think what you are really arguing for is cipher complexity. There is
> a school of thought that says complexity in a cipher is a good thing.
> If a complex cipher is built from many components, then it is more
> secure because it is less susceptible to the failure of one component.
> Or so the theory goes. But if so, that is just an argument that the
> AES winner should be a complex cipher. (Some of the candidates
> are more complex than others.)
>
> > Nearly all practical standards offer a host of options so it is quite
> wrong
> > to suggest that we cannot meet most interoperability needs while also
> > meeting the need for controlled algorithm diversity - I can list a large
> > number of internet protocol standards, all of which are designed to
> > accommodate algorithm diversity.
>
> The AES candidates all offer a choice of keys -- those are your
> options.
>
> Can you name any internet protocol standards which designed in
> algorithm diversity just because of a theory that such diversity is
> a good thing? Usually the diversity is for interoperability with
> existing system. The AES diversity you are proposing is contrary
> to interoperability interests.

PGP (and hence OpenPGP) implements diversity but was never designed to
interoperate with other applications or systems.  Many internet protocols
are 'closed' in design terms - that is they don't interoperate with other
protocols - and this means that their design does not need to offer a choice
of algorithms but they very often do.  There are many reasons for this, one
being to give users a choice.

Moreover PGP has achieved a high level of global interoperability without
adopting a single algorithm.  Hence the idea that extensive interoperabilty
requires a single algorithm standard is not only wrong but demonstrably so.

> > > A lot of people like standards. Those who
> > > don't can do whatever they want anyway.
> >
> > That's dangerously close to saying I don't care a stuff about your needs
> as
> > long as mine are met.  If you really hold this view there's not much
point
> > in continuing this debate.
>
> I think a single AES standard can meet your needs. I just don't think
> you need algorithm diversity.

As I have already said, I see three needs where we can gain benefits from
algorithm diversity but for the sake of this debate let me concentrate on
just one of them.

I have to meet some requirements that involve protection for 50+ years and I
want to provide a degree of protection against the possibility that any
single algorithm will be found later to have a serious flaw.  I intend to do
this by applying two (or more) different encryption algorithms in sequence -
an established practice in such situations and one that most information
security professionals will accept as valid.

In order to meet this need I would like to use the best internationally
agreed, open standard algorithms that are available and I see the AES
process as a good basis for making my selection.  While I could use any of
the five finalists in combination (assuming that potential IPR problems with
two of them in this situation are removed), I would like to reduce the
diversity of choice from, say, five to three because five is more than I
need and the widespread use of all five finalists will create greater
interoperability problems than are necessary to meet my diversity needs.

My aim here is to balance two conflicting AES requirements - on the one hand
interoperability requires that we reduce algortihm choice as far as is
possible but on the other hand the need for resiliance requires that we
increase the number of algorithms.

We can clearly choose a single AES winner and meet the diversity requirement
external to the AES process in an uncontrolled way or we can control the
diversity by doing this within the AES process by selecting more than one
winner (I would select two or three but not more).

I am simply arguing that we achieve a better balance between
interoperability and diversity needs by doing this in a controlled rather
than an uncontrolled way.

I respect your right to believe that my diversity needs are no more than a
figment of my imagination but I assure you that they are based of nearly 40
years of real experience in a world where information security failures cost
lives.

             Brian Gladman





Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Fri, 15 Oct 1999 18:44:04 +0100
From: "Brian Gladman" <gladman@seven77.demon.co.uk>
Message-ID: <940009374.23904.0.nnrp-11.c2de6a96@news.demon.co.uk>
References: <7u7anu$11o3@enews3.newsguy.com>
   <939980369.732.0.nnrp-14.c2de6a96@news.demon.co.uk>
Newsgroups: sci.crypt
Lines: 102

Roger Schlafly <real@ieee.org> wrote in message
news:7u7anu$11o3@enews3.newsguy.com...
> Brian Gladman <gladman@seven77.demon.co.uk> wrote in message
> news:939980369.732.0.nnrp-14.c2de6a96@news.demon.co.uk...
> > PGP (and hence OpenPGP) implements diversity but was never designed to
> > interoperate with other applications or systems.  Many internet
protocols
> > are 'closed' in design terms - that is they don't interoperate with
other
> > protocols - and this means that their design does not need to offer a
> choice
> > of algorithms but they very often do.  There are many reasons for this,
> one
> > being to give users a choice.
>
> The primary reason for the algorithm choice is for PGP to migrate away
> from some algorithims that have some undesirable properties (such as
> patents).

As I said, there are many reasons, one being to offer users a choice.

> > Moreover PGP has achieved a high level of global interoperability
without
> > adopting a single algorithm.  Hence the idea that extensive
> interoperabilty
> > requires a single algorithm standard is not only wrong but demonstrably
> so.
>
> Its interoperability is in spite of algorithm choice. There are lots of
PGP
> users who have RSA-only versions who cannot handle DH keys.

This is the real world where a balance has to be struck between conflictng
needs with the result that none can be met perfectly. Interoperability is
important in many systems but this does not mean that it always dominates
other needs.

> When there is diversity in the marketplace, I can see where PGP would
> want to address that. It might simply want to satisfy differing
perceptions
> of users. What I don't understand is why NIST would want to deliberately
> inject diveristy into the market.
>
> > I have to meet some requirements that involve protection for 50+ years
and
> I
> > want to provide a degree of protection against the possibility that any
> > single algorithm will be found later to have a serious flaw.  I intend
to
> do
> > this by applying two (or more) different encryption algorithms in
> sequence -
> > an established practice in such situations and one that most information
> > security professionals will accept as valid.
>
> There are probably also people who will not trust AES as is, and use
> triple-AES. If NIST sanctioned triple-AES, they'd use triple-triple-AES.
> That's fine, but it is pretty useless for NIST to try to accommodate them

No-one is asking for this AFAIK.   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.   You are prepared to take the risk and that's fine but I
am not and there are many like me. And its perfectly reasonable to seek an
AES result that will allow for such needs.

> > In order to meet this need I would like to use the best internationally
> > agreed, open standard algorithms that are available and I see the AES
> > process as a good basis for making my selection.  While I could use any
of
> > the five finalists in combination (assuming that potential IPR problems
> with
> > two of them in this situation are removed), I would like to reduce the
> > diversity of choice from, say, five to three because five is more than I
> > need and the widespread use of all five finalists will create greater
> > interoperability problems than are necessary to meet my diversity needs.
>
> You don't really want to use AES, you just want to use NIST AES
> submissions as input to your own homebrew cipher. That's fine -- you
> may get your 50+ year security. But you are doing something
> nonstandard.

Wrong, I want to use AES and I therefore want to ensure that the output of
the AES process can fully meet my needs. If that were not true we would not
be having this debate.

No, I'm not inventing a new cipher, I am using ciphers which have been
designed by some of the world best cryptographers in a way that protects
myself to a degree against the possibility that one of them may contain an
as yet unknown flaw.  You may not understand or appreciate this need but
that does not mean that it does not exist.

Those who advocate the protection of a large proportion of the world's
secure data with a single algorithm in pursuit of interoperability may be
content to bear the risk if the chosen cipher fails but I prefer to have a
contingency plan to cover this possibility.   I guess it depends on whether
or not we are gambers but I must admit that I have never been that keen on
gambling.  Especially when the stakes are so high.

    Brian Gladman





Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Fri, 15 Oct 1999 12:38:13 -0700
From: "Roger Schlafly" <real@ieee.org>
Message-ID: <7u7vp0$1ed1@enews3.newsguy.com>
References: <940009374.23904.0.nnrp-11.c2de6a96@news.demon.co.uk>
Newsgroups: sci.crypt
Lines: 19

Brian Gladman <gladman@seven77.demon.co.uk> wrote in message
news:940009374.23904.0.nnrp-11.c2de6a96@news.demon.co.uk...
> > There are probably also people who will not trust AES as is, and use
> > triple-AES. If NIST sanctioned triple-AES, they'd use triple-triple-AES.
> > That's fine, but it is pretty useless for NIST to try to accommodate
them
>
> No-one is asking for this AFAIK.   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.

No, you are asking for a triple-AES solution because you don't
trust AES. Perhaps your special needs justify it. That's fine, but
I don't know why you'd want to burden everyone else with an
overly complex AES when you are not going to trust it anyway.





Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Fri, 15 Oct 1999 23:29:56 +0200
From: Mok-Kong Shen <mok-kong.shen@t-online.de>
Message-ID: <38079CD4.67ADE027@t-online.de>
References: <7u7vp0$1ed1@enews3.newsguy.com>
Newsgroups: sci.crypt
Lines: 12

Roger Schlafly wrote:
> 

> No, you are asking for a triple-AES solution because you don't
> trust AES. Perhaps your special needs justify it. That's fine, but
> I don't know why you'd want to burden everyone else with an
> overly complex AES when you are not going to trust it anyway.

Triple DES standard doesn't burden those that use single DES,
as far as I am aware.

M. K. Shen


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Sat, 16 Oct 1999 09:07:02 -0700
From: "Roger Schlafly" <real@ieee.org>
Message-ID: <7ua7pn$2q5s@enews3.newsguy.com>
References: <38079CD4.67ADE027@t-online.de>
Newsgroups: sci.crypt
Lines: 9

Mok-Kong Shen <mok-kong.shen@t-online.de> wrote in message
news:38079CD4.67ADE027@t-online.de...
> Triple DES standard doesn't burden those that use single DES,
> as far as I am aware.

Sure it does -- they don't interoperate.





Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Sat, 16 Oct 1999 19:35:43 +0200
From: Mok-Kong Shen <mok-kong.shen@t-online.de>
Message-ID: <3808B76F.50B7D6D0@t-online.de>
References: <7ua7pn$2q5s@enews3.newsguy.com>
Newsgroups: sci.crypt
Lines: 33

Roger Schlafly wrote:
> 
> Mok-Kong Shen <mok-kong.shen@t-online.de> wrote
> > Triple DES standard doesn't burden those that use single DES,
> > as far as I am aware.
> 
> Sure it does -- they don't interoperate.

People that use triple DES don't use single DES and vice versa.
So there is no need of inperoperability. I was answering your
point (if I understood correctly) that having an additional
standard like triple DES leads to disadvantages of those who
use DES. There aren't any such arising from the mere fact that a 
separate standard exists. (In other follow-ups I employed the
analogy in the field of programming languages.)

I like to take this opportunity also to repeat (wrpt what is discussed
elsewhere in this thread) that on the day when AES is finalized
all top candidates are likely to have received the same degree/amount
of scrutiny by the best of professionals. So the chance of using
multiple encryption of these leading to weakness (relative to
single encryption with the winner of AES) is negligibly small or
practically zero. The single disadvantage may be in performance,
which could be tolerated in at least a part of the practical 
applications. I personally consider it to be a naive idea to 
consider one single cipher (one that doesn't yet have gone through 
the test of time as DES has done) to be so extremely good that one 
never needs to bother about its possible vulnerability. To those who 
are SO SURE about modern (super) high technology being able to 
absulutely guarantee all their needs (whether crypto or not) I like 
to recall one single name: Titanic.

M. K. Shen


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Sat, 16 Oct 1999 11:08:08 -0700
From: "Roger Schlafly" <real@ieee.org>
Message-ID: <7uaest$2u47@enews3.newsguy.com>
References: <3808B76F.50B7D6D0@t-online.de>
Newsgroups: sci.crypt
Lines: 25

Mok-Kong Shen <mok-kong.shen@t-online.de> wrote in message
news:3808B76F.50B7D6D0@t-online.de...
> Roger Schlafly wrote:
> >
> > Mok-Kong Shen <mok-kong.shen@t-online.de> wrote
> > > Triple DES standard doesn't burden those that use single DES,
> > > as far as I am aware.
> >
> > Sure it does -- they don't interoperate.
>
> People that use triple DES don't use single DES and vice versa.

Exactly. No interoperability.

> To those who
> are SO SURE about modern (super) high technology being able to
> absulutely guarantee all their needs (whether crypto or not) I like
> to recall one single name: Titanic.

Yes, that's what iterated ciphers are. Big, slow, clumsy, and
misplaced confidence in something just because it is big, slow,
and clumsy.





Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Sat, 16 Oct 1999 14:15:25 -0600
From: jcoffin@taeus.com (Jerry Coffin)
Message-ID: <MPG.12728a683b4683939896ff@news.mindspring.com>
References: <7uaest$2u47@enews3.newsguy.com>
Newsgroups: sci.crypt
Lines: 30

In article <7uaest$2u47@enews3.newsguy.com>, real@ieee.org says...

[ ... ]

> > People that use triple DES don't use single DES and vice versa.
> 
> Exactly. No interoperability.

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.  If two programs are going to 
interoperate, they obviously need at least one common algorithm, and 
some way of agreeing upon the algorithm they'll use when they're 
interoperating.

I doubt it takes more than 100 lines of code on average to implement 
the AES finalist algorithms.  That means a product that included ALL 
of them would still only be devoting around 500 lines of code to 
implementing the algorithms themselves.  Obviously the amount of space 
devoted can (and typically will) depend on how heavily the code's been 
optimized, but ultimately the fact remains: implementing all of them 
(especially since code samples of all are available already) isn't 
likely to be a particularly large part of a implementing a complete 
encryption product.

-- 
    Later,
    Jerry.
 
The universe is a figment of its own imagination.


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: 16 Oct 1999 16:11:57 -0700
From: daw@blowfish.isaac.cs.berkeley.edu (David Wagner)
Message-ID: <7ub0nt$9ep$1@blowfish.isaac.cs.berkeley.edu>
References: <MPG.12728a683b4683939896ff@news.mindspring.com>
Newsgroups: sci.crypt
Lines: 6

In article <MPG.12728a683b4683939896ff@news.mindspring.com>,
Jerry Coffin <jcoffin@taeus.com> wrote:
> I doubt it takes more than 100 lines of code on average to implement 
> the AES finalist algorithms.

In software, it's easy; in hardware, it's a huge added cost.


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Sat, 16 Oct 1999 23:21:25 -0400
From: "Trevor Jackson, III" <fullmoon@aspi.net>
Message-ID: <380940B5.FD686CC9@aspi.net>
References: <7ub0nt$9ep$1@blowfish.isaac.cs.berkeley.edu>
Newsgroups: sci.crypt
Lines: 13

David Wagner wrote:

> In article <MPG.12728a683b4683939896ff@news.mindspring.com>,
> Jerry Coffin <jcoffin@taeus.com> wrote:
> > I doubt it takes more than 100 lines of code on average to implement
> > the AES finalist algorithms.
>
> In software, it's easy; in hardware, it's a huge added cost.

Huge compared to what?  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.



Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Sun, 17 Oct 1999 10:19:20 -0600
From: jcoffin@taeus.com (Jerry Coffin)
Message-ID: <MPG.1273a370da6f75de989701@news.mindspring.com>
References: <7ub0nt$9ep$1@blowfish.isaac.cs.berkeley.edu>
Newsgroups: sci.crypt
Lines: 62

In article <7ub0nt$9ep$1@blowfish.isaac.cs.berkeley.edu>, 
daw@blowfish.isaac.cs.berkeley.edu says...
> In article <MPG.12728a683b4683939896ff@news.mindspring.com>,
> Jerry Coffin <jcoffin@taeus.com> wrote:
> > I doubt it takes more than 100 lines of code on average to implement 
> > the AES finalist algorithms.
> 
> In software, it's easy; in hardware, it's a huge added cost.

The TwoFish FPGA implementation uses an equivalent of roughly 28,000 
gates.  If we assume that's about average for the five finalists (RC-6 
could probably be smaller, Serpent likely larger, ...) and that we 
can't share any noticeable amount of logic between implementations, 
that means implementing all five should take around 150,000 gates 
(rounding up).  Adding in even some fairly complex logic to handle 
selecting between them, possibly a bit of caching, etc., we should be 
able to fit all five into, say, 200,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.  That 
ignores things like packaging costs and such, but these should be 
_close_ to constant -- we'd only need a few extra pins to deal with 
selecting the algorithm(s) to use.

Of course, in a real chip, you'd probably want to build in something 
like a PCI interface, so the chip would be easy to hook up to existing 
peripherals.  That'll add on around 4 to 5 square millimeters or so by 
itself -- I.e. close to the area needed to implement the encryption 
algorithms.  This would increase the cost to around two dollars per 
chip.

Unless the product involved was being built in relatively limited 
quantities, the cost of including all five algorithms would NOT be 
terribly high.  When dealing with limited quantities, unles extremely 
high performance was needed, it would probably be easier to simply 
embed a processor core and put the algorithms in ROM.

Just for example, the MicroSPARC IIep is available under Sun's 
Community Source License, making it easy for even a very poorly 
financed startup company (e.g. a college kid in his dorm room) to 
download and start a design.  It uses around 208,000 gates for the 
core and licenses for 3% of the selling price of the chip into which 
it's embedded IIRC.  You could probably even reduce their estimated 
gate count somewhat, because in this situation you probably wouldn't 
need some things they normally include such as PCI and S-bus.

In the end, I just don't buy the idea that the cost of including all 
five in a hardware design would be prohibitive unless the quantity 
being produced was _extremely_ limited so the initial design cost 
predominated overall costs.  In this case, I think a design based on 
an embedded microprocessor core would eliminate the problems, though 
of course at some cost in licensing the core.  Given that products 
produced in such limited quantities are generally quite expensive 
anyway, I doubt the incremental cost of including more algorithms 
would be particularly noticeable.

-- 
    Later,
    Jerry.
 
The universe is a figment of its own imagination.


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: 18 Oct 1999 12:47:36 -0700
From: daw@blowfish.isaac.cs.berkeley.edu (David Wagner)
Message-ID: <7uftgo$a56$1@blowfish.isaac.cs.berkeley.edu>
References: <MPG.1273a370da6f75de989701@news.mindspring.com>
Newsgroups: sci.crypt
Lines: 11

In article <MPG.1273a370da6f75de989701@news.mindspring.com>,
Jerry Coffin <jcoffin@taeus.com> wrote:
> In the end, I just don't buy the idea that the cost of including all 
> five in a hardware design would be prohibitive [...]

And yet, the hardware folks seem to disagree strongly.

Personally, I'm more inclined to believe people with experience
building hardware than to believe my own theories of how the world
ought to work.  Maybe we ought to hear from some of the hardware
vendors on this topic?


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: 19 Oct 1999 01:07:11 -0700
From: daw@blowfish.isaac.cs.berkeley.edu (David Wagner)
Message-ID: <7uh8rf$at1$1@blowfish.isaac.cs.berkeley.edu>
References: <MPG.1275b95159ce0eee989711@news.mindspring.com>
   <7uftgo$a56$1@blowfish.isaac.cs.berkeley.edu>
Newsgroups: sci.crypt
Lines: 29

In article <MPG.1275b95159ce0eee989711@news.mindspring.com>,
Jerry Coffin <jcoffin@taeus.com> wrote:
> In article <7uftgo$a56$1@blowfish.isaac.cs.berkeley.edu>, 
> daw@blowfish.isaac.cs.berkeley.edu says...
> > In article <MPG.1273a370da6f75de989701@news.mindspring.com>,
> > Jerry Coffin <jcoffin@taeus.com> wrote:
> > > In the end, I just don't buy the idea that the cost of including all 
> > > five in a hardware design would be prohibitive [...]
> > 
> > And yet, the hardware folks seem to disagree strongly.
> 
> _What_ hardware folks?  I'm basically quoting directly from the 
> hardware designers I know -- and for years now, I've been basically 
> the lone software guy in a company devoted primarily to hardware 
> design.

If that's true, then I'd be persuaded, although it _is_ different from
what I've heard.  This seems important enough that we ought to have some
hardware folks lend their experience here; any chance in getting one of
them (or you) to write a brief letter to NIST explaining their preference
and the criteria they used to reach it?  (I assume it's unlikely they'll
post to sci.crypt.)

P.S. Do your comments apply to small resource-starved devices,
such as cellphones?  I got the impression that CPU-makers have more
transistors than they know what to do with, but that makers of hardware
for resource-limited devices such as cellphones were much more reticent
to waste even a few hundred gates unnecessarily.  In fact, I thought
this was one of the key design criterion for A5 (the GSM cipher).


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Tue, 19 Oct 1999 12:51:25 -0600
From: jcoffin@taeus.com (Jerry Coffin)
Message-ID: <MPG.12766b53e5e6087a989716@news.mindspring.com>
References: <7uh8rf$at1$1@blowfish.isaac.cs.berkeley.edu>
Newsgroups: sci.crypt
Lines: 51

In article <7uh8rf$at1$1@blowfish.isaac.cs.berkeley.edu>, 
daw@blowfish.isaac.cs.berkeley.edu says...

[ ... ] 

> P.S. Do your comments apply to small resource-starved devices,
> such as cellphones?  I got the impression that CPU-makers have more
> transistors than they know what to do with, but that makers of hardware
> for resource-limited devices such as cellphones were much more reticent
> to waste even a few hundred gates unnecessarily.  In fact, I thought
> this was one of the key design criterion for A5 (the GSM cipher).

A cell phone would generally be an _ideal_ candidate for a software 
implementation.  A typical cell phone already includes at least one 
processor (and often a couple of them).  For example, Motorola cell 
phones use Motorola DSPs, Qualcomm chip-sets incorporate an ARM 
processor core, and so on.

In addition, cell phones use vocoders that compress the speech _very_ 
heavily before transmission -- the data rate involved is normally on 
the order of 8-14 K/sec., so encryption would add _very_ little to the 
CPU load, and the performance of a dedicated hardware implementation 
would be completely unnecessary.

We're talking (at most) about using a slightly larger ROM or Flash 
chip to hold the code.  Even that is unlikely though: it's fairly rare 
that the ROM or Flash chip in a cell phone is really full to start 
with, and it would be unusual that adding a couple of encryption 
algorithms would be enough to push the requirement to the next larger 
size of memory chip (unless some of the AES candidates use more code 
than I realize).  Offhand, I suspect RAM needed to implement S-boxes 
and such would be a bigger problem, but unless there was an idea of 
applying the algorithms serially instead of merely allowing a choice 
between algorithms, you'd only have to include enough RAM for the 
single heaviest user, not enough for all of them to operate at the 
same time.

OTOH, to say much about suitability of AES to cell phones, I'd have to 
re-check the packet sizes in which cell phones normally transmit data.  
If the packet size isn't (at least close to) as large as a cipher 
block, this would cause a problem.  Obviously if you incorporated AES, 
you'd be designing a new standard, so increasing the block size a 
little wouldn't necessarily be a major problem.  OTOH, if we were 
looking at increasing the packet size a lot, it could cause a problem, 
especially if you were using TDMA instead of CDMA.

-- 
    Later,
    Jerry.
 
The universe is a figment of its own imagination.


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: 19 Oct 1999 13:19:26 -0700
From: daw@blowfish.isaac.cs.berkeley.edu (David Wagner)
Message-ID: <7uijoe$bca$1@blowfish.isaac.cs.berkeley.edu>
References: <MPG.12766b53e5e6087a989716@news.mindspring.com>
Newsgroups: sci.crypt
Lines: 19

In article <MPG.12766b53e5e6087a989716@news.mindspring.com>,
Jerry Coffin <jcoffin@taeus.com> wrote:
> A cell phone would generally be an _ideal_ candidate for a software 
> implementation.

I've heard some complaints that, at least for some of the AES finalists,
software just won't offer good enough performance.  The CPU is already at
near-full utilization in some of these suckers, I'm told, and sometimes
you only get a 8-bit or 16-bit processor as well (which some AES finalists
aren't optimized for).

I don't understand cellphones very well, so I can't speak authoritatively
on them, but I don't see any reason to focus exclusively on them,
either; I mentioned them only as an example of a resource-starved device.
More generally, we can consider any low-end device that wants to implement
crypto in hardware.  I don't see any reason to believe that the low end
will go away anytime soon.  Am I confused?

Anyway, what do we do about the low end where space/power/etc. is tight?


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: 20 Oct 1999 16:25:50 GMT
From: aph@cygnus.remove.co.uk (Andrew Haley)
Message-ID: <7ukqee$g66$3@korai.cygnus.co.uk>
References: <MPG.1273a370da6f75de989701@news.mindspring.com>
Newsgroups: sci.crypt
Lines: 11

Jerry Coffin (jcoffin@taeus.com) wrote:
: The TwoFish FPGA implementation uses an equivalent of roughly 28,000 
: gates.

Hmmm, that's interesting.  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.  Okay,
that's a stream cipher rather than a block cipher, but it might be all
that's needed.

Andrew.


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Sun, 17 Oct 1999 17:05:02 GMT
From: ritter@io.com (Terry Ritter)
Message-ID: <380a019f.9607208@news.io.com>
References: <7ub0nt$9ep$1@blowfish.isaac.cs.berkeley.edu>
Newsgroups: sci.crypt
Lines: 29


On 16 Oct 1999 16:11:57 -0700, in
<7ub0nt$9ep$1@blowfish.isaac.cs.berkeley.edu>, in sci.crypt
daw@blowfish.isaac.cs.berkeley.edu (David Wagner) wrote:

>In article <MPG.12728a683b4683939896ff@news.mindspring.com>,
>Jerry Coffin <jcoffin@taeus.com> wrote:
>> I doubt it takes more than 100 lines of code on average to implement 
>> the AES finalist algorithms.
>
>In software, it's easy; in hardware, it's a huge added cost.

There is "hardware," and then there is hardware:  Many "hardware"
systems now use embedded processors to perform the "hardware" task,
and there may be multiple such processors.  Typically such systems
load from flash and save state in flash; there is no floppy or hard
drive or file system, but in a real sense, everything is software
inside.  

In engineering design we are even seeing very complex single-chip
systems which take initialization from flash and save state in flash.
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.  

---
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: Mon, 18 Oct 1999 20:05:13 GMT
From: schneier@counterpane.com (Bruce Schneier)
Message-ID: <38167d2c.21460142@news.visi.com>
References: <MPG.12728a683b4683939896ff@news.mindspring.com>
Newsgroups: sci.crypt
Lines: 23

On Sat, 16 Oct 1999 14:15:25 -0600, jcoffin@taeus.com (Jerry Coffin)
wrote:
>I doubt it takes more than 100 lines of code on average to implement 
>the AES finalist algorithms.  That means a product that included ALL 
>of them would still only be devoting around 500 lines of code to 
>implementing the algorithms themselves.  Obviously the amount of space 
>devoted can (and typically will) depend on how heavily the code's been 
>optimized, but ultimately the fact remains: implementing all of them 
>(especially since code samples of all are available already) isn't 
>likely to be a particularly large part of a implementing a complete 
>encryption product.

Don't think software; it's easy in software.  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.  It means that there is going to
be some trade-off between features.

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: Mon, 18 Oct 1999 20:03:25 GMT
From: schneier@counterpane.com (Bruce Schneier)
Message-ID: <38157cdd.21380804@news.visi.com>
References: <38079CD4.67ADE027@t-online.de>
Newsgroups: sci.crypt
Lines: 24

On Fri, 15 Oct 1999 23:29:56 +0200, Mok-Kong Shen
<mok-kong.shen@t-online.de> wrote:

>Roger Schlafly wrote:
>> 
>
>> No, you are asking for a triple-AES solution because you don't
>> trust AES. Perhaps your special needs justify it. That's fine, but
>> I don't know why you'd want to burden everyone else with an
>> overly complex AES when you are not going to trust it anyway.
>
>Triple DES standard doesn't burden those that use single DES,
>as far as I am aware.

It depends what you mean by burden.  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.  It's
so large that I might not do it, even if DES is insecure.

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, 19 Oct 1999 00:09:43 +0200
From: Mok-Kong Shen <mok-kong.shen@t-online.de>
Message-ID: <380B9AA7.99C00E85@t-online.de>
References: <38157cdd.21380804@news.visi.com>
Newsgroups: sci.crypt
Lines: 27

Bruce Schneier wrote:
> 
> <mok-kong.shen@t-online.de> wrote:

> >
> >> No, you are asking for a triple-AES solution because you don't
> >> trust AES. Perhaps your special needs justify it. That's fine, but
> >> I don't know why you'd want to burden everyone else with an
> >> overly complex AES when you are not going to trust it anyway.
> >
> >Triple DES standard doesn't burden those that use single DES,
> >as far as I am aware.
> 
> It depends what you mean by burden.  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.  It's
> so large that I might not do it, even if DES is insecure.

But you nevertheless do at least have a chance of a choice, because 
of the fact that triple-DES exists. If this didn't exist, you would 
have no choice even if you badly desired to get away from insecurity. 
Anyway, 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).

M. K. Shen


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Sat, 16 Oct 1999 09:59:05 +0100
From: "Brian Gladman" <gladman@seven77.demon.co.uk>
Message-ID: <940065003.1402.0.nnrp-14.c2de6a96@news.demon.co.uk>
References: <7u7vp0$1ed1@enews3.newsguy.com>
Newsgroups: sci.crypt
Lines: 66


Roger Schlafly <real@ieee.org> wrote in message
news:7u7vp0$1ed1@enews3.newsguy.com...
> Brian Gladman <gladman@seven77.demon.co.uk> wrote in message
> news:940009374.23904.0.nnrp-11.c2de6a96@news.demon.co.uk...
> > > There are probably also people who will not trust AES as is, and use
> > > triple-AES. If NIST sanctioned triple-AES, they'd use
triple-triple-AES.
> > > That's fine, but it is pretty useless for NIST to try to accommodate
> them
> >
> > No-one is asking for this AFAIK.   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.
>
> No, you are asking for a triple-AES solution because you don't
> trust AES. Perhaps your special needs justify it. That's fine, but
> I don't know why you'd want to burden everyone else with an
> overly complex AES when you are not going to trust it anyway.

For you trust may be as simple as 'yes' or 'no' but for me its not, I trust
things to varying degrees. I have a high degree of trust in my Bank in
looking after my money but I don't trust them absolutely and I hence check
what they do.  For me trust is not a binary variable but a continuous one
from, say, 0 (no trust) to 1 (absolute trust).

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.  And the consequences
are dire if the cipher does fail since a large proportion of the world's
secure data may well end up being protected by it.

In 'hand waving' terms we might loosely say that the risk we are taking is
the product of 'a very small probability of failure' with 'a huge
consequence if this failure occurs'.  And the problem we face is that we
simply don't have any idea whether the resulting product is so small that we
can afford to ignore it or so large that we must do something about it.

Optimists will hope it is small and carry the risk - in other words they are
gambling.   Pessimists will also hope it is small but they will assume it is
not and will hence develop a contingency plan to cope if the worst happens.
I don't object to you gambing provided it does not cause me harm but in AES
we are gambling for the world as a whole and not just for ourselves.  And
that's why the debate is so important.

And there is nothing necessarily burdensome about an AES process in which
the result gives a formal status to more than one algorithm.  For example, I
have no objection to a 'multiple winners' result which indicates that where
only a single algorithm is necessary it should be algorithm X.  Nor have I
ruled out other possibilities which allow most of the requirements of
'multiple winner' advocates to be met without major compromises on the part
of those who want just one winner.

And why do you consider that my need to have a contingency plan to guard
against unlikely but possible future events is so special?  Other
contributions to the debate here show very clearly that I am not alone.
Many disasters have been made much worse because people have failed to
anticipate and plan for them.

     Brian Gladman





Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: 16 Oct 1999 18:52:33 -0400
From: juola@mathcs.duq.edu (Patrick Juola)
Message-ID: <7uavjh$fs8$1@quine.mathcs.duq.edu>
References: <3808FDFD.9779F327@t-online.de>
   <939980369.732.0.nnrp-14.c2de6a96@news.demon.co.uk>
Newsgroups: sci.crypt
Lines: 62

In article <3808FDFD.9779F327@t-online.de>,
Mok-Kong Shen  <mok-kong.shen@t-online.de> wrote:
>Roger Schlafly wrote:
>> 
>> Exactly. No interoperability.
>
>Why do you care so much about interoperability? For a specific group 
>of communication partners to communicate securely, it suffices that 
>they argree on a specific software/hardware to use.

Because the whole point of computer -- or more generally, communications --
networks is to permit communication between widely distant and possibly
unfamilar parties.  One of the nice things about the telephone is that
someone can telephone me from almost anywhere in the world, irrespective
of whether or not they've communicated with me before or whether or not
I have the same sort of telephone that they do.  I can pass out my
phone and fax numbers on my business cards, confident that anyone
can communicate with me -- or that they can tell other people how to
communicate with on the basis only of that information.

I can drive almost anywhere, secure in the knowledge that no matter
where I go, I will find a gas station that interoperates with my
car.  I didn't have to put some sort of special doohickey in my
engine to make sure that the gasoline I put in in Denver will run
in the engine I bought in New York.

Similarly, I can put my PGP key into a public location and anyone
who wants it -- and has a copy of PGP -- can get my key and communicate
with me "securely."  However, how many people have PGP?  And how many
people have a different secure Email protocol that is incompatible
with PGP?  And how many people are not going to want to switch over?



> If because of 
>lack of interoperability some three-lettered agencicies can't 
>intercept their messages, that's even better, isn't it?

Well, gee.  Let's assume that no one can communiate at all -- that
means that no possible interception can occur.  That would be
best of all, wouldn't it?

> If someone 
>participates in two groups with two different software/hardware, he 
>can acquire the necessary software/hardware, can't he?

Not if it's expensive or ubiquitous.   Do you have any idea how much it
would cost to replace all of IBM's desk telephones?

> If there is
>sufficient market demand, manufacturers would provide facilities
>for handling messages of both groups, much like my electric razor,
>which works both in Europe and in US, where the voltages are different.
>The language of my mother tongue needs an entirely different computer
>input system than for English or the European languages. There isn't
>any interoperability possible. Do you see the point?

Yes.  *IF* you have enough money to buy everything twice then you're
"merely" inconvenienced.

	-kitten



Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Sun, 17 Oct 1999 12:20:57 +0200
From: Mok-Kong Shen <mok-kong.shen@t-online.de>
Message-ID: <3809A309.2BB799AA@t-online.de>
References: <7uavjh$fs8$1@quine.mathcs.duq.edu>
Newsgroups: sci.crypt
Lines: 41

Patrick Juola wrote:
>
> Mok-Kong Shen  <mok-kong.shen@t-online.de> wrote:

> >Why do you care so much about interoperability? For a specific group
> >of communication partners to communicate securely, it suffices that
> >they argree on a specific software/hardware to use.
> 
> Because the whole point of computer -- or more generally, communications --
> networks is to permit communication between widely distant and possibly
> unfamilar parties.  One of the nice things about the telephone is that
> someone can telephone me from almost anywhere in the world, irrespective
> of whether or not they've communicated with me before or whether or not

You missed my point. Highly secure communication is different from 
public communication (e.g. a message through courier is different 
from an announcement in the newspaper). The communication partners
in the first case know each other's identity and they agree on a 
certain secure means of communication before actually exchanging
messages. If the security requirement is high engough, they can 
(normally) afford higher cost, lower throughput, more inconvenience, 
etc. etc. So there are different encryption algorithms suitable for 
different environments. Is triple DES interoperable with single DES? 
Why is triple DES currently in use at all?? The suggestion of Don 
Johnson to have super-AES doesn't exclude the use of AES and vice 
versa. Even if AES were provided as a standard to encrypt all
people's e-mail on the internet, you are still free to employ
additional encryption to your messages (unless some crypto law
forbids that, because three-lettered agencies want to read everything).
To repeat, you use multiple encryption WHEN (and only when) you need 
higher security. If multiple encryption with a number of top AES
candidates is a standard, it doesn't mean that 'everywhere'
there has to be facilities provided for that. (Personal analogy: I 
don't feel a need of fax, because the rate of incoming messages is 
very low. So I don't spend the money to buy a fax machine, while 
lots of my friends do. Later, when the situation changes, I might 
decide to have fax facility.)

I suppose I have also answered the parts that I snipped.

M. K. Shen


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: 17 Oct 1999 14:00:35 GMT
From: djohn37050@aol.com (DJohn37050)
Message-ID: <19991017100035.11703.00000284@ng-bk1.aol.com>
References: <3809A309.2BB799AA@t-online.de>
Newsgroups: sci.crypt
Lines: 3

Just want to point out that the idea of multiple encryption using diff. algs
(Super AES), etc. is fairly obvious.
Don Johnson


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Sun, 17 Oct 1999 17:06:54 GMT
From: ritter@io.com (Terry Ritter)
Message-ID: <380a01c1.9641523@news.io.com>
References: <7uavjh$fs8$1@quine.mathcs.duq.edu>
Newsgroups: sci.crypt
Lines: 45


On 16 Oct 1999 18:52:33 -0400, in <7uavjh$fs8$1@quine.mathcs.duq.edu>,
in sci.crypt juola@mathcs.duq.edu (Patrick Juola) wrote:

>In article <3808FDFD.9779F327@t-online.de>,
>Mok-Kong Shen  <mok-kong.shen@t-online.de> wrote:
>>Roger Schlafly wrote:
>>> 
>>> Exactly. No interoperability.
>>
>>Why do you care so much about interoperability? For a specific group 
>>of communication partners to communicate securely, it suffices that 
>>they argree on a specific software/hardware to use.
>
>Because the whole point of computer -- or more generally, communications --
>networks is to permit communication between widely distant and possibly
>unfamilar parties.  One of the nice things about the telephone is that
>someone can telephone me from almost anywhere in the world, irrespective
>of whether or not they've communicated with me before or whether or not
>I have the same sort of telephone that they do.  I can pass out my
>phone and fax numbers on my business cards, confident that anyone
>can communicate with me -- or that they can tell other people how to
>communicate with on the basis only of that information.
>
>I can drive almost anywhere, secure in the knowledge that no matter
>where I go, I will find a gas station that interoperates with my
>car.  I didn't have to put some sort of special doohickey in my
>engine to make sure that the gasoline I put in in Denver will run
>in the engine I bought in New York.

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.  

As to knowing which cipher to use, that information should come along
with the key.  

If you do not have that cipher, you might negotiate a cipher you both
have, or drop down to triple-AES or triple-DES (which you both will
have), or get the cipher itself sent along with the key.  

---
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 09:59:44 GMT
From: ritter@io.com (Terry Ritter)
Message-ID: <3806fab2.1389948@news.io.com>
References: <7u6emi$gfv@enews3.newsguy.com>
Newsgroups: sci.crypt
Lines: 66


On Thu, 14 Oct 1999 22:40:53 -0700, in
<7u6emi$gfv@enews3.newsguy.com>, in sci.crypt "Roger Schlafly"
<real@ieee.org> wrote:

>Brian Gladman <gladman@seven77.demon.co.uk> wrote in message
>news:939934178.27828.0.nnrp-11.c2de6a96@news.demon.co.uk...
>> Because we simply don't have a way of knowing what will happen in future.
>> You may believe that the open cryptographic community can be certain that
>a
>> particular algorithm does not have as yet undetected weaknesses but I am
>not
>> convinced of this. I hence do not want to be forced by lack of diversity
>in
>> the market to put all my eggs in one basket.  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).
>
>I think what you are really arguing for is cipher complexity. There is
>a school of thought that says complexity in a cipher is a good thing.
>If a complex cipher is built from many components, then it is more
>secure because it is less susceptible to the failure of one component.
>Or so the theory goes. But if so, that is just an argument that the
>AES winner should be a complex cipher. (Some of the candidates
>are more complex than others.)
>
>> Nearly all practical standards offer a host of options so it is quite
>wrong
>> to suggest that we cannot meet most interoperability needs while also
>> meeting the need for controlled algorithm diversity - I can list a large
>> number of internet protocol standards, all of which are designed to
>> accommodate algorithm diversity.
>
>The AES candidates all offer a choice of keys -- those are your
>options.
>
>Can you name any internet protocol standards which designed in
>algorithm diversity just because of a theory that such diversity is
>a good thing? Usually the diversity is for interoperability with
>existing system. The AES diversity you are proposing is contrary
>to interoperability interests.

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.  

Thus, multiple ciphers would seem to have modest effects on
interoperability, with the major advantage of allowing the entire net
to change to a better cipher on first notice of weakness.  

The current alternative, of course, is to have a integrated system,
and we must replace the entire system simply to upgrade the cipher.
That means we must wait for somebody else to produce an acceptable
replacement, which probably requires us to first *prove* that the
"universal" cipher is weak (otherwise, everyone would argue for
"interoperability").  Could Germany and Japan *prove* their ciphers
were weak in WWII?  Would they have been better off changing their
(broken) ciphers?  

---
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 06:52:02 -0700
From: "Roger Schlafly" <real@ieee.org>
Message-ID: <7u7bfm$126l@enews3.newsguy.com>
References: <3806fab2.1389948@news.io.com>
Newsgroups: sci.crypt
Lines: 22

Terry Ritter <ritter@io.com> wrote in message
news:3806fab2.1389948@news.io.com...
> 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.

Yes, having several ciphers is equivalent to having a couple of
extra key bits.

> ...  Could Germany and Japan *prove* their ciphers
> were weak in WWII?  Would they have been better off changing their
> (broken) ciphers?

Obviously they would have tried to design better ciphers if they knew
their ciphers were being broken. But 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..





Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: 15 Oct 1999 18:23:32 GMT
From: djohn37050@aol.com (DJohn37050)
Message-ID: <19991015142332.05892.00000048@ng-co1.aol.com>
References: <7u7bfm$126l@enews3.newsguy.com>
Newsgroups: sci.crypt
Lines: 15

If one reads the history of military crypto, one finds the following:
1) User errors resulted in many breaks.
2) Even when used correctly, the "correct" method was imperfect and led to
breaks.
3) When breaks were suspected, they tried to fix it by incremental improvement,
such as adding a new cipher wheel, adding a new column to a transpostion
cipher, shortening the cryptoperiod.  All these made it more difficult for the
cryptanalyst, but because it was incremental, they knew the original solution
and just needed to figure out the incremental change, which was a MUCH easier
task.

And in fact they HAD diversity, 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.
Don Johnson


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Fri, 15 Oct 1999 22:26:17 +0200
From: Mok-Kong Shen <mok-kong.shen@t-online.de>
Message-ID: <38078DE9.11ABADDD@t-online.de>
References: <7u7bfm$126l@enews3.newsguy.com>
Newsgroups: sci.crypt
Lines: 19

Roger Schlafly wrote:
> 
> Terry Ritter <ritter@io.com> wrote
> > ...  Could Germany and Japan *prove* their ciphers
> > were weak in WWII?  Would they have been better off changing their
> > (broken) ciphers?
> 
> Obviously they would have tried to design better ciphers if they knew
> their ciphers were being broken. But 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..

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, much like the three medalists 
in Olympic games.

M. K. Shen


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Sun, 17 Oct 1999 15:45:38 GMT
From: ritter@io.com (Terry Ritter)
Message-ID: <3809eeae.4757943@news.io.com>
References: <7u7bfm$126l@enews3.newsguy.com>
Newsgroups: sci.crypt
Lines: 39


On Fri, 15 Oct 1999 06:52:02 -0700, in
<7u7bfm$126l@enews3.newsguy.com>, in sci.crypt "Roger Schlafly"
<real@ieee.org> wrote:

>Terry Ritter <ritter@io.com> wrote in message
>news:3806fab2.1389948@news.io.com...
>> 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.
>
>Yes, having several ciphers is equivalent to having a couple of
>extra key bits.
>
>> ...  Could Germany and Japan *prove* their ciphers
>> were weak in WWII?  Would they have been better off changing their
>> (broken) ciphers?
>
>Obviously they would have tried to design better ciphers if they knew
>their ciphers were being broken. But 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..

Might, might, might.  In contrast, we *know* what happens when someone
is convinced their cipher is strong enough:  the classic examples are
Germany and Japan in WWII.  

On the other hand, perhaps you have a better suggestion for
controlling this disturbing reality.  The problem is not proposals for
change.  The problem is the conventional wisdom which is insufficient
in itself.  

---
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: 16 Oct 1999 17:44:34 GMT
From: David A Molnar <dmolnar@fas.harvard.edu>
Message-ID: <7uadi2$sva$2@news.fas.harvard.edu>
References: <3806fab2.1389948@news.io.com>
Newsgroups: sci.crypt
Lines: 19

Terry Ritter <ritter@io.com> wrote:

> 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.  

You (or anyone else reading) may want to look at this master's thesis on
"Self-Describing Cryptography" :

http://ben.adida.net/thesis/

which covers exactly the problem of transferring the description of a
cipher along with the message it's going to decrypt. Part of the thesis is
a sample implementation in Java. I can't find the actual code up on the
site, but presumably one could ask the author for more details.

thanks, 
-David


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Mon, 18 Oct 1999 20:18:53 GMT
From: schneier@counterpane.com (Bruce Schneier)
Message-ID: <38197f36.21981738@news.visi.com>
References: <7uadi2$sva$2@news.fas.harvard.edu>
Newsgroups: sci.crypt
Lines: 23

On 16 Oct 1999 17:44:34 GMT, David A Molnar <dmolnar@fas.harvard.edu>
wrote:
>You (or anyone else reading) may want to look at this master's thesis on
>"Self-Describing Cryptography" :
>
>http://ben.adida.net/thesis/
>
>which covers exactly the problem of transferring the description of a
>cipher along with the message it's going to decrypt. Part of the thesis is
>a sample implementation in Java. I can't find the actual code up on the
>site, but presumably one could ask the author for more details.

I've seen proposals for this kind of thing.  You can think of it as
the cipher having a secondary key that helps choose among a family of
transformations.  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.

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: Mon, 18 Oct 1999 20:01:36 GMT
From: schneier@counterpane.com (Bruce Schneier)
Message-ID: <38147c73.21274850@news.visi.com>
References: <939934178.27828.0.nnrp-11.c2de6a96@news.demon.co.uk>
Newsgroups: sci.crypt
Lines: 17

On Thu, 14 Oct 1999 21:50:49 +0100, "Brian Gladman"
<gladman@seven77.demon.co.uk> wrote:
>Nearly all practical standards offer a host of options so it is quite wrong
>to suggest that we cannot meet most interoperability needs while also
>meeting the need for controlled algorithm diversity - I can list a large
>number of internet protocol standards, all of which are designed to
>accommodate algorithm diversity.

Yes, but security standards are different.  IPsec is much less secure
because of all the options it has.  Complexity is security's worst
enemy.

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: Mon, 18 Oct 1999 23:44:01 +0100
From: "Brian Gladman" <gladman@seven77.demon.co.uk>
Message-ID: <940286649.17035.0.nnrp-02.c2de6a96@news.demon.co.uk>
References: <38147c73.21274850@news.visi.com>
Newsgroups: sci.crypt
Lines: 32


Bruce Schneier <schneier@counterpane.com> wrote in message
news:38147c73.21274850@news.visi.com...
> On Thu, 14 Oct 1999 21:50:49 +0100, "Brian Gladman"
> <gladman@seven77.demon.co.uk> wrote:
> >Nearly all practical standards offer a host of options so it is quite
wrong
> >to suggest that we cannot meet most interoperability needs while also
> >meeting the need for controlled algorithm diversity - I can list a large
> >number of internet protocol standards, all of which are designed to
> >accommodate algorithm diversity.
>
> Yes, but security standards are different.  IPsec is much less secure
> because of all the options it has.  Complexity is security's worst
> enemy.

I agree in general but a certain amount of complexity is usually unavoidable
in meeting other requirements.  Most often the need to minimise complexity
is just one more requirement that has to be balanced against other
conflicting requirements in reaching an acceptable overall solution.

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.

Moreover, complexity, like beauty, is often in the eye of the beholder.

          Brian Gladman






Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Fri, 15 Oct 1999 10:13:27 +0200
From: Mok-Kong Shen <mok-kong.shen@t-online.de>
Message-ID: <3806E227.B0D0A454@t-online.de>
References: <7u6d12$feh@enews3.newsguy.com>
   <380685F0.737F2516@aspi.net>
Newsgroups: sci.crypt
Lines: 26

Roger Schlafly wrote:
> 
> Trevor Jackson, III <fullmoon@aspi.net> wrote in message
> news:380685F0.737F2516@aspi.net...
> > Let those who like standards pick from the final five.  If you like
> standards,
> > more standards is better isn't it?
> 
> No. Two standards for the same thing means that there is
> no standard. Your statement is like saying, if you like
> monogamy, more wives is better.

Remember that triple DES IS a seperate standard from single DES.
Why did the financial people think that single DES could be a
risk to them well before the hardware (processing speed) and
theory (differential analysis etc.) have pushed such a risk
out of a dream into reality? I guess from this fact that the 
risk assessment and security requiments of one person can be VERY 
different from another. Thus it is extremely difficult to have
one thing that fits all. I personally don't deem it entirely
unrealistic that the history might indeed repeat here: After AES 
there would soon be triple AES.

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: Fri, 15 Oct 1999 06:55:45 -0400
From: "Trevor Jackson, III" <fullmoon@aspi.net>
Message-ID: <38070831.6163F02B@aspi.net>
References: <7u6d12$feh@enews3.newsguy.com>
   <380685F0.737F2516@aspi.net>
Newsgroups: sci.crypt
Lines: 24

Roger Schlafly wrote:

> Trevor Jackson, III <fullmoon@aspi.net> wrote in message
> news:380685F0.737F2516@aspi.net...
> > Let those who like standards pick from the final five.  If you like
> standards,
> > more standards is better isn't it?
>
> No. Two standards for the same thing means that there is
> no standard. Your statement is like saying, if you like
> monogamy, more wives is better.

You are misusing the term standard.  You may have a point, but it is
obscured by your linguistic contortions.

Consider the simple act of physical measurements.  In the (reactionary)
United States there are two standards for measuring physical quantities.
They are completely independent.  Completely redundant.  But no one
claims that "two standards for the same things means that there is no
standard".

Two standards doe snot mean ero standards.  Two standards means two
standards.  2 != 0.



Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Fri, 15 Oct 1999 10:27:55 -0400
From: "Trevor Jackson, III" <fullmoon@aspi.net>
Message-ID: <380739EB.8FCE7629@aspi.net>
References: <7u796b$10u7@enews3.newsguy.com>
   <38070831.6163F02B@aspi.net>
Newsgroups: sci.crypt
Lines: 30

Roger Schlafly wrote:

> Trevor Jackson, III <fullmoon@aspi.net> wrote in message
> news:38070831.6163F02B@aspi.net...
> > Roger Schlafly wrote:
> > > No. Two standards for the same thing means that there is
> > > no standard. Your statement is like saying, if you like
> > > monogamy, more wives is better.
> >
> > You are misusing the term standard.  You may have a point, but it is
> > obscured by your linguistic contortions.
> >
> > Consider the simple act of physical measurements.  In the (reactionary)
> > United States there are two standards for measuring physical quantities.
> > They are completely independent.  Completely redundant.  But no one
> > claims that "two standards for the same things means that there is no
> > standard".
>
> You mean because we have feet and meters in the US? To the extent
> this is true, distance measurement is not standardized. It is not an ideal
> situation, as evidenced by the recent crash of the martian probe.

Right.  It isn't ideal.  It's reality.  If we design for an ideal world rather
than the real one we are doomed to failure.

Disasters attributable to misplaced decimals and loss of significance are far
more common than those attributable to units confusion.  The Hubble space
telescope fiasco was caused by loss of significance in the model use to make
the optical reference for the primary optics.



Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: 16 Oct 99 01:56:56 GMT
From: jsavard@ecn.ab.ca ()
Message-ID: <3807db68.0@ecn.ab.ca>
References: <939900926.22743.0.nnrp-12.c2de6a96@news.demon.co.uk>
Newsgroups: sci.crypt
Lines: 20

Brian Gladman (gladman@seven77.demon.co.uk) wrote:
: The arguments for multiple AES winners cannot be dismissed so easily.

Come to think of it, there *is* an easy way to dismiss the idea of having
multiple AES winners.

The AES entrants only promised to allow free use of their ciphers if their
own cipher was _the_ winner of the AES process. Hence, changing the rules
now, and declaring multiple winners would be unfair to those entrants
which are retaining proprietary rights to their ciphers.

However, just because only one algorithm is *the* winner in no way
prevents the other algorithms from being used, with the permission of
their inventors. Since the NSA has even spoken, and proclaimed that none
of the five finalists is insecure, we _have_ a plurality of block ciphers
to use.

They just won't all be declared "winners".

John Savard


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Mon, 18 Oct 1999 20:20:09 GMT
From: schneier@counterpane.com (Bruce Schneier)
Message-ID: <381a80ed.22420769@news.visi.com>
References: <3807db68.0@ecn.ab.ca>
Newsgroups: sci.crypt
Lines: 28

On 16 Oct 99 01:56:56 GMT, jsavard@ecn.ab.ca () wrote:

>Brian Gladman (gladman@seven77.demon.co.uk) wrote:
>: The arguments for multiple AES winners cannot be dismissed so easily.
>
>Come to think of it, there *is* an easy way to dismiss the idea of having
>multiple AES winners.
>
>The AES entrants only promised to allow free use of their ciphers if their
>own cipher was _the_ winner of the AES process. Hence, changing the rules
>now, and declaring multiple winners would be unfair to those entrants
>which are retaining proprietary rights to their ciphers.
>
>However, just because only one algorithm is *the* winner in no way
>prevents the other algorithms from being used, with the permission of
>their inventors. Since the NSA has even spoken, and proclaimed that none
>of the five finalists is insecure, we _have_ a plurality of block ciphers
>to use.
>
>They just won't all be declared "winners".

Heh.  It's probably against the rules, though.

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 14:45:42 GMT
From: jsavard@tenMAPSONeerf.edmonton.ab.ca (John Savard)
Message-ID: <3803487e.524419@news.prosurfr.com>
References: <3801f648.290065@news.visi.com>
   <19991010174550.05076.00000677@ng-cl1.aol.com>
Newsgroups: sci.crypt
Lines: 19

schneier@counterpane.com (Bruce Schneier) wrote, in part:

>I
>almost never have clients who can devote an arbitrary amount of
>computing resources to the encryption process.  This is why AES is
>important.

And, of course, for the specific case where a fairly large amount of
computing resources are available for encryption - a desktop computer
encrypting E-mail, the application that was well handled even by the
original DOS versions of PGP - keeping keys secure and the like is
easily mishandled (although PGP was well-designed, and limited that
threat as far as possible).

If one encrypts with a separate box with, say, a little 68HC11 inside
of it, one can keep those keys locked away rather better.

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: Tue, 12 Oct 1999 19:24:28 GMT
From: schneier@counterpane.com (Bruce Schneier)
Message-ID: <38038aa5.1795716@news.visi.com>
References: <3803487e.524419@news.prosurfr.com>
Newsgroups: sci.crypt
Lines: 29

On Tue, 12 Oct 1999 14:45:42 GMT, jsavard@tenMAPSONeerf.edmonton.ab.ca
(John Savard) wrote:

>schneier@counterpane.com (Bruce Schneier) wrote, in part:
>
>>I
>>almost never have clients who can devote an arbitrary amount of
>>computing resources to the encryption process.  This is why AES is
>>important.
>
>And, of course, for the specific case where a fairly large amount of
>computing resources are available for encryption - a desktop computer
>encrypting E-mail, the application that was well handled even by the
>original DOS versions of PGP - keeping keys secure and the like is
>easily mishandled (although PGP was well-designed, and limited that
>threat as far as possible).

Right.  E-mail encryption is a perfect application where cascades are
reasonable.  Pretty much no one cares if they have to wait 10
milliseconds or 50 milliseconds for the encryption to occur.

And I also agree that everything around the encryption is more
vulnerable.

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: Fri, 15 Oct 1999 15:03:10 GMT
From: dianelos@tecapro.com
Message-ID: <7u7fn4$l5o$1@nnrp1.deja.com>
References: <3801f648.290065@news.visi.com>
   <19991010174550.05076.00000677@ng-cl1.aol.com>
Newsgroups: sci.crypt
Lines: 56

In article <3801f648.290065@news.visi.com>,
  schneier@counterpane.com (Bruce Schneier) wrote:
> 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.

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. Cascading
ciphers was politically incorrect; even a top cryptographer I met in
the Second AES conference did not want me to quote him on this matter.
Now it is out in the open, and I think that the unstructured but fast
exchange of ideas in a newsgroup can help to dispel myths. (It
certainly helps when widely reputable people participate in the
discussion.)

The whole point in cascading ciphers, as opposed to adding rounds to a
single cipher, is to mix different kinds of structures and make the
whole beast less sensitive to an unforeseen attack. What this means is
that even after the AES a market will exist for unconventional ciphers.
Who knows, even my Frog algorithm may start hopping again. It is
simple, free, and is certainly very unconventional.

Another common issue in this tread has been about speed. Undoubtedly
there are applications that require extremely high speeds. There are
also many applications where speed is almost irrelevant. Almost all
client applications (working on the end-user's PC) don't require speeds
of encryption over a few megabits per second. IP telephony, for
example, requires only about 10 kbits per second. Contrast this to over
100 Mbits per second that can easily be achieved by the fastest AES
candidates on today's PCs. Using the AES alone for PC based IP
telephony makes little sense.

By the way, public key primitives are considered to be more susceptible
to catastrophic failure than any single symmetric cipher. Here too it
must make sense to use several methods in parallel, particularly with
the high speeds achieved by modern PCs. Unconventional public key
designs anyone? :)


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: 16 Oct 99 15:19:12 GMT
From: jsavard@ecn.ab.ca ()
Message-ID: <38089770.0@ecn.ab.ca>
References: <7u92pv$251j@enews3.newsguy.com>
   <7u7fn4$l5o$1@nnrp1.deja.com>
Newsgroups: sci.crypt
Lines: 21

Roger Schlafly (real@ieee.org) wrote:
: <dianelos@tecapro.com> wrote in message news:7u7fn4$l5o$1@nnrp1.deja.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.

: Many still think it is a bad idea. If a cipher has shortcomings,
: it is better to fix the cipher than to pile other ciphers on top
: of it.

But the point - and it's a valid one - of the side other than yours on
this question is that 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.

I agree it is a lesser degree than the one we get from a long period of
study and analysis by the academic community, however. But I think it is a
valid point that we need all the reassurance we can get - because all we
can get still isn't enough.

John Savard


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Sun, 17 Oct 1999 17:08:26 GMT
From: ritter@io.com (Terry Ritter)
Message-ID: <380a0287.9839216@news.io.com>
References: <38089770.0@ecn.ab.ca>
Newsgroups: sci.crypt
Lines: 86


On 16 Oct 99 15:19:12 GMT, in <38089770.0@ecn.ab.ca>, in sci.crypt
jsavard@ecn.ab.ca () wrote:

>Roger Schlafly (real@ieee.org) wrote:
>: <dianelos@tecapro.com> wrote in message news:7u7fn4$l5o$1@nnrp1.deja.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.
>
>: Many still think it is a bad idea. If a cipher has shortcomings,
>: it is better to fix the cipher than to pile other ciphers on top
>: of it.
>
>But the point - and it's a valid one - of the side other than yours on
>this question is that sometimes we don't *know* all the shortcomings of a
>cipher. 

Why would you claim that "the other side" says this happens
"sometimes"?  

I claim that we *never* know "all the shortcomings of a cipher,"
absent some sort of mathematically provable security in practice.

>So, if we pile up several _very different_ ciphers, we do have an
>additional degree of reassurance.
>
>I agree it is a lesser degree than the one we get from a long period of
>study and analysis by the academic community, however. 

Really?  To what degree can you *measure* the "reassurance" provided
by "the academic community?"  And if you can't measure it, how do you
know it has increased?  What is your scientific support for such a
statement?  

In fact, consider the situation during analysis:  In the beginning,
every cipher starts out unbroken.  We would thus use it.  Later on,
that same cipher may be broken, so we would not use it.  But during
the period we did use that cipher, it was still breakable, we just did
not *know* that it was breakable, but maybe someone else did.  This is
the natural life of every cipher, unless we have some delusion that
any particular cipher will *never* be broken.  I say "delusion"
because there is no scientific support for such a statement.  

We cannot even measure the effort by "the scientific community" places
into the analysis of any one cipher.  What we see in "scientific"
papers are successful (or quasi-successful) breaks.  We do *not*
(generally) see "We worked on this intensely for 8 months, and never
found a weakness."  On its own, such a statement is probably not
publishable as new Science.  Yet it would be far better evidence than
simply saying nothing at all, which is the way "the scientific
community" works now.  Our only current alternative is to consider new
ciphers *strong* until a scientific examination shows a weakness, for
that is the game "the scientific community" plays, and they see no
reason to change the rules.  


>But I think it is a
>valid point that we need all the reassurance we can get - because all we
>can get still isn't enough.

In which case, how does any amount of reassurance help?  

I claim there can be no assurance: any cipher can fail at any time.  

*  We can improve our odds by eliminating known-plaintext attacks on
component ciphers, and by requiring opponents to find weaknesses which
can be exploited within a cipher-stack environment.  

*  If we assume that all ciphers are in fact broken in practice, there
is no point in cryptography.  But if we assume that only some fraction
are broken, we can reduce the amount of our plaintext which may be
revealed by using many different ciphers.  This also has the effect of
limiting the reward opponents might get from breaking any particular
cipher, which thus limits the resources they are willing to put into
any such attack.  If our opponents needed vast resources to break a
cipher on its own, and they have fewer resources when many different
ciphers are used, we have obviously improved our situation.  

*  If we assume that some ciphers are broken, we can terminate the
extent of any successful attack by changing our cipher frequently.  

---
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: 15 Oct 1999 14:25:28 -0400
From: juola@mathcs.duq.edu (Patrick Juola)
Message-ID: <7u7rio$ds4$1@quine.mathcs.duq.edu>
References: <380760A1.BB7D356F@aspi.net>
   <7u7h2m$dcs$1@quine.mathcs.duq.edu>
Newsgroups: sci.crypt
Lines: 47

In article <380760A1.BB7D356F@aspi.net>,
Trevor Jackson, III <fullmoon@aspi.net> wrote:
>Patrick Juola wrote:
>
>> In article <380738DA.1FA12305@aspi.net>,
>> Trevor Jackson, III <fullmoon@aspi.net> wrote:
>> >Patrick Juola wrote:
>> >> In article <3806845E.16D4C14F@aspi.net>,
>> >> Trevor Jackson, III <fullmoon@aspi.net> wrote:
>> >> >
>> >> >Any users desiring to communicate will be able to select a mechanism to do
>> >> >so.  Any analysis dismissing the active participation of the users in the
>> >> >dynamic selection of their channel properties from amoug the telephone, fax,
>> >> >and email is trivially flawed.
>> >>
>> >> Nonsense.  The Three-Initial-Corp. decides to use XYZ encryption for
>> >> all it's communication needs and invests several billion dollars in XYZ-
>> >> compliant mailers, routers, telephones, and so forth.  The Even-Larger-
>> >> Five-Initial-Corp., independently, decides to invest in PQ encryption
>> >> and spends similarly huge amounts on its scrambler phone.
>> >>
>> >> 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.  And what's going to happen
>> >> when ELFIC buys TIC?
>> >>
>> >
>> >Well, the one of the companies, either the one using fax or the one using email,
>> >is going to have to change.
>>
>> ... and the whole *point* of having standards is to minimize and
>> reduce the likelihood of this sort of retooling costs.
>
>By this reasoning we should only use telephones and avoid fax and email channels?
>After all it would reduce the tooling costs, right?

No, by this reasoning we should make sure that all telephones interoperate.

You'll notice that the word "fax" didn't appear at all in the description
I gave above.  Instead, both companies have purchased *secure phones*,
but the phones won't talk to each other.

What's the advantage gained by having two sets of mutually incomprehensible
secure phones?  Half of your people can't talk to the other half -- using
channels that to an outside observer are identical.

	-kitten


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Mon, 11 Oct 1999 22:11:57 -0600
From: jgfunj@vgrknf.arg (wtshaw)
Message-ID: <jgfunj-1110992211570001@dial-243-062.itexas.net>
References: <38023EE0.C0100192@crak.com>
   <3804ae80.2804726@news.visi.com>
Newsgroups: sci.crypt
Lines: 37

In article <38023EE0.C0100192@crak.com>, "John E. Kuslich"
<johnk@crak.com> wrote:
> ...It therefore stands to reason that any software
> running on an insecure computer is also insecure.

And, an insecure architecture is fixed with software alone is only a
decorative patch; many may admire it but a few disregard it.

> The medium is the message...

As said by McL..
> 
> The medium is insecure, therefore the message is insecure.
> 
> A cryptographic system is like a boat made of layers of steel plate
> covered by more layers of titanium plate covered by layers of more steel
> armor plate.  Just one little leak, just one little sea cock left open,
> just one little iceberg, just one sailor beat up with one rubber hose can
> scuttle the ship. The name Titanic comes to mind...

That is a miserable way to build computers as well.
....
> 
> Resistance is futile...

Only if you give in.
> 
>
> Bruce Schneier wrote:

> > As our society becomes more
> > reliant on a digital infrastructure, the process of security must be
> > designed in from the beginning.
> > 
Basic Security 101, or ought to be.
-- 
Figures lie, and liars figure.--Daria Dolan

	message sender's identity is unknown, unlogged, and not replyable.
	Again, it is IMPOSSIBLE to find out the original sender's identity!
	If you wish to be blocked from future mailings or want to report
	other problems with this service, please contact the operator at
	<flash-admin@nym.alias.net>.

Subject: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Thu, 14 Oct 1999 18:50:54 +0200
From: Anonymous <flash-bounce@nym.alias.net>
Message-ID: <199910141650.SAA00989@pingu.localnet>
References: <38023EE0.C0100192@crak.com>
   <3804ae80.2804726@news.visi.com>
Newsgroups: sci.crypt
Lines: 11

Could you please explain what you mean by multiple algorithms or
ciphers.  Are you refering to chaining or using different ciphers
on different blocks.  How would that work?  Would you use alternate
ciphers onm alternate blocks, or maybe a sequential set

I am assuming that all the ciphers must use the same blovk size...

Or would you randomely select a cipher from a set on each consecutive
block...

Thanks for your answer in anticpation..

It seems that from what Mr Schneier is saying...Smart Cards are not
very Smart at all...any comments on this...they seem to be more of
a security hole then a security help



Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Thu, 14 Oct 1999 21:12:37 +0200
From: Mok-Kong Shen <mok-kong.shen@t-online.de>
Message-ID: <38062B25.A83CBEF6@t-online.de>
References: <199910141650.SAA00989@pingu.localnet>
Newsgroups: sci.crypt
Lines: 30

Anonymous wrote:
> 
> Could you please explain what you mean by multiple algorithms or
 ciphers.  Are you refering to chaining or using different ciphers 
 on different blocks.  How would that work?  Would you use alternate 
 ciphers onm alternate blocks, or maybe a sequential set of ciphers 
 on alternate blocks...
> 
> I am assuming that all the ciphers must use the same blovk size...
> 
> Or would you randomely select a cipher from a set on each 
  consecutive block...

In my humble opinion it 'suffices' for the purpose of discussion of
the present thread to make the simplest assumptions about using
multiple algorithms, i.e. avoiding as many issues as possible that
could bring in unnecessary complications without essentially
contributing to the question of comparative merits of multiple 
algorithms against single algorithm as such. Thus 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.

As you have certainly noticed, each of the five items above
can be dropped/varied. Doing so would lead to results favouring
the use of multiple algorithms in my humble opinion.

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: 18 Oct 1999 20:42:37 GMT
From: djohn37050@aol.com (DJohn37050)
Message-ID: <19991018164237.21842.00000130@ng-fk1.aol.com>
References: <38062B25.A83CBEF6@t-online.de>
Newsgroups: sci.crypt
Lines: 8

At a recent ANSI X9F1 meeting, where particpents consisted of vendors, bankers,
auditors and government, there was overwhelming consensus that NIST should
incorporate future resiliency considerations into AES criteria.

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.
Don Johnson


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Mon, 18 Oct 1999 17:17:28 -0700
From: "Roger Schlafly" <real@ieee.org>
Message-ID: <7ugd7q$1d0n@enews4.newsguy.com>
References: <19991018164237.21842.00000130@ng-fk1.aol.com>
Newsgroups: sci.crypt
Lines: 25

DJohn37050 <djohn37050@aol.com> wrote in message
news:19991018164237.21842.00000130@ng-fk1.aol.com...
> At a recent ANSI X9F1 meeting, where particpents consisted of vendors,
bankers,
> auditors and government, there was overwhelming consensus that NIST should
> incorporate future resiliency considerations into AES criteria.

This is so vague as to be meaningless. Can one winner have the
requested resiliency?

> 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.

Remember that this is the same committee of idiots who think that
RSA implementations should only be allowed to use a certain
very restricted class of primes when generating RSA keys.

Bankers are not the best ones to be making communications
security decisions.





Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Tue, 19 Oct 1999 15:45:49 GMT
From: Bob Silverman <bobs@rsa.com>
Message-ID: <7ui3n9$fm0$1@nnrp1.deja.com>
References: <7ugd7q$1d0n@enews4.newsguy.com>
Newsgroups: sci.crypt
Lines: 61

In article <7ugd7q$1d0n@enews4.newsguy.com>,
  "Roger Schlafly" <real@ieee.org> wrote:
> DJohn37050 <djohn37050@aol.com> wrote in message
> news:19991018164237.21842.00000130@ng-fk1.aol.com...
>> At a recent ANSI X9F1 meeting, where particpents consisted of
vendors,
> bankers,
>> auditors and government, there was overwhelming consensus that NIST
should
>> incorporate future resiliency considerations into AES criteria.
>
> This is so vague as to be meaningless. Can one winner have the
> requested resiliency?


It is also a mis-statement of what happened.  The working group
voted to suggest that NIST should *consider* reading documents that
discuss "future resiliency",  and *not* "NIST should incorporate....."

We did  NOT  vote to recommend to NIST that AES  should incorporate
"future resiliency", but only to recommend to NIST that they should
think about it as part of their review process.

>
> 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

But they can do that anyway!


> and do this in the context of the standard.

Then it is no longer "a standard".
>
> Remember that this is the same committee of idiots who think that
> RSA implementations should only be allowed to use a certain
> very restricted class of primes when generating RSA keys.


I fought long and hard against that requirement. To no avail.

>
> Bankers are not the best ones to be making communications
> security decisions.

Agreed. But they are competent to decide upon interoperability
standards for their industry. They understand their needs better than
others.

Also,  there are some actual cryptographers on the committee
(me,  Rich Ankney,  Rob Zucherato, Mike Wiener, Simon Blake-Wilson,
Paul Timmel  etc.)
--
Bob Silverman
"You can lead a horse's ass to knowledge, but you can't make him think"


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: 19 Oct 1999 18:17:54 GMT
From: djohn37050@aol.com (DJohn37050)
Message-ID: <19991019141754.19497.00000025@ng-cm1.aol.com>
References: <7ui3n9$fm0$1@nnrp1.deja.com>
Newsgroups: sci.crypt
Lines: 7

To be perfectly clear, there were really 2 votes at X9F1 on Future Resiliency.
1) was to incorporate future resiliency into AES process.
2) was to consider the ideas in the paper in the AES process.

Both were the consensus of the group, the latter (being weaker) obtained more
votes than the former.
Don Johnson


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Tue, 19 Oct 1999 21:51:43 -0700
From: "Roger Schlafly" <real@ieee.org>
Message-ID: <7ujhm3$1tna@enews1.newsguy.com>
References: <19991019141754.19497.00000025@ng-cm1.aol.com>
Newsgroups: sci.crypt
Lines: 25

DJohn37050 <djohn37050@aol.com> wrote in message
news:19991019141754.19497.00000025@ng-cm1.aol.com...
> To be perfectly clear, there were really 2 votes at X9F1 on Future
Resiliency.
> 1) was to incorporate future resiliency into AES process.
> 2) was to consider the ideas in the paper in the AES process.
>
> Both were the consensus of the group, the latter (being weaker) obtained
more
> votes than the former.

Do you have the text of the motion? "Future resiliency" can mean
a lot of things. It might mean that the AES winner should be
efficient on a lot of platforms. It might mean that the AES winner
should be able to withstand a wide variety of attacks. It might
mean that the AES approval process should be more flexible
in address everyone's concern or in being willing to improve
algorithms by tweaking them.

It sounds to me that you got a meaningless resolution passed,
and now you are pretending that it was an endorsement of your
ideas.





Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Wed, 20 Oct 1999 17:11:37 -0700
From: "Roger Schlafly" <real@ieee.org>
Message-ID: <7ulll2$j23@enews1.newsguy.com>
References: <19991020092446.15076.00000024@ng-fr1.aol.com>
   <7ujhm3$1tna@enews1.newsguy.com>
Newsgroups: sci.crypt
Lines: 21

DJohn37050 <djohn37050@aol.com> wrote in message
news:19991020092446.15076.00000024@ng-fr1.aol.com...
> I said I presented the ideas in my "Future Resiliency" paper and the
summary is
> that there should be disparate winners.  There was discussion in the group
> regarding what to do, if anything, about these ideas.  We settled on a
vote, so
> I could send an official note to NIST regarding X9F1 sentiments.  I did
that.

Ok, fine, but the vote was not on whether there should be disparate
winners. If I were on the committee, I would vote AGAINST any
proposal that NIST name multiple winners. But I'd vote FOR
"future resiliency into AES process". Resiliency can be a good
thing.

Therefore, I do not think that the vote was a show of support
for your ideas.





Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Wed, 20 Oct 1999 21:25:08 -0400
From: "Rich Ankney" <rankney@erols.com>
Message-ID: <7ulq8m$cdj$1@autumn.news.rcn.net>
References: <7ulll2$j23@enews1.newsguy.com>
Newsgroups: sci.crypt
Lines: 30

I was at this meeting.  IIRC, the vote was to suggest to NIST that multiple
algorithms should be allowed for AES.  Don can correct me if I'm wrong...

/ Rich

Roger Schlafly wrote in message <7ulll2$j23@enews1.newsguy.com>...
>DJohn37050 <djohn37050@aol.com> wrote in message
>news:19991020092446.15076.00000024@ng-fr1.aol.com...
>> I said I presented the ideas in my "Future Resiliency" paper and the
>summary is
>> that there should be disparate winners.  There was discussion in the
group
>> regarding what to do, if anything, about these ideas.  We settled on a
>vote, so
>> I could send an official note to NIST regarding X9F1 sentiments.  I did
>that.
>
>Ok, fine, but the vote was not on whether there should be disparate
>winners. If I were on the committee, I would vote AGAINST any
>proposal that NIST name multiple winners. But I'd vote FOR
>"future resiliency into AES process". Resiliency can be a good
>thing.
>
>Therefore, I do not think that the vote was a show of support
>for your ideas.
>
>
>




Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: 21 Oct 1999 02:07:42 GMT
From: djohn37050@aol.com (DJohn37050)
Message-ID: <19991020220742.27613.00000207@ng-bd1.aol.com>
References: <7ulq8m$cdj$1@autumn.news.rcn.net>
Newsgroups: sci.crypt
Lines: 3

Yes, Roger refuses to be convinced, so I keep clarifying, and he keeps
refusing.  Same old Roger.
Don Johnson


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Wed, 20 Oct 1999 22:48:15 -0700
From: "Roger Schlafly" <real@ieee.org>
Message-ID: <7um9cc$13h2@enews1.newsguy.com>
References: <7ulq8m$cdj$1@autumn.news.rcn.net>
Newsgroups: sci.crypt
Lines: 15

Rich Ankney <rankney@erols.com> wrote in message
news:7ulq8m$cdj$1@autumn.news.rcn.net...
> I was at this meeting.  IIRC, the vote was to suggest to NIST that
multiple
> algorithms should be allowed for AES.  Don can correct me if I'm wrong...

I challenged Don to produce the text of the motion. He didn't provide
it, but he said the motion was for "future resiliency" not multiple
algorithms.

If Don thinks that the text of the motion supports his case, let him
post it.





Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Tue, 19 Oct 1999 14:41:01 -0400
From: "Trevor Jackson, III" <fullmoon@aspi.net>
Message-ID: <380CBB3D.E9A90838@aspi.net>
References: <7ui3n9$fm0$1@nnrp1.deja.com>
Newsgroups: sci.crypt
Lines: 45

Bob Silverman wrote:

> In article <7ugd7q$1d0n@enews4.newsguy.com>,
>   "Roger Schlafly" <real@ieee.org> wrote:
> > DJohn37050 <djohn37050@aol.com> wrote in message
> > news:19991018164237.21842.00000130@ng-fk1.aol.com...
> >> At a recent ANSI X9F1 meeting, where particpents consisted of
> vendors,
> > bankers,
> >> auditors and government, there was overwhelming consensus that NIST
> should
> >> incorporate future resiliency considerations into AES criteria.
> >
> > This is so vague as to be meaningless. Can one winner have the
> > requested resiliency?
>
> It is also a mis-statement of what happened.  The working group
> voted to suggest that NIST should *consider* reading documents that
> discuss "future resiliency",  and *not* "NIST should incorporate....."
>
> We did  NOT  vote to recommend to NIST that AES  should incorporate
> "future resiliency", but only to recommend to NIST that they should
> think about it as part of their review process.
>
> >
> > 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
>
> But they can do that anyway!

They can't sell products containing unapproved ciphers to the Government.

>
>
> > and do this in the context of the standard.
>
> Then it is no longer "a standard".

Well, NIST would not have "blessed" a single cipher and thus relieved all
implementors of design responsibility for cipher selection, but it would
still be "standard", meaning passing the threshold established by NIST for
cipher criteria.  There is no problem having multiple "standard ciphers".



Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Mon, 18 Oct 1999 23:23:15 -0400
From: "Trevor Jackson, III" <fullmoon@aspi.net>
Message-ID: <380BE423.F3D7F761@aspi.net>
References: <19991018164237.21842.00000130@ng-fk1.aol.com>
Newsgroups: sci.crypt
Lines: 42

DJohn37050 wrote:

> At a recent ANSI X9F1 meeting, where particpents consisted of vendors, bankers,
> auditors and government, there was overwhelming consensus that NIST should
> incorporate future resiliency considerations into AES criteria.
>
> 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.

I suspect the term resiliency has multiple meanings.  One of the meanings we should
inspect is that of future revisions to standard algorithms, and even "Very AES"
(VAES), which may be needed sometime in the future.

DES didn't evolve.  It did not get tweaked as a standard.  It did gain extra layers
such as DESX and 3DES.  Will AES evolve?  Will it need more "tweaks"?  An
infrastructure without resiliency is brittle.  It cracks and fails
catastrophically.  Let's not.

At some point in the future we'll be faced with an aging AES and the need to create
a successor standard.  Hopefully this will occur before AES is as useless as DES is
today.  If we learn from the current tardiness we will create VAES while AES is
still "strong".  Which means that when VAES is adopted there will be two standard
ciphers.

If we select a single AES "winner" the switch to VAES will be extremely painful.
Given the expectation that security will become pervasive in the interval between
now and then the switch to VAES will be much tougher than the switch from DES to
AES.  It might rival Y2K issues as a societal problem.  Given the taste for
litigation today do we want to allow the possibility of this kind of problem?

OTOH, if we select multiple AES winners, and provide for evolutionary changes in
the standard, similar to the round 2 "tweaks", the change to VAES will be
reasonably smooth.  Not easy, but comparatively simple.

Speaking ex-cathedra from my navel I assert that the chance of the AES "winner(s)"
being catastrophically weak is small.  Very small.  Close to zero.

But the chance that we'll need something like VAES is large.  Very large.  Close to
one.




Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: 19 Oct 1999 03:51:36 GMT
From: djohn37050@aol.com (DJohn37050)
Message-ID: <19991018235136.00544.00000300@ng-fj1.aol.com>
References: <380BE423.F3D7F761@aspi.net>
Newsgroups: sci.crypt
Lines: 8

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 and gave
scads of reasons for this.

Some disagree, ok.  It remains to be seen what NIST will decide to do in this
area.  There are arguments on both sides.  Simplicity is the main one for
having only one winner.
Don Johnson


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Mon, 18 Oct 1999 22:13:05 -0700
From: "Roger Schlafly" <real@ieee.org>
Message-ID: <7ugui1$26lb@enews2.newsguy.com>
References: <19991018235136.00544.00000300@ng-fj1.aol.com>
Newsgroups: sci.crypt
Lines: 15

DJohn37050 <djohn37050@aol.com> wrote in message
news:19991018235136.00544.00000300@ng-fj1.aol.com...
> 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 and
gave
> scads of reasons for this.

So you presented a paper to some bankers, got some polite
applause, and conclude that they all favor your radical idea
of abandoning AES in favor of an official govt statement of
indecision about ciphers? I think you are flattering yourself.





Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Tue, 19 Oct 1999 08:47:38 +0100
From: "Brian Gladman" <gladman@seven77.demon.co.uk>
Message-ID: <940319265.4483.0.nnrp-07.c2de6a96@news.demon.co.uk>
References: <7ugui1$26lb@enews2.newsguy.com>
Newsgroups: sci.crypt
Lines: 25


Roger Schlafly <real@ieee.org> wrote in message
news:7ugui1$26lb@enews2.newsguy.com...
> DJohn37050 <djohn37050@aol.com> wrote in message
> news:19991018235136.00544.00000300@ng-fj1.aol.com...
> > 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
and
> gave
> > scads of reasons for this.
>
> So you presented a paper to some bankers, got some polite
> applause, and conclude that they all favor your radical idea
> of abandoning AES in favor of an official govt statement of
> indecision about ciphers? I think you are flattering yourself.

No - discounting your distorted view of AES, which is different to that held
by the program managers at NIST.  If you don't believe me check with NIST.

          Brian Gladman





Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: 19 Oct 1999 14:33:35 GMT
From: djohn37050@aol.com (DJohn37050)
Message-ID: <19991019103335.21360.00000261@ng-bd1.aol.com>
References: <7ugui1$26lb@enews2.newsguy.com>
Newsgroups: sci.crypt
Lines: 5

It was not polite applause, it was a vote on what action, if any, to make as
X9F1 to NIST in regards to this issue.

And Roger, do you consider yourself a gadfly?
Don Johnson


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Tue, 19 Oct 1999 11:06:16 -0700
From: "Roger Schlafly" <real@ieee.org>
Message-ID: <7uibrr$12hq@enews1.newsguy.com>
References: <19991019103335.21360.00000261@ng-bd1.aol.com>
Newsgroups: sci.crypt
Lines: 17

DJohn37050 <djohn37050@aol.com> wrote in message
news:19991019103335.21360.00000261@ng-bd1.aol.com...
> It was not polite applause, it was a vote on what action, if any, to make
as
> X9F1 to NIST in regards to this issue.

So post the text of the motion, if you think it supports your position.
Bob S. disputes your description of it.

I am not saying everyone on the committee is an idiot. There are
some smart cryptographers. However, the committee has made
some cryptographically unsound decisions, and I do not think the
committee as a whole is a reliable source of opinion on the crypto
merits of whether AES should choose a standard.





Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Fri, 15 Oct 1999 16:09:57 GMT
From: Bob Silverman <bobs@rsa.com>
Message-ID: <7u7jk8$o4f$1@nnrp1.deja.com>
References: <7u6dgg$fnc@enews3.newsguy.com>
   <19991014150544.21471.00000152@ng-fg1.aol.com>
Newsgroups: sci.crypt
Lines: 32

In article <7u6dgg$fnc@enews3.newsguy.com>,
  "Roger Schlafly" <real@ieee.org> wrote:
> DJohn37050 <djohn37050@aol.com> wrote in message
> news:19991014150544.21471.00000152@ng-fg1.aol.com...

<snip>


> > For systems with one alg, they  switch over over time.
> >
> > I know that I MUCH prefer the possibilities of scenario B.
>
> Not me.
>

Option B has theoretical appeal,  but it would be economically
impossible to put into practice.   It wouldn't be that hard to
implement multiple choices in *software*  and assign an OID to
transactions so the software can choose  the correct algorithm.

But hardware vendors are not going to build AES based devices
with multiple algorithms.  There are too many problems with trying to
do so. Especially for embedded devices and low power systems.


--
Bob Silverman
"You can lead a horse's ass to knowledge, but you can't make him think"


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: 15 Oct 1999 18:16:08 GMT
From: djohn37050@aol.com (DJohn37050)
Message-ID: <19991015141608.05892.00000045@ng-co1.aol.com>
References: <7u7jk8$o4f$1@nnrp1.deja.com>
Newsgroups: sci.crypt
Lines: 3

Yes, there will be systems which need to choose just one algorithm, no question
about that.
Don Johnson


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Sun, 17 Oct 1999 15:52:00 GMT
From: ritter@io.com (Terry Ritter)
Message-ID: <3809f09b.5250892@news.io.com>
References: <7u7jk8$o4f$1@nnrp1.deja.com>
Newsgroups: sci.crypt
Lines: 37


On Fri, 15 Oct 1999 16:09:57 GMT, in <7u7jk8$o4f$1@nnrp1.deja.com>, in
sci.crypt Bob Silverman <bobs@rsa.com> wrote:

>In article <7u6dgg$fnc@enews3.newsguy.com>,
>  "Roger Schlafly" <real@ieee.org> wrote:
>> DJohn37050 <djohn37050@aol.com> wrote in message
>> news:19991014150544.21471.00000152@ng-fg1.aol.com...
>
><snip>
>
>
>> > For systems with one alg, they  switch over over time.
>> >
>> > I know that I MUCH prefer the possibilities of scenario B.
>>
>> Not me.
>>
>
>Option B has theoretical appeal,  but it would be economically
>impossible to put into practice.   It wouldn't be that hard to
>implement multiple choices in *software*  and assign an OID to
>transactions so the software can choose  the correct algorithm.
>
>But hardware vendors are not going to build AES based devices
>with multiple algorithms.  

Modern "hardware" systems often consist of embedded processors and
"firmware" based in flash.  The system itself can be designed to
choose from an array of acceptable ciphers, and also maintain a list
of a cipher *required* in a cipher stack, or *disallowed* due to new
information.  

---
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: Sun, 17 Oct 1999 19:22:04 -0700
From: "Roger Schlafly" <real@ieee.org>
Message-ID: <7ue098$202p@enews3.newsguy.com>
References: <3809f09b.5250892@news.io.com>
Newsgroups: sci.crypt
Lines: 14

Terry Ritter <ritter@io.com> wrote in message
news:3809f09b.5250892@news.io.com...
> Modern "hardware" systems often consist of embedded processors and
> "firmware" based in flash.  The system itself can be designed to
> choose from an array of acceptable ciphers, and also maintain a list
> of a cipher *required* in a cipher stack, or *disallowed* due to new
> information.

Yes, hardware systems could do that. But I am sure that they
would rather devote those resources to something more useful,
in most cases.





Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Mon, 18 Oct 1999 22:42:51 -0400
From: "Trevor Jackson, III" <fullmoon@aspi.net>
Message-ID: <380BDAAB.163461B9@aspi.net>
References: <380c77b7.20062887@news.visi.com>
   <380B0D8A.F4850676@aspi.net>
   <7ue098$202p@enews3.newsguy.com>
Newsgroups: sci.crypt
Lines: 84

Bruce Schneier wrote:

> On Mon, 18 Oct 1999 08:07:38 -0400, "Trevor Jackson, III"
> <fullmoon@aspi.net> wrote:
>
> >Roger Schlafly wrote:
> >
> >> Terry Ritter <ritter@io.com> wrote in message
> >> news:3809f09b.5250892@news.io.com...
> >> > Modern "hardware" systems often consist of embedded processors and
> >> > "firmware" based in flash.  The system itself can be designed to
> >> > choose from an array of acceptable ciphers, and also maintain a list
> >> > of a cipher *required* in a cipher stack, or *disallowed* due to new
> >> > information.
> >>
> >> Yes, hardware systems could do that. But I am sure that they
> >> would rather devote those resources to something more useful,
> >> in most cases.
> >
> >Something "more useful" than averting the possibility that the entire
> >device becomes useless?
>
> Yes.  There are a zillion things more useful than that.  In a
> cellphone, for example, voice quality is far more important than
> encryption.  The system will NEVER be designed to choose from an array
> of acceptable ciphers; we can't even get a system designed that has a
> single marginally acceptable cipher.  In a network hardware switching
> box, for example, it is more important to be able to make more
> connections than it is to have a choice of algorithms.  Cisco would
> hate having multiple "must have" algorithms in IPsec.  In an embedded
> stored-value card, every one of our clients would rather field the
> system with lousy encryption than add more complexity (and cost) to
> the chip.

I disagree.  I only have a couple of decades of experience designing real
systems for real users.  Usually without the design or computational platform
resources required to do the job, with typically inconsistent requirements,
and deadlines that require a zero length design phase and a negative length
testing phase.  Sound familiar?

To a designer options are a Good Thing (I know, I read your previous reply on
a parallel thread).  The thesis you've advocated is orthogonal to most of the
examples you've provided.  For instance, there are lots of dynamic issues
here.  Meaning that the criteria that dominate design and buying decisions
evolves over time.  Voice quality is the most important property _now_, but
that may change.  Nota Bene, NEVER is an extremely long time.  I don't have
the wisdom to determine things that will NEVER happen.

Neither do you.

In fact a reasonable evolution of cell phones implies that once digital
connections are common voice quality will be satisficed and other properties
will become the sales determinants because, for the purposes of the average
user, all system will have equivalent quality.

For networking issues such as IPsec, you've objected that having multiple
"must have" ciphers is a problem.  Maybe.  I disagree but it's a non-issue.
It's a non-issue because the true choice has nothing to do with multiple
"must haves" but multiple choices from which the designer may pick one, two,
or whatever suits the application.  Do we really want the same features in a
cipher encrypting quadrillions (I'm being conservative) of 48-byte ATM
packets as we want for securing gigabyte-size medical record files?  I doubt
it.

Basic point is not to have multiple ciphers in the router, but to have
multiple ciphers from which to choose when building the router.

Besides, if Cisco isn't willing to support multiple ciphers, I'll be happy to
invest in a second or third tier vendor who  is willing to support multiple
ciphers because they want to beat Cisco.  BTW, that investment would be in
the form of buying their products not their stock.  I vote with my budget.
Regularly.

As for smart cards, we all know that security is a hassle.  Good security is
more of a hassle than lousy security.  A single AES standard isn't going to
change that.  Nor will multiple standards make it worse.  The issues are
independent.

> It's a weird world out there, but it is the world we need to design
> to.

Emphatically yes.  And that means there is no possiblility of One True
Encryption standard.



Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Mon, 18 Oct 1999 21:08:46 -0700
From: "Roger Schlafly" <real@ieee.org>
Message-ID: <7ugqpe$23mc@enews2.newsguy.com>
References: <380BDAAB.163461B9@aspi.net>
Newsgroups: sci.crypt
Lines: 14

Trevor Jackson, III <fullmoon@aspi.net> wrote in message
news:380BDAAB.163461B9@aspi.net...
> Besides, if Cisco isn't willing to support multiple ciphers, I'll be happy
to
> invest in a second or third tier vendor who  is willing to support
multiple
> ciphers because they want to beat Cisco.

What planet do you live on? 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.





Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Sat, 23 Oct 1999 18:45:09 GMT
From: Tim Tyler <tt@cryogen.com>
Message-ID: <FK2K39.5wo@bath.ac.uk>
References: <380c77b7.20062887@news.visi.com>
   <380B0D8A.F4850676@aspi.net>
   <7ue098$202p@enews3.newsguy.com>
Newsgroups: sci.crypt
Lines: 30

Bruce Schneier <schneier@counterpane.com> wrote:
: <fullmoon@aspi.net> wrote:
:>Roger Schlafly wrote:

[Ritter-style cypher swapping]

:>> Yes, hardware systems could do that. But I am sure that they
:>> would rather devote those resources to something more useful,
:>> in most cases.
:>
:>Something "more useful" than averting the possibility that the entire
:>device becomes useless?

: Yes.  There are a zillion things more useful than that.  In a
: cellphone, for example, voice quality is far more important than
: encryption. [...]

That rather depends on who is owning the cellphone, and where they are
using it.

: The system will NEVER be designed to choose from an array of
: acceptable ciphers; we can't even get a system designed that
: has a single marginally acceptable cipher. [...]

"NEVER"?  That statement is /so/ strong it is almost certain to be wrong.
-- 
__________
 |im |yler  The Mandala Centre  http://www.mandala.co.uk/  tt@cryogen.com

Smoking cures weight problems eventually.


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Sun, 24 Oct 1999 07:59:43 -0400
From: "A [Temporary] Dog" <amungedtempdog@munged.see.sig>
Message-ID: <qPESOMqnljuoRK3A06DXyrE8amFe@4ax.com>
References: <FK2K39.5wo@bath.ac.uk>
Newsgroups: sci.crypt
Lines: 45

On Sat, 23 Oct 1999 18:45:09 GMT, Tim Tyler <tt@cryogen.com> wrote:

>Bruce Schneier <schneier@counterpane.com> wrote:
>: <fullmoon@aspi.net> wrote:
>:>Roger Schlafly wrote:
>
>[Ritter-style cypher swapping]
>
>:>> Yes, hardware systems could do that. But I am sure that they
>:>> would rather devote those resources to something more useful,
>:>> in most cases.
>:>
>:>Something "more useful" than averting the possibility that the entire
>:>device becomes useless?
>
>: Yes.  There are a zillion things more useful than that.  In a
>: cellphone, for example, voice quality is far more important than
>: encryption. [...]
>
>That rather depends on who is owning the cellphone, and where they are
>using it.

Since most of us are stuck with what the mass market will support for
cellphones, what any one owner wants is irrelevant.  The cellphone
marketers have determined that voice quality is more important to a
commercially viable phone then good encryption.  Good encryption may
actually be a detriment if it gets you into a pissing match with
government authorities.

>
>: The system will NEVER be designed to choose from an array of
>: acceptable ciphers; we can't even get a system designed that
>: has a single marginally acceptable cipher. [...]
>
>"NEVER"?  That statement is /so/ strong it is almost certain to be wrong.

Not withstanding Mr. Ritter's comments on reinterpreting the words of
others, always read "never" as "for the foreseeable future".


- A (Temporary) Dog            |"Intelligent, reasonable
The Domain is *erols dot com*  |people understand that -
The Name is tempdog            |unfortunately, we're dealing 
                               |with elected officials"
Put together as name@domain    | - name withheld


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Sun, 24 Oct 1999 10:59:23 -0400
From: "Trevor Jackson, III" <fullmoon@aspi.net>
Message-ID: <38131ECB.5EC0976D@aspi.net>
References: <qPESOMqnljuoRK3A06DXyrE8amFe@4ax.com>
Newsgroups: sci.crypt
Lines: 20



A [Temporary] Dog wrote:

> >
> >"NEVER"?  That statement is /so/ strong it is almost certain to be wrong.
>
> Not withstanding Mr. Ritter's comments on reinterpreting the words of
> others, always read "never" as "for the foreseeable future".
>

I don't think so.  We aren't using clinton-speak.  We (most) are using
English.  In English never means not ever; and NEVER means
not-ever-and-I-really-mean-it!

If someone means "for the forseeable future" they might as well say "for the
forseeable future".  But I doubt the submitter meant FOR THE FORSEEABLE
FUTURE,  do you?




Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Sun, 24 Oct 1999 15:03:09 -0400
From: "A [Temporary] Dog" <amungedtempdog@munged.see.sig>
Message-ID: <2FUTOA+l9v4J2Uxo9lnjX3yUVaiy@4ax.com>
References: <38131ECB.5EC0976D@aspi.net>
Newsgroups: sci.crypt
Lines: 33

On Sun, 24 Oct 1999 10:59:23 -0400, "Trevor Jackson, III"
<fullmoon@aspi.net> pumped the following load of hot text into
sci.crypt:

>
>A [Temporary] Dog wrote:
>
>> >
>> >"NEVER"?  That statement is /so/ strong it is almost certain to be wrong.
>>
>> Not withstanding Mr. Ritter's comments on reinterpreting the words of
>> others, always read "never" as "for the foreseeable future".
>>
>
>I don't think so.  We aren't using clinton-speak.  We (most) are using
>English.  In English never means not ever; and NEVER means
>not-ever-and-I-really-mean-it!

In my experience, people frequently say "never" when they mean "not in
the foreseeable future".  BTW, we're doing dueling aphorisms here -
what's your contribution?

- A (Temporary) Dog
"Always read sober what you posted drunk.  It will teach you to keep
your mouth shut"
    -Earnest Hemingway


- A (Temporary) Dog            |"Intelligent, reasonable
The Domain is *erols dot com*  |people understand that -
The Name is tempdog            |unfortunately, we're dealing 
                               |with elected officials"
Put together as name@domain    | - name withheld


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Thu, 28 Oct 1999 23:37:18 GMT
From: Tim Tyler <tt@cryogen.com>
Message-ID: <FKC6y6.5LI@bath.ac.uk>
References: <2FUTOA+l9v4J2Uxo9lnjX3yUVaiy@4ax.com>
Newsgroups: sci.crypt
Lines: 28

A [Temporary] Dog <amungedtempdog@munged.see.sig> wrote:
: On Sun, 24 Oct 1999 10:59:23 -0400, "Trevor Jackson, III" [wrote:]
:>A [Temporary] Dog wrote (quoting me):

:>>>"NEVER"?  That statement is /so/ strong it is almost certain to be wrong.
:>>
:>> Not withstanding Mr. Ritter's comments on reinterpreting the words of
:>> others, always read "never" as "for the foreseeable future".
:>
:>I don't think so.  We aren't using clinton-speak.  We (most) are using
:>English.  In English never means not ever; and NEVER means
:>not-ever-and-I-really-mean-it!

: In my experience, people frequently say "never" when they mean "not in
: the foreseeable future". [...]

These people need to dictionaries for Christmas - it'll probably save them
from no end of misunderstandings.

People who write "NEVER" - in capital letters - when they /really/ should
be saying "maybe sometime, but probably not for a little while" or - as in
this case - "very likely someday, but I'm not exactly sure when", really
must expect to be queried.
-- 
__________
 |im |yler  The Mandala Centre  http://www.mandala.co.uk/  tt@cryogen.com

Escape-Meta-Alt-Ctrl-Shift.


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: 16 Oct 1999 14:24:53 GMT
From: djohn37050@aol.com (DJohn37050)
Message-ID: <19991016102453.13373.00000023@ng-fe1.aol.com>
References: <3807dc4f.0@ecn.ab.ca>
Newsgroups: sci.crypt
Lines: 6

John,
On patent rights for the winner(s), NIST has ALWAYS said there may be one or
more winners.  It is only some people who choose to restate what NIST actually
says to have them saying "NIST will choose a winner."  NIST has NEVER said
something as simple as that.
Don Johnson


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Mon, 18 Oct 1999 19:54:38 GMT
From: schneier@counterpane.com (Bruce Schneier)
Message-ID: <38107ae3.20874589@news.visi.com>
References: <19991016102453.13373.00000023@ng-fe1.aol.com>
Newsgroups: sci.crypt
Lines: 16

On 16 Oct 1999 14:24:53 GMT, djohn37050@aol.com (DJohn37050) wrote:

>John,
>On patent rights for the winner(s), NIST has ALWAYS said there may be one or
>more winners.  It is only some people who choose to restate what NIST actually
>says to have them saying "NIST will choose a winner."  NIST has NEVER said
>something as simple as that.

Correct.  I remember Miles saying something like "we will choose
approximately one winner."

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: 18 Oct 1999 20:26:35 GMT
From: djohn37050@aol.com (DJohn37050)
Message-ID: <19991018162635.21848.00000126@ng-fk1.aol.com>
References: <38107ae3.20874589@news.visi.com>
Newsgroups: sci.crypt
Lines: 4

I recall Miles being very clear on the fact that there might be multiple
winners.  This is the case in both the official NIST statements and in the
presentations/discussions at AES conferences.
Don Johnson


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Mon, 18 Oct 1999 22:57:06 -0400
From: "Trevor Jackson, III" <fullmoon@aspi.net>
Message-ID: <380BDE02.E1BEEA4D@aspi.net>
References: <380f7904.20395734@news.visi.com>
   <19991014150544.21471.00000152@ng-fg1.aol.com>
Newsgroups: sci.crypt
Lines: 84

Bruce Schneier wrote:

> On 14 Oct 1999 19:05:44 GMT, djohn37050@aol.com (DJohn37050) wrote:
>
> >Here is 2 slightly different scenarios;
> >A) NIST chooses ONE AES algorithm.  A few years from now, it is discovered to
> >be somewhat weaker than at first thought.  A few years after that, it is
> >discovered to be much weaker.  Now what?
>
> We deal with the problem when it arises.  This is what happened with
> DES.  It's not great.
>
> >B) NIST chooses a small number of AES algorithms.  For those systems without
> >much limitations, they do all the algs.  For those systems that are
> >constrained, they choose one.
>
> How do they choose one?  Do they pick randomly?  Do they pick the one
> that happens to meet their performance criteria on their particular
> platform?  Do you expect them to be able to choose based on
> cryptographic considerations?  (This is unlikely, since us
> cryptographers will have been unable to.)
>
> You know, I don't mind NIST choosing one algorithm for smart cards,
> one for hardware, one for software, etc.  (It makes less sense than
> choosing one, but it makes some sense.)  Then, we could have
> algorithms optimized for different platforms.  If NIST wanted to do
> that, they should have asked for this in the beginning.  NIST asked
> for a general-purpose cipher, and that's what they got.  They didn't
> ask for a hardware-optimized cipher, or a smart-card optimized cipher,
> or a 32-bit CPU optimized cipher.  The Twofish team would have had a
> much easier design job if we didn't try to optimize for all platforms.
>
> It's like requesting a general-purpose design for an automobile.  Some
> of the submissions would be faster than the other, or have more
> storage room.  But none of the submissions would be a race car, or a
> pickup truck, because the request was for a general-purpose
> automobile.

This appears to be an extremely important point.  Should we then blindly follow
this process or should we point out the foolishness it implies.  Some situations
require 18 wheels, some 24" clearance, and some a gross weight under 2000 lbs.  The
earlier we adjust the design flaws IN THE CONTEST the better the result of the
process will be.

Many of the positions taken in the last couple weeks are of the form that one
cipher is better than many.  Yet it is hard to credit the implications of this
concept because it essentially says that one cipher that is lousy at everything is
better than a number of ciphers that are optimized for various purposes.

Consider that if we had a single cipher with a few logical configuration knobs that
could be adjusted to optimize the algorithm for various environments those same
monocipher arguments would say we should elimiate all the knobs.
I suppose the protests would be even worse "The user might bump a knob by accident
and precipitate who knows what disaster!"

>
>
> >Now an algorithm is found to be weaker than
> >thought.
>
> Note that the liklihood of this increases geometically with each
> cipher that is chosen.  It is least likely to happen if only one
> cipher is chosen.
>
> >Everyone starts to migrate away from it to another of the AES algs.
> >The systems that use multiple algs, this is a matter of negoritiation of which
> >to use, etc.
>
> As long as the negotiation process is secure.  I believe that most
> applications will be as secure as the weakest cipher.
>
> >For systems with one alg, they  switch over over time.
> >
> >I know that I MUCH prefer the possibilities of scenario B.
>
> I do not.  I think they are much worse.  I think they are much worse
> cryptographically, and I think they are much worse for performance and
> interoperability.  I hope that the companies that have to implement
> what we give them make their wishes known to NIST.

Hmmm. By this logic crypto desparately needs a Bill Gates.  A pioneer to
revolutionize the market for crypto by selling Really Bad Crypto instead of
striving for Really Good Crypto that seems to be the interest in this forum.



Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Mon, 18 Oct 1999 23:01:31 -0400
From: "Trevor Jackson, III" <fullmoon@aspi.net>
Message-ID: <380BDF0B.DF1D2FD@aspi.net>
References: <7ugc24$1ca3@enews4.newsguy.com>
   <380B9AA0.165A58BD@t-online.de>
Newsgroups: sci.crypt
Lines: 31

Roger Schlafly wrote:

> Mok-Kong Shen <mok-kong.shen@t-online.de> wrote in message
> news:380B9AA0.165A58BD@t-online.de...
> > On the (presumably reasonable) assumption that the top three
> > candidates in the final round are of approximately the same strength,
> > I don't see any reason against a random choice from the beginning,
> > excepting that other factors like performance can motivate the chooser
> > to investigate the matter in more detail.
>
> You (and the other anti-standard advocates) are living in a dream
> world. Systems in the real world are subject to constraints. You
> can't just pile on random algorithms and choose randomly without
> having substantial costs for doing so.
>
> You probably also don't see any reason GM shouldn't put 2
> engines in each car.

Interesting observation.  In fact GM was one of the organizations that
dissed hybrid drive designs with similar logic.  They claimed that hybrid
designs "need two drive systems instead of one!"

Of course hybrid designs are far more flexible and will likely be viable
long term whereas single system alternates (batteries, hydrogen, alcohol,
etc. ) don't seem to be able to make it.

Makes you wonder about the possibilites of flexibility and agility available
when there are multiple cipher standards, and the constraints a single
cipher might place on some applications, making them unviable.




Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: 19 Oct 1999 03:37:50 GMT
From: djohn37050@aol.com (DJohn37050)
Message-ID: <19991018233750.00544.00000291@ng-fj1.aol.com>
References: <7ugc24$1ca3@enews4.newsguy.com>
Newsgroups: sci.crypt
Lines: 3

It is REQUIRED to put 2 independent BRAKE systems in EVERY CAR.  This is for
safety.
Don Johnson


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Tue, 19 Oct 1999 08:01:16 GMT
From: bravo.john@usa.net (Johnny Bravo)
Message-ID: <380d2528.93234057@news.mpinet.net>
References: <19991018233750.00544.00000291@ng-fj1.aol.com>
Newsgroups: sci.crypt
Lines: 11

On 19 Oct 1999 03:37:50 GMT, djohn37050@aol.com (DJohn37050) wrote:

>It is REQUIRED to put 2 independent BRAKE systems in EVERY CAR.  This is for
>safety.
>Don Johnson

  LOL, not quite the case.  If your master cylinder goes, your entire brake
system fails.  There is no backup for it.

  Johnny Bravo



Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Tue, 19 Oct 1999 15:44:06 GMT
From: bravo.john@usa.net (Johnny Bravo)
Message-ID: <380c8f2b.120377493@news.mpinet.net>
References: <380C6E8A.EF74CCA9@aspi.net>
   <380d2528.93234057@news.mpinet.net>
Newsgroups: sci.crypt
Lines: 28

On Tue, 19 Oct 1999 09:13:46 -0400, "Trevor Jackson, III" <fullmoon@aspi.net>
wrote:

>Johnny Bravo wrote:
>
>> On 19 Oct 1999 03:37:50 GMT, djohn37050@aol.com (DJohn37050) wrote:
>>
>> >It is REQUIRED to put 2 independent BRAKE systems in EVERY CAR.  This is for
>> >safety.
>> >Don Johnson
>>
>>   LOL, not quite the case.  If your master cylinder goes, your entire brake
>> system fails.  There is no backup for it.
>
>Giggle quietly.
>
>Look for a lever or pedal called the "emergency brake".

  That is the PARKING brake.  How fast can you drive with the brake pedal in
your car fully depressed.  Now try it with the parking brake, you can easily
drive 60+ mph with the parking brake on. Though I don't recommend doing so, due
to damage to the brake pads or drums.  I would hardly call such an ineffective
system a backup.
  Using the same criteria, the neutral setting is a backup for the engine.
Since you can put the car in neutral and push it.

  Johnny Bravo



Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Tue, 19 Oct 1999 09:52:59 +0200
From: Mok-Kong Shen <mok-kong.shen@t-online.de>
Message-ID: <380C235B.EA3D3F5B@t-online.de>
References: <7ugc24$1ca3@enews4.newsguy.com>
   <380B9AA0.165A58BD@t-online.de>
Newsgroups: sci.crypt
Lines: 28

Roger Schlafly wrote:
> 
> Mok-Kong Shen <mok-kong.shen@t-online.de> wrote
> 
> > On the (presumably reasonable) assumption that the top three
> > candidates in the final round are of approximately the same strength,
> > I don't see any reason against a random choice from the beginning,
> > excepting that other factors like performance can motivate the chooser
> > to investigate the matter in more detail.
> 
> You (and the other anti-standard advocates) are living in a dream
> world. Systems in the real world are subject to constraints. You
> can't just pile on random algorithms and choose randomly without
> having substantial costs for doing so.
> 
> You probably also don't see any reason GM shouldn't put 2
> engines in each car.

On the other hand, you (and some of the one-standard advocates)
confound the issue. It is not whether one 'can' or 'cannot' use more
than one AES candidates (unless a crypto law forbids that). One just 
wants NIST, for whose opinion one has a fair amount of respect, to 
testify that besides the AES winner, which is considered the best, 
a couple of others are also o.k., so that the question of doubt of 
strength of these (in case people want to use them e.g. in multiple 
encryption for whatever reason) is greatly reduced in magnitude.

M. K. Shen


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: 19 Oct 99 13:02:54 GMT
From: jsavard@ecn.ab.ca ()
Message-ID: <380c6bfe.0@ecn.ab.ca>
References: <380C235B.EA3D3F5B@t-online.de>
Newsgroups: sci.crypt
Lines: 19

Mok-Kong Shen (mok-kong.shen@t-online.de) wrote:
: On the other hand, you (and some of the one-standard advocates)
: confound the issue. It is not whether one 'can' or 'cannot' use more
: than one AES candidates (unless a crypto law forbids that). One just 
: wants NIST, for whose opinion one has a fair amount of respect, to 
: testify that besides the AES winner, which is considered the best, 
: a couple of others are also o.k., so that the question of doubt of 
: strength of these (in case people want to use them e.g. in multiple 
: encryption for whatever reason) is greatly reduced in magnitude.

Actually, that's already been done. NIST announced that the NSA had no
objections, on grounds of cryptographic strength, to any of the five
finalists.

Of course, I suppose if you're David A. Scott, you could take that to mean
that all five are weak enough for the NSA to break, but I'm not inclined
to that interpretation.

John Savard


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Tue, 19 Oct 1999 21:58:29 +0200
From: Mok-Kong Shen <mok-kong.shen@t-online.de>
Message-ID: <380CCD65.10D58748@t-online.de>
References: <380e8a1d.4149945@news.visi.com>
   <380C235B.EA3D3F5B@t-online.de>
Newsgroups: sci.crypt
Lines: 51

Bruce Schneier wrote:
> 
> On Tue, 19 Oct 1999 09:52:59 +0200, Mok-Kong Shen wrote:
> >On the other hand, you (and some of the one-standard advocates)
> >confound the issue. It is not whether one 'can' or 'cannot' use more
> >than one AES candidates (unless a crypto law forbids that). One just
> >wants NIST, for whose opinion one has a fair amount of respect, to
> >testify that besides the AES winner, which is considered the best,
> >a couple of others are also o.k., so that the question of doubt of
> >strength of these (in case people want to use them e.g. in multiple
> >encryption for whatever reason) is greatly reduced in magnitude.
> 
> If this is all you want, I have no problem with it.  NIST can choose
> an AES winner, and say that the other two (or three, or four) are also
> okay.  I don't mind.  What I want to avoid is having multiple
> algorithms in the AES standard, which would require a system to
> implement multiple algorithms in order to implement the standard.  I
> also want to avoid forcing the user to make a choice: having the
> standard be A or B.  (As I have said, if we cannot make a decision how
> to we expect non-cryptographers to.)  I am perfectly happy with
> secondary algorithms, or runners up, or anything like that.

Well, what I believe is a concern of most people that are vehemently
discussing with you may be roughly put thus: It is important to
have NIST formally declare that a couple of final round candidates
are very close to the winner in the selection criteria and that there 
is nothing against their use as far as cryptological strength is
concerned. Simply to have a NIST spokesman say some words in that
direction at a press conference is certainly not enough. There has
to be formal documentations by NIST of these close runners-ups.

Maybe others would object and would like to have something stronger, 
but in my personal view it seems to be sufficient for the envisaged 
purpose to have that stuff put as annex to the standard of the 
AES winner but it should be as detailed as the latter so that all 
implementations of them could be conforming. (I have personally also 
nothing against that being put in a seperate official document, be 
that called standard document or not, if appropriate reference is 
given to it in the standard of the AES winner.)

If that could be achieved, then I believe the market will choose 
which algorithm to use in particular fields of applications. It is 
well conceivable that for, say, cell phones one of the runner-ups is 
more cost effective than the AES winner and hence get widely used in 
that sector and some vendors will implement multiple algorithms
for arbitrary choice by the user either as single algorithm or in 
cascade.

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


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: 20 Oct 1999 13:18:38 GMT
From: djohn37050@aol.com (DJohn37050)
Message-ID: <19991020091838.15076.00000019@ng-fr1.aol.com>
References: <380CCD65.10D58748@t-online.de>
Newsgroups: sci.crypt
Lines: 3

What I want is for NIST to certify that a few AES algorithms are allowed for
federal gov't use.  This is their charge and is about all they can say anyway.
Don Johnson


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: 19 Oct 1999 14:31:34 GMT
From: djohn37050@aol.com (DJohn37050)
Message-ID: <19991019103134.21360.00000259@ng-bd1.aol.com>
References: <380c6b2f.0@ecn.ab.ca>
Newsgroups: sci.crypt
Lines: 9

In my AES paper, I used the term future resiliency to mean the ability  to not
depend on only one algorithm.  And the reason I wrote the paper is that the
sole winner idea has obvious potential advantages over multiple winners, namely
simplicity.

And if there was no other presentation, that means the vote was meaningless? 
These are people with the real money on the wire, they are in inherently
conservative.
Don Johnson


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Tue, 19 Oct 1999 15:09:45 GMT
From: schneier@counterpane.com (Bruce Schneier)
Message-ID: <380c880a.3619680@news.visi.com>
References: <19991018233622.00544.00000289@ng-fj1.aol.com>
   <3810ae1e.3043674@news.visi.com>
Newsgroups: sci.crypt
Lines: 33

On 19 Oct 1999 03:36:22 GMT, djohn37050@aol.com (DJohn37050) wrote:

>The very reason to use parallel links is so if one breaks the other might not.

Yes.  But in computer security systems, one rarely gets that property.
The system is as secure as the weakest link.  Hence, adding more
encryption algorithms necessarily makes the system weaker.

Think of the variety of systems proposed in this thread.  Someone
suggested that a protocol negotiate randomly between multiple
algorithms.  Use this to protect transactions, or passwords, or most
anything.  A system like that is as secure as the weakest algorithm.
(You can think of it as an extra few key bits choosing an algorithm,
and the system has having a large percentage of weak keys.)

Someone else suggested that the designers could install one algorithm
and a primary, and then have a fail over to a secondary.  Now the
system is vulnerable to attacks on the fail over mechanism, version
rollback attacks, etc.  (And why isn't triple-DES okay as a secondary
algorithm?)

There have been other suggestions of ways to use multiple algorithms.
I haven't seen one that works, except when the proposers postulate
that performance isn't an issue (which doesn't happen on systems that
I work on).

I haven't been convinced yet.

Bruce
**********************************************************************
Bruce Schneier, Counterpane Internet Security, Inc.  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, 19 Oct 1999 19:59:54 GMT
From: jsavard@tenMAPSONeerf.edmonton.ab.ca (John Savard)
Message-ID: <380cc370.10587222@news.prosurfr.com>
References: <380cb79d.5790473@news.visi.com>
   <19991019142122.19497.00000029@ng-cm1.aol.com>
   <380c880a.3619680@news.visi.com>
Newsgroups: sci.crypt
Lines: 94

schneier@counterpane.com (Bruce Schneier) wrote, in part:

>I'm sorry.  That sounds more like serial than parallel.  In any case,
>multiple encryption is fine; I have nothing against it.

>Use multiple encryption wherever you want: AES + whatever other
>algorithms you choose.  But please let AES be one algorithm.

For one thing, it should be noted that the multiple-cipher proposal
under discussion is intended for people seriously concerned with the
secrecy of their messages, even against attacks by powerful
adversaries, or attacks in the remote future. It may well be
cost-prohibitive for use in, say, preventing someone from taking
control of your toaster oven over the Internet, and for that we'll
just have to stumble along with an AES-only microchip.

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_.

Each time he does this, people come away from his posts with the
impression that he would be willing to use 100,000 ciphers designed by
fifth grade classes, or that he thinks the fact one can't
mathematically *prove* a cipher secure means that all ciphers are
equally bad. But those impressions _are_ false, as these two examples
are issues I raised, and when I raised these issues, he specifically
denied that he is making such obvious mistakes.

Thus, the negative superficial impression that some of his statements
about the importance of his proposal are, in my opinion, making, is to
an extent misleading. Looking at his proposal from a technical
viewpoint, I do see a sound basic idea present.


Serial and parallel encryption both have their roles in the proposal.
Parallel encryption by multiple ciphers, by itself, is unsafe because,
as correctly pointed out, the strength is roughly on the order of the
weakest cipher. (Roughly: only some, not all, messages can be read,
and there is less text to work with. And using only one cipher, since
cipher strength can't be proven, might be thought of as leaving some
nonzero chance that that cipher is, if not the "weakest" (that seems
unlikely in the case of the AES, I agree) at least unacceptably weak
as the result of an unanticipated future discovery.)

Serial encryption is intended to make parallel encryption safe. I've
suggested, and emphasized, that the user ought to be able to specify
that one of the ciphers in the serial mix should always be from a
small set of well-analyzed ciphers.

OK, so every possible combination is now "secure" by conventional
standards. What does having routines for thousands of different
ciphers, less well-analyzed than the "majors", buy you? Why is it
worth the trouble?

The fact that the algorithms used are now unknown, although the pool
from which they are chosen may be known, certainly adds a few bits to
the key, but that in itself is not of value: the component ciphers
must all meet the criterion that their keys are too long for
brute-force attacks to be effective. (Thus, triple-DES, and not DES
itself, should be a component cipher.)

If brute-force attack is impossible, then an attacker must do "real
cryptanalysis". However, every message is in a different - unknown -
mix of component ciphers. (Which ciphers are used must be negotiated
under very strong encryption, and side attacks based on how long the
negotiation took, for example, need to be carefully guarded against.)
Hence, there is never enough sample text enciphered by the same group
of ciphers - never mind the same key - to carry out attacks such as
differential cryptanalysis.

Even if one is completely contemptuous of the bulk of the ciphers used
in such a system, requiring the use of one "respected" cipher makes it
possible to see that even if the bulk of the other ciphers are
considered as doing no more than whitening, that is still making
things very difficult for the cryptanalyst, because the whitening is
quite variable in its algorithmic aspect.

In this kind of environment, even if someday easier attacks against
all five AES finalists were discovered than those now known against
MAGENTA or LUCIFER, someone digging up your old E-mails would likely
be utterly unable to read them. The data needed for an attack would be
hidden under two other ciphers, and their identity, their position,
and their keys would be unknown. (And stream ciphers, such as Panama
or RC4, are possible elements in the mix.)

Of course, it is still highly controversial whether that high a level
of security is worth that much difficulty for very many users, or
whether there are not easier and better ways to reach this point. But
this still illustrates a valid way to attempt to obtain more secrecy
than a single cipher would provide.

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: Tue, 19 Oct 1999 19:30:18 -0600
From: jgfunj@vgrknf.arg (wtshaw)
Message-ID: <jgfunj-1910991930190001@dial-243-031.itexas.net>
References: <380cc370.10587222@news.prosurfr.com>
Newsgroups: sci.crypt
Lines: 29

In article <380cc370.10587222@news.prosurfr.com>,
jsavard@tenMAPSONeerf.edmonton.ab.ca (John Savard) wrote:

> Serial and parallel encryption both have their roles in the proposal.
> Parallel encryption by multiple ciphers, by itself, is unsafe because,
> as correctly pointed out, the strength is roughly on the order of the
> weakest cipher. (Roughly: only some, not all, messages can be read,
> and there is less text to work with. And using only one cipher, since
> cipher strength can't be proven, might be thought of as leaving some
> nonzero chance that that cipher is, if not the "weakest" (that seems
> unlikely in the case of the AES, I agree) at least unacceptably weak
> as the result of an unanticipated future discovery.)
> 
> Serial encryption is intended to make parallel encryption safe. I've
> suggested, and emphasized, that the user ought to be able to specify
> that one of the ciphers in the serial mix should always be from a
> small set of well-analyzed ciphers.
> 
Perhaps you are making this too difficult, whereas, if you believe that a
couple of the ciphers are both good, simply encrypt in both and XOR the
bits of output.  This should work if the block lengths and key lengths are
the same.

If either cipher or both are as good as you think, you have to break both
to solve the message.  If the key is the same to both, things are simpler
than if they are different, both to the user and to the attacker.
-- 
Truth lies in your path for you to stumble over, 
even if you think you can easily sidestep it.


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: 20 Oct 99 06:07:43 GMT
From: jsavard@ecn.ab.ca ()
Message-ID: <380d5c2f.0@ecn.ab.ca>
References: <jgfunj-1910991930190001@dial-243-031.itexas.net>
Newsgroups: sci.crypt
Lines: 15

wtshaw (jgfunj@vgrknf.arg) wrote:
: Perhaps you are making this too difficult, whereas, if you believe that a
: couple of the ciphers are both good, simply encrypt in both and XOR the
: bits of output.  This should work if the block lengths and key lengths are
: the same.

That would be a one-way hash function. Of course, there are ways to do
this that will work (cipher block N = encryption 1 of plaintext block N
XOR encryption 2 of plaintext block N-1), and that is of interest.

But I am not "making" anything; what I've described - albeit with emphasis
on the precautions I think are important - is Terry Ritter's proposal, not
mine.

John Savard


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Wed, 20 Oct 1999 13:32:04 -0600
From: jgfunj@vgrknf.arg (wtshaw)
Message-ID: <jgfunj-2010991332050001@dial-243-005.itexas.net>
References: <380d5c2f.0@ecn.ab.ca>
Newsgroups: sci.crypt
Lines: 24

In article <380d5c2f.0@ecn.ab.ca>, jsavard@ecn.ab.ca () wrote:

> wtshaw (jgfunj@vgrknf.arg) wrote:
> : Perhaps you are making this too difficult, whereas, if you believe that a
> : couple of the ciphers are both good, simply encrypt in both and XOR the
> : bits of output.  This should work if the block lengths and key lengths are
> : the same.
> 
> That would be a one-way hash function. Of course, there are ways to do
> this that will work (cipher block N = encryption 1 of plaintext block N
> XOR encryption 2 of plaintext block N-1), and that is of interest.

That is the way of course, to keep things decipherable.  You could use the
method I suggested to prove authorship, since only you know the one or,
best yet, two keys.
> 
> But I am not "making" anything; what I've described - albeit with emphasis
> on the precautions I think are important - is Terry Ritter's proposal, not
> mine.
> 
> John Savard
-- 
Truth lies in your path for you to stumble over, 
even if you think you can easily sidestep it.


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Wed, 20 Oct 1999 08:56:53 +0100
From: "Brian Gladman" <gladman@seven77.demon.co.uk>
Message-ID: <940406238.7557.0.nnrp-07.c2de6a96@news.demon.co.uk>
References: <380c880a.3619680@news.visi.com>
Newsgroups: sci.crypt
Lines: 92

Bruce Schneier <schneier@counterpane.com> wrote in message
news:380c880a.3619680@news.visi.com...
> On 19 Oct 1999 03:36:22 GMT, djohn37050@aol.com (DJohn37050) wrote:
>
> >The very reason to use parallel links is so if one breaks the other might
not.
>
> Yes.  But in computer security systems, one rarely gets that property.
> The system is as secure as the weakest link.  Hence, adding more
> encryption algorithms necessarily makes the system weaker.

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.

This is a reasonable 'defence in depth' tactic where there is a long term
security requirement (decades) or where it is known that a system will be
specifically targetted by a very patient and well resourced enemy who is
prepared to spend years studying the algorthm(s) involved for any possible
weakness.

Historically these sorts of requirements have typically been in the defence,
intelligence or espionage fileds but as we push towards the widespread use
of encryption I can foresee a number of civil applications of encryption
that will involve these sorts of needs.

In addition to sequential encryption there are other forms of composition
(of two algorithms) that require an enemy to break both algorithms rather
than either of them in order to penetrate a system.  For example a key can
be generated by xoring two component keys and the latter can be sent to a
user encrypted with different algorithms.  In some sorts of system
particular keys are more ciritical than others and it can therefore make
sense to be ultra cautious about their security.  Such techniques are often
important in highly critical applications such as cryptographic key

> Think of the variety of systems proposed in this thread.  Someone
> suggested that a protocol negotiate randomly between multiple
> algorithms.  Use this to protect transactions, or passwords, or most
> anything.  A system like that is as secure as the weakest algorithm.
> (You can think of it as an extra few key bits choosing an algorithm,
> and the system has having a large percentage of weak keys.)

Yes, I am inclined to agree that many of the ideas put forward here are
likely to end up reducing security rather than increasing it because of the
overall system complexity involved.  But some of the simpler methods of
composing ciphers are useful in meeting a range of critical security
requrements so I don't think these ideas are undermined simply because more
adventurous ideas have been discussed.

> Someone else suggested that the designers could install one algorithm
> and a primary, and then have a fail over to a secondary.  Now the
> system is vulnerable to attacks on the fail over mechanism, version
> rollback attacks, etc.  (And why isn't triple-DES okay as a secondary
> algorithm?)

> There have been other suggestions of ways to use multiple algorithms.
> I haven't seen one that works, except when the proposers postulate
> that performance isn't an issue (which doesn't happen on systems that
> I work on).

Usually what matters is overall system performance and here there are many
systems where the performance of the block cipher employed will not have a
major impact on the overall system performance.  I agree that block
encryption speed will often be important in securing the lower protocol
layers but there are uses of encryption at the applications layer that have
the opposite properties.  Here the speed of the block encryption will often
have very little impact on overall system performance but the protection
requirement may either be long term or alternatively so critical to the
security of the system as a whole that an extra degree of safety is
worthwhile.

I do not think it is unreasonable to seek an AES outcome that accommodates
both these requirement domains.

One of the difficulties with AES is that the IPR issues may dictate that AES
algorithms have to be declared 'winners' in order that they can be used
freely whereas all we really need is more than one algorithm to come through
with some sort of formal status.  I don't have a problem with one winner and
1 or 2 backup algorithms or algorithm ranking but I am unclear whether the
rules of the AES competition will allow these forms of result in respect of
MARS and RC6 without declaring them 'winners'.

But I would have thought that such constraints might be removed if
necessary. In the limit, if RC6 and MARS are not available as 2nd and 3rd
place AES algorithms, we then have Rijndael, Serpent and Twofish since these
are not IPR constrained.  Not necessarily a bad outcome.

         Brian Gladman





Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Wed, 20 Oct 1999 11:32:34 +0200
From: Mok-Kong Shen <mok-kong.shen@t-online.de>
Message-ID: <380D8C32.F96649DF@t-online.de>
References: <940406238.7557.0.nnrp-07.c2de6a96@news.demon.co.uk>
Newsgroups: sci.crypt
Lines: 50

Brian Gladman wrote:
> 
> Usually what matters is overall system performance and here there are many
> systems where the performance of the block cipher employed will not have a
> major impact on the overall system performance.  I agree that block
> encryption speed will often be important in securing the lower protocol
> layers but there are uses of encryption at the applications layer that have
> the opposite properties.  Here the speed of the block encryption will often
> have very little impact on overall system performance but the protection
> requirement may either be long term or alternatively so critical to the
> security of the system as a whole that an extra degree of safety is
> worthwhile.
> 
> I do not think it is unreasonable to seek an AES outcome that accommodates
> both these requirement domains.

Very well said. Nothing in the world, not even AES, can fit all.

> 
> One of the difficulties with AES is that the IPR issues may dictate that AES
> algorithms have to be declared 'winners' in order that they can be used
> freely whereas all we really need is more than one algorithm to come through
> with some sort of formal status.  I don't have a problem with one winner and
> 1 or 2 backup algorithms or algorithm ranking but I am unclear whether the
> rules of the AES competition will allow these forms of result in respect of
> MARS and RC6 without declaring them 'winners'.
> 
> But I would have thought that such constraints might be removed if
> necessary. In the limit, if RC6 and MARS are not available as 2nd and 3rd
> place AES algorithms, we then have Rijndael, Serpent and Twofish since these
> are not IPR constrained.  Not necessarily a bad outcome.

Has anybody made serious thought of the possibility of extracting 
some of the good ideas from each submitted AES candidate and doing
some variations (to avoid patent problems) and putting in some
proper ideas of one's own to arrive at a new design? I mean one
certainly can learn from each something useful. In the field of
programming languages, the design of (the now time-honoured) PL/I 
is something analogous to this. I know well that PL/I has been 
heavily criticized at that time by some 'theoreticians' of computer 
science as being a monstrous conglomerate that is difficult to learn,
etc. etc. But PL/I did later have a sizable user community and is 
still in use today, if I don't err. (Even in retrospect now after 
decades I personally still can't agree with more than 10% of the 
arguments offered by the 'theoreticians'.) So I think the idea 
indicated might be practicable for some clever minds.

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: Wed, 20 Oct 1999 15:18:14 +0100
From: "Brian Gladman" <gladman@seven77.demon.co.uk>
Message-ID: <940429167.19519.0.nnrp-12.c2de6a96@news.demon.co.uk>
References: <380D8C32.F96649DF@t-online.de>
Newsgroups: sci.crypt
Lines: 49


Mok-Kong Shen <mok-kong.shen@t-online.de> wrote in message
news:380D8C32.F96649DF@t-online.de...
> Brian Gladman wrote:
> >
> > I do not think it is unreasonable to seek an AES outcome that
accommodates
> > both these requirement domains.
>
> Very well said. Nothing in the world, not even AES, can fit all.

Thank you for your kind words.

> > But I would have thought that such constraints might be removed if
> > necessary. In the limit, if RC6 and MARS are not available as 2nd and
3rd
> > place AES algorithms, we then have Rijndael, Serpent and Twofish since
these
> > are not IPR constrained.  Not necessarily a bad outcome.
>
> Has anybody made serious thought of the possibility of extracting
> some of the good ideas from each submitted AES candidate and doing
> some variations (to avoid patent problems) and putting in some
> proper ideas of one's own to arrive at a new design? I mean one

Although its quite possible that a better cipher might be constructed by
combining the techniques used in the AES algorithms in different ways, I am
rather uncertain that those who have the knowledge to do this would want to
repeat the process of algorithm development just undertaken for AES all over
again.

Moreover, as an outsider to the field of cipher design, I have the
impression that the problem here is not so much how to jumble things up but
rather that of knowing whether the result is secure.  I hence suspect that
more work on the cryptanalysis of the five AES finalists in their current
form may be more effective in improving algorithm security than the
synthesis of new algorithms right now.

But on a related point, while a block cipher can be turned into a stream
cipher in a number of ways, will a better stream cipher result if one is
designed from scratch as a stream cipher?  And, if the answer is yes, why is
there not an AES effort towards a standard stream cipher? Are they less
amenable to standardisation?

    Brian Gladman






Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: 20 Oct 1999 17:02:43 GMT
From: djohn37050@aol.com (DJohn37050)
Message-ID: <19991020130243.13073.00000098@ng-fa1.aol.com>
References: <940429167.19519.0.nnrp-12.c2de6a96@news.demon.co.uk>
Newsgroups: sci.crypt
Lines: 14

I think the reason to standardize on a block cipher are:
1) A mode can turn it into a stream cipher, if needed.
2) A stream cipher allows manipulation of individual bits.  This in turn can
have negative consequences.  I may not know how Joe votes, but I just want to
negate him, so I just flip the bit.  I know a money field goes to 10,000 but
the thousands number is often zero, etc.  And integrity methods can solve some
of these concerns.
3) A stream cipher requires synchronization to be treated as a security issue,
a two-time pad should be considered insecure.  This is often ignored in
"perfect" security analyses (after all, OTP is "perfect"), but is a real world
issue.  If I can get you to resync in the wrong place in the text stream, you
can be hosed.

Don Johnson


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: 20 Oct 1999 12:49:09 -0600
From: vjs@calcite.rhyolite.com (Vernon Schryver)
Message-ID: <7ul2r5$rd1$1@calcite.rhyolite.com>
References: <19991020130243.13073.00000098@ng-fa1.aol.com>
Newsgroups: sci.crypt
Lines: 54

In article <19991020130243.13073.00000098@ng-fa1.aol.com>,
DJohn37050 <djohn37050@aol.com> wrote:
>I think the reason to standardize on a block cipher are:

> ...
>3) A stream cipher requires synchronization to be treated as a security issue,
>a two-time pad should be considered insecure.  This is often ignored in
>"perfect" security analyses (after all, OTP is "perfect"), but is a real world
>issue.  If I can get you to resync in the wrong place in the text stream, you
>can be hosed.

Yes, "in theory there is no difference between theory and practice, but
in practice there is."

Those who advocate run-time negotating ciphers should look at real world
protocols.  All protocols that involve the parties agreeing on one choice
out of two or more alternatives have major problems in the real world.
A wonderful (so to speak) case study is PPP.  PPP based on essentially
everything being negotiated, including encryption mechanisms.  In theory,
it should all work fine.  In theory, the two PPP peers will exchange
Configure-Request, -Nak, and -Ack LCP or NCP packets until they've agreed,
and then things will just work.  In practice, that's a sick joke.

For example, consider the simple, basic 10+ year old PPP authentication
mechanisms.  Originally (or nearly so) there were two schemes, CHAP and
PAP.  In theory, the peers would exchange LCP packets to negotiate which
peer(s) need(s) authentication of the other, and then the packets would
be exchanged.  In practice, at least 50% of PPP implementations get it
wrong even after private tests with other implementations.  At least 40%
never get it right.  If they have small marketshare, they simply don't
work in various situations with various peers until (and unless) they fix
their bugs.  If they have large marketshare (e.g. Microsoft and Ascend),
everyone else does whatever is necessary to accomodate their bugs.

Then consider Microsoft's "improvement" to CHAP, besides their early bugs
(e.g. -Nak vs. -Rej for PAP).  Microsoft came up with MS-CHAP as supposedly
more secure than standard PAP and CHAP.  In fact, it is in theory strictly
less secure and in practice about the same.  More recently Microsoft came
up with MS-CHAPv2, which is incompatible, slightly less insecure, but
still fundamentally defective.

These problems with PAP, CHAP, MS-CHAP, and MS-CHAPv2 are not ancient.
MS-CHAPv2 is fairly new.  Today, when your PPP code encounters a new PPP
implementation, you can expect to receive complaints about PAP and CHAP.

Finally, for the point that implementation details matter a lot and
probably more than the encryption theory, consider that IETF standard CHAP
and PAP were implemented by big vendors in ways that allow someone who
knows the tricks to immediately cause the authenticator into handing over
information needed to log in, including in one mode, a clear-text password.


Vernon Schryver    vjs@rhyolite.com


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Wed, 20 Oct 1999 23:51:18 GMT
From: ritter@io.com (Terry Ritter)
Message-ID: <380e5567.3599851@news.io.com>
References: <7ul2r5$rd1$1@calcite.rhyolite.com>
Newsgroups: sci.crypt
Lines: 42


On 20 Oct 1999 12:49:09 -0600, in <7ul2r5$rd1$1@calcite.rhyolite.com>,
in sci.crypt vjs@calcite.rhyolite.com (Vernon Schryver) wrote:

>In article <19991020130243.13073.00000098@ng-fa1.aol.com>,
>DJohn37050 <djohn37050@aol.com> wrote:
>>I think the reason to standardize on a block cipher are:
>
>> ...
>>3) A stream cipher requires synchronization to be treated as a security issue,
>>a two-time pad should be considered insecure.  This is often ignored in
>>"perfect" security analyses (after all, OTP is "perfect"), but is a real world
>>issue.  If I can get you to resync in the wrong place in the text stream, you
>>can be hosed.
>
>Yes, "in theory there is no difference between theory and practice, but
>in practice there is."
>
>Those who advocate run-time negotating ciphers should look at real world
>protocols.  All protocols that involve the parties agreeing on one choice
>out of two or more alternatives have major problems in the real world.
>A wonderful (so to speak) case study is PPP.  PPP based on essentially
>everything being negotiated, including encryption mechanisms.  In theory,
>it should all work fine.  In theory, the two PPP peers will exchange
>Configure-Request, -Nak, and -Ack LCP or NCP packets until they've agreed,
>and then things will just work.  In practice, that's a sick joke.

Those who criticize run-time negotiation of ciphers should look at
real-world modems.  Modern modems have many modes, speeds, and
parameters, and yet do manage to exchange them in real time to good
effect.  

The ideal for ciphers, however, would be to have lists of acceptable
ciphers and negotiate agreement in the background.  

What is needed *is* a single standard -- for the negotiation and
selection of arbitrary ciphers.  

---
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: 20 Oct 1999 19:10:51 -0600
From: vjs@calcite.rhyolite.com (Vernon Schryver)
Message-ID: <7ulp6r$585$1@calcite.rhyolite.com>
References: <380e5567.3599851@news.io.com>
Newsgroups: sci.crypt
Lines: 89

In article <380e5567.3599851@news.io.com>, Terry Ritter <ritter@io.com> wrote:
>
>On 20 Oct 1999 12:49:09 -0600, in <7ul2r5$rd1$1@calcite.rhyolite.com>,
>in sci.crypt vjs@calcite.rhyolite.com (Vernon Schryver) wrote:

> ...
>Those who criticize run-time negotiation of ciphers should look at
>real-world modems.  Modern modems have many modes, speeds, and
>parameters, and yet do manage to exchange them in real time to good
>effect.  

How can you point to modems as a good example of the wonders of negotiating
protocols?  I think the politics and sausage warning applies.

v.32, v.32bis, v.42, v.42bis, v.34, and v.90 modems have only a fairly
small set of parameters to negotiate, and a lot of what they do is less
"negotiating" than "let's send this stuff and see if it works;  if it
doesn't then try the next thing on the list."  And even that "negotiating"
is heavily supplemented by "have the user configure things so that litte
needs to be or can be negotiated."  Sending probing tones and packets
might work in negotiating ciphers, but not without obvious security
problems that would need careful thought to fix.

In support my PPP efforts, I made a hobby of collecting pairs of new
Telebit, v.32, v.32bis, v.34, etc. modems (new at the time).  That was to
maintain a bunch of scripts for configuring the modems, and to see how
they worked.  For decades before that, I always seemed to be involved with
modems of one sort or another.  Hearing someone imply that modem
negotiating is now or has ever been clean is ... well ... amazing.

sheesh--haven't you noticed that the trade rags and popular press are
still warning people to get "real" v.90 modems, today, how many years
after that battle was officially over?

Double sheesh!--recent versions of Windows no longer have 5000 brands and
types of modems to choose among, but that is a recent change.  I suspect
that is less a sign that modem negotiating is finally working well than
the radical reduction in the number of modem vendors to a small handful
that can talk to each other behind the scenes.


>The ideal for ciphers, however, would be to have lists of acceptable
>ciphers and negotiate agreement in the background.  

Let's see, the parallel words for PPP are
  "The idea of PPP, howwer, is to have lists of acceptable parameters
  including for authentication, and negotiate agreement."
I'm probably what passes for a PPP expert (among other, more sane and
useful things, thank god).  My expert assessement, which I'm confident
that the other sane, long term technical participants in the IETF PPP WG
would echo, is that the idea didn't work out quite as well as we all hoped
and expected.  I bet even the big software company pointy haired
participants would endorse that phrasing.

I don't understand the "background" bit about cipher negotiating, since
for all of modems, PPP, and ciphers, until the parties agree, the main
event cannot work, and that's not exactly "background"...well, not exactly
for PPP, which, for example has the CCP (comopression) which is supposed to
be negotiated in parallel with the main NCP's, which can start sending
data before CCP converges.  That is what the PPP implementations I've
worked on do, but plenty of others don't.  Again, theory vs. practice.


>What is needed *is* a single standard -- for the negotiation and
>selection of arbitrary ciphers.  

If the words
  "What is needed *is* a single standard -- for the negotiation and
  selection of arbitrary serial link parameters."
were not said 100 times around the IETF in about 1987 and 1988 about what
became PPP, then exact equivalents were said.  In fact, PPP fits the bill
quite well.  However, no one who is a real designer can fail to learn
about negotiating and selecting arbitrary ciphers or anything else from the
example of PPP.

Not that the lessons surprise anyone with real world technical design
experience with protocols that involve much negotiating.  The main lesson
is "if you possibly can, DON'T!"

Other good (i.e. bad) examples of the inevitable perils of negotiating
besides modems and PPP include TCP and HTTP.  Most don't know about
about MSS/PMTU or window size problems, but most people have seen
"broken" web pages that don't work on some versons of some browsers.


Vernon Schryver    vjs@rhyolite.com


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Sat, 23 Oct 1999 18:39:27 GMT
From: ritter@io.com (Terry Ritter)
Message-ID: <3812005b.8360995@news.io.com>
References: <7ulp6r$585$1@calcite.rhyolite.com>
Newsgroups: sci.crypt
Lines: 155


On 20 Oct 1999 19:10:51 -0600, in <7ulp6r$585$1@calcite.rhyolite.com>,
in sci.crypt vjs@calcite.rhyolite.com (Vernon Schryver) wrote:

>In article <380e5567.3599851@news.io.com>, Terry Ritter <ritter@io.com> wrote:
>>
>>On 20 Oct 1999 12:49:09 -0600, in <7ul2r5$rd1$1@calcite.rhyolite.com>,
>>in sci.crypt vjs@calcite.rhyolite.com (Vernon Schryver) wrote:
>
>> ...
>>Those who criticize run-time negotiation of ciphers should look at
>>real-world modems.  Modern modems have many modes, speeds, and
>>parameters, and yet do manage to exchange them in real time to good
>>effect.  
>
>How can you point to modems as a good example of the wonders of negotiating
>protocols?  I think the politics and sausage warning applies.

I think the real world applies:  We have such modems.  We use them.
They work.  End of story.


>v.32, v.32bis, v.42, v.42bis, v.34, and v.90 modems have only a fairly
>small set of parameters to negotiate, and a lot of what they do is less
>"negotiating" than "let's send this stuff and see if it works;  if it
>doesn't then try the next thing on the list."  And even that "negotiating"
>is heavily supplemented by "have the user configure things so that litte
>needs to be or can be negotiated."  Sending probing tones and packets
>might work in negotiating ciphers, but not without obvious security
>problems that would need careful thought to fix.
>
>In support my PPP efforts, I made a hobby of collecting pairs of new
>Telebit, v.32, v.32bis, v.34, etc. modems (new at the time).  That was to
>maintain a bunch of scripts for configuring the modems, and to see how
>they worked.  For decades before that, I always seemed to be involved with
>modems of one sort or another.  Hearing someone imply that modem
>negotiating is now or has ever been clean is ... well ... amazing.

I doubt I implied that modem negotiation is "clean."  But it *is*
"background," and it *is* negotiation (both sides participate in the
final result), and it *is* "real world" -- it generally works in
practice.

Cipher negotiation can be far cleaner -- provided a single selection
mechanism is standardized.  If not, then we may see the same sort of
ad hoc stuff we saw with modems.  


>[...]
>>The ideal for ciphers, however, would be to have lists of acceptable
>>ciphers and negotiate agreement in the background.  
>
>Let's see, the parallel words for PPP are
>  "The idea of PPP, howwer, is to have lists of acceptable parameters
>  including for authentication, and negotiate agreement."
>I'm probably what passes for a PPP expert (among other, more sane and
>useful things, thank god).  My expert assessement, which I'm confident
>that the other sane, long term technical participants in the IETF PPP WG
>would echo, is that the idea didn't work out quite as well as we all hoped
>and expected.  I bet even the big software company pointy haired
>participants would endorse that phrasing.

I would say, "let's not do it like PPP."


>I don't understand the "background" bit about cipher negotiating, since
>for all of modems, PPP, and ciphers, until the parties agree, the main
>event cannot work, and that's not exactly "background"

Indeed, you do not understand the term "background," presumably
because you have not done your homework.  I suggest actually reading
messages before disparaging their ideas.  You might also look into my
recent article in IEEE Computer:

   http://www.io.com/~ritter/ARTS/R8INTW1.PDF

or the previous discussion, which I have archived on my pages:

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

Here, "background" approximately means "not apparent to the user."
That is just what modem negotiation is about, although we may hear
modems, and need not hear or see cipher negotiation.  

To start any conversation in cipher, it is currently necessary to
acquire common keys.  Everyone understands this.  So everyone should
be well prepared to understand that we can *also* acquire a cipher
name, or even a cipher itself, in the same way, through the same
channel.  This is not a big conceptual leap.

Once we have a conversation in cipher, we can assign part of it to a
"control channel," where negotiation takes place (generally, although
not necessarily) hidden from the user.  That would be "background"
cipher negotiation.  

Because the need is to change ciphers frequently, the desired
negotiation process is not one-time at the start, but rather, a
frequent or continuous process in different messages or sessions.  


>...well, not exactly
>for PPP, which, for example has the CCP (comopression) which is supposed to
>be negotiated in parallel with the main NCP's, which can start sending
>data before CCP converges.  That is what the PPP implementations I've
>worked on do, but plenty of others don't.  Again, theory vs. practice.

I am a working engineer. 

Theory vs. practice.


>>What is needed *is* a single standard -- for the negotiation and
>>selection of arbitrary ciphers.  
>
>If the words
>  "What is needed *is* a single standard -- for the negotiation and
>  selection of arbitrary serial link parameters."
>were not said 100 times around the IETF in about 1987 and 1988 about what
>became PPP, then exact equivalents were said.  In fact, PPP fits the bill
>quite well.  However, no one who is a real designer can fail to learn
>about negotiating and selecting arbitrary ciphers or anything else from the
>example of PPP.

Well, since you are a "real designer," I'll just let you wander on in
your monomanical tirade, while I suggest that we *not* do things like
PPP.  


>Not that the lessons surprise anyone with real world technical design
>experience with protocols that involve much negotiating.  The main lesson
>is "if you possibly can, DON'T!"

There is no other possibility, unless you wish to depend upon the
strength of a cipher which explicitly HAS *no* known or guaranteed
strength.  Not having strength is not a trivial detail, this is the
essence of the reason for using a cipher.  

The ability to change ciphers offers each of us the power to choose
what cipher we want to use.  This means no government organization is
edicting our use, or forcing it through market pressure.  We get to
choose what to use, and what not to use, and to change our minds on a
daily basis.  That is not a trivial advantage.


>Other good (i.e. bad) examples of the inevitable perils of negotiating
>besides modems and PPP include TCP and HTTP.  Most don't know about
>about MSS/PMTU or window size problems, but most people have seen
>"broken" web pages that don't work on some versons of some browsers.

Gosh, I think we'll just have to have a complete specification.

---
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: Sat, 23 Oct 1999 12:52:11 -0700
From: "Roger Schlafly" <real@ieee.org>
Message-ID: <7ut3kq$2sln@enews3.newsguy.com>
References: <3812005b.8360995@news.io.com>
Newsgroups: sci.crypt
Lines: 17

Terry Ritter <ritter@io.com> wrote in message
news:3812005b.8360995@news.io.com...
> Cipher negotiation can be far cleaner -- provided a single selection
> mechanism is standardized.  If not, then we may see the same sort of
> ad hoc stuff we saw with modems.
> ...
> Gosh, I think we'll just have to have a complete specification.

I don't think NIST was planning on standardizing a cipher negotiation
protocol -- at least not at this stage of AES. I also don't think that
such a standard would placate critics like Don Johnson. He would
say that the protocol may have unknown weaknesses, and people
ought to be able to substitute their own ad-hoc protocols.






Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Sat, 23 Oct 1999 23:11:14 GMT
From: ritter@io.com (Terry Ritter)
Message-ID: <38124042.24656067@news.io.com>
References: <7ut3kq$2sln@enews3.newsguy.com>
Newsgroups: sci.crypt
Lines: 30


On Sat, 23 Oct 1999 12:52:11 -0700, in
<7ut3kq$2sln@enews3.newsguy.com>, in sci.crypt "Roger Schlafly"
<real@ieee.org> wrote:

>Terry Ritter <ritter@io.com> wrote in message
>news:3812005b.8360995@news.io.com...
>> Cipher negotiation can be far cleaner -- provided a single selection
>> mechanism is standardized.  If not, then we may see the same sort of
>> ad hoc stuff we saw with modems.
>> ...
>> Gosh, I think we'll just have to have a complete specification.
>
>I don't think NIST was planning on standardizing a cipher negotiation
>protocol -- at least not at this stage of AES. I also don't think that
>such a standard would placate critics like Don Johnson. He would
>say that the protocol may have unknown weaknesses, and people
>ought to be able to substitute their own ad-hoc protocols.

I see no reason why the negotiation protocol must be "cryptographic,"
other than in the sense that it will handle cryptographic objects
(ciphers).  Negotiation should occur under the skirts of the current
cipher(s), and so can be an ordinary give and take.  The process
certainly could be exposed to the party at either end.  The
negotiation protocol can afford to have some weaknesses.  

---
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: 26 Oct 1999 11:39:30 -0700
From: daw@blowfish.isaac.cs.berkeley.edu (David Wagner)
Message-ID: <7v4sh2$ps2$1@blowfish.isaac.cs.berkeley.edu>
References: <38124042.24656067@news.io.com>
Newsgroups: sci.crypt
Lines: 38

In article <38124042.24656067@news.io.com>, Terry Ritter <ritter@io.com> wrote:
> I see no reason why the negotiation protocol must be "cryptographic,"
> other than in the sense that it will handle cryptographic objects
> (ciphers).  [...] The
> negotiation protocol can afford to have some weaknesses.  

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.

The SSL 2.0 ciphersuite negotiation protocol is a good case in point.
The client (Alice) sent the list of ciphersuites supported in her
implementation; the server (Bob) picked the first one from that list
that is also supported in his implementation, and both ends started
using the cipher picked by Bob.  Thus, an example protocol run might
look something like this:
  Alice -> Bob:  RC4, DES, IDEA, Triple-DES, RC4-40-export, ...
  Bob -> Alice:  IDEA

The problem is that there are severe attacks on the SSL 2.0 protocol,
due to the non-cryptographic nature of the negotiation protocol.  For
instance, an active attacker (a "man-in-the-middle") can edit Alice's
list of supported ciphers, removing all but the weakest one supported
by both endpoints (e.g., RC4-40-export); then Bob will be forced to
pick that weak one, and both ends will use the weak cipher.  Even if
both endpoints support a stronger cipher, they won't know that they've
been silently forced down to "least-common-denominator security".

Specifically, in SSL 2.0, even if both the client and the server
support strong non-exportable cryptography, they can be undetectably
forced to use weak exportable (40-bit) crypto for their communications.

In general, it is quite a challenge to design a general, secure, and
practical protocol for cipher negotiation that resists these attacks.

This illustrates the risk of cipher negotation: you might end up with
the _weakest_ of the available ciphers, and thus you'd better be very
sure that every cipher you support is strong enough for all purposes.


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Tue, 26 Oct 1999 20:10:45 GMT
From: dscott@networkusa.net (SCOTT19U.ZIP_GUY)
Message-ID: <7v4ubn$q1g$1@news.gate.net>
References: <7v4sh2$ps2$1@blowfish.isaac.cs.berkeley.edu>
Newsgroups: sci.crypt
Lines: 55

In article <7v4sh2$ps2$1@blowfish.isaac.cs.berkeley.edu>, daw@blowfish.isaac.cs.berkeley.edu (David Wagner) wrote:
>In article <38124042.24656067@news.io.com>, Terry Ritter <ritter@io.com> wrote:
>> I see no reason why the negotiation protocol must be "cryptographic,"
>> other than in the sense that it will handle cryptographic objects
>> (ciphers).  [...] The
>> negotiation protocol can afford to have some weaknesses.  
>
>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.
>
>The SSL 2.0 ciphersuite negotiation protocol is a good case in point.
>The client (Alice) sent the list of ciphersuites supported in her
>implementation; the server (Bob) picked the first one from that list
>that is also supported in his implementation, and both ends started
>using the cipher picked by Bob.  Thus, an example protocol run might
>look something like this:
>  Alice -> Bob:  RC4, DES, IDEA, Triple-DES, RC4-40-export, ...
>  Bob -> Alice:  IDEA
>
>The problem is that there are severe attacks on the SSL 2.0 protocol,
>due to the non-cryptographic nature of the negotiation protocol.  For
>instance, an active attacker (a "man-in-the-middle") can edit Alice's
>list of supported ciphers, removing all but the weakest one supported
>by both endpoints (e.g., RC4-40-export); then Bob will be forced to
>pick that weak one, and both ends will use the weak cipher.  Even if
>both endpoints support a stronger cipher, they won't know that they've
>been silently forced down to "least-common-denominator security".
>
>Specifically, in SSL 2.0, even if both the client and the server
>support strong non-exportable cryptography, they can be undetectably
>forced to use weak exportable (40-bit) crypto for their communications.
>
>In general, it is quite a challenge to design a general, secure, and
>practical protocol for cipher negotiation that resists these attacks.
>
>This illustrates the risk of cipher negotation: you might end up with
>the _weakest_ of the available ciphers, and thus you'd better be very
>sure that every cipher you support is strong enough for all purposes.

   This is why organizations should not trust browsers to automatically
encrypt there data before it is sent out on the net. People if possible
should encrypt and decrypt there data in files off line of sending it over
the web so that no automatic handshaking could occur that would allow
for a weak encryption method.




David A. Scott
--
                    SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
                    http://www.jim.com/jamesd/Kong/scott19u.zip
                    http://members.xoom.com/ecil/index.htm
                    NOTE EMAIL address is for SPAMERS


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Tue, 26 Oct 1999 21:54:03 GMT
From: jsavard@tenMAPSONeerf.edmonton.ab.ca (John Savard)
Message-ID: <3816204b.4599691@news.prosurfr.com>
References: <7v4sh2$ps2$1@blowfish.isaac.cs.berkeley.edu>
Newsgroups: sci.crypt
Lines: 58

daw@blowfish.isaac.cs.berkeley.edu (David Wagner) wrote, in part:

>This illustrates the risk of cipher negotation: you might end up with
>the _weakest_ of the available ciphers, and thus you'd better be very
>sure that every cipher you support is strong enough for all purposes.

I have to agree with that statement, it is undeniably true. However,
while I can't defend Terry Ritter's multi-ciphering proposal from
every criticism that has been levelled at it (perhaps it is cumbersome
and impractical, perhaps the effort involved is not worth it for the
security improvement it can bring - because the improvement in
security is not that badly needed, not because the improvement would
only be a small one) I must note that this is a condition that *can*
be achieved with this kind of system.

- The minimum required complement of ciphers would include the AES and
Triple-DES, which are accepted as strong. No weak ciphers are among
those required to be included.

- The choice is not between multiple ciphers to be employed singly,
but between multiple ciphers to be employed in each of three layers of
encryption.

- I've suggested that such a system should incorporate the feature of
allowing the user to select a smaller core set of "quality" ciphers at
least one of which is to be incorporated in any set of three ciphers
used.

Provided that the negotiation of ciphers is protected by encryption,
even if the protocol is not elaborate, as long as the key for that
encryption had been authenticated by normal means, determining what
ciphers are used, or forcing a particular cipher to be used, should
not be possible.

If that is the case, then there is one way in which the system will be
stronger than the weakest cipher used. A cipher that can be easily
broken with a large amount of known plaintext enciphered under a
single key still often cannot be broken on the basis of a single
message. As communications here are in the form of individual
messages, each with their own complement of ciphers as well as their
own key, and any weak ciphers, if they are used, are never used alone,
the presence of some weak ciphers in the mix is no longer
automatically fatal. 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.

At worst - whitening. At best, an enormous increase in the difficulty
of analyzing the cipher stream. (Note that since our negotiation
occurs under a single cipher, not a variable one, quintuple encryption
under the five ciphers believed strongest would not be inappropriate.)

The idea _is_ a very promising one, even if it is not suitable for all
applications, and even though it does require that some caution be
taken when working out the basic design.

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: Fri, 29 Oct 1999 03:03:33 GMT
From: ritter@io.com (Terry Ritter)
Message-ID: <38190e55.4213242@news.io.com>
References: <3816204b.4599691@news.prosurfr.com>
Newsgroups: sci.crypt
Lines: 86


On Tue, 26 Oct 1999 21:54:03 GMT, in
<3816204b.4599691@news.prosurfr.com>, in sci.crypt
jsavard@tenMAPSONeerf.edmonton.ab.ca (John Savard) wrote:

>daw@blowfish.isaac.cs.berkeley.edu (David Wagner) wrote, in part:
>
>>This illustrates the risk of cipher negotation: you might end up with
>>the _weakest_ of the available ciphers, and thus you'd better be very
>>sure that every cipher you support is strong enough for all purposes.
>
>I have to agree with that statement, it is undeniably true. However,
>while I can't defend Terry Ritter's multi-ciphering proposal from
>every criticism that has been levelled at it 

Well, let's see:


>(perhaps it is cumbersome
>and impractical, 

I suppose TCP/IP might be called "cumbersome and impractical" -- until
one starts to feel the advantages.  Once a dynamically changing cipher
scheme is programmed, there should be little need for intrusion into
applications or users.  

The dynamically changing cipher scheme may be complicated for some
people to think about, but that is mainly an issue for implementors.  


>perhaps the effort involved is not worth it for the
>security improvement it can bring - because the improvement in
>security is not that badly needed, 

If you could tell us what level of security you get from your favorite
cipher, then we could decide whether dynamically changing ciphers
improved things for you or not.  

Alas, we cannot know how much security your cipher provides.  Neither
can you, neither can anyone else.  

So, given that you do *not* know the strength of your cipher, your
preferred option seems to be to guess that you made the right choice,
and stay with it, right or wrong.  Which, of course, is the classic
failure mode in cipher use. 


>
>[...] there is one way in which the system will be
>stronger than the weakest cipher used. A cipher that can be easily
>broken with a large amount of known plaintext enciphered under a
>single key still often cannot be broken on the basis of a single
>message. As communications here are in the form of individual
>messages, each with their own complement of ciphers as well as their
>own key, and any weak ciphers, if they are used, are never used alone,
>the presence of some weak ciphers in the mix is no longer
>automatically fatal. 

An advantage of dynamically changing ciphers which the "conventional
'wisdom'" of continuously using a single cipher simply cannot match.  


>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.

As there is no practical cipher which is known to be strong, this
hardly makes any sense at all.  


>At worst - whitening. At best, an enormous increase in the difficulty
>of analyzing the cipher stream. (Note that since our negotiation
>occurs under a single cipher, not a variable one, quintuple encryption
>under the five ciphers believed strongest would not be inappropriate.)
>
>The idea _is_ a very promising one, even if it is not suitable for all
>applications, and even though it does require that some caution be
>taken when working out the basic design.

Yes, of course.  

---
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: 29 Oct 1999 09:50:04 -0600
From: vjs@calcite.rhyolite.com (Vernon Schryver)
Message-ID: <7vcfnc$r91$1@calcite.rhyolite.com>
References: <38190e55.4213242@news.io.com>
Newsgroups: sci.crypt
Lines: 17

In article <38190e55.4213242@news.io.com>, Terry Ritter <ritter@io.com> wrote:

> ...
>I suppose TCP/IP might be called "cumbersome and impractical" -- until
>one starts to feel the advantages. ...

No, if you check history or were around at the time (I first met the
Internet at the console of TIP-25 (DOCB) in about 1971), you know that
TCP/IP's detractors did not complain that it was "cumbersome and
impractical" but "simplistic and impractical."  TCP/IP was neither the
*cumbersome* response to x.25 nor the *complicated* alternative to the
ISO OSI suite, although it can be seen as a response and alternative to
them.  Circuit switching enthusiasts in the 1970's said the same sort of
things as the telco people were saying until recently, that datagrams are
simplistic, impractical, and cannot be made to provide useful service.
The ISO OSI community felt that TCP/IP was far too trivial for a real
protocol, such as in the U.K. Colour Book Protocols version of the OSI
protocols, where they insisted on putting x.25 everywhere, including below
both connection oriented services (TP4) and connectionless (TP0 and TP1)
and above Ethernet.


Vernon Schryver    vjs@rhyolite.com


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Fri, 29 Oct 1999 02:45:13 GMT
From: ritter@io.com (Terry Ritter)
Message-ID: <38190a35.3156577@news.io.com>
References: <7v4sh2$ps2$1@blowfish.isaac.cs.berkeley.edu>
Newsgroups: sci.crypt
Lines: 44


On 26 Oct 1999 11:39:30 -0700, in
<7v4sh2$ps2$1@blowfish.isaac.cs.berkeley.edu>, in sci.crypt
daw@blowfish.isaac.cs.berkeley.edu (David Wagner) wrote:

>In article <38124042.24656067@news.io.com>, Terry Ritter <ritter@io.com> wrote:
>> I see no reason why the negotiation protocol must be "cryptographic,"
>> other than in the sense that it will handle cryptographic objects
>> (ciphers).  [...] The
>> negotiation protocol can afford to have some weaknesses.  
>
>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.

Fine.  And if you don't change your cipher you might *also* end up
using the weakest of the ciphers *AND* never changing it.

Basically you continue to berate the idea of changing ciphers
apparently because that does not produce provable security.  

But you conveniently overlook that the conventional alternative *also*
does not produce provable security *and* is willing to rely on the
same potentially faulty cipher for years on end.  


>[...]
>This illustrates the risk of cipher negotation: you might end up with
>the _weakest_ of the available ciphers, and thus you'd better be very
>sure that every cipher you support is strong enough for all purposes.

Nobody can follow your advice.  Nobody knows how strong their cipher
is.  Neither do you, so it is strange advice.

It is also sloppy, since it is unnecessary that *every* cipher be of
some minimum strength.  Indeed, it is only necessary that *one* such
cipher exist in a field of two, to beat the alternative of using one
cipher, if that happens to be the wrong one!  And we cannot know if
that is the case or not.

---
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: 28 Oct 1999 20:46:05 -0700
From: daw@blowfish.isaac.cs.berkeley.edu (David Wagner)
Message-ID: <7vb59t$3q9$1@blowfish.isaac.cs.berkeley.edu>
References: <38190a35.3156577@news.io.com>
Newsgroups: sci.crypt
Lines: 28

In article <38190a35.3156577@news.io.com>, Terry Ritter <ritter@io.com> wrote:
> >Terry Ritter <ritter@io.com> wrote:
> >> I see no reason why the negotiation protocol must be "cryptographic,"
> 
> daw@blowfish.isaac.cs.berkeley.edu (David Wagner) wrote:
> >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.
> 
> Fine.  And if you don't change your cipher you might *also* end up
> using the weakest of the ciphers *AND* never changing it.

The difference is who chooses your ciphers.  Would you rather have
your adversary choose for you which cipher you'll use, or would you
rather make the choice yourself?  The answer should be obvious.

If the adversary gets the opportunity to choose which cipher you'll
use, you can bet the adversary will pick the cipher which is most
convenient for him to break.

> Basically you continue to berate the idea of changing ciphers
> apparently because that does not produce provable security.  

Er, what?  I never said that.  This is a strawman.

This issue (the risks in non-cryptographic cipher negotiation
protocols) has nothing to do with provable security, so I have a
hard time understanding where this comment came from.


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Fri, 29 Oct 1999 10:57:33 GMT
From: ritter@io.com (Terry Ritter)
Message-ID: <38197b1e.2906065@news.io.com>
References: <7vb59t$3q9$1@blowfish.isaac.cs.berkeley.edu>
Newsgroups: sci.crypt
Lines: 91


On 28 Oct 1999 20:46:05 -0700, in
<7vb59t$3q9$1@blowfish.isaac.cs.berkeley.edu>, in sci.crypt
daw@blowfish.isaac.cs.berkeley.edu (David Wagner) wrote:

>In article <38190a35.3156577@news.io.com>, Terry Ritter <ritter@io.com> wrote:
>> >Terry Ritter <ritter@io.com> wrote:
>> >> I see no reason why the negotiation protocol must be "cryptographic,"
>> 
>> daw@blowfish.isaac.cs.berkeley.edu (David Wagner) wrote:
>> >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.
>> 
>> Fine.  And if you don't change your cipher you might *also* end up
>> using the weakest of the ciphers *AND* never changing it.
>
>The difference is who chooses your ciphers.  Would you rather have
>your adversary choose for you which cipher you'll use, or would you
>rather make the choice yourself?  The answer should be obvious.
>
>If the adversary gets the opportunity to choose which cipher you'll
>use, you can bet the adversary will pick the cipher which is most
>convenient for him to break.

Oddly, this doesn't sound like anything we have been talking about.  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.  This would be an ordinary
handshake selection, not a cryptographic protocol, but nevertheless
clearly neither exposed to nor under the control of the opponents.
How is that related to the adversary choosing the cipher?  


>> Basically you continue to berate the idea of changing ciphers
>> apparently because that does not produce provable security.  
>
>Er, what?  I never said that.  This is a strawman.

In view of your argument above, I find "strawman" an interesting term
for you to use.  


>This issue (the risks in non-cryptographic cipher negotiation
>protocols) has nothing to do with provable security, so I have a
>hard time understanding where this comment came from.

It seems like a reasonable extrapolation to me.  

My comment was an inference from your complaints about the multi-level
ciphering and dynamic cipher change proposal.  Your model has been
shown to be insufficient to address major, intuitive aspects of the
proposal, but you continue with the same old model.  Your model is
biased, but you promote it anyway.  How are we to understand this?

One way to understand it is that you are willing to *assume* strength
in the single cipher you would use forever, but unwilling to make that
same assumption for the many-cipher proposal, even though it would of
course use that same cipher (along with others).  I am willing to
accept that many of those ciphers will have had less analysis than
your pick (although this is really more of an indictment of academic
review practices than cipher design).  But I am not willing to accept
that you have learned the strength of your cipher from its academic
review, and in that it is I whose position agrees with the accepted
wisdom.  

The most-analyzed cipher may turn out, in the end, to be the weakest
cipher, even though that did not seem so in the beginning.  And, since
any single cipher will get the most additional analysis, this result
might even be more probable than otherwise.  If you cannot agree,
perhaps you will give a rational explanation as to why not.  

It is obvious to even the most jaded observer that the real "strength"
of a cipher depends upon what the opponents know.  It is *obvious*
that the more important traffic a cipher carries, and the longer a
cipher is used, the more public and private research will address that
cipher, and the more likely it is that a weakness will be found.
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.  Worse, using only
one cipher means that the cipher system is unlikely to accommodate
changing ciphers easily, and that could be crucial if the cipher were
publicly found weak, which is an obvious possibility.  How are we to
understand this, indeed?  

---
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, 29 Oct 1999 11:35:42 -0600
From: jcoffin@taeus.com (Jerry Coffin)
Message-ID: <MPG.12838496129d8a269897a0@news.mindspring.com>
References: <38197b1e.2906065@news.io.com>
Newsgroups: sci.crypt
Lines: 32

In article <38197b1e.2906065@news.io.com>, ritter@io.com says...

[ ... ] 

> Oddly, this doesn't sound like anything we have been talking about.  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.  This would be an ordinary
> handshake selection, not a cryptographic protocol, but nevertheless
> clearly neither exposed to nor under the control of the opponents.
> How is that related to the adversary choosing the cipher?  

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.

If the protocol allows the same cipher to be used both for negotiation 
and for messages, then breaking that single cipher allows a MITM to 
force the same cipher to be selected with the negotiation as well, so 
he can then break the messages being sent.

By NOT allowing the same cipher to be used for both negotiation and 
messages, the opponent has to break both the negotiation-phase cipher 
and at least one more before he can really accomplish anything.

-- 
    Later,
    Jerry.
 
The universe is a figment of its own imagination.


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: 29 Oct 1999 18:37:27 -0600
From: vjs@calcite.rhyolite.com (Vernon Schryver)
Message-ID: <7vdek7$bia$1@calcite.rhyolite.com>
References: <MPG.12838496129d8a269897a0@news.mindspring.com>
Newsgroups: sci.crypt
Lines: 40

In article <MPG.12838496129d8a269897a0@news.mindspring.com>,
Jerry Coffin <jcoffin@taeus.com> wrote:

> ...
>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.
>
>If the protocol allows the same cipher to be used both for negotiation 
>and for messages, then breaking that single cipher allows a MITM to 
>force the same cipher to be selected with the negotiation as well, so 
>he can then break the messages being sent.
>
>By NOT allowing the same cipher to be used for both negotiation and 
>messages, the opponent has to break both the negotiation-phase cipher 
>and at least one more before he can really accomplish anything.

That's a good insight on the hole, but the fix is not sufficent.

A man in the middle who has broken the initial cipher could prevent what
the PPP community calls "convergence" on choosing the next cipher.  The
bad guy could modify the negotiating to ensure that there is no common
cipher or make it seem to each peer that the other does not agree.  Since
Terry Ritter insists that the negotiating is done in what he calls the
background (just like some PPP protocols including compression) without
notice to the users as user data is passed, the bad man in the middle
could force the entire session to be run in the broken cipher without the
users knowing.

This applies regardless of whether one cipher or several is used 
simultaneously.  If more than one is used, then you can consider ther
composition as a single cipher.

If someone were to ask me (and I realize no one has), I'd say that that
sounds like such a strong restriction on any cipher (or composition) which
covers any cipher negotiating that you might as well not bother with the
negotiating and stick to that strong cipher.


Please also note that such second order complications are what make
negotiating or anything fancy a security nightmare.  Would you have said
in 1990 that an authentication protocol based on shared secrets and that
never puts the same bits on the wire to be snooped can be wide open
security hole for major commercial implmentations?  I mean only only one
of the new notes at the end of RFC 1994.


Vernon Schryver    vjs@rhyolite.com


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: 3 Nov 1999 08:46:38 -0700
From: vjs@calcite.rhyolite.com (Vernon Schryver)
Message-ID: <7vplcu$evi$1@calcite.rhyolite.com>
References: <7vpfq6$rsc$1@nnrp1.deja.com>
   <7vdek7$bia$1@calcite.rhyolite.com>
Newsgroups: sci.crypt
Lines: 104

In article <7vpfq6$rsc$1@nnrp1.deja.com>,  <terry_ritter@my-deja.com> wrote:

> ...
>If we are using Mr. Ritter's protocol, we will not start
>dynamic cipher negotiation until *after* a secure and
>certified (if necessary) link is established.  There is
>no man-in-the-middle, because if there were, that would
>be identified by public key certification, or by the fact
>that the MITM does not have the message or session keys,
>and therefore cannot modify the ciphertext without
>detection.

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.  If you doubt the initial cipher, you won't use it
to negotiate new ciphers, since you can't trust the results of any
negotiating covered by the initial cipher.


>If the original key-exchange is broken, cipher negotiation
>is not going to help.

Exactly!
And if neither the intial key-exchange nor the cipher that uses those keys
is broken, then there little rational justification for adding the code
for negotiating more ciphers and the *inevitiable* security holes that
come *all* additional code, at least at first.

Since the preeminent real life negotiating protocol suite, PPP, is
somehow irrelevant, remember the SSL experience.   I think SSL was
intended at first to solve a much simplier goal than Mr. Ritter's cipher
negotiating, find a common ground between HTTP client and server,
in part because the U.S.Government ensured that more than one cipher
would be involved.

Even if you are such a wonderful (and absolutely unique) programmer that
none of your code ever has security bugs and you prevent any and all
security bugs in all of other people's code that you use, take a look at
the complications of the IETF's replacement for SSL.  I've been watching
TLS grind through the IETF for years.  It's not a bad effort, but real
life considerations apply.


>                       And if the original cipher, or the
>message or session keys are broken (!!!), we had better be
>using different, unrelated keys and other cipher layers to
>protect the negotiation better than the data.  Then we could
>negotiate a different cipher which might terminate the
>existing break, which would seem to be more than any single
>static cipher could do.

If you have a better cipher for the negotiating, then instead of using
it to negotiate, the rational thing would be to use it for the data
and forget the added complexity and so inevitable added security holes
in negotiating away a bad cipher.


>Dynamic cipher negotiation is intended to support the
>dynamic change of ciphers, which terminates any existing
>break,

Again, if there is a break, then you cannot trust any cipher
negotiating to do anything except make the break worse.

>       and also allows new cryptanalytic results to
>move an earlier cipher out of use.

In real life, no one competent will ever use such negotiating schemes
merely to move an earlier cipher out of use.  If the communicating systes
understand the new cipher, they will use it.  If not, they cannot no matter
how much negotiating they try.  Yes, new systems might use non-negotiating
mechanisms to detect old systems, such as a header that identifies the
data for their mutual convenience, or they might be paranoid and not.
Because of the security holes inevitiably opened to a man in the middle,
they certainly won't chat about switching to the new cipher under the
cover of the old.

Instead, they'll do something like send a trial in the new cipher, possibly
with a hint that the receiver should try the new cipher, or possibly
without a hint to avoid giving clues.  If that works, they'll continue
with the new cipher.  If the new cipher does not work, and they still
trust the old cipher, they might fall back to the old cipher.  If they
have any reason to doubt the old cipher, they'll remember that a bad guy
does not need to be in the middle to filter TCP connections (e.g. sending
TCP RST's or just forged TCP segments) and so cause the supprious
appearance that the new cipher does not work, and they'll never do anything
except with the new cipher.


>                                    The act of changing
>ciphers frequently also reduces the amount of ciphertext
>under any one cipher, thus reducing the advantage of
>breaking that cipher, and hides which ciphertext is
>related to which cipher, which is an essential part of
>most attacks.  But dynamic cipher negotiation is *not*
>the one solution to all possible security problems.

The fundamental problem is that contrary to academic theories, in
almost all real life cases, dynamic cipher negotiation is a security
hole that far outweighs its theoretical advantages.


Vernon Schryver    vjs@rhyolite.com


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Wed, 03 Nov 1999 19:28:12 GMT
From: jsavard@tenMAPSONeerf.edmonton.ab.ca (John Savard)
Message-ID: <38208c52.7595050@news.prosurfr.com>
References: <7vplcu$evi$1@calcite.rhyolite.com>
Newsgroups: sci.crypt
Lines: 14

vjs@calcite.rhyolite.com (Vernon Schryver) wrote, in part:

>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.  If you doubt the initial cipher, you won't use it
>to negotiate new ciphers, since you can't trust the results of any
>negotiating covered by the initial cipher.

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.

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: Sat, 30 Oct 1999 13:58:55 GMT
From: ritter@io.com (Terry Ritter)
Message-ID: <381af94b.344695@news.io.com>
References: <MPG.12838496129d8a269897a0@news.mindspring.com>
Newsgroups: sci.crypt
Lines: 49


On Fri, 29 Oct 1999 11:35:42 -0600, in
<MPG.12838496129d8a269897a0@news.mindspring.com>, in sci.crypt
jcoffin@taeus.com (Jerry Coffin) wrote:

>In article <38197b1e.2906065@news.io.com>, ritter@io.com says...
>
>[ ... ] 
>
>> Oddly, this doesn't sound like anything we have been talking about.  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.  This would be an ordinary
>> handshake selection, not a cryptographic protocol, but nevertheless
>> clearly neither exposed to nor under the control of the opponents.
>> How is that related to the adversary choosing the cipher?  
>
>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.

That's an interesting point.  One possibility is to use an
*additional* cipher on the negotiation data.  I see the negotiation
data being sent with the message, but distinguished from it in a sort
of hidden "control channel."  In this way the negotiation process need
not intrude on user communications.  

Clearly, cipher agreement negotiation will *have* phases, but I do not
see this as a sequential process of (1) negotiate, and then (2)
communicate.  Instead, communication should be in "the current cipher"
and continue like that until agreement on a new cipher occurs and "the
current cipher" changes.  


>If the protocol allows the same cipher to be used both for negotiation 
>and for messages, then breaking that single cipher allows a MITM to 
>force the same cipher to be selected with the negotiation as well, so 
>he can then break the messages being sent.
>
>By NOT allowing the same cipher to be used for both negotiation and 
>messages, the opponent has to break both the negotiation-phase cipher 
>and at least one more before he can really accomplish anything.

---
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, 29 Oct 1999 22:57:13 -0400
From: "Trevor Jackson, III" <fullmoon@aspi.net>
Message-ID: <381A5E89.8BFC94D8@aspi.net>
References: <7vcfeb$46n$1@blowfish.isaac.cs.berkeley.edu>
   <38197b1e.2906065@news.io.com>
Newsgroups: sci.crypt
Lines: 50

David Wagner wrote:

> In article <38197b1e.2906065@news.io.com>, Terry Ritter <ritter@io.com> wrote:
> > Oddly, this doesn't sound like anything we have been talking about.  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.  This would be an ordinary
> > handshake selection, not a cryptographic protocol, but nevertheless
> > clearly neither exposed to nor under the control of the opponents.
> > How is that related to the adversary choosing the cipher?
>
> Hmm.  I didn't realize that was what you meant by a non-cryptographic
> negotiation.  If it's encrypted, it sounds cryptographic to me.
>
> This also raises a further question.  I'm not very clear on how we reach
> agreement on what cipher to use to encrypt our negotiation in the first
> place.  Another negotiation?  But then is it turtles all the way down?
>
> When I hear the word "negotiation", I think of the following problem:
> Alice supports some list of ciphers, Bob supports some (potentially
> different) list of ciphers; now Alice and Bob would like to discover which
> ciphers they share in common, and hopefully find the "best" such cipher.
> Is that what you mean by the "negotiation problem", and if so, how can
> we solve the bootstrapping problem securely?

Rather than create a global namespace for ciphers, one could simply reserve cipher
zero for plain text.  When Alice wants to send her list of ciphers to Bob, she
picks a convenient probe string, including IVs as necessary, and sends it
encrypted with all of the ciphers she supports, in the order of her preference.
Bob decrypts each probe with his entire list of ciphers, and choses from among the
set that match the plaintext.  Note that this set cannot be empty because Bob can
always decode cipher zero.

Bob's reply to Alice is a small number that selects the cipher with which Alice
encrypted the Nth probe packet.  If the number is zero they cannot communicate
securely.

Since this mechanism works with Alice/Bob being complete strangers, it is subject
to many possible attacks.  It is _not_ an authentication protocol, just a cipher
selection mechanism.

If Alice and Bob are members of a common group, such as owners of software that
supports a standard default cipher, the above XnXeXgXoXtXiXaXtXiXoXnX configuation
process can take place under the cover of that default.  Since this mechanism
requires only two messages and throughput is not usually going to be an issue,
3DES may be a suitable default.




Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Sat, 30 Oct 1999 14:01:20 GMT
From: ritter@io.com (Terry Ritter)
Message-ID: <381af9f4.513163@news.io.com>
References: <381A5E89.8BFC94D8@aspi.net>
Newsgroups: sci.crypt
Lines: 116


On Fri, 29 Oct 1999 22:57:13 -0400, in <381A5E89.8BFC94D8@aspi.net>,
in sci.crypt "Trevor Jackson, III" <fullmoon@aspi.net> wrote:

>David Wagner wrote:
>
>> In article <38197b1e.2906065@news.io.com>, Terry Ritter <ritter@io.com> wrote:
>> > Oddly, this doesn't sound like anything we have been talking about.  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.  This would be an ordinary
>> > handshake selection, not a cryptographic protocol, but nevertheless
>> > clearly neither exposed to nor under the control of the opponents.
>> > How is that related to the adversary choosing the cipher?
>>
>> Hmm.  I didn't realize that was what you meant by a non-cryptographic
>> negotiation.  If it's encrypted, it sounds cryptographic to me.

By the same token, anything used in a cipher system reasonably might
be called "cryptographic."  The distinction I wish to draw is between
the complexity of common cryptographic protocols, versus a basic
selection and handshake.  The selection itself is non-cryptographic,
even if the item selected happens to be a cryptographic object.  


>> This also raises a further question.  I'm not very clear on how we reach
>> agreement on what cipher to use to encrypt our negotiation in the first
>> place.  Another negotiation?  But then is it turtles all the way down?

No.  

One might as well ask what *key* we use to encrypt messages "in the
first place"?  Obviously, both ends *must* use the same secret key, so
how do they get it?  Usually delivery is by some secure other channel,
or by authenticated public key means.  But the same process can
deliver the name of the cipher to use, or even the actual cipher
itself.  


>> When I hear the word "negotiation", I think of the following problem:
>> Alice supports some list of ciphers, Bob supports some (potentially
>> different) list of ciphers; now Alice and Bob would like to discover which
>> ciphers they share in common, and hopefully find the "best" such cipher.
>> Is that what you mean by the "negotiation problem", and if so, how can
>> we solve the bootstrapping problem securely?

I suggest that everyone have Triple DES.  In practice, people might
end up with the most well-known dozen or so ciphers, plus others.  

I see no grounds for negotiating "best."  Indeed, the idea is
explicitly *not* to select one cipher and stay with it; the idea is to
select at random among a list of reasonable size.  I would expect each
user (or their corporate security officer) to have a list of ciphers
which they will trust for use.  The "negotiation" process is simply a
way for the machinery at each end to select a random cipher and know
which cipher to use at any given time.  

As an example, initial key exchange provides the cipher to be used at
the start.  Then, say the near end sends its list of acceptable cipher
names to the far end:  (I see this happening in a hidden "control
channel" within the next message, although that channel could be
additionally encrypted).  Upon receipt of the list, if at least one of
those is acceptable to the far end, the far end sends that one cipher
name back (in the similar control channel accompanying the response
from the far end).  When the near end sees a single cipher name, and
that name is acceptable to the near end, the near end switches to that
cipher starting with the next outgoing message.  The far end expects
then next message to be in the new cipher, and so deciphers with the
new cipher first.  But if a message has been lost in transit, the
message can only be in the previous cipher, which can be tried next.
This is a resilient protocol.  


>Rather than create a global namespace for ciphers, one could simply reserve cipher
>zero for plain text.  When Alice wants to send her list of ciphers to Bob, she
>picks a convenient probe string, including IVs as necessary, and sends it
>encrypted with all of the ciphers she supports, in the order of her preference.
>Bob decrypts each probe with his entire list of ciphers, and choses from among the
>set that match the plaintext.  Note that this set cannot be empty because Bob can
>always decode cipher zero.

This seems harder than it needs to be.  Is there some advantage to it?
I mean, both ends have to have exchanged a key anyway.  Why don't they
also exchange the starting cipher name?  


>Bob's reply to Alice is a small number that selects the cipher with which Alice
>encrypted the Nth probe packet.  If the number is zero they cannot communicate
>securely.

If we assume that the list has been received, we obviously can select
from it by index.  But if the list message was lost, indexing is
impossible, while a cipher name is still useful.  I think it is
helpful and important for such a protocol to survive lost messages.


>Since this mechanism works with Alice/Bob being complete strangers, it is subject
>to many possible attacks.  It is _not_ an authentication protocol, just a cipher
>selection mechanism.
>
>If Alice and Bob are members of a common group, such as owners of software that
>supports a standard default cipher, the above XnXeXgXoXtXiXaXtXiXoXnX configuation
>process can take place under the cover of that default.  Since this mechanism
>requires only two messages and throughput is not usually going to be an issue,
>3DES may be a suitable default.

Triple DES may be the obvious cipher which everyone can be expected to
have, and could be the default starting cipher, absent a particular
specification otherwise.  

---
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: Sat, 30 Oct 1999 17:14:54 -0400
From: "Trevor Jackson, III" <fullmoon@aspi.net>
Message-ID: <381B5FCE.D577F968@aspi.net>
References: <381af9f4.513163@news.io.com>
Newsgroups: sci.crypt
Lines: 148

Terry Ritter wrote:

> On Fri, 29 Oct 1999 22:57:13 -0400, in <381A5E89.8BFC94D8@aspi.net>,
> in sci.crypt "Trevor Jackson, III" <fullmoon@aspi.net> wrote:
>
> >David Wagner wrote:
> >
> >> In article <38197b1e.2906065@news.io.com>, Terry Ritter <ritter@io.com> wrote:
> >> > Oddly, this doesn't sound like anything we have been talking about.  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.  This would be an ordinary
> >> > handshake selection, not a cryptographic protocol, but nevertheless
> >> > clearly neither exposed to nor under the control of the opponents.
> >> > How is that related to the adversary choosing the cipher?
> >>
> >> Hmm.  I didn't realize that was what you meant by a non-cryptographic
> >> negotiation.  If it's encrypted, it sounds cryptographic to me.
>
> By the same token, anything used in a cipher system reasonably might
> be called "cryptographic."  The distinction I wish to draw is between
> the complexity of common cryptographic protocols, versus a basic
> selection and handshake.  The selection itself is non-cryptographic,
> even if the item selected happens to be a cryptographic object.
>
> >> This also raises a further question.  I'm not very clear on how we reach
> >> agreement on what cipher to use to encrypt our negotiation in the first
> >> place.  Another negotiation?  But then is it turtles all the way down?
>
> No.
>
> One might as well ask what *key* we use to encrypt messages "in the
> first place"?  Obviously, both ends *must* use the same secret key, so
> how do they get it?  Usually delivery is by some secure other channel,
> or by authenticated public key means.  But the same process can
> deliver the name of the cipher to use, or even the actual cipher
> itself.

Why deliver only one when you can deliver a list?  (more on this below)

>
>
> >> When I hear the word "negotiation", I think of the following problem:
> >> Alice supports some list of ciphers, Bob supports some (potentially
> >> different) list of ciphers; now Alice and Bob would like to discover which
> >> ciphers they share in common, and hopefully find the "best" such cipher.
> >> Is that what you mean by the "negotiation problem", and if so, how can
> >> we solve the bootstrapping problem securely?
>
> I suggest that everyone have Triple DES.  In practice, people might
> end up with the most well-known dozen or so ciphers, plus others.
>
> I see no grounds for negotiating "best."  Indeed, the idea is
> explicitly *not* to select one cipher and stay with it; the idea is to
> select at random among a list of reasonable size.  I would expect each
> user (or their corporate security officer) to have a list of ciphers
> which they will trust for use.  The "negotiation" process is simply a
> way for the machinery at each end to select a random cipher and know
> which cipher to use at any given time.
>
> As an example, initial key exchange provides the cipher to be used at
> the start.  Then, say the near end sends its list of acceptable cipher
> names to the far end:  (I see this happening in a hidden "control
> channel" within the next message, although that channel could be
> additionally encrypted).  Upon receipt of the list, if at least one of
> those is acceptable to the far end, the far end sends that one cipher
> name back (in the similar control channel accompanying the response
> from the far end).  When the near end sees a single cipher name, and
> that name is acceptable to the near end, the near end switches to that
> cipher starting with the next outgoing message.  The far end expects
> then next message to be in the new cipher, and so deciphers with the
> new cipher first.  But if a message has been lost in transit, the
> message can only be in the previous cipher, which can be tried next.
> This is a resilient protocol.
>
> >Rather than create a global namespace for ciphers, one could simply reserve cipher
> >zero for plain text.  When Alice wants to send her list of ciphers to Bob, she
> >picks a convenient probe string, including IVs as necessary, and sends it
> >encrypted with all of the ciphers she supports, in the order of her preference.
> >Bob decrypts each probe with his entire list of ciphers, and choses from among the
> >set that match the plaintext.  Note that this set cannot be empty because Bob can
> >always decode cipher zero.
>
> This seems harder than it needs to be.  Is there some advantage to it?
> I mean, both ends have to have exchanged a key anyway.  Why don't they
> also exchange the starting cipher name?

If Alice publishes the public part of a two-part key she can attach a list of cipher
selection packets to the key.  Then Bob select one and use it.  The issue I was
attempting to address is avoiding the need to be excruciatingly explicit about cipher
names.  A properly constructed probe packet makes the cipher equally anonymous.  This
isn't really a security provision, it's a way to avoid rev skew problems, thus a
simplification of the expected operational details rather than a simplification of the
implementation details.

Also, if Bob is sending a stream of messages to Alice, he can do more than change the
per-messages keys.  He can also vary the cipher as long as he stays within the set
described by Alice's public key.

>
>
> >Bob's reply to Alice is a small number that selects the cipher with which Alice
> >encrypted the Nth probe packet.  If the number is zero they cannot communicate
> >securely.
>
> If we assume that the list has been received, we obviously can select
> from it by index.  But if the list message was lost, indexing is
> impossible, while a cipher name is still useful.  I think it is
> helpful and important for such a protocol to survive lost messages.

Yes, that is a valid issue.  However, channel reliability is orthogonal to channel
impenetrability (crypto).  They are both desirable properties, but need not be
implemented in the same layer.  I believe reliability is aproperty that belongs in the
transport layer, which is necessarily below the cipher/security layer.

When there are a large number of ciphers available from a large number of sources you
would need some mechanism to avoid naming errors.  Note there are two possible error
classes.  A collision occurs when Alice and Bob use the same name for different
ciphers, so operators using the software they each sell get error messages about
something that "should work" from the operator's point of view; and the opposite, a
failed rendevous occurs when they use different names for the same cipher, with the
result that operators who could have communicated cannot.

Thus selection by index, as you termed it, rather then selection by name.  Note there
is some additional confidence generated by a properly constructed probe packet in that
with it one can confirm not only that the ends points agree on the cipher they intend
to use, but also that the implementations of the ciphers are correct/match.

>
>
> >Since this mechanism works with Alice/Bob being complete strangers, it is subject
> >to many possible attacks.  It is _not_ an authentication protocol, just a cipher
> >selection mechanism.
> >
> >If Alice and Bob are members of a common group, such as owners of software that
> >supports a standard default cipher, the above XnXeXgXoXtXiXaXtXiXoXnX configuation
> >process can take place under the cover of that default.  Since this mechanism
> >requires only two messages and throughput is not usually going to be an issue,
> >3DES may be a suitable default.
>
> Triple DES may be the obvious cipher which everyone can be expected to
> have, and could be the default starting cipher, absent a particular
> specification otherwise.





Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: 30 Oct 99 03:03:33 GMT
From: jsavard@ecn.ab.ca ()
Message-ID: <381a6005.0@ecn.ab.ca>
References: <7vcfeb$46n$1@blowfish.isaac.cs.berkeley.edu>
   <38197b1e.2906065@news.io.com>
Newsgroups: sci.crypt
Lines: 10

David Wagner (daw@blowfish.isaac.cs.berkeley.edu) wrote:
: Hmm.  I didn't realize that was what you meant by a non-cryptographic
: negotiation.  If it's encrypted, it sounds cryptographic to me.

Although it was noted early on as being encrypted, I think the intent was
to state that the protocol need not be an elaborate one with special
properties; except for being enciphered, other special measures do not
seem to be obviously required.

John Savard


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Wed, 03 Nov 1999 14:27:21 GMT
From: ritter@io.com
Message-ID: <7vpgo4$sn9$1@nnrp1.deja.com>
References: <7vdr1q$5ng$1@blowfish.isaac.cs.berkeley.edu>
   <381a6005.0@ecn.ab.ca>
Newsgroups: sci.crypt
Lines: 115

In article <7vdr1q$5ng$1@blowfish.isaac.cs.berkeley.edu>,
  daw@blowfish.isaac.cs.berkeley.edu (David Wagner) wrote:
> In article <381a6005.0@ecn.ab.ca>,  <jsavard@ecn.ab.ca> wrote:
> > David Wagner (daw@blowfish.isaac.cs.berkeley.edu) wrote:
> > : Hmm.  I didn't realize that was what you meant by a
non-cryptographic
> > : negotiation.  If it's encrypted, it sounds cryptographic to me.
> >
> > Although it was noted early on as being encrypted, I think the
intent was
> > to state that the protocol need not be an elaborate one with
special
> > properties; except for being enciphered, other special measures do
not
> > seem to be obviously required.
>
> I'm not convinced (yet).
>
> First, there are the obvious protocol attacks.
>
> If it's encrypted, it'd better be MAC'ed as well -- otherwise there
might
> well be ciphertext tampering attacks (e.g., truncate the ciphertext
> to delete some of the sender's proposed ciphers).

Yes, of course.  Every cipher should have (and all of my cipher
systems do have) some sort of hash of the data which allows us
to detect ciphertext modification.  In an overall system which
coordinates email exchanges, there may well be sequence numbers
as well.


>Also, you have
> to worry about replay attacks -- so does that mean we need to add a
> challenge-response prelude to the negotiation protocol?

Sequence numbers.


>And as
someone
> else pointed out, we better make sure the cipher we use to encrypt
the
> negotiation protocol is different from the cipher we use to encrypt
> the rest of our traffic, because otherwise we have a huge single
point
> of failure.

Fine.


> Once you start getting into this level of complexity, I have to
wonder
> whether the claim that "it need not be elaborate" is truly realistic.

But what else could possibly be "realistic" in a deployed
cipher system?  Do you seriously suggest that one would
build a cipher system *without* (effectively) having
error-detection on the plaintext or ciphertext?  So that,
at least, would seem to be there already.

The whole point of such a system is to change ciphers,
which implies that we have multiple or many ciphers, any of
which can be used.  Is it then an "elaborate" extension to
allow different or additional ciphers for the dynamic
cipher negotiation?  I think not.


> Second, there are the obvious implementation issues.
>
> Usually if we need a cipher negotiation protocol, it's because we
don't
> know a priori of any ciphers that are strong enough to satisfy
everyone
> and yet are implemented everywhere.  (After all, if we had one, we'd
just
> use it for encrypting all our traffic.)

That is only one part of the goal, and perhaps the lesser
part.  Just finding one cipher which we can agree upon does
not give us the dynamic cipher changes which: (1) terminate
existing breaks, (2) reduce the amount of information under
any one cipher, and (3) hide the correspondence between
cipher and ciphertext, as most attacks require.


>But now we've got a
bootstrapping
> problem: how do we pick which cipher to encrypt our negotiation
under?
> We could precede it with another negotiation protocol, but that'd be
silly.

Yes, that would be silly.


> So I'm not convinced that cipher negotiation is as trivial as it is
> made out to be.  In fact, experience (SSL, SSH, etc.) seems to
suggest
> exactly the opposite.

Any protocol is going to be more complex than not having
a protocol.  Presumably, the simpler we make that protocol,
the better off we are.  By making it a simple selection
instead of some horribly complex (and equally unprovable)
cryptographic protocol, we have a better chance to understand
it well and implement it well.

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

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, 02 Nov 1999 20:22:10 GMT
From: bryan.olson@uptronics.com
Message-ID: <7vnh5d$fh6$1@nnrp1.deja.com>
References: <38197b1e.2906065@news.io.com>
Newsgroups: sci.crypt
Lines: 36



ritter@io.com (Terry Ritter) wrote:

> Oddly, this doesn't sound like anything we have been talking about.  I
> have never heard -- and certainly never made -- a suggestion that the
> adversary will choose the cipher.

You certainly have heard such a suggestion.  Yes, you
failed to consider the chosen cipher attack, and now
it seems that you confuse failure to recognize the
problem with not having it.

> 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.  This would be an ordinary
> handshake selection, not a cryptographic protocol, but nevertheless
> clearly neither exposed to nor under the control of the opponents.
> How is that related to the adversary choosing the cipher?

As I noted some time ago, your writings made the point
that the choice of cipher was secret, but were clearly
oblivious to the fact that authentication of the choice
is more important.  The details of your protocols have
never appeared, so we cannot tell whether the attack
would work.  The fact that you still compare the
negotiation of the cipher to modem protocols, and call
it "an ordinary handshake selection, not a cryptographic
protocol" is rather ominous.

--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: Thu, 04 Nov 1999 00:46:45 GMT
From: ritter@io.com (Terry Ritter)
Message-ID: <3820d764.3353257@news.io.com>
References: <7vnh5d$fh6$1@nnrp1.deja.com>
Newsgroups: sci.crypt
Lines: 86


On Tue, 02 Nov 1999 20:22:10 GMT, in <7vnh5d$fh6$1@nnrp1.deja.com>, in
sci.crypt bryan.olson@uptronics.com wrote:

>ritter@io.com (Terry Ritter) wrote:
>
>> Oddly, this doesn't sound like anything we have been talking about.  I
>> have never heard -- and certainly never made -- a suggestion that the
>> adversary will choose the cipher.
>
>You certainly have heard such a suggestion.  Yes, you
>failed to consider the chosen cipher attack, and now
>it seems that you confuse failure to recognize the
>problem with not having it.

A "chosen cipher attack" would imply that the opponent could choose
the cipher to be used.  That is not possible here.  

Under my proposals (multi-level ciphering, dynamically changing
ciphers, and many ciphers), the cipher would be chosen at random from
the set of ciphers acceptable to both ends.  The cipher lists may or
may not be secret, but the negotiation and selection *would* be
secret.  This process would be conducted under cipher.  

Clearly, negotiations can occur under cipher only *after* an original
cipher and key have been selected.  This is the normal key management
problem.  Cipher negotiation does not solve that.  

If user authentication is to be effective, it must occur *before* we
start talking under cipher:  We cannot hope to identify a
man-in-the-middle from information which we share with the other end.
So before we share anything of consequence we must already be sure
there is no MITM.  One possibility is to authenticate the other end by
authenticating (certifying) our public keys.  Dynamic cipher
negotiation and selection occurs only after this.  


>> 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.  This would be an ordinary
>> handshake selection, not a cryptographic protocol, but nevertheless
>> clearly neither exposed to nor under the control of the opponents.
>> How is that related to the adversary choosing the cipher?
>
>As I noted some time ago, your writings made the point
>that the choice of cipher was secret, but were clearly
>oblivious to the fact that authentication of the choice
>is more important.  

OBVIOUSLY, any cipher code can be compromised.  That is the case with
any cipher system.  That is why DES was originally for hardware only.
We don't want to use compromised code.  And simply making the source
available for review is unlikely to be helpful to most users.  

Presumably, various free cipher systems will be sufficiently well
known and analyzed to be trustable.  Some users may want to obtain
their ciphers from a reliable commercial source.  But surely nobody
imagines going out on the net and saying "hey, somebody send me <xxx>
cipher," and then trusting anything which came in.  

Yes, the cipher code itself must be trustable.  


>The details of your protocols have
>never appeared, so we cannot tell whether the attack
>would work.  The fact that you still compare the
>negotiation of the cipher to modem protocols, and call
>it "an ordinary handshake selection, not a cryptographic
>protocol" is rather ominous.

How hard do you want to make this?

Selecting a cipher from among a list of approved ciphers simply does
not require a cryptographic protocol.  I'm sure we could do all sorts
of fancy things, and it may be that the selection channel should have
additional protection.  But the selection itself is straightforward.
It is just like two people talking.  It is unimportant which cipher we
select, as long as both ends agree.  The idea is not to select the
"best."  Indeed, we want to *avoid* selecting "the" best cipher, so
that we can select arbitrarily from among a rather large set.  

---
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, 05 Nov 1999 05:18:13 GMT
From: bryan.olson@uptronics.com
Message-ID: <7vtpaj$gg$1@nnrp1.deja.com>
References: <3820d764.3353257@news.io.com>
Newsgroups: sci.crypt
Lines: 91

Terry Ritter wrote:
>
> bryan.olson@uptronics.com wrote:

> >You certainly have heard such a suggestion.  Yes, you
> >failed to consider the chosen cipher attack, and now
> >it seems that you confuse failure to recognize the
> >problem with not having it.
>
> A "chosen cipher attack" would imply that the opponent could choose
> the cipher to be used.  That is not possible here.
>
> Under my proposals (multi-level ciphering, dynamically changing
> ciphers, and many ciphers), the cipher would be chosen at random from
> the set of ciphers acceptable to both ends.  The cipher lists may or
> may not be secret, but the negotiation and selection *would* be
> secret.  This process would be conducted under cipher.

One more time: secret is not the issue.  Authenticated
is the issue.  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.  You have simply assumed the choice would be
random, without ever presenting how they ensure it
will be random when an attacker may modify the messages
that influence the choice.

[...]
Ritter:
> >> 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.  This would be an ordinary
> >> handshake selection, not a cryptographic protocol, but nevertheless
> >> clearly neither exposed to nor under the control of the opponents.
> >> How is that related to the adversary choosing the cipher?
> >
> >As I noted some time ago, your writings made the point
> >that the choice of cipher was secret, but were clearly
> >oblivious to the fact that authentication of the choice
> >is more important.
>
> OBVIOUSLY, any cipher code can be compromised. [...]

Whether an authentication code be compromised is
beyond the scope of the protocol. The point is the
need for authentication and its absence from your
proposal.

> >The details of your protocols have
> >never appeared, so we cannot tell whether the attack
> >would work.  The fact that you still compare the
> >negotiation of the cipher to modem protocols, and call
> >it "an ordinary handshake selection, not a cryptographic
> >protocol" is rather ominous.
>
> How hard do you want to make this?
>

That could be the mantra of designers of failed
protocols.

> Selecting a cipher from among a list of approved ciphers simply does
> not require a cryptographic protocol.  I'm sure we could do all sorts
> of fancy things, and it may be that the selection channel should have
> additional protection.  But the selection itself is straightforward.
> It is just like two people talking.  It is unimportant which cipher we
> select, as long as both ends agree.  The idea is not to select the
> "best."  Indeed, we want to *avoid* selecting "the" best cipher, so
> that we can select arbitrarily from among a rather large set.

A communications protocol specifies the procedure
each node executes, including the messages it sends
and its response to each possible message received.
The attack people are pointing out is one in which
the adversary looks at the protocol, and tries to
find how he can alter the messages to influence the
choice of cipher towards those that he would prefer.
It does not weaken the choice to below the strength
of weakest cipher that the sender would agree to use.

Whether such attacks would work depends upon the
protocol, and yours has never appeared.

--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: Mon, 08 Nov 1999 05:51:17 GMT
From: ritter@io.com (Terry Ritter)
Message-ID: <382664bb.4585308@news.io.com>
References: <7vtpaj$gg$1@nnrp1.deja.com>
Newsgroups: sci.crypt
Lines: 154


On Fri, 05 Nov 1999 05:18:13 GMT, in <7vtpaj$gg$1@nnrp1.deja.com>, in
sci.crypt bryan.olson@uptronics.com wrote:

>Terry Ritter wrote:
>>
>> bryan.olson@uptronics.com wrote:
>
>> >You certainly have heard such a suggestion.  Yes, you
>> >failed to consider the chosen cipher attack, and now
>> >it seems that you confuse failure to recognize the
>> >problem with not having it.
>>
>> A "chosen cipher attack" would imply that the opponent could choose
>> the cipher to be used.  That is not possible here.
>>
>> Under my proposals (multi-level ciphering, dynamically changing
>> ciphers, and many ciphers), the cipher would be chosen at random from
>> the set of ciphers acceptable to both ends.  The cipher lists may or
>> may not be secret, but the negotiation and selection *would* be
>> secret.  This process would be conducted under cipher.
>
>One more time: secret is not the issue.  Authenticated
>is the issue.  

Well, in cryptography, there are various kinds of authentication:
There is "user authentication," where we identify a particular user as
compared to some other.  There is "message authentication," where we
identify that a message has not been changed in transit.  There is
"key authentication," where we show that a particular public key is in
fact the current key, and belongs to who we expect.  There is
"algorithm authentication," where we identify that the code we wish to
use is in fact the code which the reputable source produced and has
not somehow been modified in transit.  Presumably there are other
forms as well.  Perhaps you should indicate what form of
authentication is your particular issue.  


>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.  You have simply assumed the choice would be
>random, without ever presenting how they ensure it
>will be random when an attacker may modify the messages
>that influence the choice.

First of all, the "random" selection I propose is exactly the same
sort of thing which produces message keys (or "session keys," if they
are used for multiple messages), which are used in almost every
serious cipher system.  Normally, the public-key component transfers
the message key, which is then used in a secret-key system.  This is
very well known technology, and the issues are also well known, so
there should be little need to repeat these well known details.  

Next, it is true that messages must be sent between the ends to
coordinate cipher changes.  But these messages are -- once again --
sent *under cipher*.  By "under cipher," I mean that I require that a
cipher already have been established and be in effect.  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.  


>[...]
>Ritter:
>> >> 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.  This would be an ordinary
>> >> handshake selection, not a cryptographic protocol, but nevertheless
>> >> clearly neither exposed to nor under the control of the opponents.
>> >> How is that related to the adversary choosing the cipher?
>> >
>> >As I noted some time ago, your writings made the point
>> >that the choice of cipher was secret, but were clearly
>> >oblivious to the fact that authentication of the choice
>> >is more important.
>>
>> OBVIOUSLY, any cipher code can be compromised. [...]
>
>Whether an authentication code be compromised is
>beyond the scope of the protocol. The point is the
>need for authentication and its absence from your
>proposal.

If you are describing a need for message authentication, I wholly
agree.  This should be a part of any cipher, and is in fact a part of
all of my commercial ciphers.  This is very well known technology. 

But message authentication is *not* part of the cipher-change
protocols, because those protocols *assume* that message
authentication is performed by the covering cipher.  That cipher also
carries normal message traffic, of course, in addition to the
negotiation conversation or channel.  The negotiation is the simple
use of the ordinary and expected features of any serious cipher
system.  


>> >The details of your protocols have
>> >never appeared, so we cannot tell whether the attack
>> >would work.  The fact that you still compare the
>> >negotiation of the cipher to modem protocols, and call
>> >it "an ordinary handshake selection, not a cryptographic
>> >protocol" is rather ominous.
>>
>> How hard do you want to make this?
>>
>
>That could be the mantra of designers of failed
>protocols.
>
>> Selecting a cipher from among a list of approved ciphers simply does
>> not require a cryptographic protocol.  I'm sure we could do all sorts
>> of fancy things, and it may be that the selection channel should have
>> additional protection.  But the selection itself is straightforward.
>> It is just like two people talking.  It is unimportant which cipher we
>> select, as long as both ends agree.  The idea is not to select the
>> "best."  Indeed, we want to *avoid* selecting "the" best cipher, so
>> that we can select arbitrarily from among a rather large set.
>
>A communications protocol specifies the procedure
>each node executes, including the messages it sends
>and its response to each possible message received.
>The attack people are pointing out is one in which
>the adversary looks at the protocol, and tries to
>find how he can alter the messages to influence the
>choice of cipher towards those that he would prefer.
>It does not weaken the choice to below the strength
>of weakest cipher that the sender would agree to use.
>
>Whether such attacks would work depends upon the
>protocol, and yours has never appeared.

One might reasonably expect the cipher system which encloses the
cipher-change negotiation to have at least the characteristics one now
expects to see in serious ciphers.  Identifying those messages whose
contents have changed in transit is a common and expected feature of
serious cipher systems.  It thus hardly seems odd that I would expect
such a feature to be included in the enclosing cipher.  And, since it
is a feature of *that* system, it is *not* a feature of my protocol
per se, any more than that the enclosing cipher should be secure, and
keys should be properly managed, and public keys certified, and on and
on.  These things are to be expected in serious cipher systems.  As I
have said over and over again, the negotiation occurs *under* some
established cipher.  

---
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: Thu, 11 Nov 1999 01:27:24 GMT
From: bryan.olson@uptronics.com
Message-ID: <80d61p$r1u$1@nnrp1.deja.com>
References: <382664bb.4585308@news.io.com>
Newsgroups: sci.crypt
Lines: 84

Terry Ritter wrote:
bryan.olson@uptronics.com wrote:
[...]
> >One more time: secret is not the issue.  Authenticated
> >is the issue.
>
> Well, in cryptography, there are various kinds of authentication:

Glad you're seeing that.

[...]
> >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.  You have simply assumed the choice would be
> >random, without ever presenting how they ensure it
> >will be random when an attacker may modify the messages
> >that influence the choice.
>
> First of all, the "random" selection I propose is exactly the same
> sort of thing which produces message keys (or "session keys," if they
> are used for multiple messages), which are used in almost every
> serious cipher system.  Normally, the public-key component transfers
> the message key, which is then used in a secret-key system.  This is
> very well known technology, and the issues are also well known, so
> there should be little need to repeat these well known details.

Many or most serious systems use session keys where
each key is chosen by one side, thus requiring no
negotiation.  In systems that negotiate choice of
cipher the "well known details" are well known for
their difficulty; failure to authenticate the cipher
negotiation was a mistake in SSL.

Over and over you've stated that the negotiation is
secret, protected by a cipher.  When did you note
the need for authentication or name a MAC or
signature? Now you say it's just like other cipher
systems, such as public key ciphers.  Ciphers provide
poor authentication, and public key ciphers don't
really provide any authentication at all.  It is
not the case that your claim of secrecy, protected
by a cipher implies authentication.  In fact it
implies that you missed the attack.

> Next, it is true that messages must be sent between the ends to
> coordinate cipher changes.  But these messages are -- once again --
> sent *under cipher*.  By "under cipher," I mean that I require that a
> cipher already have been established and be in effect.  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."

Now you're starting to get it.  This authentication
was completely missing from your suggestion before
others pointed out the problem.  Yes, it can be fixed,
but the actual protocol design is not the simple
exercise you had thought.

> >Whether an authentication code be compromised is
> >beyond the scope of the protocol. The point is the
> >need for authentication and its absence from your
> >proposal.
>
> If you are describing a need for message authentication, I wholly
> agree.

So thank people for pointing out that you needed it in
your negotiation phase, and stop pretending that you had
it there already.

> This should be a part of any cipher, and is in fact a part of
> all of my commercial ciphers.  This is very well known technology.

The cipher agility of your actual systems is far behind
the state of the art.  You claim to be long-time advocate
of standard protocols with interchangeable cipher, and that
the design of such protocols is easy.  Your commercial
ciphers contradict such claims.
--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: Thu, 11 Nov 1999 06:05:54 GMT
From: ritter@io.com (Terry Ritter)
Message-ID: <382a5c09.9266545@news.io.com>
References: <80d61p$r1u$1@nnrp1.deja.com>
Newsgroups: sci.crypt
Lines: 235


On Thu, 11 Nov 1999 01:27:24 GMT, in <80d61p$r1u$1@nnrp1.deja.com>, in
sci.crypt bryan.olson@uptronics.com wrote:

>Terry Ritter wrote:
>bryan.olson@uptronics.com wrote:
>[...]
>> >One more time: secret is not the issue.  Authenticated
>> >is the issue.
>>
>> Well, in cryptography, there are various kinds of authentication:
>
>Glad you're seeing that.

In the rest of the paragraph -- which you did not see fit to include
here -- I described various types of "authentication."  

I named them.  You did not.  You failed to distinguish between them,
and completely failed to identify what sort of "authentication" you
were addressing.  Strangely, it's like you really didn't know what you
were talking about, or at least could not express it clearly.  Odd.  


>[...]
>> >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.  You have simply assumed the choice would be
>> >random, without ever presenting how they ensure it
>> >will be random when an attacker may modify the messages
>> >that influence the choice.
>>
>> First of all, the "random" selection I propose is exactly the same
>> sort of thing which produces message keys (or "session keys," if they
>> are used for multiple messages), which are used in almost every
>> serious cipher system.  Normally, the public-key component transfers
>> the message key, which is then used in a secret-key system.  This is
>> very well known technology, and the issues are also well known, so
>> there should be little need to repeat these well known details.
>
>Many or most serious systems use session keys where
>each key is chosen by one side, thus requiring no
>negotiation.  

"Session keys" (more properly called "message keys," in most cases)
are in fact very close to the negotiation which I have been promoting
all along.  In my proposal, one end sends a list; the other selects
from that list, repeatedly, perhaps with every message, much like a
message key.  Occasionally a new list is requested or just sent.  I
suppose one might well say that all this requires "no negotiation,"
and this is the normal situation.  

>In systems that negotiate choice of
>cipher the "well known details" are well known for
>their difficulty; failure to authenticate the cipher
>negotiation was a mistake in SSL.

In my proposals, it is has been, and still is, unnecessary to
authenticate the cipher choice.  No authentication mistake is possible
with respect to cipher choice.  The ciphers themselves must be
authentic, but that is not a cipher-change protocol issue.  


>Over and over you've stated that the negotiation is
>secret, protected by a cipher.  When did you note
>the need for authentication or name a MAC or
>signature? Now you say it's just like other cipher
>systems, such as public key ciphers.  Ciphers provide
>poor authentication, and public key ciphers don't
>really provide any authentication at all.  It is
>not the case that your claim of secrecy, protected
>by a cipher implies authentication.  In fact it
>implies that you missed the attack.

I have always said that the cipher-change negotiation must occur under
cipher.  I am guilty of expecting that cipher system to be effective.
But I missed no attack, because there was and is no attack on the
cipher-change protocol itself, which is all I have been describing.  

The cipher-change protocol does *not* have the man-in-the-middle
problems which seem inherent in public-key cryptography.  This is
because the cipher-change "negotiation" is simply not exposed to MITM
diddling.  A MITM must be detected by the outer cipher layers, for if
not, the plaintext is exposed, making cipher-changes completely
irrelevant.  I am unaware of any claim that cipher-changes would solve
the MITM problem for public-key cryptography.  

You seem to have several big problems here, the first being the
possibility that I missed something, and so deserve your castigation.
Well, I did *not* miss what you think I did, but even if I had, who
elected you God?  If you had found a factual problem, you could
present that.  Instead, you cop an attitude and distort reality, both
of which are way out of line.   

Then you seem to think that because I made the original proposal, that
if only you could find some error in it, I would be embarrassed.
Sorry.  There are always problems with new proposals, because they
have not had the amount of development the old ones have had.  The
real issue is whether the underlying idea is correct, and here it is.
Your "authentication" issue is both specious and an embarrassingly
shallow understanding of the real problem.  


>> Next, it is true that messages must be sent between the ends to
>> coordinate cipher changes.  But these messages are -- once again --
>> sent *under cipher*.  By "under cipher," I mean that I require that a
>> cipher already have been established and be in effect.  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."
>
>Now you're starting to get it.  This authentication
>was completely missing from your suggestion before
>others pointed out the problem.  

There was and is no problem, and what was pointed out was wrong.  If
the public-key certification or message authentication is bad, the
original security is bad, and there is no protection for the raw
plaintext that we are trying to protect, so cipher-change negotiation
is the least of the problems.  

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.  Where did
*you* ever say that *those* were required?  But they *are* required,
and you missed those "attacks."  Tsk, tsk.  

>Yes, it can be fixed,
>but the actual protocol design is not the simple
>exercise you had thought.

The protocol is *just* as simple as I first proposed.  There is
essentially no protocol there at all:  We just select at random from a
list.  

The design part of this is the construction of a hidden command
channel behind the plaintext, the various messages and retained state
required to perform a clean transition, and I believe, the ability to
withstand message loss without problem.  This does require some
design, and failure here means we will not change ciphers, or may do
so in regular ways.  

In other words, the *worst* that can happen from a bad cipher-change
protocol is that we end up using one cipher repeatedly, which is the
*normal* situation now.  Failure in the protocol is thus only a
failure to take advantage of new cipher-change strength, and not an
introduction of weakness.  

>> >Whether an authentication code be compromised is
>> >beyond the scope of the protocol. The point is the
>> >need for authentication and its absence from your
>> >proposal.
>>
>> If you are describing a need for message authentication, I wholly
>> agree.
>
>So thank people for pointing out that you needed it in
>your negotiation phase, and stop pretending that you had
>it there already.

It was clear enough for almost everyone else who read my proposals.
Stop pretending that you have contributed something important.  You
have not.  Stop pretending that I have ignored or dissembled about a
real problem.  I have not.  

As far as I know, the only real problem which came up was the need for
additional protection for the command channel, beyond that used for
the plaintext.  That was pointed out by "others," not me.  But that is
not your "authentication," and it is easily fixed.  


>> This should be a part of any cipher, and is in fact a part of
>> all of my commercial ciphers.  This is very well known technology.
>
>The cipher agility of your actual systems is far behind
>the state of the art.  

"Cipher agility" would seem to mean the ability to change ciphers
quickly.  Any system which can do this is *beyond* the current state
of the art.  My proposals thus *are* the state of the art in
non-government cryptography.  

My proposals allow ciphers to change, at random, from an approved
list, with *every* *message*.  That's about as "agile" as one can get.


>You claim to be long-time advocate
>of standard protocols with interchangeable cipher, 

Not only do I claim this, I can prove it, based on archived messages
on my pages and other servers.   

>and that
>the design of such protocols is easy.  

Really?   

I doubt I ever said that the design of such protocols was "easy."
These protocols are, however, far different from the usual obscure
cryptographic protocols which typically have almost endless
possibility of error.  In that sense, cipher-change protocols *are*
easi*er*.  

>Your commercial
>ciphers contradict such claims.

I'm a little confused here:  Are you saying that I have produced
ciphers of such complexity that they obviously were not easy to
design?  Guilty.  

Actually, my ciphers are fairly simple, as serious systems go.  But
the design and actual implementation of real cipher systems is not
easy.  Perhaps you should try it, so we can see how well *you* do. 

In fact, perhaps you should come up with your own proposal to improve
cryptography, so we can see how well you do at *that*.  Maybe you
should write and publish an article so we can judge that too.  

Clearly you have trouble with the concept of what an "attack" is, and
it has taken you weeks to understand the basic concept of dynamic
cipher-changing, which most readers got in the first or second
posting.  I suggest more study and less ranting.  

Frankly, since your years-ago claim to have a break for my Fenced DES
Cipher broke down in your own failure, you have been hard to live
with.  The reality is that I produced a design which, in the end,
withstood your attacks; I built a cipher which you thought you could
break, but could not.  I'm sure it was very embarrassing for you.  But
everyone makes mistakes, and those of us who speak out are especially
exposed; most of us accept reality and move on.  Get over it.  

---
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, 12 Nov 1999 02:48:38 GMT
From: bryan.olson@uptronics.com
Message-ID: <80fv65$rvt$1@nnrp1.deja.com>
References: <382a5c09.9266545@news.io.com>
Newsgroups: sci.crypt
Lines: 265

Terry Ritter wrote:
> bryan.olson@uptronics.com wrote:
> >Terry Ritter wrote:
> >> Well, in cryptography, there are various kinds of authentication:
> >
> >Glad you're seeing that.
>
> In the rest of the paragraph -- which you did not see fit to include
> here -- I described various types of "authentication."

I deleted the tangent.  There are several neat ways to
do it, and they don't necessarily fall into one
of the types from a list.

[...]
> "Session keys" (more properly called "message keys," in most cases)
> are in fact very close to the negotiation which I have been promoting
> all along.  In my proposal, one end sends a list; the other selects
> from that list, repeatedly, perhaps with every message, much like a
> message key.

O.K. There's our description of the protocol.  I'm
talking about attacks in which the adversary
substitutes his list of cipher for the list one side
sent (More below).

[...]
> In my proposals, it is has been, and still is, unnecessary to
> authenticate the cipher choice.  No authentication mistake is possible
> with respect to cipher choice.  The ciphers themselves must be
> authentic, but that is not a cipher-change protocol issue.

I'm not sure what you mean.  The adversary may modify the
messages that influence the choice of cipher.  It is the
authenticity of these messages that is at issue, and the
handling of these messages constitutes the cipher selection
protocol.  I'll show below why authentication is necessary.

> >Over and over you've stated that the negotiation is
> >secret, protected by a cipher.  When did you note
> >the need for authentication or name a MAC or
> >signature? Now you say it's just like other cipher
> >systems, such as public key ciphers.  Ciphers provide
> >poor authentication, and public key ciphers don't
> >really provide any authentication at all.  It is
> >not the case that your claim of secrecy, protected
> >by a cipher implies authentication.  In fact it
> >implies that you missed the attack.
>
> I have always said that the cipher-change negotiation must occur under
> cipher.  I am guilty of expecting that cipher system to be effective.
> But I missed no attack, because there was and is no attack on the
> cipher-change protocol itself, which is all I have been describing.

So you've described the protocol: "In my proposal, one
end sends a list; the other selects from that list".
You've been clear that when a side sends the list,
such communication is and under a cipher.  Now I'll
describe the attack on a system entirely consistent
with your description.

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
consisting of one cipher he knows to be on Bob's list.
Bob, as the description specifies, selects a cipher
from the list.

So just as you described, the negotiation is protected
by a cipher.  Just as you wrote "In my proposal, one
end sends a list; the other selects from that list".
Thus Fred has achieved the chosen cipher attack, within
the protocol you described.  As you noted, we have to
assume the initial cipher is effective; ciphers provide
privacy and the example above grants that the cipher
is effective.


> You seem to have several big problems here, the first being the
> possibility that I missed something, and so deserve your castigation.

More like: you missed something and so should recognize
it now and fix it.

> Well, I did *not* miss what you think I did, but even if I had, who
> elected you God?  If you had found a factual problem, you could
> present that.  Instead, you cop an attitude and distort reality, both
> of which are way out of line.

I introduced the issue simply as a matter of fact.
Over and over you refused to see it, and acted like
I and others didn't know what we were talking about.


> >> 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."
> >
> >Now you're starting to get it.  This authentication
> >was completely missing from your suggestion before
> >others pointed out the problem.
>
> There was and is no problem, and what was pointed out was wrong.  If
> the public-key certification or message authentication is bad, the
> original security is bad, and there is no protection for the raw
> plaintext that we are trying to protect, so cipher-change negotiation
> is the least of the problems.

As I asked before - if you had message authentication on
the negotiation, please just cite it.  You keep saying
it's protected by a cipher.  Got the privacy; where's
the authentication?

> 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.

But the problem at issue is that the protocol you
described grants the adversary's choice even when we
assume these components are sound, as shown.

> Where did
> *you* ever say that *those* were required?  But they *are* required,
> and you missed those "attacks."  Tsk, tsk.

Yes, the protocol could fail because of one of these
components.  The issue here is protocol failure.


> >Yes, it can be fixed,
> >but the actual protocol design is not the simple
> >exercise you had thought.
>
> The protocol is *just* as simple as I first proposed.  There is
> essentially no protocol there at all:  We just select at random from a
> list.

And now we've seen that this doesn't work well without
the authentication mechanism.

> The design part of this is the construction of a hidden command
> channel behind the plaintext, the various messages and retained state
> required to perform a clean transition, and I believe, the ability to
> withstand message loss without problem.  This does require some
> design, and failure here means we will not change ciphers, or may do
> so in regular ways.

As shown, failure can grant the adversary his choice of
the ciphers, though as I noted in a previous post, the
cipher does have to be from Bob's approved list.

> In other words, the *worst* that can happen from a bad cipher-change
> protocol is that we end up using one cipher repeatedly, which is the
> *normal* situation now.  Failure in the protocol is thus only a
> failure to take advantage of new cipher-change strength, and not an
> introduction of weakness.

Shown false.

[...]
> It was clear enough for almost everyone else who read my proposals.
> Stop pretending that you have contributed something important.  You
> have not.  Stop pretending that I have ignored or dissembled about a
> real problem.  I have not.

It certainly wasn't clear to you.  Even after people
suggested the possibility of the attacker influencing the
cipher, you insisted that the secret negotiation under
a cipher ruled this out.  But look at the example - the
messages are secret under a cipher and the attacker still
gets his choice.  As I wrote the first time I brought
this up:

    Ciphers by themselves offer poor authentication, and
    the authentication of the selection channel is far
    more important than its privacy.  If I can find a way
    to forge, I can get you to use _my_ choice of your
    ciphers.

> As far as I know, the only real problem which came up was the need for
> additional protection for the command channel, beyond that used for
> the plaintext.  That was pointed out by "others," not me.  But that is
> not your "authentication," and it is easily fixed.

And the problem I noted is easily fixed.  Your
persistence in stating that the channel is protected
a cipher and never noting an authentication mechanism
baffles me.


> >The cipher agility of your actual systems is far behind
> >the state of the art.
>
> "Cipher agility" would seem to mean the ability to change ciphers
> quickly.  Any system which can do this is *beyond* the current state
> of the art.  My proposals thus *are* the state of the art in
> non-government cryptography.

But you cited your commercial systems, which have no
cipher agility at all.

[...]
> >Your commercial
> >ciphers contradict such claims.
>
> I'm a little confused here:  Are you saying that I have produced
> ciphers of such complexity that they obviously were not easy to
> design?  Guilty.

No, I'm saying the commercial ciphers you cited are
far behind the state of art in cipher agility.  If you
believe so strongly that protocols should allow many
ciphers, and also that the design is not so hard, why
are they so monolithic?

> Actually, my ciphers are fairly simple, as serious systems go.  But
> the design and actual implementation of real cipher systems is not
> easy.  Perhaps you should try it, so we can see how well *you* do.

That's most of what I do for a living.

[...]
> Frankly, since your years-ago claim to have a break for my Fenced DES
> Cipher broke down in your own failure, you have been hard to live
> with.

When you first wrote that I claimed to "break" Fenced
DES, I immediately corrected you. I called my analysis
successful because it showed your security analysis was
wrong.  I was entirely clear on what my attack did -
and you know it.

> The reality is that I produced a design which, in the end,
> withstood your attacks; I built a cipher which you thought you could
> break, but could not.  I'm sure it was very embarrassing for you.

You produced a defective design, as I showed. How
many times have you written that a block cipher
should simulate a large random permutation?  Now we
know Fenced DES does not do what a block cipher
should. You tried to make my analysis look like
failure by making things up and saying I said them;
you even had quotation marks around claims you
fabricated.  Do you think that by now I've
forgotten that you wrote them and I didn't?

> But
> everyone makes mistakes, and those of us who speak out are especially
> exposed; most of us accept reality and move on.  Get over it.

Me get over it?  I don't think I've brought up
your pathetic dishonesty in years.  You keep
inserting Fenced DES into completely unrelated
discussions so you can once again lie about what
I wrote.

--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: Sat, 13 Nov 1999 01:30:02 GMT
From: ritter@io.com (Terry Ritter)
Message-ID: <382cbf12.6376301@news.io.com>
References: <80fv65$rvt$1@nnrp1.deja.com>
Newsgroups: sci.crypt
Lines: 450


On Fri, 12 Nov 1999 02:48:38 GMT, in <80fv65$rvt$1@nnrp1.deja.com>, in
sci.crypt bryan.olson@uptronics.com wrote:

>Terry Ritter wrote:
>> bryan.olson@uptronics.com wrote:


>[...]
>> In my proposals, it is has been, and still is, unnecessary to
>> authenticate the cipher choice.  No authentication mistake is possible
>> with respect to cipher choice.  The ciphers themselves must be
>> authentic, but that is not a cipher-change protocol issue.
>
>I'm not sure what you mean.  The adversary may modify the
>messages that influence the choice of cipher.  It is the
>authenticity of these messages that is at issue, and the
>handling of these messages constitutes the cipher selection
>protocol.  I'll show below why authentication is necessary.

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 an issue in public-key cryptography which is not
normally present in secret-key cryptography.  

In secret-key cryptography, if more than two users share a key, it is
quite clear that multiple source options exist for any message which
is sent.  This is clear.  The issue of deception, then, is due to
public-key cryptography, and so must be (and generally will be)
handled in any system which uses that technology.  

Having a system where anyone can masquerade as anyone else is simply
insane.  Or perhaps you are assuming that the issue *cannot* be
handled in public-key cryptography, which would be an interesting
result.  

This is not an issue for the cipher-change protocol.  It *is* an issue
which must be considered in every public-key design.


>[...]
>So you've described the protocol: "In my proposal, one
>end sends a list; the other selects from that list".
>You've been clear that when a side sends the list,
>such communication is and under a cipher.  Now I'll
>describe the attack on a system entirely consistent
>with your description.
>
>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
>consisting of one cipher he knows to be on Bob's list.
>Bob, as the description specifies, selects a cipher
>from the list.
>
>So just as you described, the negotiation is protected
>by a cipher.  

While you claim to have assumed that the negotiation is "protected,"
in reality you have not made any such assumption.  Any cipher system
which allows anyone at all to pretend they are the other party to a
particular communication is inherently insecure.  The cipher change
protocol is hardly the issue.   

>Just as you wrote "In my proposal, one
>end sends a list; the other selects from that list".
>Thus Fred has achieved the chosen cipher attack, within
>the protocol you described.  As you noted, we have to
>assume the initial cipher is effective; ciphers provide
>privacy and the example above grants that the cipher
>is effective.

The initial ciphering system was, by your description, remarkably
ineffective.  That seems to be an issue for the cipher system design,
rather than any particular cipher, or any plaintext protocol under the
cipher.  Again, that issue does not come up when we have a single pair
of nodes operating under secret key.  The issue for public-key
cryptography, then, is to provide a protocol which does provide
security.  And when that is provided, the cipher-change protocol I
proposed will be fine, perhaps with some additional protection, which,
as you have previously noted, was suggested by "others."  


>> You seem to have several big problems here, the first being the
>> possibility that I missed something, and so deserve your castigation.
>
>More like: you missed something and so should recognize
>it now and fix it.

No, you found something which is probably well-known in public-key
design, and have attempted to use it to fault a level at which it does
not apply.  


>> Well, I did *not* miss what you think I did, but even if I had, who
>> elected you God?  If you had found a factual problem, you could
>> present that.  Instead, you cop an attitude and distort reality, both
>> of which are way out of line.
>
>I introduced the issue simply as a matter of fact.
>Over and over you refused to see it, and acted like
>I and others didn't know what we were talking about.

Small wonder.


>> >> 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."
>> >
>> >Now you're starting to get it.  This authentication
>> >was completely missing from your suggestion before
>> >others pointed out the problem.
>>
>> There was and is no problem, and what was pointed out was wrong.  If
>> the public-key certification or message authentication is bad, the
>> original security is bad, and there is no protection for the raw
>> plaintext that we are trying to protect, so cipher-change negotiation
>> is the least of the problems.
>
>As I asked before - if you had message authentication on
>the negotiation, please just cite it.  

Message authentication is *not* -- and should not be -- part of the
cipher-change protocol, but I would assume that there would be
error-detection, at least, for the delivered message (including hidden
protocol messages).  That allows us to detect any change in transit.

But that is not your issue.  Your issue is that someone may send a
message which appears to be from our far end, but is not. 

Unfortunately, if that issue is not resolved at a higher level, it
probably will not be resolved by particular plaintexts, except perhaps
when we can say, "remember what we did after that party last spring,"
and then get the right answer.  But even that assumes there no MITM,
the possibility of which must have been eliminated at the higher
level.  Which means no such possibility exists for the cipher-change
protocol.  


>You keep saying
>it's protected by a cipher.  Got the privacy; where's
>the authentication?

Any cipher system which uses ciphers must protect against masquerade.
Obviously.  This is a level above plaintext secrecy, and way above
cipher-change negotiation.  


>> 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.
>
>But the problem at issue is that the protocol you
>described grants the adversary's choice even when we
>assume these components are sound, as shown.

False.  You have assumed an insecure system.  The result is insecure.
Congratulations on your insight.  


>> Where did
>> *you* ever say that *those* were required?  But they *are* required,
>> and you missed those "attacks."  Tsk, tsk.
>
>Yes, the protocol could fail because of one of these
>components.  The issue here is protocol failure.
>
>
>> >Yes, it can be fixed,
>> >but the actual protocol design is not the simple
>> >exercise you had thought.
>>
>> The protocol is *just* as simple as I first proposed.  There is
>> essentially no protocol there at all:  We just select at random from a
>> list.
>
>And now we've seen that this doesn't work well without
>the authentication mechanism.

Now we see that the cipher-change protocol does require that the
cipher system provide security.  Without that, the cipher system
cannot provide the privacy we expect.  


>> The design part of this is the construction of a hidden command
>> channel behind the plaintext, the various messages and retained state
>> required to perform a clean transition, and I believe, the ability to
>> withstand message loss without problem.  This does require some
>> design, and failure here means we will not change ciphers, or may do
>> so in regular ways.
>
>As shown, failure can grant the adversary his choice of
>the ciphers, though as I noted in a previous post, the
>cipher does have to be from Bob's approved list.

As described, no cipher system which allows such action can possibly
be secure or private.  We certainly expect better for our plaintext,
and the cipher-change protocol is just more plaintext.  


>> In other words, the *worst* that can happen from a bad cipher-change
>> protocol is that we end up using one cipher repeatedly, which is the
>> *normal* situation now.  Failure in the protocol is thus only a
>> failure to take advantage of new cipher-change strength, and not an
>> introduction of weakness.
>
>Shown false.

Itself shown false.  


>[...]
>> It was clear enough for almost everyone else who read my proposals.
>> Stop pretending that you have contributed something important.  You
>> have not.  Stop pretending that I have ignored or dissembled about a
>> real problem.  I have not.
>
>It certainly wasn't clear to you.  Even after people
>suggested the possibility of the attacker influencing the
>cipher, you insisted that the secret negotiation under
>a cipher ruled this out.  But look at the example - the
>messages are secret under a cipher and the attacker still
>gets his choice.  As I wrote the first time I brought
>this up:
>
>    Ciphers by themselves offer poor authentication, and
>    the authentication of the selection channel is far
>    more important than its privacy.  If I can find a way
>    to forge, I can get you to use _my_ choice of your
>    ciphers.

As I noted many times, masquerade must be made impossible, and this
actually must be impossible, in any real security system.  Since
public-key technology opens the door, public-key technology is
responsible for somehow closing it.  Only then do we have a secure
cipher, and only then does it support plaintext and plaintext
cipher-change messages.  


>> As far as I know, the only real problem which came up was the need for
>> additional protection for the command channel, beyond that used for
>> the plaintext.  That was pointed out by "others," not me.  But that is
>> not your "authentication," and it is easily fixed.
>
>And the problem I noted is easily fixed.  Your
>persistence in stating that the channel is protected
>a cipher and never noting an authentication mechanism
>baffles me.

Since you ask for a solution this quandary, my guess would be that you
have had little experience with secure system design above the cipher
level.  The minimal discussion of this sort of thing is one of the
problems I have with the conventional crypto references.


>> >The cipher agility of your actual systems is far behind
>> >the state of the art.
>>
>> "Cipher agility" would seem to mean the ability to change ciphers
>> quickly.  Any system which can do this is *beyond* the current state
>> of the art.  My proposals thus *are* the state of the art in
>> non-government cryptography.
>
>But you cited your commercial systems, which have no
>cipher agility at all.

*Of* *course* it is not in my old ciphers:  If my *old* cipher systems
had cipher agility, the cipher-change protocol would hardly be a *new*
idea, now would it?  

On the other hand, it was my experience with those systems which
eventually ripened into my protocols for improved security, which
include frequent cipher-change, many ciphers, and multiciphering as a
matter of course.  


>[...]
>> >Your commercial
>> >ciphers contradict such claims.
>>
>> I'm a little confused here:  Are you saying that I have produced
>> ciphers of such complexity that they obviously were not easy to
>> design?  Guilty.
>
>No, I'm saying the commercial ciphers you cited are
>far behind the state of art in cipher agility.  

Then you have a remarkably strange idea of "cipher agility."  But
apparently you are granting some significant advantage to those
systems which switch between 4 or 5 known ciphers.  This is fine as
far as it goes, but I would like to see at least 100 ciphers, used in
3 independent levels, giving 100**3 = 1,000,000 possible ciphering
processes.  

>If you
>believe so strongly that protocols should allow many
>ciphers, and also that the design is not so hard, why
>are they so monolithic?

Could that be because my ciphers are *old* designs?  


>> Actually, my ciphers are fairly simple, as serious systems go.  But
>> the design and actual implementation of real cipher systems is not
>> easy.  Perhaps you should try it, so we can see how well *you* do.
>
>That's most of what I do for a living.

Odd.  Clearly you don't publish stuff others can use or learn from or
criticize.  And yet *you* obviously love to criticize.  It does seem a
bit one sided.  


>[...]
>> Frankly, since your years-ago claim to have a break for my Fenced DES
>> Cipher broke down in your own failure, you have been hard to live
>> with.
>
>When you first wrote that I claimed to "break" Fenced
>DES, I immediately corrected you. I called my analysis
>successful because it showed your security analysis was
>wrong.  I was entirely clear on what my attack did -
>and you know it.

Well, now, let's just see:

from http://www.io.com/~ritter/NEWS/HUGEBLK.HTM#HB16, near the middle:

"That's as far as I'll take the attack for now.  Perhaps I've 
misunderstood something about the design; please let me know if any
of the steps I've described is impossible.  I'll elaborate if parts of
my explanation are unclear.  If as much as I've described can be done,
I certainly think it's a strong enough toe-hold for the analyst that 
Fenced DES is dead."

from http://www.io.com/~ritter/NEWS/HUGEBLK.HTM#HB16, at the bottom:

"I think I probably have a few numbers wrong in my analysis, but 
not so far wrong as invalidate the attack on Fenced DES." 


So we have "Fenced DES is dead" and the (clearly implied) "I have a
valid attack on Fenced DES."  Both of these seem remarkably clear to
me.  But anyone who wishes to follow your slimy claims and
word-weaseling can do so for themselves:

   http://www.io.com/~ritter/NEWS/HUGEBLK.HTM
   http://www.io.com/~ritter/FENCED.HTM



>> The reality is that I produced a design which, in the end,
>> withstood your attacks; I built a cipher which you thought you could
>> break, but could not.  I'm sure it was very embarrassing for you.
>
>You produced a defective design, as I showed. 

Nonsense.  My cipher did not succumb to an attack which you thought
would work.  Nor is the cipher is weaker because of your attack.  My
cipher won, you lost, it's as simple as that.  

It is true that your approach was unexpected to me.  It is true that
you started out making significant headway.  That you were unable to
finish in fact clarified a major advantage to layered ciphers:  One
layer in a cipher may cause an attacker to "commit" in terms of
available information in a way which then prevents the solution of
another layer.  This is not an error -- that is the way layered
systems work, and understanding this is a step ahead in cipher design.


If it had turned out that the cipher was weaker because of your
attack, then the cipher would have been flawed.  It did not so turn
out.  And while I would include more mixing layers in any new design,
the old design proudly stands as it is.  

Various descriptions of Fenced DES can be found in the Technical
Articles by Ritter section of my pages:

   http://www.io.com/~ritter/#TechnicalArticles


>How
>many times have you written that a block cipher
>should simulate a large random permutation?  

Many times.

>Now we
>know Fenced DES does not do what a block cipher
>should. You 

Any real design is an approximation of the desired goal.  Perhaps it
could be better, but as far as you are concerned, it is more than good
enough.  

>tried to make my analysis look like
>failure by making things up and saying I said them;
>you even had quotation marks around claims you
>fabricated.  Do you think that by now I've
>forgotten that you wrote them and I didn't?

In one case, as I recall, quoted words provided the essence of your
argument and were correct in context.  For anyone to follow your
argument, and see the reasoning beyond your claims, so they could see
how the claims could be refuted, a concise summary was needed.  You
did not provide that.  I did.  I make no apologies for it, nor was I
misrepresenting either your position, or your words.  You're just
whining because the quoted position did in fact represent your
position, and that position was wrong.  

As always, I provide extensive referencing to the original material,
which is available both from me and from independent news sites.  In
context, it should be very clear where the words originate, but if
not, the original message will clear that up absolutely.  If I was
trying to obscure the source material or misstate the reference, I
would hardly make it so very easy to follow the reference back.  


>> But
>> everyone makes mistakes, and those of us who speak out are especially
>> exposed; most of us accept reality and move on.  Get over it.
>
>Me get over it?  I don't think I've brought up
>your pathetic dishonesty in years.  

OK, that's about it.  I don't think I need to hear any more from you.



>You keep
>inserting Fenced DES into completely unrelated
>discussions so you can once again lie about what
>I wrote.

What you wrote is archived on my own site, so I could hardly lie about
it. 

But as far as I know, *you* don't maintain publicly-accessible
archives, and so are free to misrepresent the past with some impunity.
Until someone reminds you of reality, of course.  

---
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: Mon, 15 Nov 1999 01:15:53 GMT
From: bryan.olson@uptronics.com
Message-ID: <80nms7$2ms$1@nnrp1.deja.com>
References: <382cbf12.6376301@news.io.com>
Newsgroups: sci.crypt
Lines: 233

First let me say I'm snipping a lot since this has
gotten very long.  I invite readers to check backwards
for more context, since my interpretation of what is
significant may differ from others.

I see the same point over and over.  Terry Ritter
says that the communications that negotiate the
choice of cipher(s) are under a cipher.  I point
out that ciphers imply secrecy, but not
authentication, and thus the attacker can influence
the choice of cipher.  Here's a sampling:

ritter@io.com (Terry Ritter) wrote:
> sci.crypt bryan.olson@uptronics.com wrote:
> >Terry Ritter wrote:

[Bryan:]
> > It is the
> >authenticity of these messages that is at issue, and the
> >handling of these messages constitutes the cipher selection
> >protocol.  I'll show below why authentication is necessary.
>
> 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.

I suggested an attack that works even given the
communication is under cipher, though I assumed the
cipher protects only the privacy of the messages.
> >[...]
> >So you've described the protocol: "In my proposal, one
> >end sends a list; the other selects from that list".
> >You've been clear that when a side sends the list,
> >such communication is and under a cipher.  Now I'll
> >describe the attack on a system entirely consistent
> >with your description.
> >
> >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
> >consisting of one cipher he knows to be on Bob's list.
> >Bob, as the description specifies, selects a cipher
> >from the list.
> >
> >So just as you described, the negotiation is protected
> >by a cipher.
>
> While you claim to have assumed that the negotiation is "protected,"
> in reality you have not made any such assumption.  Any cipher system
> which allows anyone at all to pretend they are the other party to a
> particular communication is inherently insecure.  The cipher change
> protocol is hardly the issue.

[...]
> The initial ciphering system was, by your description, remarkably
> ineffective.

Obviously it was effective for authentication, but I
assumed it was effective for privacy.

[...]
> Message authentication is *not* -- and should not be -- part of the
> cipher-change protocol, but I would assume that there would be
> error-detection, at least, for the delivered message (including hidden
> protocol messages).  That allows us to detect any change in transit.
>
> But that is not your issue.  Your issue is that someone may send a
> message which appears to be from our far end, but is not.

Exactly!  And specifically, that your statement
of the design that has these early messages under
a cipher does not imply protection against such an
attack.

Anyway, my references are clear that a "cipher"
provides secrecy but does not imply authentication.
I think Ritter's own crypto glossary agrees.
See: http://www.io.com/~ritter/GLOSSARY.HTM


On other matters:
[...]
> >But you cited your commercial systems, which have no
> >cipher agility at all.
>
> *Of* *course* it is not in my old ciphers:  If my *old* cipher systems
> had cipher agility, the cipher-change protocol would hardly be a *new*
> idea, now would it?

Hey, you cited these.  They are poor examples.

[...]
> >> Actually, my ciphers are fairly simple, as serious systems go.  But
> >> the design and actual implementation of real cipher systems is not
> >> easy.  Perhaps you should try it, so we can see how well *you* do.
> >
> >That's most of what I do for a living.
>
> Odd.  Clearly you don't publish stuff others can use or learn from or
> criticize.  And yet *you* obviously love to criticize.  It does seem a
> bit one sided.

There's plenty of my stuff for you to criticize. I've
even proposed solutions to problems you posed.  You
have historically ignored my posts unless they were
about your designs.



> >[...]
> >> Frankly, since your years-ago claim to have a break for my Fenced
DES
> >> Cipher broke down in your own failure, you have been hard to live
> >> with.
> >
> >When you first wrote that I claimed to "break" Fenced
> >DES, I immediately corrected you. I called my analysis
> >successful because it showed your security analysis was
> >wrong.  I was entirely clear on what my attack did -
> >and you know it.
>
> Well, now, let's just see:

And below we do see - that you cannot find anything
where I say my attack constituted a break.

> from http://www.io.com/~ritter/NEWS/HUGEBLK.HTM#HB16, near the middle:
>
> "That's as far as I'll take the attack for now.  Perhaps I've
> misunderstood something about the design; please let me know if any
> of the steps I've described is impossible.  I'll elaborate if parts of
> my explanation are unclear.  If as much as I've described can be done,
> I certainly think it's a strong enough toe-hold for the analyst that
> Fenced DES is dead."
>
> from http://www.io.com/~ritter/NEWS/HUGEBLK.HTM#HB16, at the bottom:
>
> "I think I probably have a few numbers wrong in my analysis, but
> not so far wrong as invalidate the attack on Fenced DES."
>
> So we have "Fenced DES is dead" and the (clearly implied) "I have a
> valid attack on Fenced DES."  Both of these seem remarkably clear to
> me.  But anyone who wishes to follow your slimy claims and
> word-weaseling can do so for themselves:
>
>    http://www.io.com/~ritter/NEWS/HUGEBLK.HTM
>    http://www.io.com/~ritter/FENCED.HTM

And my posts explain exactly what the attack does, and
never do I say what you claimed.

[...]
> >You produced a defective design, as I showed.
>
> Nonsense.  My cipher did not succumb to an attack which you thought
> would work.  Nor is the cipher is weaker because of your attack.  My
> cipher won, you lost, it's as simple as that.
>
> It is true that your approach was unexpected to me.  It is true that
> you started out making significant headway.  That you were unable to
> finish in fact clarified a major advantage to layered ciphers:  One
> layer in a cipher may cause an attacker to "commit" in terms of
> available information in a way which then prevents the solution of
> another layer.  This is not an error -- that is the way layered
> systems work, and understanding this is a step ahead in cipher design.
>
> If it had turned out that the cipher was weaker because of your
> attack, then the cipher would have been flawed.  It did not so turn
> out.  And while I would include more mixing layers in any new design,
> the old design proudly stands as it is.

[...]
> >tried to make my analysis look like
> >failure by making things up and saying I said them;
> >you even had quotation marks around claims you
> >fabricated.  Do you think that by now I've
> >forgotten that you wrote them and I didn't?
>
> In one case, as I recall, quoted words provided the essence of your
> argument and were correct in context.

No they were not, and as I asked at the time, what
do you think quotation marks mean?

[...]
> >  Get over it.
> >
> >Me get over it?  I don't think I've brought up
> >your pathetic dishonesty in years.
>
> OK, that's about it.  I don't think I need to hear any more from you.

Do you recall the last time I introduced Fenced DES
into a discussion?  It was when John Savard came up
with a similar design. I attacked his design and
wrote what I believe is a completely fair note:

| The structure of the cipher is very similar to
| a couple that Terry Ritter suggested.  He calls his
| design "Fenced DES".  The analysis above is similar
| to work I did on one of Terry's ciphers.  He agreed
| the design had a problem but thought I oversold my
| result.

http://x23.deja.com/getdoc.xp?AN=372605719&search=thread&CONTEXT=9426263
69.664076315&hitnum=2


> >You keep
> >inserting Fenced DES into completely unrelated
> >discussions so you can once again lie about what
> >I wrote.
>
> What you wrote is archived on my own site, so I could hardly lie about
> it.

Yes you can; it's just weird.  You're trying to
bluff about your up-cards.  I immediately disagreed
when you first wrote that I claimed to break Fenced
DES.  You still say it, and then support it with
quotes where I never claimed what you said.  "Toe-
hold for analysis" sure.  Do I think the design is
dead?  Yes I do.  I didn't say what you claim; you
know it; I know it; and anyone who checks an archive
knows it.


--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: Mon, 1 Nov 1999 17:15:44 GMT
From: sjmz@hplb.hpl.hp.com (Stefek Zaba)
Message-ID: <FKJ3y9.E60@hplb.hpl.hp.com>
References: <7v4sh2$ps2$1@blowfish.isaac.cs.berkeley.edu>
Newsgroups: sci.crypt
Lines: 59

In sci.crypt, David Wagner (daw@blowfish.isaac.cs.berkeley.edu) wrote:

> The problem is that there are severe attacks on the SSL 2.0 protocol,
> due to the non-cryptographic nature of the negotiation protocol.  For
> instance, an active attacker (a "man-in-the-middle") can edit Alice's
> list of supported ciphers, removing all but the weakest one supported
> by both endpoints (e.g., RC4-40-export); then Bob will be forced to
> pick that weak one, and both ends will use the weak cipher.  Even if
> both endpoints support a stronger cipher, they won't know that they've
> been silently forced down to "least-common-denominator security".

These flaws certainly exist. That they've been found, broadly addressed
in the SSL3.0 spec and further nailed down in TLS1.0 is a tribute to the
open review process and to the work of many reviewers, including one
D. Wagner :-)

The resulting cipher negotiation process is, while not "minimal", pretty
small - it passes the "back-of-the-envelope" test, and manages to define
 * a common process for establishing a "master secret" known to both parties,
   whose detailed establishment depends on the particular key agreement
   protocol but whose outcome is common;
 * a "key stretching" function used to derive session keys, IVs, and MAC
   values for each of the bulk ciphers and MACs

The common mechanisms are designed "almost once", by which I mean that they
are *not* reinvented for each new ciphersuite, but at worst once for a
family of key establishment protocol (RSA, signed DH, anonymous DH), with
a common key-stretching algorithm. Doing it right once removes many potential
sources of error. The ciphersuite negotiation has been simplified from the
SSL2.0 days: it's now as brutal as: initiator (client) sends ordered list 
(which, to David W's point later in the message excerpted above, had better
contain ONLY algorithms the client considers adequate for its interaction);
responder (server) picks exactly one, or aborts. There is *no* renegotiation
or independent negotiation of particular attributes - cihpersuites come as
a particular package of <key-agreement, bulk-cipher, MAC>. And the
negotiation messages are themselves MAC'ed, defeating the simple active
attack which SSLv2 was open to. Protection against protocol version rollback
attack is also incorporated.

Has it taken several iterations to define a robust negotiation protocol? Yes.
(Apples-to-oranges comparison follows) Has it taken as much effort as has
gone into even one AES candidate? I think not. One further simplification
available to TLS and not to modem or PPP negotiations is that TLS/SSL can
afford to refuse - rather than keep trying to find *some* ciphersuite they
agree on (like modems going back through every ITU standard and bis, ter
revision :-), they can - nay, the language of the TLS RFC encourages them to
- throw up their little cyberhands in horror shouting "unclean! unclean!".
Implementations still need to take care (as noted in David W's and Bruce S's
1996 SSL3.0 analysis paper) not to afford an attacker an abundance of matter
derived closely from the master_secret, or to allow a "large" number of
half-completed protocol runs which may signify an attempted interleaving
attack - but the protection afforded by conformant TLS1.0 implementations,
*including* the ciphersuite negotiations, is far from negligible.

Now, if Vernon S and/or David W want to lay into the concept of cipher
negotiation using TLS1.0 as the "standard of practice", I for one would
be most interested in their enlightenment...

Cheers, Stefek


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Tue, 02 Nov 1999 15:51:58 GMT
From: dianelos@tecapro.com
Message-ID: <7vn1as$2s0$1@nnrp1.deja.com>
References: <FKJ3y9.E60@hplb.hpl.hp.com>
Newsgroups: sci.crypt
Lines: 25

In article <FKJ3y9.E60@hplb.hpl.hp.com>,
  sjmz@hplb.hpl.hp.com (Stefek Zaba) wrote:

>The ciphersuite negotiation has been simplified from the
>SSL2.0 days: it's now as brutal as: initiator (client) sends ordered
>list  (which, to David W's point later in the message excerpted above,
>had better contain ONLY algorithms the client considers adequate for
>its interaction); responder (server) picks exactly one, or aborts.
>There is *no* renegotiation or independent negotiation of particular
>attributes - cihpersuites come as a particular package of <key-
>agreement, bulk-cipher, MAC>. And the negotiation messages are
>themselves MAC'ed, defeating the simple active attack which SSLv2 was
>open to. Protection against protocol version rollback attack is also
>incorporated.

In another message (see:
http://www.deja.com/threadmsg_ct.xp?AN=540914195" ) I suggested to send
a list of only *one* ciphersuite, i.e. not to send a list at all. 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.


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, 02 Nov 1999 18:56:23 GMT
From: dscott@networkusa.net (SCOTT19U.ZIP_GUY)
Message-ID: <7vn8k7$1svm$1@news.gate.net>
References: <381F1625.E61A3C7F@aspi.net>
   <7vn1as$2s0$1@nnrp1.deja.com>
Newsgroups: sci.crypt
Lines: 59

In article <381F1625.E61A3C7F@aspi.net>, "Trevor Jackson, III" <fullmoon@aspi.net> wrote:
>dianelos@tecapro.com wrote:
>
>> In article <FKJ3y9.E60@hplb.hpl.hp.com>,
>>   sjmz@hplb.hpl.hp.com (Stefek Zaba) wrote:
>>
>> >The ciphersuite negotiation has been simplified from the
>> >SSL2.0 days: it's now as brutal as: initiator (client) sends ordered
>> >list  (which, to David W's point later in the message excerpted above,
>> >had better contain ONLY algorithms the client considers adequate for
>> >its interaction); responder (server) picks exactly one, or aborts.
>> >There is *no* renegotiation or independent negotiation of particular
>> >attributes - cihpersuites come as a particular package of <key-
>> >agreement, bulk-cipher, MAC>. And the negotiation messages are
>> >themselves MAC'ed, defeating the simple active attack which SSLv2 was
>> >open to. Protection against protocol version rollback attack is also
>> >incorporated.
>>
>> In another message (see:
>> http://www.deja.com/threadmsg_ct.xp?AN=540914195" ) I suggested to send
>> a list of only *one* ciphersuite, i.e. not to send a list at all. 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.
>
>Why do you care?  If you choose a set of ciphers in which you trust you
>*are* defining how to encrypt your information.
>
>If you are stuck at 3DES and the other person insists upon AES_1, will you
>prefer to not communicate rather than communicate with a cipher other than
>your favorite?
>
>Do you also have a preference for particular keys?
>
>

  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.

 


David A. Scott
--

SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
                    
Scott famous encryption website NOT FOR WIMPS
http://members.xoom.com/ecil/index.htm

Scott rejected paper for the ACM
http://members.xoom.com/ecil/dspaper.htm

Scott famous Compression Page WIMPS allowed
http://members.xoom.com/ecil/compress.htm

**NOTE EMAIL address is for SPAMERS***


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Tue, 02 Nov 1999 19:32:32 -0500
From: "Trevor Jackson, III" <fullmoon@aspi.net>
Message-ID: <381F82A0.BF3299C3@aspi.net>
References: <7vn8k7$1svm$1@news.gate.net>
Newsgroups: sci.crypt
Lines: 50

SCOTT19U.ZIP_GUY wrote:

> In article <381F1625.E61A3C7F@aspi.net>, "Trevor Jackson, III" <fullmoon@aspi.net> wrote:
> >dianelos@tecapro.com wrote:
> >
> >> In article <FKJ3y9.E60@hplb.hpl.hp.com>,
> >>   sjmz@hplb.hpl.hp.com (Stefek Zaba) wrote:
> >>
> >> >The ciphersuite negotiation has been simplified from the
> >> >SSL2.0 days: it's now as brutal as: initiator (client) sends ordered
> >> >list  (which, to David W's point later in the message excerpted above,
> >> >had better contain ONLY algorithms the client considers adequate for
> >> >its interaction); responder (server) picks exactly one, or aborts.
> >> >There is *no* renegotiation or independent negotiation of particular
> >> >attributes - cihpersuites come as a particular package of <key-
> >> >agreement, bulk-cipher, MAC>. And the negotiation messages are
> >> >themselves MAC'ed, defeating the simple active attack which SSLv2 was
> >> >open to. Protection against protocol version rollback attack is also
> >> >incorporated.
> >>
> >> In another message (see:
> >> http://www.deja.com/threadmsg_ct.xp?AN=540914195" ) I suggested to send
> >> a list of only *one* ciphersuite, i.e. not to send a list at all. 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.
> >
> >Why do you care?  If you choose a set of ciphers in which you trust you
> >*are* defining how to encrypt your information.
> >
> >If you are stuck at 3DES and the other person insists upon AES_1, will you
> >prefer to not communicate rather than communicate with a cipher other than
> >your favorite?
> >
> >Do you also have a preference for particular keys?
> >
> >
>
>   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.

I believe that cipher stacking or layering is an appropriate solution to this kind of
dispute.  But 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.  In order to do
so I have to make a new selection from within the intersection of  the cipher I'm willing or
able to use and the cipher's my respondent is willing to use.

Layering helps by preventing arguments, but it still leaves the original issue open



Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Tue, 02 Nov 1999 23:13:47 GMT
From: dianelos@tecapro.com
Message-ID: <7vnr77$ncc$1@nnrp1.deja.com>
References: <381F1625.E61A3C7F@aspi.net>
   <7vn1as$2s0$1@nnrp1.deja.com>
Newsgroups: sci.crypt
Lines: 48

In article <381F1625.E61A3C7F@aspi.net>,
  "Trevor Jackson, III" <fullmoon@aspi.net> wrote:
> dianelos@tecapro.com wrote:

>>In another message (see:
>>http://www.deja.com/threadmsg_ct.xp?AN=540914195" ) I suggested to
>>send a list of only *one* ciphersuite, i.e. not to send a list at
>>all. 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.
>
>Why do you care?  If you choose a set of ciphers in which you trust you
>*are* defining how to encrypt your information.

I see your point, but this wouldn't work with email for example. Here
the choice of cipher must be made by me alone.

>If you are stuck at 3DES and the other person insists upon AES_1, will
>you prefer to not communicate rather than communicate with a cipher
>other than your favorite?

Well, if I trust 3DES and don't trust AES1 then I should be able
encrypt my messages with 3DES only. Communication will always be
possible if, as I suggested, there exists a public repository of
ciphersuits where executable code or source code can be downloaded.
This repository must be super-certified; can include recommendations by
cryptologists; must include code in Java but can also include code
optimized for different operating environments, etc.

The big advantage here is simplicity and flexibility. I don't have to
define a complicated ciphersuite negotiating protocol today; in the
future this protocol itself may prove to have been a bad choice. Having
to change a standard protocol that negotiates the ciphersuite is almost
as costly as changing a standard ciphersuite. By appending to the data
a pointer to the method that must be used to process them I buy
insurance for the long run. We still have a critical component though:
the certification of the ciphersuites.

> Do you also have a preference for particular keys?

Actually I might: several ciphers have a handful of "weak" keys; I may
be paranoid and want to use a key exchange protocol that checks for
them.


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: Wed, 03 Nov 1999 17:34:38 -0500
From: "Trevor Jackson, III" <fullmoon@aspi.net>
Message-ID: <3820B87E.6EACA1DD@aspi.net>
References: <7vpebt$qsa$1@nnrp1.deja.com>
   <381F84DD.ED21F158@aspi.net>
   <7vnr77$ncc$1@nnrp1.deja.com>
Newsgroups: sci.crypt
Lines: 146

dianelos@tecapro.com wrote:

> In article <381F84DD.ED21F158@aspi.net>,
>   "Trevor Jackson, III" <fullmoon@aspi.net> wrote:
> > dianelos@tecapro.com wrote:
> >> I see your point, but this wouldn't work with email for example. Here
> >> the choice of cipher must be made by me alone.
> >
> >How so?  In a PK environment one would publish one's cipher set along
> >with one's public key.  It's still the intersection of the cipher sets
> >of the two parties.
>
> Let's see: Normally, I compose the message and encrypt it off-line,
> then I connect to Internet and send all my mail in batch mode.

Good, that means you already have obtained the public keys of all of the
recipients of your messages.  When you got their public keys you also got
their supported cipher list.

> Oh, I
> suppose I could encrypt it after connecting to the Internet and after
> downloading a certified set of each addressee's set of ciphers and
> choosing a cipher for each one.

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.

> I suppose this can be done, but it
> looks complicated. What if none of the ciphers in one addresse's set is
> trusted by me?

Then you cannot communicate.  This problem is not created by having multiple
ciphers supported at each end.  This problem is created by having users
insist upon particular ciphers.  Note that if you insist upon ciphers {A1,
A2, A3 } and your respondent insists upon { B1, B2 }, they you can still
communicate securely in both your opinions, by using two ciphers, one of
yours and one of his.  Both of you will believe that the doubly encuphered
messages are secure.

If you _lack_ the cipher agility just described, you cannot ever convince
both participants that their messages are secure.


> What if my addressee does not have public keys?

Then, as now, you would need to obtain a secret key from him.  With the
secret key comes the set of his ciphers.

> What if my addressee uses a different PK protocol?

Then you can't talk anyway.

> What if I want to send one
> message to 100 destinations?

You have to encipher multiple times anyway because using the same key for
broadcast messages creates an opportunity for attack.  I'm not a protocol
expert, barely even a student.  But I know there's weakness in reusing
message keys whether serially or in parallel.

> More importantly: what if the standard (or widely used) PK system
> suffers a catastrophic failure in the future?

Yeah, what if?  The ensuing disturbance would have nothing to do with cipher
agility.

> This is more probable to
> happen with PK than with a symmetric cipher. Therefore it is even more
> important to be able to change PK environments.

Probably true.  But AFAIK there is no reason to believe we can create "many"
PK systems, whereas there is good reason to believe that we can create
"many" symmetric ciphers.

>
>
> (...)
> >I would fear such a central repository.  It adds a third party to the
> >system, and that third party is going to be vulnerable to attacks that
> >the original parties would not.
>
> A third party is not necessary if a group of people stick to a few
> ciphersuites. Then I just have to name one key exchange protocol (or
> several to be executed in parallel) and one cipher (or several to be
> executed in series). Also consider that a PK environment normally
> involves third parties too. In a networked world third parties are a
> fact of life.

Sure.  As a key respository.  Not as a repository for security
implementations.  The two aren;t anywhere near comparable.

>
>
> Now, I don't claim that my suggestion is the best solution or that
> public servers are an indispensable component to any solution. What I
> do claim is that it is worthwhile to think about the feasibility of a
> "protocol of protocols". I want to be able in the future to dynamically
> change ciphersuites as a defense against unforeseen attacks and
> catastrophic failures. The Y2K error is so costly because so many
> programs all around the world are using one single, stupid (and de
> facto standard) data structure. We should learn from that experience
> and try to avoid a situation in the future where somebody discovers
> that a standardized cryptographic primitive that forms part of almost
> all security software is useless. In other words let us define a high
> level standard that explains how to change a low level standard.

An extremely ambitious goal.

>
>
> >I also have an aversion to downloading security code on demand.  It
> >appears to me to be the inverse of a trojan.  instead of an opponent
> >penetrating my firewalls, security, permissions, etc. by subterfuge. I
> >actually invite them in by regularly replacing the critical security
> components of my infrastructure from an external source.
>
> Trojan horses are a huge problem but I wonder if a few trusted central
> servers of certified code would not work *against* Trojan attacks. In
> my original message I suggested that you should be able to instruct
> your "code downloader" to only fetch code trusted by you. For example,
> you could instruct it to only download code certified by NIST or, if
> you prefer, by Schneier as well as by Shamir. Also *all* ciphersuites
> in the central servers should be in source code too - a big problem
> (but not insurmountable) for Trojan Horse designers. Finally, loading
> new code can be a fully manual process.
>
> Anyway, I see what you mean. In many cases you would never want to use
> the centralized code servers but you would be glad they are there just
> in case something extraordinary happens. For example: many applications
> will happily use the AES main winner as the only symmetric cipher
> primitive. Other more conservative applications may include code for
> both the AES-1 and the AES-2 winner (assuming NIST does choose two
> winners), just in case that something very bad happened to AES-1. Now
> you may argue that it is highly unlikely, but it is still realistically
> possible that both AES-1 and AES-2 suffer a sudden catastrophic failure
> in 50 years time. Then you will want to be able to instruct your
> application to download the new cipher X from a centralized server - or
> at least be able to introduce cipher X directly into the application.
> Let us trust in standards, but let us also be prepared.
>
> 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: 23 Oct 1999 23:29:33 -0600
From: vjs@calcite.rhyolite.com (Vernon Schryver)
Message-ID: <7uu5ft$f7v$1@calcite.rhyolite.com>
References: <3812005b.8360995@news.io.com>
Newsgroups: sci.crypt
Lines: 162

In article <3812005b.8360995@news.io.com>, Terry Ritter <ritter@io.com> wrote:

> ...
>>How can you point to modems as a good example of the wonders of negotiating
>>protocols?  I think the politics and sausage warning applies.
>
>I think the real world applies:  We have such modems.  We use them.
>They work.  End of story.

That might be the end of a fairy tale or a nightmare, but I
thought you were talking about engineering.

Modems do not work all of the time.  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.


> ...
>I doubt I implied that modem negotiation is "clean."  But it *is*
>"background," and it *is* negotiation (both sides participate in the
>final result), and it *is* "real world" -- it generally works in
>practice.

The "it generally works in practice" can be said about PPP, only more so.
And again, who wants a cipher negotiating protocol that "generally
works in practice"?

Only salescritters or people with no technical knowledge can claim that
either PPP or modems are examples that could cause a working engineer to
be enthusaistic about negotiating ciphers.  Sane, technically inclined
people who look at modems, PPP, or any other "standardized", dynamic
negotiating network protocol must be very skeptical of the idea.

>Cipher negotiation can be far cleaner -- provided a single selection
>mechanism is standardized.  If not, then we may see the same sort of
>ad hoc stuff we saw with modems.  

But "ad hoc" modem negotiation was your counter to the 10+ years of
public experience with offically standardized, carefully architected,
designed and tested PPP.

As for "can be cleaner...", those words echo what was said about
standardizing the negotiations between wide area routers in the leased-line
IETF WG that was merged with the SLIP-replacment WG in about 1987 to form
what is now the PPP working group.  I think users are better served by
the result (PPP) than by the old proprietary protocols, but no one can
call PPP clean--at least no one honest and with a clue.

Maybe Communism will work the next time it's tried too.
But my money is on standards committees behaving like committees.


> ...
>I would say, "let's not do it like PPP."

Exactly how would you do that?  The problems with PPP negotiating are not
any single technical issue, but the inevitable morass that comes with
complicated network stuff in the best possible circumstances.


>>I don't understand the "background" bit about cipher negotiating, since
>>for all of modems, PPP, and ciphers, until the parties agree, the main
>>event cannot work, and that's not exactly "background"
>
>Indeed, you do not understand the term "background," presumably
>because you have not done your homework.  I suggest actually reading
>messages before disparaging their ideas.  You might also look into my
>recent article in IEEE Computer:
>
>   http://www.io.com/~ritter/ARTS/R8INTW1.PDF
>
>or the previous discussion, which I have archived on my pages:
>
>   http://www.io.com/~ritter/NEWS4/LIMCRYPT.HTM
>
>Here, "background" approximately means "not apparent to the user."
>That is just what modem negotiation is about, although we may hear
>modems, and need not hear or see cipher negotiation.  
>
>To start any conversation in cipher, it is currently necessary to
>acquire common keys.  Everyone understands this.  So everyone should
>be well prepared to understand that we can *also* acquire a cipher
>name, or even a cipher itself, in the same way, through the same
>channel.  This is not a big conceptual leap.
>
>Once we have a conversation in cipher, we can assign part of it to a
>"control channel," where negotiation takes place (generally, although
>not necessarily) hidden from the user.  That would be "background"
>cipher negotiation.  
>
>Because the need is to change ciphers frequently, the desired
>negotiation process is not one-time at the start, but rather, a
>frequent or continuous process in different messages or sessions.  

Before repeating your old line yet again, you should do your own homework,
which is to actually investigate at least one real, deployed network
protocol that does the negotiating of the sort that you say is so easy.
And by "investigate," I don't mean merely read some user documentation or
repeat your dreams of how things would turn out if only people would listen
to you.

As for your "background" stuff--take your own advice and read what you
are responding to before pontificating about homework.  No matter on what
"ground" the cipher negotiating is done, once the sender decides to switch
to another cipher, data must soon stop flowing until the new cipher has
been negotiated.  You can call the cipher negotiating "background" if you
want, but when the user-data stops flowing the notion is ... strained.
When one party decides a new cipher is required, you must fairly soon
either use a new cipher or stop moving data.  Otherwise think what a bad
guy could do.


>>...well, not exactly
>>for PPP, which, for example has the CCP (comopression) which is supposed to
>>be negotiated in parallel with the main NCP's, which can start sending
>>data before CCP converges.  That is what the PPP implementations I've
>>worked on do, but plenty of others don't.  Again, theory vs. practice.
>
>I am a working engineer. 
>
>Theory vs. practice.

Shouldn't a working engineer know about the common, existing, widely
*practiced* examples of the thing he is proposing?  SSL is a closer example
than modems or PPP.  (I picked PPP because I know more about PPP than
SSL.)  Do you care to say something about SSL that will convince people
that negotiating ciphers is a great idea?


> ...
>Well, since you are a "real designer," I'll just let you wander on in
>your monomanical tirade, while I suggest that we *not* do things like
>PPP.  

The biggest trouble with PPP is that it is a standardized network thing.
Network things that are standards are always at least 95% politics, by
which I mean everything that comes with design by committee and approval
by standards committees.  Negotiating ciphers such as you have proposed
would necessarily be network things.  Your repeated appeals to the word
"standardized" mean that they would enjoy the attentions of standards
committees.

> ...
>There is no other possibility, unless you wish to depend upon the
>strength of a cipher which explicitly HAS *no* known or guaranteed
>strength.  Not having strength is not a trivial detail, this is the
>essence of the reason for using a cipher.  

Before complaining of my monomanical tirades, you ought to notice a few
of your own ...yes, you and others have pointed out with endless boring
repetitions, the truth of the premise of that paragraph, that we have no
guarantees, measurements, or even definitions of the true, theoretical
strength of any practical cipher.  However, as others have tirelessly
responded, your claim that automated switching among lots of ciphers is
the only alternative to a falling sky does not follow from that premise.

>The ability to change ciphers offers each of us the power to choose
>what cipher we want to use.  This means no government organization is
>edicting our use, or forcing it through market pressure.  We get to
>choose what to use, and what not to use, and to change our minds on a
>daily basis.  That is not a trivial advantage.

Yes, it's good to be able to change ciphers.  That does not imply anything
one way or another about computers negotiating ciphers in real time.


>>Other good (i.e. bad) examples of the inevitable perils of negotiating
>>besides modems and PPP include TCP and HTTP.  Most don't know about
>>about MSS/PMTU or window size problems, but most people have seen
>>"broken" web pages that don't work on some versons of some browsers.
>
>Gosh, I think we'll just have to have a complete specification.

The equivalent failure mode of negotiated ciphers for a broken web page
would be picking ROT26 as the cipher right after ROT13.  Or one of
the SSL security bugs.

The world is full of self-described architects, designers, and inventors.
Most are frauds who invent only self-delusions, hot air, snake oil, and
promises to finally build a perptual motion machine that will work this
time, (and help patent attourneys make the payments on their Mercedes.)
The real architects, designers, and inventors not only desgin and invent,
but also build real implementations that are useful in real life.  So when
will we see the implementation of negotiated/varying ciphers that you are
building?


Vernon Schryver    vjs@rhyolite.com


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Sun, 24 Oct 1999 08:53:09 GMT
From: ritter@io.com (Terry Ritter)
Message-ID: <3812c8b2.9444970@news.io.com>
References: <7uu5ft$f7v$1@calcite.rhyolite.com>
Newsgroups: sci.crypt
Lines: 398


On 23 Oct 1999 23:29:33 -0600, in <7uu5ft$f7v$1@calcite.rhyolite.com>,
in sci.crypt vjs@calcite.rhyolite.com (Vernon Schryver) wrote:

>In article <3812005b.8360995@news.io.com>, Terry Ritter <ritter@io.com> wrote:
>
>> ...
>>>How can you point to modems as a good example of the wonders of negotiating
>>>protocols?  I think the politics and sausage warning applies.
>>
>>I think the real world applies:  We have such modems.  We use them.
>>They work.  End of story.
>
>That might be the end of a fairy tale or a nightmare, but I
>thought you were talking about engineering.
>
>Modems do not work all of the time.  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.

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.  

Cipher negotiation is not the same situation as modem negotiation.
Since modem negotiation is in fact used in practice to make dynamic
connection-by-connection negotiated decisions, it shows that this is
in fact practical in deployed systems.


>> ...
>>I doubt I implied that modem negotiation is "clean."  But it *is*
>>"background," and it *is* negotiation (both sides participate in the
>>final result), and it *is* "real world" -- it generally works in
>>practice.
>
>The "it generally works in practice" can be said about PPP, only more so.
>And again, who wants a cipher negotiating protocol that "generally
>works in practice"?

PPP is not cipher negotiation.


>Only salescritters or people with no technical knowledge can claim that
>either PPP or modems are examples that could cause a working engineer to
>be enthusaistic about negotiating ciphers.  Sane, technically inclined
>people who look at modems, PPP, or any other "standardized", dynamic
>negotiating network protocol must be very skeptical of the idea.

Just what is it that you don't get about requesting a cipher, then
receiving an answer, yes, no, or a suggested alternative, all of which
occurs in the error-corrected data?  It is fine to be wairy of new
ideas, but this seems somewhat OTT.


>>Cipher negotiation can be far cleaner -- provided a single selection
>>mechanism is standardized.  If not, then we may see the same sort of
>>ad hoc stuff we saw with modems.  
>
>But "ad hoc" modem negotiation was your counter to the 10+ years of
>public experience with offically standardized, carefully architected,
>designed and tested PPP.

The whole basis for cipher selection is very clean.


>As for "can be cleaner...", those words echo what was said about
>standardizing the negotiations between wide area routers in the leased-line
>IETF WG that was merged with the SLIP-replacment WG in about 1987 to form
>what is now the PPP working group.  I think users are better served by
>the result (PPP) than by the old proprietary protocols, but no one can
>call PPP clean--at least no one honest and with a clue.
>
>Maybe Communism will work the next time it's tried too.
>But my money is on standards committees behaving like committees.

And just what standards committee would that be, exactly?


>> ...
>>I would say, "let's not do it like PPP."
>
>Exactly how would you do that?  The problems with PPP negotiating are not
>any single technical issue, but the inevitable morass that comes with
>complicated network stuff in the best possible circumstances.

Negotiating a cipher can be and should be distinct from using any
particular cipher.  This is not a complicated network stuff, but a
simple selection protocol quite comparable to what two people would do
if they were discussing which cipher to use on the phone.  


>>>I don't understand the "background" bit about cipher negotiating, since
>>>for all of modems, PPP, and ciphers, until the parties agree, the main
>>>event cannot work, and that's not exactly "background"
>>
>>Indeed, you do not understand the term "background," presumably
>>because you have not done your homework.  I suggest actually reading
>>messages before disparaging their ideas.  You might also look into my
>>recent article in IEEE Computer:
>>
>>   http://www.io.com/~ritter/ARTS/R8INTW1.PDF
>>
>>or the previous discussion, which I have archived on my pages:
>>
>>   http://www.io.com/~ritter/NEWS4/LIMCRYPT.HTM
>>
>>Here, "background" approximately means "not apparent to the user."
>>That is just what modem negotiation is about, although we may hear
>>modems, and need not hear or see cipher negotiation.  
>>
>>To start any conversation in cipher, it is currently necessary to
>>acquire common keys.  Everyone understands this.  So everyone should
>>be well prepared to understand that we can *also* acquire a cipher
>>name, or even a cipher itself, in the same way, through the same
>>channel.  This is not a big conceptual leap.
>>
>>Once we have a conversation in cipher, we can assign part of it to a
>>"control channel," where negotiation takes place (generally, although
>>not necessarily) hidden from the user.  That would be "background"
>>cipher negotiation.  
>>
>>Because the need is to change ciphers frequently, the desired
>>negotiation process is not one-time at the start, but rather, a
>>frequent or continuous process in different messages or sessions.  
>
>Before repeating your old line yet again, you should do your own homework,
>which is to actually investigate at least one real, deployed network
>protocol that does the negotiating of the sort that you say is so easy.
>And by "investigate," I don't mean merely read some user documentation or
>repeat your dreams of how things would turn out if only people would listen
>to you.

I have presented the example that modems do in fact in practice
negotiate their state, today, in mass fielded systems.  I am sorry if
you have trouble with your modems, but I have used modems from home
since the early 80's, we typically still do use modems from home
several times a day, and considering that they are working on lines
designed for voice and not data, they generally work well, and in fact
much better than they used to.  


>As for your "background" stuff--take your own advice and read what you
>are responding to before pontificating about homework.  No matter on what
>"ground" the cipher negotiating is done, once the sender decides to switch
>to another cipher, data must soon stop flowing until the new cipher has
>been negotiated.  

Clearly, that is the wrong way to do it.  

The right way to do it is to come to a decision, and only then change
the cipher.  Until a decision is made, the data continue to flow under
the old cipher.  

>You can call the cipher negotiating "background" if you
>want, but when the user-data stops flowing the notion is ... strained.
>When one party decides a new cipher is required, you must fairly soon
>either use a new cipher or stop moving data.  Otherwise think what a bad
>guy could do.

OK, what could a bad guy do?  The conversation is under cipher, the
negotiation is under cipher, and if the cipher takes several exchanges
to change, then it does.  If there is no alternative cipher, there can
be no agreement, and so no change.  If one party insists that a change
occur, and no change is possible, then, obviously, communication
stops.  What is hard about this?


>>>...well, not exactly
>>>for PPP, which, for example has the CCP (comopression) which is supposed to
>>>be negotiated in parallel with the main NCP's, which can start sending
>>>data before CCP converges.  That is what the PPP implementations I've
>>>worked on do, but plenty of others don't.  Again, theory vs. practice.
>>
>>I am a working engineer. 
>>
>>Theory vs. practice.
>
>Shouldn't a working engineer know about the common, existing, widely
>*practiced* examples of the thing he is proposing?  SSL is a closer example
>than modems or PPP.  (I picked PPP because I know more about PPP than
>SSL.)  Do you care to say something about SSL that will convince people
>that negotiating ciphers is a great idea?

No, 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.

Changing ciphers is a great idea if we want to complicate any attack
which requires the accumulation of ciphertext from a particular
cipher.  If, as we expect, opponents cannot distinguish the ciphers
from their ciphertexts, they simply do not have the basis for most
types of described attacks.  I would call this a worthwhile motive for
the modest additional complexity required to automatically switch
ciphers.  

That is not the only motive, however.  Another good motive is to make
the secure communications path resilient against the known failure of
our favorite ciphers.  Only if the systems can automatically move to
new ciphers can we hope to avoid massive disruption from the failure
of something which cannot be guaranteed in an engineering sense.  


>> ...
>>Well, since you are a "real designer," I'll just let you wander on in
>>your monomanical tirade, while I suggest that we *not* do things like
>>PPP.  
>
>The biggest trouble with PPP is that it is a standardized network thing.
>Network things that are standards are always at least 95% politics, by
>which I mean everything that comes with design by committee and approval
>by standards committees.  Negotiating ciphers such as you have proposed
>would necessarily be network things.  Your repeated appeals to the word
>"standardized" mean that they would enjoy the attentions of standards
>committees.

In my experience, many "standardized" technologies in fact start out
as ad-hoc standards, and it is this genesis and the desire to stay
with the mistakes of the past which -- as much as anything -- mark the
problem.  

The virtually universal practice in both hardware and software is to
hack out a solution and ship it, with minimal thought given to
consequences.  But "thought" is just what is going on here.  Only if
we get a reasonable concensus about *what* need be done will it *then*
make sense to try to standardize *how* that will be done.  


>> ...
>>There is no other possibility, unless you wish to depend upon the
>>strength of a cipher which explicitly HAS *no* known or guaranteed
>>strength.  Not having strength is not a trivial detail, this is the
>>essence of the reason for using a cipher.  
>
>Before complaining of my monomanical tirades, you ought to notice a few
>of your own ...yes, you and others have pointed out with endless boring
>repetitions, the truth of the premise of that paragraph, that we have no
>guarantees, measurements, or even definitions of the true, theoretical
>strength of any practical cipher.  However, as others have tirelessly
>responded, your claim that automated switching among lots of ciphers is
>the only alternative to a falling sky does not follow from that premise.

I doubt that I have ever said any such thing.  I do not say that
switching among ciphers is the only possible solution.  I have many
times asked for alternative contributions to solving the fundamental
problem.  But since I have been arguing this for some years now, I
don't expect that many degrees of freedom remain to be investigated.  

The security advantages which accrue from "automated switching" among
locally-approved ciphers are many and broad.  I think it is sufficient
to notice that ciphers do not enjoy the same sort of performance
specification that we normally expect from communications system
components.  If a hardware fails, or cannot keep up, or does not
follow a spec'd protocol, we know that something is wrong; we can fix
it or replace it.  Similarly the software.  But even if we find out
that our cipher has failed, we cannot bitch, because a cipher carries
no performance guarantees with respect to security.  In what other
component in a communications system would we tolerate a complete lack
of specification about the fundamental role of that component?  

Now, what does switching do for us?  Mainly, it gives us the freedom
to change a component which is not and can not be guaranteed.  But it
also complicates attacks by making it difficult or impossible to
distinguish the ciphertext from a particular cipher so it can be used
to generate a particular attack.  


>>The ability to change ciphers offers each of us the power to choose
>>what cipher we want to use.  This means no government organization is
>>edicting our use, or forcing it through market pressure.  We get to
>>choose what to use, and what not to use, and to change our minds on a
>>daily basis.  That is not a trivial advantage.
>
>Yes, it's good to be able to change ciphers.  That does not imply anything
>one way or another about computers negotiating ciphers in real time.

First of all, I think your use "real time" is confusing.  When we talk
about "real time operating systems" we mean systems which have defined
worst-case performance characteristics.  But I see no need for any
such limitation on negotiation.  Certainly cipher negotiation would
"real time" in the sense that negotiation information would flow
during message time, but *not* in the sense that it had to be
accomplished before the next message could occur.  

And any system which will benefit non-computer types must operate
virtually on its own, with minimal setup and maintenance.  In
particular, it must be easy to stop using a particular cipher.  If
cipher changing is not the normal mode of operation, that is quite
unlikely to work smoothly when needed.  


>>>Other good (i.e. bad) examples of the inevitable perils of negotiating
>>>besides modems and PPP include TCP and HTTP.  Most don't know about
>>>about MSS/PMTU or window size problems, but most people have seen
>>>"broken" web pages that don't work on some versons of some browsers.
>>
>>Gosh, I think we'll just have to have a complete specification.
>
>The equivalent failure mode of negotiated ciphers for a broken web page
>would be picking ROT26 as the cipher right after ROT13.  Or one of
>the SSL security bugs.

No, that would *not* be a failure of negotiation:  That would be a
problem with the content of the cipher selection set, and that content
is a human decision.  If humans want to allow the use of both ROT13
and ROT26, the system might well choose ROT13 and ROT26.  But I
thought we were talking about serious ciphers here, and the only
counterpart to ROT26 in a serious cipher is the ability to use a buggy
implementation.  

We don't normally depend upon *perfect* software, because we cannot
assure any such thing.  Consequently, some implementations -- even of
the best ciphers -- *will* have bugs.  Having frequent cipher changes
at least takes us out of a buggy implementation into some other
implementation fairly quickly.   


>The world is full of self-described architects, designers, and inventors.
>Most are frauds who invent only self-delusions, hot air, snake oil, and
>promises to finally build a perptual motion machine that will work this
>time, (and help patent attourneys make the payments on their Mercedes.)

Well, the world is *also* full of people who hack something together
and then call themselves architects or designers; I like to think that
there is something more involved.  And while I can hardly speak for
all those you have indicted here, I suppose we would all like to be
more successful than we are.  

In cryptography, I have a well-documented 10-year history of
publication in ink on paper, fundamental patents, and lately web page
publications.  You can read my papers on my pages.  You can read how I
describe my inventions, what they do, their reason for being, as well
as the actual patents themselves if you are masochistic.  You can read
the detailed designs for my older cipher products.  And, if you have
the background, you can compare my work to the state of the art and
come to your own conclusions.  

*  Recently, I have been interested in the technical analysis of
analog noise for cryptographic purposes, and I have about 20 pages of
figures and graphs which build some interesting conclusions:

   http://www.io.com/~ritter/NOISE/NOISCHAR.HTM

*  Before that, I was interested in the construction of keyed
orthogonal Latin squares of large order, and you can read about that
too:

   http://www.io.com/~ritter/ARTS/NONLBBM.HTM

*  Before *that*, I was interested in the analysis of S-boxes through
the measure of Boolean nonlinearity.  Not only do I describe the
measure, I include actual working code to do it:

   http://www.io.com/~ritter/JAVASCRP/NONLMEAS.HTM

*  All this is, of course, in addition to a crypto glossary of almost
400K, and my introduction to cryptography:

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

As archived on my pages, I have carried many arguments onto sci.crypt,
and I normally present not only my views, but also the opposing views
and allow the readers to come to their own conclusions.  

While I am quite sure that others have been more productive or more
effective or more . . . appropriate during this period, I have done
what I have done.  Perhaps you need to compare my work to the similar
goods from those you described before you see the difference.  

But I'm not quite sure what all this has to do with the current
conversation.  


>The real architects, designers, and inventors not only desgin and invent,
>but also build real implementations that are useful in real life.  

Since when did *you* get to decide what makes a "real" designer or
inventor?  I would say that, with respect to true scientific
innovation, it is the argument that matters, and *only* the argument.



>So when
>will we see the implementation of negotiated/varying ciphers that you are
>building?

I have some rather complete designs.  But as I see it, there is little
point in attempting to field such a product in an environment where
"real" designers still think that cryptanalysis tells us that a
standardized cipher must be strong, so we don't really need all this
fancy cipher-change stuff.  Perhaps things will change in a year or
two.  

---
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: 24 Oct 1999 09:52:33 -0600
From: vjs@calcite.rhyolite.com (Vernon Schryver)
Message-ID: <7uva01$pm3$1@calcite.rhyolite.com>
References: <3812c8b2.9444970@news.io.com>
Newsgroups: sci.crypt
Lines: 421

In article <3812c8b2.9444970@news.io.com>, Terry Ritter <ritter@io.com> wrote:

> ...
>>Modems do not work all of the time.  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.
>
>Cipher negotiation is not in itself cryptographic.

If cipher negotiation is not critical to keeping secrets, then there is
no reason to do it.  The 1st Amendment lets anyone claim that a failure in
cipher negotiating could not possibly compromise security, but no one who
has dealt with real life security protocols will believe it.  It is an
egregious offense against the dictum that theory and practice are not the
same to imply that cipher negotiating would never open any security holes.


>                                                    It can and should
>occur under the current cipher(s) and should be a straightforward
>selection. ...

That's what they all said about PPP selecting MTU's, IP addreses,
and authentication schemes, TCP doing PMTU discovery, and SSL.


>Cipher negotiation is not the same situation as modem negotiation.
>Since modem negotiation is in fact used in practice to make dynamic
>connection-by-connection negotiated decisions, it shows that this is
>in fact practical in deployed systems.

I have never said or even implied that cipher negotiating is impossible.
My original example, PPP, shows that negotiating things is possible.
The issue is whether in practice you can design and deploy a cipher
negotiating system that would not make people run away screaming.

Haven't you noticed the signature "SSL isn't" of one author here?
How will your cipher negotiating protocol be certain to not only
avoid all of SSL's problems, but also all possible new problems?


> ...
>>>I doubt I implied that modem negotiation is "clean."  But it *is*
>>>"background," and it *is* negotiation (both sides participate in the
>>>final result), and it *is* "real world" -- it generally works in
>>>practice.
>>
>>The "it generally works in practice" can be said about PPP, only more so.
>>And again, who wants a cipher negotiating protocol that "generally
>>works in practice"?
>
>PPP is not cipher negotiation.

It is at best intellectually dishonest to say that PPP is so different
from cipher negotiating that the PPP experience is irrelevant.  In both
PPP and cipher negotiating, all that the computers do is agree on some
parameters.  Moreover, as I've mentioned, one of the biggest real life
negotiating problem areas in PPP has been the negotiation of authentication
protocol, picking among PAP, MD5 CHAP, MS-CHAP (which involves MD4 and
DES), and MS-CHAPv2 (ditto, except I think they use MD5 also or instead).
"MD4", "MD5", and "DES" refer to the familiar hash and encryption
functions.  One PPP peer says "let's try X", for X=its preferred
authentication algorithm.  The other peer says either "ok" or "no, instead
let's use Y."  The first says either "ok, let's use Y", or shuts down or
restricts the link to traffic not needing authentication.  Isn't that
exactly what you envision for cipher negotiating?

Read the forthcoming edition of James Carlson's PPP book in which he
describes some of the many ways the PPP authentication negotiation fails
in real life.  In theory and in the RFC's, of course, it's perfect.


> ...
>Just what is it that you don't get about requesting a cipher, then
>receiving an answer, yes, no, or a suggested alternative, all of which
>occurs in the error-corrected data?  It is fine to be wairy of new
>ideas, but this seems somewhat OTT.

My point is that "requesting an X, then receiving an answer, yes, no or
suggested alternative" 

 - is an idea is anything but new or untried.

 - is exactly PPP Configure-Requests, Configure-Naks, and Configure-Acks.

 - it is nothing like what occurs in "error-corrected data", except as
    I might explain things to someone with no idea of or interest in
    negotiating things or CRC's, forward error codes, and ARQ.


> ...
>The whole basis for cipher selection is very clean.

That is statement, like others of yours in support of cipher negotiating,
is like what the fellow who advocates extremely long keys says about his
code and ciphers.  It is at best an expression of a hope.


> ...
>And just what standards committee would that be, exactly?

If you negotiate your ciphers for the purpose of protecting IP (including
IPv6) data, the IETF would ensure it is involved eventually.  If you move
down a layer, you would get the ITU or an ad hoc committee like the ATM
Forum or an official committee such as IEEE 802.3 or ANSI x.3.  If you go
up, say to protect HTTP, you'll be involved with the W3C or the IETF.

In real life, whether you or I like it or not (I don't), if you are talking
about a multi-vendor protocol, you will have standards committees involved.

Have you not noticed where the next version of SSL is being done?

If you use cipher negotiating to protect voice data, you'll find the CLEA
forcing equipment vendors to get your protocol sanctioned by a standards
committee to avoid fines for failing to include enough wire tapping.  (See
the recent big noises in the "raven" mailinglist of the IETF in which the
IETF is trying to avoid getting involved in putting more tapping facilities
into IP.  The on-line press has been filled with reports of that circus.)


>>> ...
>>>I would say, "let's not do it like PPP."
>>
>>Exactly how would you do that?  The problems with PPP negotiating are not
>>any single technical issue, but the inevitable morass that comes with
>>complicated network stuff in the best possible circumstances.
>
>Negotiating a cipher can be and should be distinct from using any
>particular cipher.  This is not a complicated network stuff, but a
>simple selection protocol quite comparable to what two people would do
>if they were discussing which cipher to use on the phone.  

Exactly the same theory is said still about all of PPP.
Only salescritters and the clue challenged believe it.

Much of PPP negotiating is for small numbers, with one peer proposing a
value, and the other saying either "ok" or "let's do X instead."  Almost
all of the rest of PPP negotiating consists of one peer saying "let's do
Z" and the peer saying either "yes" or "no".  That's simpler than
your cipher negotiating, but it also has lots of real life problems.


> ...
>I have presented the example that modems do in fact in practice
>negotiate their state, today, in mass fielded systems.  I am sorry if
>you have trouble with your modems, but I have used modems from home
>since the early 80's, we typically still do use modems from home
>several times a day, and considering that they are working on lines
>designed for voice and not data, they generally work well, and in fact
>much better than they used to.  

And I have mentioned that I have been dealing with modems since the 1960's.
that modem negotiating is at best ugly under the covers (as you agreed),
that modems still sometimes fail to negotiate (as you agreed), and that
the modem protocol war continues as demonstrated by the still unwinding
v.90 battle.

Who is going to be using your cipher negotiating protocol before it matures
like modem protocols, before it works "much getter than [it] used to."
Personally, I'll be keeping data I care about under other schemes a while
longer than that.

As evidence that cipher negotiating could not escape standards committees,
note that major modem protocols for the last 10 years have involved the
worst of standards committees, the ITU.


> ...
>>When one party decides a new cipher is required, you must fairly soon
>>either use a new cipher or stop moving data.  Otherwise think what a bad
>>guy could do.
>
>OK, what could a bad guy do?  The conversation is under cipher, the
>negotiation is under cipher, and if the cipher takes several exchanges
>to change, then it does.  If there is no alternative cipher, there can
>be no agreement, and so no change.  If one party insists that a change
>occur, and no change is possible, then, obviously, communication
>stops.  What is hard about this?

If the initial cipher is absolutely secure, then there is no reason to
ever change it or negotiate anything.
You necessarily assume that the bad guys can break some ciphers.  If 
the bad guy has a real-time break of a cipher you happen to use for
a while, he can keep you from switching.

For a real life example of the problems of negotiating ciphers, "what is
hard about" SSL?


> ...
>No, 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.

I've not seen anyone claim negotiating ciphers is "impossible."  Nothing
I have said could be honestly interpreted as claiming impossibility.
After all, I've been talking about real life protocols that mostly work.

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.


>Changing ciphers is a great idea if we want to complicate any attack
>which requires the accumulation of ciphertext from a particular
>cipher.  If, as we expect, opponents cannot distinguish the ciphers
>from their ciphertexts, they simply do not have the basis for most
>types of described attacks.  I would call this a worthwhile motive for
>the modest additional complexity required to automatically switch
>ciphers.  

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.


>That is not the only motive, however.  Another good motive is to make
>the secure communications path resilient against the known failure of
>our favorite ciphers.  Only if the systems can automatically move to
>new ciphers can we hope to avoid massive disruption from the failure
>of something which cannot be guaranteed in an engineering sense.  

That conclusion is your thesis.  You have not proven it.


> ...
>In my experience, many "standardized" technologies in fact start out
>as ad-hoc standards, and it is this genesis and the desire to stay
>with the mistakes of the past which -- as much as anything -- mark the
>problem.  

In my experience, which has brushed against language as well as network
standards and committees, the predecessor to the standards committee
product is invariably smaller, cleaner, and more robust.

What standards committees do is no more or less "ad hoc" than what any
other committee, group, or individual does.  There are no formulas for
producing protocols.  They are all "ad hoc," but some are more informed
by past experience.


>The virtually universal practice in both hardware and software is to
>hack out a solution and ship it, with minimal thought given to
>consequences.

Maybe where you do your engineering, but not where I've been doing mine
for the last 30+ years.

>               But "thought" is just what is going on here.

No, what is going on here is standard netnews, talk with very little
throught, and no significance.
Name a single protocol that has ever been designed in a netnews group.
Not even NNTP managed that trick.


>                                                             Only if
>we get a reasonable concensus about *what* need be done will it *then*
>make sense to try to standardize *how* that will be done.  

I insist on considering at least sketches of "how" simultaneously with
"what."  The worst protocol standards (e.g. the ISO OSI suite or MAP and
TOP) are created by committees deciding "what" before and independent of
"how."

Regardless, the only concensus that matters in the real world is among
what I think of as "practicing engineers" (people who actually build
things) and their customers.  There is not a quorum of either for
considering negotiating ciphers.


> ...
>>>There is no other possibility, unless you wish to depend upon the
>>>strength of a cipher which explicitly HAS *no* known or guaranteed
>>>strength.  Not having strength is not a trivial detail, this is the
>>>essence of the reason for using a cipher.  
>>
>>Before complaining of my monomanical tirades, you ought to notice a few
>>of your own ...yes, you and others have pointed out with endless boring
>>repetitions, the truth of the premise of that paragraph, that we have no
>>guarantees, measurements, or even definitions of the true, theoretical
>>strength of any practical cipher.  However, as others have tirelessly
>>responded, your claim that automated switching among lots of ciphers is
>>the only alternative to a falling sky does not follow from that premise.
>
>I doubt that I have ever said any such thing.  I do not say that
>switching among ciphers is the only possible solution.

You said "There is no other possibility" in the words quoted above your
claim that you did not say that.


> ...
>The security advantages which accrue from "automated switching" among
>locally-approved ciphers are many and broad. ...

No one disagrees with that.

The trouble is that you go from that true statement to claims that
negotiating ciphers is easy, safe, and non-fattening.  I think it is none
of those.  I've designed and implemented more than 1 or 2 protocols since
my first simplistic hack that made two computers talk to each other over
phone lines in the 1960's, and merely implemented a lot more.


> ...
>>Yes, it's good to be able to change ciphers.  That does not imply anything
>>one way or another about computers negotiating ciphers in real time.
>
>First of all, I think your use "real time" is confusing.  When we talk
>about "real time operating systems" we mean systems which have defined
>worst-case performance characteristics.

I wish "real time operating systems" had something to do with "defined
worst-case performance characteristics," but by 10 or 15 years ago,
"defined" had been replaced by "rarely violated, we think."  Now you must
demand "hard realtime" to get more than a prayer and a salescritter
promise.


>                                         But I see no need for any
>such limitation on negotiation.  Certainly cipher negotiation would
>"real time" in the sense that negotiation information would flow
>during message time, but *not* in the sense that it had to be
>accomplished before the next message could occur.  

I carefully did not say "before the next message could occur," but
intentionally wrote "fairly soon."


>And any system which will benefit non-computer types must operate
>virtually on its own, with minimal setup and maintenance.  In
>particular, it must be easy to stop using a particular cipher.  If
>cipher changing is not the normal mode of operation, that is quite
>unlikely to work smoothly when needed.  

Replace "cipher" with any of the parameters negotiated with PPP or SSL,
and I've heard those words many times.  I'm not saying they are wrong,
but that in practice they do not imply what you wish they did, that
negotiating will work smoothly merely because it is central, and as 
proof, I've pointed to many real life examples.


> ...
>We don't normally depend upon *perfect* software, because we cannot
>assure any such thing.  Consequently, some implementations -- even of
>the best ciphers -- *will* have bugs.  Having frequent cipher changes
>at least takes us out of a buggy implementation into some other
>implementation fairly quickly.   

You could make money as a stand-up comedian for the IETF PPP Working
Group with lines like that.  I'm serious; you would get big laughs
from people who have designed and built negotiating computer protocols by
saying that negoiating necessarily gets you out of anything quickly.


>>The world is full of self-described architects, designers, and inventors.
>>Most are frauds who invent only self-delusions, hot air, snake oil, and
>>promises to finally build a perptual motion machine that will work this
>>time, (and help patent attourneys make the payments on their Mercedes.)
>
>Well, the world is *also* full of people who hack something together
>and then call themselves architects or designers; I like to think that
>there is something more involved.  And while I can hardly speak for
>all those you have indicted here, I suppose we would all like to be
>more successful than we are.  
>
>In cryptography, I have a well-documented 10-year history of
>publication in ink on paper, fundamental patents, and lately web page
>publications.  You can read my papers on my pages.  You can read how I
> ...

Have you implemented any of your ideas in commercial products?


>>The real architects, designers, and inventors not only desgin and invent,
>>but also build real implementations that are useful in real life.  
>
>Since when did *you* get to decide what makes a "real" designer or
>inventor?  I would say that, with respect to true scientific
>innovation, it is the argument that matters, and *only* the argument.

Nonsense!  Outside of math, arguments are mere hot air.  Even the purest
of theoreticians depend on experimentalists for validation.  Besides
sci.cript is about enginnering instead of science or math, despite the
netnews hierarchy, and as you and others have implicitly been saying for
months in rants about the lack of theory of cipher strength.
No, don't bother pointing at the occassional elementary number theory or
complexity notion.  I spent too many years in math graduate school to be
overawed by such things, especially when so many authors here get them
wrong.


>>So when
>>will we see the implementation of negotiated/varying ciphers that you are
>>building?
>
>I have some rather complete designs.  But as I see it, there is little
>point in attempting to field such a product in an environment where
>"real" designers still think that cryptanalysis tells us that a
>standardized cipher must be strong, so we don't really need all this
>fancy cipher-change stuff.  Perhaps things will change in a year or
>two.  

To distinguish oneself from legions of cranks, all of whom have "rather
complete designs" for antigravity machines, FTL drives, perpetual motion
machines, and many other wonderful things, one must produce working
implementations that other people can test drive.


Vernon Schryver    vjs@rhyolite.com


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: 25 Oct 1999 20:12:54 -0600
From: vjs@calcite.rhyolite.com (Vernon Schryver)
Message-ID: <7v32n6$k72$1@calcite.rhyolite.com>
References: <38147B53.4B9EDA7B@aspi.net>
   <7uva01$pm3$1@calcite.rhyolite.com>
Newsgroups: sci.crypt
Lines: 132

In article <38147B53.4B9EDA7B@aspi.net>,
Trevor Jackson, III <fullmoon@aspi.net> wrote:

> ...
>> Haven't you noticed the signature "SSL isn't" of one author here?
>> How will your cipher negotiating protocol be certain to not only
>> avoid all of SSL's problems, but also all possible new problems?
>
>There is a fundamental difference between establishing a connection, a la PPP or
>SSL, and altering the operation of an existing connection.  The latter is simpler
>in many ways, not the least of which is that fallback/revert is always possible

As far as I understand it, that statement has no relation to that I
understand to be PPP.

> ...
>> It is at best intellectually dishonest to say that PPP is so different
>> from cipher negotiating that the PPP experience is irrelevant.  In both
>> PPP and cipher negotiating, all that the computers do is agree on some
>> parameters.
>
>No.
>
>PPP has to build a connection where none exists.  This eliminates the standard
>communication primitives and requires a step-wise negotiation of the protocol in
>order to build up support the standard communication primitives.

That is completely wrong.  All of PPP is built on "standard communications
primitives," namely a pair of full-duplex streams of packets without errors
but possibly with packet losses, and that preserve packet order.  PPP
requires the existence of "standard communications primitives" that are
more restricted and powerful than those provided by UDP/IP.  (UDP delivers
packets potentially out of order).

>In dynamic cipher negotiation (DCN for want of a better abbreviation) a viable
>connection already exists.

Like the usual, ordered, error-detected connection underneath all of PPP?

Or does it require the reliable stream (i.e. not only no bad packets, but
no packets lost) that can be negotiated with PPP, and that is required by
some forms of PPP compression, including some that have the negotiation
problems I've referred to?  That's the flavor of PPP favored by Gandalf
that is a form of x.25.

Do seriously mean to claim that x.25 does not offer "standard
communications primitives"?


>                  It can be used to verify the correct interoperation of
>the target cipher prior to committment.

The trouble with negotiating protocols or ciphers is in picking a "target,"
or the equivalent of agreeing on the merchandise and the price.  By the
time you have a "target cipher" whose "correct interoperation" you can
verify, you've already the problems in negotiating, just as by the time
you carry home your melons from the market, the negotiating problems are
long past.

Well, some of the major PPP problems involve the equivalent of you deciding
after you get home that you made a bad deal, and going back to the market
to try to find and haggle with the vendor.  If you say that the equivalent
problems won't happen with negotiating ciphers, I'll not believe you.
Note that some of the other major PPP problems are due to the sloppiness
of a bunch of vendors who ignore the clear requirements in the main 
PPP RFC's concerning renegotiating parameters.  Those errors have caused
significant security problems.  (I'm talking of the common junk that
gives up upon receiving an LCP Configure-Request after reaching OPENED)


>                                         And since fallback/revert is always
>available the complexity of error/dispute handling is dramatically reduced.

That's another wonderfully funny statement.
Those who have actually implemented protocols with "fallback/revert" know
that such features are extremely fertile sources of major problems in
the real world.  We also know that the salescritters sell such features
to unsuspecting users and system administrators as the opposite of
what they usually are, sources of bugs and major sources of complexity.


> ...
>> Much of PPP negotiating is for small numbers, with one peer proposing a
>> value, and the other saying either "ok" or "let's do X instead."  Almost
>> all of the rest of PPP negotiating consists of one peer saying "let's do
>> Z" and the peer saying either "yes" or "no".  That's simpler than
>> your cipher negotiating, but it also has lots of real life problems.
>
>In what sense is is similar?  We want one small number, the ID of the cipher.
>What additional complexity do you see associated with cipher selection other than
>cipher selection? (Yes that phrasing is purposefully chosen).

Carefully phrased or not, I do not understand any technical content in that
question.

For an example that might answer the question, the job of the CCP (PPP
compression control protocol) is to get the PPP peers to agree on a 16-bit
ID for a compression algorithm.  The point of the LCP authentication
Conf-Req/Rej/Nak packets is to pick a similar, small ID of an
authentication protocol.  How is that harder than picking the ID of a
cipher?


>> ...
>Please point to an example where a higher level user of a channel is unable to
>detect the phase transition.  Both PPP and SSL fail this test as the presence of
>absence of a channel counts as detectable.

What do you mean by "phase transition"  Or "absence of a channel"?  Do
you seriously mean to claim or imply that PPP ever exists, works, or starts
to work or something similar when there is no "channel" between the peers?
I think SSL assumes that it has TCP/IP underneath, which is less than what
any cipher negotiating protoocol will assume for transport.  What do you
think?


No, please do not bother responding.


Vernon Schryver    vjs@rhyolite.com


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: 24 Oct 1999 10:13:34 -0600
From: vjs@calcite.rhyolite.com (Vernon Schryver)
Message-ID: <7uvb7e$q7s$1@calcite.rhyolite.com>
References: <38131CDC.40A35B01@aspi.net>
   <7uu5ft$f7v$1@calcite.rhyolite.com>
Newsgroups: sci.crypt
Lines: 91

In article <38131CDC.40A35B01@aspi.net>,
Trevor Jackson, III <fullmoon@aspi.net> wrote:

> ...
>> Only salescritters or people with no technical knowledge can claim that
>> either PPP or modems are examples that could cause a working engineer to
>> be enthusaistic about negotiating ciphers.  Sane, technically inclined
>> people who look at modems, PPP, or any other "standardized", dynamic
>> negotiating network protocol must be very skeptical of the idea.
>
>Any other?  I think not.
>
>You can pick on negotiation failures typically those that evolved over time, which
>usually means layers of kludge upon kludge, sometimes driven by commercial issues
>(PPP),

Base on that statement, you have no idea of the history or even nature of
PPP.  PPP in general and PPP negotiating in particular are as much as was
possible the exact opposite of something "that evolved over time."
(Before you argue with me about the history of PPP, please tell me under
what name I can find your words in the IETF PPP WG archives.)


>       and sometimes driven by technological advances (modems).

That notion of the history of modems is also as wrong, based on what I've
observed since before dial-up 1200 bit/sec modems were available
(1,200 bit/sec, not 12,000 bps).


>OTOH, you have failed to note the cases in which negotiation is so successful that
>it is almost invisible.  Consider DECnet.  Once a machine is configured there is
>little chance of failure.  You hook up the wires and the machine figures out wht
>topology necessary to communicate with other machines.  This is a negotiation
>protocol that works.

Have you ever worked inside a DECnet implementation?  I have been paid to
port and hack code that implemented Phase IV, and then to deal with problem
reports from customers that the technical support people could not answer.
To say the least, I do not agree with your claim that DECnet "is a
negotation protocol that [always] works."

Even the claim that DECnet was a "negotation protcol" is not quite true 
in my view.


>Note that this class of error, noticing only the problems, is a basic wheel
>approach which causes sampling error.
>There is no alue to this sort of anecdotal horror story.  If you want to address
>the topic of negotiating protocols, please produce an issue that you believe will
>be difficult to solve and lead to negotiation failures.

You're evidently as much of a "practicing engineer" as Terry Ritter.
My point is that in theory, there are no non-trivial problems that would
need attention, but in practice there always are.
In theory, there are no anecdotes that do not conform to theory.
Practice consists of anecdotes.


> ...
>Not relevant.  We aren't faced with "complicated network stuff" or anything
>similar.  Anyone adding one or more  AES ciphers to an existing multi-cipher
>product already the the problem and a solution.  Adding several AES ciphers to an
>existing single-cipher product is no harder than adding a single ("the") AES
>cipher; negotitaion is required.

That is wrong.  Negotiation is not necessarily required, although the
receiver does need to figure out or know by prior configuration which
cipher is in use.  "Negotiation" involves proposing, rejecting,
counter-proposing, and accepting.  "Negotiation" is not inolved in asking
the wire for a network address and accepting whatever you get.  It is also
not merely looking at a header to identify a packet format or cipher.
Asking for a DHCP or BOOTP address or picking a decryption scheme and key
based on a packet header has as much to do with "negotiating" as buying
groceries in a typical American supermarket, nothing whatsoever.


>                            creating a new product is the only case in which
>the requirement to negotiate cipher selection is an issue.  Note that this is
>going to be common for reasona of backward compatibility during the
>changeover/upgrade period.

Nonsense.  Upward compatiblity does *not* need negotiating, but merely
recognizing the old form.  Negotiating is required if you want to
have the sender and receiver have potentically non-overlapping sets
of ciphers and to discover and agree on the best common cipher.
It is also required by Terry Ritters proposals.

Moreover, the "changeover/upgrade period" for protocols invariably lasts
a very long time.  A case study of how long that can be is in the endurance
of DECnet Phase IV which has been officially obsolete and deprecated for
more than 10 years, but which is still a common form of DECnet (where
DECnet still exists).
Because of embedded systems, changes in cipher protocols take even longer.


> ...
>You cannot just wish this requirement away.  Nor can you ignore the ubiquity of
>the issue and claim that multiple AES selections creates an abnormal condition.
>As discussed above it is probably normal to have multiple ciphers.
> ...

And you cannot just wish requirements into existence.
AES is not the first new cipher in history.  Ciphers have been coming and
going for decades.  Still, negotiating ciphers is not universal, and
where it is done, not without significant security problems in
practice but not theory (e.g. SSL).


Vernon Schryver    vjs@rhyolite.com


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Sun, 24 Oct 1999 18:13:34 +0200
From: vjs@calcite.rhyolite.com (vjs@calcite.rhyolite.com)
Message-ID: <fc.3b9aca0002b8f3503b9aca008f91dec6.10ab9@peg.dyndns.org>
References: <7uvb7e$q7s$1@calcite.rhyolite.com>
Newsgroups: sci.crypt
Lines: 129

In article <38131CDC.40A35B01@aspi.net>,
Trevor Jackson, III <fullmoon@aspi.net> wrote:

>> ...
>>> Only salescritters or people with no technical knowledge can claim that
>>> either PPP or modems are examples that could cause a working engineer
>to
>>> be enthusaistic about negotiating ciphers.  Sane, technically inclined
>>> people who look at modems, PPP, or any other "standardized", dynamic
>>> negotiating network protocol must be very skeptical of the idea.
>>
>>Any other?  I think not.
>>
>>You can pick on negotiation failures typically those that evolved over
>time, which
>>usually means layers of kludge upon kludge, sometimes driven by
>commercial issues
>>(PPP),

Base on that statement, you have no idea of the history or even nature of
PPP.  PPP in general and PPP negotiating in particular are as much as was
possible the exact opposite of something "that evolved over time."
(Before you argue with me about the history of PPP, please tell me under
what name I can find your words in the IETF PPP WG archives.)


>>       and sometimes driven by technological advances (modems).

That notion of the history of modems is also as wrong, based on what I've
observed since before dial-up 1200 bit/sec modems were available
(1,200 bit/sec, not 12,000 bps).


>>OTOH, you have failed to note the cases in which negotiation is so
>successful that
>>it is almost invisible.  Consider DECnet.  Once a machine is configured
>there is
>>little chance of failure.  You hook up the wires and the machine figures
>out wht
>>topology necessary to communicate with other machines.  This is a
>negotiation
>>protocol that works.

Have you ever worked inside a DECnet implementation?  I have been paid to
port and hack code that implemented Phase IV, and then to deal with problem
reports from customers that the technical support people could not answer.
To say the least, I do not agree with your claim that DECnet "is a
negotation protocol that [always] works."

Even the claim that DECnet was a "negotation protcol" is not quite true 
in my view.


>>Note that this class of error, noticing only the problems, is a basic
>wheel
>>approach which causes sampling error.
>>There is no alue to this sort of anecdotal horror story.  If you want to
>address
>>the topic of negotiating protocols, please produce an issue that you
>believe will
>>be difficult to solve and lead to negotiation failures.

You're evidently as much of a "practicing engineer" as Terry Ritter.
My point is that in theory, there are no non-trivial problems that would
need attention, but in practice there always are.
In theory, there are no anecdotes that do not conform to theory.
Practice consists of anecdotes.


>> ...
>>Not relevant.  We aren't faced with "complicated network stuff" or
>anything
>>similar.  Anyone adding one or more  AES ciphers to an existing
>multi-cipher
>>product already the the problem and a solution.  Adding several AES
>ciphers to an
>>existing single-cipher product is no harder than adding a single ("the")
>AES
>>cipher; negotitaion is required.

That is wrong.  Negotiation is not necessarily required, although the
receiver does need to figure out or know by prior configuration which
cipher is in use.  "Negotiation" involves proposing, rejecting,
counter-proposing, and accepting.  "Negotiation" is not inolved in asking
the wire for a network address and accepting whatever you get.  It is also
not merely looking at a header to identify a packet format or cipher.
Asking for a DHCP or BOOTP address or picking a decryption scheme and key
based on a packet header has as much to do with "negotiating" as buying
groceries in a typical American supermarket, nothing whatsoever.


>>                            creating a new product is the only case in
>which
>>the requirement to negotiate cipher selection is an issue.  Note that
>this is
>>going to be common for reasona of backward compatibility during the
>>changeover/upgrade period.

Nonsense.  Upward compatiblity does *not* need negotiating, but merely
recognizing the old form.  Negotiating is required if you want to
have the sender and receiver have potentically non-overlapping sets
of ciphers and to discover and agree on the best common cipher.
It is also required by Terry Ritters proposals.

Moreover, the "changeover/upgrade period" for protocols invariably lasts
a very long time.  A case study of how long that can be is in the endurance
of DECnet Phase IV which has been officially obsolete and deprecated for
more than 10 years, but which is still a common form of DECnet (where
DECnet still exists).
Because of embedded systems, changes in cipher protocols take even longer.


>> ...
>>You cannot just wish this requirement away.  Nor can you ignore the
>ubiquity of
>>the issue and claim that multiple AES selections creates an abnormal
>condition.
>>As discussed above it is probably normal to have multiple ciphers.
>> ...

And you cannot just wish requirements into existence.
AES is not the first new cipher in history.  Ciphers have been coming and
going for decades.  Still, negotiating ciphers is not universal, and
where it is done, not without significant security problems in
practice but not theory (e.g. SSL).


Vernon Schryver    vjs@rhyolite.com


{}{}{} Posted via Uncensored-News.Com, http://www.uncensored-news.com {}{}{}
{}{}{}{} Only $8.95 A Month, - The Worlds Uncensored News Source {}{}{}{}
{}{}{}{}{} Five News Servers with a BINARIES ONLY Server {}{}{}{}{}


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Mon, 25 Oct 1999 12:18:38 -0400
From: "Trevor Jackson, III" <fullmoon@aspi.net>
Message-ID: <381482DE.B036BC49@aspi.net>
References: <7uvb7e$q7s$1@calcite.rhyolite.com>
Newsgroups: sci.crypt
Lines: 174

Vernon Schryver wrote:

> In article <38131CDC.40A35B01@aspi.net>,
> Trevor Jackson, III <fullmoon@aspi.net> wrote:
>
> > ...
> >> Only salescritters or people with no technical knowledge can claim that
> >> either PPP or modems are examples that could cause a working engineer to
> >> be enthusaistic about negotiating ciphers.  Sane, technically inclined
> >> people who look at modems, PPP, or any other "standardized", dynamic
> >> negotiating network protocol must be very skeptical of the idea.
> >
> >Any other?  I think not.
> >
> >You can pick on negotiation failures typically those that evolved over time, which
> >usually means layers of kludge upon kludge, sometimes driven by commercial issues
> >(PPP),
>
> Base on that statement, you have no idea of the history or even nature of
> PPP.  PPP in general and PPP negotiating in particular are as much as was
> possible the exact opposite of something "that evolved over time."

So.  In a previous post you alluded to the fact that the first implementations weren't
quite as functional or correct as later implementations.  If this is not "evolution
over time" what is the term you use for it?

> (Before you argue with me about the history of PPP, please tell me under
> what name I can find your words in the IETF PPP WG archives.)
>
> >       and sometimes driven by technological advances (modems).
>
> That notion of the history of modems is also as wrong, based on what I've
> observed since before dial-up 1200 bit/sec modems were available
> (1,200 bit/sec, not 12,000 bps).

Are we competing on ages or something?  I've got half a dozen 300 baud modems floating
around here someplace, and a couple of monster 1200 baud mini computer modems.  I know
what got us from there to here.  It wasn't a trivial process.  It was ugly then and is
still ugly now.

I do not belive this is an appropriate basis for comparison with dynamic cipher
negotiation (DCN).

> >OTOH, you have failed to note the cases in which negotiation is so successful that
> >it is almost invisible.  Consider DECnet.  Once a machine is configured there is
> >little chance of failure.  You hook up the wires and the machine figures out wht
> >topology necessary to communicate with other machines.  This is a negotiation
> >protocol that works.
>
> Have you ever worked inside a DECnet implementation?

Yes.  At the driver level.  I'm sure you can identify a DRV-11B.

>  I have been paid to
> port and hack code that implemented Phase IV, and then to deal with problem
> reports from customers that the technical support people could not answer.
> To say the least, I do not agree with your claim that DECnet "is a
> negotation protocol that [always] works."

Of course it does not always work.  Nothing does.

Point is that it is a vaible architecture.  One still in use in high performance
systems because it is perceived to be superior, and those making the decisions have
measurements to prove it.

> Even the claim that DECnet was a "negotation protcol" is not quite true
> in my view.

OK, let's argue that some other time.  It certainly is a dynamic environment, which is
enough to support the case I was presenting.

>
>
> >Note that this class of error, noticing only the problems, is a basic wheel
> >approach which causes sampling error.
> >There is no alue to this sort of anecdotal horror story.  If you want to address
> >the topic of negotiating protocols, please produce an issue that you believe will
> >be difficult to solve and lead to negotiation failures.
>
> You're evidently as much of a "practicing engineer" as Terry Ritter.
> My point is that in theory, there are no non-trivial problems that would
> need attention, but in practice there always are.
> In theory, there are no anecdotes that do not conform to theory.
> Practice consists of anecdotes.

Garbage.  I am nothing BUT a practicing engineer.

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?

>
>
> > ...
> >Not relevant.  We aren't faced with "complicated network stuff" or anything
> >similar.  Anyone adding one or more  AES ciphers to an existing multi-cipher
> >product already the the problem and a solution.  Adding several AES ciphers to an
> >existing single-cipher product is no harder than adding a single ("the") AES
> >cipher; negotitaion is required.
>
> That is wrong.  Negotiation is not necessarily required, although the
> receiver does need to figure out or know by prior configuration which
> cipher is in use.  "Negotiation" involves proposing, rejecting,
> counter-proposing, and accepting.

No.

In your experience negotiation may actually be an interactive process, and for DCN it
could be made arbitrarily complex.  But your argument appears to be that it is
necessarily very complex.  You have yet to support your position.

In fact "negotiation" may imply more work than needs to be done.  Perhaps you would
feel more comfortable with the term "configuration".   Whatever you call it, it could
be a simple as one end sending propose-cipher-change accompanied by the target cipher
and a sample encryption of a standard probe message, all covered by the current
cipher.  The other end sends either accept or reject, at which point the process is
complete.

Now to me, as a practicing engineer, a complex configuration change means upgrading the
system software on a multi-user computer without disturbing the users except that they
cannot type during the hardware reboot process.  That happens to be the first project I
undertook out of school.  It worked.  I belive that qualifies me to comment on the
complexity of software negotiations.


>  "Negotiation" is not inolved in asking
> the wire for a network address and accepting whatever you get.  It is also
> not merely looking at a header to identify a packet format or cipher.
> Asking for a DHCP or BOOTP address or picking a decryption scheme and key
> based on a packet header has as much to do with "negotiating" as buying
> groceries in a typical American supermarket, nothing whatsoever.

Your lack of experience is showing.  Do you have a particular issue with cipher
selection or are you reacting to the term "negotiation" instead of the referent the
term indicates?

>
>
> >                            creating a new product is the only case in which
> >the requirement to negotiate cipher selection is an issue.  Note that this is
> >going to be common for reasona of backward compatibility during the
> >changeover/upgrade period.
>
> Nonsense.  Upward compatiblity does *not* need negotiating, but merely
> recognizing the old form.  Negotiating is required if you want to
> have the sender and receiver have potentically non-overlapping sets
> of ciphers and to discover and agree on the best common cipher.
> It is also required by Terry Ritters proposals.
>
> Moreover, the "changeover/upgrade period" for protocols invariably lasts
> a very long time.  A case study of how long that can be is in the endurance
> of DECnet Phase IV which has been officially obsolete and deprecated for
> more than 10 years, but which is still a common form of DECnet (where
> DECnet still exists).
> Because of embedded systems, changes in cipher protocols take even longer.

Exactly.  This is why we should design in the requirement for flexibility as early as
possible rather than wishing away the issues that madate it.

>
>
> > ...
> >You cannot just wish this requirement away.  Nor can you ignore the ubiquity of
> >the issue and claim that multiple AES selections creates an abnormal condition.
> >As discussed above it is probably normal to have multiple ciphers.
> > ...
>
> And you cannot just wish requirements into existence.
> AES is not the first new cipher in history.  Ciphers have been coming and
> going for decades.  Still, negotiating ciphers is not universal, and
> where it is done, not without significant security problems in
> practice but not theory (e.g. SSL).

Your assertions support my conclusion and not your own.  Thank you.



Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: 25 Oct 1999 20:28:17 -0600
From: vjs@calcite.rhyolite.com (Vernon Schryver)
Message-ID: <7v33k1$kh4$1@calcite.rhyolite.com>
References: <381482DE.B036BC49@aspi.net>
Newsgroups: sci.crypt
Lines: 122

In article <381482DE.B036BC49@aspi.net>,
Trevor Jackson, III <fullmoon@aspi.net> wrote:

> ...
>> >You can pick on negotiation failures typically those that evolved over time, which
>> >usually means layers of kludge upon kludge, sometimes driven by commercial issues
>> >(PPP),
>>
>> Base on that statement, you have no idea of the history or even nature of
>> PPP.  PPP in general and PPP negotiating in particular are as much as was
>> possible the exact opposite of something "that evolved over time."
>
>So.  In a previous post you alluded to the fact that the first implementations weren't
>quite as functional or correct as later implementations.  If this is not "evolution
>over time" what is the term you use for it?

Are you claiming that fixing problems in implementations has something to do
with a *protocol* that you describe as "layers of kludge upon kludge"?
You claimed that the PPP *protocol* involved "layers of kludge upon kludge."

While some of the bugs in some of the PPP implementations might have
been due to kludgy implementations, many were not.



>> >       and sometimes driven by technological advances (modems).
>>
>> That notion of the history of modems is also as wrong, based on what I've
>> observed since before dial-up 1200 bit/sec modems were available
>> (1,200 bit/sec, not 12,000 bps).
>
>Are we competing on ages or something?  I've got half a dozen 300 baud modems floating
> ...

My impression of you is of a teenager typing in his grandfather's shop.
There is great, provided you don't make up facts as you go along.  You
could also be an experienced system administrator.  Again, that's would
be a good thing, absent a habit of inventing technical facts.


> ...
>> Have you ever worked inside a DECnet implementation?
>
>Yes.  At the driver level.  I'm sure you can identify a DRV-11B.

I'm sorry, but I do not believe that you have ever seen much DECnet or
any other network code.  Perhaps you installed or configured some VMS
software or hardware.  No one acquainted with DECnet internals would talk
about as you do.


>> >There is no alue to this sort of anecdotal horror story.  If you want to address
>> >the topic of negotiating protocols, please produce an issue that you believe will
>> >be difficult to solve and lead to negotiation failures.
>>
>> You're evidently as much of a "practicing engineer" as Terry Ritter.
>> My point is that in theory, there are no non-trivial problems that would
>> need attention, but in practice there always are.
>> In theory, there are no anecdotes that do not conform to theory.
>> Practice consists of anecdotes.
>
>Garbage.  I am nothing BUT a practicing engineer.

I'm sorry, but I do not believe that is true as I define the notion.  You
could be a system administrator, system engineer, network engineer, or
similar.  Again, those are good things, although they do not involve much
protocol or program design or implementation.


>> > ...
>> >Not relevant.  We aren't faced with "complicated network stuff" or anything
>> >similar.  Anyone adding one or more  AES ciphers to an existing multi-cipher
>> >product already the the problem and a solution.  Adding several AES ciphers to an
>> >existing single-cipher product is no harder than adding a single ("the") AES
>> >cipher; negotitaion is required.
>>
>> That is wrong.  Negotiation is not necessarily required, although the
>> receiver does need to figure out or know by prior configuration which
>> cipher is in use.  "Negotiation" involves proposing, rejecting,
>> counter-proposing, and accepting.
>
>No.
>
>In your experience negotiation may actually be an interactive process, and for DCN it
>could be made arbitrarily complex.  But your argument appears to be that it is
>necessarily very complex.  You have yet to support your position.

Either you or Terry Ritter described the dynamic cipher process as one
system proposing a cipher and the other agreeing or rejecting it.  That
is necessarily your "interactive process" and what I call "negotiation."
It is a good description of PPP and other negotiating protocols.

It is also very different from the mechanisms used to handle upward
compatibility.  In those cases, the newer system recognizes the old stuff,
and copes.  There is no requesting, rejecting, and counter proposing
between peers.  The old system is by definition too stupid to understand
the new stuff, and so the new system does whatever is necessary.


>In fact "negotiation" may imply more work than needs to be done.  Perhaps you would
>feel more comfortable with the term "configuration".   Whatever you call it, it could
>be a simple as one end sending propose-cipher-change accompanied by the target cipher
>and a sample encryption of a standard probe message, all covered by the current
>cipher.  The other end sends either accept or reject, at which point the process is
>complete.

Once again, that last is the sum total of the purpose of the PPP state
machine, and it's inevitiable boundary cases, error paths,and other
complications found when you write a complete state machine that are the
root cause of the real world problems I keep talking about.


>Now to me, as a practicing engineer, a complex configuration change means upgrading the
>system software on a multi-user computer without disturbing the users except that they
>cannot type during the hardware reboot process.  That happens to be the first project I
>undertook out of school.  It worked.  I belive that qualifies me to comment on the
>complexity of software negotiations.

No, while system installation, configuration, and upgrading are often
major hassles and can be iterative, they are very different from what
computers do in a negotiating network protocol.


Please do not bother responding.


Vernon Schryver    vjs@rhyolite.com


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Mon, 25 Oct 1999 12:19:29 -0400
From: "Trevor Jackson, III" <fullmoon@aspi.net>
Message-ID: <38148311.ADAFCFCB@aspi.net>
References: <7uvb7e$q7s$1@calcite.rhyolite.com>
Newsgroups: sci.crypt
Lines: 175

Vernon Schryver wrote:

> In article <38131CDC.40A35B01@aspi.net>,
> Trevor Jackson, III <fullmoon@aspi.net> wrote:
>
> > ...
> >> Only salescritters or people with no technical knowledge can claim that
> >> either PPP or modems are examples that could cause a working engineer to
> >> be enthusaistic about negotiating ciphers.  Sane, technically inclined
> >> people who look at modems, PPP, or any other "standardized", dynamic
> >> negotiating network protocol must be very skeptical of the idea.
> >
> >Any other?  I think not.
> >
> >You can pick on negotiation failures typically those that evolved over time, which
> >usually means layers of kludge upon kludge, sometimes driven by commercial issues
> >(PPP),
>
> Base on that statement, you have no idea of the history or even nature of
> PPP.  PPP in general and PPP negotiating in particular are as much as was
> possible the exact opposite of something "that evolved over time."

So.  In a previous post you alluded to the fact that the first implementations weren't
quite as functional or correct as later implementations.  If this is not "evolution
over time" what is the term you use for it?

> (Before you argue with me about the history of PPP, please tell me under
> what name I can find your words in the IETF PPP WG archives.)
>
> >       and sometimes driven by technological advances (modems).
>
> That notion of the history of modems is also as wrong, based on what I've
> observed since before dial-up 1200 bit/sec modems were available
> (1,200 bit/sec, not 12,000 bps).

Are we competing on ages or something?  I've got half a dozen 300 baud modems floating
around here someplace, and a couple of monster 1200 baud mini computer modems.  I know
what got us from there to here.  It wasn't a trivial process.  It was ugly then and is
still ugly now.

I do not belive this is an appropriate basis for comparison with dynamic cipher
negotiation (DCN).

> >OTOH, you have failed to note the cases in which negotiation is so successful that
> >it is almost invisible.  Consider DECnet.  Once a machine is configured there is
> >little chance of failure.  You hook up the wires and the machine figures out wht
> >topology necessary to communicate with other machines.  This is a negotiation
> >protocol that works.
>
> Have you ever worked inside a DECnet implementation?

Yes.  At the driver level.  I'm sure you can identify a DRV-11B.

>  I have been paid to
> port and hack code that implemented Phase IV, and then to deal with problem
> reports from customers that the technical support people could not answer.
> To say the least, I do not agree with your claim that DECnet "is a
> negotation protocol that [always] works."

Of course it does not always work.  Nothing does.

Point is that it is a vaible architecture.  One still in use in high performance
systems because it is perceived to be superior, and those making the decisions have
measurements to prove it.

> Even the claim that DECnet was a "negotation protcol" is not quite true
> in my view.

OK, let's argue that some other time.  It certainly is a dynamic environment, which is
enough to support the case I was presenting.

>
>
> >Note that this class of error, noticing only the problems, is a basic wheel
> >approach which causes sampling error.
> >There is no alue to this sort of anecdotal horror story.  If you want to address
> >the topic of negotiating protocols, please produce an issue that you believe will
> >be difficult to solve and lead to negotiation failures.
>
> You're evidently as much of a "practicing engineer" as Terry Ritter.
> My point is that in theory, there are no non-trivial problems that would
> need attention, but in practice there always are.
> In theory, there are no anecdotes that do not conform to theory.
> Practice consists of anecdotes.

Garbage.  I am nothing BUT a practicing engineer.

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?

>
>
> > ...
> >Not relevant.  We aren't faced with "complicated network stuff" or anything
> >similar.  Anyone adding one or more  AES ciphers to an existing multi-cipher
> >product already the the problem and a solution.  Adding several AES ciphers to an
> >existing single-cipher product is no harder than adding a single ("the") AES
> >cipher; negotitaion is required.
>
> That is wrong.  Negotiation is not necessarily required, although the
> receiver does need to figure out or know by prior configuration which
> cipher is in use.  "Negotiation" involves proposing, rejecting,
> counter-proposing, and accepting.

No.

In your experience negotiation may actually be an interactive process, and for DCN it
could be made arbitrarily complex.  But your argument appears to be that it is
necessarily very complex.  You have yet to support your position.

In fact "negotiation" may imply more work than needs to be done.  Perhaps you would
feel more comfortable with the term "configuration".   Whatever you call it, it could
be a simple as one end sending propose-cipher-change accompanied by the target cipher
and a sample encryption of a standard probe message, all covered by the current
cipher.  The other end sends either accept or reject, at which point the process is
complete.

Now to me, as a practicing engineer, a complex configuration change means upgrading the
system software on a multi-user computer without disturbing the users except that they
cannot type during the hardware reboot process.  That happens to be the first project I
undertook out of school.  It worked.  I belive that qualifies me to comment on the
complexity of software negotiations.


>  "Negotiation" is not inolved in asking
> the wire for a network address and accepting whatever you get.  It is also
> not merely looking at a header to identify a packet format or cipher.
> Asking for a DHCP or BOOTP address or picking a decryption scheme and key
> based on a packet header has as much to do with "negotiating" as buying
> groceries in a typical American supermarket, nothing whatsoever.

Your lack of experience is showing.  Do you have a particular issue with cipher
selection or are you reacting to the term "negotiation" instead of the referent the
term indicates?

>
>
> >                            creating a new product is the only case in which
> >the requirement to negotiate cipher selection is an issue.  Note that this is
> >going to be common for reasona of backward compatibility during the
> >changeover/upgrade period.
>
> Nonsense.  Upward compatiblity does *not* need negotiating, but merely
> recognizing the old form.  Negotiating is required if you want to
> have the sender and receiver have potentically non-overlapping sets
> of ciphers and to discover and agree on the best common cipher.
> It is also required by Terry Ritters proposals.
>
> Moreover, the "changeover/upgrade period" for protocols invariably lasts
> a very long time.  A case study of how long that can be is in the endurance
> of DECnet Phase IV which has been officially obsolete and deprecated for
> more than 10 years, but which is still a common form of DECnet (where
> DECnet still exists).
> Because of embedded systems, changes in cipher protocols take even longer.

Exactly.  This is why we should design in the requirement for flexibility as early as
possible rather than wishing away the issues that madate it.

>
>
> > ...
> >You cannot just wish this requirement away.  Nor can you ignore the ubiquity of
> >the issue and claim that multiple AES selections creates an abnormal condition.
> >As discussed above it is probably normal to have multiple ciphers.
> > ...
>
> And you cannot just wish requirements into existence.
> AES is not the first new cipher in history.  Ciphers have been coming and
> going for decades.  Still, negotiating ciphers is not universal, and
> where it is done, not without significant security problems in
> practice but not theory (e.g. SSL).

Your assertions support my conclusion and not your own.  Thank you.




Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Mon, 25 Oct 1999 00:14:16 -0600
From: jgfunj@vgrknf.arg (wtshaw)
Message-ID: <jgfunj-2510990014160001@dial-243-047.itexas.net>
References: <3812005b.8360995@news.io.com>
Newsgroups: sci.crypt
Lines: 46

In article <3812005b.8360995@news.io.com>, ritter@io.com (Terry Ritter) wrote:
> 
> Cipher negotiation can be far cleaner -- provided a single selection
> mechanism is standardized.  If not, then we may see the same sort of
> ad hoc stuff we saw with modems.  
...
> 
> Because the need is to change ciphers frequently, the desired
> negotiation process is not one-time at the start, but rather, a
> frequent or continuous process in different messages or sessions.  
> 
....
> 
> There is no other possibility, unless you wish to depend upon the
> strength of a cipher which explicitly HAS *no* known or guaranteed
> strength.  Not having strength is not a trivial detail, this is the
> essence of the reason for using a cipher.  
> 
> The ability to change ciphers offers each of us the power to choose
> what cipher we want to use.  This means no government organization is
> edicting our use, or forcing it through market pressure.  We get to
> choose what to use, and what not to use, and to change our minds on a
> daily basis.  That is not a trivial advantage.
> 
Well, how clean can it be: Figure that you have a list of ciphers which
you will accept.   It is up to the sender to speak in one or them, at
least.

Figure that you develop a means of generating a key for any of them, but
from something which may be acceptable in form to anyone of them, text of
some sufficient length.

The recepient generates all the keys as needed, tries one at a time with
an appropriate algorithm on the ciphertext.  The system should lock to the
one with the most appropriate recovered plaintext, likely only one that
makes sense.

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.

Sounds simple enough to me, but who am I to judge?
-- 
Sometime ago, Gates bought lots of shares of Apple.
My preference is to keep the Worm out of the Apple.


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Mon, 25 Oct 1999 08:14:16 +0200
From: jgfunj@vgrknf.arg (jgfunj@vgrknf.arg)
Message-ID: <fc.3b9aca00f7d881713b9aca008f91dec6.10ab1@peg.dyndns.org>
References: <jgfunj-2510990014160001@dial-243-047.itexas.net>
Newsgroups: sci.crypt
Lines: 48

In article <3812005b.8360995@news.io.com>, ritter@io.com (Terry Ritter)
wrote:
>> 
>> Cipher negotiation can be far cleaner -- provided a single selection
>> mechanism is standardized.  If not, then we may see the same sort of
>> ad hoc stuff we saw with modems.  
...
>> 
>> Because the need is to change ciphers frequently, the desired
>> negotiation process is not one-time at the start, but rather, a
>> frequent or continuous process in different messages or sessions.  
>> 
....
>> 
>> There is no other possibility, unless you wish to depend upon the
>> strength of a cipher which explicitly HAS *no* known or guaranteed
>> strength.  Not having strength is not a trivial detail, this is the
>> essence of the reason for using a cipher.  
>> 
>> The ability to change ciphers offers each of us the power to choose
>> what cipher we want to use.  This means no government organization is
>> edicting our use, or forcing it through market pressure.  We get to
>> choose what to use, and what not to use, and to change our minds on a
>> daily basis.  That is not a trivial advantage.
>> 
Well, how clean can it be: Figure that you have a list of ciphers which
you will accept.   It is up to the sender to speak in one or them, at
least.

Figure that you develop a means of generating a key for any of them, but
from something which may be acceptable in form to anyone of them, text of
some sufficient length.

The recepient generates all the keys as needed, tries one at a time with
an appropriate algorithm on the ciphertext.  The system should lock to the
one with the most appropriate recovered plaintext, likely only one that
makes sense.

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.

Sounds simple enough to me, but who am I to judge?
-- 
Sometime ago, Gates bought lots of shares of Apple.
My preference is to keep the Worm out of the Apple.


{}{}{} Posted via Uncensored-News.Com, http://www.uncensored-news.com {}{}{}
{}{}{}{} Only $8.95 A Month, - The Worlds Uncensored News Source {}{}{}{}
{}{}{}{}{} Five News Servers with a BINARIES ONLY Server {}{}{}{}{}


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: 25 Oct 1999 00:51:22 -0600
From: vjs@calcite.rhyolite.com (Vernon Schryver)
Message-ID: <7v0ula$cc9$1@calcite.rhyolite.com>
References: <jgfunj-2510990014160001@dial-243-047.itexas.net>
Newsgroups: sci.crypt
Lines: 41

In article <jgfunj-2510990014160001@dial-243-047.itexas.net>,
wtshaw <jgfunj@vgrknf.arg> wrote:

> ...
>Well, how clean can it be: Figure that you have a list of ciphers which
>you will accept.   It is up to the sender to speak in one or them, at
>least.

> ...
>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.
>
>Sounds simple enough to me, but who am I to judge?

Look at PPP compression for examples of complications.  Compression
is very much like encryption, as has been pointed out here many times,
so you can't just shrug off the PPP compression follies.
For example, what you do when both peers can handle both A and B, but one
strongly prefers A while the other prefers B.  Say one peer has AES type
I hardware but does type II in 8-bit 3 MHz software, and vice versa for
the other peer.  What do you do, and why?

For another example, look at the last ten (10) years of complications
in the PPP IPCP IP address negotiations.

In the initial theories, those problems were too trivial to worry about.
It wasn't until systems got into the field that our noses were rubbed in
the holes in the theories.

The worst result of the compression negotiation complications (as well as
egregious bugs by a large vendor or two, and a dose or two of
embrace-and-extend by a very large software outfit) 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.
-- 


Vernon Schryver    vjs@rhyolite.com


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Mon, 25 Oct 1999 08:51:22 +0200
From: vjs@calcite.rhyolite.com (vjs@calcite.rhyolite.com)
Message-ID: <fc.3b9aca00502e21e63b9aca008f91dec6.10ab7@peg.dyndns.org>
References: <7v0ula$cc9$1@calcite.rhyolite.com>
Newsgroups: sci.crypt
Lines: 43

In article <jgfunj-2510990014160001@dial-243-047.itexas.net>,
wtshaw <jgfunj@vgrknf.arg> wrote:

>> ...
>>Well, how clean can it be: Figure that you have a list of ciphers which
>>you will accept.   It is up to the sender to speak in one or them, at
>>least.

>> ...
>>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.
>>
>>Sounds simple enough to me, but who am I to judge?

Look at PPP compression for examples of complications.  Compression
is very much like encryption, as has been pointed out here many times,
so you can't just shrug off the PPP compression follies.
For example, what you do when both peers can handle both A and B, but one
strongly prefers A while the other prefers B.  Say one peer has AES type
I hardware but does type II in 8-bit 3 MHz software, and vice versa for
the other peer.  What do you do, and why?

For another example, look at the last ten (10) years of complications
in the PPP IPCP IP address negotiations.

In the initial theories, those problems were too trivial to worry about.
It wasn't until systems got into the field that our noses were rubbed in
the holes in the theories.

The worst result of the compression negotiation complications (as well as
egregious bugs by a large vendor or two, and a dose or two of
embrace-and-extend by a very large software outfit) 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.
-- 


Vernon Schryver    vjs@rhyolite.com


{}{}{} Posted via Uncensored-News.Com, http://www.uncensored-news.com {}{}{}
{}{}{}{} Only $8.95 A Month, - The Worlds Uncensored News Source {}{}{}{}
{}{}{}{}{} Five News Servers with a BINARIES ONLY Server {}{}{}{}{}


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Mon, 25 Oct 1999 11:52:04 -0600
From: jgfunj@vgrknf.arg (wtshaw)
Message-ID: <jgfunj-2510991152040001@dial-243-058.itexas.net>
References: <7v0ula$cc9$1@calcite.rhyolite.com>
Newsgroups: sci.crypt
Lines: 19

In article <7v0ula$cc9$1@calcite.rhyolite.com>, vjs@calcite.rhyolite.com
(Vernon Schryver) wrote:
> 
> The worst result of the compression negotiation complications (as well as
> egregious bugs by a large vendor or two, and a dose or two of
> embrace-and-extend by a very large software outfit) 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.

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.  If
someone will not accept the same cipher(s), then you have a problem, so
you only negotiate one list of mutually acceptable ciphers.  Compression
has nothing to do with it, unless both of you agree on a cipher that uses
it.
-- 
Sometime ago, Gates bought lots of shares of Apple.
My preference is to keep the Worm out of the Apple.


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Mon, 25 Oct 1999 12:20:51 -0400
From: "Trevor Jackson, III" <fullmoon@aspi.net>
Message-ID: <38148363.5693C841@aspi.net>
References: <jgfunj-2510990014160001@dial-243-047.itexas.net>
Newsgroups: sci.crypt
Lines: 55

wtshaw wrote:

> In article <3812005b.8360995@news.io.com>, ritter@io.com (Terry Ritter) wrote:
> >
> > Cipher negotiation can be far cleaner -- provided a single selection
> > mechanism is standardized.  If not, then we may see the same sort of
> > ad hoc stuff we saw with modems.
> ...
> >
> > Because the need is to change ciphers frequently, the desired
> > negotiation process is not one-time at the start, but rather, a
> > frequent or continuous process in different messages or sessions.
> >
> ....
> >
> > There is no other possibility, unless you wish to depend upon the
> > strength of a cipher which explicitly HAS *no* known or guaranteed
> > strength.  Not having strength is not a trivial detail, this is the
> > essence of the reason for using a cipher.
> >
> > The ability to change ciphers offers each of us the power to choose
> > what cipher we want to use.  This means no government organization is
> > edicting our use, or forcing it through market pressure.  We get to
> > choose what to use, and what not to use, and to change our minds on a
> > daily basis.  That is not a trivial advantage.
> >
> Well, how clean can it be: Figure that you have a list of ciphers which
> you will accept.   It is up to the sender to speak in one or them, at
> least.
>
> Figure that you develop a means of generating a key for any of them, but
> from something which may be acceptable in form to anyone of them, text of
> some sufficient length.
>
> The recepient generates all the keys as needed, tries one at a time with
> an appropriate algorithm on the ciphertext.  The system should lock to the
> one with the most appropriate recovered plaintext, likely only one that
> makes sense.

This becomes trivial if the initial message contains a standard plaintext.

>
>
> 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.
>
> Sounds simple enough to me, but who am I to judge?
> --
> Sometime ago, Gates bought lots of shares of Apple.
> My preference is to keep the Worm out of the Apple.





Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Tue, 26 Oct 1999 11:09:11 -0600
From: jgfunj@vgrknf.arg (wtshaw)
Message-ID: <jgfunj-2610991109110001@dial-243-006.itexas.net>
References: <38148363.5693C841@aspi.net>
Newsgroups: sci.crypt
Lines: 28

In article <38148363.5693C841@aspi.net>, "Trevor Jackson, III"
<fullmoon@aspi.net> wrote:

> wtshaw wrote:
> 
> > The recepient generates all the keys as needed, tries one at a time with
> > an appropriate algorithm on the ciphertext.  The system should lock to the
> > one with the most appropriate recovered plaintext, likely only one that
> > makes sense.
> 
> This becomes trivial if the initial message contains a standard plaintext.
> 
From time to time I have put in code that looks for text in decryption. 
The simple GIGO is adequate to warn that text was not encrypted.   If
spaces are encrypted one way of the other it is simple to get an average
word length, perhaps variance, or any of many liguistic tests as well.

As you say, putting encrypted text at the beginning makes algorithm
verification reasonable.  
> >
> > 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.
> >
-- 
Sometime ago, Gates bought lots of shares of Apple.
My preference is to keep the Worm out of the Apple.


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Fri, 29 Oct 1999 03:21:24 GMT
From: ritter@io.com (Terry Ritter)
Message-ID: <38191286.5286277@news.io.com>
References: <jgfunj-2510990014160001@dial-243-047.itexas.net>
Newsgroups: sci.crypt
Lines: 91


On Mon, 25 Oct 1999 00:14:16 -0600, in
<jgfunj-2510990014160001@dial-243-047.itexas.net>, in sci.crypt
jgfunj@vgrknf.arg (wtshaw) wrote:

>In article <3812005b.8360995@news.io.com>, ritter@io.com (Terry Ritter) wrote:
>> 
>> Cipher negotiation can be far cleaner -- provided a single selection
>> mechanism is standardized.  If not, then we may see the same sort of
>> ad hoc stuff we saw with modems.  
>...
>> 
>> Because the need is to change ciphers frequently, the desired
>> negotiation process is not one-time at the start, but rather, a
>> frequent or continuous process in different messages or sessions.  
>> 
>....
>> 
>> There is no other possibility, unless you wish to depend upon the
>> strength of a cipher which explicitly HAS *no* known or guaranteed
>> strength.  Not having strength is not a trivial detail, this is the
>> essence of the reason for using a cipher.  
>> 
>> The ability to change ciphers offers each of us the power to choose
>> what cipher we want to use.  This means no government organization is
>> edicting our use, or forcing it through market pressure.  We get to
>> choose what to use, and what not to use, and to change our minds on a
>> daily basis.  That is not a trivial advantage.
>> 
>Well, how clean can it be: Figure that you have a list of ciphers which
>you will accept.   It is up to the sender to speak in one or them, at
>least.

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.  

If agreement never occurs, the user should be notified, but from the
point of view of the cipher change state system, the next change
simply has not yet occurred.  

Also I would support a different cipher in each direction, thus
simplifying the negotiation process.  


>Figure that you develop a means of generating a key for any of them, but
>from something which may be acceptable in form to anyone of them, text of
>some sufficient length.

I would require each cipher to have some sort of hash which takes a
sequence of bytes to the internal keying value for that particular
cipher.  The sequence of bytes could be a textual keyphrase of almost
arbitrary length, or just a random binary.  In this way, we can use
the same key with any cipher we pick, and do not have to pick keys of
a particular form for each particular cipher.   


>The recepient generates all the keys as needed, tries one at a time with
>an appropriate algorithm on the ciphertext.  The system should lock to the
>one with the most appropriate recovered plaintext, likely only one that
>makes sense.

I would require the cipher system to include a hash of the message
with each message.  This is not only to aid dynamically changing the
cipher, but also because using the wrong key is, in my experience, the
major sort of error which users encounter (assuming a stable
implementation).  It is important to detect common user errors.  

So, when the cipher changes, the cipher is *either* the last cipher
used, being used again, or the new cipher, just proposed.  We try the
old one, then the new one.  If the new one is OK, we accept it.  If
neither, the next time we get a message we try both again.  


>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.
>
>Sounds simple enough to me, but who am I to judge?

We can improve the efficiency quite a bit, but that is the general
idea.  Maybe "negotiation" is the wrong word for many people:
Actually, it's a normal sort of handshake that we complete simply by
using the new cipher.  

---
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: Tue, 26 Oct 1999 23:04:06 GMT
From: dianelos@tecapro.com
Message-ID: <7v5c14$q8q$1@nnrp1.deja.com>
References: <3812005b.8360995@news.io.com>
Newsgroups: sci.crypt
Lines: 78

In article <3812005b.8360995@news.io.com>,
  ritter@io.com (Terry Ritter) wrote:

> To start any conversation in cipher, it is currently necessary to
> acquire common keys.  Everyone understands this.  So everyone should
> be well prepared to understand that we can *also* acquire a cipher
> name, or even a cipher itself, in the same way, through the same
> channel.  This is not a big conceptual leap.
>
> Once we have a conversation in cipher, we can assign part of it to a
> "control channel," where negotiation takes place (...)

I quite agree, but maybe the word "negotiation" is not the best one in
this context. We can add to the encrypted data the code necessary for
decrypting it. That is, we can create software objects that include
both data and methods for processing it. 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. If you worry about speed publish
code optimized for several hardware platforms.

No negotiation between the communicating partners takes place for
defining which security algorithms will be used. Simply, the one who
receives an encrypted message (or a challenge for starting a secure
session) checks to see if the code necessary for processing this is
loaded locally. If not, it downloads it from a central repository,
checks its signature, checks whether the signer is to be trusted, and
executes the code (and adds it to the menu of code held locally for
future use). Encryption technology can now grow unhindered by widely
used standards that in the future may become unstable or be left behind.

For this to work of course, we do need one certification standard we
can trust for the long run. Everything else though becomes liquid. If
you write your own email client and want to send mail encrypted by the
second AES winner cascaded with 3DES and ABC and finally with XYZ, just
publish Java code for your super-duper cipher in the central server,
get it certified and assigned a number (or a name for that matter), and
you are done. Your email client will be able to send encrypted mail to
any other email client in the word which will know what to do to
decrypt your messages – if it chooses to accept your messages.

If you don't trust this liquid world and only trust the AES for your
symmetric cipher, then nothing changes. You just send all your messages
flagged as AES messages or even refuse to read any messages not flagged
AES. In a Darwinian world, people who do choose the best algorithms
will thrive; these may very well turn out to be the ones who choose the
AES and not, say, your ciphers or mine. On the other hand, if we
artificially restrict the free competition of algorithms, then in the
end we shall all end using sub-par algorithms.

My basic point is that if *you* own the information you are sending you
might as well define how *you* want to protect it. In other words if
you own information you should be able to structure it any way you
like. I do believe in standards as a way to facilitate communication -
but not as a way to limit how communication will take place. I don't
think there are good technical reasons for restricting the structure of
the communication - after all if you want to talk to a hardwired high
speed link then you may just respect *its* protocols. OTOH I think
there are many security and economic advantages for not imposing one
micro-standard to everybody.

I see some relation to the way a capitalistic society works: as long as
you don't use an illegal method you can manage your properties any way
you like. In this system of free competition, the ones who invent or
choose the most effective methods thrive and drive the rest of the
economy. I think that in the information society of the future we
should also be careful to motivate rather than restrict the free
competition of methods for managing information: the algorithms.

I do see the need for the AES or maybe for a few widely respected
ciphers. I do think that we need good and standardized security
primitives. What we don't need is a high level inflexible standard that
restricts us to use only one or one out of a few given primitives.


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: Wed, 20 Oct 1999 21:00:42 +0200
From: Mok-Kong Shen <mok-kong.shen@t-online.de>
Message-ID: <380E1159.721F0732@t-online.de>
References: <940429167.19519.0.nnrp-12.c2de6a96@news.demon.co.uk>
Newsgroups: sci.crypt
Lines: 31

Brian Gladman wrote:
> 
> Although its quite possible that a better cipher might be constructed by
> combining the techniques used in the AES algorithms in different ways, I am
> rather uncertain that those who have the knowledge to do this would want to
> repeat the process of algorithm development just undertaken for AES all over
> again.
> 
> Moreover, as an outsider to the field of cipher design, I have the
> impression that the problem here is not so much how to jumble things up but
> rather that of knowing whether the result is secure.  I hence suspect that
> more work on the cryptanalysis of the five AES finalists in their current
> form may be more effective in improving algorithm security than the
> synthesis of new algorithms right now.

It is certainly advantageous to have the best people in the crypto
field focus their attention to a few ciphers that are used by the
general public so that any defects could be found as early as
possible. I have little doubt that that will indeed be the case.
We'll soon see a large number of papers on AES just as we have seen
papers on DES in the past, I believe. On the other hand, I consider
it a pity if some good ideas that are specific to the individual
candidates fail to obtain their deserved attention simply because
these candidates don't get into the final round. So 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.

M. K. Shen


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: 21 Oct 99 05:46:26 GMT
From: jsavard@ecn.ab.ca ()
Message-ID: <380ea8b2.0@ecn.ab.ca>
References: <940429167.19519.0.nnrp-12.c2de6a96@news.demon.co.uk>
Newsgroups: sci.crypt
Lines: 35

Brian Gladman (gladman@seven77.demon.co.uk) wrote:
: Mok-Kong Shen <mok-kong.shen@t-online.de> wrote in message
: news:380D8C32.F96649DF@t-online.de...

: > Has anybody made serious thought of the possibility of extracting
: > some of the good ideas from each submitted AES candidate and doing
: > some variations (to avoid patent problems) and putting in some
: > proper ideas of one's own to arrive at a new design? I mean one

Well, I've gone beyond *thinking* about it. Look at Quadibloc II through
Quadibloc VI on my web site.

: Although its quite possible that a better cipher might be constructed by
: combining the techniques used in the AES algorithms in different ways, I am
: rather uncertain that those who have the knowledge to do this would want to
: repeat the process of algorithm development just undertaken for AES all over
: again.

As you point out later, cipher _design_ isn't the hard part:

: Moreover, as an outsider to the field of cipher design, I have the
: impression that the problem here is not so much how to jumble things up but
: rather that of knowing whether the result is secure.  I hence suspect that
: more work on the cryptanalysis of the five AES finalists in their current
: form may be more effective in improving algorithm security than the
: synthesis of new algorithms right now.

But we can take the lessons learned from that cryptanalysis, and put
together some somewhat overdesigned ciphers from it fairly easily.

And Quadibloc III, in particular, shows what I've done to take a lesson
from FROG, and design a single cipher that pretends to be multiple
ciphers.

John Savard


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Wed, 20 Oct 1999 21:00:50 +0200
From: Mok-Kong Shen <mok-kong.shen@t-online.de>
Message-ID: <380E1162.B881144D@t-online.de>
References: <380DFA11.48429AE1@aspi.net>
   <380D8C32.F96649DF@t-online.de>
Newsgroups: sci.crypt
Lines: 33

Trevor Jackson, III wrote:
> 
> It seems that every language ever used has a legacy user community.  Conglomerate
> languages are difficult to work with (i.e., the complexity is a source of bugs).
> Conglomerate ciphers would be a disaster because the complexity would be a source
> of weakness.

I don't like to revive a debate over PL/I that is now more than
two decades old. (But let me say that I didn't even agree with the
critic raised at that time that the language is a conglomerate.)
My point in the previous post was that in my view there are probably
good stuffs in each of the AES candidates and that these (the
ideas) could be utilized in some way to advantage in some future 
designs.

> 
> I believe that by careful combination, layering, one can effectively combine
> ciphers to increase strength.  But one cannot build ciphers as one builds lego
> projects.  Taking apart a few ciphers does not get you pieces that you can
> naturally combine to create a new cipher.  Design concepts, perhaps, are
> reusable.  But a good cipher needs a synergism and inner harmony reminiscent of
> the most elegant math and physics theories.

In my view it depends on the level of abstraction of getting the
relevant stuffs. 'Physically' extracting from different ciphers
and putting them together is impossible. At one level up you
get bad ciphers. Another level up you get something better, and
so on. It is the underlying idea (basic principle) that one needs.
(Like in a math course one should learn the methodology of solving 
problems, while the concrete solution of specific problems in a 
given text book is by itself comparatively less important.)

M. K. Shen


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Fri, 22 Oct 1999 11:55:22 +0200
From: Mok-Kong Shen <mok-kong.shen@t-online.de>
Message-ID: <3810348A.8FF09BDA@t-online.de>
References: <7uodib$vh6$1@nnrp1.deja.com>
   <940406238.7557.0.nnrp-07.c2de6a96@news.demon.co.uk>
Newsgroups: sci.crypt
Lines: 14

bryan.olson@uptronics.com wrote:
> 
> I agree with what Massey said at the first AES conference,
> that the number of rounds should increase with the key
> size.  Of the five finalists, Rijndael is the only one
> that calls for more rounds when using longer keys.

I can well inmagine that it is true that the number of rounds 
should increase with the key size in order to attain an optimal 
design, without however being able to state very concrete and firm
arguments. Do you happen to remember the arguments of Massey? 
Would you please tell these? Thanks.

M. K. Shen


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Wed, 20 Oct 1999 09:34:14 -0700
From: jlundell@resilience.com (Jonathan Lundell)
Message-ID: <jlundell-2010990934140001@207.213.213.113>
References: <380cb79d.5790473@news.visi.com>
   <19991019142122.19497.00000029@ng-cm1.aol.com>
   <380c880a.3619680@news.visi.com>
Newsgroups: sci.crypt
Lines: 17

In article <380cb79d.5790473@news.visi.com>, schneier@counterpane.com
(Bruce Schneier) wrote:

> >When "I" say parallel, I mean multiple encryption (Super AES) for very
> >important data.  I do not mean randomly picking one of many or any similar
> >thing.
> 
> I'm sorry.  That sounds more like serial than parallel.

At the risk of pointing out the obvious, what we have here is a breakdown
of the "weak link" metaphor. "Multiple encryption", or cascading, I
suppose, means serial encryption, yes. But the corresponding physical
analogy in the "weak link" metaphor is parallel links, or chains.

-- 
/Jonathan Lundell.
jlundell@resilience.com


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: 19 Oct 1999 18:38:09 GMT
From: djohn37050@aol.com (DJohn37050)
Message-ID: <19991019143809.19497.00000032@ng-cm1.aol.com>
References: <380f8b12.4395746@news.visi.com>
Newsgroups: sci.crypt
Lines: 36

X9F1 meetings are open, not closed.  Anyone can attend, only members can vote. 
If anyone wants to make a counter-presentation they can, just get on the
agenda.

But it does seem to me that people are talking in circles.

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?
First: But that is complex.
Second: Yes, and it can be handled.
First: It is difficult to do right.
Second: Yes, but if I want to do so, I should be able to do so.
First: But it is complex and may not interoperate.
Second: Life can be complex, negotiate to interoperate.
First: But it will cost more.
Second: Maybe not.  In any case, if one breaks the cost is astronomical.
X9F1: We have multiple asymmetric algs, it makes sense to also have multiple
symmetric algs.
First: Whoa, that was a dumb decision after a one-sided pitch, if it even was a
decision.
Second: It was a vote, actually 2 votes.
First: Well, they did not know what they were doing.
Second: Maybe they do.

Both have their points and perspectives.  I guess it will be an interesting 3rd
AES conference.
My attitude is yes, having more than one means someone may get it wrong, but
this is not a reason not to have it.  

Do we have redundant computers on space missions?  Why?
Do we have redundant brake systems on cars?  Why?

It is simpler and cheaper not to do this, but there are reasons to add
complexity.  Safety and security reasons.
Don Johnson


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Wed, 20 Oct 1999 11:32:08 +0200
From: Mok-Kong Shen <mok-kong.shen@t-online.de>
Message-ID: <380D8C18.F251FF3A@t-online.de>
References: <7ujled$1vrq@enews1.newsguy.com>
   <19991019143809.19497.00000032@ng-cm1.aol.com>
Newsgroups: sci.crypt
Lines: 18

Roger Schlafly wrote:
> 

> And ciphers have a multiplicity of keys to choose from. If a
> key is compromised, you switch to a different key. The AES
> candidates have a very large key space.

If a cipher has weakness that can be exploited, like DES in respect
of differential analysis etc., a very large key space alone doesn't
necessarily give one a very good and comfortable feeling of security, 
I am afraid. (I gave though recently in another thread that DES can 
be rendered immune to differential analysis simply via using variable 
keys for the blocks, a method which is evidently also applicable to 
AES.)

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: 20 Oct 1999 03:16:49 GMT
From: djohn37050@aol.com (DJohn37050)
Message-ID: <19991019231649.22027.00000075@ng-cm1.aol.com>
References: <MPG.1276b7f2f5c996fd98971b@news.mindspring.com>
Newsgroups: sci.crypt
Lines: 11

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.  

I am certain there are other examples like this.

And what is the US government supposed to do if their only pick breaks?  Hurry
up and certify another algorithm?  Guess and pick a non-certified one?  It is
clear to me that for SOME scenarios, it is mandatory to have more than one AES
winner.
Don Johnson


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Tue, 19 Oct 1999 23:38:11 -0400
From: "Trevor Jackson, III" <fullmoon@aspi.net>
Message-ID: <380D3923.8B5E1D50@aspi.net>
References: <19991019231649.22027.00000075@ng-cm1.aol.com>
Newsgroups: sci.crypt
Lines: 34

DJohn37050 wrote:

> 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.
>
> I am certain there are other examples like this.
>
> And what is the US government supposed to do if their only pick breaks?  Hurry
> up and certify another algorithm?  Guess and pick a non-certified one?  It is
> clear to me that for SOME scenarios, it is mandatory to have more than one AES
> winner.

Let's consider this in a bit more detail.  What would happen if a suspicion were
cast over "the" single AES winner?  Not a catastrophic break, but, say, a
non-constructive proof that a weakness of such-and-such work factor existed.  We'd
want to activate a backup.

I just came from a Personal Protection course where, among other things, one
learns the rules of various forms of fighting.  Rule #1 of a gunfight is "Have a
gun."

To activate a backup on must "have a backup".  If NIST's contest results were
presented using a win/place/show ranking system we could use the "place" cipher as
a secondary or backup mechanism to be deployed only in mission-critical systems.
For truly serious systems, like NASA's man-rated systems criteria, we could
provided a tertiary cipher with the "show" entry.

This proposal suggests that NIST apply a _ranking_ to the ciphers rather than a
binary accept/reject result.  Given a clear "winner" most of the
simplicity/cost/interoperability/standardization arguments disappear.  We'd _have_
a winnner.  But we'd also have alternates.  Backups.  Options in case of disaster
or better optimization for particular applications.



Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Wed, 20 Oct 1999 19:05:59 GMT
From: bryan.olson@uptronics.com
Message-ID: <7ul3qc$je6$1@nnrp1.deja.com>
References: <380D3923.8B5E1D50@aspi.net>
Newsgroups: sci.crypt
Lines: 30

Trevor Jackson, III wrote:

> I just came from a Personal Protection course where, among other
things, one
> learns the rules of various forms of fighting.  Rule #1 of a gunfight
is "Have a
> gun."

Nope.  It's "Stay out of gunfights".


> To activate a backup on must "have a backup".  If NIST's
> contest results were presented using a win/place/show ranking system
[...]
> For truly serious systems, like NASA's man-rated
> systems criteria, we could provided a tertiary cipher
> with the "show" entry.

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.  We can't
un-send encrypted messages.  When we encrypt a
message under cipher X, we depend on X for as
long as that message remains sensitive.

--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: Wed, 20 Oct 1999 16:38:10 -0400
From: "Trevor Jackson, III" <fullmoon@aspi.net>
Message-ID: <380E2832.B7397664@aspi.net>
References: <7ul3qc$je6$1@nnrp1.deja.com>
Newsgroups: sci.crypt
Lines: 41

bryan.olson@uptronics.com wrote:

> Trevor Jackson, III wrote:
>
> > I just came from a Personal Protection course where, among other
> things, one
> > learns the rules of various forms of fighting.  Rule #1 of a gunfight
> is "Have a
> > gun."

> Nope.  It's "Stay out of gunfights".

That's a low-numbered rule of suvival.  Different, enclosing domain.

>
>
> > To activate a backup on must "have a backup".  If NIST's
> > contest results were presented using a win/place/show ranking system
> [...]
> > For truly serious systems, like NASA's man-rated
> > systems criteria, we could provided a tertiary cipher
> > with the "show" entry.
>
> 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.  We can't
> un-send encrypted messages.  When we encrypt a
> message under cipher X, we depend on X for as
> long as that message remains sensitive.

Yes, absolutely.  For those very serious situations I'd suggest multiple
encipherment.

For the high-volumne, short message lifetime applications, like banking
networks, we'd want a backup in reserve to counteract the systemic effects
of a post-release detection of weakness similar to what may be going on the
the French banking system.

Both of the above scenarios make multiple NIST selections valuable.




Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Wed, 20 Oct 1999 12:52:06 -0600
From: jcoffin@taeus.com (Jerry Coffin)
Message-ID: <MPG.1277a283679dedad98971e@news.mindspring.com>
References: <19991019231649.22027.00000075@ng-cm1.aol.com>
Newsgroups: sci.crypt
Lines: 48

In article <19991019231649.22027.00000075@ng-cm1.aol.com>, 
djohn37050@aol.com says...
> 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.  
> 
> I am certain there are other examples like this.
> 
> And what is the US government supposed to do if their only pick breaks?  Hurry
> up and certify another algorithm?  Guess and pick a non-certified one?  It is
> clear to me that for SOME scenarios, it is mandatory to have more than one AES
> winner.

I'm not sure I'd go _nearly_ this far.  On one hand, I agree that 
having some sort of backup in a satellite is a good idea.

OTOH, I don't think it necessarily makes a lot of sense to use 
communication satellites as the basis upon which decisions about AES 
are made.  They're clearly a VERY limited market, and unless I'm badly 
mistaken, most satellites normally only communicate with a limited 
number of ground stations.  The main reason more than one algorithm 
would be needed would be if there was a government agency that owned a 
satellite used for sensitive but unclassified information so they were 
mandated to use AES.  I'm not aware of any government agencies in this 
situation: the military owns many satellites, but most of them are 
equipped to deal with classified information, which will presumably be 
placed outside the AES arena, much as it has been with DES.

For other companies, etc., that own satellites, using two or more 
algorithms is fine, but there's no requirement that any of the 
necessarily be AES.  In addition, the satellite could include only one 
algorithm, but implement it in an FPGA rather than hard-wired logic.  
In this case, when/if necessary, the satellite could be re-programmed 
remotely to implement a different algorithm.  I don't know much about 
system architecture of satellites, it offhand it seems like it would 
be a bare minimum of good sense to make them as re-programmable as 
possible from the ground.

To summarize: I don't think simply invoking "hardware designs" is a 
sufficient reason to say that AES must have only one algorithm.  OTOH, 
I don't think invoking "satellites" is a sufficient reason to say that 
it must have more than one either.

-- 
    Later,
    Jerry.
 
The universe is a figment of its own imagination.


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Wed, 20 Oct 1999 23:04:50 -0700
From: "Roger Schlafly" <real@ieee.org>
Message-ID: <7umabi$144v@enews1.newsguy.com>
References: <380e7293.821932@news.visi.com>
   <19991019231649.22027.00000075@ng-cm1.aol.com>
Newsgroups: sci.crypt
Lines: 16

Bruce Schneier <schneier@counterpane.com> wrote in message
news:380e7293.821932@news.visi.com...
> I give up.  It's frustrating to argue real-world constraints with
> people who don't deal with real-world constraints.  People in this
> thread have argued that 8-bit processors aren't important, that people
> who use cryptography don't care about performance, that protocols to
> negotiate arbitrary ciphers are more secure than single-cipher
> protocols, that randomly choosing among a set of ciphers is more
> secure than a single cipher, and a variety of other things.  It's just
> not worth my time anymore.

I think they oppose standards for ideological or business reasons.
Most of these arguments could be used against any standard.





Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Thu, 21 Oct 1999 00:07:26 -0600
From: jcoffin@taeus.com (Jerry Coffin)
Message-ID: <MPG.12785b5dcad647ba989731@news.mindspring.com>
References: <380e7293.821932@news.visi.com>
   <19991019231649.22027.00000075@ng-cm1.aol.com>
Newsgroups: sci.crypt
Lines: 35

In article <380e7293.821932@news.visi.com>, schneier@counterpane.com 
says...
> On 20 Oct 1999 03:16:49 GMT, djohn37050@aol.com (DJohn37050) wrote:
> 
> >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.  
> >
> >I am certain there are other examples like this.
> 
> It's a moronic example.  Do you really think that satellites are
> thrown away if there are software bugs?  Even NASA probes have
> uploadable software.

In this case what prevents the opponent from uploading a bit of new 
programming that just sends him the key being used?  The obvious thing 
would be a MAC on the programming message.

Now, of course the opponent has two possible avenues of attack: 
breaking either the core cipher OR the MAC allows the enemy access to 
the satellite.  This sounds suspiciously similar to the scenarios you 
describe as an undesirable result of having more than one winner in 
the AES competition.

Maybe my example really was moronic, but if so I don't think 
uploadable programming of the cipher is what puts it into that 
category.  I'm not sure I'd go so far as to call your response 
moronic, but at least as it was presented, it doesn't sound to me like  
a good way to enhance security.

-- 
    Later,
    Jerry.
 
The universe is a figment of its own imagination.


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Thu, 21 Oct 1999 10:41:52 +0200
From: Mok-Kong Shen <mok-kong.shen@t-online.de>
Message-ID: <380ED1D0.9B71B61F@t-online.de>
References: <380e7293.821932@news.visi.com>
   <19991019231649.22027.00000075@ng-cm1.aol.com>
Newsgroups: sci.crypt
Lines: 32

Bruce Schneier wrote:
> 

> I give up.  It's frustrating to argue real-world constraints with
> people who don't deal with real-world constraints.  People in this
> thread have argued that 8-bit processors aren't important, that people
> who use cryptography don't care about performance, that protocols to
> negotiate arbitrary ciphers are more secure than single-cipher
> protocols, that randomly choosing among a set of ciphers is more
> secure than a single cipher, and a variety of other things.  It's just
> not worth my time anymore.
> 
> Good luck with your agenda.

In one point Mr. Schneier has clearly and definitely erred, namely
concerning his phrase about randomly choosing a cipher. Randomly
choosing among a set of ciphers can NEVER be weaker than the
weakest of the set. If ciphers in a set are of equal strength (
or not known to be of differing strength) then randomly choosing is 
evidently a superior stategy. If one cipher is stronger than the
others, the usefulness of random choosing will depend on the
strength differences and the cardinality of the set and can't be
evaluated simply. On the assumption that there are 3 ciphers
of the final round of AES that are equally or extremely nearly 
equally strong, it is almost sure that random choosing is a much
better strategy.

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

M. K. Shen


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Thu, 21 Oct 1999 13:11:31 +0100
From: "Brian Gladman" <gladman@seven77.demon.co.uk>
Message-ID: <940507920.9242.0.nnrp-14.c2de6a96@news.demon.co.uk>
References: <380ED1D0.9B71B61F@t-online.de>
Newsgroups: sci.crypt
Lines: 62

Mok-Kong Shen <mok-kong.shen@t-online.de> wrote in message
news:380ED1D0.9B71B61F@t-online.de...
> Bruce Schneier wrote:

> In one point Mr. Schneier has clearly and definitely erred, namely
> concerning his phrase about randomly choosing a cipher. Randomly
> choosing among a set of ciphers can NEVER be weaker than the
> weakest of the set. If ciphers in a set are of equal strength (
> or not known to be of differing strength) then randomly choosing is
> evidently a superior stategy. If one cipher is stronger than the
> others, the usefulness of random choosing will depend on the
> strength differences and the cardinality of the set and can't be
> evaluated simply. On the assumption that there are 3 ciphers
> of the final round of AES that are equally or extremely nearly
> equally strong, it is almost sure that random choosing is a much
> better strategy.

I do think, however, that there have to be fair ground rules for such a
comparison and I think this is what Bruce is saying.

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.

If we postulate that all ciphers achieve a strength implied by their
keyspace, we will not have achieved anything other than increasing the
complexity of our system.  So we have to assume unequal strength ciphers in
order to see possible advantages.  But when the two cipher scheme is
employed with algorithms of known strength it makes no sense to choose the
weaker of the two so we also have to also assume that we do not know which
of the algorithms is stronger.

In the two algorithm scheme we will hence find that 50% of our messages will
be more strongly protected and 50% less so. In contrast when we use a single
algorithm, since we don't know which is stronger, we have to 'toss a coin'
and we hence find that there is a 50% chance that we end up with either more
or less protection for all our messages.  Which outcome is better is pretty
unclear.

But we have an extra key bit to use so provided the weaker algortihm exceeds
a strength implied by one half of its keyspace we will win on average by
choosing a single algorithm rather than by choosing between two.   Whether
we can expect a weak algorithm to have given up more or less than half its
keyspace I have no idea (we might look at some past failed algorithms to
assess what the probabilities are here).

In overall terms I agree with Bruce here - I am doubtful that any schemes of
this type will achieve much other than increasing the complexity of our
system and hence reducing the prospects of a correct system implementation.

Deployed diversity (as distinct from diversity of choice during design) will
increase the complexity of our system and this means that we really should
see a big win if we are going to use it.

There are good arguments for algorithm diversity but I personally doubt that
they lie in this direction.

    Brian Gladman





Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Fri, 22 Oct 1999 09:01:35 -0400
From: "Trevor Jackson, III" <fullmoon@aspi.net>
Message-ID: <3810602F.DDB77E65@aspi.net>
References: <7uotnb$n28$1@blowfish.isaac.cs.berkeley.edu>
   <940541039.4744.0.nnrp-03.c2de6a96@news.demon.co.uk>
Newsgroups: sci.crypt
Lines: 93

David Wagner wrote:

> I have some rather large quibbles with your model.
>
> But let me first state up front that I believe very much in your general
> methodology.  If we can form a reasonable model and make some quantitive
> risk estimates on the basis of that model, that would be a powerful
> argument for whether to select multiple winners or not.

How can you form quantitative risk estimates?  Could you provide an example of
such a calculation?  I'm reminded of NASA's quantitative risk estimate that the
odds of a shuttle disaster were 1:100,000.

Do you intend your estimates to be (contrary to NASA's) defensible?  Testable?
Scientifically verifiable?  What standard of rigor would you accept as useful?


> Now, back to my quibbles.  I have a big bone to pick with your model; I
> believe it is unrepresentative in a number of important ways.  I'll list
> just two:
> 1. It counts the total amount of work required to break _all_ messages.
>    This is asking too much of the adversary; it is already disastrous
>    if the adversary can read only 10% of our traffic.  IMHO a better
>    metric would be the expected number of messages that can be read by
>    an adversary with a given amount of resources.
> 2. In practice, we can do better than random selection of our ciphers.
>    While we may not have perfect knowledge on which algorithms are most
>    secure, we can form some rough estimate or some approximate relative
>    ranking.

How?  The error range on our estimates is so large that for all intents and
purposes all ciphers with similar key size and no known weaknesses are
approximately equal.

On what basis should we select?  strength: see above.  performance: depends
strongly on application context.

After we've weeded out the weaker ciphers there's no dominating property that
provides the equivalent of a pareto-optimal choice.  Since there are multiple
dimensions to the feature/benefit space it probably isn't possible to
objectively order the remaining candidates.

If, for instance, we had three or four criteria and five candidates none of
which dominate or almost dominate in all criteria the selection of a cipher for
a specific application is sensitive to the weights the particular application
environment places on each criteria.  Selecting a single winner in the general
case means selecting without regard to the criteria weights or by averaging the
specific environment weights in some way.

The averaging process, or the decision to ignore criteria weights completely,
means that the selection of a general "winner" by that method is a NOP.  It
means nothing to the designer/implementor faced with a particular application.
In almost every case the designer/implementor is better off applying the
criteria weights particular to his problem in order to choose from a set whose
elements are diverse.

OTOH, consideration of the actual criteria and their importance (ranking) may
produce a trivial solution.  One cipher _might_ stand out so much that it's
choice is obvious.  Extrema do occur.  However, this is the case in which a
unique selection by NIST is gilding the lily.  They only have to point out the
superiority of the obvious winner,  Selecting secondary (place & show) ciphers
would not dilute the preference for the "winner".




>  Although we can't be sure which AES finalist is strongest,
>    surely our best experts can do better than mere coin-flipping at
>    picking the best algorithm!  If not, there's little point in taking
>    the AES process any further.

This is exactly the point of multiple selections.  There's no reason to  take
the AES process further than the point at which we say "no known weakness".

> If you take these factors into consideration, I claim that the conclusion
> regarding multiple ciphers changes drastically.
>
> I'd like to take this opportunity to plug my own model.  I put together
> a more sophisticated and (I like to believe) more credible model of the
> risks in an earlier sci.crypt post, about a month or two ago.  On the
> basis of this model, I argued that using multiple ciphers would actually
> decrease overall security.  These posts inspired some lengthy discussions
> from others on the merits of the proposed model.
>
> Since we seem to see eye-to-eye at least on the methodology, if not on
> the model, I'd like to invite you to take a look at those earlier postings.
> If I can convince you to take a look, I'd appreciate any feedback you (or
> anyone else) might have.  Let me know if you'd like me to forward you a
> copy of my earlier posts.

I would be interested in what you consider the definitive statement of your
model.



Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Fri, 22 Oct 1999 20:04:33 +0200
From: Mok-Kong Shen <mok-kong.shen@t-online.de>
Message-ID: <3810A731.D4206CFA@t-online.de>
References: <3810602F.DDB77E65@aspi.net>
Newsgroups: sci.crypt
Lines: 41

Trevor Jackson, III wrote:
> 

> On what basis should we select?  strength: see above.  performance: depends
> strongly on application context.
> 
> After we've weeded out the weaker ciphers there's no dominating property that
> provides the equivalent of a pareto-optimal choice.  Since there are multiple
> dimensions to the feature/benefit space it probably isn't possible to
> objectively order the remaining candidates.
> 
> If, for instance, we had three or four criteria and five candidates none of
> which dominate or almost dominate in all criteria the selection of a cipher for
> a specific application is sensitive to the weights the particular application
> environment places on each criteria.  Selecting a single winner in the general
> case means selecting without regard to the criteria weights or by averaging the
> specific environment weights in some way.
> 
> The averaging process, or the decision to ignore criteria weights completely,
> means that the selection of a general "winner" by that method is a NOP.  It
> means nothing to the designer/implementor faced with a particular application.
> In almost every case the designer/implementor is better off applying the
> criteria weights particular to his problem in order to choose from a set whose
> elements are diverse.
> 
> OTOH, consideration of the actual criteria and their importance (ranking) may
> produce a trivial solution.  One cipher _might_ stand out so much that it's
> choice is obvious.  Extrema do occur.  However, this is the case in which a
> unique selection by NIST is gilding the lily.  They only have to point out the
> superiority of the obvious winner,  Selecting secondary (place & show) ciphers
> would not dilute the preference for the "winner".

Very well said. 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. It will be more like ranking the top three girls 
in the miss world contest. All girls are pretty but everybody will 
have his subjective ranking not necessarily identical to that
pronounced by the jury.

M. K. Shen


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Sat, 23 Oct 1999 18:41:57 GMT
From: ritter@io.com (Terry Ritter)
Message-ID: <381200e4.8497981@news.io.com>
References: <940507920.9242.0.nnrp-14.c2de6a96@news.demon.co.uk>
Newsgroups: sci.crypt
Lines: 134


On Thu, 21 Oct 1999 13:11:31 +0100, in
<940507920.9242.0.nnrp-14.c2de6a96@news.demon.co.uk>, in sci.crypt
"Brian Gladman" <gladman@seven77.demon.co.uk> wrote:

>Mok-Kong Shen <mok-kong.shen@t-online.de> wrote in message
>news:380ED1D0.9B71B61F@t-online.de...
>> Bruce Schneier wrote:
>
>> In one point Mr. Schneier has clearly and definitely erred, namely
>> concerning his phrase about randomly choosing a cipher. Randomly
>> choosing among a set of ciphers can NEVER be weaker than the
>> weakest of the set. If ciphers in a set are of equal strength (
>> or not known to be of differing strength) then randomly choosing is
>> evidently a superior stategy. If one cipher is stronger than the
>> others, the usefulness of random choosing will depend on the
>> strength differences and the cardinality of the set and can't be
>> evaluated simply. On the assumption that there are 3 ciphers
>> of the final round of AES that are equally or extremely nearly
>> equally strong, it is almost sure that random choosing is a much
>> better strategy.
>
>I do think, however, that there have to be fair ground rules for such a
>comparison and I think this is what Bruce is saying.

I think it fascinating how many people seem to feel that Schneier's
words need their personal interpretation, and that they are qualified
to do that.  Something is wrong here:  Schneier is a professional
author.  Presumably he understands his words.  If something he
presents requires interpretation by someone else, not only has he not
presented it right, it actually (gasp!) may be wrong.  

If he says something outrageous, let it stand.  Criticize exactly what
he says.  We will never know what he means if his words are free to be
re-interpreted at will by all and sundry.  I find it likely that each
new interpretation is due more to the interpreter than the original
content.  

Let messages stand or fall on their content, the exact words, exactly
as they appear.  People can clarify their own errors or
misinterpretations.  Then we get the real scoop instead of a
masticated mess.   


>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.

Well, yes, it would be "reasonable" to ask which would be stronger,
*IF* we could measure strength.  But in the *real* world (that would
be the thing Schneier talks about), we *cannot* measure strength.  We
do not use weak ciphers, so any cipher we do use has unknown strength.


So, obviously, it is NOT "reasonable" to ask which cipher would be
stronger -- if one also expects a reply.


>If we postulate that all ciphers achieve a strength implied by their
>keyspace, 

That is a ridiculous postulation in any case.


>we will not have achieved anything other than increasing the
>complexity of our system.  So we have to assume unequal strength ciphers in
>order to see possible advantages.  But when the two cipher scheme is
>employed with algorithms of known strength it makes no sense to choose the
>weaker of the two so we also have to also assume that we do not know which
>of the algorithms is stronger.

But we do not use weak ciphers, and that means virtually any cipher
which has even theoretical breaks.  So we can never expect to know the
strengths of the ciphers we use.  We may find out about one cipher
some day, and then we will change ciphers and *still* not know how
strong the cipher we use actually may be.  


>In the two algorithm scheme we will hence find that 50% of our messages will
>be more strongly protected and 50% less so. In contrast when we use a single
>algorithm, since we don't know which is stronger, we have to 'toss a coin'
>and we hence find that there is a 50% chance that we end up with either more
>or less protection for all our messages.  Which outcome is better is pretty
>unclear.

By doing that we have put all our eggs in one basket.  We thus depend
upon the strength of that basket -- a strength we can neither prove
nor measure.  We are depending upon the strength of a particular
cipher, and that is something which cannot be depended upon.  

The primary advantage of choosing among multiple ciphers is NOT to
provide keyspace, but instead to allow changing to a new cipher.  This
is an advantage because changing to a new cipher obviously terminates
any break which had been applied to the old cipher.  You can claim all
the analysis you want, but you cannot claim a known strength.  And
without that, you *cannot* depend upon that cipher.  

One of the fundamental problems we have in the real world with ciphers
is that we cannot tell when they have been broken and are exposing our
data.  We cannot tell.  Now what do we do about it?


>But we have an extra key bit to use so provided the weaker algortihm exceeds
>a strength implied by one half of its keyspace we will win on average by
>choosing a single algorithm rather than by choosing between two.   Whether
>we can expect a weak algorithm to have given up more or less than half its
>keyspace I have no idea (we might look at some past failed algorithms to
>assess what the probabilities are here).

The issue in breaking ciphers is only rarely keyspace.


>In overall terms I agree with Bruce here - I am doubtful that any schemes of
>this type will achieve much other than increasing the complexity of our
>system and hence reducing the prospects of a correct system implementation.

Nonsense.  We choose a cipher.  We use it.  We choose another cipher.
We use that.  Yup, pretty tough.


>Deployed diversity (as distinct from diversity of choice during design) will
>increase the complexity of our system and this means that we really should
>see a big win if we are going to use it.
>
>There are good arguments for algorithm diversity but I personally doubt that
>they lie in this direction.

Then you need to re-think your position.

---
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: 23 Oct 99 21:54:43 GMT
From: jsavard@ecn.ab.ca ()
Message-ID: <38122ea3.0@ecn.ab.ca>
References: <381200e4.8497981@news.io.com>
Newsgroups: sci.crypt
Lines: 18

Terry Ritter (ritter@io.com) wrote:
: If he says something outrageous, let it stand.  Criticize exactly what
: he says.

At the risk of being seen to be blowing my own horn, I did just that
recently in response to an article in a recent issue of Crypto-Gram. And
soon enough, he clarified himself, so now it is clear that he means that
user-memorized secrets can't provide security in the case of systems
designed for use by unmotivated employees or consumers, not that it is
absolutely impossible for them to be the basis of secure cryptographic
keys.

Since Mr. Schneier has such a good reputation, however, there is a
tendency to assume he won't intentionally say something that doesn't make
sense. Those of us not basking in public adulation must watch our words
more carefully.

John Savard


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Sun, 24 Oct 1999 00:49:12 +0200
From: Mok-Kong Shen <mok-kong.shen@t-online.de>
Message-ID: <38123B68.CF22A21F@t-online.de>
References: <7ut49g$2t3v@enews3.newsguy.com>
   <381200e4.8497981@news.io.com>
Newsgroups: sci.crypt
Lines: 34

Roger Schlafly wrote:
> 
> Terry Ritter <ritter@io.com> wrote in message
> news:381200e4.8497981@news.io.com...
> > Well, yes, it would be "reasonable" to ask which would be stronger,
> > *IF* we could measure strength.  But in the *real* world (that would
> > be the thing Schneier talks about), we *cannot* measure strength.  We
> > do not use weak ciphers, so any cipher we do use has unknown strength.
> 
> Your extremism on this issue is rather amusing, but it is also absurd.
> It is like saying that you cannot measure building strength -- all you
> can do is wait for an earthquake and see if the building falls down.
> We have building codes and structural engineers to assure building
> strength. Sure, when the earthquake comes, there might be some
> surprises. But if you want a strong house, then there are steps you
> can take that will almost certainly give you a stronger house.

Engineers test building materials in laboratories. With that
knowledge and the theory of mechanics (including elasticity and
plasticity) and the estimated loading they design their structures
employing a factor of safety that is contained in the standards
of building construction. For complicated structures, where a 
satisfactory computation is difficult, one also builds a model to 
be tested. There are formulae that allow the results of the model 
to be transferred to the prototype. Do you think that you can draw 
parallels with the design and investigation of strength of crypto 
algorithms? Consider just the simplest point: 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? And how do you know whether 
a cleverer person may not need less than that 'something' to cause 
it to be broken?

M. K. Shen


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Mon, 25 Oct 1999 07:58:48 +0200
From: jgfunj@vgrknf.arg (jgfunj@vgrknf.arg)
Message-ID: <fc.3b9aca0064361c543b9aca004dfd3b8d.10aaf@peg.dyndns.org>
References: <jgfunj-2410992358480001@dial-243-047.itexas.net>
   <381200e4.8497981@news.io.com>
Newsgroups: sci.crypt
Lines: 29

In article <381200e4.8497981@news.io.com>, ritter@io.com (Terry Ritter)
wrote:

>> On Thu, 21 Oct 1999 13:11:31 +0100, in
>> <940507920.9242.0.nnrp-14.c2de6a96@news.demon.co.uk>, in sci.crypt
>> "Brian Gladman" <gladman@seven77.demon.co.uk> wrote:
>> 
>> >If we postulate that all ciphers achieve a strength implied by their
>> >keyspace, 
>> 
>> That is a ridiculous postulation in any case.

Keyspace depends on what you do with it.
>> 
....
>> The primary advantage of choosing among multiple ciphers is NOT to
>> provide keyspace, but instead to allow changing to a new cipher.  This
>> is an advantage because changing to a new cipher obviously terminates
>> any break which had been applied to the old cipher.  You can claim all
>> the analysis you want, but you cannot claim a known strength.  And
>> without that, you *cannot* depend upon that cipher.  
>>.....
>> The issue in breaking ciphers is only rarely keyspace.

Ah..so much depends on the meaning of strength.
-- 
Sometime ago, Gates bought lots of shares of Apple.
My preference is to keep the Worm out of the Apple.


{}{}{} Posted via Uncensored-News.Com, http://www.uncensored-news.com {}{}{}
{}{}{}{} Only $8.95 A Month, - The Worlds Uncensored News Source {}{}{}{}
{}{}{}{}{} Five News Servers with a BINARIES ONLY Server {}{}{}{}{}


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Sun, 24 Oct 1999 03:39:23 GMT
From: dianelos@tecapro.com
Message-ID: <7utv1b$ldc$1@nnrp1.deja.com>
References: <940507920.9242.0.nnrp-14.c2de6a96@news.demon.co.uk>
Newsgroups: sci.crypt
Lines: 71

In article <940507920.9242.0.nnrp-14.c2de6a96@news.demon.co.uk>,
  "Brian Gladman" <gladman@seven77.demon.co.uk> wrote:

>...
>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.

Interestingly enough, I discussed precisely this question in an older
post:

Take two ciphers A and B with keys of N bits. These ciphers must be
independent in the sense that physically breaking one does not help in
breaking the other. (By "physical break" I mean the work necessary to
recover the key when the cipher is already cryptanalyzed; "logical
break" would be the work necessary to successfully cryptanalyze a
cipher" - in what follows we discuss physical break only). Let us
suppose that these ciphers are not perfect; and therefore there exists
a method (known or unknown) to break them, which is more efficient than
brute force, i.e. the trying of all possible keys. For ciphers A and B
there exists then a method to break them at a cost comparable to 2^
(N*k) operations where k<1 (2^N corresponds to brute forcing them). If
you increase the key length by 1 bit, then you would need 2^((N+1)*k)
=2^N * 2^k operations to break A or B (here I assume A and B are
equally strong, a similar analysis can be done for the case k_A<>k_B ).
If you create a new cipher C with a key of N+1 bits where the last bit
is used to choose either A or B as the working cipher with a key of N
bits, then you must apply the A-attack, and with 50% probability the B-
attack also. The reason is that you don't know whether A or B has been
used; so you try the attack against A to see if it succeds. With 50%
probability it won't succeed and you will have to implement the attack
against B also. Here I assume that the best way to identify which
cipher is being used is that by breaking the cipher – with modern
ciphers I think this is a valid assumption.

So the cost for breaking C is 2^(N*k)+0.5*2^(N*k)=3/2 * 2^(N*k).
Therefore you need more effort to break C with a key of N+1 bits, than
either A or B with a key of N+1 bits, as long as k is less then ln
(3/2)/ln(2) = 0.58. If instead of two ciphers, you started with 2^M
different ciphers, then the results are more dramatic. The average
effort required for breaking the resulting cipher is now 2^(N*K-1)*
(2^M+1) and it will be stronger as long as k < 1/M*(ln(2^M+1)/ln(2) -1)
or for large M: k < 1 - 1/M. So, unless you are prety certain that your
cipher is perfect (k=1) then you are better off choosing one cipher
from as large a pool (M>>1) as possible. In a way, we get a security
amplifier with not cost in speed.

Let us assume, for example, that four AES finalists survive with a
flawless security record. Instead of using any one of them with a 128
bit key we could use the "fourAES" cipher with a 130 bit key. This
cipher will be stronger as long as k<0.66, i.e. as long as we assume
there exists an (unknown) attack that can break the AES finalists with
less than 2^(0.66*128)=2^84 cost. Is this a good assumption? Today, an
attack of 2^84 cost against a 128 bit AES candidate would certainly
kill it. What are the chances that in the next 50 years cryptanalysis
will improve to the level that such powerful attacks are discovered
against an AES finalist class cipher? The answer to that question is
anybody's guess, but it would be best to be on the safe side.

Observe that in my discussion above, the choosing of the cipher depends
on they key. It is not done randomly which would requiere us to add
information to the ciphertext about which cipher has been used. The
latter is probably a bad idea if we assume that the attacker has
sufficient resources to cryptanalyze all alternate ciphers - in that
case the attacker would first attack the ciphertexts produced by the
weakest cipher.


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: Sun, 24 Oct 1999 07:13:22 GMT
From: ritter@io.com (Terry Ritter)
Message-ID: <3812b166.3480429@news.io.com>
References: <7utv1b$ldc$1@nnrp1.deja.com>
Newsgroups: sci.crypt
Lines: 49


On Sun, 24 Oct 1999 03:39:23 GMT, in <7utv1b$ldc$1@nnrp1.deja.com>, in
sci.crypt dianelos@tecapro.com wrote:

>[...]
>Observe that in my discussion above, the choosing of the cipher depends
>on they key. It is not done randomly which would requiere us to add
>information to the ciphertext about which cipher has been used. 

Something seems wrong with this observation:  Keys we use for actual
data encryption generally are *message keys*, and in fact *should* be
random values.  Using a random message key value to select a cipher
sounds rather similar to using a random value to select a cipher.  

Nor would additional information generally be needed, unless the
message key value was so tightly drawn as to have already been used
completely.  In general, it is not a good idea to scrimp on the
message key size.  While we might hope that a message key value would
be 100 percent unpredictable, it is wiser to plan for full cipher
strength with less unpredictability, by using a larger message key.  


>The
>latter is probably a bad idea if we assume that the attacker has
>sufficient resources to cryptanalyze all alternate ciphers - in that
>case the attacker would first attack the ciphertexts produced by the
>weakest cipher.

We certainly would hope that any attacker could not distinguish
between ciphertexts produced by one cipher and another.  One might
even think that an ability to identify a particular cipher from its
ciphertext alone would be a straightforward indication of cipher
weakness.  

Obviously an attacker could try all ciphertexts under the weakest
cipher first, but if the attack requires messages from only a
particular cipher, how would the attacker know which messages to use?


When the cipher itself is changed dynamically on a message-by-message
basis, there should be no way to distinguish the subset of ciphertexts
produced by a particular cipher.  It would thus seem to be hard for an
attacker to even collect the required amount of single-cipher
ciphertext, let alone start any actual attack.  

---
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: Mon, 25 Oct 1999 04:35:01 +0200
From: dianelos@tecapro.com (dianelos@tecapro.com)
Message-ID: <fc.3b9aca0027318a663b9aca004dfd3b8d.10a9a@peg.dyndns.org>
References: <7v0fkl$8tu$1@nnrp1.deja.com>
   <3812b166.3480429@news.io.com>
Newsgroups: sci.crypt
Lines: 123

In article <3812b166.3480429@news.io.com>,
  ritter@io.com (Terry Ritter) wrote:

>> On Sun, 24 Oct 1999 03:39:23 GMT, in <7utv1b$ldc$1@nnrp1.deja.com>, in
>> sci.crypt dianelos@tecapro.com wrote:
>>
>>>[...]
>>>Observe that in my discussion above, the choosing of the cipher
>>>depends on they key. It is not done randomly which would requiere us
>>>to add information to the ciphertext about which cipher has been
>>>used.
>>
>> Something seems wrong with this observation:  Keys we use for actual
>> data encryption generally are *message keys*, and in fact *should* be
>> random values.  Using a random message key value to select a cipher
>> sounds rather similar to using a random value to select a cipher.

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. If you choose the
ciphers by any other method then, by definition, the attacker will
always know which cipher is being used: the attacker can know
everything except the key.

Now if the attacker *does* know which cipher has been used for each
ciphertext block, then he can attack the ciphertext encrypted by the
weakest cipher. Consider this: even though we in the public don't know
the lower bound of security of the individual ciphers we must assume
that a powerful attacker does know. We also can assume that these lower
bounds vary a lot - it would be strange indeed if different ciphers
were very similar in their lower bound of security. So in a pool of
four ciphers it is quite probable that one (the "lemon") is orders of
magnitude weaker than the others and that the attacker knows this. Let
us assume the lemon falls to a known plaintext attack that requires a
small number of known plaintexts. It is true that the attacker will now
have to collect four times more data for the lemon, but this quantity
will be a trifle compared to the plaintext that must be known for
attacking any of the other three ciphers. Therefore the attacker will
easily break 25% of the communications recovering almost all
intelligence. Instead of using this method, we would be better off
choosing one cipher by chance sticking to it.

The situation is very different is the choice of ciphers is unknown to
the attacker, and for that it is necessary that the choice of the
ciphers depend on the key. (There is curious exception: to encrypt the
next block choose the cipher completely at random and send only the
resulting ciphertext. To decrypt, try in sequence the various ciphers
until you get intelligible plaintext.)

>> We certainly would hope that any attacker could not distinguish
>> between ciphertexts produced by one cipher and another.  One might
>> even think that an ability to identify a particular cipher from its
>> ciphertext alone would be a straightforward indication of cipher
>> weakness.

I agree.

>> Obviously an attacker could try all ciphertexts under the weakest
>> cipher first, but if the attack requires messages from only a
>> particular cipher, how would the attacker know which messages to use?
>>
>> When the cipher itself is changed dynamically on a message-by-message
>> basis, there should be no way to distinguish the subset of ciphertexts
>> produced by a particular cipher.  It would thus seem to be hard for an
>> attacker to even collect the required amount of single-cipher
>> ciphertext, let alone start any actual attack.

When the cipher choice is changed dynamically in a way that the
attacker cannot predict, then we do get some very interesting
properties even if the pool contains only two or three ciphers: It
seems a ciphertext only attack on the weak cipher will not work,
because the attacker will not know which ciphertext blocks belong to
it. Known or chosen plaintext attacks will apparently not work either
and for the same reason: even if the attacker chooses the entire
plaintext stream, he cannot collect and analyze the ciphertext blocks
that have been encrypted with the lemon. It does appear that mixing
ciphers can be very useful, but only if the attacker cannot predict
their sequence.

How does one achieve this? Using a few bits of the key to index one in
a pool of N ciphers is not the best way, because then all blocks will
be encrypted with the same cipher. The attacker applies the lemon-
attack and with 1/N probability it will work. Using the key to start a
PRN sequence is not the best solution either: If the key is reused then
the first block will always be encrypted with the same cipher. I think
the best solution is to use an IV as well as the key to start a PRN
sequence. One possibility:

Pool N ciphers.
Define random IV and add it to the ciphertext.
T(0) = IV
H(0) = Key

To encrypt the i-the block T(i):

H(i) = Hash( H(i-1) xor T(i-1) )
index(i) = H(i) mod N
C(i) = encrypt( index(i) ) ( T(i), Key )

Here is another possibility. Let us assume we trust four of the AES
finalists (which use 128 bit blocks).

index = least significant 2 bits of key
H = IV

Step A: H = encrypt( index ) ( H, Key)
Step B: Use 63 groups of 2 bits of H to index a cipher and encrypt the
first 63 blocks of plaintext.
Step C: index = last 2 bits of H
Step D: go to Step A

The ciphertext increases in one block and speed decreases about 2%

One more thought. Mixing ciphers in a secret sequence seems to be
useful even if only two ciphers are used. What about using only one
cipher while changing the direction of the encryption, i.e. use it
sometimes to encrypt and sometimes to decrypt depending on the secret
sequence?


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


{}{}{} Posted via Uncensored-News.Com, http://www.uncensored-news.com {}{}{}
{}{}{}{} Only $8.95 A Month, - The Worlds Uncensored News Source {}{}{}{}
{}{}{}{}{} Five News Servers with a BINARIES ONLY Server {}{}{}{}{}


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Mon, 25 Oct 1999 10:06:22 +0200
From: Mok-Kong Shen <mok-kong.shen@t-online.de>
Message-ID: <38140F7E.48AEB54B@t-online.de>
References: <7v0fkl$8tu$1@nnrp1.deja.com>
   <3812b166.3480429@news.io.com>
Newsgroups: sci.crypt
Lines: 26

dianelos@tecapro.com wrote:
> 

> Now if the attacker *does* know which cipher has been used for each
> ciphertext block, then he can attack the ciphertext encrypted by the
> weakest cipher. Consider this: even though we in the public don't know
> the lower bound of security of the individual ciphers we must assume
> that a powerful attacker does know. We also can assume that these lower
> bounds vary a lot - it would be strange indeed if different ciphers
> were very similar in their lower bound of security. So in a pool of
> four ciphers it is quite probable that one (the "lemon") is orders of
> magnitude weaker than the others and that the attacker knows this. Let
> us assume the lemon falls to a known plaintext attack that requires a
> small number of known plaintexts. It is true that the attacker will now
> have to collect four times more data for the lemon, but this quantity
> will be a trifle compared to the plaintext that must be known for
> attacking any of the other three ciphers. Therefore the attacker will
> easily break 25% of the communications recovering almost all
> intelligence. Instead of using this method, we would be better off
> choosing one cipher by chance sticking to it.

A tiny remark: Using variable keys as proposed by me in another 
thread, such attacks presumably have to be considered in a different 
perspective.

M. K. Shen


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Mon, 25 Oct 1999 10:06:22 +0200
From: mok-kong.shen@t-online.de (mok-kong.shen@t-online.de)
Message-ID: <fc.3b9aca001bd038733b9aca004dfd3b8d.10abf@peg.dyndns.org>
References: <38140F7E.48AEB54B@t-online.de>
Newsgroups: sci.crypt
Lines: 27

dianelos@tecapro.com wrote:
>> 

>> Now if the attacker *does* know which cipher has been used for each
>> ciphertext block, then he can attack the ciphertext encrypted by the
>> weakest cipher. Consider this: even though we in the public don't know
>> the lower bound of security of the individual ciphers we must assume
>> that a powerful attacker does know. We also can assume that these lower
>> bounds vary a lot - it would be strange indeed if different ciphers
>> were very similar in their lower bound of security. So in a pool of
>> four ciphers it is quite probable that one (the "lemon") is orders of
>> magnitude weaker than the others and that the attacker knows this. Let
>> us assume the lemon falls to a known plaintext attack that requires a
>> small number of known plaintexts. It is true that the attacker will now
>> have to collect four times more data for the lemon, but this quantity
>> will be a trifle compared to the plaintext that must be known for
>> attacking any of the other three ciphers. Therefore the attacker will
>> easily break 25% of the communications recovering almost all
>> intelligence. Instead of using this method, we would be better off
>> choosing one cipher by chance sticking to it.

A tiny remark: Using variable keys as proposed by me in another 
thread, such attacks presumably have to be considered in a different 
perspective.

M. K. Shen


{}{}{} Posted via Uncensored-News.Com, http://www.uncensored-news.com {}{}{}
{}{}{}{} Only $8.95 A Month, - The Worlds Uncensored News Source {}{}{}{}
{}{}{}{}{} Five News Servers with a BINARIES ONLY Server {}{}{}{}{}


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Mon, 25 Oct 1999 12:25:38 -0400
From: "Trevor Jackson, III" <fullmoon@aspi.net>
Message-ID: <38148482.9BFC5B7C@aspi.net>
References: <7v0fkl$8tu$1@nnrp1.deja.com>
   <3812b166.3480429@news.io.com>
Newsgroups: sci.crypt
Lines: 136

dianelos@tecapro.com wrote:

> In article <3812b166.3480429@news.io.com>,
>   ritter@io.com (Terry Ritter) wrote:
>
> > On Sun, 24 Oct 1999 03:39:23 GMT, in <7utv1b$ldc$1@nnrp1.deja.com>, in
> > sci.crypt dianelos@tecapro.com wrote:
> >
> >>[...]
> >>Observe that in my discussion above, the choosing of the cipher
> >>depends on they key. It is not done randomly which would requiere us
> >>to add information to the ciphertext about which cipher has been
> >>used.
> >
> > Something seems wrong with this observation:  Keys we use for actual
> > data encryption generally are *message keys*, and in fact *should* be
> > random values.  Using a random message key value to select a cipher
> > sounds rather similar to using a random value to select a cipher.
>
> 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. If you choose the
> ciphers by any other method then, by definition, the attacker will
> always know which cipher is being used: the attacker can know
> everything except the key.
>
> Now if the attacker *does* know which cipher has been used for each
> ciphertext block, then he can attack the ciphertext encrypted by the
> weakest cipher. Consider this: even though we in the public don't know
> the lower bound of security of the individual ciphers we must assume
> that a powerful attacker does know. We also can assume that these lower
> bounds vary a lot - it would be strange indeed if different ciphers
> were very similar in their lower bound of security. So in a pool of
> four ciphers it is quite probable that one (the "lemon") is orders of
> magnitude weaker than the others and that the attacker knows this. Let
> us assume the lemon falls to a known plaintext attack that requires a
> small number of known plaintexts. It is true that the attacker will now
> have to collect four times more data for the lemon, but this quantity
> will be a trifle compared to the plaintext that must be known for
> attacking any of the other three ciphers. Therefore the attacker will
> easily break 25% of the communications recovering almost all
> intelligence. Instead of using this method, we would be better off
> choosing one cipher by chance sticking to it.
>
> The situation is very different is the choice of ciphers is unknown to
> the attacker, and for that it is necessary that the choice of the
> ciphers depend on the key. (There is curious exception: to encrypt the
> next block choose the cipher completely at random and send only the
> resulting ciphertext. To decrypt, try in sequence the various ciphers
> until you get intelligible plaintext.)

It appears to me to be extremely difficult to define "intelligible
plaintext".  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.

And if I'm sening noise, e.g., a message key, it is impossible by
definition.

>
>
> > We certainly would hope that any attacker could not distinguish
> > between ciphertexts produced by one cipher and another.  One might
> > even think that an ability to identify a particular cipher from its
> > ciphertext alone would be a straightforward indication of cipher
> > weakness.
>
> I agree.
>
> > Obviously an attacker could try all ciphertexts under the weakest
> > cipher first, but if the attack requires messages from only a
> > particular cipher, how would the attacker know which messages to use?
> >
> > When the cipher itself is changed dynamically on a message-by-message
> > basis, there should be no way to distinguish the subset of ciphertexts
> > produced by a particular cipher.  It would thus seem to be hard for an
> > attacker to even collect the required amount of single-cipher
> > ciphertext, let alone start any actual attack.
>
> When the cipher choice is changed dynamically in a way that the
> attacker cannot predict, then we do get some very interesting
> properties even if the pool contains only two or three ciphers: It
> seems a ciphertext only attack on the weak cipher will not work,
> because the attacker will not know which ciphertext blocks belong to
> it. Known or chosen plaintext attacks will apparently not work either
> and for the same reason: even if the attacker chooses the entire
> plaintext stream, he cannot collect and analyze the ciphertext blocks
> that have been encrypted with the lemon. It does appear that mixing
> ciphers can be very useful, but only if the attacker cannot predict
> their sequence.
>
> How does one achieve this? Using a few bits of the key to index one in
> a pool of N ciphers is not the best way, because then all blocks will
> be encrypted with the same cipher. The attacker applies the lemon-
> attack and with 1/N probability it will work. Using the key to start a
> PRN sequence is not the best solution either: If the key is reused then
> the first block will always be encrypted with the same cipher. I think
> the best solution is to use an IV as well as the key to start a PRN
> sequence. One possibility:
>
> Pool N ciphers.
> Define random IV and add it to the ciphertext.
> T(0) = IV
> H(0) = Key
>
> To encrypt the i-the block T(i):
>
> H(i) = Hash( H(i-1) xor T(i-1) )
> index(i) = H(i) mod N
> C(i) = encrypt( index(i) ) ( T(i), Key )
>
> Here is another possibility. Let us assume we trust four of the AES
> finalists (which use 128 bit blocks).
>
> index = least significant 2 bits of key
> H = IV
>
> Step A: H = encrypt( index ) ( H, Key)
> Step B: Use 63 groups of 2 bits of H to index a cipher and encrypt the
> first 63 blocks of plaintext.
> Step C: index = last 2 bits of H
> Step D: go to Step A
>
> The ciphertext increases in one block and speed decreases about 2%
>
> One more thought. Mixing ciphers in a secret sequence seems to be
> useful even if only two ciphers are used. What about using only one
> cipher while changing the direction of the encryption, i.e. use it
> sometimes to encrypt and sometimes to decrypt depending on the secret
> sequence?
>
> 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: Mon, 25 Oct 1999 18:25:38 +0200
From: fullmoon@aspi.net (fullmoon@aspi.net)
Message-ID: <fc.3b9aca00d0dffd663b9aca004dfd3b8d.10af6@peg.dyndns.org>
References: <38148482.9BFC5B7C@aspi.net>
Newsgroups: sci.crypt
Lines: 137

dianelos@tecapro.com wrote:

>> In article <3812b166.3480429@news.io.com>,
>>   ritter@io.com (Terry Ritter) wrote:
>>
>> > On Sun, 24 Oct 1999 03:39:23 GMT, in <7utv1b$ldc$1@nnrp1.deja.com>, in
>> > sci.crypt dianelos@tecapro.com wrote:
>> >
>> >>[...]
>> >>Observe that in my discussion above, the choosing of the cipher
>> >>depends on they key. It is not done randomly which would requiere us
>> >>to add information to the ciphertext about which cipher has been
>> >>used.
>> >
>> > Something seems wrong with this observation:  Keys we use for actual
>> > data encryption generally are *message keys*, and in fact *should* be
>> > random values.  Using a random message key value to select a cipher
>> > sounds rather similar to using a random value to select a cipher.
>>
>> 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. If you choose the
>> ciphers by any other method then, by definition, the attacker will
>> always know which cipher is being used: the attacker can know
>> everything except the key.
>>
>> Now if the attacker *does* know which cipher has been used for each
>> ciphertext block, then he can attack the ciphertext encrypted by the
>> weakest cipher. Consider this: even though we in the public don't know
>> the lower bound of security of the individual ciphers we must assume
>> that a powerful attacker does know. We also can assume that these lower
>> bounds vary a lot - it would be strange indeed if different ciphers
>> were very similar in their lower bound of security. So in a pool of
>> four ciphers it is quite probable that one (the "lemon") is orders of
>> magnitude weaker than the others and that the attacker knows this. Let
>> us assume the lemon falls to a known plaintext attack that requires a
>> small number of known plaintexts. It is true that the attacker will now
>> have to collect four times more data for the lemon, but this quantity
>> will be a trifle compared to the plaintext that must be known for
>> attacking any of the other three ciphers. Therefore the attacker will
>> easily break 25% of the communications recovering almost all
>> intelligence. Instead of using this method, we would be better off
>> choosing one cipher by chance sticking to it.
>>
>> The situation is very different is the choice of ciphers is unknown to
>> the attacker, and for that it is necessary that the choice of the
>> ciphers depend on the key. (There is curious exception: to encrypt the
>> next block choose the cipher completely at random and send only the
>> resulting ciphertext. To decrypt, try in sequence the various ciphers
>> until you get intelligible plaintext.)

It appears to me to be extremely difficult to define "intelligible
plaintext".  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.

And if I'm sening noise, e.g., a message key, it is impossible by
definition.

>>
>>
>> > We certainly would hope that any attacker could not distinguish
>> > between ciphertexts produced by one cipher and another.  One might
>> > even think that an ability to identify a particular cipher from its
>> > ciphertext alone would be a straightforward indication of cipher
>> > weakness.
>>
>> I agree.
>>
>> > Obviously an attacker could try all ciphertexts under the weakest
>> > cipher first, but if the attack requires messages from only a
>> > particular cipher, how would the attacker know which messages to use?
>> >
>> > When the cipher itself is changed dynamically on a message-by-message
>> > basis, there should be no way to distinguish the subset of ciphertexts
>> > produced by a particular cipher.  It would thus seem to be hard for an
>> > attacker to even collect the required amount of single-cipher
>> > ciphertext, let alone start any actual attack.
>>
>> When the cipher choice is changed dynamically in a way that the
>> attacker cannot predict, then we do get some very interesting
>> properties even if the pool contains only two or three ciphers: It
>> seems a ciphertext only attack on the weak cipher will not work,
>> because the attacker will not know which ciphertext blocks belong to
>> it. Known or chosen plaintext attacks will apparently not work either
>> and for the same reason: even if the attacker chooses the entire
>> plaintext stream, he cannot collect and analyze the ciphertext blocks
>> that have been encrypted with the lemon. It does appear that mixing
>> ciphers can be very useful, but only if the attacker cannot predict
>> their sequence.
>>
>> How does one achieve this? Using a few bits of the key to index one in
>> a pool of N ciphers is not the best way, because then all blocks will
>> be encrypted with the same cipher. The attacker applies the lemon-
>> attack and with 1/N probability it will work. Using the key to start a
>> PRN sequence is not the best solution either: If the key is reused then
>> the first block will always be encrypted with the same cipher. I think
>> the best solution is to use an IV as well as the key to start a PRN
>> sequence. One possibility:
>>
>> Pool N ciphers.
>> Define random IV and add it to the ciphertext.
>> T(0) = IV
>> H(0) = Key
>>
>> To encrypt the i-the block T(i):
>>
>> H(i) = Hash( H(i-1) xor T(i-1) )
>> index(i) = H(i) mod N
>> C(i) = encrypt( index(i) ) ( T(i), Key )
>>
>> Here is another possibility. Let us assume we trust four of the AES
>> finalists (which use 128 bit blocks).
>>
>> index = least significant 2 bits of key
>> H = IV
>>
>> Step A: H = encrypt( index ) ( H, Key)
>> Step B: Use 63 groups of 2 bits of H to index a cipher and encrypt the
>> first 63 blocks of plaintext.
>> Step C: index = last 2 bits of H
>> Step D: go to Step A
>>
>> The ciphertext increases in one block and speed decreases about 2%
>>
>> One more thought. Mixing ciphers in a secret sequence seems to be
>> useful even if only two ciphers are used. What about using only one
>> cipher while changing the direction of the encryption, i.e. use it
>> sometimes to encrypt and sometimes to decrypt depending on the secret
>> sequence?
>>
>> Sent via Deja.com http://www.deja.com/
>> Before you buy.





{}{}{} Posted via Uncensored-News.Com, http://www.uncensored-news.com {}{}{}
{}{}{}{} Only $8.95 A Month, - The Worlds Uncensored News Source {}{}{}{}
{}{}{}{}{} Five News Servers with a BINARIES ONLY Server {}{}{}{}{}


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Tue, 26 Oct 1999 14:08:45 GMT
From: dianelos@tecapro.com
Message-ID: <7v4cla$1og$1@nnrp1.deja.com>
References: <38148482.9BFC5B7C@aspi.net>
Newsgroups: sci.crypt
Lines: 35

In article <38148482.9BFC5B7C@aspi.net>,
  "Trevor Jackson, III" <fullmoon@aspi.net> wrote:
> dianelos@tecapro.com wrote:

>>The situation is very different is the choice of ciphers is unknown to
>>the attacker, and for that it is necessary that the choice of the
>>ciphers depend on the key. (There is curious exception: to encrypt the
>>next block choose the cipher completely at random and send only the
>>resulting ciphertext. To decrypt, try in sequence the various ciphers
>>until you get intelligible plaintext.)
>
>It appears to me to be extremely difficult to define "intelligible
>plaintext".  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.

If the plaintext is compressed then you decompress it and see if it is
intellible.

>And if I'm sening noise, e.g., a message key, it is impossible by
>definition.

If you are sending a random key then you can add its hash.

There are always ways to send intellible plaintext. What is interesting
about this method is that it is now impossible for the attacker to know
which block has been encrypted by which cipher and this renders any
attack that requires more than 30 or so plaintexts impossible too. If
you encrypt using four ciphers then decryption speed will be on average
2.5 times slower, but with the speed of modern ciphers this is not a
big problem.


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: Thu, 28 Oct 1999 22:10:37 GMT
From: dianelos@tecapro.com
Message-ID: <7vahkq$i4d$1@nnrp1.deja.com>
References: <7v4cla$1og$1@nnrp1.deja.com>
Newsgroups: sci.crypt
Lines: 87


>   "Trevor Jackson, III" <fullmoon@aspi.net> wrote:
> (...)
>>It appears to me to be extremely difficult to define "intelligible
>>plaintext".

An update on how to send "intelligible plaintext" while using two
ciphers in random sequence:

Take two ciphers that work with 128 bit blocks; Twofish and Rijndael
are free and are good choices. Now implement the following protocol
that works on blocks of 120 bits of plaintext. For each block compute a
hash digest of 8 bits and concatenate it to the plaintext block;
randomly choose one of the two ciphers, encrypt the block and send the
ciphertext. Also, decrypt this ciphertext with the other cipher,
compute the hash of the 120 first bits of the result and compare it
with the original hash. If they are equal then add 1 to the plaintext
and repeat the whole process.

To decrypt try both ciphers and check the hash. If one hash is correct
and the other is not then use the plaintext that produced the correct
hash. If both hashes are correct then we have a collision. Read the
next ciphertext block and check the hashes again. If they are equal
(double collision with probability 2^(- 16)) then compare the 120 bit
plaintext block created now with the previous 120 bit block; if the
current block equals the previous block plus one, then you have
identified the correct cipher. There is a extremely low probability (2^
(-136)) of a triple collision in which both plaintexts come out
alright. If you worry about such low probabilities, implement a
protocol that loops around until the 8 bit hash doesn't collide.

This protocol is slow: to encrypt one block it uses a little over one
encryption and one decryption plus the time necessary to produce one
random bit; to decrypt it uses a little over two decryptions. Taking
into account the very high speeds achieved by modern ciphers, almost
all applications could live with this. The ciphertext stream is about
7% larger.

Why use this protocol instead of cascading two ciphers (with roughly
the same cost in speed)? I think the difference is this: 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. Any attack against a cipher that requires a
lot of previous knowledge (more than about 30 plaintexts) will not work.

Some observations:

1. The 8 bit hash need not be "cryptographically secure". In this
context any fast hash function works fine. Probably even a simple xor
of all bytes would be sufficient.

2. The random number generator must be unpredictable. For high volume
work you will need a hardware based RNG (how fast is the new Pentium
chip in this?). For lower speeds (certainly for Internet client
requirements) you can use the PC itself as an entropy generator. I
think that Yarrow does something like this. I've written code myself
that collects entropy in the background using exact timing information
for mouse and keyboard events, hard disc access, etc; you can add a
hash of the state of the stack, and so on. (I like to call this an
"Almost Random Number Generator" or ARNG.)

3. Other variations. Instead of randomizing the cipher, we can design
similar protocols that randomize the encryption direction or randomize
the key. Examples: Use one cipher in a random sequence of encryptions
or decryptions. Use two ciphers each one with its particular key. Use
two ciphers and two keys for a protocol that is 4 times slower.

4. The following variant is more efficient (you pay 1% in speed and 1%
in space), but may be less secure: Use blocks of 127 bits of plaintext
to which you add 1 random bit. This random bit defines which cipher
will encrypt the next block. I believe that this protocol is not as
secure as the previous ones, because the information about which cipher
will be used is explicit.

Conclusion:

Normally, the attacker is supposed to know everything except the secret
key. In addition to this, the proposed protocol denies the attacker
knowledge about which cipher has been used for each block. Anything
that denies the attacker knowledge is a valid defense. I think that
this protocol makes it almost impossible to apply conventional
cryptanalytic attacks at a modest cost in speed and space.


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: Sun, 24 Oct 1999 01:08:06 -0700
From: "Roger Schlafly" <real@ieee.org>
Message-ID: <7uueot$oia@enews3.newsguy.com>
References: <7utv1b$ldc$1@nnrp1.deja.com>
Newsgroups: sci.crypt
Lines: 14

<dianelos@tecapro.com> wrote in message news:7utv1b$ldc$1@nnrp1.deja.com...
> Let us assume, for example, that four AES finalists survive with a
> flawless security record. Instead of using any one of them with a 128
> bit key we could use the "fourAES" cipher with a 130 bit key. This
> cipher will be stronger as long as k<0.66, i.e. as long as we assume
> there exists an (unknown) attack that can break the AES finalists with
> less than 2^(0.66*128)=2^84 cost.

Even if your analysis is correct, it is stronger by only a trivial
amount. It would be more secure to just increase the key size
by a few bits.





Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Sun, 24 Oct 1999 09:05:43 GMT
From: ritter@io.com (Terry Ritter)
Message-ID: <3812cb38.10091467@news.io.com>
References: <7uueot$oia@enews3.newsguy.com>
Newsgroups: sci.crypt
Lines: 38


On Sun, 24 Oct 1999 01:08:06 -0700, in
<7uueot$oia@enews3.newsguy.com>, in sci.crypt "Roger Schlafly"
<real@ieee.org> wrote:

><dianelos@tecapro.com> wrote in message news:7utv1b$ldc$1@nnrp1.deja.com...
>> Let us assume, for example, that four AES finalists survive with a
>> flawless security record. Instead of using any one of them with a 128
>> bit key we could use the "fourAES" cipher with a 130 bit key. This
>> cipher will be stronger as long as k<0.66, i.e. as long as we assume
>> there exists an (unknown) attack that can break the AES finalists with
>> less than 2^(0.66*128)=2^84 cost.
>
>Even if your analysis is correct, it is stronger by only a trivial
>amount. It would be more secure to just increase the key size
>by a few bits.

Using different ciphers is fundamentally different from simply
increasing the keyspace.  We have plenty of keyspace, or could have it
if we wanted it.  Using different ciphers is not an attempt to gain
more keyspace.  

One difference is that we expect a particular attack on a cipher to
work independent of key.  Adding keyspace is probably not going to
make a successful attack much more difficult.  But we do *not* expect
the same attack (other than in handwave generalities) to work on a
*different* cipher.

By changing the cipher we thus terminate any existing break which we
cannot expect to know about anyway.  We also complicate the ciphertext
situation for anyone trying to distinguish the particular ciphertext
belonging to a particular cipher.  Accumulating ciphertext from a
particular cipher would seem to be necessary for most real attacks.

---
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: Sun, 24 Oct 1999 21:26:59 GMT
From: dianelos@tecapro.com
Message-ID: <7uvtj0$t7e$1@nnrp1.deja.com>
References: <7uueot$oia@enews3.newsguy.com>
Newsgroups: sci.crypt
Lines: 62

In article <7uueot$oia@enews3.newsguy.com>,
  "Roger Schlafly" <real@ieee.org> wrote:

> Even if your analysis is correct, it is stronger by only a trivial
> amount. It would be more secure to just increase the key size
> by a few bits.

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.

Now, I agree that if the pool is not very large then the practical
advantage is negligible. If somebody discovered a k=0.5 attack against
the AES class ciphers then the "fourAES" cipher I described would
increase the cost of attack only in 25% (not even one additional bit of
security).

Using multiple ciphers becomes interesting only with M>>1. Let us for a
moment assume we had 2^128 independent ciphers (M=128). If we use only
one of them with a key of 256 bits and somebody discovers an k=0.2
attack then we get a cipher with 256*0.2=51 bits of effective security,
i.e. we have a catastrophic failure in our hands. If, on the other
hand, we use all of them with a key of 128 bits and use the other 128
bits of the key to index the pool of ciphers, then the average cost of
the attack 2^(k*N-1)*(2^M+1)=2^153, i.e. it would afford us a very
significant 153 bits of security.

How do we get 2^128 ciphers? First of all observe that each individual
cipher can be very weak indeed. For large M, the cost of breaking the
"pooled" cipher would be 2^(k*N+M-1), i.e. that cipher's strength would
be k*N+M-1 bits. Even if k=0.01, i.e. even if each individual cipher
offers only 1.28 bits of security, the "pooled" cipher would still
offer 128.28 bits of security. So the question here is how to produce a
great many independent ciphers without much thought about the strength
of each individual one.

The best way I can imagine to achieve this is to create a cipher
generator: take a large number of bits out of the key and use them to
produce a cipher (code+tables). Use the rest of the key plus the
plaintext blocks to drive that cipher and produce the ciphertext.

This is almost exactly what my Frog algorithm does. Only about 5.6% of
the key material is really used as key data. The rest is used for
building tables and for "expressing" code. The AES specifications
didn't allow assembly code - therefore the only code variability I
included in my AES candidate was key dependent addresses. Frog is not
unique in that respect. Twofish can also be considered a "pool" of 2^64
ciphers because it uses that many key dependent tables. The big
question for any such cipher is whether the cipher instances are
independent.

I have written a more generalized version of Frog that works like a
compiler and literally produces code. That version generates key
dependent instructions as well as key and data dependent addresses.
Therefore, arguably, the generalized version of Frog covers a much more
"variable" subset of the cipher space, which brings it nearer to the
ideal of a generator that produces independent ciphers.



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: 26 Oct 1999 12:27:50 -0700
From: daw@blowfish.isaac.cs.berkeley.edu (David Wagner)
Message-ID: <7v4vbm$q05$1@blowfish.isaac.cs.berkeley.edu>
References: <7uvtj0$t7e$1@nnrp1.deja.com>
Newsgroups: sci.crypt
Lines: 22

In article <7uvtj0$t7e$1@nnrp1.deja.com>,  <dianelos@tecapro.com> wrote:
> The best way I can imagine to achieve this is to create a cipher
> generator: take a large number of bits out of the key and use them to
> produce a cipher (code+tables). Use the rest of the key plus the
> plaintext blocks to drive that cipher and produce the ciphertext.
> 
> This is almost exactly what my Frog algorithm does. Only about 5.6% of
> the key material is really used as key data. The rest is used for
> building tables and for "expressing" code.

The problem is that it is very challenging to ensure that all of the
resulting ciphers truly are "independent" of each other.

If they're not "independent", your argument for security breaks down.
In particular, it might be that you could attack N "dependent" ciphers
with not much more complexity than that required to attack 1 such cipher.

I can think of some very natural examples of this phenomenom.  FROG is
one good example; there are very large classes of "ciphers" which can
be attacked by a differential attack that needs the same chosen plaintext
queries for all such ciphers, and thus not knowing which "cipher" is in
use doesn't hurt the attacker too much.


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Wed, 27 Oct 1999 20:13:08 GMT
From: dianelos@tecapro.com
Message-ID: <7v7mcg$fq3$1@nnrp1.deja.com>
References: <7v4vbm$q05$1@blowfish.isaac.cs.berkeley.edu>
Newsgroups: sci.crypt
Lines: 33

In article <7v4vbm$q05$1@blowfish.isaac.cs.berkeley.edu>,
  daw@blowfish.isaac.cs.berkeley.edu (David Wagner) wrote:
> In article <7uvtj0$t7e$1@nnrp1.deja.com>,  <dianelos@tecapro.com>
wrote:
>>The best way I can imagine to achieve this is to create a cipher
>>generator: take a large number of bits out of the key and use them to
>>produce a cipher (code+tables). Use the rest of the key plus the
>>plaintext blocks to drive that cipher and produce the ciphertext.
>>
>>This is almost exactly what my Frog algorithm does. Only about 5.6% of
>>the key material is really used as key data. The rest is used for
>>building tables and for "expressing" code.
>
>The problem is that it is very challenging to ensure that all of the
>resulting ciphers truly are "independent" of each other.

Very challenging indeed. Any ideas about how it could be done?

>If they're not "independent", your argument for security breaks down.
>In particular, it might be that you could attack N "dependent" ciphers
>with not much more complexity than that required to attack 1 such
>cipher.
>
>I can think of some very natural examples of this phenomenom.  FROG is
>one good example; (...)

What I wanted to say was that Frog can be viewed as a cipher generator
- not that it is a generator that produces independent ciphers. Sorry
for the ambiguity.


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: Thu, 28 Oct 1999 14:15:21 -0600
From: jgfunj@vgrknf.arg (wtshaw)
Message-ID: <jgfunj-2810991415210001@dial-243-062.itexas.net>
References: <7v7mcg$fq3$1@nnrp1.deja.com>
Newsgroups: sci.crypt
Lines: 32

In article <7v7mcg$fq3$1@nnrp1.deja.com>, dianelos@tecapro.com wrote:

> In article <7v4vbm$q05$1@blowfish.isaac.cs.berkeley.edu>,
>   daw@blowfish.isaac.cs.berkeley.edu (David Wagner) wrote:
> > In article <7uvtj0$t7e$1@nnrp1.deja.com>,  <dianelos@tecapro.com>
> wrote:
> >>The best way I can imagine to achieve this is to create a cipher
> >>generator: take a large number of bits out of the key and use them to
> >>produce a cipher (code+tables). Use the rest of the key plus the
> >>plaintext blocks to drive that cipher and produce the ciphertext.
> >>
> >>This is almost exactly what my Frog algorithm does. Only about 5.6% of
> >>the key material is really used as key data. The rest is used for
> >>building tables and for "expressing" code.
> >
> >The problem is that it is very challenging to ensure that all of the
> >resulting ciphers truly are "independent" of each other.
> 
> Very challenging indeed. Any ideas about how it could be done?
> 
How do you elliminate redundancy in anything?  Strangely, the answer might
be in another thread, some sort of compression to work against *sameness*,
or, at least some sort of tests to reject obvious problems, as in a
*check* for randomness, which still miss something critical.

A similiar problem exists with multialphabetic ciphers, where commonality
is to be avoided.  You either fight by contruction, and/or qualify with
filters, which sounds most appropriate to be debated regarding a noted
issue in entirely a different newsgroup.  As to cipher/key problems, some
methods prove tolerable.
-- 
To make a mountain out of a molehill, just add dirt.


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: 26 Oct 1999 12:04:07 -0700
From: daw@blowfish.isaac.cs.berkeley.edu (David Wagner)
Message-ID: <7v4tv7$pv5$1@blowfish.isaac.cs.berkeley.edu>
References: <7utv1b$ldc$1@nnrp1.deja.com>
Newsgroups: sci.crypt
Lines: 22

In article <7utv1b$ldc$1@nnrp1.deja.com>,  <dianelos@tecapro.com> wrote:
> Take two ciphers A and B with keys of N bits. These ciphers must be
> independent in the sense that physically breaking one does not help in
> breaking the other. [...] For ciphers A and B
> there exists then a method to break them at a cost comparable to 2^
> (N*k) operations where k<1 (2^N corresponds to brute forcing them). If
> you increase the key length by 1 bit, then you would need 2^((N+1)*k)
> =2^N * 2^k operations to break A or B [...]

Why do you assume that the complexity of attack is linear in the keylength?
To put the question differently: why should we expect that increasing the
key length will increase the complexity of attack proportionally?

In most of the cryptanalytic (shortcut) attacks I can think of, the
complexity of attack is essentially independent of the key length.

Since the argument is predicated on this assumption, and since the assumption
seems unlikely, I'm not sure how much we can really conclude from the
argument.  (Correct me if I'm misunderstanding.)

Is there some way to generalize the argument to work without such a strong
"linearity" assumption on the complexity of shortcut attacks?


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Wed, 27 Oct 1999 20:05:21 GMT
From: dianelos@tecapro.com
Message-ID: <7v7ltu$fdh$1@nnrp1.deja.com>
References: <7v4tv7$pv5$1@blowfish.isaac.cs.berkeley.edu>
Newsgroups: sci.crypt
Lines: 81

In article <7v4tv7$pv5$1@blowfish.isaac.cs.berkeley.edu>,
  daw@blowfish.isaac.cs.berkeley.edu (David Wagner) wrote:
> In article <7utv1b$ldc$1@nnrp1.deja.com>,  <dianelos@tecapro.com>
wrote:
>>Take two ciphers A and B with keys of N bits. These ciphers must be
>>independent in the sense that physically breaking one does not help in
>>breaking the other. [...] For ciphers A and B
>>there exists then a method to break them at a cost comparable to 2^
>>(N*k) operations where k<1 (2^N corresponds to brute forcing them). If
>>you increase the key length by 1 bit, then you would need 2^((N+1)*k)
>>=2^N * 2^k operations to break A or B [...]
>
>Why do you assume that the complexity of attack is linear in the
>keylength? To put the question differently: why should we expect that
>increasing the key length will increase the complexity of attack
>proportionally?
>
>In most of the cryptanalytic (shortcut) attacks I can think of, the
>complexity of attack is essentially independent of the key length.
>
>Since the argument is predicated on this assumption, and since the
>assumption seems unlikely, I'm not sure how much we can really
>conclude from the argument.  (Correct me if I'm misunderstanding.)

It seems to me that if an attack's complexity grows slower than linear
in the key length then the argument becomes stronger, because even if
that attack's complexity did grow linearly the method described would
produce a stronger cipher against that attack. In other words, even if
we assume that the component ciphers are stronger than what they
probably are we can construct an even stronger cipher. A similar
argument can be made for the observation that the component ciphers
will not really be equally strong: assume that all are as strong as the
strongest one and then proceed to construct a cipher that is stronger
still.

Formally we can express this as follows:

For all sets of ciphers and for key bit lengths of N in the range
[Nmin,Nmax] there exists k<=1 so that the cost of breaking any one of
them is greater or equal 2^(k*N).

Nmin, Nmax is the fixed range of key lengths that interest us. 2^(Nmax-
Nmin) must greater than the number of ciphers in the set.

Let us now choose any two independent ciphers A and B and specify
N=Nmin and Nmax=Nmin+1. Then

   cost(A,N) >= 2^(k*N)
   cost(B,N) >= 2^(k*N)
   cost(A,N+1) >= 2^(k*(N+1))
   cost(B,N+1) >= 2^(k*(N+1))

Construct a cipher C with keys of N+1 bits and use the last bit of the
key to decide whether to apply A or B.

Then cost(C,N+1) = cost(A,N)+cost(B,N)/2
                 >= 3/2 * 2^(k*N)
                 >= 3/2 * 2^(-k) * 2^(k*N + k)
                 >= 3/2 * 2^(-k) * cost(A,N+1)

3/2 * 2^(-k) > 1 => cost(C,N+1) > cost(A,N+1)
or:
k < ln(3/2)/ln(2) => cost(C,N+1) > cost(A,N+1)

So we have constructed a cipher C which is on average stronger than A
or B (as long as A and B are rather weak).

If the set has 2^M ciphers then the cost of the attack is 2^(k*N1)*
(2^M+1). If M is large then no matter how weak the component ciphers
are (k->0), any attack against C will have complexity greater than M-1.

I am not sure about the practical significance of this. Proving that a
huge set of ciphers is independent may be as difficult to do as proving
that a cipher is strong. On the other hand, if we build a generator
that produces desperately different ciphers we may trust its quality of
independence more than we now trust the strength of any conventional
design.


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: 22 Oct 1999 08:00:41 +0100
From: Paul Crowley <paul@hedonism.demon.co.uk>
Message-ID: <87r9inhobr.fsf@hedonism.demon.co.uk>
References: <380ED1D0.9B71B61F@t-online.de>
Newsgroups: sci.crypt
Lines: 17

Mok-Kong Shen <mok-kong.shen@t-online.de> writes:
> In one point Mr. Schneier has clearly and definitely erred, namely
> concerning his phrase about randomly choosing a cipher. Randomly
> choosing among a set of ciphers can NEVER be weaker than the
> weakest of the set.

False.  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.
-- 
  __
\/ o\ paul@hedonism.demon.co.uk     Got a Linux strategy? \ /
/\__/ Paul Crowley  http://www.hedonism.demon.co.uk/paul/ /~\


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Fri, 22 Oct 1999 20:04:27 +0200
From: Mok-Kong Shen <mok-kong.shen@t-online.de>
Message-ID: <3810A72B.6CE17EA4@t-online.de>
References: <87r9inhobr.fsf@hedonism.demon.co.uk>
Newsgroups: sci.crypt
Lines: 29

Paul Crowley wrote:
> 
> Mok-Kong Shen <mok-kong.shen@t-online.de> writes:
> > In one point Mr. Schneier has clearly and definitely erred, namely
> > concerning his phrase about randomly choosing a cipher. Randomly
> > choosing among a set of ciphers can NEVER be weaker than the
> > weakest of the set.
> 
> False.  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.

Sorry that I don't quite understand. In one case we have C1, C2, C3,
C4, .... In other case we have something like C1, C2', C3', C4, .....
where the primes refer to encipherment by the alternate algorithm.
Now the analyst doesn't have a priori knowlege of which message
is enciphered by which algorithm. Why is the second scheme weaker?
Could you explain in a bit detail?

> 
> Cipher strength is not measured on a single linear scale.

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.

M. K. Shehn


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Sat, 23 Oct 1999 22:52:51 GMT
From: ritter@io.com (Terry Ritter)
Message-ID: <38123c26.23603548@news.io.com>
References: <87r9inhobr.fsf@hedonism.demon.co.uk>
Newsgroups: sci.crypt
Lines: 41


On 22 Oct 1999 08:00:41 +0100, in
<87r9inhobr.fsf@hedonism.demon.co.uk>, in sci.crypt Paul Crowley
<paul@hedonism.demon.co.uk> wrote:

>Mok-Kong Shen <mok-kong.shen@t-online.de> writes:
>> In one point Mr. Schneier has clearly and definitely erred, namely
>> concerning his phrase about randomly choosing a cipher. Randomly
>> choosing among a set of ciphers can NEVER be weaker than the
>> weakest of the set.
>
>False.  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.

I have no idea what this can possibly mean.

Even if the opponent has both lower values, here 2^20 plaintext and
2^30 work, how does that help?  He needs to satisfy *all* requirements
for *any* *one* attack; he cannot mix and match.  

Then we have the issue of "recover messages."  Which messages?  All
messages, or just that proportion which was protected under the weaker
cipher?  Clearly, it is the part rather than the whole which is
recovered by the lesser attack.  But if we are in fact using the
lesser cipher, that is our whole.  

Ideally we would never use an attackable cipher.  If we knew the
strengths of ciphers, that what we would do.  Unfortunately, we do
*not* know the strengths of ciphers which we use, so we can hardly
choose between them.  

The alternative to using a variety of ciphers, of course, is to depend
upon something which explicitly cannot be depended upon.  

---
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: Thu, 21 Oct 1999 11:21:19 +0100
From: "Brian Gladman" <gladman@seven77.demon.co.uk>
Message-ID: <940501283.15899.0.nnrp-12.c2de6a96@news.demon.co.uk>
References: <380e7293.821932@news.visi.com>
   <19991019231649.22027.00000075@ng-cm1.aol.com>
Newsgroups: sci.crypt
Lines: 57

Bruce Schneier <schneier@counterpane.com> wrote in message
news:380e7293.821932@news.visi.com...
> On 20 Oct 1999 03:16:49 GMT, djohn37050@aol.com (DJohn37050) wrote:
>
> >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.
> >
> >I am certain there are other examples like this.
>
> It's a moronic example.  Do you really think that satellites are
> thrown away if there are software bugs?  Even NASA probes have
> uploadable software.

"Yes" is the short answer for at least some satellites.

How many satellites do you know of where (1) encryption is employed, and (2)
it is implemented in software or field updatable hardware?

For communications and surveillance satellites that use encryption to
protect their primary channels (as distinct from control channels) the
bandwidths would typically be far too high for the use of software based
encryption. Moreover, encryption hardware would not necessarily be field
updatable because this would conflict with other requirements.

And satellite control channels are especially critical and hence require
very high levels of protection from a wide range of possible attacks.  In
consequence it would not be unreasonable to consider multiple encryption
layers (sequential encryption) in this part of the overall design.

On what experience base do you assert that satellites are a 'moronic
example' of the practical use of encryption?  Encryption on satellites is
inevitably specilaised and hence unrepresentative of typical use.  But I
think that 'moronic' goes too far.

> I give up.  It's frustrating to argue real-world constraints with
> people who don't deal with real-world constraints.  People in this
[snip]

I am not sure whether you are characterising the whole thread with this
remark or just this sub-thread.  I certainly agree that sci.crypt is a
difficult place to have a serious debate about such matters because it is
always necessary to apply a 'common sense' filter to so much of what is said
(I only rarely join in for just this reason).

But between the 'noise' there has been a serious debate going on and I know
for certain that a number of those who are arguing for multiple AES
algorithms are very well aware of real world constraints.

Moreover, spurious and purely academic arguments have not been the exclusive
preserve of those who argue for an AES outcome that is more than the
announcement of a single winner.

           Brian Gladman





Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Thu, 21 Oct 1999 11:40:17 -0700
From: "Roger Schlafly" <real@ieee.org>
Message-ID: <7unmk8$mqh$1@nntp1.atl.mindspring.net>
References: <940501283.15899.0.nnrp-12.c2de6a96@news.demon.co.uk>
Newsgroups: sci.crypt
Lines: 16

Brian Gladman <gladman@seven77.demon.co.uk> wrote in message
news:940501283.15899.0.nnrp-12.c2de6a96@news.demon.co.uk...
> On what experience base do you assert that satellites are a 'moronic
> example' of the practical use of encryption?  Encryption on satellites is
> inevitably specilaised and hence unrepresentative of typical use.  But I
> think that 'moronic' goes too far.

I'm sorry, but I agree with Bruce. It is a moronic example.
Satellite folks do worry about catastrophic failure, but not
about AES flaws. Even if there is a security failure, it will
almost certainly not be because the AES block cipher has
some sort of weakness. There are 100s of other problems,
each of which is millions of times more likely to go wrong.





Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Thu, 21 Oct 1999 14:17:59 -0600
From: jcoffin@taeus.com (Jerry Coffin)
Message-ID: <MPG.127921664e5eb6398973c@news.mindspring.com>
References: <7unmk8$mqh$1@nntp1.atl.mindspring.net>
Newsgroups: sci.crypt
Lines: 46

In article <7unmk8$mqh$1@nntp1.atl.mindspring.net>, real@ieee.org 
says...
> Brian Gladman <gladman@seven77.demon.co.uk> wrote in message
> news:940501283.15899.0.nnrp-12.c2de6a96@news.demon.co.uk...
> > On what experience base do you assert that satellites are a 'moronic
> > example' of the practical use of encryption?  Encryption on satellites is
> > inevitably specilaised and hence unrepresentative of typical use.  But I
> > think that 'moronic' goes too far.
> 
> I'm sorry, but I agree with Bruce. It is a moronic example.
> Satellite folks do worry about catastrophic failure, but not
> about AES flaws. Even if there is a security failure, it will
> almost certainly not be because the AES block cipher has
> some sort of weakness. There are 100s of other problems,
> each of which is millions of times more likely to go wrong.

Hmm...let's see.  Bruce says failure of AES isn't a problem because it 
would be made reprogrammable (while ignoring the security implications 
of doing that).

You say the designer would NOT worry about AES failing, in which case 
he'd almost certainly hard-wire since this would keep from introducing 
the other security problems, as well as saving quite a bit of money 
and power.

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."  Is that 
correct?  Or are you saying the designer really WOULD put the AES in 
programmable logic despite not being concerned with it possibly 
failing?  If so, why would he do that?

I'd also note that programmable logic is quite expensive and does NOT 
make particularly efficient use of die area -- I'm willing to bet that 
a hardwired implementation of (say) three of the five AES finalists 
would cost less to build than using a CPLD large enough to hold any 
one of them, and would consume less power as well.  Most of the 
reasons originally given to favor a single algorithm would almost 
certainly work in reverse if, as a consequence, the single algorithm 
were placed in programmable logic.

-- 
    Later,
    Jerry.
 
The universe is a figment of its own imagination.


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Thu, 21 Oct 1999 23:15:28 -0700
From: "Roger Schlafly" <real@ieee.org>
Message-ID: <7uovc0$1bss@enews2.newsguy.com>
References: <MPG.127921664e5eb6398973c@news.mindspring.com>
Newsgroups: sci.crypt
Lines: 13

Jerry Coffin <jcoffin@taeus.com> wrote in message
news:MPG.127921664e5eb6398973c@news.mindspring.com...
> Hmm...let's see.  Bruce says failure of AES isn't a problem because it
> would be made reprogrammable (while ignoring the security implications
> of doing that).

The system will have many portions. The portions you are worried
about, you put in software. Otherwise, in hardware. Either way, it
is not a problem. At least, not a problem that is going to be solved
by multiple AES winners.





Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Fri, 22 Oct 1999 09:03:35 -0400
From: "Trevor Jackson, III" <fullmoon@aspi.net>
Message-ID: <381060A7.B68AD67E@aspi.net>
References: <7uovc0$1bss@enews2.newsguy.com>
Newsgroups: sci.crypt
Lines: 16

Roger Schlafly wrote:

> Jerry Coffin <jcoffin@taeus.com> wrote in message
> news:MPG.127921664e5eb6398973c@news.mindspring.com...
> > Hmm...let's see.  Bruce says failure of AES isn't a problem because it
> > would be made reprogrammable (while ignoring the security implications
> > of doing that).
>
> The system will have many portions. The portions you are worried
> about, you put in software. Otherwise, in hardware. Either way, it
> is not a problem. At least, not a problem that is going to be solved
> by multiple AES winners.

Are you speaking Ex Cathedra or are we permitted to know the reasoning
behind your pronouncement?



Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Fri, 22 Oct 1999 14:13:51 -0600
From: jcoffin@taeus.com (Jerry Coffin)
Message-ID: <MPG.127a5c0e2fb09c8989746@news.mindspring.com>
References: <7uovc0$1bss@enews2.newsguy.com>
Newsgroups: sci.crypt
Lines: 64

In article <7uovc0$1bss@enews2.newsguy.com>, real@ieee.org says...
> Jerry Coffin <jcoffin@taeus.com> wrote in message
> news:MPG.127921664e5eb6398973c@news.mindspring.com...
> > Hmm...let's see.  Bruce says failure of AES isn't a problem because it
> > would be made reprogrammable (while ignoring the security implications
> > of doing that).
> 
> The system will have many portions. The portions you are worried
> about, you put in software. Otherwise, in hardware. Either way, it
> is not a problem. At least, not a problem that is going to be solved
> by multiple AES winners.

I take little comfort from your assurance that "Either way, it is not 
a problem."  My only comfort is derived from the fact that you 
apparently haven't and won't design any systems upon which my life or 
the peace of the world depend.

The reality is exactly the opposite: whichever decision you make, 
there WILL be a problem, and having multiple hard-coded algorithms 
DOES provide a credible solution to at least most of the problem.

If you hardwire a single algorithm, security is lost when/if that 
algorithm is broken.

If you decide to cure that by making the single algorithm re-
programmable, then you have to protect the programming capability with 
another algorithm.  In addition, by putting the algorithm into re-
programmable hardware, you lose much of the benefit of putting it into 
hardware at all.

Having multiple algorithms deals with this in a relatively simple 
fashion: you hardwire multiple algorithms.  You have a message to 
switch from each algorithm to the next, but allows NO other control 
over the satellite's actions at all.

If you hardwire one algorithm, the satellite is secure until that 
algorithm is broken.  If you make the algorithm re-programmable, your 
satellite is secure until one of two algorithms is broken.  If you 
have five hardwired algorithms, your satellite is secure until all 
five algorithms are broken.

If there's a flaw in the logic here, please be so kind as to point it 
out.  A simple statement that "this doesn't really cure any problem" 
will not work.  If you're looking at the single hardwired algorithm, 
then you have to show that breaking one algorithm is just as difficult 
as breaking N algorithms (1<N<=5).  If you want to back up Bruce's 
idea of the algorithm being programmable, then you have to show that 
breaking your choice of 2 algorithms is just as difficult as breaking 
all N algorithms (again, 1<N<=5).

I simply don't see ANY logical way to conclude anything of the sort.  

I've already made one post that pointed out that I don't think 
satellite design is a mainstream market that should be considered 
heavily in AES selection.  Bryan Gladman has echoed that from a much 
more authoritative position.  Neither of these, however, has any 
effect on Bruce's claim that my example was "moronic" or your's that 
"Either way, it makes no difference".

-- 
    Later,
    Jerry.
 
The universe is a figment of its own imagination.


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: 22 Oct 1999 14:07:23 -0700
From: daw@blowfish.isaac.cs.berkeley.edu (David Wagner)
Message-ID: <7uqjmb$oei$1@blowfish.isaac.cs.berkeley.edu>
References: <MPG.127a5c0e2fb09c8989746@news.mindspring.com>
Newsgroups: sci.crypt
Lines: 20

In article <MPG.127a5c0e2fb09c8989746@news.mindspring.com>,
Jerry Coffin <jcoffin@taeus.com> wrote:
> If you hardwire one algorithm, the satellite is secure until that 
> algorithm is broken.  If you make the algorithm re-programmable, your 
> satellite is secure until one of two algorithms is broken.  If you 
> have five hardwired algorithms, your satellite is secure until all 
> five algorithms are broken.
> 
> If there's a flaw in the logic here, please be so kind as to point it 
> out.

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.

I think it is more prudent to assume that if you select somehow from a
list of five algorithms for each connection, you may end up with a system
that is only as strong as the weakest of the five algorithms.


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Fri, 22 Oct 1999 16:31:08 -0600
From: jcoffin@taeus.com (Jerry Coffin)
Message-ID: <MPG.127a8eb5cdf3aebe98974a@news.mindspring.com>
References: <7uqjmb$oei$1@blowfish.isaac.cs.berkeley.edu>
Newsgroups: sci.crypt
Lines: 74

In article <7uqjmb$oei$1@blowfish.isaac.cs.berkeley.edu>, 
daw@blowfish.isaac.cs.berkeley.edu says...
> In article <MPG.127a5c0e2fb09c8989746@news.mindspring.com>,
> Jerry Coffin <jcoffin@taeus.com> wrote:
> > If you hardwire one algorithm, the satellite is secure until that 
> > algorithm is broken.  If you make the algorithm re-programmable, your 
> > satellite is secure until one of two algorithms is broken.  If you 
> > have five hardwired algorithms, your satellite is secure until all 
> > five algorithms are broken.
> > 
> > If there's a flaw in the logic here, please be so kind as to point it 
> > out.
> 
> You seem to assume that you will know when someone breaks your algorithm.

Yes, more or less.

> 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.

Of course.  OTOH, if you're at all prudent about things, you can get a 
pretty fair idea that your security is breaking down somewhere, and 
when that happens, you can at least take SOME action if your 
investigation indicates that the cipher may be what's causing a 
problem.

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.
 
> I think it is more prudent to assume that if you select somehow from a
> list of five algorithms for each connection, you may end up with a system
> that is only as strong as the weakest of the five algorithms.

WHY?  I've already suggested a method that, AT WORST is at least as 
strong as the method you suggest.  You're basically asking that I 
assume that whoever designs the system is an idiot.  You're asking 
that if I design a system, I that ignore the best method I know and 
intentionally weaken the system.

The phrase "straw man" comes to mind here: you're basically asking 
that if I don't select the method you consider good, that the only 
alternative I consider is one we both already know is bad.

If no third alterative existed, then your position might be a 
reasonable one, but it seems pretty clear to me that if you include a 
number of ciphers and simply never use any but one, then the security 
is no worse than if you'd only ever included one in the first place.  
IOW, the worst possible case with my suggestion is as strong as your 
suggestion.

Even in this worst-case scenarios, I think having multiple AES winners 
improves security.  The funding for cryptanalysis and number of 
serious cryptanalysts in the world are both quite limited.  If AES 
selects a number of different winning algorithms, that research 
capability is likely to be spread more or less evenly among those 
winners rather all being concentrated on one.  This is likely to 
reduce the possibility of any one being broken in any specific period 
of time.

In addition, if an opponent KNOWS that at the first sign of a problem, 
you can switch from one cipher to another, he's less likely to invest 
the (typically large) amount of money necessary to build specialized 
hardware to break the first cipher to start with.  Thus, until there 
were really serious theoretical problems found with _all_ the winners, 
it would be substantially less likely that anybody would invest the 
money necessary to really decrypt any of them.

-- 
    Later,
    Jerry.
 
The universe is a figment of its own imagination.


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: 22 Oct 1999 23:46:29 GMT
From: djohn37050@aol.com (DJohn37050)
Message-ID: <19991022194629.28474.00000026@ng-ck1.aol.com>
References: <MPG.127a8eb5cdf3aebe98974a@news.mindspring.com>
Newsgroups: sci.crypt
Lines: 6

Yes, the effect of having multiple algs increasing the cost/benefit ratio to an
attacker was mentioned in my AES paper.  This means it is entirely possible
that a flaw will not be found (or found as fast) if multiple winners are picked
than would be found if there is only one.  In one case, jackpot; in the other,
switch to backup.
Don Johnson


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: 22 Oct 1999 17:28:57 -0700
From: daw@blowfish.isaac.cs.berkeley.edu (David Wagner)
Message-ID: <7uqvg9$ol1$1@blowfish.isaac.cs.berkeley.edu>
References: <MPG.127a8eb5cdf3aebe98974a@news.mindspring.com>
Newsgroups: sci.crypt
Lines: 82

In article <MPG.127a8eb5cdf3aebe98974a@news.mindspring.com>,
Jerry Coffin <jcoffin@taeus.com> wrote:
> 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.

That's not what I said at all.  Please try to understand my reasoning
before dismissing it out of hand; there may be a fatal flaw in my
arguments, but I don't think this is it.

> > I think it is more prudent to assume that if you select somehow from a
> > list of five algorithms for each connection, you may end up with a system
> > that is only as strong as the weakest of the five algorithms.
> 
> WHY?  I've already suggested a method that, AT WORST is at least as 
> strong as the method you suggest.

Maybe it is, maybe it isn't.

That's a very strong claim; I'd like to show that it's not only wrong,
but it's backwards.  Watch closely.

Suppose unbeknownst to us, one of the AES finalists ("the lemon") is
fatally flawed, but the rest are totally strong.  In other words, let's
assume that our adversaries are able to read traffic encrypted under
"the lemon", but we don't realize this.

Now, there are two ways we could have designed our cryptosystems:

1. Scenario: We picked one lucky finalist as the single AES winner.
   That cipher, and no other, becomes deployed everywhere.

   Risk: If we pick "the lemon" as our winner, all of traffic is readable.

   Expected result: With probability at most 1/5, all our traffic
   is readable.  With prob. at least 4/5, all our traffic is secure.

2. Scenario: All five finalists were designed as winners; the idea is
   that, for each new connection, one picks a new key at random _and_
   a new cipher (from the five finalists) at random.  This is what is
   done in deployed systems worldwide.

   Risk: Every connection that uses "the lemon" is insecure.

   Expected result: With probability 1, exactly 1/5 of our traffic can
   be read by the adversary.

Tell me if I'm wrong, but I think #2 summarizes your suggested approach,
and #1 summarizes the "conventional wisdom" approach.

Let's compare the two approaches.  I claim that #1 is a much better
situation to be in.  Consider: In many cases when we send the same
confidential data across multiple connections.

For instance, if we want to keep it a secret that our company is about
to be bought out by Microsoft, we might have lots of encrypted telephone
conversations where company employees discuss the impact of that amongst
themselves.  If the adversary is able to break the encryption associated
with any one of those phone conversations, he has all the information
we wanted to hide, and we lose lots of money; from our point of view, if
he can crack one of them, it's as bad as if he could crack them all.

Now it should become clear why approach #1 is preferable.  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.  Thus, in scenario #2, we are guaranteed
to get screwed and to lose money.  In contrast, in scenario #1, we lose
money only if NIST got unlucky when picking a winner for the AES.  Thus,
in scenario #1, we have at most a 1/5 probability of getting screwed.

Personally, I'd rather take the <= 1/5 probability of getting screwed
than take the scenario where I'm guaranteed to get screwed!

Now let's compare to what you claimed.  You claimed (if I understand
correctly) that #2 is "AT WORST" at least as strong as #1.  Yet it should
now be clear that #2 is weaker than #1: substantially weaker, even.

In fact, I'd claim that you have the statement backwards: the correct
statement is "scenario #1 (picking a single winner) is AT WORST at least
as strong as scenario #2 (picking multiple winners), and probably stronger".

So, where did I go wrong?


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Fri, 22 Oct 1999 20:48:17 -0600
From: jcoffin@taeus.com (Jerry Coffin)
Message-ID: <MPG.127acf919169e8c98974d@news.mindspring.com>
References: <7uqvg9$ol1$1@blowfish.isaac.cs.berkeley.edu>
Newsgroups: sci.crypt
Lines: 130

In article <7uqvg9$ol1$1@blowfish.isaac.cs.berkeley.edu>, 
daw@blowfish.isaac.cs.berkeley.edu says...

[ ... ] 

> 2. Scenario: All five finalists were designed as winners; the idea is
>    that, for each new connection, one picks a new key at random _and_
>    a new cipher (from the five finalists) at random.  This is what is
>    done in deployed systems worldwide.
> 
>    Risk: Every connection that uses "the lemon" is insecure.
> 
>    Expected result: With probability 1, exactly 1/5 of our traffic can
>    be read by the adversary.

This bears no relationship to what I proposed at all.  What I proposed 
was that you start with one cipher.  You use it for ALL communication.  
When and if you are given reason to believe this cipher is or will 
become compromised, you switch to the second.  When/if you are given 
reason to believe that is or may become compromised, you switch to the 
third.  This continues until you run out of ciphers.

Now, there some people have proposed ordering the ciphers in the 
standard -- I.e. the standard itself say something to the effect that: 
"here are algorithms 1, 2 and 3" and they'd be used in that order.  I 
don't agree with this approach.  I believe AES should stick to 
algorithms, not protocols.  Protocols are (at least IMO) an entirely 
separate kettle of fish from algorithms, and should be kept separate 
both in the implementation and the standards -- right now FIPS 46-2 
describes a single algorithm; other standards deal with how to do 
chaining, how to do protocols, etc., and I think that's the way things 
should stay.  The one place you'd see something in AES that deal with 
algorithm selection would be a bit like the progression from FIPS 46-2 
to FIPS 46-3 -- this changes the recommendation from DES to 3DES.  In 
a later version of AES, there might be a change from (say) three 
algorithms to two if one of the existing algorithms was found to have 
a substantial weakness.

The basic difference would be that in the AES, there would be more 
than one algorithm described -- nothing more.  Nothing about which one 
is preferred, how to pick between them, negotiate usage, etc.  
Ultimately, ensuring interoperability goes WELL beyond the algorithm, 
and does NOT belong in AES, IMO.  One proposal has suggested that one 
particular algorithm be chosen to include in all possible AES 
implementations.  IMO, this would be pointless since it's still far to 
weak to ensure anything approaching interoperability (just as the 
single algorithm in DES doesn't ensure interoperability between 
products).
 
> Tell me if I'm wrong, but I think #2 summarizes your suggested approach,
> and #1 summarizes the "conventional wisdom" approach.

I'm not sure how you could have gotten this impression from my last 
message, but as I said above, it's not merely a bit mistaken, but dead 
wrong from beginning to end.
 
> Let's compare the two approaches.  I claim that #1 is a much better
> situation to be in.  Consider: In many cases when we send the same
> confidential data across multiple connections.

I claim that #3 is a better situation to be in.  First of all, I think 
your idea that there's one "lemon" and four "winners" is unrealistic.  
The believe all the algorithms are well enough designed that there's 
not going to be a quick, simple break on any of them.

Even so, I think #2 is _probably_ a better scenario than #1.  I think 
it's safe to say that breaking AES by key-space exhaustion isn't 
something to worry about.  Most other forms of attack we know about 
involve collecting large amounts of text encrypted with the cipher 
under attack.  If the text is encrypted randomly with N different 
ciphers, then it takes approximately N times as long to collect a 
sufficient amount of text to attack a single cipher.  This means it is 
N times as likely that the key will be changed before a sufficient 
amount of text can be collected.

> Now it should become clear why approach #1 is preferable.  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.  Thus, in scenario #2, we are guaranteed
> to get screwed and to lose money.  In contrast, in scenario #1, we lose
> money only if NIST got unlucky when picking a winner for the AES.  Thus,
> in scenario #1, we have at most a 1/5 probability of getting screwed.

I think you're ignoring a great deal of what you know about 
cryptanalysis.  You know perfectly well that a single conversation (or 
email message) is likely to provide an insufficient amount of 
encrypted text to mount a successful attack on anything.  The opponent 
will likely have to collect data from (at least) millions of 
conversations before an attack becomes feasible at all.  By using 5 
ciphers, the length of time before any attack becomes feasible at all 
is multiplied by 5 as well.  IOW, chances are 5 times as high that the 
opponent won't be able to break anything until after the news is 
publicly available anyway.
 
> Now let's compare to what you claimed.  You claimed (if I understand
> correctly) that #2 is "AT WORST" at least as strong as #1.  Yet it should
> now be clear that #2 is weaker than #1: substantially weaker, even.

I hadn't claimed anything about #2.  I was quite clear in stating that 
was I was offering was completely different from #2, and I'm still 
quite clear about that -- I didn't think #2 was the optimal approach 
and I still don't.  Despite this, given the amount of encrypted text 
likely to be needed for a successful attack on any of the ciphers, not 
to mention the amount of research necessary to create a practical 
attack in the first place, and the dilution of research that will take 
place if multiple winners are selected, I think #2 is STILL probably 
superior to #1.

> In fact, I'd claim that you have the statement backwards: the correct
> statement is "scenario #1 (picking a single winner) is AT WORST at least
> as strong as scenario #2 (picking multiple winners), and probably stronger".
>
> So, where did I go wrong?

Almost everywhere.  You started by ignoring what I'd written, and 
trying to put me down as advocating something entirely different than 
I really wrote about at all.  You continued by ignoring most of what 
you've known about cryptanalysis for years.  You finished by ignoring 
the effect of diluting research over a number of algorithms instead of 
nearly the entire world's efforts in cryptanalysis being aimed at one 
specific algorithm.

I'm not sure there aren't any other defects in your argument, but 
those three seem quite obvious.

-- 
    Later,
    Jerry.
 
The universe is a figment of its own imagination.


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: 22 Oct 1999 21:28:52 -0700
From: daw@blowfish.isaac.cs.berkeley.edu (David Wagner)
Message-ID: <7urdi4$op0$1@blowfish.isaac.cs.berkeley.edu>
References: <MPG.127acf919169e8c98974d@news.mindspring.com>
Newsgroups: sci.crypt
Lines: 30

In article <MPG.127acf919169e8c98974d@news.mindspring.com>,
Jerry Coffin <jcoffin@taeus.com> wrote:
> This bears no relationship to what I proposed at all.  What I proposed 
> was that you start with one cipher.  You use it for ALL communication.  
> When and if you are given reason to believe this cipher is or will 
> become compromised, you switch to the second.  When/if you are given 
> reason to believe that is or may become compromised, you switch to the 
> third.  This continues until you run out of ciphers.

Ahh, you're right, I misunderstood.  I apologize profusely.

Ok, now we're back to the problem of detecting when the opponent has
broken our cipher.

In any case, there's clearly a cost-benefit tradeoff (in some systems,
anyway) between (1) cost and (2) ease of switching ciphers if a flaw is
found, and I'd claim that the right balance point will be different for
different applications.  Forcing folks to implement multiple _alternates_
(runners-up) if they want to comply with the AES does make it easier to
switch ciphers at some future time if necessary, but it's not clear to
me that it's the right design choice to force on _all_ deployed systems.

My preference would be to have exactly one MUST-implement "AES winner".
Then, if you like, you can pick several optional alternates that you MAY
implement at your discretion; I don't care about that part.  (I'm using
the words MUST and MAY as in the meaning established for IETF standards.)

Would you agree to such an approach?  Or do you feel we need to force
multiple MUST-implement ciphers on everyone in the world who wants to claim
AES-compliance?


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Sat, 23 Oct 1999 11:04:16 +0200
From: Mok-Kong Shen <mok-kong.shen@t-online.de>
Message-ID: <38117A10.EBF78F3F@t-online.de>
References: <7urdi4$op0$1@blowfish.isaac.cs.berkeley.edu>
Newsgroups: sci.crypt
Lines: 15

David Wagner wrote:
> 

> My preference would be to have exactly one MUST-implement "AES winner".
> Then, if you like, you can pick several optional alternates that you MAY
> implement at your discretion; I don't care about that part.  (I'm using
> the words MUST and MAY as in the meaning established for IETF standards.)

I conjecture that this is acceptable to the majority. This means
however, as I said in a previous follow-up, that NIST, besides 
picking a winner, has to testify the usefulness of a couple of 
other candidates in formal documents with details of the same nature 
as the winner.

M. K. Shen


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Sat, 23 Oct 1999 18:04:26 +0200
From: Mok-Kong Shen <mok-kong.shen@t-online.de>
Message-ID: <3811DC8A.3D1E5CE@t-online.de>
References: <3811AD98.43C6F1DC@aspi.net>
   <38117A10.EBF78F3F@t-online.de>
Newsgroups: sci.crypt
Lines: 24

Trevor Jackson, III wrote:
> 
> Mok-Kong Shen wrote:

> > I conjecture that this is acceptable to the majority. This means
> > however, as I said in a previous follow-up, that NIST, besides
> > picking a winner, has to testify the usefulness of a couple of
> > other candidates in formal documents with details of the same nature
> > as the winner.
> 
> I disagree.  A MUST-implement requirement forces every designer to include the
> MUST cipher even if it will never be used.  I.e., the MAY cipher might so
> dominate the application environment that it is the obvious choice.  What
> benefit is there in forcing implementors to waste their effort on unnecessary
> hoops just to get approval?

But I believe one could be satisfied with a compromise. I guess that
the possibility of NIST announcing, say, 3 candidates to be 'the'
(all entirely equivalent) standards is fiable. So letting one be 
the must and the others be may could be a practicable solution out
of the dilema. Note that one must not use the MUST implementation at 
all. (I am aware that my viewpoint is critisizable. )

M. K. Shen


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Sun, 24 Oct 1999 10:18:04 +0200
From: Mok-Kong Shen <mok-kong.shen@t-online.de>
Message-ID: <3812C0BC.A85E70E8@t-online.de>
References: <381272E4.6F192CC@aspi.net>
   <381233F1.1A2332BA@t-online.de>
Newsgroups: sci.crypt
Lines: 54

Trevor Jackson, III wrote:
> 
> Mok-Kong Shen wrote:
> 
> > Trevor Jackson, III wrote:
> > >
> > > What do you belive is the difference between a MUST implement feature and a MAY
> > > implement feature?
> >
> > I am not sure in which sense your question is posed.
> 
> You suggested that NIST recommend one MUST implement cipher and several MAY implement
> ciphers.  They you said that implementors would not have to implement the MUST
> implement algorithm.  This last statement appears to contradict the definition of
> MUST implement.  It appears that you think the MUST implement cipher you think NIST
> should recommend is and implementation option.  The MAY-implement ciphers are
> obviously optional as well.  So why did you distingush between MUST and MAY if the
> difference makes no difference?

I am quite sure that you mis-read my sentences. I am quoting my
previous post below:

      But I believe one could be satisfied with a compromise. 
      I guess that the possibility of NIST announcing, say, 3 
      candidates to be 'the' (all entirely equivalent) standards 
      is fiable. So letting one be the must and the others be may 
      could be a practicable solution out of the dilema. Note that 
      one must not use the MUST implementation at all. (I am aware 
      that my viewpoint is critisizable. )

I way saying that one (the user) must not use the MUST implementation,
not that the implementor may omit the MUST implementation. This
implies that, if e.g. there are rumors that the winner were broken, he
can simply drop that. While the analogy with standards in programming
languages is only partly appropriate (because we are in our case
considering a number of candidates that are functionally equivalent
to one another, not certain features that are necessary and others
that are not necessary in all situations) I do like to mention that 
the language COBOL has 3 levels in its standard. All implementor must 
implement the first level (without that no meaningful program can be 
written), those that also implement the higher levels can claim that 
their products provide these higher level features. So the market 
demand will determine what kind of complilers at what price category 
one will have. In our case a manufacturer that also implements the 
two MAY algorithms can claim that the user can have a random choice 
of the three available algorithms or do multiple encryption with them. 
Those users that have very have good faith in the winner can buy a 
product that only implements that at a lower price. Since all
implementations have the MUST algorithm, all users can at least
communicate with that and the issue of interoperability vanishes.

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: Sat, 23 Oct 1999 08:41:32 -0400
From: "Trevor Jackson, III" <fullmoon@aspi.net>
Message-ID: <3811ACFC.B07D4E1D@aspi.net>
References: <7urdi4$op0$1@blowfish.isaac.cs.berkeley.edu>
Newsgroups: sci.crypt
Lines: 39

David Wagner wrote:

> In article <MPG.127acf919169e8c98974d@news.mindspring.com>,
> Jerry Coffin <jcoffin@taeus.com> wrote:
> > This bears no relationship to what I proposed at all.  What I proposed
> > was that you start with one cipher.  You use it for ALL communication.
> > When and if you are given reason to believe this cipher is or will
> > become compromised, you switch to the second.  When/if you are given
> > reason to believe that is or may become compromised, you switch to the
> > third.  This continues until you run out of ciphers.
>
> Ahh, you're right, I misunderstood.  I apologize profusely.
>
> Ok, now we're back to the problem of detecting when the opponent has
> broken our cipher.
>
> In any case, there's clearly a cost-benefit tradeoff (in some systems,
> anyway) between (1) cost and (2) ease of switching ciphers if a flaw is
> found, and I'd claim that the right balance point will be different for
> different applications.  Forcing folks to implement multiple _alternates_
> (runners-up) if they want to comply with the AES does make it easier to
> switch ciphers at some future time if necessary, but it's not clear to
> me that it's the right design choice to force on _all_ deployed systems.
>
> My preference would be to have exactly one MUST-implement "AES winner".
> Then, if you like, you can pick several optional alternates that you MAY
> implement at your discretion; I don't care about that part.  (I'm using
> the words MUST and MAY as in the meaning established for IETF standards.)
>
> Would you agree to such an approach?  Or do you feel we need to force
> multiple MUST-implement ciphers on everyone in the world who wants to claim
> AES-compliance?

Why have any MUST implement ciphers at all.  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.  Thus if NIST chooses a set of AES algorithms
any cipher from that set would satisfy the minimum security threshold and thus
be "AES compliant".



Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Sat, 23 Oct 1999 11:22:05 -0700
From: "Roger Schlafly" <real@ieee.org>
Message-ID: <7usubj$2pib@enews3.newsguy.com>
References: <3811ACFC.B07D4E1D@aspi.net>
Newsgroups: sci.crypt
Lines: 18

Trevor Jackson, III <fullmoon@aspi.net> wrote in message
news:3811ACFC.B07D4E1D@aspi.net...
> Why have any MUST implement ciphers at all.  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.  Thus if NIST chooses a set of AES
algorithms
> any cipher from that set would satisfy the minimum security threshold and
thus
> be "AES compliant".

All other things being equal, interoperability is a good thing. That goes
without saying. But even if NIST's role is only one of acceptance testing,
its job is a lot easier with 1 cipher, than with 5 or 15.





Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Sat, 23 Oct 1999 22:49:12 -0400
From: "Trevor Jackson, III" <fullmoon@aspi.net>
Message-ID: <381273A8.F638A516@aspi.net>
References: <7usubj$2pib@enews3.newsguy.com>
Newsgroups: sci.crypt
Lines: 29

Roger Schlafly wrote:

> Trevor Jackson, III <fullmoon@aspi.net> wrote in message
> news:3811ACFC.B07D4E1D@aspi.net...
> > Why have any MUST implement ciphers at all.  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.  Thus if NIST chooses a set of AES
> algorithms
> > any cipher from that set would satisfy the minimum security threshold and
> thus
> > be "AES compliant".
>
> All other things being equal, interoperability is a good thing. That goes
> without saying. But even if NIST's role is only one of acceptance testing,
> its job is a lot easier with 1 cipher, than with 5 or 15.

Since when did the ease of the job become and issue?  Why should we care how
hard it is?  The only think worth considering is the value of the result.  A
single selection is vastly less valuable (to the USG as well as the security
world) than a set of ciphers.

Besides, even if acceptance testing _were_ the goal, which it is not, it's not
that hard.  It's an engineering problem.  You give it to an engineer and he
solves it.  It cannot be made harder than that.





Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: 23 Oct 1999 15:04:20 GMT
From: djohn37050@aol.com (DJohn37050)
Message-ID: <19991023110420.02050.00000283@ng-fa1.aol.com>
References: <7urdi4$op0$1@blowfish.isaac.cs.berkeley.edu>
Newsgroups: sci.crypt
Lines: 3

Yes, my take is that NIST should say there are multiples winners and let the
market sort it out.
Don Johnson


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Sat, 23 Oct 1999 10:52:40 -0700
From: "Roger Schlafly" <real@ieee.org>
Message-ID: <7usske$2oif@enews3.newsguy.com>
References: <19991023110420.02050.00000283@ng-fa1.aol.com>
Newsgroups: sci.crypt
Lines: 12

DJohn37050 <djohn37050@aol.com> wrote in message
news:19991023110420.02050.00000283@ng-fa1.aol.com...
> Yes, my take is that NIST should say there are multiples winners and let
the
> market sort it out.

Why should NIST even be involved at all? You seem to have a theory
that more ciphers are always better, so why not let anyone use any
cipher he wants, and "let the market sort it out"?





Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Sat, 23 Oct 1999 12:42:48 -0600
From: jgfunj@vgrknf.arg (wtshaw)
Message-ID: <jgfunj-2310991242490001@dial-243-032.itexas.net>
References: <7urdi4$op0$1@blowfish.isaac.cs.berkeley.edu>
Newsgroups: sci.crypt
Lines: 11

In article <7urdi4$op0$1@blowfish.isaac.cs.berkeley.edu>,
daw@blowfish.isaac.cs.berkeley.edu (David Wagner) wrote:


> Ok, now we're back to the problem of detecting when the opponent has
> broken our cipher.
> 
The opponent will likely not tell, and will seek to cover information
recovered with another and believable source.
-- 
SSL isn't.


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Sat, 23 Oct 1999 08:38:28 -0400
From: "Trevor Jackson, III" <fullmoon@aspi.net>
Message-ID: <3811AC44.EE814058@aspi.net>
References: <MPG.127acf919169e8c98974d@news.mindspring.com>
Newsgroups: sci.crypt
Lines: 34



Jerry Coffin wrote:

> Now, there some people have proposed ordering the ciphers in the
> standard -- I.e. the standard itself say something to the effect that:
> "here are algorithms 1, 2 and 3" and they'd be used in that order.  I
> don't agree with this approach.  I believe AES should stick to
> algorithms, not protocols.  Protocols are (at least IMO) an entirely
> separate kettle of fish from algorithms, and should be kept separate
> both in the implementation and the standards -- right now FIPS 46-2
> describes a single algorithm; other standards deal with how to do
> chaining, how to do protocols, etc., and I think that's the way things
> should stay.  The one place you'd see something in AES that deal with
> algorithm selection would be a bit like the progression from FIPS 46-2
> to FIPS 46-3 -- this changes the recommendation from DES to 3DES.  In
> a later version of AES, there might be a change from (say) three
> algorithms to two if one of the existing algorithms was found to have
> a substantial weakness.
>
> The basic difference would be that in the AES, there would be more
> than one algorithm described -- nothing more.  Nothing about which one
> is preferred, how to pick between them, negotiate usage, etc.
> Ultimately, ensuring interoperability goes WELL beyond the algorithm,
> and does NOT belong in AES, IMO.  One proposal has suggested that one
> particular algorithm be chosen to include in all possible AES
> implementations.  IMO, this would be pointless since it's still far to
> weak to ensure anything approaching interoperability (just as the
> single algorithm in DES doesn't ensure interoperability between
> products).

This logic leaves me no choice.  I am forced to agree.  The "output" of hte AES
contest chold be a set of ciphers.  NMNL.



Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Fri, 22 Oct 1999 23:58:43 -0400
From: "Trevor Jackson, III" <fullmoon@aspi.net>
Message-ID: <38113273.CCB2D39C@aspi.net>
References: <7uqvg9$ol1$1@blowfish.isaac.cs.berkeley.edu>
Newsgroups: sci.crypt
Lines: 95

David Wagner wrote:

> In article <MPG.127a8eb5cdf3aebe98974a@news.mindspring.com>,
> Jerry Coffin <jcoffin@taeus.com> wrote:
> > 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.
>
> That's not what I said at all.  Please try to understand my reasoning
> before dismissing it out of hand; there may be a fatal flaw in my
> arguments, but I don't think this is it.
>
> > > I think it is more prudent to assume that if you select somehow from a
> > > list of five algorithms for each connection, you may end up with a system
> > > that is only as strong as the weakest of the five algorithms.
> >
> > WHY?  I've already suggested a method that, AT WORST is at least as
> > strong as the method you suggest.
>
> Maybe it is, maybe it isn't.
>
> That's a very strong claim; I'd like to show that it's not only wrong,
> but it's backwards.  Watch closely.
>
> Suppose unbeknownst to us, one of the AES finalists ("the lemon") is
> fatally flawed, but the rest are totally strong.  In other words, let's
> assume that our adversaries are able to read traffic encrypted under
> "the lemon", but we don't realize this.
>
> Now, there are two ways we could have designed our cryptosystems:
>
> 1. Scenario: We picked one lucky finalist as the single AES winner.
>    That cipher, and no other, becomes deployed everywhere.
>
>    Risk: If we pick "the lemon" as our winner, all of traffic is readable.
>
>    Expected result: With probability at most 1/5, all our traffic
>    is readable.  With prob. at least 4/5, all our traffic is secure.
>
> 2. Scenario: All five finalists were designed as winners; the idea is
>    that, for each new connection, one picks a new key at random _and_
>    a new cipher (from the five finalists) at random.  This is what is
>    done in deployed systems worldwide.
>
>    Risk: Every connection that uses "the lemon" is insecure.
>
>    Expected result: With probability 1, exactly 1/5 of our traffic can
>    be read by the adversary.

> Tell me if I'm wrong, but I think #2 summarizes your suggested approach,
> and #1 summarizes the "conventional wisdom" approach.

#2 is not a valid summary of his suggestion.  You assumed that all five ciphers
were in use.  He assumed serial use of multiple ciphers.  I.e., only one cipher is
in use, similar to #1 above.  But in the case that a sour taste is detected, all
traffic switches to another cipher.  This variant, #1+switching, is clearly
superior to the original #1.

>
>
> Let's compare the two approaches.  I claim that #1 is a much better
> situation to be in.  Consider: In many cases when we send the same
> confidential data across multiple connections.
>
> For instance, if we want to keep it a secret that our company is about
> to be bought out by Microsoft, we might have lots of encrypted telephone
> conversations where company employees discuss the impact of that amongst
> themselves.  If the adversary is able to break the encryption associated
> with any one of those phone conversations, he has all the information
> we wanted to hide, and we lose lots of money; from our point of view, if
> he can crack one of them, it's as bad as if he could crack them all.
>
> Now it should become clear why approach #1 is preferable.  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.  Thus, in scenario #2, we are guaranteed
> to get screwed and to lose money.  In contrast, in scenario #1, we lose
> money only if NIST got unlucky when picking a winner for the AES.  Thus,
> in scenario #1, we have at most a 1/5 probability of getting screwed.
>
> Personally, I'd rather take the <= 1/5 probability of getting screwed
> than take the scenario where I'm guaranteed to get screwed!
>
> Now let's compare to what you claimed.  You claimed (if I understand
> correctly) that #2 is "AT WORST" at least as strong as #1.  Yet it should
> now be clear that #2 is weaker than #1: substantially weaker, even.
>
> In fact, I'd claim that you have the statement backwards: the correct
> statement is "scenario #1 (picking a single winner) is AT WORST at least
> as strong as scenario #2 (picking multiple winners), and probably stronger".
>
> So, where did I go wrong?





Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Sat, 23 Oct 1999 11:04:11 +0200
From: Mok-Kong Shen <mok-kong.shen@t-online.de>
Message-ID: <38117A0B.48803CF9@t-online.de>
References: <7uqvg9$ol1$1@blowfish.isaac.cs.berkeley.edu>
Newsgroups: sci.crypt
Lines: 34

David Wagner wrote:
>

> Suppose unbeknownst to us, one of the AES finalists ("the lemon") is
> fatally flawed, but the rest are totally strong.  In other words, let's
> assume that our adversaries are able to read traffic encrypted under
> "the lemon", but we don't realize this.
> 
> Now, there are two ways we could have designed our cryptosystems:
> 
> 1. Scenario: We picked one lucky finalist as the single AES winner.
>    That cipher, and no other, becomes deployed everywhere.
> 
>    Risk: If we pick "the lemon" as our winner, all of traffic is readable.
> 
>    Expected result: With probability at most 1/5, all our traffic
>    is readable.  With prob. at least 4/5, all our traffic is secure.

> 
> 2. Scenario: All five finalists were designed as winners; the idea is
>    that, for each new connection, one picks a new key at random _and_
>    a new cipher (from the five finalists) at random.  This is what is
>    done in deployed systems worldwide.
> 
>    Risk: Every connection that uses "the lemon" is insecure.
> 
>    Expected result: With probability 1, exactly 1/5 of our traffic can
>    be read by the adversary.

Question: Why did you use 'at most' and 'at least' in the first
paragraph above instead of 'exactly' ('exactly' is albeit used in the 
second paragraph cited)? Could you please explain a little bit?

M. K. Shen


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: 24 Oct 1999 13:28:44 -0400
From: juola@mathcs.duq.edu (Patrick Juola)
Message-ID: <7uvfkc$uoh$1@quine.mathcs.duq.edu>
References: <7uqvg9$ol1$1@blowfish.isaac.cs.berkeley.edu>
Newsgroups: sci.crypt
Lines: 56

In article <7uqvg9$ol1$1@blowfish.isaac.cs.berkeley.edu>,
David Wagner <daw@blowfish.isaac.cs.berkeley.edu> wrote:
>In article <MPG.127a8eb5cdf3aebe98974a@news.mindspring.com>,
>Jerry Coffin <jcoffin@taeus.com> wrote:
>Now, there are two ways we could have designed our cryptosystems:
>
>1. Scenario: We picked one lucky finalist as the single AES winner.
>   That cipher, and no other, becomes deployed everywhere.
>
>   Risk: If we pick "the lemon" as our winner, all of traffic is readable.
>
>   Expected result: With probability at most 1/5, all our traffic
>   is readable.  With prob. at least 4/5, all our traffic is secure.
>
>2. Scenario: All five finalists were designed as winners; the idea is
>   that, for each new connection, one picks a new key at random _and_
>   a new cipher (from the five finalists) at random.  This is what is
>   done in deployed systems worldwide.
>
>   Risk: Every connection that uses "the lemon" is insecure.
>
>   Expected result: With probability 1, exactly 1/5 of our traffic can
>   be read by the adversary.
>
>Tell me if I'm wrong, but I think #2 summarizes your suggested approach,
>and #1 summarizes the "conventional wisdom" approach.
>
>Let's compare the two approaches.  I claim that #1 is a much better
>situation to be in.  Consider: In many cases when we send the same
>confidential data across multiple connections.
>
>For instance, if we want to keep it a secret that our company is about
>to be bought out by Microsoft, we might have lots of encrypted telephone
>conversations where company employees discuss the impact of that amongst
>themselves.  If the adversary is able to break the encryption associated
>with any one of those phone conversations, he has all the information
>we wanted to hide, and we lose lots of money; from our point of view, if
>he can crack one of them, it's as bad as if he could crack them all.
>
>Now it should become clear why approach #1 is preferable.  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.

It gets worse.  The exposed messages in situation #2 will provide cribs
for unexposed messages and make the cryptanalysis of those messages
much easier.  So even if the actual secret that you wanted to keep
was only sent via a "secure" method, any related messages encrypted
with the "lemon" will reveal enough plaintext to sugggest probable
plaintext in the "secure" message.

So I think the expected result of situation #2 would be more accurately
expresse that "with probability 1, more than 1/5 of our traffic can
be read by the adversary."

	-kitten


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: 25 Oct 1999 08:08:20 +0100
From: Paul Crowley <paul@hedonism.demon.co.uk>
Message-ID: <873duzlxy4.fsf@hedonism.demon.co.uk>
References: <7uvfkc$uoh$1@quine.mathcs.duq.edu>
Newsgroups: sci.crypt
Lines: 14

juola@mathcs.duq.edu (Patrick Juola) writes:
> It gets worse.  The exposed messages in situation #2 will provide cribs
> for unexposed messages and make the cryptanalysis of those messages
> much easier.

David Wagner's model assumes that only one of the five ciphers used is 
weak, and therefore that the others will be resistant to a known
plaintext attack.  If more than one is weak, I suspect this is only
one of many ways that interactions between them can be used to reduce
the security of the system as a whole.
-- 
  __
\/ o\ paul@hedonism.demon.co.uk     Got a Linux strategy? \ /
/\__/ Paul Crowley  http://www.hedonism.demon.co.uk/paul/ /~\


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Sat, 23 Oct 1999 11:04:05 +0200
From: Mok-Kong Shen <mok-kong.shen@t-online.de>
Message-ID: <38117A05.BF2985B5@t-online.de>
References: <7uqjmb$oei$1@blowfish.isaac.cs.berkeley.edu>
Newsgroups: sci.crypt
Lines: 19

David Wagner wrote:
> 
> I think it is more prudent to assume that if you select somehow from a
> list of five algorithms for each connection, you may end up with a system
> that is only as strong as the weakest of the five algorithms.

I suppose that this has been stated before: If one randomly choose
from a set of algorithms of different strength, then one has a
chance of (sometimes) using the weakest algorithm. The weakness
of the whole has to be weight-summed according to the probability 
of usage. One can of course take the standpoint that it could be 
catastrophical if the weakest algorithm ever gets used and hence
the weakest algorithm determines everything. That's a thoroughly
viable standpoint. But, if one assumes that a few of the finalists
of AES are (yet) unable to be differentiated from one another in
respect of strength (a scenario that I believe to be certain), then 
there is no weakest algorithm to be considered.

M. K. Shen


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Fri, 22 Oct 1999 00:02:36 +0100
From: "Brian Gladman" <gladman@seven77.demon.co.uk>
Message-ID: <940546985.6817.0.nnrp-08.c2de6a96@news.demon.co.uk>
References: <7unmk8$mqh$1@nntp1.atl.mindspring.net>
Newsgroups: sci.crypt
Lines: 41

Roger Schlafly <real@ieee.org> wrote in message
news:7unmk8$mqh$1@nntp1.atl.mindspring.net...
> Brian Gladman <gladman@seven77.demon.co.uk> wrote in message
> news:940501283.15899.0.nnrp-12.c2de6a96@news.demon.co.uk...
> > On what experience base do you assert that satellites are a 'moronic
> > example' of the practical use of encryption?  Encryption on satellites
is
> > inevitably specilaised and hence unrepresentative of typical use.  But I
> > think that 'moronic' goes too far.
>
> I'm sorry, but I agree with Bruce. It is a moronic example.
> Satellite folks do worry about catastrophic failure, but not
> about AES flaws. Even if there is a security failure, it will
> almost certainly not be because the AES block cipher has
> some sort of weakness. There are 100s of other problems,
> each of which is millions of times more likely to go wrong.

From 1980 to 1988 I was responsible for the UKs defence computing and
communications research programme, including satellite based systems and
aspects of the UK's civil R&D programme in this field.  And from 1988 to
1995 I was Director of Strategic Communications in the UK Minsistry of
Defence where I directed the acquisiton of UK and NATO satellite
communications systems.

You are totally wrong - we did worry about the possible impact of
cryptographic failures on both defence and civil satellite systems.  AES
algorithms were not around at the time but had they been, and had their use
been contemplated, I am completely confident that the possibility that they
might fail would have been on our long list of potential problems for
consideration during system design and development.

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.

   Brian Gladman





Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: 21 Oct 1999 23:14:56 GMT
From: djohn37050@aol.com (DJohn37050)
Message-ID: <19991021191456.26924.00000195@ng-bj1.aol.com>
References: <940546985.6817.0.nnrp-08.c2de6a96@news.demon.co.uk>
Newsgroups: sci.crypt
Lines: 2

I did not come up with the satellite example, but I thot it a good one.
Don Johnson


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Thu, 21 Oct 1999 23:07:46 -0700
From: "Roger Schlafly" <real@ieee.org>
Message-ID: <7uouti$1blv@enews2.newsguy.com>
References: <940546985.6817.0.nnrp-08.c2de6a96@news.demon.co.uk>
Newsgroups: sci.crypt
Lines: 19

Brian Gladman <gladman@seven77.demon.co.uk> wrote in message
news:940546985.6817.0.nnrp-08.c2de6a96@news.demon.co.uk...
> From 1980 to 1988 I was responsible for the UKs defence computing and
> communications research programme, including satellite based systems and
> ...
> You are totally wrong - we did worry about the possible impact of
> cryptographic failures on both defence and civil satellite systems.

If you know so much about communications satellites, then I am sure
you choose your words carefully. I'll bet you did worry about
cryptographic failures. I hope someone did, anyway. There are a lot
of possible problems -- theft of keys, leakage of key bits, broken
random number generator, protocol failure, various hardware failures
that might reveal too much, or lock out too much, etc. I'd lose a lot
of sleep over some of these possibilities if I were in charge. But
worrying about weaknesses in the AES block cipher -- NOT.





Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Fri, 22 Oct 1999 13:20:14 +0100
From: "Brian Gladman" <gladman@seven77.demon.co.uk>
Message-ID: <940594844.5782.0.nnrp-11.c2de6a96@news.demon.co.uk>
References: <7uouti$1blv@enews2.newsguy.com>
Newsgroups: sci.crypt
Lines: 36


Roger Schlafly <real@ieee.org> wrote in message
news:7uouti$1blv@enews2.newsguy.com...
> Brian Gladman <gladman@seven77.demon.co.uk> wrote in message
> news:940546985.6817.0.nnrp-08.c2de6a96@news.demon.co.uk...
> > From 1980 to 1988 I was responsible for the UKs defence computing and
> > communications research programme, including satellite based systems and
> > ...
> > You are totally wrong - we did worry about the possible impact of
> > cryptographic failures on both defence and civil satellite systems.
>
> If you know so much about communications satellites, then I am sure
> you choose your words carefully. I'll bet you did worry about
> cryptographic failures. I hope someone did, anyway. There are a lot
> of possible problems -- theft of keys, leakage of key bits, broken
> random number generator, protocol failure, various hardware failures
> that might reveal too much, or lock out too much, etc. I'd lose a lot
> of sleep over some of these possibilities if I were in charge. But
> worrying about weaknesses in the AES block cipher -- NOT.

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.

But returning to the main point at immediate issue, I do not consider the
satellite example to be 'moronic' and nothing you have said has convinced me
otherwise.  And I remain disappointed that Bruce used this emotive and
somewhat uncharitable term to describe it.

But I see little point in continuing this debate - I am content to leave it
up to others to judge whether this was an accurate characterisation.

    Brian Gladman




Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: 22 Oct 1999 08:14:58 +0100
From: Paul Crowley <paul@hedonism.demon.co.uk>
Message-ID: <87puy7hnnx.fsf@hedonism.demon.co.uk>
References: <940501283.15899.0.nnrp-12.c2de6a96@news.demon.co.uk>
Newsgroups: sci.crypt
Lines: 11

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: you could perhaps change the mode of operation,
the number of rounds, or the key schedule, or some similar tweak to
frustrate the attack discovered.  It's not what you might like best;
but it's supposed to be very unlikely that an attack will be found,
and it's nice to know you're not helpless if it is.
-- 
  __
\/ o\ paul@hedonism.demon.co.uk     Got a Linux strategy? \ /
/\__/ Paul Crowley  http://www.hedonism.demon.co.uk/paul/ /~\


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Sat, 23 Oct 1999 18:26:12 GMT
From: ritter@io.com (Terry Ritter)
Message-ID: <3811fd8e.7643988@news.io.com>
References: <87puy7hnnx.fsf@hedonism.demon.co.uk>
Newsgroups: sci.crypt
Lines: 41


On 22 Oct 1999 08:14:58 +0100, in
<87puy7hnnx.fsf@hedonism.demon.co.uk>, in sci.crypt Paul Crowley
<paul@hedonism.demon.co.uk> wrote:

>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: you could perhaps change the mode of operation,
>the number of rounds, or the key schedule, or some similar tweak to
>frustrate the attack discovered.  It's not what you might like best;
>but it's supposed to be very unlikely that an attack will be found,
>and it's nice to know you're not helpless if it is.

In the satellite example, adding fixes to the crypto may be possible,
if there are a limited number of ground stations communicating with
the satellite.  

But when a cipher is to be used by many, to change it is to introduce
incompatibilities, delays, and vast costs.  And during the change-over
delay we have the poor situation of no acceptable cipher at all.  

To avoid this, 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.  In my
experience, both hardware and software often contain supposed
"features" which do not work in practice, and we do not find this
until we actually try to use that feature.  

Of course, the larger reason for changing ciphers is that we cannot
(in general) know whether our cipher is broken.  Clearly, using a
broken cipher is not conducive to successful cryptography.  So if we
insist on continually using the same cipher, we may in fact continue
to expose our data.  If we assume that most ciphers are not broken,
changing ciphers at least gives us a good chance of ending the period
during which our information was exposed.  Our alternative is to never
end the period of exposure.  

---
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: 22 Oct 1999 17:09:05 -0700
From: daw@blowfish.isaac.cs.berkeley.edu (David Wagner)
Message-ID: <7uqub1$ok9$1@blowfish.isaac.cs.berkeley.edu>
References: <940579277.29462.0.nnrp-11.c2de6a96@news.demon.co.uk>
   <7uotnb$n28$1@blowfish.isaac.cs.berkeley.edu>
Newsgroups: sci.crypt
Lines: 33

I temporarily mirrored my earlier posts at
  http://www.cs.berkeley.edu/~daw/tmp/multiple-ciphers.html
The arguments are currently a bit sketchy, and need to be refined a bit
before one can draw any definite conclusions about the AES.  I hope to
find time to get a chance to write a better presentation at some point
in the future, but in the meantime I hope you'll forgive those shortcomings.

I think there are one or two interesting insights that might come out
of this sort of analysis (but they are still only preliminary indications,
so take them with a huge grain of salt):
1. When the same information is sent in different messages (so that
   compromise of any one message in a group is almost as bad as compromise
   as all of them in the group), then putting all our eggs in one
   basket is a _good_ idea.  Using a different cipher to encrypt every
   message in the group runs the risk that we'll get only the strength
   of the weakest of the ciphers, which is undesirable.
2. When we can make some informed guesses at the relative ranking of
   the available ciphers (with regard to security) and gain any advantage
   over random coin flipping, it is to our advantage to exploit that
   information rather than merely selecting ciphers at random.
3. It's better to focus all our cryptanalysis resources on one cipher,
   rather than to split it up among ciphers.  Ideally we'd like a cipher
   that we can be sure is safe; of course we'll never attain that ideal,
   but we'd do well to try to come as close to it as possible.  The
   problem becomes most acute when the adversary's analysis resources
   are much greater than our own---in this case, it is in our interests
   to narrow the analysis gap as much as possible by focusing all our
   attention on analysis of one cipher, to gain as much assurance as
   possible.
These claims are all stated in an informal, intuitive, and non-rigorous
style, but in some sense they are at least somewhat backed up by the
quantitative analysis I did (at least, if you believe that my model is
representative).


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Fri, 22 Oct 1999 23:51:36 -0400
From: "Trevor Jackson, III" <fullmoon@aspi.net>
Message-ID: <381130C8.69ED831@aspi.net>
References: <7uqub1$ok9$1@blowfish.isaac.cs.berkeley.edu>
Newsgroups: sci.crypt
Lines: 74



David Wagner wrote:

> I temporarily mirrored my earlier posts at
>   http://www.cs.berkeley.edu/~daw/tmp/multiple-ciphers.html
> The arguments are currently a bit sketchy, and need to be refined a bit
> before one can draw any definite conclusions about the AES.  I hope to
> find time to get a chance to write a better presentation at some point
> in the future, but in the meantime I hope you'll forgive those shortcomings.
>
> I think there are one or two interesting insights that might come out
> of this sort of analysis (but they are still only preliminary indications,
> so take them with a huge grain of salt):
> 1. When the same information is sent in different messages (so that
>    compromise of any one message in a group is almost as bad as compromise
>    as all of them in the group), then putting all our eggs in one
>    basket is a _good_ idea.  Using a different cipher to encrypt every
>    message in the group runs the risk that we'll get only the strength
>    of the weakest of the ciphers, which is undesirable.
> 2. When we can make some informed guesses at the relative ranking of
>    the available ciphers (with regard to security) and gain any advantage
>    over random coin flipping, it is to our advantage to exploit that
>    information rather than merely selecting ciphers at random.
> 3. It's better to focus all our cryptanalysis resources on one cipher,
>    rather than to split it up among ciphers.  Ideally we'd like a cipher
>    that we can be sure is safe; of course we'll never attain that ideal,
>    but we'd do well to try to come as close to it as possible.  The
>    problem becomes most acute when the adversary's analysis resources
>    are much greater than our own---in this case, it is in our interests
>    to narrow the analysis gap as much as possible by focusing all our
>    attention on analysis of one cipher, to gain as much assurance as
>    possible.

Items 1 & 2 appear sensible, but I suspect they harbor some illusions about our
knowledge of cipher strength.  In the case of 2, for example, if the best we can
do is guess about the relative ranking of ciphers, then we're guessing whether
there is a best cipher within a given set, and further guessing that we are able
to detect that superlative.  I.e., we might be fooling ourselves about the
degree to which one cipher is stronger than another, and in pursuit of a guess,
forego some of the benefits of diversity.

Item 3 is clearly a philosophical issue that may not be resolvable.  It is an
issue worth exploring.  But I must take exception to the concluding remark.  I
dispute that any amout of concentrated analysis of one cipher gives us any
assurance as to it's strength.  We can only report failure to find weakness.
Like being judged Not Guilty by a Court, it cannot be transformed into any kind
of endorsement.

Personally I agree that some concentration of effort is useful because if there
is a weakness that can be found with a reasonable amout of work we'll increase
the chances that we find the easy weaknesses and thus weed out clearly bad
ciphers.

Evolution is not based on the popular phrase "survival of the fittest". It is
based on the death, or non-reproduction, of the unfit.  Thus, rather than chase
a grail (show a cipher strong), I prefer to preserve a [small] set of ciphers as
viable options, concentrating on eliminating from the set those that don't
belong there.

Consider that concentrating all available effort on a single candidate might
backfire.  After all that effort isn't aimed at "strengthening" the cipher but
at finding a weakness in it.  We know it cannot show the candidate strong, but a
successful concentration of effort might show it weak.  What do we do then?  The
can't win/might lose outcome of this approach appears to be improvable.

> These claims are all stated in an informal, intuitive, and non-rigorous
> style, but in some sense they are at least somewhat backed up by the
> quantitative analysis I did (at least, if you believe that my model is
> representative).

I have not read your analyses yet, but I will do so.  Do you believe the results
of your analysis are testable?  Reproducible?



Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Sat, 23 Oct 1999 09:23:00 -0400
From: "Trevor Jackson, III" <fullmoon@aspi.net>
Message-ID: <3811B6B4.A5FA99EC@aspi.net>
References: <7uqub1$ok9$1@blowfish.isaac.cs.berkeley.edu>
Newsgroups: sci.crypt
Lines: 22

David Wagner wrote:

> I temporarily mirrored my earlier posts at
>   http://www.cs.berkeley.edu/~daw/tmp/multiple-ciphers.html
> The arguments are currently a bit sketchy, and need to be refined a bit
> before one can draw any definite conclusions about the AES.  I hope to
> find time to get a chance to write a better presentation at some point
> in the future, but in the meantime I hope you'll forgive those shortcomings.
>

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.  In particular the assumption that
the probability of a break is monotonicly related to the effort spent on
designing and testing it and independent of the effort spent on cracking it.

This assumption appears to be dangerously close to the Labor Theory of Value.  I
believe it to be false.

Thus, since I question the foundation of the model, I do not credit the
conclusions with any signifigance.



Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: 26 Oct 1999 11:44:08 -0700
From: daw@blowfish.isaac.cs.berkeley.edu (David Wagner)
Message-ID: <7v4spo$pt6$1@blowfish.isaac.cs.berkeley.edu>
References: <3811B6B4.A5FA99EC@aspi.net>
Newsgroups: sci.crypt
Lines: 19

In article <3811B6B4.A5FA99EC@aspi.net>,
Trevor Jackson, III <fullmoon@aspi.net> wrote:
> 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.  In particular the assumption that
> the probability of a break is monotonicly related to the effort spent on
> designing and testing it and independent of the effort spent on cracking it.

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, or at least large enough that
dilution effects still were negligible -- so that, if a cipher had a hole,
the adversary would find it.  I suppose this is in line with the tradition
of making conservative assumptions about the adversary's capabilities, although
it might cause inaccuracies for the modelling purposes.

Thanks for pointing that out.  At the very least, it is an assumption which
should have been made explicit; moreover, it seems to be a partial limitation
of the model.  I appreciate the feedback.


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Sat, 23 Oct 1999 22:53:02 GMT
From: ritter@io.com (Terry Ritter)
Message-ID: <38123c48.23637250@news.io.com>
References: <7uqub1$ok9$1@blowfish.isaac.cs.berkeley.edu>
Newsgroups: sci.crypt
Lines: 172


On 22 Oct 1999 17:09:05 -0700, in
<7uqub1$ok9$1@blowfish.isaac.cs.berkeley.edu>, in sci.crypt
daw@blowfish.isaac.cs.berkeley.edu (David Wagner) wrote:

>I temporarily mirrored my earlier posts at
>  http://www.cs.berkeley.edu/~daw/tmp/multiple-ciphers.html
>The arguments are currently a bit sketchy, and need to be refined a bit
>before one can draw any definite conclusions about the AES.  I hope to
>find time to get a chance to write a better presentation at some point
>in the future, but in the meantime I hope you'll forgive those shortcomings.

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.  

You have made a biased presentation of a biased thesis.  That is not a
good start.  


>I think there are one or two interesting insights that might come out
>of this sort of analysis (but they are still only preliminary indications,
>so take them with a huge grain of salt):
>1. When the same information is sent in different messages (so that
>   compromise of any one message in a group is almost as bad as compromise
>   as all of them in the group), then putting all our eggs in one
>   basket is a _good_ idea.  Using a different cipher to encrypt every
>   message in the group runs the risk that we'll get only the strength
>   of the weakest of the ciphers, which is undesirable.

As I have shown before, this silently assumes that we know something
about the strength of the cipher which is the unstated alternative.  

In order to use the term "good" we must compare one alternative with
the other.  In order to make a comparison, we must examine the
alternatives.  When we do, we see that the one cipher we might use
could be the weakest of them all.  And this can happen even if a break
is known for every other cipher except the one we choose.  The result
in that case is that we will continue to use that same weak cipher
forever.

Shall we postulate a distribution of various strengths in the ciphers,
and then the probability of having such-and-such strength?  Surely the
expectation from choosing the one cipher at random would be the same
as moving among all the ciphers at random.  In any case, such a
strengths of ciphers we would use.  We do not know the strengths, we
do not even know that any of the ciphers has any strength at all.  We
can of course *assume* strength, but then the assumptions become our
results.  

On the other hand, there are consequences of choosing one cipher which
are *not* in question:  For one thing, having a single cipher means
that the majority of worthwhile communications are protected by that
one cipher.  The selected cipher thus becomes the ideal single target
for opposition research.  Far more effort will be spent on trying to
break the cipher by people who will not reveal their results than was
ever spent by academics during the original vetting.  To the extent
that effort implies looking for -- and thus, occasionally finding --
previously unknown weakness, having any single cipher sets up the
ideal situation for that cipher to be broken in secret.  And setting
us up to use a cipher which is broken, but which we do not know is
broken, is the worst possible kind of cryptography.  

Another consequence of choosing one cipher is that cipher systems
using that cipher need support only one cipher.  This means that even
if academics discover the cipher is weak, the fielded systems will
generally have no easy way to switch to another cipher, and there will
be tremendous financial pressure to hide or simply ignore any such
results.  The result of course is a weakening of the communications
structure which cryptography was introduced to avoid.  

I claim that unless these issues are included in the model, the model
cannot be expected to provide any insight into reality.  


>2. When we can make some informed guesses at the relative ranking of
>   the available ciphers (with regard to security) and gain any advantage
>   over random coin flipping, it is to our advantage to exploit that
>   information rather than merely selecting ciphers at random.

Clearly, in any system which selects among ciphers for use, we only
use ciphers which are not known to be broken.  Therefore, we have no
information about strength for any of the ciphers we do use.

I would argue that while there can of course be "guesses" with respect
to strength, there simply ARE NO "*informed* guesses."  This is
because strength occurs in the context of the abilities of our
opponent, and we do not know that context.  Thus you are assuming
information which does not (and I think *can* not) exist.  

No scientific basis exists for extrapolating from any tests of
weakness which have been applied, to other -- unknown -- tests of
weakness.  There is no scientific basis for "informed" guesses about
ciphers which have passed all tests.  Indeed, I would argue that even
known weaknesses which are impractical are generally irrelevant to
real use.  


>3. It's better to focus all our cryptanalysis resources on one cipher,
>   rather than to split it up among ciphers.  Ideally we'd like a cipher
>   that we can be sure is safe; of course we'll never attain that ideal,
>   but we'd do well to try to come as close to it as possible.  

This may in fact be the essence of the opposition to the
multiple-cipher model.  But it is false.

We have no measure for cipher strength.  We have no indication whether
additional effort has brought us "nearer" to a result or not.  Added
resources may be doing *something*, but we have no idea whether that
"something" is progressing toward exposing a flaw or not.  We have no
understanding of the size of the search space, and so have no idea
what proportion of it we have addressed.  

Frankly, it does not matter how much effort we put into analyzing a
cipher, if we do not find a weakness and our opponents do.  There is
no scientific basis for assuming that our efforts will be rewarded
proportionally, or even at all.  Cryptanalysis simply does not testify
about the strength of ciphers which have no known weakness.  

And if we do have only one cipher, and continue the examination after
selection, when we get results we have to either contend with changing
a massive installed base, or keep quiet about a true weakness.  In
either case, this sets up cryptanalysts as the "fall guys."


>The
>   problem becomes most acute when the adversary's analysis resources
>   are much greater than our own---in this case, it is in our interests
>   to narrow the analysis gap as much as possible by focusing all our
>   attention on analysis of one cipher, to gain as much assurance as
>   possible.

An "analysis gap" implies some form of quantification.  Two things
come to mind:  effort, and results.  

If the issue is effort, we have no hope that a handful of academics,
working from basically their own grants, can possibly approach the
work which will be put into breaking a standard cipher.  I would
expect that the sum of all opposing efforts would be orders of
magnitude above anything academics can do during the vetting process.
And the more information which is protected by that cipher, the more
resources will be made available to attack it.  Further, these attack
attempts will continue over a much longer period than the original
vetting.  Any attempt to try to "narrow" the gap is thus completely
unrealistic.

If the issue is results, we only get results on *weakness*.  So the
instant we get any serious results on a cipher, that cipher becomes
undesirable.  If that happens to the standard cipher, what do we do?
What are the costs of switching, what will the delays be, and what
will be the situation during those delays?  These costs are incurred
by the choice of a single cipher, do not occur with systems which
naturally change ciphers, and so the costs should appear in any
comparison between the two approaches.  


>These claims are all stated in an informal, intuitive, and non-rigorous
>style, but in some sense they are at least somewhat backed up by the
>quantitative analysis I did (at least, if you believe that my model is
>representative).

Not only do *I* not so believe, it is hard to imagine that *anyone*
could possibly believe that your model represents useful reality.
Trust me:  You do not want to publish this.  

---
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: 26 Oct 1999 11:59:14 -0700
From: daw@blowfish.isaac.cs.berkeley.edu (David Wagner)
Message-ID: <7v4tm2$puf$1@blowfish.isaac.cs.berkeley.edu>
References: <38123c48.23637250@news.io.com>
Newsgroups: sci.crypt
Lines: 21

In article <38123c48.23637250@news.io.com>, Terry Ritter <ritter@io.com> wrote:
> 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.

Yes, you're right.  You (and several others) have given some excellent
feedback which has definitely helped me, and which was not directly
incorporated into that web page.

But the goal wasn't to provide a comprehensive survey of the strengths
and weaknesses of the model.  (I have to leave that for later, due to
lack of time.)  It was just intended as a quick "5-minute" hack to provide
a relatively brief introduction to the proposed model, with a pointer to
more extensive discussion on it on Dejanews.  I don't have time for more.

It's not clear to me how this demonstrates some sort of bias on my part,
but I apologize if I caused any confusion.

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.  Still, if I get a chance, I'll try to reply.

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

Last updated: 2001-06-05