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