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:

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


Subject: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Sun, 10 Oct 1999 15:25:38 GMT From: schneier@counterpane.com (Bruce Schneier) Message-ID: <3804ae80.2804726@news.visi.com> Newsgroups: sci.crypt Lines: 101 Inside Risks #112 CACM vol. 42, no. 10, October 1999. Risks of Relying on Cryptography Bruce Schneier Cryptography is often treated as if it were magic security dust: "sprinkle some on your system, and it is secure; then, you're secure as long as the key length is large enough--112 bits, 128 bits, 256 bits" (I've even seen companies boast of 16,000 bits.) "Sure, there are always new developments in cryptanalysis, but we've never seen an operationally useful cryptanalytic attack against a standard algorithm. Even the analyses of DES aren't any better than brute force in most operational situations. As long as you use a conservative published algorithm, you're secure." This just isn't true. Recently we've seen attacks that hack into the mathematics of cryptography and go beyond traditional cryptanalysis, forcing cryptography to do something new, different, and unexpected. For example: * Using information about timing, power consumption, and radiation of a device when it executes a cryptographic algorithm, cryptanalysts have been able to break smart cards and other would-be secure tokens. These are called ``side-channel attacks.'' * By forcing faults during operation, cryptanalysts have been able to break even more smart cards. This is called ``failure analysis.'' Similarly, cryptanalysts have been able to break other algorithms based on how systems respond to legitimate errors. * One researcher was able to break RSA-signed messages when formatted using the PKCS standard. He did not break RSA, but rather the way it was used. Just think of the beauty: we don't know how to factor large numbers effectively, and we don't know how to break RSA. But if you use RSA in a certain common way, then in some implementations it is possible to break the security of RSA ... without breaking RSA. * Cryptanalysts have analyzed many systems by breaking the pseudorandom number generators used to supply cryptographic keys. The cryptographic algorithms might be secure, but the key-generation procedures were not. Again, think of the beauty: the algorithm is secure, but the method to produce keys for the algorithm has a weakness, which means that there aren't as many possible keys as there should be. * Researchers have broken cryptographic systems by looking at the way different keys are related to each other. Each key might be secure, but the combination of several related keys can be enough to cryptanalyze the system. The common thread through all of these exploits is that they've all pushed the envelope of what constitutes cryptanalysis by using out-of-band information to determine the keys. Before side-channel attacks, the open crypto community did not think about using information other than the plaintext and the ciphertext to attack algorithms. After the first paper, researchers began to look at invasive side channels, attacks based on introducing transient and permanent faults, and other side channels. Suddenly there was a whole new way to do cryptanalysis. Several years ago I was talking with an NSA employee about a particular exploit. He told about how a system was broken; it was a sneaky attack, one that I didn't think should even count. "That's cheating," I said. He looked at me as if I'd just arrived from Neptune. "Defense against cheating" (that is, not playing by the *assumed* rules) is one of the basic tenets of security engineering. Conventional engineering is about making things work. It's the genesis of the term "hack,"' as in "he worked all night and hacked the code together." The code works; it doesn't matter what it looks like. Security engineering is different; it's about making sure things don't do something they shouldn't. It's making sure security isn't broken, even in the presence of a malicious adversary who does everything in his power to make sure that things don't work in the worst possible way at the worst possible times. A good attack is one that the engineers never even thought about. Defending against these unknown attacks is impossible, but the risk can be mitigated with good system design. The mantra of any good security engineer is: "Security is a not a product, but a process." It's more than designing strong cryptography into a system; it's designing the entire system such that all security measures, including cryptography, work together. It's designing the entire system so that when the unexpected attack comes from nowhere, the system can be upgraded and resecured. It's never a matter of "if a security flaw is found," but "when a security flaw is found." This isn't a temporary problem. Cryptanalysts will forever be pushing the envelope of attacks. And whenever crypto is used to protect massive financial resources (especially with world-wide master keys), these violations of designers' assumptions can be expected to be used more aggressively by malicious attackers. As our society becomes more reliant on a digital infrastructure, the process of security must be designed in from the beginning. ********************************************************************** Bruce Schneier, President, Counterpane Systems Phone: 612-823-1098 101 E Minnehaha Parkway, Minneapolis, MN 55419 Fax: 612-823-1590 Free crypto newsletter. See: http://www.counterpane.com
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Sun, 10 Oct 1999 18:11:10 +0200 From: Mok-Kong Shen <mok-kong.shen@t-online.de> Message-ID: <3800BA9E.8F12A758@t-online.de> References: <3804ae80.2804726@news.visi.com> Newsgroups: sci.crypt Lines: 45 Bruce Schneier wrote: > > The common thread through all of these exploits is that they've all > pushed the envelope of what constitutes cryptanalysis by using > out-of-band information to determine the keys. Before side-channel > attacks, the open crypto community did not think about using > information other than the plaintext and the ciphertext to attack > algorithms. After the first paper, researchers began to look at > invasive side channels, attacks based on introducing transient and > permanent faults, and other side channels. Suddenly there was a whole > new way to do cryptanalysis. .................................... > Defending against these unknown attacks is impossible, but the risk > can be mitigated with good system design. The mantra of any good > security engineer is: "Security is a not a product, but a process." > It's more than designing strong cryptography into a system; it's > designing the entire system such that all security measures, including > cryptography, work together. It's designing the entire system so that > when the unexpected attack comes from nowhere, the system can be > upgraded and resecured. It's never a matter of "if a security flaw is > found," but "when a security flaw is found." > > This isn't a temporary problem. Cryptanalysts will forever be pushing > the envelope of attacks. And whenever crypto is used to protect > massive financial resources (especially with world-wide master keys), > these violations of designers' assumptions can be expected to be used > more aggressively by malicious attackers. As our society becomes more > reliant on a digital infrastructure, the process of security must be > designed in from the beginning. I appreciate very much your arguments. I believe the above paragraphs are entirely true and extremely valuable. I like only to mention that some complementary and apparently also useful additional viewpoints may be found in the following reference: T. Ritter, Cryptography. IEEE Computer, Aug. 1999, p.94-95. where, among others, the advantage of multiple encryption using a number of (changing) ciphers is discussed. (This is an application of the general principle of variability in my humble view.) M. K. Shen ----------------------------- http://home.t-online.de/home/mok-kong.shen
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: 10 Oct 1999 21:45:50 GMT From: djohn37050@aol.com (DJohn37050) Message-ID: <19991010174550.05076.00000677@ng-cl1.aol.com> References: <3800BA9E.8F12A758@t-online.de> Newsgroups: sci.crypt Lines: 4 Multiple encryption using different ciphers was also mentioned in my submission to the 2nd AES conference entitled "Future Resiliency: A Possible New AES Criterion" and is available from NIST AES web site. Don Johnson
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Mon, 11 Oct 1999 17:14:24 +0200 From: Mok-Kong Shen <mok-kong.shen@t-online.de> Message-ID: <3801FED0.1FF9D640@t-online.de> References: <19991010174550.05076.00000677@ng-cl1.aol.com> Newsgroups: sci.crypt Lines: 58 DJohn37050 wrote: > > Multiple encryption using different ciphers was also mentioned in my submission > to the 2nd AES conference entitled "Future Resiliency: A Possible New AES > Criterion" and is available from NIST AES web site. I am very happy to be able to read your paper. I believe that a part of the posts to a recent thread on Terry Ritter's paper could have been spared, were your paper known to the participants at that time. The eloquence, with which you advance your arguments and to which I whole-heartedly agree, is simply admirable. However, to be honest, I have considerable doubt as to whether even your highly convincing article succeeds to shaken the time- honoured, deep-rooted conservatism of the bureaucrats. (I suppose here that the one-winner criterion is an expression of that all-pervasive conservatism, which, by the way, I believe is even shared by part of the professionals and academics and which Terry Ritter recently apparently attempted to oppose with his (feeble) one-man campaign.) I want to highlight a tiny point which is certainly implicitly also contained in your paper: Even for a fixed set of n algorithms there are n! ways of combination to build a compound cipher. This combinatorial explosion alone is an effective defense against analysis. The one-winner criterion is in fact absurd if one remembers that in Olympic games there are conferred to the sportsmen besides gold medals also ones made of silver and bronze. I like to cite one sentence from your paper for the readers of this group: If there are a small handful of good algorithms with different attributes, then NIST should sanction those algorithms and let the market decide. I believe that one should clearly realize that the 'war' between defenders and aggressors of information security is non-ending. It's much like one between physicians and microbes. Several decades ago, when penicillin was discovered, plently people believed that infections could soon be totally put under control. Today scientists struggle to find remedies against AIDS. Eventually scientists will win against AIDS, but surely some new diseases will surge up after that. Mr. Schneier mentioned in his post that the discovery of power analysis etc. suddenly poses an new (unexpected) menace. But I vaguely remember someone claiming there are some effective means of protecting against that (which others then surely would attempt to circumvent). Like playing chess, each move of a player will be responded to by his opponents. Or, to draw an analogy from warfare: After missiles are used there are developed anti-missiles. I am sure there are also anti-anti-missiles and anti-anti-anti- ..... ad infinitum. It's pure vanity to assume that one single (fixed) cipher could provide secure communications for the entire world. M. K. Shen ------------------------ http://home.t-online.de/home/mok-kong.shen
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Mon, 11 Oct 1999 10:26:25 -0700 From: Sundial Services <info@sundialservices.com> Message-ID: <38021DC1.500D@sundialservices.com> References: <3801FED0.1FF9D640@t-online.de> Newsgroups: sci.crypt Lines: 49 Mok-Kong Shen wrote: > > I want to highlight a tiny point which is certainly implicitly also > contained in your paper: Even for a fixed set of n algorithms > there are n! ways of combination to build a compound cipher. This > combinatorial explosion alone is an effective defense against > analysis. > The essential point that Bruce mentions is that, if you build an immensely strong bank-vault door to your home, but beside it is an open window ... then your home is -worse- than insecure. It's wide open but you THINK it's safe -- you ASSUME it's safe. When I look at the crypto algorithms that come out today, it seems to me that for all practical civilian purposes all of them are quite strong enough, and have been for some time. True, someone -might- come against them with all the arsenal that Wile E. Coyote sometimes arrayed against the Roadrunner (a few good Dr. Seuss comics also come to mind) ... but everyone else is going to look for some way to go -around- that impregnable doorway, not through it. The key, or the key-scheduling algorithm, is an obvious choice. While algorithms cannot be broken using brute-force, perhaps the key can... there is usually a "phrase you can easily remember" and so on. The list of ingenious methods people can use is just as big as the list of ingenious methods other people use to try to protect things. Strategies like choosing from among 'n' different cipher algorithms, mixing them up in various ways or applying several of them in various ways ... will layer more sheets of bulletproof iron on top of the door we already have. It will not eliminate that open window if it exists. I've found that, the more clever you think you are in creating the protection scheme you put in place -- the more easily you can overlook "another, obvious-now-that-I-see-it" possibility for going completely around it. For instance, at one university I tried to sysop for, I couldn't sleep one night so I tried to log in... and couldn't! Five minutes later my password worked -- and lo, "root" was logged on elsewhere. It turns out that students, who also couldn't sleep, discovered that the password file was unprotected. They simply replaced it, logged on, quickly moved it back. The fact that I discovered the hole was quite by accident. Not a good analogy, I realize, but the point is that the possibility of this "move the iron door out of the way, go inside, put the iron door back" attack had simply never occurred to me. Much less that people were doing it. I changed root-passwords all the time and deceived -myself- into thinking the system was secure.
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Mon, 11 Oct 1999 22:19:41 +0200 From: Mok-Kong Shen <mok-kong.shen@t-online.de> Message-ID: <3802465D.FAA2412F@t-online.de> References: <38021DC1.500D@sundialservices.com> Newsgroups: sci.crypt Lines: 45 Sundial Services wrote: > > Mok-Kong Shen wrote: > > > > I want to highlight a tiny point which is certainly implicitly also > > contained in your paper: Even for a fixed set of n algorithms > > there are n! ways of combination to build a compound cipher. This > > combinatorial explosion alone is an effective defense against > > analysis. > > > > The essential point that Bruce mentions is that, if you build an > immensely strong bank-vault door to your home, but beside it is an open > window ... then your home is -worse- than insecure. It's wide open but > you THINK it's safe -- you ASSUME it's safe. > > When I look at the crypto algorithms that come out today, it seems to me > that for all practical civilian purposes all of them are quite strong > enough, and have been for some time. True, someone -might- come against > them with all the arsenal that Wile E. Coyote sometimes arrayed against > the Roadrunner (a few good Dr. Seuss comics also come to mind) ... but > everyone else is going to look for some way to go -around- that > impregnable doorway, not through it. > > The key, or the key-scheduling algorithm, is an obvious choice. While > algorithms cannot be broken using brute-force, perhaps the key can... > there is usually a "phrase you can easily remember" and so on. The list > of ingenious methods people can use is just as big as the list of > ingenious methods other people use to try to protect things. > > Strategies like choosing from among 'n' different cipher algorithms, > mixing them up in various ways or applying several of them in various > ways ... will layer more sheets of bulletproof iron on top of the door > we already have. It will not eliminate that open window if it exists. > > I've found that, the more clever you think you are in creating the > protection scheme you put in place -- the more easily you can overlook > "another, obvious-now-that-I-see-it" possibility for going completely > around it. What do you have against e.g. multiple encrpytion with the top three algorithms of the final round of AES instead of with the winner of AES alone? M. K. Shen
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Mon, 11 Oct 1999 23:05:53 -0400 From: "Trevor Jackson, III" <fullmoon@aspi.net> Message-ID: <3802A591.A94449EB@aspi.net> References: <38055ece.2545892@news.visi.com> <3802465D.FAA2412F@t-online.de> Newsgroups: sci.crypt Lines: 30 Bruce Schneier wrote: > On Mon, 11 Oct 1999 22:19:41 +0200, Mok-Kong Shen > <mok-kong.shen@t-online.de> wrote: > >What do you have against e.g. multiple encrpytion with the top three > >algorithms of the final round of AES instead of with the winner > >of AES alone? > > It completely misses the point. There isn't just one. > It's like putting an enormous stake > in the ground and hoping the enemy runs right into it, instead of > building a broad palisade. > > Certainly, if you have the time to wait, encrypt with a cascade of > three algorithms. But this solution isn't going to help anyone > writing Internet protocols, for example. Nor implementors of smartcards, record-level database encryption, etc. The list of inappropriate uses of any cipher is larger than the list of appropriate uses. In this instance, multi-level encryption, one would need a justification for spending the extra time/cost/effort involved. But given that justification it's a reasonable answer. Is it your positiom that there is no circumstance justifying multi-level encryption?
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Tue, 12 Oct 1999 14:45:33 GMT From: schneier@counterpane.com (Bruce Schneier) Message-ID: <3803493a.1800228@news.visi.com> References: <3802A591.A94449EB@aspi.net> Newsgroups: sci.crypt Lines: 23 On Mon, 11 Oct 1999 23:05:53 -0400, "Trevor Jackson, III" <fullmoon@aspi.net> wrote: >Nor implementors of smartcards, record-level database encryption, etc. >The list of inappropriate uses of any cipher is larger than the list of >appropriate uses. In this instance, multi-level encryption, one would >need a justification for spending the extra time/cost/effort involved. >But given that justification it's a reasonable answer. Indeed. >Is it your positiom that there is no circumstance justifying multi-level >encryption? Of course not. That would be a rather stupid position. I just didn't see many real-world applications where that was a good solution. Even triple-DES--a perfect example of multi-level encryption--was too slow for many applications. Bruce ********************************************************************** Bruce Schneier, President, Counterpane Systems Phone: 612-823-1098 101 E Minnehaha Parkway, Minneapolis, MN 55419 Fax: 612-823-1590 Free crypto newsletter. See: http://www.counterpane.com
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Tue, 12 Oct 1999 12:46:28 -0400 From: "Trevor Jackson, III" <fullmoon@aspi.net> Message-ID: <380365E4.75BDDC00@aspi.net> References: <3803493a.1800228@news.visi.com> Newsgroups: sci.crypt Lines: 31 Bruce Schneier wrote: > On Mon, 11 Oct 1999 23:05:53 -0400, "Trevor Jackson, III" > <fullmoon@aspi.net> wrote: > >Nor implementors of smartcards, record-level database encryption, etc. > >The list of inappropriate uses of any cipher is larger than the list of > >appropriate uses. In this instance, multi-level encryption, one would > >need a justification for spending the extra time/cost/effort involved. > >But given that justification it's a reasonable answer. > > Indeed. > > >Is it your positiom that there is no circumstance justifying multi-level > >encryption? > > Of course not. That would be a rather stupid position. I just didn't > see many real-world applications where that was a good solution. Even > triple-DES--a perfect example of multi-level encryption--was too slow > for many applications. I guess it depends on what you mean by "many". 3DES may be too slow for many (?) applications, but it might also be fast enough for many (?) applications. You may not have found many (?) real-world applications where it is a good solution, but that may be sampling error. I doubt anyone would criticize you for concentrating your efforts on areas where you and your company can make a difference/contribution/profit. I doubt that finding uses for 3DES ranks high on your personal or corporate agenda.
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Tue, 12 Oct 1999 09:11:38 +0100 From: "Brian Gladman" <gladman@seven77.demon.co.uk> Message-ID: <939715842.16902.0.nnrp-10.c2de6a96@news.demon.co.uk> References: <38055ece.2545892@news.visi.com> <3802465D.FAA2412F@t-online.de> Newsgroups: sci.crypt Lines: 24 Bruce Schneier <schneier@counterpane.com> wrote in message news:38055ece.2545892@news.visi.com... > On Mon, 11 Oct 1999 22:19:41 +0200, Mok-Kong Shen > <mok-kong.shen@t-online.de> wrote: > >What do you have against e.g. multiple encrpytion with the top three > >algorithms of the final round of AES instead of with the winner > >of AES alone? > > It completely misses the point. It's like putting an enormous stake > in the ground and hoping the enemy runs right into it, instead of > building a broad palisade. So let me understand this - those who advocate controlled diversity of algorithm choice through multiple AES winners are driving a single stake in the ground while those who advocate a single AES winner are building a broad palisade. Funny that, but I rather thought that it was the other way round. Brian Gladman
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: 12 Oct 1999 11:50:52 GMT From: djohn37050@aol.com (DJohn37050) Message-ID: <19991012075052.28722.00000022@ng-cq1.aol.com> References: <939715842.16902.0.nnrp-10.c2de6a96@news.demon.co.uk> Newsgroups: sci.crypt Lines: 8 Yes, sometimes the value of the message is so high that it is appropriate to use encrytion with multiple algorithms, just in case one would break. I do not see how the previous statement could be controversial to anyone. I again like Brian's point. For small systems we may need to choose one algorithm to do a particular job, but for large systems, it is much better to go for algorithm independence, etc. Don Johnson
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Tue, 12 Oct 1999 18:23:10 +0200 From: Mok-Kong Shen <mok-kong.shen@t-online.de> Message-ID: <3803606E.67BB7C2C@t-online.de> References: <19991012075052.28722.00000022@ng-cq1.aol.com> Newsgroups: sci.crypt Lines: 18 DJohn37050 wrote: > > Yes, sometimes the value of the message is so high that it is appropriate to > use encrytion with multiple algorithms, just in case one would break. I do not > see how the previous statement could be controversial to anyone. > > I again like Brian's point. For small systems we may need to choose one > algorithm to do a particular job, but for large systems, it is much better to > go for algorithm independence, etc. I warmly recommend those of the group who haven't yet read Don Johnson's paper to do so (access via AES of NIST). The arguments made there for what is termed 'future resiliency perspective' are in my humble opinion entirely sound and extremely convincing. M. K. Shen ------------------------ http://home.t-online.de/home/mok-kong.shen
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: 12 Oct 1999 21:16:41 GMT From: djohn37050@aol.com (DJohn37050) Message-ID: <19991012171641.05056.00000181@ng-co1.aol.com> References: <3803606E.67BB7C2C@t-online.de> Newsgroups: sci.crypt Lines: 6 All right!!!!! And if you want to see my thoughts on future resiliency from an asymmetric algorithm viewpoint, see my presentation and paper made at PKS '99 at www.certicom.com Don Johnson
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Tue, 12 Oct 1999 23:13:20 +0100 From: "Brian Gladman" <gladman@seven77.demon.co.uk> Message-ID: <939766335.5121.0.nnrp-01.c2de6a96@news.demon.co.uk> References: <3804499e.1899628@news.visi.com> <939715842.16902.0.nnrp-10.c2de6a96@news.demon.co.uk> Newsgroups: sci.crypt Lines: 46 Bruce Schneier <schneier@counterpane.com> wrote in message news:3804499e.1899628@news.visi.com... > On Tue, 12 Oct 1999 09:11:38 +0100, "Brian Gladman" > <gladman@seven77.demon.co.uk> wrote: > > > > >Bruce Schneier <schneier@counterpane.com> wrote in message > >news:38055ece.2545892@news.visi.com... > >> On Mon, 11 Oct 1999 22:19:41 +0200, Mok-Kong Shen > >> <mok-kong.shen@t-online.de> wrote: > >> >What do you have against e.g. multiple encrpytion with the top three > >> >algorithms of the final round of AES instead of with the winner > >> >of AES alone? > >> > >> It completely misses the point. It's like putting an enormous stake > >> in the ground and hoping the enemy runs right into it, instead of > >> building a broad palisade. > > > >So let me understand this - those who advocate controlled diversity of > >algorithm choice through multiple AES winners are driving a single stake in > >the ground while those who advocate a single AES winner are building a broad > >palisade. > > No. I am talking about encrypting with multiple algorithms as opposed > to encrypting with a single algorithm. I am not talking about how > many algorithms win AES. Mok-Kong's question asked about "multiple > encryption with the top three algorithms of the final round" as > opposed to the single "winner of the AES." Thanks for the clarification - I thought that you were making a more general point on which I would have to disagree but I now see from this and other posts that you are not denying the existence of situations where multiple sequential encryption using different algorithms will have a positive security value. So all we need now is a good way of meeting ***these*** requirements in the future using open standard algorithms that have secured the widespread support of the cryptographic R&D community. Brian Gladman
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Wed, 13 Oct 1999 22:33:50 GMT From: jsavard@tenMAPSONeerf.edmonton.ab.ca (John Savard) Message-ID: <3805076f.1326616@news.prosurfr.com> References: <939715842.16902.0.nnrp-10.c2de6a96@news.demon.co.uk> Newsgroups: sci.crypt Lines: 38 "Brian Gladman" <gladman@seven77.demon.co.uk> wrote, in part: >Bruce Schneier <schneier@counterpane.com> wrote in message >news:38055ece.2545892@news.visi.com... >> It completely misses the point. It's like putting an enormous stake >> in the ground and hoping the enemy runs right into it, instead of >> building a broad palisade. >So let me understand this - those who advocate controlled diversity of >algorithm choice through multiple AES winners are driving a single stake in >the ground while those who advocate a single AES winner are building a broad >palisade. >Funny that, but I rather thought that it was the other way round. It isn't the idea of having two or three AES winners that Bruce was referring to, but the idea of relying on a system that is based on the principle that, since *no* cipher is proven secure, one needs _thousands_ of ciphers, chosen at random by one's encryption program... with the problem that of those thousands of ciphers, only a handful recieved any serious analysis. The use of multiple encryption, where at least one well-analyzed cipher, like an AES finalist, is among those used, was sort of grudgingly accepted as a possible supplement to the idea by its advocate. This is the proposal that's been criticized as 'driving a stake in the ground', and I can see why that example has been chosen. The author of this proposal has had many useful ideas, but without appreciating or acknowledging the value of the 'conventional' point of view, whether or not this has led to real drawbacks in any idea of his, it will certainly lead to the merits of his ideas not getting a fair hearing. John Savard ( teneerf<- ) http://www.ecn.ab.ca/~jsavard/crypto.htm
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Thu, 14 Oct 1999 02:55:39 GMT From: ritter@io.com (Terry Ritter) Message-ID: <380545dc.11389503@news.io.com> References: <3805076f.1326616@news.prosurfr.com> Newsgroups: sci.crypt Lines: 107 On Wed, 13 Oct 1999 22:33:50 GMT, in <3805076f.1326616@news.prosurfr.com>, in sci.crypt jsavard@tenMAPSONeerf.edmonton.ab.ca (John Savard) wrote: >"Brian Gladman" <gladman@seven77.demon.co.uk> wrote, in part: >>Bruce Schneier <schneier@counterpane.com> wrote in message >>news:38055ece.2545892@news.visi.com... > >>> It completely misses the point. It's like putting an enormous stake >>> in the ground and hoping the enemy runs right into it, instead of >>> building a broad palisade. > >>So let me understand this - those who advocate controlled diversity of >>algorithm choice through multiple AES winners are driving a single stake in >>the ground while those who advocate a single AES winner are building a broad >>palisade. > >>Funny that, but I rather thought that it was the other way round. > >It isn't the idea of having two or three AES winners that Bruce was >referring to, but the idea of relying on a system that is based on the >principle that, since *no* cipher is proven secure, one needs >_thousands_ of ciphers, chosen at random by one's encryption >program... It seems odd to me that you know what is on Schneier's mind, but your summary is wrong: If we could believe that any one cipher is forever unbreakable, we would need no more than that. Our problem is that there is no such evidence. We are ever so casually asked to risk the whole of our information society on mere opinion that, in a very real sense, can have no expertise behind it. Our experts simply cannot know what our opponents may do. We only add ciphers to reduce the risk inherent in the conventional wisdom. The advantage begins with the very first additional cipher. To the extent that any one cipher is a risk, using two different ciphers in sequence tends to protect both. And when we use three different ciphers, then even if one is completely broken, the opponent still does not have known-plaintext for either of the other two. Beyond that, we can also increase the number of ciphers. Or perhaps you will offer a better alternative . . . . >with the problem that of those thousands of ciphers, only a handful >recieved any serious analysis. Thousands? The number of "cipherings" (distinct 3-level cipher stacks) is the cube of the number of ciphers. Surely we can all agree that there are currently hundreds of different ciphers, all constructed in a climate which does not encourage a profusion of ciphers. It seems to me that rather quickly we could have something like 10**6 different cipher stacks available. The point of having many "cipherings" is *not* to increase keyspace per se, but instead to give us the frequent opportunity to change from one ciphering to another, thus terminating any break which may have occurred. We do want to have enough cipherings so that we can support a few broken combinations which expose only a small fraction of our data. Probably thousands is enough. But if we dynamically increase the working set of ciphers (explicitly avoiding any which are known weak, of course), we can force our opponents to support an extremely costly process of detection, acquisition and analysis for every new cipher. This is to our advantage. >The use of multiple encryption, where at least one well-analyzed >cipher, like an AES finalist, is among those used, was sort of >grudgingly accepted as a possible supplement to the idea by its >advocate. Using a particular cipher necessarily reduces the number of different cipher stacks to the square of the number of ciphers, instead of the cube. This is some degree of loss, and the only reason to do it is if someone is convinced that a particular cipher is unbreakable. But there will be many different opinions about which particular cipher that should be. How much different is this from a random selection? >This is the proposal that's been criticized as 'driving a stake in the >ground', and I can see why that example has been chosen. The author of >this proposal has had many useful ideas, but without appreciating or >acknowledging the value of the 'conventional' point of view, whether >or not this has led to real drawbacks in any idea of his, it will >certainly lead to the merits of his ideas not getting a fair hearing. First of all, we are discussing a security flaw at the heart of conventional cryptography. We do not pussyfoot around with serious public issues. Also note that I have in the past presented various ideas at a somewhat lower key, only to see those ideas explicitly avoided by those many trust to provide a complete survey of cryptography. So I've "been there," and "done that." My experience is that those who support the conventional wisdom will avoid anything fundamentally new and disturbing at almost any cost. And if you are not part of the solution, you are part of the problem. --- Terry Ritter ritter@io.com http://www.io.com/~ritter/ Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Fri, 15 Oct 1999 19:07:15 GMT From: jsavard@tenMAPSONeerf.edmonton.ab.ca (John Savard) Message-ID: <38077871.14251584@news.prosurfr.com> References: <380545dc.11389503@news.io.com> Newsgroups: sci.crypt Lines: 37 ritter@io.com (Terry Ritter) wrote, in part: >It seems odd to me that you know what is on Schneier's mind, I can only assume that it was something like your proposal he was criticizing, because such a criticism wouldn't make sense applied to what Brian Gladman was talking about. Your proposal at least appeared to have serious weaknesses, the way people understood it at first. (I certainly grant that you had a right not to be amused at some of the things that happened as the thread went along; you clarified some of the details of what you were proposing as the result of questions, and the response was "how do we know you didn't just steal the idea our question implied".) >My experience is that those who >support the conventional wisdom will avoid anything fundamentally new >and disturbing at almost any cost. And if you are not part of the >solution, you are part of the problem. It's obviously wrong if you jump from "no cipher is proven secure" to "all ciphers are equally bad". You may rightly protest that you never jumped to that kind of conclusion, but at times you allowed it to appear that this was the basis of your multi-ciphering proposal. The "conventional wisdom" in cryptography, as in other fields, did not arise simply by whim or prejudice, but came about as the result of knowledge and experience. That doesn't mean it doesn't have its limitations and omissions - many of which I feel you have correctly located, and are attempting to address. To be "part of the solution", however, one has to be more than a "voice crying in the wilderness". And that involves paying the conventional wisdom its due, and recognizing that due. John Savard ( teneerf<- ) http://www.ecn.ab.ca/~jsavard/crypto.htm
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Sun, 17 Oct 1999 15:41:11 GMT From: ritter@io.com (Terry Ritter) Message-ID: <3809ee12.4602146@news.io.com> References: <38077871.14251584@news.prosurfr.com> Newsgroups: sci.crypt Lines: 112 On Fri, 15 Oct 1999 19:07:15 GMT, in <38077871.14251584@news.prosurfr.com>, in sci.crypt jsavard@tenMAPSONeerf.edmonton.ab.ca (John Savard) wrote: >ritter@io.com (Terry Ritter) wrote, in part: > >>It seems odd to me that you know what is on Schneier's mind, > >I can only assume that it was something like your proposal he was >criticizing, because such a criticism wouldn't make sense applied to >what Brian Gladman was talking about. > >Your proposal at least appeared to have serious weaknesses, the way >people understood it at first. (I certainly grant that you had a right >not to be amused at some of the things that happened as the thread >went along; you clarified some of the details of what you were >proposing as the result of questions, and the response was "how do we >know you didn't just steal the idea our question implied".) We had a big discussion based on my proposals in April 1999, some of which is archived on my pages (see: http://www.io.com/~ritter/NEWS4/LIMCRYPT.HTM ). And I have had various public discussions about parts of this over several years (see from 1996, for example: http://www.io.com/~ritter/CRYPTWAR.HTM for example: http://www.imc.org/workshop/mail-archive/0233.html ). But I think it was just within the last year that I realized how important it was for people to see this before locking AES alone into all future systems. >>My experience is that those who >>support the conventional wisdom will avoid anything fundamentally new >>and disturbing at almost any cost. And if you are not part of the >>solution, you are part of the problem. > >It's obviously wrong if you jump from "no cipher is proven secure" to >"all ciphers are equally bad". I don't believe that, I doubt I ever said it, and find it hard to imagine that anyone could reasonably interpret my words to have that meaning. No matter how many clear unambiguous statements I make, however, it is rather easy for you to misstate my position, as you yourself did in your earlier posting: >>It isn't the idea of having two or three AES winners that Bruce was >>referring to, but the idea of relying on a system that is based on the >>principle that, since *no* cipher is proven secure, one needs >>_thousands_ of ciphers, chosen at random by one's encryption >>program... It is wrong to imply that there is no improvement wrought from each dimension: multiple level ciphering, dynamically changing ciphers, and having many ciphers to choose from. Insisting that the weakness of the proposal is that we don't have many "good" ciphers misstates the situation. The real weakness is that we don't know that we have *one* "good" cipher; now what do we do about it? The problem we have is *not* the proposals, but instead the way things are currently done. Yet we see continued slanted misstatements, despite whole reams of archived messages and summaries which lay it all out. >You may rightly protest that you never >jumped to that kind of conclusion, but at times you allowed it to >appear that this was the basis of your multi-ciphering proposal. I "allowed it to appear"? You say I deliberately allowed a misconception because it would improve my position? No. Nonsense. That did not happen. I don't answer every message, of course. (Currently, even this amount of time is unsustainable for me.) Sometimes I misstate, and sometimes I do make mistakes. But intentionally leaving a false impression? No. Why would I do that? The underlying position is solid and correct. I have no need for misconceptions, and I feel no particular need to "win" at any such cost. This is not about me winning. This is about solving a serious problem on the horizon at a time when the solution cost is relatively small. If we wait for AES-only to get wired-in, we will have a very serious and costly situation indeed. >The "conventional wisdom" in cryptography, as in other fields, did not >arise simply by whim or prejudice, but came about as the result of >knowledge and experience. That doesn't mean it doesn't have its >limitations and omissions - many of which I feel you have correctly >located, and are attempting to address. > >To be "part of the solution", however, one has to be more than a >"voice crying in the wilderness". And that involves paying the >conventional wisdom its due, and recognizing that due. There is no "due." The conventional wisdom *caused* the situation by failing to practice the Science they claim to support. Nor are they in any hurry to correct their error despite the fact that society will actually depend upon this stuff. That hardly deserves respect. --- Terry Ritter ritter@io.com http://www.io.com/~ritter/ Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: 17 Oct 99 19:33:32 GMT From: jsavard@ecn.ab.ca () Message-ID: <380a248c.0@ecn.ab.ca> References: <3809ee12.4602146@news.io.com> Newsgroups: sci.crypt Lines: 67 Terry Ritter (ritter@io.com) wrote: : On Fri, 15 Oct 1999 19:07:15 GMT, in : <38077871.14251584@news.prosurfr.com>, in sci.crypt : jsavard@tenMAPSONeerf.edmonton.ab.ca (John Savard) wrote: : >It's obviously wrong if you jump from "no cipher is proven secure" to : >"all ciphers are equally bad". : I don't believe that, I doubt I ever said it, and find it hard to : imagine that anyone could reasonably interpret my words to have that : meaning. : >You may rightly protest that you never : >jumped to that kind of conclusion, but at times you allowed it to : >appear that this was the basis of your multi-ciphering proposal. : I "allowed it to appear"? You say I deliberately allowed a : misconception because it would improve my position? No. Nonsense. : That did not happen. I agree. When I said "allowed it to appear", I did not mean that you _deliberately_ promoted any misconceptions. It's just that there were flaws in your proposal as it originally appeared, but that, although you did address those flaws (with multiple layers of encryption), you still managed to leave the impression that those measures were less than critical, or that they were an afterthought. And that impression has led to the other impression: that the whole idea is based on faulty reasoning. : This is not about me winning. This is about solving a serious problem : on the horizon at a time when the solution cost is relatively small. : If we wait for AES-only to get wired-in, we will have a very serious : and costly situation indeed. Be assured that AES-only will get wired in to a number of systems, but that encryption will also be done elsewhere in software in a multitude of ways. : >The "conventional wisdom" in cryptography, as in other fields, did not : >arise simply by whim or prejudice, but came about as the result of : >knowledge and experience. That doesn't mean it doesn't have its : >limitations and omissions - many of which I feel you have correctly : >located, and are attempting to address. : >To be "part of the solution", however, one has to be more than a : >"voice crying in the wilderness". And that involves paying the : >conventional wisdom its due, and recognizing that due. : There is no "due." The conventional wisdom *caused* the situation by : failing to practice the Science they claim to support. Nor are they : in any hurry to correct their error despite the fact that society will : actually depend upon this stuff. That hardly deserves respect. Of course, I do not agree. The specific part of the conventional wisdom at issue here is the importance of extensive study and testing of any cipher. As cipher designs have a large "infant mortality", and it gets harder and harder to find flaws in those ciphers that have survived longer, this isn't unscientific. You have pointed out a problem that needs correcting, and a way to correct it: but that isn't enough. It also has to be made clear that the proposed method of correcting matters won't make things worse. I think I can see that this can be avoided, but I also understand why quite a few people are remaining unconvinced. John Savard
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Sat, 16 Oct 1999 01:23:21 GMT From: bryan.olson@uptronics.com Message-ID: <7u8k22$g32$1@nnrp1.deja.com> References: <380545dc.11389503@news.io.com> Newsgroups: sci.crypt Lines: 129 Terry Ritter wrote: > John Savard wrote: > >It isn't the idea of having two or three AES winners that Bruce was > >referring to, but the idea of relying on a system that is based on the > >principle that, since *no* cipher is proven secure, one needs > >_thousands_ of ciphers, chosen at random by one's encryption > >program... > > It seems odd to me that you know what is on Schneier's mind, Isn't that what this reading and writing thing is all about? > but your > summary is wrong: If we could believe that any one cipher is forever > unbreakable, we would need no more than that. His summary was fine; your claim above is simply non responsive. > Our problem is that > there is no such evidence. We are ever so casually asked to risk the > whole of our information society on mere opinion that, in a very real > sense, can have no expertise behind it. Our experts simply cannot > know what our opponents may do. We are on shaky ground relying on the scientific method to resolve mathematical questions, but so far it's the best we have figured out how to do. > We only add ciphers to reduce the risk inherent in the conventional > wisdom. The advantage begins with the very first additional cipher. In terms of provable, quantifiable, security, they are tied at squat. No advantage there. > To the extent that any one cipher is a risk, using two different > ciphers in sequence tends to protect both. And when we use three > different ciphers, then even if one is completely broken, the opponent > still does not have known-plaintext for either of the other two. Ah, _relative_ security. We have proofs of that. > Beyond that, we can also increase the number of ciphers. > > Or perhaps you will offer a better alternative . . . . The point is that the conventional wisdom is already a better alternative than this per-message change of ciphers. > The point of having many "cipherings" is *not* to increase keyspace > per se, but instead to give us the frequent opportunity to change from > one ciphering to another, thus terminating any break which may have > occurred. And opening one where previously blocked. > We do want to have enough cipherings so that we can support > a few broken combinations which expose only a small fraction of our > data. Probably thousands is enough. A small chance of exposing all my plaintext is far better than a large chance of exposing a small portion. The many-cipher system offers a bad trade. > But if we dynamically increase the working set of ciphers (explicitly > avoiding any which are known weak, of course), we can force our > opponents to support an extremely costly process of detection, > acquisition and analysis for every new cipher. This is to our > advantage. The attacker can just go after the low-hanging fruit. He gets a bigger advantage than we do. He can also propose ciphers that he can break. How do you know not to use them? > >The use of multiple encryption, where at least one well-analyzed > >cipher, like an AES finalist, is among those used, was sort of > >grudgingly accepted as a possible supplement to the idea by its > >advocate. > > Using a particular cipher necessarily reduces the number of different > cipher stacks to the square of the number of ciphers, instead of the > cube. This is some degree of loss, and the only reason to do it is if > someone is convinced that a particular cipher is unbreakable. But > there will be many different opinions about which particular cipher > that should be. How much different is this from a random selection? Very. It puts a lower limit on the strength of the combinations. It protects us in the face of attacks on the selection process - what we might call the "chosen cipher" attack. > First of all, we are discussing a security flaw at the heart of > conventional cryptography. We do not pussyfoot around with serious > public issues. I don't know exactly what constitutes "pussyfooting", but you continue to ignore the devastating flaws in the per -message cipher choice. > Also note that I have in the past presented various ideas at a > somewhat lower key, only to see those ideas explicitly avoided by > those many trust to provide a complete survey of cryptography. So > I've "been there," and "done that." Been where and done what? According to your posts, you've been a crypto consultant over the years when DES, the only real standard, was dying. How many of these hundred-cipher systems have you built? How many are in use? Those who are trusted have an obligation to avoid techniques they believe are inferior. > My experience is that those who > support the conventional wisdom will avoid anything fundamentally new > and disturbing at almost any cost. A look at the course cryptography has taken since the "New Directions" paper should disabuse one of the notion that the field rejects new and disturbing ideas. --Bryan Sent via Deja.com http://www.deja.com/ Before you buy.
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Tue, 12 Oct 1999 00:33:57 GMT From: dcd@firstnethou.com (Dan Day) Message-ID: <38087cc1.7586514@news.globalcenter.net> References: <38021DC1.500D@sundialservices.com> Newsgroups: sci.crypt Lines: 62 On Mon, 11 Oct 1999 10:26:25 -0700, Sundial Services <info@sundialservices.com> wrote: >For instance, at one university I tried to sysop for, I couldn't sleep >one night so I tried to log in... and couldn't! Five minutes later my >password worked -- and lo, "root" was logged on elsewhere. It turns out >that students, who also couldn't sleep, discovered that the password >file was unprotected. They simply replaced it, logged on, quickly moved >it back. The fact that I discovered the hole was quite by accident. >Not a good analogy, I realize, but the point is that the possibility of >this "move the iron door out of the way, go inside, put the iron door >back" attack had simply never occurred to me. Much less that people >were doing it. I changed root-passwords all the time and deceived >-myself- into thinking the system was secure. We pulled a similar dodge back when I was in college... On a PDP 11/70 with the RSTS/E timesharing system, the following properties held: 1. Only a "privileged" account could set the bit on an executable file which enabled the executable to perform privileged operations even when run by a non-privileged user. (This is how a lot of the system software and features were implemented.) 2. If a non-privileged user tried to compile a new (rogue) executable "into" the existing "priviledged-bit-on" executable, the system wisely turned off the "privileged bit". Sounds reasonably secure, no? No. One day, I hit upon the following simple scheme to crack the system wide open: 1. Compile program "A", which would perform any nefarious act I wanted to perform if only the "privilege bit" were set. 2. Search the system for any privileged executable that had the read-write flags enabled, and that was at least as large as program "A". Call this program "B". 3. Write a quickie "BASIC" program that opened "B" as a data file and copied all of its bytes to temporary file "C". 4. Use the same BASIC program to copy the byte contents of "A" into "B". This, amazingly enough, left the privileged bit of "B" still on. I now had my own rogue program existing under name "B", and privileged, and could perform absolutely any operation of which the system was capable, including creating my own privileged login. Once I opened the door, it was a simple matter to then get the original contents of "B" out of temporary copy "C" and stuff them back into "B" where they belonged, leaving the system as it had been originally (more or less...) Clearly, this was *not* something that the system developers had counted on... They were apparently under the misconception that only the compiler would be writing to executable files. Sadly, I lacked the dishonest nature which would have enabled me to change my grades, or put myself on the college payroll system, so it was little more than an academic exercise, but still... -- "How strangely will the Tools of a Tyrant pervert the plain Meaning of Words!" --Samuel Adams (1722-1803), letter to John Pitts, January 21, 1776
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Mon, 11 Oct 1999 23:13:09 -0400 From: "Trevor Jackson, III" <fullmoon@aspi.net> Message-ID: <3802A745.41AF101B@aspi.net> References: <38087cc1.7586514@news.globalcenter.net> Newsgroups: sci.crypt Lines: 70 Dan Day wrote: > On Mon, 11 Oct 1999 10:26:25 -0700, Sundial Services <info@sundialservices.com> > wrote: > >For instance, at one university I tried to sysop for, I couldn't sleep > >one night so I tried to log in... and couldn't! Five minutes later my > >password worked -- and lo, "root" was logged on elsewhere. It turns out > >that students, who also couldn't sleep, discovered that the password > >file was unprotected. They simply replaced it, logged on, quickly moved > >it back. The fact that I discovered the hole was quite by accident. > >Not a good analogy, I realize, but the point is that the possibility of > >this "move the iron door out of the way, go inside, put the iron door > >back" attack had simply never occurred to me. Much less that people > >were doing it. I changed root-passwords all the time and deceived > >-myself- into thinking the system was secure. > > We pulled a similar dodge back when I was in college... On a > PDP 11/70 with the RSTS/E timesharing system, the following properties > held: > 1. Only a "privileged" account could set the bit on an executable > file which enabled the executable to perform privileged operations > even when run by a non-privileged user. (This is how a lot of > the system software and features were implemented.) > 2. If a non-privileged user tried to compile a new (rogue) executable > "into" the existing "priviledged-bit-on" executable, the system > wisely turned off the "privileged bit". > > Sounds reasonably secure, no? No. > > One day, I hit upon the following simple scheme to crack the system > wide open: > 1. Compile program "A", which would perform any nefarious act > I wanted to perform if only the "privilege bit" were set. > 2. Search the system for any privileged executable that had the > read-write flags enabled, and that was at least as large > as program "A". Call this program "B". > 3. Write a quickie "BASIC" program that opened "B" as a data > file and copied all of its bytes to temporary file "C". > 4. Use the same BASIC program to copy the byte contents of > "A" into "B". This, amazingly enough, left the privileged > bit of "B" still on. This is almost exactly the technique used to crack multics, which was designed from the ground up to be secure including hardware memory protection. The only difference is that the multics crack used a hole in the memory protection hardware to create trojans out of privileged programs. When a user activated a trojan it would first ransacked the users file space looking for top secret files and then copy the original progam overitself to perform the requested operation.. > > > I now had my own rogue program existing under name "B", and privileged, > and could perform absolutely any operation of which the system was > capable, including creating my own privileged login. > > Once I opened the door, it was a simple matter to then get the original > contents of "B" out of temporary copy "C" and stuff them back into > "B" where they belonged, leaving the system as it had been originally > (more or less...) > > Clearly, this was *not* something that the system developers had > counted on... They were apparently under the misconception that > only the compiler would be writing to executable files. > > Sadly, I lacked the dishonest nature which would have enabled me > to change my grades, or put myself on the college payroll system, > so it was little more than an academic exercise, but still...
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Mon, 11 Oct 1999 17:41:15 +0100 From: "Brian Gladman" <gladman@seven77.demon.co.uk> Message-ID: <939660019.585.0.nnrp-06.c2de6a96@news.demon.co.uk> References: <3801f648.290065@news.visi.com> <19991010174550.05076.00000677@ng-cl1.aol.com> Newsgroups: sci.crypt Lines: 46 Bruce Schneier <schneier@counterpane.com> wrote in message news:3801f648.290065@news.visi.com... > On 10 Oct 1999 21:45:50 GMT, djohn37050@aol.com (DJohn37050) wrote: > > >Multiple encryption using different ciphers was also mentioned in my submission > >to the 2nd AES conference entitled "Future Resiliency: A Possible New AES > >Criterion" and is available from NIST AES web site. > > Yes. In general, I find it uninteresting to talk about encryption > when there are no constraints. Of course you can use multiple > encryption using different ciphers, if you have the time/gates/etc. > Of course it's more secure, as is almost everything if you throw > enough rounds at it. > > Where it really matters, and where real cryptography comes into play, > is when you have to deal with real-world performance decisions. I > almost never have clients who can devote an arbitrary amount of > computing resources to the encryption process. This is why AES is > important. The principle of using two different algorithms in sequence to achieve a degree of protection against any individual weaknesses that they might have is a well established technique that is often used where very long term protection is needed (i.e over decades). This does not need an arbitrary amount of computing resource but, for similar algorithms, about twice the direct resources that only one would require. Moreover, in many situations the cost of the symmetric encryption process will be small compared with other processing costs so this overhead will not be large. I agree that AES is important (a) in establishing a set of secure algorithms, and (b) in removing excessive diversity of choice. In my view, however, we need more than one winner since this will allow a degree of choice in dedicated, closed applications, a worthwhile degree of diversity in open applications (which already typically offer a choice of algorithms) and the ability to employ multiple, sequential encryption using different (but still open standard) algorithms where the requirement justifies this. Moreover, I am assured that the choice between a single and multiple AES winners remains open so the issue is an important one that is worthy of debate. Brian Gladman
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: 11 Oct 1999 16:50:03 GMT From: djohn37050@aol.com (DJohn37050) Message-ID: <19991011125003.11994.00000127@ng-cl1.aol.com> References: <939660019.585.0.nnrp-06.c2de6a96@news.demon.co.uk> Newsgroups: sci.crypt Lines: 2 Brian says it so well. Don Johnson
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Thu, 14 Oct 1999 12:33:11 +0100 From: "Brian Gladman" <gladman@seven77.demon.co.uk> Message-ID: <939900926.22743.0.nnrp-12.c2de6a96@news.demon.co.uk> References: <7u41at$1acd@enews1.newsguy.com> <38052703.45FB@sundialservices.com> Newsgroups: sci.crypt Lines: 23 Roger Schlafly <real@ieee.org> wrote in message news:7u41at$1acd@enews1.newsguy.com... > Sundial Services <info@sundialservices.com> wrote in message > news:38052703.45FB@sundialservices.com... > Yes, that's right. Those who subscribe to the theory that > it is better to use your own homebrew combination of > ciphers can just use the AES finalists. Everyone else will > just use the AES winner. The arguments for multiple AES winners cannot be dismissed so easily. There are at least three reasons for wanting more than one winner: (1) to provide a degree of choice in dedicated, closed applications, (2) to provide a degree of diversity in open applications (a well established practice), and (3) to meet requirements that benefit from the sequential application of different encryption algortithms (again an established practice). Brian Gladman
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Thu, 14 Oct 1999 14:35:38 GMT From: schneier@counterpane.com (Bruce Schneier) Message-ID: <3807e932.1387860@news.visi.com> References: <939900926.22743.0.nnrp-12.c2de6a96@news.demon.co.uk> Newsgroups: sci.crypt Lines: 48 On Thu, 14 Oct 1999 12:33:11 +0100, "Brian Gladman" <gladman@seven77.demon.co.uk> wrote: > >Roger Schlafly <real@ieee.org> wrote in message >news:7u41at$1acd@enews1.newsguy.com... >> Sundial Services <info@sundialservices.com> wrote in message >> news:38052703.45FB@sundialservices.com... > >> Yes, that's right. Those who subscribe to the theory that >> it is better to use your own homebrew combination of >> ciphers can just use the AES finalists. Everyone else will >> just use the AES winner. > >The arguments for multiple AES winners cannot be dismissed so easily. There >are at least three reasons for wanting more than one winner: (1) to provide >a degree of choice in dedicated, closed applications, (2) to provide a >degree of diversity in open applications (a well established practice), and >(3) to meet requirements that benefit from the sequential application of >different encryption algortithms (again an established practice). (3) doesn't make sense to me. Whether there is one winner or several, those that want to cascade multiple algorithms will do so. They do so now, and there's no problem. I disagree with (2) also, primarily from a hardware perspective. I've gone to Ascend, Cisco, and other companies to discuss AES. The first thing they are concerned about is how they will be able to fit the algorithms into their hardware. Multiple algorithms means more chip real estate; they hate that. In software it's no problem adding another algorithm, but it is in hardware. As to (1), why does it make sense to give people without the expertise to make a choice a choice? If we, as the world's non-military cryptographers, cannot choose an algorithm, why should we expect others to? My primary worry is that a system that has a choice of algorithms will, operationally, be as secure as the weakest. If that is the case, diversity is necessarily bad. And we will always have a backup algorithm: triple-DES. I see no benefit from NIST passing the buck and not making a decision. Bruce ********************************************************************** Bruce Schneier, President, Counterpane Systems Phone: 612-823-1098 101 E Minnehaha Parkway, Minneapolis, MN 55419 Fax: 612-823-1590 Free crypto newsletter. See: http://www.counterpane.com
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Thu, 14 Oct 1999 21:00:15 +0100 From: "Brian Gladman" <gladman@seven77.demon.co.uk> Message-ID: <939931146.26204.0.nnrp-11.c2de6a96@news.demon.co.uk> References: <3807e932.1387860@news.visi.com> Newsgroups: sci.crypt Lines: 81 Bruce Schneier <schneier@counterpane.com> wrote in message news:3807e932.1387860@news.visi.com... > On Thu, 14 Oct 1999 12:33:11 +0100, "Brian Gladman" > <gladman@seven77.demon.co.uk> wrote: > [snip] > >The arguments for multiple AES winners cannot be dismissed so easily.There > >are at least three reasons for wanting more than one winner: (1) to provide > >a degree of choice in dedicated, closed applications, (2) to provide a > >degree of diversity in open applications (a well established practice), and > >(3) to meet requirements that benefit from the sequential application of > >different encryption algortithms (again an established practice). > > (3) doesn't make sense to me. Whether there is one winner or several, > those that want to cascade multiple algorithms will do so. They do so > now, and there's no problem. I am inclined to believe that five algorithms provides too much diversity and this might be the result of choosing just one winner. I have less of a concern if we eliminate two and choose a winner from the remaining three but we would need to ensure that all three that remain are free of all IPR constraints. > I disagree with (2) also, primarily from a hardware perspective. I've > gone to Ascend, Cisco, and other companies to discuss AES. The first > thing they are concerned about is how they will be able to fit the > algorithms into their hardware. Multiple algorithms means more chip > real estate; they hate that. In software it's no problem adding > another algorithm, but it is in hardware. AFAIK no-one is saying that an application must offer multiple algorithms. And I don't see hardware suppliers going out of business in a multiple algorithm environment - if this is a requirement I am completely confident that they will meet it. While we should, of course, take the concerns of hardware suppliers into account, we should also recognise that other suppliers will be able to provide algorithm diversity without great difficulty and will see market advantages in doing so (as they do now). > As to (1), why does it make sense to give people without the expertise > to make a choice a choice? If we, as the world's non-military > cryptographers, cannot choose an algorithm, why should we expect > others to? One reason is that they may have more information than we have when they make their choice. It is quite possible that after the single AES winner has been selected more information will come to light that will cast doubt on its security performance. The provision of limited algorithm diversity (on the lines proposed by Don Johnson) provides a degree of protection against this possibility. In simple terms its not good security practice to put all our eggs in one basket, especially so when we cannot be certain that the basket does not have holes in it. > My primary worry is that a system that has a choice of algorithms > will, operationally, be as secure as the weakest. If that is the > case, diversity is necessarily bad. And we will always have a backup > algorithm: triple-DES. I see no benefit from NIST passing the buck > and not making a decision. I agree that there are engineering issues involved in using mutiple algorithms that can cause problems but these are not necesarily difficult to overcome. In any event we already have a great deal of practical experience here since many internet protocols already employ such features. And I don't see a very convincing reason to use an interim algorithm with a 64 bit block length as a backup when some of the world's best cryptographers have provided five carefully designed algorithms from which to make our choice. Nor do I see multiple algorithm choice by NIST as passing the buck - its about ensuring that the AES programme delivers what is needed instead of assuming that what was right last time is still right now. Brian Gladman
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Thu, 14 Oct 1999 22:57:23 +0200 From: Mok-Kong Shen <mok-kong.shen@t-online.de> Message-ID: <380643B3.660859EE@t-online.de> References: <939931146.26204.0.nnrp-11.c2de6a96@news.demon.co.uk> Newsgroups: sci.crypt Lines: 36 Brian Gladman wrote: > > AFAIK no-one is saying that an application must offer multiple algorithms. > And I don't see hardware suppliers going out of business in a multiple > algorithm environment - if this is a requirement I am completely confident > that they will meet it. ................ > One reason is that they may have more information than we have when they > make their choice. It is quite possible that after the single AES winner > has been selected more information will come to light that will cast doubt > on its security performance. The provision of limited algorithm diversity > (on the lines proposed by Don Johnson) provides a degree of protection > against this possibility. In simple terms its not good security practice to > put all our eggs in one basket, especially so when we cannot be certain that > the basket does not have holes in it. > I agree that there are engineering issues involved in using mutiple > algorithms that can cause problems but these are not necesarily difficult to > overcome. In any event we already have a great deal of practical experience > here since many internet protocols already employ such features. ..................... > > Nor do I see multiple algorithm choice by NIST as passing the buck - its > about ensuring that the AES programme delivers what is needed instead of > assuming that what was right last time is still right now. I guess it could perhaps also be useful to know the raison de etre of 3DES after DES has come out. If we'll have 3AES, then it certainly wouldn't be a big step in my humble opinion to employ instead the three top ones in the final round of AES contest for multiple encryption. M. K. Shen
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Thu, 14 Oct 1999 23:07:57 -0700 From: "Roger Schlafly" <real@ieee.org> Message-ID: <7u6g9a$hl1@enews3.newsguy.com> References: <19991014205614.19168.00000326@ng-fo1.aol.com> <380643B3.660859EE@t-online.de> Newsgroups: sci.crypt Lines: 14 DJohn37050 <djohn37050@aol.com> wrote in message news:19991014205614.19168.00000326@ng-fo1.aol.com... > BTW, when I made my presentation to ANSI X9F1, the consensus by a large margin > was to ask NIST to include "future resiliency" as an AES criterion. What do the bankers mean by the term "future resiliency"? That the AES winner not be broken in the future? These are the same folks who want "strong" keys for RSA. Do they also want strong keys for AES? <g>
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: 15 Oct 1999 09:18:32 GMT From: peter@office.knowledge.com (Peter Galbavy) Message-ID: <slrn80dsb7.bi6.peter@office.knowledge.com> References: <939931146.26204.0.nnrp-11.c2de6a96@news.demon.co.uk> Newsgroups: sci.crypt Lines: 24 In article <939931146.26204.0.nnrp-11.c2de6a96@news.demon.co.uk>, Brian Gladman wrote: >I am inclined to believe that five algorithms provides too much diversity >and this might be the result of choosing just one winner. I have less of a >concern if we eliminate two and choose a winner from the remaining three but >we would need to ensure that all three that remain are free of all IPR >constraints. Should I, in all seriousness, be thankful that the AES contest is being undertaken in the US ? In the UK, I can guarentee you the outcome: The winner would be the company holding the most profitable IPR that then subsequently employs the government miniter(s) responsible for the selection, after they leave parliment. What safeguards are there to prevent this ? I remember reading that most participants will give out "free" licenses if their contestant is chosen - but is there a mandatory surrender of those rights required to complete ? (Kudos to those who are entering non-IPR laden entries). Regards, -- Peter Galbavy Knowledge Matters Ltd http://www.knowledge.com/
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: 16 Oct 1999 17:30:59 GMT From: David A Molnar <dmolnar@fas.harvard.edu> Message-ID: <7uacoj$sva$1@news.fas.harvard.edu> References: <slrn80dsb7.bi6.peter@office.knowledge.com> Newsgroups: sci.crypt Lines: 8 Peter Galbavy <peter@office.knowledge.com> wrote: > chosen - but is there a mandatory surrender of those rights required > to complete ? (Kudos to those who are entering non-IPR laden entries). Not to compete, but the winner must be freely available to all in the same fashion as DES and DSA are.
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Sun, 17 Oct 1999 17:04:28 GMT From: ritter@io.com (Terry Ritter) Message-ID: <380a0172.9562959@news.io.com> References: <7uacoj$sva$1@news.fas.harvard.edu> Newsgroups: sci.crypt Lines: 29 On 16 Oct 1999 17:30:59 GMT, in <7uacoj$sva$1@news.fas.harvard.edu>, in sci.crypt David A Molnar <dmolnar@fas.harvard.edu> wrote: >Peter Galbavy <peter@office.knowledge.com> wrote: >> chosen - but is there a mandatory surrender of those rights required >> to complete ? (Kudos to those who are entering non-IPR laden entries). > >Not to compete, but the winner must be freely available to all in the same >fashion as DES and DSA are. To compete, one first had to give up rights *if* one's entry was chosen by NIST. That is called an *option* on rights, and options are not normally free, yet there was no compensation for meeting this requirement. Of course, those who had no rights were not inconvenienced at all. Oddly, "free" does not mean free to the end user: Software using AES is not required to be free. Hardware using AES is not required to be free. Apparently, "free" means that the manufacturers get some of their raw materials free, so they can have higher profits. Everybody gets to make money, except for cipher designers. Which of course tends to prevent the establishment of an industry of cipher design, something I assume the government would like to avoid. --- Terry Ritter ritter@io.com http://www.io.com/~ritter/ Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Tue, 19 Oct 1999 19:08:17 GMT From: Tim Tyler <tt@cryogen.com> Message-ID: <FJv6Ht.Jss@bath.ac.uk> References: <3807e932.1387860@news.visi.com> Newsgroups: sci.crypt Lines: 13 Bruce Schneier <schneier@counterpane.com> wrote: : If we, as the world's non-military cryptographers, cannot choose an : algorithm, why should we expect others to? There is no such thing as a non-military cryptographer: Business is war (Japaneese proverb). -- __________ |im |yler The Mandala Centre http://www.mandala.co.uk/ tt@cryogen.com Imagination is the only weapon in the war against reality.
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Thu, 14 Oct 1999 17:07:03 GMT From: Bob Silverman <bobs@rsa.com> Message-ID: <7u52ja$t8e$1@nnrp1.deja.com> References: <939900926.22743.0.nnrp-12.c2de6a96@news.demon.co.uk> Newsgroups: sci.crypt Lines: 35 In article <939900926.22743.0.nnrp-12.c2de6a96@news.demon.co.uk>, "Brian Gladman" <gladman@seven77.demon.co.uk> wrote: > > The arguments for multiple AES winners cannot be dismissed so easily. Yes it can. By one word. The word is: interoperability. By allowing multiple algorithms you are certain to guarantee that there will be some users who can't talk to others. There > are at least three reasons for wanting more than one winner: (1) to provide > a degree of choice in dedicated, closed applications, (2) to provide a > degree of diversity in open applications Why does everyone use TCP/IP? Repeat after me: A Standard allows interoperability. -- Bob Silverman "You can lead a horse's ass to knowledge, but you can't make him think" Sent via Deja.com http://www.deja.com/ Before you buy.
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Thu, 14 Oct 1999 19:48:47 +0100 From: "Brian Gladman" <gladman@seven77.demon.co.uk> Message-ID: <939926885.15815.0.nnrp-13.c2de6a96@news.demon.co.uk> References: <7u52ja$t8e$1@nnrp1.deja.com> Newsgroups: sci.crypt Lines: 39 Bob Silverman <bobs@rsa.com> wrote in message news:7u52ja$t8e$1@nnrp1.deja.com... > In article <939900926.22743.0.nnrp-12.c2de6a96@news.demon.co.uk>, > "Brian Gladman" <gladman@seven77.demon.co.uk> wrote: > > > > The arguments for multiple AES winners cannot be dismissed so easily. > > Yes it can. By one word. The word is: > > interoperability. But the domain of crytographic use includes systems for which interoperability is not a requirement. > By allowing multiple algorithms you are certain to guarantee that there > will be some users who can't talk to others. True, but also true if a single AES winner is chosen since we are not to my knowledge insisting that everyone uses it. > There > > are at least three reasons for wanting more than one winner: (1) to > provide > > a degree of choice in dedicated, closed applications, (2) to provide a > > degree of diversity in open applications > > Why does everyone use TCP/IP? Why do most internet security protocols provide for dynamic algorithm negotiation? > A Standard allows interoperability. where interoperability is needed. Brian Gladman
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: 15 Oct 1999 09:42:23 -0400 From: juola@mathcs.duq.edu (Patrick Juola) Message-ID: <7u7avv$d60$1@quine.mathcs.duq.edu> References: <3806845E.16D4C14F@aspi.net> <7u52ja$t8e$1@nnrp1.deja.com> Newsgroups: sci.crypt Lines: 35 In article <3806845E.16D4C14F@aspi.net>, Trevor Jackson, III <fullmoon@aspi.net> wrote: >Bob Silverman wrote: > >> In article <939900926.22743.0.nnrp-12.c2de6a96@news.demon.co.uk>, >> "Brian Gladman" <gladman@seven77.demon.co.uk> wrote: >> > >> > The arguments for multiple AES winners cannot be dismissed so easily. >> >> Yes it can. By one word. The word is: >> >> interoperability. >> >> By allowing multiple algorithms you are certain to guarantee that there >> will be some users who can't talk to others. > >No. This is an invalid conclusion. > >Any users desiring to communicate will be able to select a mechanism to do >so. Any analysis dismissing the active participation of the users in the >dynamic selection of their channel properties from amoug the telephone, fax, >and email is trivially flawed. Nonsense. The Three-Initial-Corp. decides to use XYZ encryption for all it's communication needs and invests several billion dollars in XYZ- compliant mailers, routers, telephones, and so forth. The Even-Larger- Five-Initial-Corp., independently, decides to invest in PQ encryption and spends similarly huge amounts on its scrambler phone. The individual participant/employees of the companies involved are probably not going to be able to "dynamically select" their encryption scheme; they will use what's on their desk. And what's going to happen when ELFIC buys TIC? -kitten
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Fri, 15 Oct 1999 13:41:02 -0700 From: "Roger Schlafly" <real@ieee.org> Message-ID: <7u83ep$1gep@enews3.newsguy.com> References: <380760A1.BB7D356F@aspi.net> <7u7h2m$dcs$1@quine.mathcs.duq.edu> Newsgroups: sci.crypt Lines: 11 Trevor Jackson, III <fullmoon@aspi.net> wrote in message news:380760A1.BB7D356F@aspi.net... > By this reasoning we should only use telephones and avoid fax and email channels? > After all it would reduce the tooling costs, right? When they put in fax and email standards, they didn't deliberately introduce incompatible formats for diversity purposes.
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: 15 Oct 1999 22:33:17 GMT From: djohn37050@aol.com (DJohn37050) Message-ID: <19991015183317.04628.00000020@ng-fq1.aol.com> References: <7u83ep$1gep@enews3.newsguy.com> Newsgroups: sci.crypt Lines: 11 Roger, In fact there are multiple fax transmission protocols, each vendor came up with one and then cross licensed with others. But at first each fax would only talk to another from the same vendor (for example). Fax machines now do a negotiation. And we all know about competing email formats, etc. Talk to the Irish about potato monoculture. That is why there are more Irish-decendents in USA than in Ireland. Dependence on one thing is fine, AS LONG AS IT WORKS. Don Johnson
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Fri, 15 Oct 1999 21:11:00 -0700 From: "Roger Schlafly" <real@ieee.org> Message-ID: <7u8tqq$21q0@enews3.newsguy.com> References: <19991015183317.04628.00000020@ng-fq1.aol.com> Newsgroups: sci.crypt Lines: 21 DJohn37050 <djohn37050@aol.com> wrote in message news:19991015183317.04628.00000020@ng-fq1.aol.com... > Roger, In fact there are multiple fax transmission protocols, each vendor came > up with one and then cross licensed with others. But at first each fax would > only talk to another from the same vendor (for example). Fax machines now do a > negotiation. Yes, there were multiple protocols until a standard was adopted. The standard sure didn't add protocols for the sake of diversity. > Talk to the Irish about potato monoculture. You've lost me here. Is there some Irish position on potato standardization that I should know about? <g>
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: 20 Oct 1999 08:32:54 -0400 From: juola@mathcs.duq.edu (Patrick Juola) Message-ID: <7ukcpm$nad$1@quine.mathcs.duq.edu> References: <FJv7r5.LD8@bath.ac.uk> <38127c13.21178922@news.visi.com> <19991015183317.04628.00000020@ng-fq1.aol.com> Newsgroups: sci.crypt Lines: 29 In article <FJv7r5.LD8@bath.ac.uk>, Tim Tyler <tt@cryogen.com> wrote: >Bruce Schneier <schneier@counterpane.com> wrote: >: On 15 Oct 1999 22:33:17 GMT, djohn37050@aol.com (DJohn37050) wrote: > >:>Talk to the Irish about potato monoculture. That is why there are more >:>Irish-decendents in USA than in Ireland. Dependence on one thing is fine, >:>AS LONG AS IT WORKS. > >: And security is one of the places where it works. Security is a >: chain, generally as secure as the weakest link. Diversity is fine in >: the potato crop, but a disaster in security. > >German WWII could be portrayed as the failure of a monoculture in >cryptography (though there was more than one "crop"). > >Diversity *can* be a disaster in security - if the same message winds up >being encoded using different crypto-systems, with different strengths. Interesting that you should write these two paragraphs in tandem with each other.... One of the major methods the British used to crack the (difficult) German cyphers was by using or even creating known-plaintext in other cyphers. For example, sowing mines in a particular area so that a warning would have to be sent both to the submarines and the surface ships. Why are we sure that the same trick wouldn't work for multiple AES winners? -kitten
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Wed, 20 Oct 1999 17:58:29 GMT From: Tim Tyler <tt@cryogen.com> Message-ID: <FJwxxH.I9H@bath.ac.uk> References: <7ukcpm$nad$1@quine.mathcs.duq.edu> Newsgroups: sci.crypt Lines: 38 Patrick Juola <juola@mathcs.duq.edu> wrote: : In article <FJv7r5.LD8@bath.ac.uk>, Tim Tyler <tt@cryogen.com> wrote: :>Bruce Schneier <schneier@counterpane.com> wrote: :>: On 15 Oct 1999 22:33:17 GMT, djohn37050@aol.com (DJohn37050) wrote: [cypher monoculture] :>: And security is one of the places where it works. Security is a :>: chain, generally as secure as the weakest link. Diversity is fine in :>: the potato crop, but a disaster in security. [snip "German WWII could be portrayed as the failure of a monoculture"] :>Diversity *can* be a disaster in security - if the same message winds up :>being encoded using different crypto-systems, with different strengths. : Interesting that you should write these two paragraphs in tandem with : each other.... One of the major methods the British used to crack : the (difficult) German cyphers was by using or even creating : known-plaintext in other cyphers. Yes - I an aware of the history. : Why are we sure that the same trick wouldn't work for multiple AES : winners? I'm not advocating using multiple cyphers at the same time. I was talking about changing cyphers at regular intervals, and the need for reprogrammable cyphermachines. *Even* when changing cyphers there's increased risk of plaintext attack. However *NOT* changing cyphers at all is probably an even worse strategy. -- __________ |im |yler The Mandala Centre http://www.mandala.co.uk/ tt@cryogen.com Love is grand; divorce, forty grand.
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Tue, 19 Oct 1999 00:09:29 +0200 From: Mok-Kong Shen <mok-kong.shen@t-online.de> Message-ID: <380B9A99.3BA612BB@t-online.de> References: <38117b17.20927257@news.visi.com> <3806845E.16D4C14F@aspi.net> <7u52ja$t8e$1@nnrp1.deja.com> Newsgroups: sci.crypt Lines: 18 Bruce Schneier wrote: > > This is a great theory. When is it going to happen in the U.S. > cellphone industry. Phone interoperability is actually something > important, not like security; I can't buy a phone that allows me to > dynamically select among different digital standards, and none of the > serious vendors are moving in this direction. > > The theory may be a Good Thing (tm), but it often doesn't work in > practice. It nonetheless shows that one can manage to live with some non-interoperability. I indicated elsewhere that there are a number of programming language standards, resulting in some (apparently yet tolerable) non-interoperability. M. K. Shen
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Thu, 14 Oct 1999 21:50:49 +0100 From: "Brian Gladman" <gladman@seven77.demon.co.uk> Message-ID: <939934178.27828.0.nnrp-11.c2de6a96@news.demon.co.uk> References: <7u54g2$1huj@enews3.newsguy.com> <939900926.22743.0.nnrp-12.c2de6a96@news.demon.co.uk> Newsgroups: sci.crypt Lines: 63 Roger Schlafly <real@ieee.org> wrote in message news:7u54g2$1huj@enews3.newsguy.com... > Brian Gladman <gladman@seven77.demon.co.uk> wrote in message > news:939900926.22743.0.nnrp-12.c2de6a96@news.demon.co.uk... > > The arguments for multiple AES winners cannot be dismissed so easily. > There > > are at least three reasons for wanting more than one winner: (1) to > provide > > a degree of choice in dedicated, closed applications, (2) to provide a > > degree of diversity in open applications (a well established practice), > and > > (3) to meet requirements that benefit from the sequential application of > > different encryption algortithms (again an established practice). > > You are just saying that one algorithm won't be good enough for > some reason. But what is the reason? Why is diversity/choice > good? Because we simply don't have a way of knowing what will happen in future. You may believe that the open cryptographic community can be certain that a particular algorithm does not have as yet undetected weaknesses but I am not convinced of this. I hence do not want to be forced by lack of diversity in the market to put all my eggs in one basket. Its a good security principle to have (a) defence in breadth, (b) defence in depth, and (c) a fall back plan for when things go wrong. Algorithm diversity is about (c) and to some extent (b). I also think its wrong to assume that the diversity of algorithms in existing applications is there in the absense of any market demand for it. > There is diversity in practice because there is disagreement > about what is best. If it turns out that the five finalists are all > more or less equally good, then there may never be a consensus > about what to use unless someone like NIST declares one to > be the standard. Nearly all practical standards offer a host of options so it is quite wrong to suggest that we cannot meet most interoperability needs while also meeting the need for controlled algorithm diversity - I can list a large number of internet protocol standards, all of which are designed to accommodate algorithm diversity. So its quite wrong to suggest that we cannot meet most interoperability needs without imposing an 'algorithmic monoculture' on the whole of the world. A lot of people like standards. Those who > don't can do whatever they want anyway. That's dangerously close to saying I don't care a stuff about your needs as long as mine are met. If you really hold this view there's not much point in continuing this debate. I, too, like standards and I have worked pretty hard to help ensure that the AES standard will succeed. But whether or not we have a standard is quite different from deciding whether or not the standard should support requirements for controlled algorithm diversity. Brian Gladman
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Thu, 14 Oct 1999 22:40:53 -0700 From: "Roger Schlafly" <real@ieee.org> Message-ID: <7u6emi$gfv@enews3.newsguy.com> References: <939934178.27828.0.nnrp-11.c2de6a96@news.demon.co.uk> Newsgroups: sci.crypt Lines: 52 Brian Gladman <gladman@seven77.demon.co.uk> wrote in message news:939934178.27828.0.nnrp-11.c2de6a96@news.demon.co.uk... > Because we simply don't have a way of knowing what will happen in future. > You may believe that the open cryptographic community can be certain that a > particular algorithm does not have as yet undetected weaknesses but I am not > convinced of this. I hence do not want to be forced by lack of diversity in > the market to put all my eggs in one basket. Its a good security principle > to have (a) defence in breadth, (b) defence in depth, and (c) a fall back > plan for when things go wrong. Algorithm diversity is about (c) and to > some extent (b). I think what you are really arguing for is cipher complexity. There is a school of thought that says complexity in a cipher is a good thing. If a complex cipher is built from many components, then it is more secure because it is less susceptible to the failure of one component. Or so the theory goes. But if so, that is just an argument that the AES winner should be a complex cipher. (Some of the candidates are more complex than others.) > Nearly all practical standards offer a host of options so it is quite wrong > to suggest that we cannot meet most interoperability needs while also > meeting the need for controlled algorithm diversity - I can list a large > number of internet protocol standards, all of which are designed to > accommodate algorithm diversity. The AES candidates all offer a choice of keys -- those are your options. Can you name any internet protocol standards which designed in algorithm diversity just because of a theory that such diversity is a good thing? Usually the diversity is for interoperability with existing system. The AES diversity you are proposing is contrary to interoperability interests. > > A lot of people like standards. Those who > > don't can do whatever they want anyway. > > That's dangerously close to saying I don't care a stuff about your needs as > long as mine are met. If you really hold this view there's not much point > in continuing this debate. I think a single AES standard can meet your needs. I just don't think you need algorithm diversity.
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Fri, 15 Oct 1999 10:22:50 +0100 From: "Brian Gladman" <gladman@seven77.demon.co.uk> Message-ID: <939980369.732.0.nnrp-14.c2de6a96@news.demon.co.uk> References: <7u6emi$gfv@enews3.newsguy.com> Newsgroups: sci.crypt Lines: 110 Roger Schlafly <real@ieee.org> wrote in message news:7u6emi$gfv@enews3.newsguy.com... > Brian Gladman <gladman@seven77.demon.co.uk> wrote in message > news:939934178.27828.0.nnrp-11.c2de6a96@news.demon.co.uk... > > Because we simply don't have a way of knowing what will happen in future. > > You may believe that the open cryptographic community can be certain that > a > > particular algorithm does not have as yet undetected weaknesses but I am > not > > convinced of this. I hence do not want to be forced by lack of diversity > in > > the market to put all my eggs in one basket. Its a good security > principle > > to have (a) defence in breadth, (b) defence in depth, and (c) a fall back > > plan for when things go wrong. Algorithm diversity is about (c) and to > > some extent (b). > > I think what you are really arguing for is cipher complexity. There is > a school of thought that says complexity in a cipher is a good thing. > If a complex cipher is built from many components, then it is more > secure because it is less susceptible to the failure of one component. > Or so the theory goes. But if so, that is just an argument that the > AES winner should be a complex cipher. (Some of the candidates > are more complex than others.) > > > Nearly all practical standards offer a host of options so it is quite > wrong > > to suggest that we cannot meet most interoperability needs while also > > meeting the need for controlled algorithm diversity - I can list a large > > number of internet protocol standards, all of which are designed to > > accommodate algorithm diversity. > > The AES candidates all offer a choice of keys -- those are your > options. > > Can you name any internet protocol standards which designed in > algorithm diversity just because of a theory that such diversity is > a good thing? Usually the diversity is for interoperability with > existing system. The AES diversity you are proposing is contrary > to interoperability interests. PGP (and hence OpenPGP) implements diversity but was never designed to interoperate with other applications or systems. Many internet protocols are 'closed' in design terms - that is they don't interoperate with other protocols - and this means that their design does not need to offer a choice of algorithms but they very often do. There are many reasons for this, one being to give users a choice. Moreover PGP has achieved a high level of global interoperability without adopting a single algorithm. Hence the idea that extensive interoperabilty requires a single algorithm standard is not only wrong but demonstrably so. > > > A lot of people like standards. Those who > > > don't can do whatever they want anyway. > > > > That's dangerously close to saying I don't care a stuff about your needs > as > > long as mine are met. If you really hold this view there's not much point > > in continuing this debate. > > I think a single AES standard can meet your needs. I just don't think > you need algorithm diversity. As I have already said, I see three needs where we can gain benefits from algorithm diversity but for the sake of this debate let me concentrate on just one of them. I have to meet some requirements that involve protection for 50+ years and I want to provide a degree of protection against the possibility that any single algorithm will be found later to have a serious flaw. I intend to do this by applying two (or more) different encryption algorithms in sequence - an established practice in such situations and one that most information security professionals will accept as valid. In order to meet this need I would like to use the best internationally agreed, open standard algorithms that are available and I see the AES process as a good basis for making my selection. While I could use any of the five finalists in combination (assuming that potential IPR problems with two of them in this situation are removed), I would like to reduce the diversity of choice from, say, five to three because five is more than I need and the widespread use of all five finalists will create greater interoperability problems than are necessary to meet my diversity needs. My aim here is to balance two conflicting AES requirements - on the one hand interoperability requires that we reduce algortihm choice as far as is possible but on the other hand the need for resiliance requires that we increase the number of algorithms. We can clearly choose a single AES winner and meet the diversity requirement external to the AES process in an uncontrolled way or we can control the diversity by doing this within the AES process by selecting more than one winner (I would select two or three but not more). I am simply arguing that we achieve a better balance between interoperability and diversity needs by doing this in a controlled rather than an uncontrolled way. I respect your right to believe that my diversity needs are no more than a figment of my imagination but I assure you that they are based of nearly 40 years of real experience in a world where information security failures cost lives. Brian Gladman
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Fri, 15 Oct 1999 18:44:04 +0100 From: "Brian Gladman" <gladman@seven77.demon.co.uk> Message-ID: <940009374.23904.0.nnrp-11.c2de6a96@news.demon.co.uk> References: <7u7anu$11o3@enews3.newsguy.com> <939980369.732.0.nnrp-14.c2de6a96@news.demon.co.uk> Newsgroups: sci.crypt Lines: 102 Roger Schlafly <real@ieee.org> wrote in message news:7u7anu$11o3@enews3.newsguy.com... > Brian Gladman <gladman@seven77.demon.co.uk> wrote in message > news:939980369.732.0.nnrp-14.c2de6a96@news.demon.co.uk... > > PGP (and hence OpenPGP) implements diversity but was never designed to > > interoperate with other applications or systems. Many internet protocols > > are 'closed' in design terms - that is they don't interoperate with other > > protocols - and this means that their design does not need to offer a > choice > > of algorithms but they very often do. There are many reasons for this, > one > > being to give users a choice. > > The primary reason for the algorithm choice is for PGP to migrate away > from some algorithims that have some undesirable properties (such as > patents). As I said, there are many reasons, one being to offer users a choice. > > Moreover PGP has achieved a high level of global interoperability without > > adopting a single algorithm. Hence the idea that extensive > interoperabilty > > requires a single algorithm standard is not only wrong but demonstrably > so. > > Its interoperability is in spite of algorithm choice. There are lots of PGP > users who have RSA-only versions who cannot handle DH keys. This is the real world where a balance has to be struck between conflictng needs with the result that none can be met perfectly. Interoperability is important in many systems but this does not mean that it always dominates other needs. > When there is diversity in the marketplace, I can see where PGP would > want to address that. It might simply want to satisfy differing perceptions > of users. What I don't understand is why NIST would want to deliberately > inject diveristy into the market. > > > I have to meet some requirements that involve protection for 50+ years and > I > > want to provide a degree of protection against the possibility that any > > single algorithm will be found later to have a serious flaw. I intend to > do > > this by applying two (or more) different encryption algorithms in > sequence - > > an established practice in such situations and one that most information > > security professionals will accept as valid. > > There are probably also people who will not trust AES as is, and use > triple-AES. If NIST sanctioned triple-AES, they'd use triple-triple-AES. > That's fine, but it is pretty useless for NIST to try to accommodate them No-one is asking for this AFAIK. I have a high level of trust in the AES process but since I have a lot at stake I want a fall back position in case things go wrong. You are prepared to take the risk and that's fine but I am not and there are many like me. And its perfectly reasonable to seek an AES result that will allow for such needs. > > In order to meet this need I would like to use the best internationally > > agreed, open standard algorithms that are available and I see the AES > > process as a good basis for making my selection. While I could use any of > > the five finalists in combination (assuming that potential IPR problems > with > > two of them in this situation are removed), I would like to reduce the > > diversity of choice from, say, five to three because five is more than I > > need and the widespread use of all five finalists will create greater > > interoperability problems than are necessary to meet my diversity needs. > > You don't really want to use AES, you just want to use NIST AES > submissions as input to your own homebrew cipher. That's fine -- you > may get your 50+ year security. But you are doing something > nonstandard. Wrong, I want to use AES and I therefore want to ensure that the output of the AES process can fully meet my needs. If that were not true we would not be having this debate. No, I'm not inventing a new cipher, I am using ciphers which have been designed by some of the world best cryptographers in a way that protects myself to a degree against the possibility that one of them may contain an as yet unknown flaw. You may not understand or appreciate this need but that does not mean that it does not exist. Those who advocate the protection of a large proportion of the world's secure data with a single algorithm in pursuit of interoperability may be content to bear the risk if the chosen cipher fails but I prefer to have a contingency plan to cover this possibility. I guess it depends on whether or not we are gambers but I must admit that I have never been that keen on gambling. Especially when the stakes are so high. Brian Gladman
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Fri, 15 Oct 1999 12:38:13 -0700 From: "Roger Schlafly" <real@ieee.org> Message-ID: <7u7vp0$1ed1@enews3.newsguy.com> References: <940009374.23904.0.nnrp-11.c2de6a96@news.demon.co.uk> Newsgroups: sci.crypt Lines: 19 Brian Gladman <gladman@seven77.demon.co.uk> wrote in message news:940009374.23904.0.nnrp-11.c2de6a96@news.demon.co.uk... > > There are probably also people who will not trust AES as is, and use > > triple-AES. If NIST sanctioned triple-AES, they'd use triple-triple-AES. > > That's fine, but it is pretty useless for NIST to try to accommodate them > > No-one is asking for this AFAIK. I have a high level of trust in the AES > process but since I have a lot at stake I want a fall back position in case > things go wrong. No, you are asking for a triple-AES solution because you don't trust AES. Perhaps your special needs justify it. That's fine, but I don't know why you'd want to burden everyone else with an overly complex AES when you are not going to trust it anyway.
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Fri, 15 Oct 1999 23:29:56 +0200 From: Mok-Kong Shen <mok-kong.shen@t-online.de> Message-ID: <38079CD4.67ADE027@t-online.de> References: <7u7vp0$1ed1@enews3.newsguy.com> Newsgroups: sci.crypt Lines: 12 Roger Schlafly wrote: > > No, you are asking for a triple-AES solution because you don't > trust AES. Perhaps your special needs justify it. That's fine, but > I don't know why you'd want to burden everyone else with an > overly complex AES when you are not going to trust it anyway. Triple DES standard doesn't burden those that use single DES, as far as I am aware. M. K. Shen
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Sat, 16 Oct 1999 09:07:02 -0700 From: "Roger Schlafly" <real@ieee.org> Message-ID: <7ua7pn$2q5s@enews3.newsguy.com> References: <38079CD4.67ADE027@t-online.de> Newsgroups: sci.crypt Lines: 9 Mok-Kong Shen <mok-kong.shen@t-online.de> wrote in message news:38079CD4.67ADE027@t-online.de... > Triple DES standard doesn't burden those that use single DES, > as far as I am aware. Sure it does -- they don't interoperate.
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Sat, 16 Oct 1999 19:35:43 +0200 From: Mok-Kong Shen <mok-kong.shen@t-online.de> Message-ID: <3808B76F.50B7D6D0@t-online.de> References: <7ua7pn$2q5s@enews3.newsguy.com> Newsgroups: sci.crypt Lines: 33 Roger Schlafly wrote: > > Mok-Kong Shen <mok-kong.shen@t-online.de> wrote > > Triple DES standard doesn't burden those that use single DES, > > as far as I am aware. > > Sure it does -- they don't interoperate. People that use triple DES don't use single DES and vice versa. So there is no need of inperoperability. I was answering your point (if I understood correctly) that having an additional standard like triple DES leads to disadvantages of those who use DES. There aren't any such arising from the mere fact that a separate standard exists. (In other follow-ups I employed the analogy in the field of programming languages.) I like to take this opportunity also to repeat (wrpt what is discussed elsewhere in this thread) that on the day when AES is finalized all top candidates are likely to have received the same degree/amount of scrutiny by the best of professionals. So the chance of using multiple encryption of these leading to weakness (relative to single encryption with the winner of AES) is negligibly small or practically zero. The single disadvantage may be in performance, which could be tolerated in at least a part of the practical applications. I personally consider it to be a naive idea to consider one single cipher (one that doesn't yet have gone through the test of time as DES has done) to be so extremely good that one never needs to bother about its possible vulnerability. To those who are SO SURE about modern (super) high technology being able to absulutely guarantee all their needs (whether crypto or not) I like to recall one single name: Titanic. M. K. Shen
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Sat, 16 Oct 1999 11:08:08 -0700 From: "Roger Schlafly" <real@ieee.org> Message-ID: <7uaest$2u47@enews3.newsguy.com> References: <3808B76F.50B7D6D0@t-online.de> Newsgroups: sci.crypt Lines: 25 Mok-Kong Shen <mok-kong.shen@t-online.de> wrote in message news:3808B76F.50B7D6D0@t-online.de... > Roger Schlafly wrote: > > > > Mok-Kong Shen <mok-kong.shen@t-online.de> wrote > > > Triple DES standard doesn't burden those that use single DES, > > > as far as I am aware. > > > > Sure it does -- they don't interoperate. > > People that use triple DES don't use single DES and vice versa. Exactly. No interoperability. > To those who > are SO SURE about modern (super) high technology being able to > absulutely guarantee all their needs (whether crypto or not) I like > to recall one single name: Titanic. Yes, that's what iterated ciphers are. Big, slow, clumsy, and misplaced confidence in something just because it is big, slow, and clumsy.
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Sat, 16 Oct 1999 14:15:25 -0600 From: jcoffin@taeus.com (Jerry Coffin) Message-ID: <MPG.12728a683b4683939896ff@news.mindspring.com> References: <7uaest$2u47@enews3.newsguy.com> Newsgroups: sci.crypt Lines: 30 In article <7uaest$2u47@enews3.newsguy.com>, real@ieee.org says... [ ... ] > > People that use triple DES don't use single DES and vice versa. > > Exactly. No interoperability. I would keep in mind, however, that using the same algorithm doesn't guarantee interoperability, and having two (or more) algorithms available doesn't prevent it. If two programs are going to interoperate, they obviously need at least one common algorithm, and some way of agreeing upon the algorithm they'll use when they're interoperating. I doubt it takes more than 100 lines of code on average to implement the AES finalist algorithms. That means a product that included ALL of them would still only be devoting around 500 lines of code to implementing the algorithms themselves. Obviously the amount of space devoted can (and typically will) depend on how heavily the code's been optimized, but ultimately the fact remains: implementing all of them (especially since code samples of all are available already) isn't likely to be a particularly large part of a implementing a complete encryption product. -- Later, Jerry. The universe is a figment of its own imagination.
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: 16 Oct 1999 16:11:57 -0700 From: daw@blowfish.isaac.cs.berkeley.edu (David Wagner) Message-ID: <7ub0nt$9ep$1@blowfish.isaac.cs.berkeley.edu> References: <MPG.12728a683b4683939896ff@news.mindspring.com> Newsgroups: sci.crypt Lines: 6 In article <MPG.12728a683b4683939896ff@news.mindspring.com>, Jerry Coffin <jcoffin@taeus.com> wrote: > I doubt it takes more than 100 lines of code on average to implement > the AES finalist algorithms. In software, it's easy; in hardware, it's a huge added cost.
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Sat, 16 Oct 1999 23:21:25 -0400 From: "Trevor Jackson, III" <fullmoon@aspi.net> Message-ID: <380940B5.FD686CC9@aspi.net> References: <7ub0nt$9ep$1@blowfish.isaac.cs.berkeley.edu> Newsgroups: sci.crypt Lines: 13 David Wagner wrote: > In article <MPG.12728a683b4683939896ff@news.mindspring.com>, > Jerry Coffin <jcoffin@taeus.com> wrote: > > I doubt it takes more than 100 lines of code on average to implement > > the AES finalist algorithms. > > In software, it's easy; in hardware, it's a huge added cost. Huge compared to what? A single-chip implementation of just the cipher might sustain a 100% or so increase in cost. But an appliance will see only a few percent increase in cost.
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Sun, 17 Oct 1999 10:19:20 -0600 From: jcoffin@taeus.com (Jerry Coffin) Message-ID: <MPG.1273a370da6f75de989701@news.mindspring.com> References: <7ub0nt$9ep$1@blowfish.isaac.cs.berkeley.edu> Newsgroups: sci.crypt Lines: 62 In article <7ub0nt$9ep$1@blowfish.isaac.cs.berkeley.edu>, daw@blowfish.isaac.cs.berkeley.edu says... > In article <MPG.12728a683b4683939896ff@news.mindspring.com>, > Jerry Coffin <jcoffin@taeus.com> wrote: > > I doubt it takes more than 100 lines of code on average to implement > > the AES finalist algorithms. > > In software, it's easy; in hardware, it's a huge added cost. The TwoFish FPGA implementation uses an equivalent of roughly 28,000 gates. If we assume that's about average for the five finalists (RC-6 could probably be smaller, Serpent likely larger, ...) and that we can't share any noticeable amount of logic between implementations, that means implementing all five should take around 150,000 gates (rounding up). Adding in even some fairly complex logic to handle selecting between them, possibly a bit of caching, etc., we should be able to fit all five into, say, 200,000 gates. In a modern .18 micron fabrication, 200,000 gates should fit in less than 4.5 square millimeters, which can be fabricated in reasonable quantities at a cost of approximately one dollar per chip. That ignores things like packaging costs and such, but these should be _close_ to constant -- we'd only need a few extra pins to deal with selecting the algorithm(s) to use. Of course, in a real chip, you'd probably want to build in something like a PCI interface, so the chip would be easy to hook up to existing peripherals. That'll add on around 4 to 5 square millimeters or so by itself -- I.e. close to the area needed to implement the encryption algorithms. This would increase the cost to around two dollars per chip. Unless the product involved was being built in relatively limited quantities, the cost of including all five algorithms would NOT be terribly high. When dealing with limited quantities, unles extremely high performance was needed, it would probably be easier to simply embed a processor core and put the algorithms in ROM. Just for example, the MicroSPARC IIep is available under Sun's Community Source License, making it easy for even a very poorly financed startup company (e.g. a college kid in his dorm room) to download and start a design. It uses around 208,000 gates for the core and licenses for 3% of the selling price of the chip into which it's embedded IIRC. You could probably even reduce their estimated gate count somewhat, because in this situation you probably wouldn't need some things they normally include such as PCI and S-bus. In the end, I just don't buy the idea that the cost of including all five in a hardware design would be prohibitive unless the quantity being produced was _extremely_ limited so the initial design cost predominated overall costs. In this case, I think a design based on an embedded microprocessor core would eliminate the problems, though of course at some cost in licensing the core. Given that products produced in such limited quantities are generally quite expensive anyway, I doubt the incremental cost of including more algorithms would be particularly noticeable. -- Later, Jerry. The universe is a figment of its own imagination.
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: 18 Oct 1999 12:47:36 -0700 From: daw@blowfish.isaac.cs.berkeley.edu (David Wagner) Message-ID: <7uftgo$a56$1@blowfish.isaac.cs.berkeley.edu> References: <MPG.1273a370da6f75de989701@news.mindspring.com> Newsgroups: sci.crypt Lines: 11 In article <MPG.1273a370da6f75de989701@news.mindspring.com>, Jerry Coffin <jcoffin@taeus.com> wrote: > In the end, I just don't buy the idea that the cost of including all > five in a hardware design would be prohibitive [...] And yet, the hardware folks seem to disagree strongly. Personally, I'm more inclined to believe people with experience building hardware than to believe my own theories of how the world ought to work. Maybe we ought to hear from some of the hardware vendors on this topic?
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: 19 Oct 1999 01:07:11 -0700 From: daw@blowfish.isaac.cs.berkeley.edu (David Wagner) Message-ID: <7uh8rf$at1$1@blowfish.isaac.cs.berkeley.edu> References: <MPG.1275b95159ce0eee989711@news.mindspring.com> <7uftgo$a56$1@blowfish.isaac.cs.berkeley.edu> Newsgroups: sci.crypt Lines: 29 In article <MPG.1275b95159ce0eee989711@news.mindspring.com>, Jerry Coffin <jcoffin@taeus.com> wrote: > In article <7uftgo$a56$1@blowfish.isaac.cs.berkeley.edu>, > daw@blowfish.isaac.cs.berkeley.edu says... > > In article <MPG.1273a370da6f75de989701@news.mindspring.com>, > > Jerry Coffin <jcoffin@taeus.com> wrote: > > > In the end, I just don't buy the idea that the cost of including all > > > five in a hardware design would be prohibitive [...] > > > > And yet, the hardware folks seem to disagree strongly. > > _What_ hardware folks? I'm basically quoting directly from the > hardware designers I know -- and for years now, I've been basically > the lone software guy in a company devoted primarily to hardware > design. If that's true, then I'd be persuaded, although it _is_ different from what I've heard. This seems important enough that we ought to have some hardware folks lend their experience here; any chance in getting one of them (or you) to write a brief letter to NIST explaining their preference and the criteria they used to reach it? (I assume it's unlikely they'll post to sci.crypt.) P.S. Do your comments apply to small resource-starved devices, such as cellphones? I got the impression that CPU-makers have more transistors than they know what to do with, but that makers of hardware for resource-limited devices such as cellphones were much more reticent to waste even a few hundred gates unnecessarily. In fact, I thought this was one of the key design criterion for A5 (the GSM cipher).
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Tue, 19 Oct 1999 12:51:25 -0600 From: jcoffin@taeus.com (Jerry Coffin) Message-ID: <MPG.12766b53e5e6087a989716@news.mindspring.com> References: <7uh8rf$at1$1@blowfish.isaac.cs.berkeley.edu> Newsgroups: sci.crypt Lines: 51 In article <7uh8rf$at1$1@blowfish.isaac.cs.berkeley.edu>, daw@blowfish.isaac.cs.berkeley.edu says... [ ... ] > P.S. Do your comments apply to small resource-starved devices, > such as cellphones? I got the impression that CPU-makers have more > transistors than they know what to do with, but that makers of hardware > for resource-limited devices such as cellphones were much more reticent > to waste even a few hundred gates unnecessarily. In fact, I thought > this was one of the key design criterion for A5 (the GSM cipher). A cell phone would generally be an _ideal_ candidate for a software implementation. A typical cell phone already includes at least one processor (and often a couple of them). For example, Motorola cell phones use Motorola DSPs, Qualcomm chip-sets incorporate an ARM processor core, and so on. In addition, cell phones use vocoders that compress the speech _very_ heavily before transmission -- the data rate involved is normally on the order of 8-14 K/sec., so encryption would add _very_ little to the CPU load, and the performance of a dedicated hardware implementation would be completely unnecessary. We're talking (at most) about using a slightly larger ROM or Flash chip to hold the code. Even that is unlikely though: it's fairly rare that the ROM or Flash chip in a cell phone is really full to start with, and it would be unusual that adding a couple of encryption algorithms would be enough to push the requirement to the next larger size of memory chip (unless some of the AES candidates use more code than I realize). Offhand, I suspect RAM needed to implement S-boxes and such would be a bigger problem, but unless there was an idea of applying the algorithms serially instead of merely allowing a choice between algorithms, you'd only have to include enough RAM for the single heaviest user, not enough for all of them to operate at the same time. OTOH, to say much about suitability of AES to cell phones, I'd have to re-check the packet sizes in which cell phones normally transmit data. If the packet size isn't (at least close to) as large as a cipher block, this would cause a problem. Obviously if you incorporated AES, you'd be designing a new standard, so increasing the block size a little wouldn't necessarily be a major problem. OTOH, if we were looking at increasing the packet size a lot, it could cause a problem, especially if you were using TDMA instead of CDMA. -- Later, Jerry. The universe is a figment of its own imagination.
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: 19 Oct 1999 13:19:26 -0700 From: daw@blowfish.isaac.cs.berkeley.edu (David Wagner) Message-ID: <7uijoe$bca$1@blowfish.isaac.cs.berkeley.edu> References: <MPG.12766b53e5e6087a989716@news.mindspring.com> Newsgroups: sci.crypt Lines: 19 In article <MPG.12766b53e5e6087a989716@news.mindspring.com>, Jerry Coffin <jcoffin@taeus.com> wrote: > A cell phone would generally be an _ideal_ candidate for a software > implementation. I've heard some complaints that, at least for some of the AES finalists, software just won't offer good enough performance. The CPU is already at near-full utilization in some of these suckers, I'm told, and sometimes you only get a 8-bit or 16-bit processor as well (which some AES finalists aren't optimized for). I don't understand cellphones very well, so I can't speak authoritatively on them, but I don't see any reason to focus exclusively on them, either; I mentioned them only as an example of a resource-starved device. More generally, we can consider any low-end device that wants to implement crypto in hardware. I don't see any reason to believe that the low end will go away anytime soon. Am I confused? Anyway, what do we do about the low end where space/power/etc. is tight?
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: 20 Oct 1999 16:25:50 GMT From: aph@cygnus.remove.co.uk (Andrew Haley) Message-ID: <7ukqee$g66$3@korai.cygnus.co.uk> References: <MPG.1273a370da6f75de989701@news.mindspring.com> Newsgroups: sci.crypt Lines: 11 Jerry Coffin (jcoffin@taeus.com) wrote: : The TwoFish FPGA implementation uses an equivalent of roughly 28,000 : gates. Hmmm, that's interesting. I imagine that a FPGA implementation of the Shrinking Generator with reasonable register lengths could be done with hundreds of gates, and almost certainly less than 1000. Okay, that's a stream cipher rather than a block cipher, but it might be all that's needed. Andrew.
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Sun, 17 Oct 1999 17:05:02 GMT From: ritter@io.com (Terry Ritter) Message-ID: <380a019f.9607208@news.io.com> References: <7ub0nt$9ep$1@blowfish.isaac.cs.berkeley.edu> Newsgroups: sci.crypt Lines: 29 On 16 Oct 1999 16:11:57 -0700, in <7ub0nt$9ep$1@blowfish.isaac.cs.berkeley.edu>, in sci.crypt daw@blowfish.isaac.cs.berkeley.edu (David Wagner) wrote: >In article <MPG.12728a683b4683939896ff@news.mindspring.com>, >Jerry Coffin <jcoffin@taeus.com> wrote: >> I doubt it takes more than 100 lines of code on average to implement >> the AES finalist algorithms. > >In software, it's easy; in hardware, it's a huge added cost. There is "hardware," and then there is hardware: Many "hardware" systems now use embedded processors to perform the "hardware" task, and there may be multiple such processors. Typically such systems load from flash and save state in flash; there is no floppy or hard drive or file system, but in a real sense, everything is software inside. In engineering design we are even seeing very complex single-chip systems which take initialization from flash and save state in flash. It is not much of a leap to talk about a stand-alone ciphering chip which takes as its state a flash of various ciphers which it can then execute. --- Terry Ritter ritter@io.com http://www.io.com/~ritter/ Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Mon, 18 Oct 1999 20:05:13 GMT From: schneier@counterpane.com (Bruce Schneier) Message-ID: <38167d2c.21460142@news.visi.com> References: <MPG.12728a683b4683939896ff@news.mindspring.com> Newsgroups: sci.crypt Lines: 23 On Sat, 16 Oct 1999 14:15:25 -0600, jcoffin@taeus.com (Jerry Coffin) wrote: >I doubt it takes more than 100 lines of code on average to implement >the AES finalist algorithms. That means a product that included ALL >of them would still only be devoting around 500 lines of code to >implementing the algorithms themselves. Obviously the amount of space >devoted can (and typically will) depend on how heavily the code's been >optimized, but ultimately the fact remains: implementing all of them >(especially since code samples of all are available already) isn't >likely to be a particularly large part of a implementing a complete >encryption product. Don't think software; it's easy in software. Think of the applications where crypto is going to be used by the masses: smart cards, routers, cellphones. These are hardware devices, and adding a second algorithm is a great burden. It means that there is going to be some trade-off between features. Bruce ********************************************************************** Bruce Schneier, President, Counterpane Systems Phone: 612-823-1098 101 E Minnehaha Parkway, Minneapolis, MN 55419 Fax: 612-823-1590 Free crypto newsletter. See: http://www.counterpane.com
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Mon, 18 Oct 1999 20:03:25 GMT From: schneier@counterpane.com (Bruce Schneier) Message-ID: <38157cdd.21380804@news.visi.com> References: <38079CD4.67ADE027@t-online.de> Newsgroups: sci.crypt Lines: 24 On Fri, 15 Oct 1999 23:29:56 +0200, Mok-Kong Shen <mok-kong.shen@t-online.de> wrote: >Roger Schlafly wrote: >> > >> No, you are asking for a triple-AES solution because you don't >> trust AES. Perhaps your special needs justify it. That's fine, but >> I don't know why you'd want to burden everyone else with an >> overly complex AES when you are not going to trust it anyway. > >Triple DES standard doesn't burden those that use single DES, >as far as I am aware. It depends what you mean by burden. If I developed a pay-TV application, for example, and use DES in all the transmitters and set-top boxes, switching to triple-DES is a very large burden. It's so large that I might not do it, even if DES is insecure. Bruce ********************************************************************** Bruce Schneier, President, Counterpane Systems Phone: 612-823-1098 101 E Minnehaha Parkway, Minneapolis, MN 55419 Fax: 612-823-1590 Free crypto newsletter. See: http://www.counterpane.com
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Tue, 19 Oct 1999 00:09:43 +0200 From: Mok-Kong Shen <mok-kong.shen@t-online.de> Message-ID: <380B9AA7.99C00E85@t-online.de> References: <38157cdd.21380804@news.visi.com> Newsgroups: sci.crypt Lines: 27 Bruce Schneier wrote: > > <mok-kong.shen@t-online.de> wrote: > > > >> No, you are asking for a triple-AES solution because you don't > >> trust AES. Perhaps your special needs justify it. That's fine, but > >> I don't know why you'd want to burden everyone else with an > >> overly complex AES when you are not going to trust it anyway. > > > >Triple DES standard doesn't burden those that use single DES, > >as far as I am aware. > > It depends what you mean by burden. If I developed a pay-TV > application, for example, and use DES in all the transmitters and > set-top boxes, switching to triple-DES is a very large burden. It's > so large that I might not do it, even if DES is insecure. But you nevertheless do at least have a chance of a choice, because of the fact that triple-DES exists. If this didn't exist, you would have no choice even if you badly desired to get away from insecurity. Anyway, there is no reason to say that the (parallel) existence of the triple-DES standard leads to disadvantages of those using single DES (those who don't want, don't need and don't care to use triple DES). M. K. Shen
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Sat, 16 Oct 1999 09:59:05 +0100 From: "Brian Gladman" <gladman@seven77.demon.co.uk> Message-ID: <940065003.1402.0.nnrp-14.c2de6a96@news.demon.co.uk> References: <7u7vp0$1ed1@enews3.newsguy.com> Newsgroups: sci.crypt Lines: 66 Roger Schlafly <real@ieee.org> wrote in message news:7u7vp0$1ed1@enews3.newsguy.com... > Brian Gladman <gladman@seven77.demon.co.uk> wrote in message > news:940009374.23904.0.nnrp-11.c2de6a96@news.demon.co.uk... > > > There are probably also people who will not trust AES as is, and use > > > triple-AES. If NIST sanctioned triple-AES, they'd use triple-triple-AES. > > > That's fine, but it is pretty useless for NIST to try to accommodate > them > > > > No-one is asking for this AFAIK. I have a high level of trust in the AES > > process but since I have a lot at stake I want a fall back position in > case > > things go wrong. > > No, you are asking for a triple-AES solution because you don't > trust AES. Perhaps your special needs justify it. That's fine, but > I don't know why you'd want to burden everyone else with an > overly complex AES when you are not going to trust it anyway. For you trust may be as simple as 'yes' or 'no' but for me its not, I trust things to varying degrees. I have a high degree of trust in my Bank in looking after my money but I don't trust them absolutely and I hence check what they do. For me trust is not a binary variable but a continuous one from, say, 0 (no trust) to 1 (absolute trust). I have a high level of trust in the AES process and I am very confident that the probability that a single winner will later be found to have a serious flaw is very, very small. But I don't have absolute trust in the winner because this probability cannot be shown to be zero. And the consequences are dire if the cipher does fail since a large proportion of the world's secure data may well end up being protected by it. In 'hand waving' terms we might loosely say that the risk we are taking is the product of 'a very small probability of failure' with 'a huge consequence if this failure occurs'. And the problem we face is that we simply don't have any idea whether the resulting product is so small that we can afford to ignore it or so large that we must do something about it. Optimists will hope it is small and carry the risk - in other words they are gambling. Pessimists will also hope it is small but they will assume it is not and will hence develop a contingency plan to cope if the worst happens. I don't object to you gambing provided it does not cause me harm but in AES we are gambling for the world as a whole and not just for ourselves. And that's why the debate is so important. And there is nothing necessarily burdensome about an AES process in which the result gives a formal status to more than one algorithm. For example, I have no objection to a 'multiple winners' result which indicates that where only a single algorithm is necessary it should be algorithm X. Nor have I ruled out other possibilities which allow most of the requirements of 'multiple winner' advocates to be met without major compromises on the part of those who want just one winner. And why do you consider that my need to have a contingency plan to guard against unlikely but possible future events is so special? Other contributions to the debate here show very clearly that I am not alone. Many disasters have been made much worse because people have failed to anticipate and plan for them. Brian Gladman
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: 16 Oct 1999 18:52:33 -0400 From: juola@mathcs.duq.edu (Patrick Juola) Message-ID: <7uavjh$fs8$1@quine.mathcs.duq.edu> References: <3808FDFD.9779F327@t-online.de> <939980369.732.0.nnrp-14.c2de6a96@news.demon.co.uk> Newsgroups: sci.crypt Lines: 62 In article <3808FDFD.9779F327@t-online.de>, Mok-Kong Shen <mok-kong.shen@t-online.de> wrote: >Roger Schlafly wrote: >> >> Exactly. No interoperability. > >Why do you care so much about interoperability? For a specific group >of communication partners to communicate securely, it suffices that >they argree on a specific software/hardware to use. Because the whole point of computer -- or more generally, communications -- networks is to permit communication between widely distant and possibly unfamilar parties. One of the nice things about the telephone is that someone can telephone me from almost anywhere in the world, irrespective of whether or not they've communicated with me before or whether or not I have the same sort of telephone that they do. I can pass out my phone and fax numbers on my business cards, confident that anyone can communicate with me -- or that they can tell other people how to communicate with on the basis only of that information. I can drive almost anywhere, secure in the knowledge that no matter where I go, I will find a gas station that interoperates with my car. I didn't have to put some sort of special doohickey in my engine to make sure that the gasoline I put in in Denver will run in the engine I bought in New York. Similarly, I can put my PGP key into a public location and anyone who wants it -- and has a copy of PGP -- can get my key and communicate with me "securely." However, how many people have PGP? And how many people have a different secure Email protocol that is incompatible with PGP? And how many people are not going to want to switch over? > If because of >lack of interoperability some three-lettered agencicies can't >intercept their messages, that's even better, isn't it? Well, gee. Let's assume that no one can communiate at all -- that means that no possible interception can occur. That would be best of all, wouldn't it? > If someone >participates in two groups with two different software/hardware, he >can acquire the necessary software/hardware, can't he? Not if it's expensive or ubiquitous. Do you have any idea how much it would cost to replace all of IBM's desk telephones? > If there is >sufficient market demand, manufacturers would provide facilities >for handling messages of both groups, much like my electric razor, >which works both in Europe and in US, where the voltages are different. >The language of my mother tongue needs an entirely different computer >input system than for English or the European languages. There isn't >any interoperability possible. Do you see the point? Yes. *IF* you have enough money to buy everything twice then you're "merely" inconvenienced. -kitten
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Sun, 17 Oct 1999 12:20:57 +0200 From: Mok-Kong Shen <mok-kong.shen@t-online.de> Message-ID: <3809A309.2BB799AA@t-online.de> References: <7uavjh$fs8$1@quine.mathcs.duq.edu> Newsgroups: sci.crypt Lines: 41 Patrick Juola wrote: > > Mok-Kong Shen <mok-kong.shen@t-online.de> wrote: > >Why do you care so much about interoperability? For a specific group > >of communication partners to communicate securely, it suffices that > >they argree on a specific software/hardware to use. > > Because the whole point of computer -- or more generally, communications -- > networks is to permit communication between widely distant and possibly > unfamilar parties. One of the nice things about the telephone is that > someone can telephone me from almost anywhere in the world, irrespective > of whether or not they've communicated with me before or whether or not You missed my point. Highly secure communication is different from public communication (e.g. a message through courier is different from an announcement in the newspaper). The communication partners in the first case know each other's identity and they agree on a certain secure means of communication before actually exchanging messages. If the security requirement is high engough, they can (normally) afford higher cost, lower throughput, more inconvenience, etc. etc. So there are different encryption algorithms suitable for different environments. Is triple DES interoperable with single DES? Why is triple DES currently in use at all?? The suggestion of Don Johnson to have super-AES doesn't exclude the use of AES and vice versa. Even if AES were provided as a standard to encrypt all people's e-mail on the internet, you are still free to employ additional encryption to your messages (unless some crypto law forbids that, because three-lettered agencies want to read everything). To repeat, you use multiple encryption WHEN (and only when) you need higher security. If multiple encryption with a number of top AES candidates is a standard, it doesn't mean that 'everywhere' there has to be facilities provided for that. (Personal analogy: I don't feel a need of fax, because the rate of incoming messages is very low. So I don't spend the money to buy a fax machine, while lots of my friends do. Later, when the situation changes, I might decide to have fax facility.) I suppose I have also answered the parts that I snipped. M. K. Shen
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: 17 Oct 1999 14:00:35 GMT From: djohn37050@aol.com (DJohn37050) Message-ID: <19991017100035.11703.00000284@ng-bk1.aol.com> References: <3809A309.2BB799AA@t-online.de> Newsgroups: sci.crypt Lines: 3 Just want to point out that the idea of multiple encryption using diff. algs (Super AES), etc. is fairly obvious. Don Johnson
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Sun, 17 Oct 1999 17:06:54 GMT From: ritter@io.com (Terry Ritter) Message-ID: <380a01c1.9641523@news.io.com> References: <7uavjh$fs8$1@quine.mathcs.duq.edu> Newsgroups: sci.crypt Lines: 45 On 16 Oct 1999 18:52:33 -0400, in <7uavjh$fs8$1@quine.mathcs.duq.edu>, in sci.crypt juola@mathcs.duq.edu (Patrick Juola) wrote: >In article <3808FDFD.9779F327@t-online.de>, >Mok-Kong Shen <mok-kong.shen@t-online.de> wrote: >>Roger Schlafly wrote: >>> >>> Exactly. No interoperability. >> >>Why do you care so much about interoperability? For a specific group >>of communication partners to communicate securely, it suffices that >>they argree on a specific software/hardware to use. > >Because the whole point of computer -- or more generally, communications -- >networks is to permit communication between widely distant and possibly >unfamilar parties. One of the nice things about the telephone is that >someone can telephone me from almost anywhere in the world, irrespective >of whether or not they've communicated with me before or whether or not >I have the same sort of telephone that they do. I can pass out my >phone and fax numbers on my business cards, confident that anyone >can communicate with me -- or that they can tell other people how to >communicate with on the basis only of that information. > >I can drive almost anywhere, secure in the knowledge that no matter >where I go, I will find a gas station that interoperates with my >car. I didn't have to put some sort of special doohickey in my >engine to make sure that the gasoline I put in in Denver will run >in the engine I bought in New York. And, if there were a standard cipher *interface*, anytime you needed to use a different cipher to "interoperate," you could just plug that cipher in. As to knowing which cipher to use, that information should come along with the key. If you do not have that cipher, you might negotiate a cipher you both have, or drop down to triple-AES or triple-DES (which you both will have), or get the cipher itself sent along with the key. --- Terry Ritter ritter@io.com http://www.io.com/~ritter/ Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Fri, 15 Oct 1999 09:59:44 GMT From: ritter@io.com (Terry Ritter) Message-ID: <3806fab2.1389948@news.io.com> References: <7u6emi$gfv@enews3.newsguy.com> Newsgroups: sci.crypt Lines: 66 On Thu, 14 Oct 1999 22:40:53 -0700, in <7u6emi$gfv@enews3.newsguy.com>, in sci.crypt "Roger Schlafly" <real@ieee.org> wrote: >Brian Gladman <gladman@seven77.demon.co.uk> wrote in message >news:939934178.27828.0.nnrp-11.c2de6a96@news.demon.co.uk... >> Because we simply don't have a way of knowing what will happen in future. >> You may believe that the open cryptographic community can be certain that >a >> particular algorithm does not have as yet undetected weaknesses but I am >not >> convinced of this. I hence do not want to be forced by lack of diversity >in >> the market to put all my eggs in one basket. Its a good security >principle >> to have (a) defence in breadth, (b) defence in depth, and (c) a fall back >> plan for when things go wrong. Algorithm diversity is about (c) and to >> some extent (b). > >I think what you are really arguing for is cipher complexity. There is >a school of thought that says complexity in a cipher is a good thing. >If a complex cipher is built from many components, then it is more >secure because it is less susceptible to the failure of one component. >Or so the theory goes. But if so, that is just an argument that the >AES winner should be a complex cipher. (Some of the candidates >are more complex than others.) > >> Nearly all practical standards offer a host of options so it is quite >wrong >> to suggest that we cannot meet most interoperability needs while also >> meeting the need for controlled algorithm diversity - I can list a large >> number of internet protocol standards, all of which are designed to >> accommodate algorithm diversity. > >The AES candidates all offer a choice of keys -- those are your >options. > >Can you name any internet protocol standards which designed in >algorithm diversity just because of a theory that such diversity is >a good thing? Usually the diversity is for interoperability with >existing system. The AES diversity you are proposing is contrary >to interoperability interests. The use of *keys* limits interoperability -- to those who have the right keys. We now do arrange to transfer keys as needed. We could arrange to transfer the name of the cipher to be used, or even the cipher itself. Thus, multiple ciphers would seem to have modest effects on interoperability, with the major advantage of allowing the entire net to change to a better cipher on first notice of weakness. The current alternative, of course, is to have a integrated system, and we must replace the entire system simply to upgrade the cipher. That means we must wait for somebody else to produce an acceptable replacement, which probably requires us to first *prove* that the "universal" cipher is weak (otherwise, everyone would argue for "interoperability"). Could Germany and Japan *prove* their ciphers were weak in WWII? Would they have been better off changing their (broken) ciphers? --- Terry Ritter ritter@io.com http://www.io.com/~ritter/ Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Fri, 15 Oct 1999 06:52:02 -0700 From: "Roger Schlafly" <real@ieee.org> Message-ID: <7u7bfm$126l@enews3.newsguy.com> References: <3806fab2.1389948@news.io.com> Newsgroups: sci.crypt Lines: 22 Terry Ritter <ritter@io.com> wrote in message news:3806fab2.1389948@news.io.com... > The use of *keys* limits interoperability -- to those who have the > right keys. We now do arrange to transfer keys as needed. We could > arrange to transfer the name of the cipher to be used, or even the > cipher itself. Yes, having several ciphers is equivalent to having a couple of extra key bits. > ... Could Germany and Japan *prove* their ciphers > were weak in WWII? Would they have been better off changing their > (broken) ciphers? Obviously they would have tried to design better ciphers if they knew their ciphers were being broken. But diversity for the sake of diversity would not have helped htem much, and might have even hurt them because the alternative ciphers might be more easily broken..
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: 15 Oct 1999 18:23:32 GMT From: djohn37050@aol.com (DJohn37050) Message-ID: <19991015142332.05892.00000048@ng-co1.aol.com> References: <7u7bfm$126l@enews3.newsguy.com> Newsgroups: sci.crypt Lines: 15 If one reads the history of military crypto, one finds the following: 1) User errors resulted in many breaks. 2) Even when used correctly, the "correct" method was imperfect and led to breaks. 3) When breaks were suspected, they tried to fix it by incremental improvement, such as adding a new cipher wheel, adding a new column to a transpostion cipher, shortening the cryptoperiod. All these made it more difficult for the cryptanalyst, but because it was incremental, they knew the original solution and just needed to figure out the incremental change, which was a MUCH easier task. And in fact they HAD diversity, the best groups PLANNED to have their ciphers go away, they figured that they were broken after being in use for some time even if they were not. Don Johnson
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Fri, 15 Oct 1999 22:26:17 +0200 From: Mok-Kong Shen <mok-kong.shen@t-online.de> Message-ID: <38078DE9.11ABADDD@t-online.de> References: <7u7bfm$126l@enews3.newsguy.com> Newsgroups: sci.crypt Lines: 19 Roger Schlafly wrote: > > Terry Ritter <ritter@io.com> wrote > > ... Could Germany and Japan *prove* their ciphers > > were weak in WWII? Would they have been better off changing their > > (broken) ciphers? > > Obviously they would have tried to design better ciphers if they knew > their ciphers were being broken. But diversity for the sake of > diversity would not have helped htem much, and might have even > hurt them because the alternative ciphers might be more easily > broken.. I suppose it is (generally) assumed in the current discussion that the top three candidates in the final round of AES contest are approximately of the same quality, much like the three medalists in Olympic games. M. K. Shen
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Sun, 17 Oct 1999 15:45:38 GMT From: ritter@io.com (Terry Ritter) Message-ID: <3809eeae.4757943@news.io.com> References: <7u7bfm$126l@enews3.newsguy.com> Newsgroups: sci.crypt Lines: 39 On Fri, 15 Oct 1999 06:52:02 -0700, in <7u7bfm$126l@enews3.newsguy.com>, in sci.crypt "Roger Schlafly" <real@ieee.org> wrote: >Terry Ritter <ritter@io.com> wrote in message >news:3806fab2.1389948@news.io.com... >> The use of *keys* limits interoperability -- to those who have the >> right keys. We now do arrange to transfer keys as needed. We could >> arrange to transfer the name of the cipher to be used, or even the >> cipher itself. > >Yes, having several ciphers is equivalent to having a couple of >extra key bits. > >> ... Could Germany and Japan *prove* their ciphers >> were weak in WWII? Would they have been better off changing their >> (broken) ciphers? > >Obviously they would have tried to design better ciphers if they knew >their ciphers were being broken. But diversity for the sake of >diversity would not have helped htem much, and might have even >hurt them because the alternative ciphers might be more easily >broken.. Might, might, might. In contrast, we *know* what happens when someone is convinced their cipher is strong enough: the classic examples are Germany and Japan in WWII. On the other hand, perhaps you have a better suggestion for controlling this disturbing reality. The problem is not proposals for change. The problem is the conventional wisdom which is insufficient in itself. --- Terry Ritter ritter@io.com http://www.io.com/~ritter/ Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: 16 Oct 1999 17:44:34 GMT From: David A Molnar <dmolnar@fas.harvard.edu> Message-ID: <7uadi2$sva$2@news.fas.harvard.edu> References: <3806fab2.1389948@news.io.com> Newsgroups: sci.crypt Lines: 19 Terry Ritter <ritter@io.com> wrote: > The use of *keys* limits interoperability -- to those who have the > right keys. We now do arrange to transfer keys as needed. We could > arrange to transfer the name of the cipher to be used, or even the > cipher itself. You (or anyone else reading) may want to look at this master's thesis on "Self-Describing Cryptography" : http://ben.adida.net/thesis/ which covers exactly the problem of transferring the description of a cipher along with the message it's going to decrypt. Part of the thesis is a sample implementation in Java. I can't find the actual code up on the site, but presumably one could ask the author for more details. thanks, -David
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Mon, 18 Oct 1999 20:18:53 GMT From: schneier@counterpane.com (Bruce Schneier) Message-ID: <38197f36.21981738@news.visi.com> References: <7uadi2$sva$2@news.fas.harvard.edu> Newsgroups: sci.crypt Lines: 23 On 16 Oct 1999 17:44:34 GMT, David A Molnar <dmolnar@fas.harvard.edu> wrote: >You (or anyone else reading) may want to look at this master's thesis on >"Self-Describing Cryptography" : > >http://ben.adida.net/thesis/ > >which covers exactly the problem of transferring the description of a >cipher along with the message it's going to decrypt. Part of the thesis is >a sample implementation in Java. I can't find the actual code up on the >site, but presumably one could ask the author for more details. I've seen proposals for this kind of thing. You can think of it as the cipher having a secondary key that helps choose among a family of transformations. Ciphers like this generally have lots of weak keys--they are as secure as the weakest transformation in the family--and are usually stronger without the secondary key. Bruce ********************************************************************** Bruce Schneier, President, Counterpane Systems Phone: 612-823-1098 101 E Minnehaha Parkway, Minneapolis, MN 55419 Fax: 612-823-1590 Free crypto newsletter. See: http://www.counterpane.com
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Mon, 18 Oct 1999 20:01:36 GMT From: schneier@counterpane.com (Bruce Schneier) Message-ID: <38147c73.21274850@news.visi.com> References: <939934178.27828.0.nnrp-11.c2de6a96@news.demon.co.uk> Newsgroups: sci.crypt Lines: 17 On Thu, 14 Oct 1999 21:50:49 +0100, "Brian Gladman" <gladman@seven77.demon.co.uk> wrote: >Nearly all practical standards offer a host of options so it is quite wrong >to suggest that we cannot meet most interoperability needs while also >meeting the need for controlled algorithm diversity - I can list a large >number of internet protocol standards, all of which are designed to >accommodate algorithm diversity. Yes, but security standards are different. IPsec is much less secure because of all the options it has. Complexity is security's worst enemy. Bruce ********************************************************************** Bruce Schneier, President, Counterpane Systems Phone: 612-823-1098 101 E Minnehaha Parkway, Minneapolis, MN 55419 Fax: 612-823-1590 Free crypto newsletter. See: http://www.counterpane.com
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Mon, 18 Oct 1999 23:44:01 +0100 From: "Brian Gladman" <gladman@seven77.demon.co.uk> Message-ID: <940286649.17035.0.nnrp-02.c2de6a96@news.demon.co.uk> References: <38147c73.21274850@news.visi.com> Newsgroups: sci.crypt Lines: 32 Bruce Schneier <schneier@counterpane.com> wrote in message news:38147c73.21274850@news.visi.com... > On Thu, 14 Oct 1999 21:50:49 +0100, "Brian Gladman" > <gladman@seven77.demon.co.uk> wrote: > >Nearly all practical standards offer a host of options so it is quite wrong > >to suggest that we cannot meet most interoperability needs while also > >meeting the need for controlled algorithm diversity - I can list a large > >number of internet protocol standards, all of which are designed to > >accommodate algorithm diversity. > > Yes, but security standards are different. IPsec is much less secure > because of all the options it has. Complexity is security's worst > enemy. I agree in general but a certain amount of complexity is usually unavoidable in meeting other requirements. Most often the need to minimise complexity is just one more requirement that has to be balanced against other conflicting requirements in reaching an acceptable overall solution. I consider Twofish to be a more complex algorithm than RC6 but I don't judge this to mean that RC6 is necessarily more secure than Twofish. There is more to it than that. Moreover, complexity, like beauty, is often in the eye of the beholder. Brian Gladman
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Fri, 15 Oct 1999 10:13:27 +0200 From: Mok-Kong Shen <mok-kong.shen@t-online.de> Message-ID: <3806E227.B0D0A454@t-online.de> References: <7u6d12$feh@enews3.newsguy.com> <380685F0.737F2516@aspi.net> Newsgroups: sci.crypt Lines: 26 Roger Schlafly wrote: > > Trevor Jackson, III <fullmoon@aspi.net> wrote in message > news:380685F0.737F2516@aspi.net... > > Let those who like standards pick from the final five. If you like > standards, > > more standards is better isn't it? > > No. Two standards for the same thing means that there is > no standard. Your statement is like saying, if you like > monogamy, more wives is better. Remember that triple DES IS a seperate standard from single DES. Why did the financial people think that single DES could be a risk to them well before the hardware (processing speed) and theory (differential analysis etc.) have pushed such a risk out of a dream into reality? I guess from this fact that the risk assessment and security requiments of one person can be VERY different from another. Thus it is extremely difficult to have one thing that fits all. I personally don't deem it entirely unrealistic that the history might indeed repeat here: After AES there would soon be triple AES. M. K. Shen ----------------------- http://home.t-online.de/home/mok-kong.shen
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Fri, 15 Oct 1999 06:55:45 -0400 From: "Trevor Jackson, III" <fullmoon@aspi.net> Message-ID: <38070831.6163F02B@aspi.net> References: <7u6d12$feh@enews3.newsguy.com> <380685F0.737F2516@aspi.net> Newsgroups: sci.crypt Lines: 24 Roger Schlafly wrote: > Trevor Jackson, III <fullmoon@aspi.net> wrote in message > news:380685F0.737F2516@aspi.net... > > Let those who like standards pick from the final five. If you like > standards, > > more standards is better isn't it? > > No. Two standards for the same thing means that there is > no standard. Your statement is like saying, if you like > monogamy, more wives is better. You are misusing the term standard. You may have a point, but it is obscured by your linguistic contortions. Consider the simple act of physical measurements. In the (reactionary) United States there are two standards for measuring physical quantities. They are completely independent. Completely redundant. But no one claims that "two standards for the same things means that there is no standard". Two standards doe snot mean ero standards. Two standards means two standards. 2 != 0.
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Fri, 15 Oct 1999 10:27:55 -0400 From: "Trevor Jackson, III" <fullmoon@aspi.net> Message-ID: <380739EB.8FCE7629@aspi.net> References: <7u796b$10u7@enews3.newsguy.com> <38070831.6163F02B@aspi.net> Newsgroups: sci.crypt Lines: 30 Roger Schlafly wrote: > Trevor Jackson, III <fullmoon@aspi.net> wrote in message > news:38070831.6163F02B@aspi.net... > > Roger Schlafly wrote: > > > No. Two standards for the same thing means that there is > > > no standard. Your statement is like saying, if you like > > > monogamy, more wives is better. > > > > You are misusing the term standard. You may have a point, but it is > > obscured by your linguistic contortions. > > > > Consider the simple act of physical measurements. In the (reactionary) > > United States there are two standards for measuring physical quantities. > > They are completely independent. Completely redundant. But no one > > claims that "two standards for the same things means that there is no > > standard". > > You mean because we have feet and meters in the US? To the extent > this is true, distance measurement is not standardized. It is not an ideal > situation, as evidenced by the recent crash of the martian probe. Right. It isn't ideal. It's reality. If we design for an ideal world rather than the real one we are doomed to failure. Disasters attributable to misplaced decimals and loss of significance are far more common than those attributable to units confusion. The Hubble space telescope fiasco was caused by loss of significance in the model use to make the optical reference for the primary optics.
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: 16 Oct 99 01:56:56 GMT From: jsavard@ecn.ab.ca () Message-ID: <3807db68.0@ecn.ab.ca> References: <939900926.22743.0.nnrp-12.c2de6a96@news.demon.co.uk> Newsgroups: sci.crypt Lines: 20 Brian Gladman (gladman@seven77.demon.co.uk) wrote: : The arguments for multiple AES winners cannot be dismissed so easily. Come to think of it, there *is* an easy way to dismiss the idea of having multiple AES winners. The AES entrants only promised to allow free use of their ciphers if their own cipher was _the_ winner of the AES process. Hence, changing the rules now, and declaring multiple winners would be unfair to those entrants which are retaining proprietary rights to their ciphers. However, just because only one algorithm is *the* winner in no way prevents the other algorithms from being used, with the permission of their inventors. Since the NSA has even spoken, and proclaimed that none of the five finalists is insecure, we _have_ a plurality of block ciphers to use. They just won't all be declared "winners". John Savard
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Mon, 18 Oct 1999 20:20:09 GMT From: schneier@counterpane.com (Bruce Schneier) Message-ID: <381a80ed.22420769@news.visi.com> References: <3807db68.0@ecn.ab.ca> Newsgroups: sci.crypt Lines: 28 On 16 Oct 99 01:56:56 GMT, jsavard@ecn.ab.ca () wrote: >Brian Gladman (gladman@seven77.demon.co.uk) wrote: >: The arguments for multiple AES winners cannot be dismissed so easily. > >Come to think of it, there *is* an easy way to dismiss the idea of having >multiple AES winners. > >The AES entrants only promised to allow free use of their ciphers if their >own cipher was _the_ winner of the AES process. Hence, changing the rules >now, and declaring multiple winners would be unfair to those entrants >which are retaining proprietary rights to their ciphers. > >However, just because only one algorithm is *the* winner in no way >prevents the other algorithms from being used, with the permission of >their inventors. Since the NSA has even spoken, and proclaimed that none >of the five finalists is insecure, we _have_ a plurality of block ciphers >to use. > >They just won't all be declared "winners". Heh. It's probably against the rules, though. Bruce ********************************************************************** Bruce Schneier, President, Counterpane Systems Phone: 612-823-1098 101 E Minnehaha Parkway, Minneapolis, MN 55419 Fax: 612-823-1590 Free crypto newsletter. See: http://www.counterpane.com
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Tue, 12 Oct 1999 14:45:42 GMT From: jsavard@tenMAPSONeerf.edmonton.ab.ca (John Savard) Message-ID: <3803487e.524419@news.prosurfr.com> References: <3801f648.290065@news.visi.com> <19991010174550.05076.00000677@ng-cl1.aol.com> Newsgroups: sci.crypt Lines: 19 schneier@counterpane.com (Bruce Schneier) wrote, in part: >I >almost never have clients who can devote an arbitrary amount of >computing resources to the encryption process. This is why AES is >important. And, of course, for the specific case where a fairly large amount of computing resources are available for encryption - a desktop computer encrypting E-mail, the application that was well handled even by the original DOS versions of PGP - keeping keys secure and the like is easily mishandled (although PGP was well-designed, and limited that threat as far as possible). If one encrypts with a separate box with, say, a little 68HC11 inside of it, one can keep those keys locked away rather better. John Savard ( teneerf<- ) http://www.ecn.ab.ca/~jsavard/crypto.htm
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Tue, 12 Oct 1999 19:24:28 GMT From: schneier@counterpane.com (Bruce Schneier) Message-ID: <38038aa5.1795716@news.visi.com> References: <3803487e.524419@news.prosurfr.com> Newsgroups: sci.crypt Lines: 29 On Tue, 12 Oct 1999 14:45:42 GMT, jsavard@tenMAPSONeerf.edmonton.ab.ca (John Savard) wrote: >schneier@counterpane.com (Bruce Schneier) wrote, in part: > >>I >>almost never have clients who can devote an arbitrary amount of >>computing resources to the encryption process. This is why AES is >>important. > >And, of course, for the specific case where a fairly large amount of >computing resources are available for encryption - a desktop computer >encrypting E-mail, the application that was well handled even by the >original DOS versions of PGP - keeping keys secure and the like is >easily mishandled (although PGP was well-designed, and limited that >threat as far as possible). Right. E-mail encryption is a perfect application where cascades are reasonable. Pretty much no one cares if they have to wait 10 milliseconds or 50 milliseconds for the encryption to occur. And I also agree that everything around the encryption is more vulnerable. Bruce ********************************************************************** Bruce Schneier, President, Counterpane Systems Phone: 612-823-1098 101 E Minnehaha Parkway, Minneapolis, MN 55419 Fax: 612-823-1590 Free crypto newsletter. See: http://www.counterpane.com
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Fri, 15 Oct 1999 15:03:10 GMT From: dianelos@tecapro.com Message-ID: <7u7fn4$l5o$1@nnrp1.deja.com> References: <3801f648.290065@news.visi.com> <19991010174550.05076.00000677@ng-cl1.aol.com> Newsgroups: sci.crypt Lines: 56 In article <3801f648.290065@news.visi.com>, schneier@counterpane.com (Bruce Schneier) wrote: > On 10 Oct 1999 21:45:50 GMT, djohn37050@aol.com (DJohn37050) wrote: > >>Multiple encryption using different ciphers was also mentioned in my >>submission to the 2nd AES conference entitled "Future Resiliency: A >>Possible New AES Criterion" and is available from NIST AES web site. > >Yes. In general, I find it uninteresting to talk about encryption >when there are no constraints. Of course you can use multiple >encryption using different ciphers, if you have the time/gates/etc. >Of course it's more secure, as is almost everything if you throw >enough rounds at it. > >Where it really matters, and where real cryptography comes into play, >is when you have to deal with real-world performance decisions. I >almost never have clients who can devote an arbitrary amount of >computing resources to the encryption process. This is why AES is >important. Much of this thread has been about cascading ciphers as a way to increase security. What I find interesting is that only a few months ago many in this newsgroup thought that this is a bad idea. Cascading ciphers was politically incorrect; even a top cryptographer I met in the Second AES conference did not want me to quote him on this matter. Now it is out in the open, and I think that the unstructured but fast exchange of ideas in a newsgroup can help to dispel myths. (It certainly helps when widely reputable people participate in the discussion.) The whole point in cascading ciphers, as opposed to adding rounds to a single cipher, is to mix different kinds of structures and make the whole beast less sensitive to an unforeseen attack. What this means is that even after the AES a market will exist for unconventional ciphers. Who knows, even my Frog algorithm may start hopping again. It is simple, free, and is certainly very unconventional. Another common issue in this tread has been about speed. Undoubtedly there are applications that require extremely high speeds. There are also many applications where speed is almost irrelevant. Almost all client applications (working on the end-user's PC) don't require speeds of encryption over a few megabits per second. IP telephony, for example, requires only about 10 kbits per second. Contrast this to over 100 Mbits per second that can easily be achieved by the fastest AES candidates on today's PCs. Using the AES alone for PC based IP telephony makes little sense. By the way, public key primitives are considered to be more susceptible to catastrophic failure than any single symmetric cipher. Here too it must make sense to use several methods in parallel, particularly with the high speeds achieved by modern PCs. Unconventional public key designs anyone? :) Sent via Deja.com http://www.deja.com/ Before you buy.
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: 16 Oct 99 15:19:12 GMT From: jsavard@ecn.ab.ca () Message-ID: <38089770.0@ecn.ab.ca> References: <7u92pv$251j@enews3.newsguy.com> <7u7fn4$l5o$1@nnrp1.deja.com> Newsgroups: sci.crypt Lines: 21 Roger Schlafly (real@ieee.org) wrote: : <dianelos@tecapro.com> wrote in message news:7u7fn4$l5o$1@nnrp1.deja.com... : > Much of this thread has been about cascading ciphers as a way to : > increase security. What I find interesting is that only a few months : > ago many in this newsgroup thought that this is a bad idea. : Many still think it is a bad idea. If a cipher has shortcomings, : it is better to fix the cipher than to pile other ciphers on top : of it. But the point - and it's a valid one - of the side other than yours on this question is that sometimes we don't *know* all the shortcomings of a cipher. So, if we pile up several _very different_ ciphers, we do have an additional degree of reassurance. I agree it is a lesser degree than the one we get from a long period of study and analysis by the academic community, however. But I think it is a valid point that we need all the reassurance we can get - because all we can get still isn't enough. John Savard
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Sun, 17 Oct 1999 17:08:26 GMT From: ritter@io.com (Terry Ritter) Message-ID: <380a0287.9839216@news.io.com> References: <38089770.0@ecn.ab.ca> Newsgroups: sci.crypt Lines: 86 On 16 Oct 99 15:19:12 GMT, in <38089770.0@ecn.ab.ca>, in sci.crypt jsavard@ecn.ab.ca () wrote: >Roger Schlafly (real@ieee.org) wrote: >: <dianelos@tecapro.com> wrote in message news:7u7fn4$l5o$1@nnrp1.deja.com... >: > Much of this thread has been about cascading ciphers as a way to >: > increase security. What I find interesting is that only a few months >: > ago many in this newsgroup thought that this is a bad idea. > >: Many still think it is a bad idea. If a cipher has shortcomings, >: it is better to fix the cipher than to pile other ciphers on top >: of it. > >But the point - and it's a valid one - of the side other than yours on >this question is that sometimes we don't *know* all the shortcomings of a >cipher. Why would you claim that "the other side" says this happens "sometimes"? I claim that we *never* know "all the shortcomings of a cipher," absent some sort of mathematically provable security in practice. >So, if we pile up several _very different_ ciphers, we do have an >additional degree of reassurance. > >I agree it is a lesser degree than the one we get from a long period of >study and analysis by the academic community, however. Really? To what degree can you *measure* the "reassurance" provided by "the academic community?" And if you can't measure it, how do you know it has increased? What is your scientific support for such a statement? In fact, consider the situation during analysis: In the beginning, every cipher starts out unbroken. We would thus use it. Later on, that same cipher may be broken, so we would not use it. But during the period we did use that cipher, it was still breakable, we just did not *know* that it was breakable, but maybe someone else did. This is the natural life of every cipher, unless we have some delusion that any particular cipher will *never* be broken. I say "delusion" because there is no scientific support for such a statement. We cannot even measure the effort by "the scientific community" places into the analysis of any one cipher. What we see in "scientific" papers are successful (or quasi-successful) breaks. We do *not* (generally) see "We worked on this intensely for 8 months, and never found a weakness." On its own, such a statement is probably not publishable as new Science. Yet it would be far better evidence than simply saying nothing at all, which is the way "the scientific community" works now. Our only current alternative is to consider new ciphers *strong* until a scientific examination shows a weakness, for that is the game "the scientific community" plays, and they see no reason to change the rules. >But I think it is a >valid point that we need all the reassurance we can get - because all we >can get still isn't enough. In which case, how does any amount of reassurance help? I claim there can be no assurance: any cipher can fail at any time. * We can improve our odds by eliminating known-plaintext attacks on component ciphers, and by requiring opponents to find weaknesses which can be exploited within a cipher-stack environment. * If we assume that all ciphers are in fact broken in practice, there is no point in cryptography. But if we assume that only some fraction are broken, we can reduce the amount of our plaintext which may be revealed by using many different ciphers. This also has the effect of limiting the reward opponents might get from breaking any particular cipher, which thus limits the resources they are willing to put into any such attack. If our opponents needed vast resources to break a cipher on its own, and they have fewer resources when many different ciphers are used, we have obviously improved our situation. * If we assume that some ciphers are broken, we can terminate the extent of any successful attack by changing our cipher frequently. --- Terry Ritter ritter@io.com http://www.io.com/~ritter/ Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: 15 Oct 1999 14:25:28 -0400 From: juola@mathcs.duq.edu (Patrick Juola) Message-ID: <7u7rio$ds4$1@quine.mathcs.duq.edu> References: <380760A1.BB7D356F@aspi.net> <7u7h2m$dcs$1@quine.mathcs.duq.edu> Newsgroups: sci.crypt Lines: 47 In article <380760A1.BB7D356F@aspi.net>, Trevor Jackson, III <fullmoon@aspi.net> wrote: >Patrick Juola wrote: > >> In article <380738DA.1FA12305@aspi.net>, >> Trevor Jackson, III <fullmoon@aspi.net> wrote: >> >Patrick Juola wrote: >> >> In article <3806845E.16D4C14F@aspi.net>, >> >> Trevor Jackson, III <fullmoon@aspi.net> wrote: >> >> > >> >> >Any users desiring to communicate will be able to select a mechanism to do >> >> >so. Any analysis dismissing the active participation of the users in the >> >> >dynamic selection of their channel properties from amoug the telephone, fax, >> >> >and email is trivially flawed. >> >> >> >> Nonsense. The Three-Initial-Corp. decides to use XYZ encryption for >> >> all it's communication needs and invests several billion dollars in XYZ- >> >> compliant mailers, routers, telephones, and so forth. The Even-Larger- >> >> Five-Initial-Corp., independently, decides to invest in PQ encryption >> >> and spends similarly huge amounts on its scrambler phone. >> >> >> >> The individual participant/employees of the companies involved are >> >> probably not going to be able to "dynamically select" their encryption >> >> scheme; they will use what's on their desk. And what's going to happen >> >> when ELFIC buys TIC? >> >> >> > >> >Well, the one of the companies, either the one using fax or the one using email, >> >is going to have to change. >> >> ... and the whole *point* of having standards is to minimize and >> reduce the likelihood of this sort of retooling costs. > >By this reasoning we should only use telephones and avoid fax and email channels? >After all it would reduce the tooling costs, right? No, by this reasoning we should make sure that all telephones interoperate. You'll notice that the word "fax" didn't appear at all in the description I gave above. Instead, both companies have purchased *secure phones*, but the phones won't talk to each other. What's the advantage gained by having two sets of mutually incomprehensible secure phones? Half of your people can't talk to the other half -- using channels that to an outside observer are identical. -kitten
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Mon, 11 Oct 1999 22:11:57 -0600 From: jgfunj@vgrknf.arg (wtshaw) Message-ID: <jgfunj-1110992211570001@dial-243-062.itexas.net> References: <38023EE0.C0100192@crak.com> <3804ae80.2804726@news.visi.com> Newsgroups: sci.crypt Lines: 37 In article <38023EE0.C0100192@crak.com>, "John E. Kuslich" <johnk@crak.com> wrote: > ...It therefore stands to reason that any software > running on an insecure computer is also insecure. And, an insecure architecture is fixed with software alone is only a decorative patch; many may admire it but a few disregard it. > The medium is the message... As said by McL.. > > The medium is insecure, therefore the message is insecure. > > A cryptographic system is like a boat made of layers of steel plate > covered by more layers of titanium plate covered by layers of more steel > armor plate. Just one little leak, just one little sea cock left open, > just one little iceberg, just one sailor beat up with one rubber hose can > scuttle the ship. The name Titanic comes to mind... That is a miserable way to build computers as well. .... > > Resistance is futile... Only if you give in. > > > Bruce Schneier wrote: > > As our society becomes more > > reliant on a digital infrastructure, the process of security must be > > designed in from the beginning. > > Basic Security 101, or ought to be. -- Figures lie, and liars figure.--Daria Dolan message sender's identity is unknown, unlogged, and not replyable. Again, it is IMPOSSIBLE to find out the original sender's identity! If you wish to be blocked from future mailings or want to report other problems with this service, please contact the operator at <flash-admin@nym.alias.net>.
Subject: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Thu, 14 Oct 1999 18:50:54 +0200 From: Anonymous <flash-bounce@nym.alias.net> Message-ID: <199910141650.SAA00989@pingu.localnet> References: <38023EE0.C0100192@crak.com> <3804ae80.2804726@news.visi.com> Newsgroups: sci.crypt Lines: 11 Could you please explain what you mean by multiple algorithms or ciphers. Are you refering to chaining or using different ciphers on different blocks. How would that work? Would you use alternate ciphers onm alternate blocks, or maybe a sequential set I am assuming that all the ciphers must use the same blovk size... Or would you randomely select a cipher from a set on each consecutive block... Thanks for your answer in anticpation.. It seems that from what Mr Schneier is saying...Smart Cards are not very Smart at all...any comments on this...they seem to be more of a security hole then a security help
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Thu, 14 Oct 1999 21:12:37 +0200 From: Mok-Kong Shen <mok-kong.shen@t-online.de> Message-ID: <38062B25.A83CBEF6@t-online.de> References: <199910141650.SAA00989@pingu.localnet> Newsgroups: sci.crypt Lines: 30 Anonymous wrote: > > Could you please explain what you mean by multiple algorithms or ciphers. Are you refering to chaining or using different ciphers on different blocks. How would that work? Would you use alternate ciphers onm alternate blocks, or maybe a sequential set of ciphers on alternate blocks... > > I am assuming that all the ciphers must use the same blovk size... > > Or would you randomely select a cipher from a set on each consecutive block... In my humble opinion it 'suffices' for the purpose of discussion of the present thread to make the simplest assumptions about using multiple algorithms, i.e. avoiding as many issues as possible that could bring in unnecessary complications without essentially contributing to the question of comparative merits of multiple algorithms against single algorithm as such. Thus I would assume (1) n cipers are selected, n = constant, (2) these are ordered, (3) these have the same block size, (4) each block is sequentially enciphered by the n ciphers, (5) there is no chaining. As you have certainly noticed, each of the five items above can be dropped/varied. Doing so would lead to results favouring the use of multiple algorithms in my humble opinion. M. K. Shen -------------------------- http://home.t-online.de/home/mok-kong.shen
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: 18 Oct 1999 20:42:37 GMT From: djohn37050@aol.com (DJohn37050) Message-ID: <19991018164237.21842.00000130@ng-fk1.aol.com> References: <38062B25.A83CBEF6@t-online.de> Newsgroups: sci.crypt Lines: 8 At a recent ANSI X9F1 meeting, where particpents consisted of vendors, bankers, auditors and government, there was overwhelming consensus that NIST should incorporate future resiliency considerations into AES criteria. No one is saying that an implementation cannot choose one algorithm, just allow the ones that want to (for whatever reason) to be allowed to implement more than one and do this in the context of the standard. Don Johnson
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Mon, 18 Oct 1999 17:17:28 -0700 From: "Roger Schlafly" <real@ieee.org> Message-ID: <7ugd7q$1d0n@enews4.newsguy.com> References: <19991018164237.21842.00000130@ng-fk1.aol.com> Newsgroups: sci.crypt Lines: 25 DJohn37050 <djohn37050@aol.com> wrote in message news:19991018164237.21842.00000130@ng-fk1.aol.com... > At a recent ANSI X9F1 meeting, where particpents consisted of vendors, bankers, > auditors and government, there was overwhelming consensus that NIST should > incorporate future resiliency considerations into AES criteria. This is so vague as to be meaningless. Can one winner have the requested resiliency? > No one is saying that an implementation cannot choose one algorithm, just allow > the ones that want to (for whatever reason) to be allowed to implement more > than one and do this in the context of the standard. Remember that this is the same committee of idiots who think that RSA implementations should only be allowed to use a certain very restricted class of primes when generating RSA keys. Bankers are not the best ones to be making communications security decisions.
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Tue, 19 Oct 1999 15:45:49 GMT From: Bob Silverman <bobs@rsa.com> Message-ID: <7ui3n9$fm0$1@nnrp1.deja.com> References: <7ugd7q$1d0n@enews4.newsguy.com> Newsgroups: sci.crypt Lines: 61 In article <7ugd7q$1d0n@enews4.newsguy.com>, "Roger Schlafly" <real@ieee.org> wrote: > DJohn37050 <djohn37050@aol.com> wrote in message > news:19991018164237.21842.00000130@ng-fk1.aol.com... >> At a recent ANSI X9F1 meeting, where particpents consisted of vendors, > bankers, >> auditors and government, there was overwhelming consensus that NIST should >> incorporate future resiliency considerations into AES criteria. > > This is so vague as to be meaningless. Can one winner have the > requested resiliency? It is also a mis-statement of what happened. The working group voted to suggest that NIST should *consider* reading documents that discuss "future resiliency", and *not* "NIST should incorporate....." We did NOT vote to recommend to NIST that AES should incorporate "future resiliency", but only to recommend to NIST that they should think about it as part of their review process. > > No one is saying that an implementation cannot choose one algorithm, >just allow >>the ones that want to (for whatever reason) to be allowed to implement > more than one But they can do that anyway! > and do this in the context of the standard. Then it is no longer "a standard". > > Remember that this is the same committee of idiots who think that > RSA implementations should only be allowed to use a certain > very restricted class of primes when generating RSA keys. I fought long and hard against that requirement. To no avail. > > Bankers are not the best ones to be making communications > security decisions. Agreed. But they are competent to decide upon interoperability standards for their industry. They understand their needs better than others. Also, there are some actual cryptographers on the committee (me, Rich Ankney, Rob Zucherato, Mike Wiener, Simon Blake-Wilson, Paul Timmel etc.) -- Bob Silverman "You can lead a horse's ass to knowledge, but you can't make him think" Sent via Deja.com http://www.deja.com/ Before you buy.
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: 19 Oct 1999 18:17:54 GMT From: djohn37050@aol.com (DJohn37050) Message-ID: <19991019141754.19497.00000025@ng-cm1.aol.com> References: <7ui3n9$fm0$1@nnrp1.deja.com> Newsgroups: sci.crypt Lines: 7 To be perfectly clear, there were really 2 votes at X9F1 on Future Resiliency. 1) was to incorporate future resiliency into AES process. 2) was to consider the ideas in the paper in the AES process. Both were the consensus of the group, the latter (being weaker) obtained more votes than the former. Don Johnson
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Tue, 19 Oct 1999 21:51:43 -0700 From: "Roger Schlafly" <real@ieee.org> Message-ID: <7ujhm3$1tna@enews1.newsguy.com> References: <19991019141754.19497.00000025@ng-cm1.aol.com> Newsgroups: sci.crypt Lines: 25 DJohn37050 <djohn37050@aol.com> wrote in message news:19991019141754.19497.00000025@ng-cm1.aol.com... > To be perfectly clear, there were really 2 votes at X9F1 on Future Resiliency. > 1) was to incorporate future resiliency into AES process. > 2) was to consider the ideas in the paper in the AES process. > > Both were the consensus of the group, the latter (being weaker) obtained more > votes than the former. Do you have the text of the motion? "Future resiliency" can mean a lot of things. It might mean that the AES winner should be efficient on a lot of platforms. It might mean that the AES winner should be able to withstand a wide variety of attacks. It might mean that the AES approval process should be more flexible in address everyone's concern or in being willing to improve algorithms by tweaking them. It sounds to me that you got a meaningless resolution passed, and now you are pretending that it was an endorsement of your ideas.
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Wed, 20 Oct 1999 17:11:37 -0700 From: "Roger Schlafly" <real@ieee.org> Message-ID: <7ulll2$j23@enews1.newsguy.com> References: <19991020092446.15076.00000024@ng-fr1.aol.com> <7ujhm3$1tna@enews1.newsguy.com> Newsgroups: sci.crypt Lines: 21 DJohn37050 <djohn37050@aol.com> wrote in message news:19991020092446.15076.00000024@ng-fr1.aol.com... > I said I presented the ideas in my "Future Resiliency" paper and the summary is > that there should be disparate winners. There was discussion in the group > regarding what to do, if anything, about these ideas. We settled on a vote, so > I could send an official note to NIST regarding X9F1 sentiments. I did that. Ok, fine, but the vote was not on whether there should be disparate winners. If I were on the committee, I would vote AGAINST any proposal that NIST name multiple winners. But I'd vote FOR "future resiliency into AES process". Resiliency can be a good thing. Therefore, I do not think that the vote was a show of support for your ideas.
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Wed, 20 Oct 1999 21:25:08 -0400 From: "Rich Ankney" <rankney@erols.com> Message-ID: <7ulq8m$cdj$1@autumn.news.rcn.net> References: <7ulll2$j23@enews1.newsguy.com> Newsgroups: sci.crypt Lines: 30 I was at this meeting. IIRC, the vote was to suggest to NIST that multiple algorithms should be allowed for AES. Don can correct me if I'm wrong... / Rich Roger Schlafly wrote in message <7ulll2$j23@enews1.newsguy.com>... >DJohn37050 <djohn37050@aol.com> wrote in message >news:19991020092446.15076.00000024@ng-fr1.aol.com... >> I said I presented the ideas in my "Future Resiliency" paper and the >summary is >> that there should be disparate winners. There was discussion in the group >> regarding what to do, if anything, about these ideas. We settled on a >vote, so >> I could send an official note to NIST regarding X9F1 sentiments. I did >that. > >Ok, fine, but the vote was not on whether there should be disparate >winners. If I were on the committee, I would vote AGAINST any >proposal that NIST name multiple winners. But I'd vote FOR >"future resiliency into AES process". Resiliency can be a good >thing. > >Therefore, I do not think that the vote was a show of support >for your ideas. > > >
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: 21 Oct 1999 02:07:42 GMT From: djohn37050@aol.com (DJohn37050) Message-ID: <19991020220742.27613.00000207@ng-bd1.aol.com> References: <7ulq8m$cdj$1@autumn.news.rcn.net> Newsgroups: sci.crypt Lines: 3 Yes, Roger refuses to be convinced, so I keep clarifying, and he keeps refusing. Same old Roger. Don Johnson
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Wed, 20 Oct 1999 22:48:15 -0700 From: "Roger Schlafly" <real@ieee.org> Message-ID: <7um9cc$13h2@enews1.newsguy.com> References: <7ulq8m$cdj$1@autumn.news.rcn.net> Newsgroups: sci.crypt Lines: 15 Rich Ankney <rankney@erols.com> wrote in message news:7ulq8m$cdj$1@autumn.news.rcn.net... > I was at this meeting. IIRC, the vote was to suggest to NIST that multiple > algorithms should be allowed for AES. Don can correct me if I'm wrong... I challenged Don to produce the text of the motion. He didn't provide it, but he said the motion was for "future resiliency" not multiple algorithms. If Don thinks that the text of the motion supports his case, let him post it.
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Tue, 19 Oct 1999 14:41:01 -0400 From: "Trevor Jackson, III" <fullmoon@aspi.net> Message-ID: <380CBB3D.E9A90838@aspi.net> References: <7ui3n9$fm0$1@nnrp1.deja.com> Newsgroups: sci.crypt Lines: 45 Bob Silverman wrote: > In article <7ugd7q$1d0n@enews4.newsguy.com>, > "Roger Schlafly" <real@ieee.org> wrote: > > DJohn37050 <djohn37050@aol.com> wrote in message > > news:19991018164237.21842.00000130@ng-fk1.aol.com... > >> At a recent ANSI X9F1 meeting, where particpents consisted of > vendors, > > bankers, > >> auditors and government, there was overwhelming consensus that NIST > should > >> incorporate future resiliency considerations into AES criteria. > > > > This is so vague as to be meaningless. Can one winner have the > > requested resiliency? > > It is also a mis-statement of what happened. The working group > voted to suggest that NIST should *consider* reading documents that > discuss "future resiliency", and *not* "NIST should incorporate....." > > We did NOT vote to recommend to NIST that AES should incorporate > "future resiliency", but only to recommend to NIST that they should > think about it as part of their review process. > > > > > No one is saying that an implementation cannot choose one algorithm, > >just allow > >>the ones that want to (for whatever reason) to be allowed to implement > > more than one > > But they can do that anyway! They can't sell products containing unapproved ciphers to the Government. > > > > and do this in the context of the standard. > > Then it is no longer "a standard". Well, NIST would not have "blessed" a single cipher and thus relieved all implementors of design responsibility for cipher selection, but it would still be "standard", meaning passing the threshold established by NIST for cipher criteria. There is no problem having multiple "standard ciphers".
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Mon, 18 Oct 1999 23:23:15 -0400 From: "Trevor Jackson, III" <fullmoon@aspi.net> Message-ID: <380BE423.F3D7F761@aspi.net> References: <19991018164237.21842.00000130@ng-fk1.aol.com> Newsgroups: sci.crypt Lines: 42 DJohn37050 wrote: > At a recent ANSI X9F1 meeting, where particpents consisted of vendors, bankers, > auditors and government, there was overwhelming consensus that NIST should > incorporate future resiliency considerations into AES criteria. > > No one is saying that an implementation cannot choose one algorithm, just allow > the ones that want to (for whatever reason) to be allowed to implement more > than one and do this in the context of the standard. I suspect the term resiliency has multiple meanings. One of the meanings we should inspect is that of future revisions to standard algorithms, and even "Very AES" (VAES), which may be needed sometime in the future. DES didn't evolve. It did not get tweaked as a standard. It did gain extra layers such as DESX and 3DES. Will AES evolve? Will it need more "tweaks"? An infrastructure without resiliency is brittle. It cracks and fails catastrophically. Let's not. At some point in the future we'll be faced with an aging AES and the need to create a successor standard. Hopefully this will occur before AES is as useless as DES is today. If we learn from the current tardiness we will create VAES while AES is still "strong". Which means that when VAES is adopted there will be two standard ciphers. If we select a single AES "winner" the switch to VAES will be extremely painful. Given the expectation that security will become pervasive in the interval between now and then the switch to VAES will be much tougher than the switch from DES to AES. It might rival Y2K issues as a societal problem. Given the taste for litigation today do we want to allow the possibility of this kind of problem? OTOH, if we select multiple AES winners, and provide for evolutionary changes in the standard, similar to the round 2 "tweaks", the change to VAES will be reasonably smooth. Not easy, but comparatively simple. Speaking ex-cathedra from my navel I assert that the chance of the AES "winner(s)" being catastrophically weak is small. Very small. Close to zero. But the chance that we'll need something like VAES is large. Very large. Close to one.
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: 19 Oct 1999 03:51:36 GMT From: djohn37050@aol.com (DJohn37050) Message-ID: <19991018235136.00544.00000300@ng-fj1.aol.com> References: <380BE423.F3D7F761@aspi.net> Newsgroups: sci.crypt Lines: 8 The "Future Resiliency" presentation I made to X9F1 was EXACTLY the paper I submitted to 2nd AES, namely that there should be more than one winner and gave scads of reasons for this. Some disagree, ok. It remains to be seen what NIST will decide to do in this area. There are arguments on both sides. Simplicity is the main one for having only one winner. Don Johnson
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Mon, 18 Oct 1999 22:13:05 -0700 From: "Roger Schlafly" <real@ieee.org> Message-ID: <7ugui1$26lb@enews2.newsguy.com> References: <19991018235136.00544.00000300@ng-fj1.aol.com> Newsgroups: sci.crypt Lines: 15 DJohn37050 <djohn37050@aol.com> wrote in message news:19991018235136.00544.00000300@ng-fj1.aol.com... > The "Future Resiliency" presentation I made to X9F1 was EXACTLY the paper I > submitted to 2nd AES, namely that there should be more than one winner and gave > scads of reasons for this. So you presented a paper to some bankers, got some polite applause, and conclude that they all favor your radical idea of abandoning AES in favor of an official govt statement of indecision about ciphers? I think you are flattering yourself.
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Tue, 19 Oct 1999 08:47:38 +0100 From: "Brian Gladman" <gladman@seven77.demon.co.uk> Message-ID: <940319265.4483.0.nnrp-07.c2de6a96@news.demon.co.uk> References: <7ugui1$26lb@enews2.newsguy.com> Newsgroups: sci.crypt Lines: 25 Roger Schlafly <real@ieee.org> wrote in message news:7ugui1$26lb@enews2.newsguy.com... > DJohn37050 <djohn37050@aol.com> wrote in message > news:19991018235136.00544.00000300@ng-fj1.aol.com... > > The "Future Resiliency" presentation I made to X9F1 was EXACTLY the paper > I > > submitted to 2nd AES, namely that there should be more than one winner and > gave > > scads of reasons for this. > > So you presented a paper to some bankers, got some polite > applause, and conclude that they all favor your radical idea > of abandoning AES in favor of an official govt statement of > indecision about ciphers? I think you are flattering yourself. No - discounting your distorted view of AES, which is different to that held by the program managers at NIST. If you don't believe me check with NIST. Brian Gladman
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: 19 Oct 1999 14:33:35 GMT From: djohn37050@aol.com (DJohn37050) Message-ID: <19991019103335.21360.00000261@ng-bd1.aol.com> References: <7ugui1$26lb@enews2.newsguy.com> Newsgroups: sci.crypt Lines: 5 It was not polite applause, it was a vote on what action, if any, to make as X9F1 to NIST in regards to this issue. And Roger, do you consider yourself a gadfly? Don Johnson
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Tue, 19 Oct 1999 11:06:16 -0700 From: "Roger Schlafly" <real@ieee.org> Message-ID: <7uibrr$12hq@enews1.newsguy.com> References: <19991019103335.21360.00000261@ng-bd1.aol.com> Newsgroups: sci.crypt Lines: 17 DJohn37050 <djohn37050@aol.com> wrote in message news:19991019103335.21360.00000261@ng-bd1.aol.com... > It was not polite applause, it was a vote on what action, if any, to make as > X9F1 to NIST in regards to this issue. So post the text of the motion, if you think it supports your position. Bob S. disputes your description of it. I am not saying everyone on the committee is an idiot. There are some smart cryptographers. However, the committee has made some cryptographically unsound decisions, and I do not think the committee as a whole is a reliable source of opinion on the crypto merits of whether AES should choose a standard.
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Fri, 15 Oct 1999 16:09:57 GMT From: Bob Silverman <bobs@rsa.com> Message-ID: <7u7jk8$o4f$1@nnrp1.deja.com> References: <7u6dgg$fnc@enews3.newsguy.com> <19991014150544.21471.00000152@ng-fg1.aol.com> Newsgroups: sci.crypt Lines: 32 In article <7u6dgg$fnc@enews3.newsguy.com>, "Roger Schlafly" <real@ieee.org> wrote: > DJohn37050 <djohn37050@aol.com> wrote in message > news:19991014150544.21471.00000152@ng-fg1.aol.com... <snip> > > For systems with one alg, they switch over over time. > > > > I know that I MUCH prefer the possibilities of scenario B. > > Not me. > Option B has theoretical appeal, but it would be economically impossible to put into practice. It wouldn't be that hard to implement multiple choices in *software* and assign an OID to transactions so the software can choose the correct algorithm. But hardware vendors are not going to build AES based devices with multiple algorithms. There are too many problems with trying to do so. Especially for embedded devices and low power systems. -- Bob Silverman "You can lead a horse's ass to knowledge, but you can't make him think" Sent via Deja.com http://www.deja.com/ Before you buy.
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: 15 Oct 1999 18:16:08 GMT From: djohn37050@aol.com (DJohn37050) Message-ID: <19991015141608.05892.00000045@ng-co1.aol.com> References: <7u7jk8$o4f$1@nnrp1.deja.com> Newsgroups: sci.crypt Lines: 3 Yes, there will be systems which need to choose just one algorithm, no question about that. Don Johnson
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Sun, 17 Oct 1999 15:52:00 GMT From: ritter@io.com (Terry Ritter) Message-ID: <3809f09b.5250892@news.io.com> References: <7u7jk8$o4f$1@nnrp1.deja.com> Newsgroups: sci.crypt Lines: 37 On Fri, 15 Oct 1999 16:09:57 GMT, in <7u7jk8$o4f$1@nnrp1.deja.com>, in sci.crypt Bob Silverman <bobs@rsa.com> wrote: >In article <7u6dgg$fnc@enews3.newsguy.com>, > "Roger Schlafly" <real@ieee.org> wrote: >> DJohn37050 <djohn37050@aol.com> wrote in message >> news:19991014150544.21471.00000152@ng-fg1.aol.com... > ><snip> > > >> > For systems with one alg, they switch over over time. >> > >> > I know that I MUCH prefer the possibilities of scenario B. >> >> Not me. >> > >Option B has theoretical appeal, but it would be economically >impossible to put into practice. It wouldn't be that hard to >implement multiple choices in *software* and assign an OID to >transactions so the software can choose the correct algorithm. > >But hardware vendors are not going to build AES based devices >with multiple algorithms. Modern "hardware" systems often consist of embedded processors and "firmware" based in flash. The system itself can be designed to choose from an array of acceptable ciphers, and also maintain a list of a cipher *required* in a cipher stack, or *disallowed* due to new information. --- Terry Ritter ritter@io.com http://www.io.com/~ritter/ Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Sun, 17 Oct 1999 19:22:04 -0700 From: "Roger Schlafly" <real@ieee.org> Message-ID: <7ue098$202p@enews3.newsguy.com> References: <3809f09b.5250892@news.io.com> Newsgroups: sci.crypt Lines: 14 Terry Ritter <ritter@io.com> wrote in message news:3809f09b.5250892@news.io.com... > Modern "hardware" systems often consist of embedded processors and > "firmware" based in flash. The system itself can be designed to > choose from an array of acceptable ciphers, and also maintain a list > of a cipher *required* in a cipher stack, or *disallowed* due to new > information. Yes, hardware systems could do that. But I am sure that they would rather devote those resources to something more useful, in most cases.
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Mon, 18 Oct 1999 22:42:51 -0400 From: "Trevor Jackson, III" <fullmoon@aspi.net> Message-ID: <380BDAAB.163461B9@aspi.net> References: <380c77b7.20062887@news.visi.com> <380B0D8A.F4850676@aspi.net> <7ue098$202p@enews3.newsguy.com> Newsgroups: sci.crypt Lines: 84 Bruce Schneier wrote: > On Mon, 18 Oct 1999 08:07:38 -0400, "Trevor Jackson, III" > <fullmoon@aspi.net> wrote: > > >Roger Schlafly wrote: > > > >> Terry Ritter <ritter@io.com> wrote in message > >> news:3809f09b.5250892@news.io.com... > >> > Modern "hardware" systems often consist of embedded processors and > >> > "firmware" based in flash. The system itself can be designed to > >> > choose from an array of acceptable ciphers, and also maintain a list > >> > of a cipher *required* in a cipher stack, or *disallowed* due to new > >> > information. > >> > >> Yes, hardware systems could do that. But I am sure that they > >> would rather devote those resources to something more useful, > >> in most cases. > > > >Something "more useful" than averting the possibility that the entire > >device becomes useless? > > Yes. There are a zillion things more useful than that. In a > cellphone, for example, voice quality is far more important than > encryption. The system will NEVER be designed to choose from an array > of acceptable ciphers; we can't even get a system designed that has a > single marginally acceptable cipher. In a network hardware switching > box, for example, it is more important to be able to make more > connections than it is to have a choice of algorithms. Cisco would > hate having multiple "must have" algorithms in IPsec. In an embedded > stored-value card, every one of our clients would rather field the > system with lousy encryption than add more complexity (and cost) to > the chip. I disagree. I only have a couple of decades of experience designing real systems for real users. Usually without the design or computational platform resources required to do the job, with typically inconsistent requirements, and deadlines that require a zero length design phase and a negative length testing phase. Sound familiar? To a designer options are a Good Thing (I know, I read your previous reply on a parallel thread). The thesis you've advocated is orthogonal to most of the examples you've provided. For instance, there are lots of dynamic issues here. Meaning that the criteria that dominate design and buying decisions evolves over time. Voice quality is the most important property _now_, but that may change. Nota Bene, NEVER is an extremely long time. I don't have the wisdom to determine things that will NEVER happen. Neither do you. In fact a reasonable evolution of cell phones implies that once digital connections are common voice quality will be satisficed and other properties will become the sales determinants because, for the purposes of the average user, all system will have equivalent quality. For networking issues such as IPsec, you've objected that having multiple "must have" ciphers is a problem. Maybe. I disagree but it's a non-issue. It's a non-issue because the true choice has nothing to do with multiple "must haves" but multiple choices from which the designer may pick one, two, or whatever suits the application. Do we really want the same features in a cipher encrypting quadrillions (I'm being conservative) of 48-byte ATM packets as we want for securing gigabyte-size medical record files? I doubt it. Basic point is not to have multiple ciphers in the router, but to have multiple ciphers from which to choose when building the router. Besides, if Cisco isn't willing to support multiple ciphers, I'll be happy to invest in a second or third tier vendor who is willing to support multiple ciphers because they want to beat Cisco. BTW, that investment would be in the form of buying their products not their stock. I vote with my budget. Regularly. As for smart cards, we all know that security is a hassle. Good security is more of a hassle than lousy security. A single AES standard isn't going to change that. Nor will multiple standards make it worse. The issues are independent. > It's a weird world out there, but it is the world we need to design > to. Emphatically yes. And that means there is no possiblility of One True Encryption standard.
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Mon, 18 Oct 1999 21:08:46 -0700 From: "Roger Schlafly" <real@ieee.org> Message-ID: <7ugqpe$23mc@enews2.newsguy.com> References: <380BDAAB.163461B9@aspi.net> Newsgroups: sci.crypt Lines: 14 Trevor Jackson, III <fullmoon@aspi.net> wrote in message news:380BDAAB.163461B9@aspi.net... > Besides, if Cisco isn't willing to support multiple ciphers, I'll be happy to > invest in a second or third tier vendor who is willing to support multiple > ciphers because they want to beat Cisco. What planet do you live on? Cisco is not going out of business because it only offers AES/Rijndahl and the competition is supplementing it with one of the AES rejects.
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Sat, 23 Oct 1999 18:45:09 GMT From: Tim Tyler <tt@cryogen.com> Message-ID: <FK2K39.5wo@bath.ac.uk> References: <380c77b7.20062887@news.visi.com> <380B0D8A.F4850676@aspi.net> <7ue098$202p@enews3.newsguy.com> Newsgroups: sci.crypt Lines: 30 Bruce Schneier <schneier@counterpane.com> wrote: : <fullmoon@aspi.net> wrote: :>Roger Schlafly wrote: [Ritter-style cypher swapping] :>> Yes, hardware systems could do that. But I am sure that they :>> would rather devote those resources to something more useful, :>> in most cases. :> :>Something "more useful" than averting the possibility that the entire :>device becomes useless? : Yes. There are a zillion things more useful than that. In a : cellphone, for example, voice quality is far more important than : encryption. [...] That rather depends on who is owning the cellphone, and where they are using it. : The system will NEVER be designed to choose from an array of : acceptable ciphers; we can't even get a system designed that : has a single marginally acceptable cipher. [...] "NEVER"? That statement is /so/ strong it is almost certain to be wrong. -- __________ |im |yler The Mandala Centre http://www.mandala.co.uk/ tt@cryogen.com Smoking cures weight problems eventually.
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Sun, 24 Oct 1999 07:59:43 -0400 From: "A [Temporary] Dog" <amungedtempdog@munged.see.sig> Message-ID: <qPESOMqnljuoRK3A06DXyrE8amFe@4ax.com> References: <FK2K39.5wo@bath.ac.uk> Newsgroups: sci.crypt Lines: 45 On Sat, 23 Oct 1999 18:45:09 GMT, Tim Tyler <tt@cryogen.com> wrote: >Bruce Schneier <schneier@counterpane.com> wrote: >: <fullmoon@aspi.net> wrote: >:>Roger Schlafly wrote: > >[Ritter-style cypher swapping] > >:>> Yes, hardware systems could do that. But I am sure that they >:>> would rather devote those resources to something more useful, >:>> in most cases. >:> >:>Something "more useful" than averting the possibility that the entire >:>device becomes useless? > >: Yes. There are a zillion things more useful than that. In a >: cellphone, for example, voice quality is far more important than >: encryption. [...] > >That rather depends on who is owning the cellphone, and where they are >using it. Since most of us are stuck with what the mass market will support for cellphones, what any one owner wants is irrelevant. The cellphone marketers have determined that voice quality is more important to a commercially viable phone then good encryption. Good encryption may actually be a detriment if it gets you into a pissing match with government authorities. > >: The system will NEVER be designed to choose from an array of >: acceptable ciphers; we can't even get a system designed that >: has a single marginally acceptable cipher. [...] > >"NEVER"? That statement is /so/ strong it is almost certain to be wrong. Not withstanding Mr. Ritter's comments on reinterpreting the words of others, always read "never" as "for the foreseeable future". - A (Temporary) Dog |"Intelligent, reasonable The Domain is *erols dot com* |people understand that - The Name is tempdog |unfortunately, we're dealing |with elected officials" Put together as name@domain | - name withheld
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Sun, 24 Oct 1999 10:59:23 -0400 From: "Trevor Jackson, III" <fullmoon@aspi.net> Message-ID: <38131ECB.5EC0976D@aspi.net> References: <qPESOMqnljuoRK3A06DXyrE8amFe@4ax.com> Newsgroups: sci.crypt Lines: 20 A [Temporary] Dog wrote: > > > >"NEVER"? That statement is /so/ strong it is almost certain to be wrong. > > Not withstanding Mr. Ritter's comments on reinterpreting the words of > others, always read "never" as "for the foreseeable future". > I don't think so. We aren't using clinton-speak. We (most) are using English. In English never means not ever; and NEVER means not-ever-and-I-really-mean-it! If someone means "for the forseeable future" they might as well say "for the forseeable future". But I doubt the submitter meant FOR THE FORSEEABLE FUTURE, do you?
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Sun, 24 Oct 1999 15:03:09 -0400 From: "A [Temporary] Dog" <amungedtempdog@munged.see.sig> Message-ID: <2FUTOA+l9v4J2Uxo9lnjX3yUVaiy@4ax.com> References: <38131ECB.5EC0976D@aspi.net> Newsgroups: sci.crypt Lines: 33 On Sun, 24 Oct 1999 10:59:23 -0400, "Trevor Jackson, III" <fullmoon@aspi.net> pumped the following load of hot text into sci.crypt: > >A [Temporary] Dog wrote: > >> > >> >"NEVER"? That statement is /so/ strong it is almost certain to be wrong. >> >> Not withstanding Mr. Ritter's comments on reinterpreting the words of >> others, always read "never" as "for the foreseeable future". >> > >I don't think so. We aren't using clinton-speak. We (most) are using >English. In English never means not ever; and NEVER means >not-ever-and-I-really-mean-it! In my experience, people frequently say "never" when they mean "not in the foreseeable future". BTW, we're doing dueling aphorisms here - what's your contribution? - A (Temporary) Dog "Always read sober what you posted drunk. It will teach you to keep your mouth shut" -Earnest Hemingway - A (Temporary) Dog |"Intelligent, reasonable The Domain is *erols dot com* |people understand that - The Name is tempdog |unfortunately, we're dealing |with elected officials" Put together as name@domain | - name withheld
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Thu, 28 Oct 1999 23:37:18 GMT From: Tim Tyler <tt@cryogen.com> Message-ID: <FKC6y6.5LI@bath.ac.uk> References: <2FUTOA+l9v4J2Uxo9lnjX3yUVaiy@4ax.com> Newsgroups: sci.crypt Lines: 28 A [Temporary] Dog <amungedtempdog@munged.see.sig> wrote: : On Sun, 24 Oct 1999 10:59:23 -0400, "Trevor Jackson, III" [wrote:] :>A [Temporary] Dog wrote (quoting me): :>>>"NEVER"? That statement is /so/ strong it is almost certain to be wrong. :>> :>> Not withstanding Mr. Ritter's comments on reinterpreting the words of :>> others, always read "never" as "for the foreseeable future". :> :>I don't think so. We aren't using clinton-speak. We (most) are using :>English. In English never means not ever; and NEVER means :>not-ever-and-I-really-mean-it! : In my experience, people frequently say "never" when they mean "not in : the foreseeable future". [...] These people need to dictionaries for Christmas - it'll probably save them from no end of misunderstandings. People who write "NEVER" - in capital letters - when they /really/ should be saying "maybe sometime, but probably not for a little while" or - as in this case - "very likely someday, but I'm not exactly sure when", really must expect to be queried. -- __________ |im |yler The Mandala Centre http://www.mandala.co.uk/ tt@cryogen.com Escape-Meta-Alt-Ctrl-Shift.
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: 16 Oct 1999 14:24:53 GMT From: djohn37050@aol.com (DJohn37050) Message-ID: <19991016102453.13373.00000023@ng-fe1.aol.com> References: <3807dc4f.0@ecn.ab.ca> Newsgroups: sci.crypt Lines: 6 John, On patent rights for the winner(s), NIST has ALWAYS said there may be one or more winners. It is only some people who choose to restate what NIST actually says to have them saying "NIST will choose a winner." NIST has NEVER said something as simple as that. Don Johnson
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Mon, 18 Oct 1999 19:54:38 GMT From: schneier@counterpane.com (Bruce Schneier) Message-ID: <38107ae3.20874589@news.visi.com> References: <19991016102453.13373.00000023@ng-fe1.aol.com> Newsgroups: sci.crypt Lines: 16 On 16 Oct 1999 14:24:53 GMT, djohn37050@aol.com (DJohn37050) wrote: >John, >On patent rights for the winner(s), NIST has ALWAYS said there may be one or >more winners. It is only some people who choose to restate what NIST actually >says to have them saying "NIST will choose a winner." NIST has NEVER said >something as simple as that. Correct. I remember Miles saying something like "we will choose approximately one winner." Bruce ********************************************************************** Bruce Schneier, President, Counterpane Systems Phone: 612-823-1098 101 E Minnehaha Parkway, Minneapolis, MN 55419 Fax: 612-823-1590 Free crypto newsletter. See: http://www.counterpane.com
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: 18 Oct 1999 20:26:35 GMT From: djohn37050@aol.com (DJohn37050) Message-ID: <19991018162635.21848.00000126@ng-fk1.aol.com> References: <38107ae3.20874589@news.visi.com> Newsgroups: sci.crypt Lines: 4 I recall Miles being very clear on the fact that there might be multiple winners. This is the case in both the official NIST statements and in the presentations/discussions at AES conferences. Don Johnson
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Mon, 18 Oct 1999 22:57:06 -0400 From: "Trevor Jackson, III" <fullmoon@aspi.net> Message-ID: <380BDE02.E1BEEA4D@aspi.net> References: <380f7904.20395734@news.visi.com> <19991014150544.21471.00000152@ng-fg1.aol.com> Newsgroups: sci.crypt Lines: 84 Bruce Schneier wrote: > On 14 Oct 1999 19:05:44 GMT, djohn37050@aol.com (DJohn37050) wrote: > > >Here is 2 slightly different scenarios; > >A) NIST chooses ONE AES algorithm. A few years from now, it is discovered to > >be somewhat weaker than at first thought. A few years after that, it is > >discovered to be much weaker. Now what? > > We deal with the problem when it arises. This is what happened with > DES. It's not great. > > >B) NIST chooses a small number of AES algorithms. For those systems without > >much limitations, they do all the algs. For those systems that are > >constrained, they choose one. > > How do they choose one? Do they pick randomly? Do they pick the one > that happens to meet their performance criteria on their particular > platform? Do you expect them to be able to choose based on > cryptographic considerations? (This is unlikely, since us > cryptographers will have been unable to.) > > You know, I don't mind NIST choosing one algorithm for smart cards, > one for hardware, one for software, etc. (It makes less sense than > choosing one, but it makes some sense.) Then, we could have > algorithms optimized for different platforms. If NIST wanted to do > that, they should have asked for this in the beginning. NIST asked > for a general-purpose cipher, and that's what they got. They didn't > ask for a hardware-optimized cipher, or a smart-card optimized cipher, > or a 32-bit CPU optimized cipher. The Twofish team would have had a > much easier design job if we didn't try to optimize for all platforms. > > It's like requesting a general-purpose design for an automobile. Some > of the submissions would be faster than the other, or have more > storage room. But none of the submissions would be a race car, or a > pickup truck, because the request was for a general-purpose > automobile. This appears to be an extremely important point. Should we then blindly follow this process or should we point out the foolishness it implies. Some situations require 18 wheels, some 24" clearance, and some a gross weight under 2000 lbs. The earlier we adjust the design flaws IN THE CONTEST the better the result of the process will be. Many of the positions taken in the last couple weeks are of the form that one cipher is better than many. Yet it is hard to credit the implications of this concept because it essentially says that one cipher that is lousy at everything is better than a number of ciphers that are optimized for various purposes. Consider that if we had a single cipher with a few logical configuration knobs that could be adjusted to optimize the algorithm for various environments those same monocipher arguments would say we should elimiate all the knobs. I suppose the protests would be even worse "The user might bump a knob by accident and precipitate who knows what disaster!" > > > >Now an algorithm is found to be weaker than > >thought. > > Note that the liklihood of this increases geometically with each > cipher that is chosen. It is least likely to happen if only one > cipher is chosen. > > >Everyone starts to migrate away from it to another of the AES algs. > >The systems that use multiple algs, this is a matter of negoritiation of which > >to use, etc. > > As long as the negotiation process is secure. I believe that most > applications will be as secure as the weakest cipher. > > >For systems with one alg, they switch over over time. > > > >I know that I MUCH prefer the possibilities of scenario B. > > I do not. I think they are much worse. I think they are much worse > cryptographically, and I think they are much worse for performance and > interoperability. I hope that the companies that have to implement > what we give them make their wishes known to NIST. Hmmm. By this logic crypto desparately needs a Bill Gates. A pioneer to revolutionize the market for crypto by selling Really Bad Crypto instead of striving for Really Good Crypto that seems to be the interest in this forum.
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Mon, 18 Oct 1999 23:01:31 -0400 From: "Trevor Jackson, III" <fullmoon@aspi.net> Message-ID: <380BDF0B.DF1D2FD@aspi.net> References: <7ugc24$1ca3@enews4.newsguy.com> <380B9AA0.165A58BD@t-online.de> Newsgroups: sci.crypt Lines: 31 Roger Schlafly wrote: > Mok-Kong Shen <mok-kong.shen@t-online.de> wrote in message > news:380B9AA0.165A58BD@t-online.de... > > On the (presumably reasonable) assumption that the top three > > candidates in the final round are of approximately the same strength, > > I don't see any reason against a random choice from the beginning, > > excepting that other factors like performance can motivate the chooser > > to investigate the matter in more detail. > > You (and the other anti-standard advocates) are living in a dream > world. Systems in the real world are subject to constraints. You > can't just pile on random algorithms and choose randomly without > having substantial costs for doing so. > > You probably also don't see any reason GM shouldn't put 2 > engines in each car. Interesting observation. In fact GM was one of the organizations that dissed hybrid drive designs with similar logic. They claimed that hybrid designs "need two drive systems instead of one!" Of course hybrid designs are far more flexible and will likely be viable long term whereas single system alternates (batteries, hydrogen, alcohol, etc. ) don't seem to be able to make it. Makes you wonder about the possibilites of flexibility and agility available when there are multiple cipher standards, and the constraints a single cipher might place on some applications, making them unviable.
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: 19 Oct 1999 03:37:50 GMT From: djohn37050@aol.com (DJohn37050) Message-ID: <19991018233750.00544.00000291@ng-fj1.aol.com> References: <7ugc24$1ca3@enews4.newsguy.com> Newsgroups: sci.crypt Lines: 3 It is REQUIRED to put 2 independent BRAKE systems in EVERY CAR. This is for safety. Don Johnson
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Tue, 19 Oct 1999 08:01:16 GMT From: bravo.john@usa.net (Johnny Bravo) Message-ID: <380d2528.93234057@news.mpinet.net> References: <19991018233750.00544.00000291@ng-fj1.aol.com> Newsgroups: sci.crypt Lines: 11 On 19 Oct 1999 03:37:50 GMT, djohn37050@aol.com (DJohn37050) wrote: >It is REQUIRED to put 2 independent BRAKE systems in EVERY CAR. This is for >safety. >Don Johnson LOL, not quite the case. If your master cylinder goes, your entire brake system fails. There is no backup for it. Johnny Bravo
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Tue, 19 Oct 1999 15:44:06 GMT From: bravo.john@usa.net (Johnny Bravo) Message-ID: <380c8f2b.120377493@news.mpinet.net> References: <380C6E8A.EF74CCA9@aspi.net> <380d2528.93234057@news.mpinet.net> Newsgroups: sci.crypt Lines: 28 On Tue, 19 Oct 1999 09:13:46 -0400, "Trevor Jackson, III" <fullmoon@aspi.net> wrote: >Johnny Bravo wrote: > >> On 19 Oct 1999 03:37:50 GMT, djohn37050@aol.com (DJohn37050) wrote: >> >> >It is REQUIRED to put 2 independent BRAKE systems in EVERY CAR. This is for >> >safety. >> >Don Johnson >> >> LOL, not quite the case. If your master cylinder goes, your entire brake >> system fails. There is no backup for it. > >Giggle quietly. > >Look for a lever or pedal called the "emergency brake". That is the PARKING brake. How fast can you drive with the brake pedal in your car fully depressed. Now try it with the parking brake, you can easily drive 60+ mph with the parking brake on. Though I don't recommend doing so, due to damage to the brake pads or drums. I would hardly call such an ineffective system a backup. Using the same criteria, the neutral setting is a backup for the engine. Since you can put the car in neutral and push it. Johnny Bravo
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Tue, 19 Oct 1999 09:52:59 +0200 From: Mok-Kong Shen <mok-kong.shen@t-online.de> Message-ID: <380C235B.EA3D3F5B@t-online.de> References: <7ugc24$1ca3@enews4.newsguy.com> <380B9AA0.165A58BD@t-online.de> Newsgroups: sci.crypt Lines: 28 Roger Schlafly wrote: > > Mok-Kong Shen <mok-kong.shen@t-online.de> wrote > > > On the (presumably reasonable) assumption that the top three > > candidates in the final round are of approximately the same strength, > > I don't see any reason against a random choice from the beginning, > > excepting that other factors like performance can motivate the chooser > > to investigate the matter in more detail. > > You (and the other anti-standard advocates) are living in a dream > world. Systems in the real world are subject to constraints. You > can't just pile on random algorithms and choose randomly without > having substantial costs for doing so. > > You probably also don't see any reason GM shouldn't put 2 > engines in each car. On the other hand, you (and some of the one-standard advocates) confound the issue. It is not whether one 'can' or 'cannot' use more than one AES candidates (unless a crypto law forbids that). One just wants NIST, for whose opinion one has a fair amount of respect, to testify that besides the AES winner, which is considered the best, a couple of others are also o.k., so that the question of doubt of strength of these (in case people want to use them e.g. in multiple encryption for whatever reason) is greatly reduced in magnitude. M. K. Shen
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: 19 Oct 99 13:02:54 GMT From: jsavard@ecn.ab.ca () Message-ID: <380c6bfe.0@ecn.ab.ca> References: <380C235B.EA3D3F5B@t-online.de> Newsgroups: sci.crypt Lines: 19 Mok-Kong Shen (mok-kong.shen@t-online.de) wrote: : On the other hand, you (and some of the one-standard advocates) : confound the issue. It is not whether one 'can' or 'cannot' use more : than one AES candidates (unless a crypto law forbids that). One just : wants NIST, for whose opinion one has a fair amount of respect, to : testify that besides the AES winner, which is considered the best, : a couple of others are also o.k., so that the question of doubt of : strength of these (in case people want to use them e.g. in multiple : encryption for whatever reason) is greatly reduced in magnitude. Actually, that's already been done. NIST announced that the NSA had no objections, on grounds of cryptographic strength, to any of the five finalists. Of course, I suppose if you're David A. Scott, you could take that to mean that all five are weak enough for the NSA to break, but I'm not inclined to that interpretation. John Savard
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Tue, 19 Oct 1999 21:58:29 +0200 From: Mok-Kong Shen <mok-kong.shen@t-online.de> Message-ID: <380CCD65.10D58748@t-online.de> References: <380e8a1d.4149945@news.visi.com> <380C235B.EA3D3F5B@t-online.de> Newsgroups: sci.crypt Lines: 51 Bruce Schneier wrote: > > On Tue, 19 Oct 1999 09:52:59 +0200, Mok-Kong Shen wrote: > >On the other hand, you (and some of the one-standard advocates) > >confound the issue. It is not whether one 'can' or 'cannot' use more > >than one AES candidates (unless a crypto law forbids that). One just > >wants NIST, for whose opinion one has a fair amount of respect, to > >testify that besides the AES winner, which is considered the best, > >a couple of others are also o.k., so that the question of doubt of > >strength of these (in case people want to use them e.g. in multiple > >encryption for whatever reason) is greatly reduced in magnitude. > > If this is all you want, I have no problem with it. NIST can choose > an AES winner, and say that the other two (or three, or four) are also > okay. I don't mind. What I want to avoid is having multiple > algorithms in the AES standard, which would require a system to > implement multiple algorithms in order to implement the standard. I > also want to avoid forcing the user to make a choice: having the > standard be A or B. (As I have said, if we cannot make a decision how > to we expect non-cryptographers to.) I am perfectly happy with > secondary algorithms, or runners up, or anything like that. Well, what I believe is a concern of most people that are vehemently discussing with you may be roughly put thus: It is important to have NIST formally declare that a couple of final round candidates are very close to the winner in the selection criteria and that there is nothing against their use as far as cryptological strength is concerned. Simply to have a NIST spokesman say some words in that direction at a press conference is certainly not enough. There has to be formal documentations by NIST of these close runners-ups. Maybe others would object and would like to have something stronger, but in my personal view it seems to be sufficient for the envisaged purpose to have that stuff put as annex to the standard of the AES winner but it should be as detailed as the latter so that all implementations of them could be conforming. (I have personally also nothing against that being put in a seperate official document, be that called standard document or not, if appropriate reference is given to it in the standard of the AES winner.) If that could be achieved, then I believe the market will choose which algorithm to use in particular fields of applications. It is well conceivable that for, say, cell phones one of the runner-ups is more cost effective than the AES winner and hence get widely used in that sector and some vendors will implement multiple algorithms for arbitrary choice by the user either as single algorithm or in cascade. M. K. Shen --------------------- hppt://home.t-online.de/home/mok-kong.shen
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: 20 Oct 1999 13:18:38 GMT From: djohn37050@aol.com (DJohn37050) Message-ID: <19991020091838.15076.00000019@ng-fr1.aol.com> References: <380CCD65.10D58748@t-online.de> Newsgroups: sci.crypt Lines: 3 What I want is for NIST to certify that a few AES algorithms are allowed for federal gov't use. This is their charge and is about all they can say anyway. Don Johnson
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: 19 Oct 1999 14:31:34 GMT From: djohn37050@aol.com (DJohn37050) Message-ID: <19991019103134.21360.00000259@ng-bd1.aol.com> References: <380c6b2f.0@ecn.ab.ca> Newsgroups: sci.crypt Lines: 9 In my AES paper, I used the term future resiliency to mean the ability to not depend on only one algorithm. And the reason I wrote the paper is that the sole winner idea has obvious potential advantages over multiple winners, namely simplicity. And if there was no other presentation, that means the vote was meaningless? These are people with the real money on the wire, they are in inherently conservative. Don Johnson
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Tue, 19 Oct 1999 15:09:45 GMT From: schneier@counterpane.com (Bruce Schneier) Message-ID: <380c880a.3619680@news.visi.com> References: <19991018233622.00544.00000289@ng-fj1.aol.com> <3810ae1e.3043674@news.visi.com> Newsgroups: sci.crypt Lines: 33 On 19 Oct 1999 03:36:22 GMT, djohn37050@aol.com (DJohn37050) wrote: >The very reason to use parallel links is so if one breaks the other might not. Yes. But in computer security systems, one rarely gets that property. The system is as secure as the weakest link. Hence, adding more encryption algorithms necessarily makes the system weaker. Think of the variety of systems proposed in this thread. Someone suggested that a protocol negotiate randomly between multiple algorithms. Use this to protect transactions, or passwords, or most anything. A system like that is as secure as the weakest algorithm. (You can think of it as an extra few key bits choosing an algorithm, and the system has having a large percentage of weak keys.) Someone else suggested that the designers could install one algorithm and a primary, and then have a fail over to a secondary. Now the system is vulnerable to attacks on the fail over mechanism, version rollback attacks, etc. (And why isn't triple-DES okay as a secondary algorithm?) There have been other suggestions of ways to use multiple algorithms. I haven't seen one that works, except when the proposers postulate that performance isn't an issue (which doesn't happen on systems that I work on). I haven't been convinced yet. Bruce ********************************************************************** Bruce Schneier, Counterpane Internet Security, Inc. Phone: 612-823-1098 101 E Minnehaha Parkway, Minneapolis, MN 55419 Fax: 612-823-1590 Free crypto newsletter. See: http://www.counterpane.com
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Tue, 19 Oct 1999 19:59:54 GMT From: jsavard@tenMAPSONeerf.edmonton.ab.ca (John Savard) Message-ID: <380cc370.10587222@news.prosurfr.com> References: <380cb79d.5790473@news.visi.com> <19991019142122.19497.00000029@ng-cm1.aol.com> <380c880a.3619680@news.visi.com> Newsgroups: sci.crypt Lines: 94 schneier@counterpane.com (Bruce Schneier) wrote, in part: >I'm sorry. That sounds more like serial than parallel. In any case, >multiple encryption is fine; I have nothing against it. >Use multiple encryption wherever you want: AES + whatever other >algorithms you choose. But please let AES be one algorithm. For one thing, it should be noted that the multiple-cipher proposal under discussion is intended for people seriously concerned with the secrecy of their messages, even against attacks by powerful adversaries, or attacks in the remote future. It may well be cost-prohibitive for use in, say, preventing someone from taking control of your toaster oven over the Internet, and for that we'll just have to stumble along with an AES-only microchip. I've been *strongly* critical of Terry Ritter for wording some of his posts in ways that imply his multi-ciphering proposal is _everything_, and the confidence we get in ciphers from their study and analysis is _nothing_. Each time he does this, people come away from his posts with the impression that he would be willing to use 100,000 ciphers designed by fifth grade classes, or that he thinks the fact one can't mathematically *prove* a cipher secure means that all ciphers are equally bad. But those impressions _are_ false, as these two examples are issues I raised, and when I raised these issues, he specifically denied that he is making such obvious mistakes. Thus, the negative superficial impression that some of his statements about the importance of his proposal are, in my opinion, making, is to an extent misleading. Looking at his proposal from a technical viewpoint, I do see a sound basic idea present. Serial and parallel encryption both have their roles in the proposal. Parallel encryption by multiple ciphers, by itself, is unsafe because, as correctly pointed out, the strength is roughly on the order of the weakest cipher. (Roughly: only some, not all, messages can be read, and there is less text to work with. And using only one cipher, since cipher strength can't be proven, might be thought of as leaving some nonzero chance that that cipher is, if not the "weakest" (that seems unlikely in the case of the AES, I agree) at least unacceptably weak as the result of an unanticipated future discovery.) Serial encryption is intended to make parallel encryption safe. I've suggested, and emphasized, that the user ought to be able to specify that one of the ciphers in the serial mix should always be from a small set of well-analyzed ciphers. OK, so every possible combination is now "secure" by conventional standards. What does having routines for thousands of different ciphers, less well-analyzed than the "majors", buy you? Why is it worth the trouble? The fact that the algorithms used are now unknown, although the pool from which they are chosen may be known, certainly adds a few bits to the key, but that in itself is not of value: the component ciphers must all meet the criterion that their keys are too long for brute-force attacks to be effective. (Thus, triple-DES, and not DES itself, should be a component cipher.) If brute-force attack is impossible, then an attacker must do "real cryptanalysis". However, every message is in a different - unknown - mix of component ciphers. (Which ciphers are used must be negotiated under very strong encryption, and side attacks based on how long the negotiation took, for example, need to be carefully guarded against.) Hence, there is never enough sample text enciphered by the same group of ciphers - never mind the same key - to carry out attacks such as differential cryptanalysis. Even if one is completely contemptuous of the bulk of the ciphers used in such a system, requiring the use of one "respected" cipher makes it possible to see that even if the bulk of the other ciphers are considered as doing no more than whitening, that is still making things very difficult for the cryptanalyst, because the whitening is quite variable in its algorithmic aspect. In this kind of environment, even if someday easier attacks against all five AES finalists were discovered than those now known against MAGENTA or LUCIFER, someone digging up your old E-mails would likely be utterly unable to read them. The data needed for an attack would be hidden under two other ciphers, and their identity, their position, and their keys would be unknown. (And stream ciphers, such as Panama or RC4, are possible elements in the mix.) Of course, it is still highly controversial whether that high a level of security is worth that much difficulty for very many users, or whether there are not easier and better ways to reach this point. But this still illustrates a valid way to attempt to obtain more secrecy than a single cipher would provide. John Savard ( teneerf<- ) http://www.ecn.ab.ca/~jsavard/crypto.htm
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Tue, 19 Oct 1999 19:30:18 -0600 From: jgfunj@vgrknf.arg (wtshaw) Message-ID: <jgfunj-1910991930190001@dial-243-031.itexas.net> References: <380cc370.10587222@news.prosurfr.com> Newsgroups: sci.crypt Lines: 29 In article <380cc370.10587222@news.prosurfr.com>, jsavard@tenMAPSONeerf.edmonton.ab.ca (John Savard) wrote: > Serial and parallel encryption both have their roles in the proposal. > Parallel encryption by multiple ciphers, by itself, is unsafe because, > as correctly pointed out, the strength is roughly on the order of the > weakest cipher. (Roughly: only some, not all, messages can be read, > and there is less text to work with. And using only one cipher, since > cipher strength can't be proven, might be thought of as leaving some > nonzero chance that that cipher is, if not the "weakest" (that seems > unlikely in the case of the AES, I agree) at least unacceptably weak > as the result of an unanticipated future discovery.) > > Serial encryption is intended to make parallel encryption safe. I've > suggested, and emphasized, that the user ought to be able to specify > that one of the ciphers in the serial mix should always be from a > small set of well-analyzed ciphers. > Perhaps you are making this too difficult, whereas, if you believe that a couple of the ciphers are both good, simply encrypt in both and XOR the bits of output. This should work if the block lengths and key lengths are the same. If either cipher or both are as good as you think, you have to break both to solve the message. If the key is the same to both, things are simpler than if they are different, both to the user and to the attacker. -- Truth lies in your path for you to stumble over, even if you think you can easily sidestep it.
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: 20 Oct 99 06:07:43 GMT From: jsavard@ecn.ab.ca () Message-ID: <380d5c2f.0@ecn.ab.ca> References: <jgfunj-1910991930190001@dial-243-031.itexas.net> Newsgroups: sci.crypt Lines: 15 wtshaw (jgfunj@vgrknf.arg) wrote: : Perhaps you are making this too difficult, whereas, if you believe that a : couple of the ciphers are both good, simply encrypt in both and XOR the : bits of output. This should work if the block lengths and key lengths are : the same. That would be a one-way hash function. Of course, there are ways to do this that will work (cipher block N = encryption 1 of plaintext block N XOR encryption 2 of plaintext block N-1), and that is of interest. But I am not "making" anything; what I've described - albeit with emphasis on the precautions I think are important - is Terry Ritter's proposal, not mine. John Savard
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Wed, 20 Oct 1999 13:32:04 -0600 From: jgfunj@vgrknf.arg (wtshaw) Message-ID: <jgfunj-2010991332050001@dial-243-005.itexas.net> References: <380d5c2f.0@ecn.ab.ca> Newsgroups: sci.crypt Lines: 24 In article <380d5c2f.0@ecn.ab.ca>, jsavard@ecn.ab.ca () wrote: > wtshaw (jgfunj@vgrknf.arg) wrote: > : Perhaps you are making this too difficult, whereas, if you believe that a > : couple of the ciphers are both good, simply encrypt in both and XOR the > : bits of output. This should work if the block lengths and key lengths are > : the same. > > That would be a one-way hash function. Of course, there are ways to do > this that will work (cipher block N = encryption 1 of plaintext block N > XOR encryption 2 of plaintext block N-1), and that is of interest. That is the way of course, to keep things decipherable. You could use the method I suggested to prove authorship, since only you know the one or, best yet, two keys. > > But I am not "making" anything; what I've described - albeit with emphasis > on the precautions I think are important - is Terry Ritter's proposal, not > mine. > > John Savard -- Truth lies in your path for you to stumble over, even if you think you can easily sidestep it.
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Wed, 20 Oct 1999 08:56:53 +0100 From: "Brian Gladman" <gladman@seven77.demon.co.uk> Message-ID: <940406238.7557.0.nnrp-07.c2de6a96@news.demon.co.uk> References: <380c880a.3619680@news.visi.com> Newsgroups: sci.crypt Lines: 92 Bruce Schneier <schneier@counterpane.com> wrote in message news:380c880a.3619680@news.visi.com... > On 19 Oct 1999 03:36:22 GMT, djohn37050@aol.com (DJohn37050) wrote: > > >The very reason to use parallel links is so if one breaks the other might not. > > Yes. But in computer security systems, one rarely gets that property. > The system is as secure as the weakest link. Hence, adding more > encryption algorithms necessarily makes the system weaker. If implemented correctly, sequential encryption using different algorithms can provide protection in a situation where one of the algorithms being used contains an as yet undiscovered weakness. This is a reasonable 'defence in depth' tactic where there is a long term security requirement (decades) or where it is known that a system will be specifically targetted by a very patient and well resourced enemy who is prepared to spend years studying the algorthm(s) involved for any possible weakness. Historically these sorts of requirements have typically been in the defence, intelligence or espionage fileds but as we push towards the widespread use of encryption I can foresee a number of civil applications of encryption that will involve these sorts of needs. In addition to sequential encryption there are other forms of composition (of two algorithms) that require an enemy to break both algorithms rather than either of them in order to penetrate a system. For example a key can be generated by xoring two component keys and the latter can be sent to a user encrypted with different algorithms. In some sorts of system particular keys are more ciritical than others and it can therefore make sense to be ultra cautious about their security. Such techniques are often important in highly critical applications such as cryptographic key > Think of the variety of systems proposed in this thread. Someone > suggested that a protocol negotiate randomly between multiple > algorithms. Use this to protect transactions, or passwords, or most > anything. A system like that is as secure as the weakest algorithm. > (You can think of it as an extra few key bits choosing an algorithm, > and the system has having a large percentage of weak keys.) Yes, I am inclined to agree that many of the ideas put forward here are likely to end up reducing security rather than increasing it because of the overall system complexity involved. But some of the simpler methods of composing ciphers are useful in meeting a range of critical security requrements so I don't think these ideas are undermined simply because more adventurous ideas have been discussed. > Someone else suggested that the designers could install one algorithm > and a primary, and then have a fail over to a secondary. Now the > system is vulnerable to attacks on the fail over mechanism, version > rollback attacks, etc. (And why isn't triple-DES okay as a secondary > algorithm?) > There have been other suggestions of ways to use multiple algorithms. > I haven't seen one that works, except when the proposers postulate > that performance isn't an issue (which doesn't happen on systems that > I work on). Usually what matters is overall system performance and here there are many systems where the performance of the block cipher employed will not have a major impact on the overall system performance. I agree that block encryption speed will often be important in securing the lower protocol layers but there are uses of encryption at the applications layer that have the opposite properties. Here the speed of the block encryption will often have very little impact on overall system performance but the protection requirement may either be long term or alternatively so critical to the security of the system as a whole that an extra degree of safety is worthwhile. I do not think it is unreasonable to seek an AES outcome that accommodates both these requirement domains. One of the difficulties with AES is that the IPR issues may dictate that AES algorithms have to be declared 'winners' in order that they can be used freely whereas all we really need is more than one algorithm to come through with some sort of formal status. I don't have a problem with one winner and 1 or 2 backup algorithms or algorithm ranking but I am unclear whether the rules of the AES competition will allow these forms of result in respect of MARS and RC6 without declaring them 'winners'. But I would have thought that such constraints might be removed if necessary. In the limit, if RC6 and MARS are not available as 2nd and 3rd place AES algorithms, we then have Rijndael, Serpent and Twofish since these are not IPR constrained. Not necessarily a bad outcome. Brian Gladman
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Wed, 20 Oct 1999 11:32:34 +0200 From: Mok-Kong Shen <mok-kong.shen@t-online.de> Message-ID: <380D8C32.F96649DF@t-online.de> References: <940406238.7557.0.nnrp-07.c2de6a96@news.demon.co.uk> Newsgroups: sci.crypt Lines: 50 Brian Gladman wrote: > > Usually what matters is overall system performance and here there are many > systems where the performance of the block cipher employed will not have a > major impact on the overall system performance. I agree that block > encryption speed will often be important in securing the lower protocol > layers but there are uses of encryption at the applications layer that have > the opposite properties. Here the speed of the block encryption will often > have very little impact on overall system performance but the protection > requirement may either be long term or alternatively so critical to the > security of the system as a whole that an extra degree of safety is > worthwhile. > > I do not think it is unreasonable to seek an AES outcome that accommodates > both these requirement domains. Very well said. Nothing in the world, not even AES, can fit all. > > One of the difficulties with AES is that the IPR issues may dictate that AES > algorithms have to be declared 'winners' in order that they can be used > freely whereas all we really need is more than one algorithm to come through > with some sort of formal status. I don't have a problem with one winner and > 1 or 2 backup algorithms or algorithm ranking but I am unclear whether the > rules of the AES competition will allow these forms of result in respect of > MARS and RC6 without declaring them 'winners'. > > But I would have thought that such constraints might be removed if > necessary. In the limit, if RC6 and MARS are not available as 2nd and 3rd > place AES algorithms, we then have Rijndael, Serpent and Twofish since these > are not IPR constrained. Not necessarily a bad outcome. Has anybody made serious thought of the possibility of extracting some of the good ideas from each submitted AES candidate and doing some variations (to avoid patent problems) and putting in some proper ideas of one's own to arrive at a new design? I mean one certainly can learn from each something useful. In the field of programming languages, the design of (the now time-honoured) PL/I is something analogous to this. I know well that PL/I has been heavily criticized at that time by some 'theoreticians' of computer science as being a monstrous conglomerate that is difficult to learn, etc. etc. But PL/I did later have a sizable user community and is still in use today, if I don't err. (Even in retrospect now after decades I personally still can't agree with more than 10% of the arguments offered by the 'theoreticians'.) So I think the idea indicated might be practicable for some clever minds. M. K. Shen ------------------------- http://home.t-online.de/home/mok-kong.shen
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Wed, 20 Oct 1999 15:18:14 +0100 From: "Brian Gladman" <gladman@seven77.demon.co.uk> Message-ID: <940429167.19519.0.nnrp-12.c2de6a96@news.demon.co.uk> References: <380D8C32.F96649DF@t-online.de> Newsgroups: sci.crypt Lines: 49 Mok-Kong Shen <mok-kong.shen@t-online.de> wrote in message news:380D8C32.F96649DF@t-online.de... > Brian Gladman wrote: > > > > I do not think it is unreasonable to seek an AES outcome that accommodates > > both these requirement domains. > > Very well said. Nothing in the world, not even AES, can fit all. Thank you for your kind words. > > But I would have thought that such constraints might be removed if > > necessary. In the limit, if RC6 and MARS are not available as 2nd and 3rd > > place AES algorithms, we then have Rijndael, Serpent and Twofish since these > > are not IPR constrained. Not necessarily a bad outcome. > > Has anybody made serious thought of the possibility of extracting > some of the good ideas from each submitted AES candidate and doing > some variations (to avoid patent problems) and putting in some > proper ideas of one's own to arrive at a new design? I mean one Although its quite possible that a better cipher might be constructed by combining the techniques used in the AES algorithms in different ways, I am rather uncertain that those who have the knowledge to do this would want to repeat the process of algorithm development just undertaken for AES all over again. Moreover, as an outsider to the field of cipher design, I have the impression that the problem here is not so much how to jumble things up but rather that of knowing whether the result is secure. I hence suspect that more work on the cryptanalysis of the five AES finalists in their current form may be more effective in improving algorithm security than the synthesis of new algorithms right now. But on a related point, while a block cipher can be turned into a stream cipher in a number of ways, will a better stream cipher result if one is designed from scratch as a stream cipher? And, if the answer is yes, why is there not an AES effort towards a standard stream cipher? Are they less amenable to standardisation? Brian Gladman
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: 20 Oct 1999 17:02:43 GMT From: djohn37050@aol.com (DJohn37050) Message-ID: <19991020130243.13073.00000098@ng-fa1.aol.com> References: <940429167.19519.0.nnrp-12.c2de6a96@news.demon.co.uk> Newsgroups: sci.crypt Lines: 14 I think the reason to standardize on a block cipher are: 1) A mode can turn it into a stream cipher, if needed. 2) A stream cipher allows manipulation of individual bits. This in turn can have negative consequences. I may not know how Joe votes, but I just want to negate him, so I just flip the bit. I know a money field goes to 10,000 but the thousands number is often zero, etc. And integrity methods can solve some of these concerns. 3) A stream cipher requires synchronization to be treated as a security issue, a two-time pad should be considered insecure. This is often ignored in "perfect" security analyses (after all, OTP is "perfect"), but is a real world issue. If I can get you to resync in the wrong place in the text stream, you can be hosed. Don Johnson
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: 20 Oct 1999 12:49:09 -0600 From: vjs@calcite.rhyolite.com (Vernon Schryver) Message-ID: <7ul2r5$rd1$1@calcite.rhyolite.com> References: <19991020130243.13073.00000098@ng-fa1.aol.com> Newsgroups: sci.crypt Lines: 54 In article <19991020130243.13073.00000098@ng-fa1.aol.com>, DJohn37050 <djohn37050@aol.com> wrote: >I think the reason to standardize on a block cipher are: > ... >3) A stream cipher requires synchronization to be treated as a security issue, >a two-time pad should be considered insecure. This is often ignored in >"perfect" security analyses (after all, OTP is "perfect"), but is a real world >issue. If I can get you to resync in the wrong place in the text stream, you >can be hosed. Yes, "in theory there is no difference between theory and practice, but in practice there is." Those who advocate run-time negotating ciphers should look at real world protocols. All protocols that involve the parties agreeing on one choice out of two or more alternatives have major problems in the real world. A wonderful (so to speak) case study is PPP. PPP based on essentially everything being negotiated, including encryption mechanisms. In theory, it should all work fine. In theory, the two PPP peers will exchange Configure-Request, -Nak, and -Ack LCP or NCP packets until they've agreed, and then things will just work. In practice, that's a sick joke. For example, consider the simple, basic 10+ year old PPP authentication mechanisms. Originally (or nearly so) there were two schemes, CHAP and PAP. In theory, the peers would exchange LCP packets to negotiate which peer(s) need(s) authentication of the other, and then the packets would be exchanged. In practice, at least 50% of PPP implementations get it wrong even after private tests with other implementations. At least 40% never get it right. If they have small marketshare, they simply don't work in various situations with various peers until (and unless) they fix their bugs. If they have large marketshare (e.g. Microsoft and Ascend), everyone else does whatever is necessary to accomodate their bugs. Then consider Microsoft's "improvement" to CHAP, besides their early bugs (e.g. -Nak vs. -Rej for PAP). Microsoft came up with MS-CHAP as supposedly more secure than standard PAP and CHAP. In fact, it is in theory strictly less secure and in practice about the same. More recently Microsoft came up with MS-CHAPv2, which is incompatible, slightly less insecure, but still fundamentally defective. These problems with PAP, CHAP, MS-CHAP, and MS-CHAPv2 are not ancient. MS-CHAPv2 is fairly new. Today, when your PPP code encounters a new PPP implementation, you can expect to receive complaints about PAP and CHAP. Finally, for the point that implementation details matter a lot and probably more than the encryption theory, consider that IETF standard CHAP and PAP were implemented by big vendors in ways that allow someone who knows the tricks to immediately cause the authenticator into handing over information needed to log in, including in one mode, a clear-text password. Vernon Schryver vjs@rhyolite.com
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Wed, 20 Oct 1999 23:51:18 GMT From: ritter@io.com (Terry Ritter) Message-ID: <380e5567.3599851@news.io.com> References: <7ul2r5$rd1$1@calcite.rhyolite.com> Newsgroups: sci.crypt Lines: 42 On 20 Oct 1999 12:49:09 -0600, in <7ul2r5$rd1$1@calcite.rhyolite.com>, in sci.crypt vjs@calcite.rhyolite.com (Vernon Schryver) wrote: >In article <19991020130243.13073.00000098@ng-fa1.aol.com>, >DJohn37050 <djohn37050@aol.com> wrote: >>I think the reason to standardize on a block cipher are: > >> ... >>3) A stream cipher requires synchronization to be treated as a security issue, >>a two-time pad should be considered insecure. This is often ignored in >>"perfect" security analyses (after all, OTP is "perfect"), but is a real world >>issue. If I can get you to resync in the wrong place in the text stream, you >>can be hosed. > >Yes, "in theory there is no difference between theory and practice, but >in practice there is." > >Those who advocate run-time negotating ciphers should look at real world >protocols. All protocols that involve the parties agreeing on one choice >out of two or more alternatives have major problems in the real world. >A wonderful (so to speak) case study is PPP. PPP based on essentially >everything being negotiated, including encryption mechanisms. In theory, >it should all work fine. In theory, the two PPP peers will exchange >Configure-Request, -Nak, and -Ack LCP or NCP packets until they've agreed, >and then things will just work. In practice, that's a sick joke. Those who criticize run-time negotiation of ciphers should look at real-world modems. Modern modems have many modes, speeds, and parameters, and yet do manage to exchange them in real time to good effect. The ideal for ciphers, however, would be to have lists of acceptable ciphers and negotiate agreement in the background. What is needed *is* a single standard -- for the negotiation and selection of arbitrary ciphers. --- Terry Ritter ritter@io.com http://www.io.com/~ritter/ Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: 20 Oct 1999 19:10:51 -0600 From: vjs@calcite.rhyolite.com (Vernon Schryver) Message-ID: <7ulp6r$585$1@calcite.rhyolite.com> References: <380e5567.3599851@news.io.com> Newsgroups: sci.crypt Lines: 89 In article <380e5567.3599851@news.io.com>, Terry Ritter <ritter@io.com> wrote: > >On 20 Oct 1999 12:49:09 -0600, in <7ul2r5$rd1$1@calcite.rhyolite.com>, >in sci.crypt vjs@calcite.rhyolite.com (Vernon Schryver) wrote: > ... >Those who criticize run-time negotiation of ciphers should look at >real-world modems. Modern modems have many modes, speeds, and >parameters, and yet do manage to exchange them in real time to good >effect. How can you point to modems as a good example of the wonders of negotiating protocols? I think the politics and sausage warning applies. v.32, v.32bis, v.42, v.42bis, v.34, and v.90 modems have only a fairly small set of parameters to negotiate, and a lot of what they do is less "negotiating" than "let's send this stuff and see if it works; if it doesn't then try the next thing on the list." And even that "negotiating" is heavily supplemented by "have the user configure things so that litte needs to be or can be negotiated." Sending probing tones and packets might work in negotiating ciphers, but not without obvious security problems that would need careful thought to fix. In support my PPP efforts, I made a hobby of collecting pairs of new Telebit, v.32, v.32bis, v.34, etc. modems (new at the time). That was to maintain a bunch of scripts for configuring the modems, and to see how they worked. For decades before that, I always seemed to be involved with modems of one sort or another. Hearing someone imply that modem negotiating is now or has ever been clean is ... well ... amazing. sheesh--haven't you noticed that the trade rags and popular press are still warning people to get "real" v.90 modems, today, how many years after that battle was officially over? Double sheesh!--recent versions of Windows no longer have 5000 brands and types of modems to choose among, but that is a recent change. I suspect that is less a sign that modem negotiating is finally working well than the radical reduction in the number of modem vendors to a small handful that can talk to each other behind the scenes. >The ideal for ciphers, however, would be to have lists of acceptable >ciphers and negotiate agreement in the background. Let's see, the parallel words for PPP are "The idea of PPP, howwer, is to have lists of acceptable parameters including for authentication, and negotiate agreement." I'm probably what passes for a PPP expert (among other, more sane and useful things, thank god). My expert assessement, which I'm confident that the other sane, long term technical participants in the IETF PPP WG would echo, is that the idea didn't work out quite as well as we all hoped and expected. I bet even the big software company pointy haired participants would endorse that phrasing. I don't understand the "background" bit about cipher negotiating, since for all of modems, PPP, and ciphers, until the parties agree, the main event cannot work, and that's not exactly "background"...well, not exactly for PPP, which, for example has the CCP (comopression) which is supposed to be negotiated in parallel with the main NCP's, which can start sending data before CCP converges. That is what the PPP implementations I've worked on do, but plenty of others don't. Again, theory vs. practice. >What is needed *is* a single standard -- for the negotiation and >selection of arbitrary ciphers. If the words "What is needed *is* a single standard -- for the negotiation and selection of arbitrary serial link parameters." were not said 100 times around the IETF in about 1987 and 1988 about what became PPP, then exact equivalents were said. In fact, PPP fits the bill quite well. However, no one who is a real designer can fail to learn about negotiating and selecting arbitrary ciphers or anything else from the example of PPP. Not that the lessons surprise anyone with real world technical design experience with protocols that involve much negotiating. The main lesson is "if you possibly can, DON'T!" Other good (i.e. bad) examples of the inevitable perils of negotiating besides modems and PPP include TCP and HTTP. Most don't know about about MSS/PMTU or window size problems, but most people have seen "broken" web pages that don't work on some versons of some browsers. Vernon Schryver vjs@rhyolite.com
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Sat, 23 Oct 1999 18:39:27 GMT From: ritter@io.com (Terry Ritter) Message-ID: <3812005b.8360995@news.io.com> References: <7ulp6r$585$1@calcite.rhyolite.com> Newsgroups: sci.crypt Lines: 155 On 20 Oct 1999 19:10:51 -0600, in <7ulp6r$585$1@calcite.rhyolite.com>, in sci.crypt vjs@calcite.rhyolite.com (Vernon Schryver) wrote: >In article <380e5567.3599851@news.io.com>, Terry Ritter <ritter@io.com> wrote: >> >>On 20 Oct 1999 12:49:09 -0600, in <7ul2r5$rd1$1@calcite.rhyolite.com>, >>in sci.crypt vjs@calcite.rhyolite.com (Vernon Schryver) wrote: > >> ... >>Those who criticize run-time negotiation of ciphers should look at >>real-world modems. Modern modems have many modes, speeds, and >>parameters, and yet do manage to exchange them in real time to good >>effect. > >How can you point to modems as a good example of the wonders of negotiating >protocols? I think the politics and sausage warning applies. I think the real world applies: We have such modems. We use them. They work. End of story. >v.32, v.32bis, v.42, v.42bis, v.34, and v.90 modems have only a fairly >small set of parameters to negotiate, and a lot of what they do is less >"negotiating" than "let's send this stuff and see if it works; if it >doesn't then try the next thing on the list." And even that "negotiating" >is heavily supplemented by "have the user configure things so that litte >needs to be or can be negotiated." Sending probing tones and packets >might work in negotiating ciphers, but not without obvious security >problems that would need careful thought to fix. > >In support my PPP efforts, I made a hobby of collecting pairs of new >Telebit, v.32, v.32bis, v.34, etc. modems (new at the time). That was to >maintain a bunch of scripts for configuring the modems, and to see how >they worked. For decades before that, I always seemed to be involved with >modems of one sort or another. Hearing someone imply that modem >negotiating is now or has ever been clean is ... well ... amazing. I doubt I implied that modem negotiation is "clean." But it *is* "background," and it *is* negotiation (both sides participate in the final result), and it *is* "real world" -- it generally works in practice. Cipher negotiation can be far cleaner -- provided a single selection mechanism is standardized. If not, then we may see the same sort of ad hoc stuff we saw with modems. >[...] >>The ideal for ciphers, however, would be to have lists of acceptable >>ciphers and negotiate agreement in the background. > >Let's see, the parallel words for PPP are > "The idea of PPP, howwer, is to have lists of acceptable parameters > including for authentication, and negotiate agreement." >I'm probably what passes for a PPP expert (among other, more sane and >useful things, thank god). My expert assessement, which I'm confident >that the other sane, long term technical participants in the IETF PPP WG >would echo, is that the idea didn't work out quite as well as we all hoped >and expected. I bet even the big software company pointy haired >participants would endorse that phrasing. I would say, "let's not do it like PPP." >I don't understand the "background" bit about cipher negotiating, since >for all of modems, PPP, and ciphers, until the parties agree, the main >event cannot work, and that's not exactly "background" Indeed, you do not understand the term "background," presumably because you have not done your homework. I suggest actually reading messages before disparaging their ideas. You might also look into my recent article in IEEE Computer: http://www.io.com/~ritter/ARTS/R8INTW1.PDF or the previous discussion, which I have archived on my pages: http://www.io.com/~ritter/NEWS4/LIMCRYPT.HTM Here, "background" approximately means "not apparent to the user." That is just what modem negotiation is about, although we may hear modems, and need not hear or see cipher negotiation. To start any conversation in cipher, it is currently necessary to acquire common keys. Everyone understands this. So everyone should be well prepared to understand that we can *also* acquire a cipher name, or even a cipher itself, in the same way, through the same channel. This is not a big conceptual leap. Once we have a conversation in cipher, we can assign part of it to a "control channel," where negotiation takes place (generally, although not necessarily) hidden from the user. That would be "background" cipher negotiation. Because the need is to change ciphers frequently, the desired negotiation process is not one-time at the start, but rather, a frequent or continuous process in different messages or sessions. >...well, not exactly >for PPP, which, for example has the CCP (comopression) which is supposed to >be negotiated in parallel with the main NCP's, which can start sending >data before CCP converges. That is what the PPP implementations I've >worked on do, but plenty of others don't. Again, theory vs. practice. I am a working engineer. Theory vs. practice. >>What is needed *is* a single standard -- for the negotiation and >>selection of arbitrary ciphers. > >If the words > "What is needed *is* a single standard -- for the negotiation and > selection of arbitrary serial link parameters." >were not said 100 times around the IETF in about 1987 and 1988 about what >became PPP, then exact equivalents were said. In fact, PPP fits the bill >quite well. However, no one who is a real designer can fail to learn >about negotiating and selecting arbitrary ciphers or anything else from the >example of PPP. Well, since you are a "real designer," I'll just let you wander on in your monomanical tirade, while I suggest that we *not* do things like PPP. >Not that the lessons surprise anyone with real world technical design >experience with protocols that involve much negotiating. The main lesson >is "if you possibly can, DON'T!" There is no other possibility, unless you wish to depend upon the strength of a cipher which explicitly HAS *no* known or guaranteed strength. Not having strength is not a trivial detail, this is the essence of the reason for using a cipher. The ability to change ciphers offers each of us the power to choose what cipher we want to use. This means no government organization is edicting our use, or forcing it through market pressure. We get to choose what to use, and what not to use, and to change our minds on a daily basis. That is not a trivial advantage. >Other good (i.e. bad) examples of the inevitable perils of negotiating >besides modems and PPP include TCP and HTTP. Most don't know about >about MSS/PMTU or window size problems, but most people have seen >"broken" web pages that don't work on some versons of some browsers. Gosh, I think we'll just have to have a complete specification. --- Terry Ritter ritter@io.com http://www.io.com/~ritter/ Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Sat, 23 Oct 1999 12:52:11 -0700 From: "Roger Schlafly" <real@ieee.org> Message-ID: <7ut3kq$2sln@enews3.newsguy.com> References: <3812005b.8360995@news.io.com> Newsgroups: sci.crypt Lines: 17 Terry Ritter <ritter@io.com> wrote in message news:3812005b.8360995@news.io.com... > Cipher negotiation can be far cleaner -- provided a single selection > mechanism is standardized. If not, then we may see the same sort of > ad hoc stuff we saw with modems. > ... > Gosh, I think we'll just have to have a complete specification. I don't think NIST was planning on standardizing a cipher negotiation protocol -- at least not at this stage of AES. I also don't think that such a standard would placate critics like Don Johnson. He would say that the protocol may have unknown weaknesses, and people ought to be able to substitute their own ad-hoc protocols.
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Sat, 23 Oct 1999 23:11:14 GMT From: ritter@io.com (Terry Ritter) Message-ID: <38124042.24656067@news.io.com> References: <7ut3kq$2sln@enews3.newsguy.com> Newsgroups: sci.crypt Lines: 30 On Sat, 23 Oct 1999 12:52:11 -0700, in <7ut3kq$2sln@enews3.newsguy.com>, in sci.crypt "Roger Schlafly" <real@ieee.org> wrote: >Terry Ritter <ritter@io.com> wrote in message >news:3812005b.8360995@news.io.com... >> Cipher negotiation can be far cleaner -- provided a single selection >> mechanism is standardized. If not, then we may see the same sort of >> ad hoc stuff we saw with modems. >> ... >> Gosh, I think we'll just have to have a complete specification. > >I don't think NIST was planning on standardizing a cipher negotiation >protocol -- at least not at this stage of AES. I also don't think that >such a standard would placate critics like Don Johnson. He would >say that the protocol may have unknown weaknesses, and people >ought to be able to substitute their own ad-hoc protocols. I see no reason why the negotiation protocol must be "cryptographic," other than in the sense that it will handle cryptographic objects (ciphers). Negotiation should occur under the skirts of the current cipher(s), and so can be an ordinary give and take. The process certainly could be exposed to the party at either end. The negotiation protocol can afford to have some weaknesses. --- Terry Ritter ritter@io.com http://www.io.com/~ritter/ Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: 26 Oct 1999 11:39:30 -0700 From: daw@blowfish.isaac.cs.berkeley.edu (David Wagner) Message-ID: <7v4sh2$ps2$1@blowfish.isaac.cs.berkeley.edu> References: <38124042.24656067@news.io.com> Newsgroups: sci.crypt Lines: 38 In article <38124042.24656067@news.io.com>, Terry Ritter <ritter@io.com> wrote: > I see no reason why the negotiation protocol must be "cryptographic," > other than in the sense that it will handle cryptographic objects > (ciphers). [...] The > negotiation protocol can afford to have some weaknesses. If you have a non-cryptographic negotiation protocol, you might end up with the weakest of the ciphers supported by both ends, rather than the strongest of them. The SSL 2.0 ciphersuite negotiation protocol is a good case in point. The client (Alice) sent the list of ciphersuites supported in her implementation; the server (Bob) picked the first one from that list that is also supported in his implementation, and both ends started using the cipher picked by Bob. Thus, an example protocol run might look something like this: Alice -> Bob: RC4, DES, IDEA, Triple-DES, RC4-40-export, ... Bob -> Alice: IDEA The problem is that there are severe attacks on the SSL 2.0 protocol, due to the non-cryptographic nature of the negotiation protocol. For instance, an active attacker (a "man-in-the-middle") can edit Alice's list of supported ciphers, removing all but the weakest one supported by both endpoints (e.g., RC4-40-export); then Bob will be forced to pick that weak one, and both ends will use the weak cipher. Even if both endpoints support a stronger cipher, they won't know that they've been silently forced down to "least-common-denominator security". Specifically, in SSL 2.0, even if both the client and the server support strong non-exportable cryptography, they can be undetectably forced to use weak exportable (40-bit) crypto for their communications. In general, it is quite a challenge to design a general, secure, and practical protocol for cipher negotiation that resists these attacks. This illustrates the risk of cipher negotation: you might end up with the _weakest_ of the available ciphers, and thus you'd better be very sure that every cipher you support is strong enough for all purposes.
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Tue, 26 Oct 1999 20:10:45 GMT From: dscott@networkusa.net (SCOTT19U.ZIP_GUY) Message-ID: <7v4ubn$q1g$1@news.gate.net> References: <7v4sh2$ps2$1@blowfish.isaac.cs.berkeley.edu> Newsgroups: sci.crypt Lines: 55 In article <7v4sh2$ps2$1@blowfish.isaac.cs.berkeley.edu>, daw@blowfish.isaac.cs.berkeley.edu (David Wagner) wrote: >In article <38124042.24656067@news.io.com>, Terry Ritter <ritter@io.com> wrote: >> I see no reason why the negotiation protocol must be "cryptographic," >> other than in the sense that it will handle cryptographic objects >> (ciphers). [...] The >> negotiation protocol can afford to have some weaknesses. > >If you have a non-cryptographic negotiation protocol, you might end >up with the weakest of the ciphers supported by both ends, rather than >the strongest of them. > >The SSL 2.0 ciphersuite negotiation protocol is a good case in point. >The client (Alice) sent the list of ciphersuites supported in her >implementation; the server (Bob) picked the first one from that list >that is also supported in his implementation, and both ends started >using the cipher picked by Bob. Thus, an example protocol run might >look something like this: > Alice -> Bob: RC4, DES, IDEA, Triple-DES, RC4-40-export, ... > Bob -> Alice: IDEA > >The problem is that there are severe attacks on the SSL 2.0 protocol, >due to the non-cryptographic nature of the negotiation protocol. For >instance, an active attacker (a "man-in-the-middle") can edit Alice's >list of supported ciphers, removing all but the weakest one supported >by both endpoints (e.g., RC4-40-export); then Bob will be forced to >pick that weak one, and both ends will use the weak cipher. Even if >both endpoints support a stronger cipher, they won't know that they've >been silently forced down to "least-common-denominator security". > >Specifically, in SSL 2.0, even if both the client and the server >support strong non-exportable cryptography, they can be undetectably >forced to use weak exportable (40-bit) crypto for their communications. > >In general, it is quite a challenge to design a general, secure, and >practical protocol for cipher negotiation that resists these attacks. > >This illustrates the risk of cipher negotation: you might end up with >the _weakest_ of the available ciphers, and thus you'd better be very >sure that every cipher you support is strong enough for all purposes. This is why organizations should not trust browsers to automatically encrypt there data before it is sent out on the net. People if possible should encrypt and decrypt there data in files off line of sending it over the web so that no automatic handshaking could occur that would allow for a weak encryption method. David A. Scott -- SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE http://www.jim.com/jamesd/Kong/scott19u.zip http://members.xoom.com/ecil/index.htm NOTE EMAIL address is for SPAMERS
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Tue, 26 Oct 1999 21:54:03 GMT From: jsavard@tenMAPSONeerf.edmonton.ab.ca (John Savard) Message-ID: <3816204b.4599691@news.prosurfr.com> References: <7v4sh2$ps2$1@blowfish.isaac.cs.berkeley.edu> Newsgroups: sci.crypt Lines: 58 daw@blowfish.isaac.cs.berkeley.edu (David Wagner) wrote, in part: >This illustrates the risk of cipher negotation: you might end up with >the _weakest_ of the available ciphers, and thus you'd better be very >sure that every cipher you support is strong enough for all purposes. I have to agree with that statement, it is undeniably true. However, while I can't defend Terry Ritter's multi-ciphering proposal from every criticism that has been levelled at it (perhaps it is cumbersome and impractical, perhaps the effort involved is not worth it for the security improvement it can bring - because the improvement in security is not that badly needed, not because the improvement would only be a small one) I must note that this is a condition that *can* be achieved with this kind of system. - The minimum required complement of ciphers would include the AES and Triple-DES, which are accepted as strong. No weak ciphers are among those required to be included. - The choice is not between multiple ciphers to be employed singly, but between multiple ciphers to be employed in each of three layers of encryption. - I've suggested that such a system should incorporate the feature of allowing the user to select a smaller core set of "quality" ciphers at least one of which is to be incorporated in any set of three ciphers used. Provided that the negotiation of ciphers is protected by encryption, even if the protocol is not elaborate, as long as the key for that encryption had been authenticated by normal means, determining what ciphers are used, or forcing a particular cipher to be used, should not be possible. If that is the case, then there is one way in which the system will be stronger than the weakest cipher used. A cipher that can be easily broken with a large amount of known plaintext enciphered under a single key still often cannot be broken on the basis of a single message. As communications here are in the form of individual messages, each with their own complement of ciphers as well as their own key, and any weak ciphers, if they are used, are never used alone, the presence of some weak ciphers in the mix is no longer automatically fatal. By making the use of a "strong" cipher mandatory, as I've advocated, if worst comes to worst the weak ciphers are still adding to strength, by supplying whitening, at the least, for the strong ciphers. At worst - whitening. At best, an enormous increase in the difficulty of analyzing the cipher stream. (Note that since our negotiation occurs under a single cipher, not a variable one, quintuple encryption under the five ciphers believed strongest would not be inappropriate.) The idea _is_ a very promising one, even if it is not suitable for all applications, and even though it does require that some caution be taken when working out the basic design. John Savard ( teneerf<- ) http://www.ecn.ab.ca/~jsavard/crypto.htm
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Fri, 29 Oct 1999 03:03:33 GMT From: ritter@io.com (Terry Ritter) Message-ID: <38190e55.4213242@news.io.com> References: <3816204b.4599691@news.prosurfr.com> Newsgroups: sci.crypt Lines: 86 On Tue, 26 Oct 1999 21:54:03 GMT, in <3816204b.4599691@news.prosurfr.com>, in sci.crypt jsavard@tenMAPSONeerf.edmonton.ab.ca (John Savard) wrote: >daw@blowfish.isaac.cs.berkeley.edu (David Wagner) wrote, in part: > >>This illustrates the risk of cipher negotation: you might end up with >>the _weakest_ of the available ciphers, and thus you'd better be very >>sure that every cipher you support is strong enough for all purposes. > >I have to agree with that statement, it is undeniably true. However, >while I can't defend Terry Ritter's multi-ciphering proposal from >every criticism that has been levelled at it Well, let's see: >(perhaps it is cumbersome >and impractical, I suppose TCP/IP might be called "cumbersome and impractical" -- until one starts to feel the advantages. Once a dynamically changing cipher scheme is programmed, there should be little need for intrusion into applications or users. The dynamically changing cipher scheme may be complicated for some people to think about, but that is mainly an issue for implementors. >perhaps the effort involved is not worth it for the >security improvement it can bring - because the improvement in >security is not that badly needed, If you could tell us what level of security you get from your favorite cipher, then we could decide whether dynamically changing ciphers improved things for you or not. Alas, we cannot know how much security your cipher provides. Neither can you, neither can anyone else. So, given that you do *not* know the strength of your cipher, your preferred option seems to be to guess that you made the right choice, and stay with it, right or wrong. Which, of course, is the classic failure mode in cipher use. > >[...] there is one way in which the system will be >stronger than the weakest cipher used. A cipher that can be easily >broken with a large amount of known plaintext enciphered under a >single key still often cannot be broken on the basis of a single >message. As communications here are in the form of individual >messages, each with their own complement of ciphers as well as their >own key, and any weak ciphers, if they are used, are never used alone, >the presence of some weak ciphers in the mix is no longer >automatically fatal. An advantage of dynamically changing ciphers which the "conventional 'wisdom'" of continuously using a single cipher simply cannot match. >By making the use of a "strong" cipher mandatory, >as I've advocated, if worst comes to worst the weak ciphers are still >adding to strength, by supplying whitening, at the least, for the >strong ciphers. As there is no practical cipher which is known to be strong, this hardly makes any sense at all. >At worst - whitening. At best, an enormous increase in the difficulty >of analyzing the cipher stream. (Note that since our negotiation >occurs under a single cipher, not a variable one, quintuple encryption >under the five ciphers believed strongest would not be inappropriate.) > >The idea _is_ a very promising one, even if it is not suitable for all >applications, and even though it does require that some caution be >taken when working out the basic design. Yes, of course. --- Terry Ritter ritter@io.com http://www.io.com/~ritter/ Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: 29 Oct 1999 09:50:04 -0600 From: vjs@calcite.rhyolite.com (Vernon Schryver) Message-ID: <7vcfnc$r91$1@calcite.rhyolite.com> References: <38190e55.4213242@news.io.com> Newsgroups: sci.crypt Lines: 17 In article <38190e55.4213242@news.io.com>, Terry Ritter <ritter@io.com> wrote: > ... >I suppose TCP/IP might be called "cumbersome and impractical" -- until >one starts to feel the advantages. ... No, if you check history or were around at the time (I first met the Internet at the console of TIP-25 (DOCB) in about 1971), you know that TCP/IP's detractors did not complain that it was "cumbersome and impractical" but "simplistic and impractical." TCP/IP was neither the *cumbersome* response to x.25 nor the *complicated* alternative to the ISO OSI suite, although it can be seen as a response and alternative to them. Circuit switching enthusiasts in the 1970's said the same sort of things as the telco people were saying until recently, that datagrams are simplistic, impractical, and cannot be made to provide useful service. The ISO OSI community felt that TCP/IP was far too trivial for a real protocol, such as in the U.K. Colour Book Protocols version of the OSI protocols, where they insisted on putting x.25 everywhere, including below both connection oriented services (TP4) and connectionless (TP0 and TP1) and above Ethernet. Vernon Schryver vjs@rhyolite.com
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Fri, 29 Oct 1999 02:45:13 GMT From: ritter@io.com (Terry Ritter) Message-ID: <38190a35.3156577@news.io.com> References: <7v4sh2$ps2$1@blowfish.isaac.cs.berkeley.edu> Newsgroups: sci.crypt Lines: 44 On 26 Oct 1999 11:39:30 -0700, in <7v4sh2$ps2$1@blowfish.isaac.cs.berkeley.edu>, in sci.crypt daw@blowfish.isaac.cs.berkeley.edu (David Wagner) wrote: >In article <38124042.24656067@news.io.com>, Terry Ritter <ritter@io.com> wrote: >> I see no reason why the negotiation protocol must be "cryptographic," >> other than in the sense that it will handle cryptographic objects >> (ciphers). [...] The >> negotiation protocol can afford to have some weaknesses. > >If you have a non-cryptographic negotiation protocol, you might end >up with the weakest of the ciphers supported by both ends, rather than >the strongest of them. Fine. And if you don't change your cipher you might *also* end up using the weakest of the ciphers *AND* never changing it. Basically you continue to berate the idea of changing ciphers apparently because that does not produce provable security. But you conveniently overlook that the conventional alternative *also* does not produce provable security *and* is willing to rely on the same potentially faulty cipher for years on end. >[...] >This illustrates the risk of cipher negotation: you might end up with >the _weakest_ of the available ciphers, and thus you'd better be very >sure that every cipher you support is strong enough for all purposes. Nobody can follow your advice. Nobody knows how strong their cipher is. Neither do you, so it is strange advice. It is also sloppy, since it is unnecessary that *every* cipher be of some minimum strength. Indeed, it is only necessary that *one* such cipher exist in a field of two, to beat the alternative of using one cipher, if that happens to be the wrong one! And we cannot know if that is the case or not. --- Terry Ritter ritter@io.com http://www.io.com/~ritter/ Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: 28 Oct 1999 20:46:05 -0700 From: daw@blowfish.isaac.cs.berkeley.edu (David Wagner) Message-ID: <7vb59t$3q9$1@blowfish.isaac.cs.berkeley.edu> References: <38190a35.3156577@news.io.com> Newsgroups: sci.crypt Lines: 28 In article <38190a35.3156577@news.io.com>, Terry Ritter <ritter@io.com> wrote: > >Terry Ritter <ritter@io.com> wrote: > >> I see no reason why the negotiation protocol must be "cryptographic," > > daw@blowfish.isaac.cs.berkeley.edu (David Wagner) wrote: > >If you have a non-cryptographic negotiation protocol, you might end > >up with the weakest of the ciphers supported by both ends, rather than > >the strongest of them. > > Fine. And if you don't change your cipher you might *also* end up > using the weakest of the ciphers *AND* never changing it. The difference is who chooses your ciphers. Would you rather have your adversary choose for you which cipher you'll use, or would you rather make the choice yourself? The answer should be obvious. If the adversary gets the opportunity to choose which cipher you'll use, you can bet the adversary will pick the cipher which is most convenient for him to break. > Basically you continue to berate the idea of changing ciphers > apparently because that does not produce provable security. Er, what? I never said that. This is a strawman. This issue (the risks in non-cryptographic cipher negotiation protocols) has nothing to do with provable security, so I have a hard time understanding where this comment came from.
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Fri, 29 Oct 1999 10:57:33 GMT From: ritter@io.com (Terry Ritter) Message-ID: <38197b1e.2906065@news.io.com> References: <7vb59t$3q9$1@blowfish.isaac.cs.berkeley.edu> Newsgroups: sci.crypt Lines: 91 On 28 Oct 1999 20:46:05 -0700, in <7vb59t$3q9$1@blowfish.isaac.cs.berkeley.edu>, in sci.crypt daw@blowfish.isaac.cs.berkeley.edu (David Wagner) wrote: >In article <38190a35.3156577@news.io.com>, Terry Ritter <ritter@io.com> wrote: >> >Terry Ritter <ritter@io.com> wrote: >> >> I see no reason why the negotiation protocol must be "cryptographic," >> >> daw@blowfish.isaac.cs.berkeley.edu (David Wagner) wrote: >> >If you have a non-cryptographic negotiation protocol, you might end >> >up with the weakest of the ciphers supported by both ends, rather than >> >the strongest of them. >> >> Fine. And if you don't change your cipher you might *also* end up >> using the weakest of the ciphers *AND* never changing it. > >The difference is who chooses your ciphers. Would you rather have >your adversary choose for you which cipher you'll use, or would you >rather make the choice yourself? The answer should be obvious. > >If the adversary gets the opportunity to choose which cipher you'll >use, you can bet the adversary will pick the cipher which is most >convenient for him to break. Oddly, this doesn't sound like anything we have been talking about. I have never heard -- and certainly never made -- a suggestion that the adversary will choose the cipher. On the contrary, I have suggested that each user be able to create a list of ciphers they will accept, and then negotiate agreement -- automatically, in the background, and secretly, under the cover of cipher. This would be an ordinary handshake selection, not a cryptographic protocol, but nevertheless clearly neither exposed to nor under the control of the opponents. How is that related to the adversary choosing the cipher? >> Basically you continue to berate the idea of changing ciphers >> apparently because that does not produce provable security. > >Er, what? I never said that. This is a strawman. In view of your argument above, I find "strawman" an interesting term for you to use. >This issue (the risks in non-cryptographic cipher negotiation >protocols) has nothing to do with provable security, so I have a >hard time understanding where this comment came from. It seems like a reasonable extrapolation to me. My comment was an inference from your complaints about the multi-level ciphering and dynamic cipher change proposal. Your model has been shown to be insufficient to address major, intuitive aspects of the proposal, but you continue with the same old model. Your model is biased, but you promote it anyway. How are we to understand this? One way to understand it is that you are willing to *assume* strength in the single cipher you would use forever, but unwilling to make that same assumption for the many-cipher proposal, even though it would of course use that same cipher (along with others). I am willing to accept that many of those ciphers will have had less analysis than your pick (although this is really more of an indictment of academic review practices than cipher design). But I am not willing to accept that you have learned the strength of your cipher from its academic review, and in that it is I whose position agrees with the accepted wisdom. The most-analyzed cipher may turn out, in the end, to be the weakest cipher, even though that did not seem so in the beginning. And, since any single cipher will get the most additional analysis, this result might even be more probable than otherwise. If you cannot agree, perhaps you will give a rational explanation as to why not. It is obvious to even the most jaded observer that the real "strength" of a cipher depends upon what the opponents know. It is *obvious* that the more important traffic a cipher carries, and the longer a cipher is used, the more public and private research will address that cipher, and the more likely it is that a weakness will be found. Picking a cipher -- necessarily without proof of strength -- and then using it forever would seem to be the weakest possible way to employ any cipher, and yet you continue to support this. Worse, using only one cipher means that the cipher system is unlikely to accommodate changing ciphers easily, and that could be crucial if the cipher were publicly found weak, which is an obvious possibility. How are we to understand this, indeed? --- Terry Ritter ritter@io.com http://www.io.com/~ritter/ Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Fri, 29 Oct 1999 11:35:42 -0600 From: jcoffin@taeus.com (Jerry Coffin) Message-ID: <MPG.12838496129d8a269897a0@news.mindspring.com> References: <38197b1e.2906065@news.io.com> Newsgroups: sci.crypt Lines: 32 In article <38197b1e.2906065@news.io.com>, ritter@io.com says... [ ... ] > Oddly, this doesn't sound like anything we have been talking about. I > have never heard -- and certainly never made -- a suggestion that the > adversary will choose the cipher. On the contrary, I have suggested > that each user be able to create a list of ciphers they will accept, > and then negotiate agreement -- automatically, in the background, and > secretly, under the cover of cipher. This would be an ordinary > handshake selection, not a cryptographic protocol, but nevertheless > clearly neither exposed to nor under the control of the opponents. > How is that related to the adversary choosing the cipher? IMO, to maintain any hope of improving security, you need to ensure that the cipher used in the negotiation phase is _different_ from any of the ciphers that can be selected by the negotiation. If the protocol allows the same cipher to be used both for negotiation and for messages, then breaking that single cipher allows a MITM to force the same cipher to be selected with the negotiation as well, so he can then break the messages being sent. By NOT allowing the same cipher to be used for both negotiation and messages, the opponent has to break both the negotiation-phase cipher and at least one more before he can really accomplish anything. -- Later, Jerry. The universe is a figment of its own imagination.
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: 29 Oct 1999 18:37:27 -0600 From: vjs@calcite.rhyolite.com (Vernon Schryver) Message-ID: <7vdek7$bia$1@calcite.rhyolite.com> References: <MPG.12838496129d8a269897a0@news.mindspring.com> Newsgroups: sci.crypt Lines: 40 In article <MPG.12838496129d8a269897a0@news.mindspring.com>, Jerry Coffin <jcoffin@taeus.com> wrote: > ... >IMO, to maintain any hope of improving security, you need to ensure >that the cipher used in the negotiation phase is _different_ from any >of the ciphers that can be selected by the negotiation. > >If the protocol allows the same cipher to be used both for negotiation >and for messages, then breaking that single cipher allows a MITM to >force the same cipher to be selected with the negotiation as well, so >he can then break the messages being sent. > >By NOT allowing the same cipher to be used for both negotiation and >messages, the opponent has to break both the negotiation-phase cipher >and at least one more before he can really accomplish anything. That's a good insight on the hole, but the fix is not sufficent. A man in the middle who has broken the initial cipher could prevent what the PPP community calls "convergence" on choosing the next cipher. The bad guy could modify the negotiating to ensure that there is no common cipher or make it seem to each peer that the other does not agree. Since Terry Ritter insists that the negotiating is done in what he calls the background (just like some PPP protocols including compression) without notice to the users as user data is passed, the bad man in the middle could force the entire session to be run in the broken cipher without the users knowing. This applies regardless of whether one cipher or several is used simultaneously. If more than one is used, then you can consider ther composition as a single cipher. If someone were to ask me (and I realize no one has), I'd say that that sounds like such a strong restriction on any cipher (or composition) which covers any cipher negotiating that you might as well not bother with the negotiating and stick to that strong cipher. Please also note that such second order complications are what make negotiating or anything fancy a security nightmare. Would you have said in 1990 that an authentication protocol based on shared secrets and that never puts the same bits on the wire to be snooped can be wide open security hole for major commercial implmentations? I mean only only one of the new notes at the end of RFC 1994. Vernon Schryver vjs@rhyolite.com
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: 3 Nov 1999 08:46:38 -0700 From: vjs@calcite.rhyolite.com (Vernon Schryver) Message-ID: <7vplcu$evi$1@calcite.rhyolite.com> References: <7vpfq6$rsc$1@nnrp1.deja.com> <7vdek7$bia$1@calcite.rhyolite.com> Newsgroups: sci.crypt Lines: 104 In article <7vpfq6$rsc$1@nnrp1.deja.com>, <terry_ritter@my-deja.com> wrote: > ... >If we are using Mr. Ritter's protocol, we will not start >dynamic cipher negotiation until *after* a secure and >certified (if necessary) link is established. There is >no man-in-the-middle, because if there were, that would >be identified by public key certification, or by the fact >that the MITM does not have the message or session keys, >and therefore cannot modify the ciphertext without >detection. If you can detect any and all men in the middle who have broken the initially "secure and certified" link, then there less reason to negotiate additional ciphers. If you doubt the initial cipher, you won't use it to negotiate new ciphers, since you can't trust the results of any negotiating covered by the initial cipher. >If the original key-exchange is broken, cipher negotiation >is not going to help. Exactly! And if neither the intial key-exchange nor the cipher that uses those keys is broken, then there little rational justification for adding the code for negotiating more ciphers and the *inevitiable* security holes that come *all* additional code, at least at first. Since the preeminent real life negotiating protocol suite, PPP, is somehow irrelevant, remember the SSL experience. I think SSL was intended at first to solve a much simplier goal than Mr. Ritter's cipher negotiating, find a common ground between HTTP client and server, in part because the U.S.Government ensured that more than one cipher would be involved. Even if you are such a wonderful (and absolutely unique) programmer that none of your code ever has security bugs and you prevent any and all security bugs in all of other people's code that you use, take a look at the complications of the IETF's replacement for SSL. I've been watching TLS grind through the IETF for years. It's not a bad effort, but real life considerations apply. > And if the original cipher, or the >message or session keys are broken (!!!), we had better be >using different, unrelated keys and other cipher layers to >protect the negotiation better than the data. Then we could >negotiate a different cipher which might terminate the >existing break, which would seem to be more than any single >static cipher could do. If you have a better cipher for the negotiating, then instead of using it to negotiate, the rational thing would be to use it for the data and forget the added complexity and so inevitable added security holes in negotiating away a bad cipher. >Dynamic cipher negotiation is intended to support the >dynamic change of ciphers, which terminates any existing >break, Again, if there is a break, then you cannot trust any cipher negotiating to do anything except make the break worse. > and also allows new cryptanalytic results to >move an earlier cipher out of use. In real life, no one competent will ever use such negotiating schemes merely to move an earlier cipher out of use. If the communicating systes understand the new cipher, they will use it. If not, they cannot no matter how much negotiating they try. Yes, new systems might use non-negotiating mechanisms to detect old systems, such as a header that identifies the data for their mutual convenience, or they might be paranoid and not. Because of the security holes inevitiably opened to a man in the middle, they certainly won't chat about switching to the new cipher under the cover of the old. Instead, they'll do something like send a trial in the new cipher, possibly with a hint that the receiver should try the new cipher, or possibly without a hint to avoid giving clues. If that works, they'll continue with the new cipher. If the new cipher does not work, and they still trust the old cipher, they might fall back to the old cipher. If they have any reason to doubt the old cipher, they'll remember that a bad guy does not need to be in the middle to filter TCP connections (e.g. sending TCP RST's or just forged TCP segments) and so cause the supprious appearance that the new cipher does not work, and they'll never do anything except with the new cipher. > The act of changing >ciphers frequently also reduces the amount of ciphertext >under any one cipher, thus reducing the advantage of >breaking that cipher, and hides which ciphertext is >related to which cipher, which is an essential part of >most attacks. But dynamic cipher negotiation is *not* >the one solution to all possible security problems. The fundamental problem is that contrary to academic theories, in almost all real life cases, dynamic cipher negotiation is a security hole that far outweighs its theoretical advantages. Vernon Schryver vjs@rhyolite.com
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Wed, 03 Nov 1999 19:28:12 GMT From: jsavard@tenMAPSONeerf.edmonton.ab.ca (John Savard) Message-ID: <38208c52.7595050@news.prosurfr.com> References: <7vplcu$evi$1@calcite.rhyolite.com> Newsgroups: sci.crypt Lines: 14 vjs@calcite.rhyolite.com (Vernon Schryver) wrote, in part: >If you can detect any and all men in the middle who have broken the >initially "secure and certified" link, then there less reason to negotiate >additional ciphers. If you doubt the initial cipher, you won't use it >to negotiate new ciphers, since you can't trust the results of any >negotiating covered by the initial cipher. But the idea is that one could use something on the order of heptuple-AES as the initial cipher, and now that the algorithms are *variable*, one could get by with _mere_ triple encryption thereafter. John Savard ( teneerf<- ) http://www.ecn.ab.ca/~jsavard/crypto.htm
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Sat, 30 Oct 1999 13:58:55 GMT From: ritter@io.com (Terry Ritter) Message-ID: <381af94b.344695@news.io.com> References: <MPG.12838496129d8a269897a0@news.mindspring.com> Newsgroups: sci.crypt Lines: 49 On Fri, 29 Oct 1999 11:35:42 -0600, in <MPG.12838496129d8a269897a0@news.mindspring.com>, in sci.crypt jcoffin@taeus.com (Jerry Coffin) wrote: >In article <38197b1e.2906065@news.io.com>, ritter@io.com says... > >[ ... ] > >> Oddly, this doesn't sound like anything we have been talking about. I >> have never heard -- and certainly never made -- a suggestion that the >> adversary will choose the cipher. On the contrary, I have suggested >> that each user be able to create a list of ciphers they will accept, >> and then negotiate agreement -- automatically, in the background, and >> secretly, under the cover of cipher. This would be an ordinary >> handshake selection, not a cryptographic protocol, but nevertheless >> clearly neither exposed to nor under the control of the opponents. >> How is that related to the adversary choosing the cipher? > >IMO, to maintain any hope of improving security, you need to ensure >that the cipher used in the negotiation phase is _different_ from any >of the ciphers that can be selected by the negotiation. That's an interesting point. One possibility is to use an *additional* cipher on the negotiation data. I see the negotiation data being sent with the message, but distinguished from it in a sort of hidden "control channel." In this way the negotiation process need not intrude on user communications. Clearly, cipher agreement negotiation will *have* phases, but I do not see this as a sequential process of (1) negotiate, and then (2) communicate. Instead, communication should be in "the current cipher" and continue like that until agreement on a new cipher occurs and "the current cipher" changes. >If the protocol allows the same cipher to be used both for negotiation >and for messages, then breaking that single cipher allows a MITM to >force the same cipher to be selected with the negotiation as well, so >he can then break the messages being sent. > >By NOT allowing the same cipher to be used for both negotiation and >messages, the opponent has to break both the negotiation-phase cipher >and at least one more before he can really accomplish anything. --- Terry Ritter ritter@io.com http://www.io.com/~ritter/ Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Fri, 29 Oct 1999 22:57:13 -0400 From: "Trevor Jackson, III" <fullmoon@aspi.net> Message-ID: <381A5E89.8BFC94D8@aspi.net> References: <7vcfeb$46n$1@blowfish.isaac.cs.berkeley.edu> <38197b1e.2906065@news.io.com> Newsgroups: sci.crypt Lines: 50 David Wagner wrote: > In article <38197b1e.2906065@news.io.com>, Terry Ritter <ritter@io.com> wrote: > > Oddly, this doesn't sound like anything we have been talking about. I > > have never heard -- and certainly never made -- a suggestion that the > > adversary will choose the cipher. On the contrary, I have suggested > > that each user be able to create a list of ciphers they will accept, > > and then negotiate agreement -- automatically, in the background, and > > secretly, under the cover of cipher. This would be an ordinary > > handshake selection, not a cryptographic protocol, but nevertheless > > clearly neither exposed to nor under the control of the opponents. > > How is that related to the adversary choosing the cipher? > > Hmm. I didn't realize that was what you meant by a non-cryptographic > negotiation. If it's encrypted, it sounds cryptographic to me. > > This also raises a further question. I'm not very clear on how we reach > agreement on what cipher to use to encrypt our negotiation in the first > place. Another negotiation? But then is it turtles all the way down? > > When I hear the word "negotiation", I think of the following problem: > Alice supports some list of ciphers, Bob supports some (potentially > different) list of ciphers; now Alice and Bob would like to discover which > ciphers they share in common, and hopefully find the "best" such cipher. > Is that what you mean by the "negotiation problem", and if so, how can > we solve the bootstrapping problem securely? Rather than create a global namespace for ciphers, one could simply reserve cipher zero for plain text. When Alice wants to send her list of ciphers to Bob, she picks a convenient probe string, including IVs as necessary, and sends it encrypted with all of the ciphers she supports, in the order of her preference. Bob decrypts each probe with his entire list of ciphers, and choses from among the set that match the plaintext. Note that this set cannot be empty because Bob can always decode cipher zero. Bob's reply to Alice is a small number that selects the cipher with which Alice encrypted the Nth probe packet. If the number is zero they cannot communicate securely. Since this mechanism works with Alice/Bob being complete strangers, it is subject to many possible attacks. It is _not_ an authentication protocol, just a cipher selection mechanism. If Alice and Bob are members of a common group, such as owners of software that supports a standard default cipher, the above XnXeXgXoXtXiXaXtXiXoXnX configuation process can take place under the cover of that default. Since this mechanism requires only two messages and throughput is not usually going to be an issue, 3DES may be a suitable default.
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Sat, 30 Oct 1999 14:01:20 GMT From: ritter@io.com (Terry Ritter) Message-ID: <381af9f4.513163@news.io.com> References: <381A5E89.8BFC94D8@aspi.net> Newsgroups: sci.crypt Lines: 116 On Fri, 29 Oct 1999 22:57:13 -0400, in <381A5E89.8BFC94D8@aspi.net>, in sci.crypt "Trevor Jackson, III" <fullmoon@aspi.net> wrote: >David Wagner wrote: > >> In article <38197b1e.2906065@news.io.com>, Terry Ritter <ritter@io.com> wrote: >> > Oddly, this doesn't sound like anything we have been talking about. I >> > have never heard -- and certainly never made -- a suggestion that the >> > adversary will choose the cipher. On the contrary, I have suggested >> > that each user be able to create a list of ciphers they will accept, >> > and then negotiate agreement -- automatically, in the background, and >> > secretly, under the cover of cipher. This would be an ordinary >> > handshake selection, not a cryptographic protocol, but nevertheless >> > clearly neither exposed to nor under the control of the opponents. >> > How is that related to the adversary choosing the cipher? >> >> Hmm. I didn't realize that was what you meant by a non-cryptographic >> negotiation. If it's encrypted, it sounds cryptographic to me. By the same token, anything used in a cipher system reasonably might be called "cryptographic." The distinction I wish to draw is between the complexity of common cryptographic protocols, versus a basic selection and handshake. The selection itself is non-cryptographic, even if the item selected happens to be a cryptographic object. >> This also raises a further question. I'm not very clear on how we reach >> agreement on what cipher to use to encrypt our negotiation in the first >> place. Another negotiation? But then is it turtles all the way down? No. One might as well ask what *key* we use to encrypt messages "in the first place"? Obviously, both ends *must* use the same secret key, so how do they get it? Usually delivery is by some secure other channel, or by authenticated public key means. But the same process can deliver the name of the cipher to use, or even the actual cipher itself. >> When I hear the word "negotiation", I think of the following problem: >> Alice supports some list of ciphers, Bob supports some (potentially >> different) list of ciphers; now Alice and Bob would like to discover which >> ciphers they share in common, and hopefully find the "best" such cipher. >> Is that what you mean by the "negotiation problem", and if so, how can >> we solve the bootstrapping problem securely? I suggest that everyone have Triple DES. In practice, people might end up with the most well-known dozen or so ciphers, plus others. I see no grounds for negotiating "best." Indeed, the idea is explicitly *not* to select one cipher and stay with it; the idea is to select at random among a list of reasonable size. I would expect each user (or their corporate security officer) to have a list of ciphers which they will trust for use. The "negotiation" process is simply a way for the machinery at each end to select a random cipher and know which cipher to use at any given time. As an example, initial key exchange provides the cipher to be used at the start. Then, say the near end sends its list of acceptable cipher names to the far end: (I see this happening in a hidden "control channel" within the next message, although that channel could be additionally encrypted). Upon receipt of the list, if at least one of those is acceptable to the far end, the far end sends that one cipher name back (in the similar control channel accompanying the response from the far end). When the near end sees a single cipher name, and that name is acceptable to the near end, the near end switches to that cipher starting with the next outgoing message. The far end expects then next message to be in the new cipher, and so deciphers with the new cipher first. But if a message has been lost in transit, the message can only be in the previous cipher, which can be tried next. This is a resilient protocol. >Rather than create a global namespace for ciphers, one could simply reserve cipher >zero for plain text. When Alice wants to send her list of ciphers to Bob, she >picks a convenient probe string, including IVs as necessary, and sends it >encrypted with all of the ciphers she supports, in the order of her preference. >Bob decrypts each probe with his entire list of ciphers, and choses from among the >set that match the plaintext. Note that this set cannot be empty because Bob can >always decode cipher zero. This seems harder than it needs to be. Is there some advantage to it? I mean, both ends have to have exchanged a key anyway. Why don't they also exchange the starting cipher name? >Bob's reply to Alice is a small number that selects the cipher with which Alice >encrypted the Nth probe packet. If the number is zero they cannot communicate >securely. If we assume that the list has been received, we obviously can select from it by index. But if the list message was lost, indexing is impossible, while a cipher name is still useful. I think it is helpful and important for such a protocol to survive lost messages. >Since this mechanism works with Alice/Bob being complete strangers, it is subject >to many possible attacks. It is _not_ an authentication protocol, just a cipher >selection mechanism. > >If Alice and Bob are members of a common group, such as owners of software that >supports a standard default cipher, the above XnXeXgXoXtXiXaXtXiXoXnX configuation >process can take place under the cover of that default. Since this mechanism >requires only two messages and throughput is not usually going to be an issue, >3DES may be a suitable default. Triple DES may be the obvious cipher which everyone can be expected to have, and could be the default starting cipher, absent a particular specification otherwise. --- Terry Ritter ritter@io.com http://www.io.com/~ritter/ Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Sat, 30 Oct 1999 17:14:54 -0400 From: "Trevor Jackson, III" <fullmoon@aspi.net> Message-ID: <381B5FCE.D577F968@aspi.net> References: <381af9f4.513163@news.io.com> Newsgroups: sci.crypt Lines: 148 Terry Ritter wrote: > On Fri, 29 Oct 1999 22:57:13 -0400, in <381A5E89.8BFC94D8@aspi.net>, > in sci.crypt "Trevor Jackson, III" <fullmoon@aspi.net> wrote: > > >David Wagner wrote: > > > >> In article <38197b1e.2906065@news.io.com>, Terry Ritter <ritter@io.com> wrote: > >> > Oddly, this doesn't sound like anything we have been talking about. I > >> > have never heard -- and certainly never made -- a suggestion that the > >> > adversary will choose the cipher. On the contrary, I have suggested > >> > that each user be able to create a list of ciphers they will accept, > >> > and then negotiate agreement -- automatically, in the background, and > >> > secretly, under the cover of cipher. This would be an ordinary > >> > handshake selection, not a cryptographic protocol, but nevertheless > >> > clearly neither exposed to nor under the control of the opponents. > >> > How is that related to the adversary choosing the cipher? > >> > >> Hmm. I didn't realize that was what you meant by a non-cryptographic > >> negotiation. If it's encrypted, it sounds cryptographic to me. > > By the same token, anything used in a cipher system reasonably might > be called "cryptographic." The distinction I wish to draw is between > the complexity of common cryptographic protocols, versus a basic > selection and handshake. The selection itself is non-cryptographic, > even if the item selected happens to be a cryptographic object. > > >> This also raises a further question. I'm not very clear on how we reach > >> agreement on what cipher to use to encrypt our negotiation in the first > >> place. Another negotiation? But then is it turtles all the way down? > > No. > > One might as well ask what *key* we use to encrypt messages "in the > first place"? Obviously, both ends *must* use the same secret key, so > how do they get it? Usually delivery is by some secure other channel, > or by authenticated public key means. But the same process can > deliver the name of the cipher to use, or even the actual cipher > itself. Why deliver only one when you can deliver a list? (more on this below) > > > >> When I hear the word "negotiation", I think of the following problem: > >> Alice supports some list of ciphers, Bob supports some (potentially > >> different) list of ciphers; now Alice and Bob would like to discover which > >> ciphers they share in common, and hopefully find the "best" such cipher. > >> Is that what you mean by the "negotiation problem", and if so, how can > >> we solve the bootstrapping problem securely? > > I suggest that everyone have Triple DES. In practice, people might > end up with the most well-known dozen or so ciphers, plus others. > > I see no grounds for negotiating "best." Indeed, the idea is > explicitly *not* to select one cipher and stay with it; the idea is to > select at random among a list of reasonable size. I would expect each > user (or their corporate security officer) to have a list of ciphers > which they will trust for use. The "negotiation" process is simply a > way for the machinery at each end to select a random cipher and know > which cipher to use at any given time. > > As an example, initial key exchange provides the cipher to be used at > the start. Then, say the near end sends its list of acceptable cipher > names to the far end: (I see this happening in a hidden "control > channel" within the next message, although that channel could be > additionally encrypted). Upon receipt of the list, if at least one of > those is acceptable to the far end, the far end sends that one cipher > name back (in the similar control channel accompanying the response > from the far end). When the near end sees a single cipher name, and > that name is acceptable to the near end, the near end switches to that > cipher starting with the next outgoing message. The far end expects > then next message to be in the new cipher, and so deciphers with the > new cipher first. But if a message has been lost in transit, the > message can only be in the previous cipher, which can be tried next. > This is a resilient protocol. > > >Rather than create a global namespace for ciphers, one could simply reserve cipher > >zero for plain text. When Alice wants to send her list of ciphers to Bob, she > >picks a convenient probe string, including IVs as necessary, and sends it > >encrypted with all of the ciphers she supports, in the order of her preference. > >Bob decrypts each probe with his entire list of ciphers, and choses from among the > >set that match the plaintext. Note that this set cannot be empty because Bob can > >always decode cipher zero. > > This seems harder than it needs to be. Is there some advantage to it? > I mean, both ends have to have exchanged a key anyway. Why don't they > also exchange the starting cipher name? If Alice publishes the public part of a two-part key she can attach a list of cipher selection packets to the key. Then Bob select one and use it. The issue I was attempting to address is avoiding the need to be excruciatingly explicit about cipher names. A properly constructed probe packet makes the cipher equally anonymous. This isn't really a security provision, it's a way to avoid rev skew problems, thus a simplification of the expected operational details rather than a simplification of the implementation details. Also, if Bob is sending a stream of messages to Alice, he can do more than change the per-messages keys. He can also vary the cipher as long as he stays within the set described by Alice's public key. > > > >Bob's reply to Alice is a small number that selects the cipher with which Alice > >encrypted the Nth probe packet. If the number is zero they cannot communicate > >securely. > > If we assume that the list has been received, we obviously can select > from it by index. But if the list message was lost, indexing is > impossible, while a cipher name is still useful. I think it is > helpful and important for such a protocol to survive lost messages. Yes, that is a valid issue. However, channel reliability is orthogonal to channel impenetrability (crypto). They are both desirable properties, but need not be implemented in the same layer. I believe reliability is aproperty that belongs in the transport layer, which is necessarily below the cipher/security layer. When there are a large number of ciphers available from a large number of sources you would need some mechanism to avoid naming errors. Note there are two possible error classes. A collision occurs when Alice and Bob use the same name for different ciphers, so operators using the software they each sell get error messages about something that "should work" from the operator's point of view; and the opposite, a failed rendevous occurs when they use different names for the same cipher, with the result that operators who could have communicated cannot. Thus selection by index, as you termed it, rather then selection by name. Note there is some additional confidence generated by a properly constructed probe packet in that with it one can confirm not only that the ends points agree on the cipher they intend to use, but also that the implementations of the ciphers are correct/match. > > > >Since this mechanism works with Alice/Bob being complete strangers, it is subject > >to many possible attacks. It is _not_ an authentication protocol, just a cipher > >selection mechanism. > > > >If Alice and Bob are members of a common group, such as owners of software that > >supports a standard default cipher, the above XnXeXgXoXtXiXaXtXiXoXnX configuation > >process can take place under the cover of that default. Since this mechanism > >requires only two messages and throughput is not usually going to be an issue, > >3DES may be a suitable default. > > Triple DES may be the obvious cipher which everyone can be expected to > have, and could be the default starting cipher, absent a particular > specification otherwise.
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: 30 Oct 99 03:03:33 GMT From: jsavard@ecn.ab.ca () Message-ID: <381a6005.0@ecn.ab.ca> References: <7vcfeb$46n$1@blowfish.isaac.cs.berkeley.edu> <38197b1e.2906065@news.io.com> Newsgroups: sci.crypt Lines: 10 David Wagner (daw@blowfish.isaac.cs.berkeley.edu) wrote: : Hmm. I didn't realize that was what you meant by a non-cryptographic : negotiation. If it's encrypted, it sounds cryptographic to me. Although it was noted early on as being encrypted, I think the intent was to state that the protocol need not be an elaborate one with special properties; except for being enciphered, other special measures do not seem to be obviously required. John Savard
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Wed, 03 Nov 1999 14:27:21 GMT From: ritter@io.com Message-ID: <7vpgo4$sn9$1@nnrp1.deja.com> References: <7vdr1q$5ng$1@blowfish.isaac.cs.berkeley.edu> <381a6005.0@ecn.ab.ca> Newsgroups: sci.crypt Lines: 115 In article <7vdr1q$5ng$1@blowfish.isaac.cs.berkeley.edu>, daw@blowfish.isaac.cs.berkeley.edu (David Wagner) wrote: > In article <381a6005.0@ecn.ab.ca>, <jsavard@ecn.ab.ca> wrote: > > David Wagner (daw@blowfish.isaac.cs.berkeley.edu) wrote: > > : Hmm. I didn't realize that was what you meant by a non-cryptographic > > : negotiation. If it's encrypted, it sounds cryptographic to me. > > > > Although it was noted early on as being encrypted, I think the intent was > > to state that the protocol need not be an elaborate one with special > > properties; except for being enciphered, other special measures do not > > seem to be obviously required. > > I'm not convinced (yet). > > First, there are the obvious protocol attacks. > > If it's encrypted, it'd better be MAC'ed as well -- otherwise there might > well be ciphertext tampering attacks (e.g., truncate the ciphertext > to delete some of the sender's proposed ciphers). Yes, of course. Every cipher should have (and all of my cipher systems do have) some sort of hash of the data which allows us to detect ciphertext modification. In an overall system which coordinates email exchanges, there may well be sequence numbers as well. >Also, you have > to worry about replay attacks -- so does that mean we need to add a > challenge-response prelude to the negotiation protocol? Sequence numbers. >And as someone > else pointed out, we better make sure the cipher we use to encrypt the > negotiation protocol is different from the cipher we use to encrypt > the rest of our traffic, because otherwise we have a huge single point > of failure. Fine. > Once you start getting into this level of complexity, I have to wonder > whether the claim that "it need not be elaborate" is truly realistic. But what else could possibly be "realistic" in a deployed cipher system? Do you seriously suggest that one would build a cipher system *without* (effectively) having error-detection on the plaintext or ciphertext? So that, at least, would seem to be there already. The whole point of such a system is to change ciphers, which implies that we have multiple or many ciphers, any of which can be used. Is it then an "elaborate" extension to allow different or additional ciphers for the dynamic cipher negotiation? I think not. > Second, there are the obvious implementation issues. > > Usually if we need a cipher negotiation protocol, it's because we don't > know a priori of any ciphers that are strong enough to satisfy everyone > and yet are implemented everywhere. (After all, if we had one, we'd just > use it for encrypting all our traffic.) That is only one part of the goal, and perhaps the lesser part. Just finding one cipher which we can agree upon does not give us the dynamic cipher changes which: (1) terminate existing breaks, (2) reduce the amount of information under any one cipher, and (3) hide the correspondence between cipher and ciphertext, as most attacks require. >But now we've got a bootstrapping > problem: how do we pick which cipher to encrypt our negotiation under? > We could precede it with another negotiation protocol, but that'd be silly. Yes, that would be silly. > So I'm not convinced that cipher negotiation is as trivial as it is > made out to be. In fact, experience (SSL, SSH, etc.) seems to suggest > exactly the opposite. Any protocol is going to be more complex than not having a protocol. Presumably, the simpler we make that protocol, the better off we are. By making it a simple selection instead of some horribly complex (and equally unprovable) cryptographic protocol, we have a better chance to understand it well and implement it well. --- Terry Ritter ritter@io.com http://www.io.com/~ritter/ Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM Sent via Deja.com http://www.deja.com/ Before you buy.
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Tue, 02 Nov 1999 20:22:10 GMT From: bryan.olson@uptronics.com Message-ID: <7vnh5d$fh6$1@nnrp1.deja.com> References: <38197b1e.2906065@news.io.com> Newsgroups: sci.crypt Lines: 36 ritter@io.com (Terry Ritter) wrote: > Oddly, this doesn't sound like anything we have been talking about. I > have never heard -- and certainly never made -- a suggestion that the > adversary will choose the cipher. You certainly have heard such a suggestion. Yes, you failed to consider the chosen cipher attack, and now it seems that you confuse failure to recognize the problem with not having it. > On the contrary, I have suggested > that each user be able to create a list of ciphers they will accept, > and then negotiate agreement -- automatically, in the background, and > secretly, under the cover of cipher. This would be an ordinary > handshake selection, not a cryptographic protocol, but nevertheless > clearly neither exposed to nor under the control of the opponents. > How is that related to the adversary choosing the cipher? As I noted some time ago, your writings made the point that the choice of cipher was secret, but were clearly oblivious to the fact that authentication of the choice is more important. The details of your protocols have never appeared, so we cannot tell whether the attack would work. The fact that you still compare the negotiation of the cipher to modem protocols, and call it "an ordinary handshake selection, not a cryptographic protocol" is rather ominous. --Bryan Sent via Deja.com http://www.deja.com/ Before you buy.
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Thu, 04 Nov 1999 00:46:45 GMT From: ritter@io.com (Terry Ritter) Message-ID: <3820d764.3353257@news.io.com> References: <7vnh5d$fh6$1@nnrp1.deja.com> Newsgroups: sci.crypt Lines: 86 On Tue, 02 Nov 1999 20:22:10 GMT, in <7vnh5d$fh6$1@nnrp1.deja.com>, in sci.crypt bryan.olson@uptronics.com wrote: >ritter@io.com (Terry Ritter) wrote: > >> Oddly, this doesn't sound like anything we have been talking about. I >> have never heard -- and certainly never made -- a suggestion that the >> adversary will choose the cipher. > >You certainly have heard such a suggestion. Yes, you >failed to consider the chosen cipher attack, and now >it seems that you confuse failure to recognize the >problem with not having it. A "chosen cipher attack" would imply that the opponent could choose the cipher to be used. That is not possible here. Under my proposals (multi-level ciphering, dynamically changing ciphers, and many ciphers), the cipher would be chosen at random from the set of ciphers acceptable to both ends. The cipher lists may or may not be secret, but the negotiation and selection *would* be secret. This process would be conducted under cipher. Clearly, negotiations can occur under cipher only *after* an original cipher and key have been selected. This is the normal key management problem. Cipher negotiation does not solve that. If user authentication is to be effective, it must occur *before* we start talking under cipher: We cannot hope to identify a man-in-the-middle from information which we share with the other end. So before we share anything of consequence we must already be sure there is no MITM. One possibility is to authenticate the other end by authenticating (certifying) our public keys. Dynamic cipher negotiation and selection occurs only after this. >> On the contrary, I have suggested >> that each user be able to create a list of ciphers they will accept, >> and then negotiate agreement -- automatically, in the background, and >> secretly, under the cover of cipher. This would be an ordinary >> handshake selection, not a cryptographic protocol, but nevertheless >> clearly neither exposed to nor under the control of the opponents. >> How is that related to the adversary choosing the cipher? > >As I noted some time ago, your writings made the point >that the choice of cipher was secret, but were clearly >oblivious to the fact that authentication of the choice >is more important. OBVIOUSLY, any cipher code can be compromised. That is the case with any cipher system. That is why DES was originally for hardware only. We don't want to use compromised code. And simply making the source available for review is unlikely to be helpful to most users. Presumably, various free cipher systems will be sufficiently well known and analyzed to be trustable. Some users may want to obtain their ciphers from a reliable commercial source. But surely nobody imagines going out on the net and saying "hey, somebody send me <xxx> cipher," and then trusting anything which came in. Yes, the cipher code itself must be trustable. >The details of your protocols have >never appeared, so we cannot tell whether the attack >would work. The fact that you still compare the >negotiation of the cipher to modem protocols, and call >it "an ordinary handshake selection, not a cryptographic >protocol" is rather ominous. How hard do you want to make this? Selecting a cipher from among a list of approved ciphers simply does not require a cryptographic protocol. I'm sure we could do all sorts of fancy things, and it may be that the selection channel should have additional protection. But the selection itself is straightforward. It is just like two people talking. It is unimportant which cipher we select, as long as both ends agree. The idea is not to select the "best." Indeed, we want to *avoid* selecting "the" best cipher, so that we can select arbitrarily from among a rather large set. --- Terry Ritter ritter@io.com http://www.io.com/~ritter/ Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Fri, 05 Nov 1999 05:18:13 GMT From: bryan.olson@uptronics.com Message-ID: <7vtpaj$gg$1@nnrp1.deja.com> References: <3820d764.3353257@news.io.com> Newsgroups: sci.crypt Lines: 91 Terry Ritter wrote: > > bryan.olson@uptronics.com wrote: > >You certainly have heard such a suggestion. Yes, you > >failed to consider the chosen cipher attack, and now > >it seems that you confuse failure to recognize the > >problem with not having it. > > A "chosen cipher attack" would imply that the opponent could choose > the cipher to be used. That is not possible here. > > Under my proposals (multi-level ciphering, dynamically changing > ciphers, and many ciphers), the cipher would be chosen at random from > the set of ciphers acceptable to both ends. The cipher lists may or > may not be secret, but the negotiation and selection *would* be > secret. This process would be conducted under cipher. One more time: secret is not the issue. Authenticated is the issue. One side can certainly make a random choice, but your method calls for them to agree, and thus the choice must be influenced by messages between them. You have simply assumed the choice would be random, without ever presenting how they ensure it will be random when an attacker may modify the messages that influence the choice. [...] Ritter: > >> On the contrary, I have suggested > >> that each user be able to create a list of ciphers they will accept, > >> and then negotiate agreement -- automatically, in the background, and > >> secretly, under the cover of cipher. This would be an ordinary > >> handshake selection, not a cryptographic protocol, but nevertheless > >> clearly neither exposed to nor under the control of the opponents. > >> How is that related to the adversary choosing the cipher? > > > >As I noted some time ago, your writings made the point > >that the choice of cipher was secret, but were clearly > >oblivious to the fact that authentication of the choice > >is more important. > > OBVIOUSLY, any cipher code can be compromised. [...] Whether an authentication code be compromised is beyond the scope of the protocol. The point is the need for authentication and its absence from your proposal. > >The details of your protocols have > >never appeared, so we cannot tell whether the attack > >would work. The fact that you still compare the > >negotiation of the cipher to modem protocols, and call > >it "an ordinary handshake selection, not a cryptographic > >protocol" is rather ominous. > > How hard do you want to make this? > That could be the mantra of designers of failed protocols. > Selecting a cipher from among a list of approved ciphers simply does > not require a cryptographic protocol. I'm sure we could do all sorts > of fancy things, and it may be that the selection channel should have > additional protection. But the selection itself is straightforward. > It is just like two people talking. It is unimportant which cipher we > select, as long as both ends agree. The idea is not to select the > "best." Indeed, we want to *avoid* selecting "the" best cipher, so > that we can select arbitrarily from among a rather large set. A communications protocol specifies the procedure each node executes, including the messages it sends and its response to each possible message received. The attack people are pointing out is one in which the adversary looks at the protocol, and tries to find how he can alter the messages to influence the choice of cipher towards those that he would prefer. It does not weaken the choice to below the strength of weakest cipher that the sender would agree to use. Whether such attacks would work depends upon the protocol, and yours has never appeared. --Bryan Sent via Deja.com http://www.deja.com/ Before you buy.
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Mon, 08 Nov 1999 05:51:17 GMT From: ritter@io.com (Terry Ritter) Message-ID: <382664bb.4585308@news.io.com> References: <7vtpaj$gg$1@nnrp1.deja.com> Newsgroups: sci.crypt Lines: 154 On Fri, 05 Nov 1999 05:18:13 GMT, in <7vtpaj$gg$1@nnrp1.deja.com>, in sci.crypt bryan.olson@uptronics.com wrote: >Terry Ritter wrote: >> >> bryan.olson@uptronics.com wrote: > >> >You certainly have heard such a suggestion. Yes, you >> >failed to consider the chosen cipher attack, and now >> >it seems that you confuse failure to recognize the >> >problem with not having it. >> >> A "chosen cipher attack" would imply that the opponent could choose >> the cipher to be used. That is not possible here. >> >> Under my proposals (multi-level ciphering, dynamically changing >> ciphers, and many ciphers), the cipher would be chosen at random from >> the set of ciphers acceptable to both ends. The cipher lists may or >> may not be secret, but the negotiation and selection *would* be >> secret. This process would be conducted under cipher. > >One more time: secret is not the issue. Authenticated >is the issue. Well, in cryptography, there are various kinds of authentication: There is "user authentication," where we identify a particular user as compared to some other. There is "message authentication," where we identify that a message has not been changed in transit. There is "key authentication," where we show that a particular public key is in fact the current key, and belongs to who we expect. There is "algorithm authentication," where we identify that the code we wish to use is in fact the code which the reputable source produced and has not somehow been modified in transit. Presumably there are other forms as well. Perhaps you should indicate what form of authentication is your particular issue. >One side can certainly make a random >choice, but your method calls for them to agree, and >thus the choice must be influenced by messages between >them. You have simply assumed the choice would be >random, without ever presenting how they ensure it >will be random when an attacker may modify the messages >that influence the choice. First of all, the "random" selection I propose is exactly the same sort of thing which produces message keys (or "session keys," if they are used for multiple messages), which are used in almost every serious cipher system. Normally, the public-key component transfers the message key, which is then used in a secret-key system. This is very well known technology, and the issues are also well known, so there should be little need to repeat these well known details. Next, it is true that messages must be sent between the ends to coordinate cipher changes. But these messages are -- once again -- sent *under cipher*. By "under cipher," I mean that I require that a cipher already have been established and be in effect. Whatever cipher system has been established will authenticate received messages in some way (often with a hash of the plaintext), and thus will detect "any" attempt by an attacker to "modify the messages." This is very well known technology, and -- again -- there should be little need to describe it in detail. >[...] >Ritter: >> >> On the contrary, I have suggested >> >> that each user be able to create a list of ciphers they will >accept, >> >> and then negotiate agreement -- automatically, in the background, >and >> >> secretly, under the cover of cipher. This would be an ordinary >> >> handshake selection, not a cryptographic protocol, but nevertheless >> >> clearly neither exposed to nor under the control of the opponents. >> >> How is that related to the adversary choosing the cipher? >> > >> >As I noted some time ago, your writings made the point >> >that the choice of cipher was secret, but were clearly >> >oblivious to the fact that authentication of the choice >> >is more important. >> >> OBVIOUSLY, any cipher code can be compromised. [...] > >Whether an authentication code be compromised is >beyond the scope of the protocol. The point is the >need for authentication and its absence from your >proposal. If you are describing a need for message authentication, I wholly agree. This should be a part of any cipher, and is in fact a part of all of my commercial ciphers. This is very well known technology. But message authentication is *not* part of the cipher-change protocols, because those protocols *assume* that message authentication is performed by the covering cipher. That cipher also carries normal message traffic, of course, in addition to the negotiation conversation or channel. The negotiation is the simple use of the ordinary and expected features of any serious cipher system. >> >The details of your protocols have >> >never appeared, so we cannot tell whether the attack >> >would work. The fact that you still compare the >> >negotiation of the cipher to modem protocols, and call >> >it "an ordinary handshake selection, not a cryptographic >> >protocol" is rather ominous. >> >> How hard do you want to make this? >> > >That could be the mantra of designers of failed >protocols. > >> Selecting a cipher from among a list of approved ciphers simply does >> not require a cryptographic protocol. I'm sure we could do all sorts >> of fancy things, and it may be that the selection channel should have >> additional protection. But the selection itself is straightforward. >> It is just like two people talking. It is unimportant which cipher we >> select, as long as both ends agree. The idea is not to select the >> "best." Indeed, we want to *avoid* selecting "the" best cipher, so >> that we can select arbitrarily from among a rather large set. > >A communications protocol specifies the procedure >each node executes, including the messages it sends >and its response to each possible message received. >The attack people are pointing out is one in which >the adversary looks at the protocol, and tries to >find how he can alter the messages to influence the >choice of cipher towards those that he would prefer. >It does not weaken the choice to below the strength >of weakest cipher that the sender would agree to use. > >Whether such attacks would work depends upon the >protocol, and yours has never appeared. One might reasonably expect the cipher system which encloses the cipher-change negotiation to have at least the characteristics one now expects to see in serious ciphers. Identifying those messages whose contents have changed in transit is a common and expected feature of serious cipher systems. It thus hardly seems odd that I would expect such a feature to be included in the enclosing cipher. And, since it is a feature of *that* system, it is *not* a feature of my protocol per se, any more than that the enclosing cipher should be secure, and keys should be properly managed, and public keys certified, and on and on. These things are to be expected in serious cipher systems. As I have said over and over again, the negotiation occurs *under* some established cipher. --- Terry Ritter ritter@io.com http://www.io.com/~ritter/ Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Thu, 11 Nov 1999 01:27:24 GMT From: bryan.olson@uptronics.com Message-ID: <80d61p$r1u$1@nnrp1.deja.com> References: <382664bb.4585308@news.io.com> Newsgroups: sci.crypt Lines: 84 Terry Ritter wrote: bryan.olson@uptronics.com wrote: [...] > >One more time: secret is not the issue. Authenticated > >is the issue. > > Well, in cryptography, there are various kinds of authentication: Glad you're seeing that. [...] > >One side can certainly make a random > >choice, but your method calls for them to agree, and > >thus the choice must be influenced by messages between > >them. You have simply assumed the choice would be > >random, without ever presenting how they ensure it > >will be random when an attacker may modify the messages > >that influence the choice. > > First of all, the "random" selection I propose is exactly the same > sort of thing which produces message keys (or "session keys," if they > are used for multiple messages), which are used in almost every > serious cipher system. Normally, the public-key component transfers > the message key, which is then used in a secret-key system. This is > very well known technology, and the issues are also well known, so > there should be little need to repeat these well known details. Many or most serious systems use session keys where each key is chosen by one side, thus requiring no negotiation. In systems that negotiate choice of cipher the "well known details" are well known for their difficulty; failure to authenticate the cipher negotiation was a mistake in SSL. Over and over you've stated that the negotiation is secret, protected by a cipher. When did you note the need for authentication or name a MAC or signature? Now you say it's just like other cipher systems, such as public key ciphers. Ciphers provide poor authentication, and public key ciphers don't really provide any authentication at all. It is not the case that your claim of secrecy, protected by a cipher implies authentication. In fact it implies that you missed the attack. > Next, it is true that messages must be sent between the ends to > coordinate cipher changes. But these messages are -- once again -- > sent *under cipher*. By "under cipher," I mean that I require that a > cipher already have been established and be in effect. Whatever > cipher system has been established will authenticate received messages > in some way (often with a hash of the plaintext), and thus will detect > "any" attempt by an attacker to "modify the messages." Now you're starting to get it. This authentication was completely missing from your suggestion before others pointed out the problem. Yes, it can be fixed, but the actual protocol design is not the simple exercise you had thought. > >Whether an authentication code be compromised is > >beyond the scope of the protocol. The point is the > >need for authentication and its absence from your > >proposal. > > If you are describing a need for message authentication, I wholly > agree. So thank people for pointing out that you needed it in your negotiation phase, and stop pretending that you had it there already. > This should be a part of any cipher, and is in fact a part of > all of my commercial ciphers. This is very well known technology. The cipher agility of your actual systems is far behind the state of the art. You claim to be long-time advocate of standard protocols with interchangeable cipher, and that the design of such protocols is easy. Your commercial ciphers contradict such claims. --Bryan Sent via Deja.com http://www.deja.com/ Before you buy.
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Thu, 11 Nov 1999 06:05:54 GMT From: ritter@io.com (Terry Ritter) Message-ID: <382a5c09.9266545@news.io.com> References: <80d61p$r1u$1@nnrp1.deja.com> Newsgroups: sci.crypt Lines: 235 On Thu, 11 Nov 1999 01:27:24 GMT, in <80d61p$r1u$1@nnrp1.deja.com>, in sci.crypt bryan.olson@uptronics.com wrote: >Terry Ritter wrote: >bryan.olson@uptronics.com wrote: >[...] >> >One more time: secret is not the issue. Authenticated >> >is the issue. >> >> Well, in cryptography, there are various kinds of authentication: > >Glad you're seeing that. In the rest of the paragraph -- which you did not see fit to include here -- I described various types of "authentication." I named them. You did not. You failed to distinguish between them, and completely failed to identify what sort of "authentication" you were addressing. Strangely, it's like you really didn't know what you were talking about, or at least could not express it clearly. Odd. >[...] >> >One side can certainly make a random >> >choice, but your method calls for them to agree, and >> >thus the choice must be influenced by messages between >> >them. You have simply assumed the choice would be >> >random, without ever presenting how they ensure it >> >will be random when an attacker may modify the messages >> >that influence the choice. >> >> First of all, the "random" selection I propose is exactly the same >> sort of thing which produces message keys (or "session keys," if they >> are used for multiple messages), which are used in almost every >> serious cipher system. Normally, the public-key component transfers >> the message key, which is then used in a secret-key system. This is >> very well known technology, and the issues are also well known, so >> there should be little need to repeat these well known details. > >Many or most serious systems use session keys where >each key is chosen by one side, thus requiring no >negotiation. "Session keys" (more properly called "message keys," in most cases) are in fact very close to the negotiation which I have been promoting all along. In my proposal, one end sends a list; the other selects from that list, repeatedly, perhaps with every message, much like a message key. Occasionally a new list is requested or just sent. I suppose one might well say that all this requires "no negotiation," and this is the normal situation. >In systems that negotiate choice of >cipher the "well known details" are well known for >their difficulty; failure to authenticate the cipher >negotiation was a mistake in SSL. In my proposals, it is has been, and still is, unnecessary to authenticate the cipher choice. No authentication mistake is possible with respect to cipher choice. The ciphers themselves must be authentic, but that is not a cipher-change protocol issue. >Over and over you've stated that the negotiation is >secret, protected by a cipher. When did you note >the need for authentication or name a MAC or >signature? Now you say it's just like other cipher >systems, such as public key ciphers. Ciphers provide >poor authentication, and public key ciphers don't >really provide any authentication at all. It is >not the case that your claim of secrecy, protected >by a cipher implies authentication. In fact it >implies that you missed the attack. I have always said that the cipher-change negotiation must occur under cipher. I am guilty of expecting that cipher system to be effective. But I missed no attack, because there was and is no attack on the cipher-change protocol itself, which is all I have been describing. The cipher-change protocol does *not* have the man-in-the-middle problems which seem inherent in public-key cryptography. This is because the cipher-change "negotiation" is simply not exposed to MITM diddling. A MITM must be detected by the outer cipher layers, for if not, the plaintext is exposed, making cipher-changes completely irrelevant. I am unaware of any claim that cipher-changes would solve the MITM problem for public-key cryptography. You seem to have several big problems here, the first being the possibility that I missed something, and so deserve your castigation. Well, I did *not* miss what you think I did, but even if I had, who elected you God? If you had found a factual problem, you could present that. Instead, you cop an attitude and distort reality, both of which are way out of line. Then you seem to think that because I made the original proposal, that if only you could find some error in it, I would be embarrassed. Sorry. There are always problems with new proposals, because they have not had the amount of development the old ones have had. The real issue is whether the underlying idea is correct, and here it is. Your "authentication" issue is both specious and an embarrassingly shallow understanding of the real problem. >> Next, it is true that messages must be sent between the ends to >> coordinate cipher changes. But these messages are -- once again -- >> sent *under cipher*. By "under cipher," I mean that I require that a >> cipher already have been established and be in effect. Whatever >> cipher system has been established will authenticate received messages >> in some way (often with a hash of the plaintext), and thus will detect >> "any" attempt by an attacker to "modify the messages." > >Now you're starting to get it. This authentication >was completely missing from your suggestion before >others pointed out the problem. There was and is no problem, and what was pointed out was wrong. If the public-key certification or message authentication is bad, the original security is bad, and there is no protection for the raw plaintext that we are trying to protect, so cipher-change negotiation is the least of the problems. Your peculiar concentration on "authentication" obscures the real problem, and that problem is that the original cipher must be secure in many ways, including algorithm, key, and implementation. Where did *you* ever say that *those* were required? But they *are* required, and you missed those "attacks." Tsk, tsk. >Yes, it can be fixed, >but the actual protocol design is not the simple >exercise you had thought. The protocol is *just* as simple as I first proposed. There is essentially no protocol there at all: We just select at random from a list. The design part of this is the construction of a hidden command channel behind the plaintext, the various messages and retained state required to perform a clean transition, and I believe, the ability to withstand message loss without problem. This does require some design, and failure here means we will not change ciphers, or may do so in regular ways. In other words, the *worst* that can happen from a bad cipher-change protocol is that we end up using one cipher repeatedly, which is the *normal* situation now. Failure in the protocol is thus only a failure to take advantage of new cipher-change strength, and not an introduction of weakness. >> >Whether an authentication code be compromised is >> >beyond the scope of the protocol. The point is the >> >need for authentication and its absence from your >> >proposal. >> >> If you are describing a need for message authentication, I wholly >> agree. > >So thank people for pointing out that you needed it in >your negotiation phase, and stop pretending that you had >it there already. It was clear enough for almost everyone else who read my proposals. Stop pretending that you have contributed something important. You have not. Stop pretending that I have ignored or dissembled about a real problem. I have not. As far as I know, the only real problem which came up was the need for additional protection for the command channel, beyond that used for the plaintext. That was pointed out by "others," not me. But that is not your "authentication," and it is easily fixed. >> This should be a part of any cipher, and is in fact a part of >> all of my commercial ciphers. This is very well known technology. > >The cipher agility of your actual systems is far behind >the state of the art. "Cipher agility" would seem to mean the ability to change ciphers quickly. Any system which can do this is *beyond* the current state of the art. My proposals thus *are* the state of the art in non-government cryptography. My proposals allow ciphers to change, at random, from an approved list, with *every* *message*. That's about as "agile" as one can get. >You claim to be long-time advocate >of standard protocols with interchangeable cipher, Not only do I claim this, I can prove it, based on archived messages on my pages and other servers. >and that >the design of such protocols is easy. Really? I doubt I ever said that the design of such protocols was "easy." These protocols are, however, far different from the usual obscure cryptographic protocols which typically have almost endless possibility of error. In that sense, cipher-change protocols *are* easi*er*. >Your commercial >ciphers contradict such claims. I'm a little confused here: Are you saying that I have produced ciphers of such complexity that they obviously were not easy to design? Guilty. Actually, my ciphers are fairly simple, as serious systems go. But the design and actual implementation of real cipher systems is not easy. Perhaps you should try it, so we can see how well *you* do. In fact, perhaps you should come up with your own proposal to improve cryptography, so we can see how well you do at *that*. Maybe you should write and publish an article so we can judge that too. Clearly you have trouble with the concept of what an "attack" is, and it has taken you weeks to understand the basic concept of dynamic cipher-changing, which most readers got in the first or second posting. I suggest more study and less ranting. Frankly, since your years-ago claim to have a break for my Fenced DES Cipher broke down in your own failure, you have been hard to live with. The reality is that I produced a design which, in the end, withstood your attacks; I built a cipher which you thought you could break, but could not. I'm sure it was very embarrassing for you. But everyone makes mistakes, and those of us who speak out are especially exposed; most of us accept reality and move on. Get over it. --- Terry Ritter ritter@io.com http://www.io.com/~ritter/ Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Fri, 12 Nov 1999 02:48:38 GMT From: bryan.olson@uptronics.com Message-ID: <80fv65$rvt$1@nnrp1.deja.com> References: <382a5c09.9266545@news.io.com> Newsgroups: sci.crypt Lines: 265 Terry Ritter wrote: > bryan.olson@uptronics.com wrote: > >Terry Ritter wrote: > >> Well, in cryptography, there are various kinds of authentication: > > > >Glad you're seeing that. > > In the rest of the paragraph -- which you did not see fit to include > here -- I described various types of "authentication." I deleted the tangent. There are several neat ways to do it, and they don't necessarily fall into one of the types from a list. [...] > "Session keys" (more properly called "message keys," in most cases) > are in fact very close to the negotiation which I have been promoting > all along. In my proposal, one end sends a list; the other selects > from that list, repeatedly, perhaps with every message, much like a > message key. O.K. There's our description of the protocol. I'm talking about attacks in which the adversary substitutes his list of cipher for the list one side sent (More below). [...] > In my proposals, it is has been, and still is, unnecessary to > authenticate the cipher choice. No authentication mistake is possible > with respect to cipher choice. The ciphers themselves must be > authentic, but that is not a cipher-change protocol issue. I'm not sure what you mean. The adversary may modify the messages that influence the choice of cipher. It is the authenticity of these messages that is at issue, and the handling of these messages constitutes the cipher selection protocol. I'll show below why authentication is necessary. > >Over and over you've stated that the negotiation is > >secret, protected by a cipher. When did you note > >the need for authentication or name a MAC or > >signature? Now you say it's just like other cipher > >systems, such as public key ciphers. Ciphers provide > >poor authentication, and public key ciphers don't > >really provide any authentication at all. It is > >not the case that your claim of secrecy, protected > >by a cipher implies authentication. In fact it > >implies that you missed the attack. > > I have always said that the cipher-change negotiation must occur under > cipher. I am guilty of expecting that cipher system to be effective. > But I missed no attack, because there was and is no attack on the > cipher-change protocol itself, which is all I have been describing. So you've described the protocol: "In my proposal, one end sends a list; the other selects from that list". You've been clear that when a side sends the list, such communication is and under a cipher. Now I'll describe the attack on a system entirely consistent with your description. Suppose all parties are given an authentic certificate for Bob's public key. Alice sends her list of ciphers to Bob, encrypted under Bob's public key. Fred blocks the message from Alice and substitutes his own list consisting of one cipher he knows to be on Bob's list. Bob, as the description specifies, selects a cipher from the list. So just as you described, the negotiation is protected by a cipher. Just as you wrote "In my proposal, one end sends a list; the other selects from that list". Thus Fred has achieved the chosen cipher attack, within the protocol you described. As you noted, we have to assume the initial cipher is effective; ciphers provide privacy and the example above grants that the cipher is effective. > You seem to have several big problems here, the first being the > possibility that I missed something, and so deserve your castigation. More like: you missed something and so should recognize it now and fix it. > Well, I did *not* miss what you think I did, but even if I had, who > elected you God? If you had found a factual problem, you could > present that. Instead, you cop an attitude and distort reality, both > of which are way out of line. I introduced the issue simply as a matter of fact. Over and over you refused to see it, and acted like I and others didn't know what we were talking about. > >> Whatever > >> cipher system has been established will authenticate > >> received messages > >> in some way (often with a hash of the plaintext), > >> and thus will detect > >> "any" attempt by an attacker to "modify the messages." > > > >Now you're starting to get it. This authentication > >was completely missing from your suggestion before > >others pointed out the problem. > > There was and is no problem, and what was pointed out was wrong. If > the public-key certification or message authentication is bad, the > original security is bad, and there is no protection for the raw > plaintext that we are trying to protect, so cipher-change negotiation > is the least of the problems. As I asked before - if you had message authentication on the negotiation, please just cite it. You keep saying it's protected by a cipher. Got the privacy; where's the authentication? > Your peculiar concentration on "authentication" obscures the real > problem, and that problem is that the original cipher must be secure > in many ways, including algorithm, key, and implementation. But the problem at issue is that the protocol you described grants the adversary's choice even when we assume these components are sound, as shown. > Where did > *you* ever say that *those* were required? But they *are* required, > and you missed those "attacks." Tsk, tsk. Yes, the protocol could fail because of one of these components. The issue here is protocol failure. > >Yes, it can be fixed, > >but the actual protocol design is not the simple > >exercise you had thought. > > The protocol is *just* as simple as I first proposed. There is > essentially no protocol there at all: We just select at random from a > list. And now we've seen that this doesn't work well without the authentication mechanism. > The design part of this is the construction of a hidden command > channel behind the plaintext, the various messages and retained state > required to perform a clean transition, and I believe, the ability to > withstand message loss without problem. This does require some > design, and failure here means we will not change ciphers, or may do > so in regular ways. As shown, failure can grant the adversary his choice of the ciphers, though as I noted in a previous post, the cipher does have to be from Bob's approved list. > In other words, the *worst* that can happen from a bad cipher-change > protocol is that we end up using one cipher repeatedly, which is the > *normal* situation now. Failure in the protocol is thus only a > failure to take advantage of new cipher-change strength, and not an > introduction of weakness. Shown false. [...] > It was clear enough for almost everyone else who read my proposals. > Stop pretending that you have contributed something important. You > have not. Stop pretending that I have ignored or dissembled about a > real problem. I have not. It certainly wasn't clear to you. Even after people suggested the possibility of the attacker influencing the cipher, you insisted that the secret negotiation under a cipher ruled this out. But look at the example - the messages are secret under a cipher and the attacker still gets his choice. As I wrote the first time I brought this up: Ciphers by themselves offer poor authentication, and the authentication of the selection channel is far more important than its privacy. If I can find a way to forge, I can get you to use _my_ choice of your ciphers. > As far as I know, the only real problem which came up was the need for > additional protection for the command channel, beyond that used for > the plaintext. That was pointed out by "others," not me. But that is > not your "authentication," and it is easily fixed. And the problem I noted is easily fixed. Your persistence in stating that the channel is protected a cipher and never noting an authentication mechanism baffles me. > >The cipher agility of your actual systems is far behind > >the state of the art. > > "Cipher agility" would seem to mean the ability to change ciphers > quickly. Any system which can do this is *beyond* the current state > of the art. My proposals thus *are* the state of the art in > non-government cryptography. But you cited your commercial systems, which have no cipher agility at all. [...] > >Your commercial > >ciphers contradict such claims. > > I'm a little confused here: Are you saying that I have produced > ciphers of such complexity that they obviously were not easy to > design? Guilty. No, I'm saying the commercial ciphers you cited are far behind the state of art in cipher agility. If you believe so strongly that protocols should allow many ciphers, and also that the design is not so hard, why are they so monolithic? > Actually, my ciphers are fairly simple, as serious systems go. But > the design and actual implementation of real cipher systems is not > easy. Perhaps you should try it, so we can see how well *you* do. That's most of what I do for a living. [...] > Frankly, since your years-ago claim to have a break for my Fenced DES > Cipher broke down in your own failure, you have been hard to live > with. When you first wrote that I claimed to "break" Fenced DES, I immediately corrected you. I called my analysis successful because it showed your security analysis was wrong. I was entirely clear on what my attack did - and you know it. > The reality is that I produced a design which, in the end, > withstood your attacks; I built a cipher which you thought you could > break, but could not. I'm sure it was very embarrassing for you. You produced a defective design, as I showed. How many times have you written that a block cipher should simulate a large random permutation? Now we know Fenced DES does not do what a block cipher should. You tried to make my analysis look like failure by making things up and saying I said them; you even had quotation marks around claims you fabricated. Do you think that by now I've forgotten that you wrote them and I didn't? > But > everyone makes mistakes, and those of us who speak out are especially > exposed; most of us accept reality and move on. Get over it. Me get over it? I don't think I've brought up your pathetic dishonesty in years. You keep inserting Fenced DES into completely unrelated discussions so you can once again lie about what I wrote. --Bryan Sent via Deja.com http://www.deja.com/ Before you buy.
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Sat, 13 Nov 1999 01:30:02 GMT From: ritter@io.com (Terry Ritter) Message-ID: <382cbf12.6376301@news.io.com> References: <80fv65$rvt$1@nnrp1.deja.com> Newsgroups: sci.crypt Lines: 450 On Fri, 12 Nov 1999 02:48:38 GMT, in <80fv65$rvt$1@nnrp1.deja.com>, in sci.crypt bryan.olson@uptronics.com wrote: >Terry Ritter wrote: >> bryan.olson@uptronics.com wrote: >[...] >> In my proposals, it is has been, and still is, unnecessary to >> authenticate the cipher choice. No authentication mistake is possible >> with respect to cipher choice. The ciphers themselves must be >> authentic, but that is not a cipher-change protocol issue. > >I'm not sure what you mean. The adversary may modify the >messages that influence the choice of cipher. It is the >authenticity of these messages that is at issue, and the >handling of these messages constitutes the cipher selection >protocol. I'll show below why authentication is necessary. There is something seriously wrong with a cipher system which allows messages to be substituted by anyone who happens to have a non-secret public key. This is an issue in public-key cryptography which is not normally present in secret-key cryptography. In secret-key cryptography, if more than two users share a key, it is quite clear that multiple source options exist for any message which is sent. This is clear. The issue of deception, then, is due to public-key cryptography, and so must be (and generally will be) handled in any system which uses that technology. Having a system where anyone can masquerade as anyone else is simply insane. Or perhaps you are assuming that the issue *cannot* be handled in public-key cryptography, which would be an interesting result. This is not an issue for the cipher-change protocol. It *is* an issue which must be considered in every public-key design. >[...] >So you've described the protocol: "In my proposal, one >end sends a list; the other selects from that list". >You've been clear that when a side sends the list, >such communication is and under a cipher. Now I'll >describe the attack on a system entirely consistent >with your description. > >Suppose all parties are given an authentic certificate >for Bob's public key. Alice sends her list of ciphers >to Bob, encrypted under Bob's public key. Fred blocks >the message from Alice and substitutes his own list >consisting of one cipher he knows to be on Bob's list. >Bob, as the description specifies, selects a cipher >from the list. > >So just as you described, the negotiation is protected >by a cipher. While you claim to have assumed that the negotiation is "protected," in reality you have not made any such assumption. Any cipher system which allows anyone at all to pretend they are the other party to a particular communication is inherently insecure. The cipher change protocol is hardly the issue. >Just as you wrote "In my proposal, one >end sends a list; the other selects from that list". >Thus Fred has achieved the chosen cipher attack, within >the protocol you described. As you noted, we have to >assume the initial cipher is effective; ciphers provide >privacy and the example above grants that the cipher >is effective. The initial ciphering system was, by your description, remarkably ineffective. That seems to be an issue for the cipher system design, rather than any particular cipher, or any plaintext protocol under the cipher. Again, that issue does not come up when we have a single pair of nodes operating under secret key. The issue for public-key cryptography, then, is to provide a protocol which does provide security. And when that is provided, the cipher-change protocol I proposed will be fine, perhaps with some additional protection, which, as you have previously noted, was suggested by "others." >> You seem to have several big problems here, the first being the >> possibility that I missed something, and so deserve your castigation. > >More like: you missed something and so should recognize >it now and fix it. No, you found something which is probably well-known in public-key design, and have attempted to use it to fault a level at which it does not apply. >> Well, I did *not* miss what you think I did, but even if I had, who >> elected you God? If you had found a factual problem, you could >> present that. Instead, you cop an attitude and distort reality, both >> of which are way out of line. > >I introduced the issue simply as a matter of fact. >Over and over you refused to see it, and acted like >I and others didn't know what we were talking about. Small wonder. >> >> Whatever >> >> cipher system has been established will authenticate >> >> received messages >> >> in some way (often with a hash of the plaintext), >> >> and thus will detect >> >> "any" attempt by an attacker to "modify the messages." >> > >> >Now you're starting to get it. This authentication >> >was completely missing from your suggestion before >> >others pointed out the problem. >> >> There was and is no problem, and what was pointed out was wrong. If >> the public-key certification or message authentication is bad, the >> original security is bad, and there is no protection for the raw >> plaintext that we are trying to protect, so cipher-change negotiation >> is the least of the problems. > >As I asked before - if you had message authentication on >the negotiation, please just cite it. Message authentication is *not* -- and should not be -- part of the cipher-change protocol, but I would assume that there would be error-detection, at least, for the delivered message (including hidden protocol messages). That allows us to detect any change in transit. But that is not your issue. Your issue is that someone may send a message which appears to be from our far end, but is not. Unfortunately, if that issue is not resolved at a higher level, it probably will not be resolved by particular plaintexts, except perhaps when we can say, "remember what we did after that party last spring," and then get the right answer. But even that assumes there no MITM, the possibility of which must have been eliminated at the higher level. Which means no such possibility exists for the cipher-change protocol. >You keep saying >it's protected by a cipher. Got the privacy; where's >the authentication? Any cipher system which uses ciphers must protect against masquerade. Obviously. This is a level above plaintext secrecy, and way above cipher-change negotiation. >> Your peculiar concentration on "authentication" obscures the real >> problem, and that problem is that the original cipher must be secure >> in many ways, including algorithm, key, and implementation. > >But the problem at issue is that the protocol you >described grants the adversary's choice even when we >assume these components are sound, as shown. False. You have assumed an insecure system. The result is insecure. Congratulations on your insight. >> Where did >> *you* ever say that *those* were required? But they *are* required, >> and you missed those "attacks." Tsk, tsk. > >Yes, the protocol could fail because of one of these >components. The issue here is protocol failure. > > >> >Yes, it can be fixed, >> >but the actual protocol design is not the simple >> >exercise you had thought. >> >> The protocol is *just* as simple as I first proposed. There is >> essentially no protocol there at all: We just select at random from a >> list. > >And now we've seen that this doesn't work well without >the authentication mechanism. Now we see that the cipher-change protocol does require that the cipher system provide security. Without that, the cipher system cannot provide the privacy we expect. >> The design part of this is the construction of a hidden command >> channel behind the plaintext, the various messages and retained state >> required to perform a clean transition, and I believe, the ability to >> withstand message loss without problem. This does require some >> design, and failure here means we will not change ciphers, or may do >> so in regular ways. > >As shown, failure can grant the adversary his choice of >the ciphers, though as I noted in a previous post, the >cipher does have to be from Bob's approved list. As described, no cipher system which allows such action can possibly be secure or private. We certainly expect better for our plaintext, and the cipher-change protocol is just more plaintext. >> In other words, the *worst* that can happen from a bad cipher-change >> protocol is that we end up using one cipher repeatedly, which is the >> *normal* situation now. Failure in the protocol is thus only a >> failure to take advantage of new cipher-change strength, and not an >> introduction of weakness. > >Shown false. Itself shown false. >[...] >> It was clear enough for almost everyone else who read my proposals. >> Stop pretending that you have contributed something important. You >> have not. Stop pretending that I have ignored or dissembled about a >> real problem. I have not. > >It certainly wasn't clear to you. Even after people >suggested the possibility of the attacker influencing the >cipher, you insisted that the secret negotiation under >a cipher ruled this out. But look at the example - the >messages are secret under a cipher and the attacker still >gets his choice. As I wrote the first time I brought >this up: > > Ciphers by themselves offer poor authentication, and > the authentication of the selection channel is far > more important than its privacy. If I can find a way > to forge, I can get you to use _my_ choice of your > ciphers. As I noted many times, masquerade must be made impossible, and this actually must be impossible, in any real security system. Since public-key technology opens the door, public-key technology is responsible for somehow closing it. Only then do we have a secure cipher, and only then does it support plaintext and plaintext cipher-change messages. >> As far as I know, the only real problem which came up was the need for >> additional protection for the command channel, beyond that used for >> the plaintext. That was pointed out by "others," not me. But that is >> not your "authentication," and it is easily fixed. > >And the problem I noted is easily fixed. Your >persistence in stating that the channel is protected >a cipher and never noting an authentication mechanism >baffles me. Since you ask for a solution this quandary, my guess would be that you have had little experience with secure system design above the cipher level. The minimal discussion of this sort of thing is one of the problems I have with the conventional crypto references. >> >The cipher agility of your actual systems is far behind >> >the state of the art. >> >> "Cipher agility" would seem to mean the ability to change ciphers >> quickly. Any system which can do this is *beyond* the current state >> of the art. My proposals thus *are* the state of the art in >> non-government cryptography. > >But you cited your commercial systems, which have no >cipher agility at all. *Of* *course* it is not in my old ciphers: If my *old* cipher systems had cipher agility, the cipher-change protocol would hardly be a *new* idea, now would it? On the other hand, it was my experience with those systems which eventually ripened into my protocols for improved security, which include frequent cipher-change, many ciphers, and multiciphering as a matter of course. >[...] >> >Your commercial >> >ciphers contradict such claims. >> >> I'm a little confused here: Are you saying that I have produced >> ciphers of such complexity that they obviously were not easy to >> design? Guilty. > >No, I'm saying the commercial ciphers you cited are >far behind the state of art in cipher agility. Then you have a remarkably strange idea of "cipher agility." But apparently you are granting some significant advantage to those systems which switch between 4 or 5 known ciphers. This is fine as far as it goes, but I would like to see at least 100 ciphers, used in 3 independent levels, giving 100**3 = 1,000,000 possible ciphering processes. >If you >believe so strongly that protocols should allow many >ciphers, and also that the design is not so hard, why >are they so monolithic? Could that be because my ciphers are *old* designs? >> Actually, my ciphers are fairly simple, as serious systems go. But >> the design and actual implementation of real cipher systems is not >> easy. Perhaps you should try it, so we can see how well *you* do. > >That's most of what I do for a living. Odd. Clearly you don't publish stuff others can use or learn from or criticize. And yet *you* obviously love to criticize. It does seem a bit one sided. >[...] >> Frankly, since your years-ago claim to have a break for my Fenced DES >> Cipher broke down in your own failure, you have been hard to live >> with. > >When you first wrote that I claimed to "break" Fenced >DES, I immediately corrected you. I called my analysis >successful because it showed your security analysis was >wrong. I was entirely clear on what my attack did - >and you know it. Well, now, let's just see: from http://www.io.com/~ritter/NEWS/HUGEBLK.HTM#HB16, near the middle: "That's as far as I'll take the attack for now. Perhaps I've misunderstood something about the design; please let me know if any of the steps I've described is impossible. I'll elaborate if parts of my explanation are unclear. If as much as I've described can be done, I certainly think it's a strong enough toe-hold for the analyst that Fenced DES is dead." from http://www.io.com/~ritter/NEWS/HUGEBLK.HTM#HB16, at the bottom: "I think I probably have a few numbers wrong in my analysis, but not so far wrong as invalidate the attack on Fenced DES." So we have "Fenced DES is dead" and the (clearly implied) "I have a valid attack on Fenced DES." Both of these seem remarkably clear to me. But anyone who wishes to follow your slimy claims and word-weaseling can do so for themselves: http://www.io.com/~ritter/NEWS/HUGEBLK.HTM http://www.io.com/~ritter/FENCED.HTM >> The reality is that I produced a design which, in the end, >> withstood your attacks; I built a cipher which you thought you could >> break, but could not. I'm sure it was very embarrassing for you. > >You produced a defective design, as I showed. Nonsense. My cipher did not succumb to an attack which you thought would work. Nor is the cipher is weaker because of your attack. My cipher won, you lost, it's as simple as that. It is true that your approach was unexpected to me. It is true that you started out making significant headway. That you were unable to finish in fact clarified a major advantage to layered ciphers: One layer in a cipher may cause an attacker to "commit" in terms of available information in a way which then prevents the solution of another layer. This is not an error -- that is the way layered systems work, and understanding this is a step ahead in cipher design. If it had turned out that the cipher was weaker because of your attack, then the cipher would have been flawed. It did not so turn out. And while I would include more mixing layers in any new design, the old design proudly stands as it is. Various descriptions of Fenced DES can be found in the Technical Articles by Ritter section of my pages: http://www.io.com/~ritter/#TechnicalArticles >How >many times have you written that a block cipher >should simulate a large random permutation? Many times. >Now we >know Fenced DES does not do what a block cipher >should. You Any real design is an approximation of the desired goal. Perhaps it could be better, but as far as you are concerned, it is more than good enough. >tried to make my analysis look like >failure by making things up and saying I said them; >you even had quotation marks around claims you >fabricated. Do you think that by now I've >forgotten that you wrote them and I didn't? In one case, as I recall, quoted words provided the essence of your argument and were correct in context. For anyone to follow your argument, and see the reasoning beyond your claims, so they could see how the claims could be refuted, a concise summary was needed. You did not provide that. I did. I make no apologies for it, nor was I misrepresenting either your position, or your words. You're just whining because the quoted position did in fact represent your position, and that position was wrong. As always, I provide extensive referencing to the original material, which is available both from me and from independent news sites. In context, it should be very clear where the words originate, but if not, the original message will clear that up absolutely. If I was trying to obscure the source material or misstate the reference, I would hardly make it so very easy to follow the reference back. >> But >> everyone makes mistakes, and those of us who speak out are especially >> exposed; most of us accept reality and move on. Get over it. > >Me get over it? I don't think I've brought up >your pathetic dishonesty in years. OK, that's about it. I don't think I need to hear any more from you. >You keep >inserting Fenced DES into completely unrelated >discussions so you can once again lie about what >I wrote. What you wrote is archived on my own site, so I could hardly lie about it. But as far as I know, *you* don't maintain publicly-accessible archives, and so are free to misrepresent the past with some impunity. Until someone reminds you of reality, of course. --- Terry Ritter ritter@io.com http://www.io.com/~ritter/ Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Mon, 15 Nov 1999 01:15:53 GMT From: bryan.olson@uptronics.com Message-ID: <80nms7$2ms$1@nnrp1.deja.com> References: <382cbf12.6376301@news.io.com> Newsgroups: sci.crypt Lines: 233 First let me say I'm snipping a lot since this has gotten very long. I invite readers to check backwards for more context, since my interpretation of what is significant may differ from others. I see the same point over and over. Terry Ritter says that the communications that negotiate the choice of cipher(s) are under a cipher. I point out that ciphers imply secrecy, but not authentication, and thus the attacker can influence the choice of cipher. Here's a sampling: ritter@io.com (Terry Ritter) wrote: > sci.crypt bryan.olson@uptronics.com wrote: > >Terry Ritter wrote: [Bryan:] > > It is the > >authenticity of these messages that is at issue, and the > >handling of these messages constitutes the cipher selection > >protocol. I'll show below why authentication is necessary. > > There is something seriously wrong with a cipher system which allows > messages to be substituted by anyone who happens to have a non-secret > public key. I suggested an attack that works even given the communication is under cipher, though I assumed the cipher protects only the privacy of the messages. > >[...] > >So you've described the protocol: "In my proposal, one > >end sends a list; the other selects from that list". > >You've been clear that when a side sends the list, > >such communication is and under a cipher. Now I'll > >describe the attack on a system entirely consistent > >with your description. > > > >Suppose all parties are given an authentic certificate > >for Bob's public key. Alice sends her list of ciphers > >to Bob, encrypted under Bob's public key. Fred blocks > >the message from Alice and substitutes his own list > >consisting of one cipher he knows to be on Bob's list. > >Bob, as the description specifies, selects a cipher > >from the list. > > > >So just as you described, the negotiation is protected > >by a cipher. > > While you claim to have assumed that the negotiation is "protected," > in reality you have not made any such assumption. Any cipher system > which allows anyone at all to pretend they are the other party to a > particular communication is inherently insecure. The cipher change > protocol is hardly the issue. [...] > The initial ciphering system was, by your description, remarkably > ineffective. Obviously it was effective for authentication, but I assumed it was effective for privacy. [...] > Message authentication is *not* -- and should not be -- part of the > cipher-change protocol, but I would assume that there would be > error-detection, at least, for the delivered message (including hidden > protocol messages). That allows us to detect any change in transit. > > But that is not your issue. Your issue is that someone may send a > message which appears to be from our far end, but is not. Exactly! And specifically, that your statement of the design that has these early messages under a cipher does not imply protection against such an attack. Anyway, my references are clear that a "cipher" provides secrecy but does not imply authentication. I think Ritter's own crypto glossary agrees. See: http://www.io.com/~ritter/GLOSSARY.HTM On other matters: [...] > >But you cited your commercial systems, which have no > >cipher agility at all. > > *Of* *course* it is not in my old ciphers: If my *old* cipher systems > had cipher agility, the cipher-change protocol would hardly be a *new* > idea, now would it? Hey, you cited these. They are poor examples. [...] > >> Actually, my ciphers are fairly simple, as serious systems go. But > >> the design and actual implementation of real cipher systems is not > >> easy. Perhaps you should try it, so we can see how well *you* do. > > > >That's most of what I do for a living. > > Odd. Clearly you don't publish stuff others can use or learn from or > criticize. And yet *you* obviously love to criticize. It does seem a > bit one sided. There's plenty of my stuff for you to criticize. I've even proposed solutions to problems you posed. You have historically ignored my posts unless they were about your designs. > >[...] > >> Frankly, since your years-ago claim to have a break for my Fenced DES > >> Cipher broke down in your own failure, you have been hard to live > >> with. > > > >When you first wrote that I claimed to "break" Fenced > >DES, I immediately corrected you. I called my analysis > >successful because it showed your security analysis was > >wrong. I was entirely clear on what my attack did - > >and you know it. > > Well, now, let's just see: And below we do see - that you cannot find anything where I say my attack constituted a break. > from http://www.io.com/~ritter/NEWS/HUGEBLK.HTM#HB16, near the middle: > > "That's as far as I'll take the attack for now. Perhaps I've > misunderstood something about the design; please let me know if any > of the steps I've described is impossible. I'll elaborate if parts of > my explanation are unclear. If as much as I've described can be done, > I certainly think it's a strong enough toe-hold for the analyst that > Fenced DES is dead." > > from http://www.io.com/~ritter/NEWS/HUGEBLK.HTM#HB16, at the bottom: > > "I think I probably have a few numbers wrong in my analysis, but > not so far wrong as invalidate the attack on Fenced DES." > > So we have "Fenced DES is dead" and the (clearly implied) "I have a > valid attack on Fenced DES." Both of these seem remarkably clear to > me. But anyone who wishes to follow your slimy claims and > word-weaseling can do so for themselves: > > http://www.io.com/~ritter/NEWS/HUGEBLK.HTM > http://www.io.com/~ritter/FENCED.HTM And my posts explain exactly what the attack does, and never do I say what you claimed. [...] > >You produced a defective design, as I showed. > > Nonsense. My cipher did not succumb to an attack which you thought > would work. Nor is the cipher is weaker because of your attack. My > cipher won, you lost, it's as simple as that. > > It is true that your approach was unexpected to me. It is true that > you started out making significant headway. That you were unable to > finish in fact clarified a major advantage to layered ciphers: One > layer in a cipher may cause an attacker to "commit" in terms of > available information in a way which then prevents the solution of > another layer. This is not an error -- that is the way layered > systems work, and understanding this is a step ahead in cipher design. > > If it had turned out that the cipher was weaker because of your > attack, then the cipher would have been flawed. It did not so turn > out. And while I would include more mixing layers in any new design, > the old design proudly stands as it is. [...] > >tried to make my analysis look like > >failure by making things up and saying I said them; > >you even had quotation marks around claims you > >fabricated. Do you think that by now I've > >forgotten that you wrote them and I didn't? > > In one case, as I recall, quoted words provided the essence of your > argument and were correct in context. No they were not, and as I asked at the time, what do you think quotation marks mean? [...] > > Get over it. > > > >Me get over it? I don't think I've brought up > >your pathetic dishonesty in years. > > OK, that's about it. I don't think I need to hear any more from you. Do you recall the last time I introduced Fenced DES into a discussion? It was when John Savard came up with a similar design. I attacked his design and wrote what I believe is a completely fair note: | The structure of the cipher is very similar to | a couple that Terry Ritter suggested. He calls his | design "Fenced DES". The analysis above is similar | to work I did on one of Terry's ciphers. He agreed | the design had a problem but thought I oversold my | result. http://x23.deja.com/getdoc.xp?AN=372605719&search=thread&CONTEXT=9426263 69.664076315&hitnum=2 > >You keep > >inserting Fenced DES into completely unrelated > >discussions so you can once again lie about what > >I wrote. > > What you wrote is archived on my own site, so I could hardly lie about > it. Yes you can; it's just weird. You're trying to bluff about your up-cards. I immediately disagreed when you first wrote that I claimed to break Fenced DES. You still say it, and then support it with quotes where I never claimed what you said. "Toe- hold for analysis" sure. Do I think the design is dead? Yes I do. I didn't say what you claim; you know it; I know it; and anyone who checks an archive knows it. --Bryan Sent via Deja.com http://www.deja.com/ Before you buy.
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Mon, 1 Nov 1999 17:15:44 GMT From: sjmz@hplb.hpl.hp.com (Stefek Zaba) Message-ID: <FKJ3y9.E60@hplb.hpl.hp.com> References: <7v4sh2$ps2$1@blowfish.isaac.cs.berkeley.edu> Newsgroups: sci.crypt Lines: 59 In sci.crypt, David Wagner (daw@blowfish.isaac.cs.berkeley.edu) wrote: > The problem is that there are severe attacks on the SSL 2.0 protocol, > due to the non-cryptographic nature of the negotiation protocol. For > instance, an active attacker (a "man-in-the-middle") can edit Alice's > list of supported ciphers, removing all but the weakest one supported > by both endpoints (e.g., RC4-40-export); then Bob will be forced to > pick that weak one, and both ends will use the weak cipher. Even if > both endpoints support a stronger cipher, they won't know that they've > been silently forced down to "least-common-denominator security". These flaws certainly exist. That they've been found, broadly addressed in the SSL3.0 spec and further nailed down in TLS1.0 is a tribute to the open review process and to the work of many reviewers, including one D. Wagner :-) The resulting cipher negotiation process is, while not "minimal", pretty small - it passes the "back-of-the-envelope" test, and manages to define * a common process for establishing a "master secret" known to both parties, whose detailed establishment depends on the particular key agreement protocol but whose outcome is common; * a "key stretching" function used to derive session keys, IVs, and MAC values for each of the bulk ciphers and MACs The common mechanisms are designed "almost once", by which I mean that they are *not* reinvented for each new ciphersuite, but at worst once for a family of key establishment protocol (RSA, signed DH, anonymous DH), with a common key-stretching algorithm. Doing it right once removes many potential sources of error. The ciphersuite negotiation has been simplified from the SSL2.0 days: it's now as brutal as: initiator (client) sends ordered list (which, to David W's point later in the message excerpted above, had better contain ONLY algorithms the client considers adequate for its interaction); responder (server) picks exactly one, or aborts. There is *no* renegotiation or independent negotiation of particular attributes - cihpersuites come as a particular package of <key-agreement, bulk-cipher, MAC>. And the negotiation messages are themselves MAC'ed, defeating the simple active attack which SSLv2 was open to. Protection against protocol version rollback attack is also incorporated. Has it taken several iterations to define a robust negotiation protocol? Yes. (Apples-to-oranges comparison follows) Has it taken as much effort as has gone into even one AES candidate? I think not. One further simplification available to TLS and not to modem or PPP negotiations is that TLS/SSL can afford to refuse - rather than keep trying to find *some* ciphersuite they agree on (like modems going back through every ITU standard and bis, ter revision :-), they can - nay, the language of the TLS RFC encourages them to - throw up their little cyberhands in horror shouting "unclean! unclean!". Implementations still need to take care (as noted in David W's and Bruce S's 1996 SSL3.0 analysis paper) not to afford an attacker an abundance of matter derived closely from the master_secret, or to allow a "large" number of half-completed protocol runs which may signify an attempted interleaving attack - but the protection afforded by conformant TLS1.0 implementations, *including* the ciphersuite negotiations, is far from negligible. Now, if Vernon S and/or David W want to lay into the concept of cipher negotiation using TLS1.0 as the "standard of practice", I for one would be most interested in their enlightenment... Cheers, Stefek
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Tue, 02 Nov 1999 15:51:58 GMT From: dianelos@tecapro.com Message-ID: <7vn1as$2s0$1@nnrp1.deja.com> References: <FKJ3y9.E60@hplb.hpl.hp.com> Newsgroups: sci.crypt Lines: 25 In article <FKJ3y9.E60@hplb.hpl.hp.com>, sjmz@hplb.hpl.hp.com (Stefek Zaba) wrote: >The ciphersuite negotiation has been simplified from the >SSL2.0 days: it's now as brutal as: initiator (client) sends ordered >list (which, to David W's point later in the message excerpted above, >had better contain ONLY algorithms the client considers adequate for >its interaction); responder (server) picks exactly one, or aborts. >There is *no* renegotiation or independent negotiation of particular >attributes - cihpersuites come as a particular package of <key- >agreement, bulk-cipher, MAC>. And the negotiation messages are >themselves MAC'ed, defeating the simple active attack which SSLv2 was >open to. Protection against protocol version rollback attack is also >incorporated. In another message (see: http://www.deja.com/threadmsg_ct.xp?AN=540914195" ) I suggested to send a list of only *one* ciphersuite, i.e. not to send a list at all. If I send a message containing my information, it should be I who defines how to encrypt it - not the other party in some way. Security should not be negotiable. Sent via Deja.com http://www.deja.com/ Before you buy.
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Tue, 02 Nov 1999 18:56:23 GMT From: dscott@networkusa.net (SCOTT19U.ZIP_GUY) Message-ID: <7vn8k7$1svm$1@news.gate.net> References: <381F1625.E61A3C7F@aspi.net> <7vn1as$2s0$1@nnrp1.deja.com> Newsgroups: sci.crypt Lines: 59 In article <381F1625.E61A3C7F@aspi.net>, "Trevor Jackson, III" <fullmoon@aspi.net> wrote: >dianelos@tecapro.com wrote: > >> In article <FKJ3y9.E60@hplb.hpl.hp.com>, >> sjmz@hplb.hpl.hp.com (Stefek Zaba) wrote: >> >> >The ciphersuite negotiation has been simplified from the >> >SSL2.0 days: it's now as brutal as: initiator (client) sends ordered >> >list (which, to David W's point later in the message excerpted above, >> >had better contain ONLY algorithms the client considers adequate for >> >its interaction); responder (server) picks exactly one, or aborts. >> >There is *no* renegotiation or independent negotiation of particular >> >attributes - cihpersuites come as a particular package of <key- >> >agreement, bulk-cipher, MAC>. And the negotiation messages are >> >themselves MAC'ed, defeating the simple active attack which SSLv2 was >> >open to. Protection against protocol version rollback attack is also >> >incorporated. >> >> In another message (see: >> http://www.deja.com/threadmsg_ct.xp?AN=540914195" ) I suggested to send >> a list of only *one* ciphersuite, i.e. not to send a list at all. If I >> send a message containing my information, it should be I who defines >> how to encrypt it - not the other party in some way. Security should >> not be negotiable. > >Why do you care? If you choose a set of ciphers in which you trust you >*are* defining how to encrypt your information. > >If you are stuck at 3DES and the other person insists upon AES_1, will you >prefer to not communicate rather than communicate with a cipher other than >your favorite? > >Do you also have a preference for particular keys? > > I know I am getting in this late but if one person has his heart set on 3DES and another AES_! why not allow them to use both in series so that both methods can be used at once. David A. Scott -- SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE http://www.jim.com/jamesd/Kong/scott19u.zip Scott famous encryption website NOT FOR WIMPS http://members.xoom.com/ecil/index.htm Scott rejected paper for the ACM http://members.xoom.com/ecil/dspaper.htm Scott famous Compression Page WIMPS allowed http://members.xoom.com/ecil/compress.htm **NOTE EMAIL address is for SPAMERS***
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Tue, 02 Nov 1999 19:32:32 -0500 From: "Trevor Jackson, III" <fullmoon@aspi.net> Message-ID: <381F82A0.BF3299C3@aspi.net> References: <7vn8k7$1svm$1@news.gate.net> Newsgroups: sci.crypt Lines: 50 SCOTT19U.ZIP_GUY wrote: > In article <381F1625.E61A3C7F@aspi.net>, "Trevor Jackson, III" <fullmoon@aspi.net> wrote: > >dianelos@tecapro.com wrote: > > > >> In article <FKJ3y9.E60@hplb.hpl.hp.com>, > >> sjmz@hplb.hpl.hp.com (Stefek Zaba) wrote: > >> > >> >The ciphersuite negotiation has been simplified from the > >> >SSL2.0 days: it's now as brutal as: initiator (client) sends ordered > >> >list (which, to David W's point later in the message excerpted above, > >> >had better contain ONLY algorithms the client considers adequate for > >> >its interaction); responder (server) picks exactly one, or aborts. > >> >There is *no* renegotiation or independent negotiation of particular > >> >attributes - cihpersuites come as a particular package of <key- > >> >agreement, bulk-cipher, MAC>. And the negotiation messages are > >> >themselves MAC'ed, defeating the simple active attack which SSLv2 was > >> >open to. Protection against protocol version rollback attack is also > >> >incorporated. > >> > >> In another message (see: > >> http://www.deja.com/threadmsg_ct.xp?AN=540914195" ) I suggested to send > >> a list of only *one* ciphersuite, i.e. not to send a list at all. If I > >> send a message containing my information, it should be I who defines > >> how to encrypt it - not the other party in some way. Security should > >> not be negotiable. > > > >Why do you care? If you choose a set of ciphers in which you trust you > >*are* defining how to encrypt your information. > > > >If you are stuck at 3DES and the other person insists upon AES_1, will you > >prefer to not communicate rather than communicate with a cipher other than > >your favorite? > > > >Do you also have a preference for particular keys? > > > > > > I know I am getting in this late but if one person has his heart set on > 3DES and another AES_! why not allow them to use both in series so > that both methods can be used at once. I believe that cipher stacking or layering is an appropriate solution to this kind of dispute. But I suspect you still need to resolve the original issue, selecting ciphers dynamically, because I may decide that to change the cipher that I selected. In order to do so I have to make a new selection from within the intersection of the cipher I'm willing or able to use and the cipher's my respondent is willing to use. Layering helps by preventing arguments, but it still leaves the original issue open
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Tue, 02 Nov 1999 23:13:47 GMT From: dianelos@tecapro.com Message-ID: <7vnr77$ncc$1@nnrp1.deja.com> References: <381F1625.E61A3C7F@aspi.net> <7vn1as$2s0$1@nnrp1.deja.com> Newsgroups: sci.crypt Lines: 48 In article <381F1625.E61A3C7F@aspi.net>, "Trevor Jackson, III" <fullmoon@aspi.net> wrote: > dianelos@tecapro.com wrote: >>In another message (see: >>http://www.deja.com/threadmsg_ct.xp?AN=540914195" ) I suggested to >>send a list of only *one* ciphersuite, i.e. not to send a list at >>all. If I send a message containing my information, it should be I >>who defines how to encrypt it - not the other party in some way. >>Security should not be negotiable. > >Why do you care? If you choose a set of ciphers in which you trust you >*are* defining how to encrypt your information. I see your point, but this wouldn't work with email for example. Here the choice of cipher must be made by me alone. >If you are stuck at 3DES and the other person insists upon AES_1, will >you prefer to not communicate rather than communicate with a cipher >other than your favorite? Well, if I trust 3DES and don't trust AES1 then I should be able encrypt my messages with 3DES only. Communication will always be possible if, as I suggested, there exists a public repository of ciphersuits where executable code or source code can be downloaded. This repository must be super-certified; can include recommendations by cryptologists; must include code in Java but can also include code optimized for different operating environments, etc. The big advantage here is simplicity and flexibility. I don't have to define a complicated ciphersuite negotiating protocol today; in the future this protocol itself may prove to have been a bad choice. Having to change a standard protocol that negotiates the ciphersuite is almost as costly as changing a standard ciphersuite. By appending to the data a pointer to the method that must be used to process them I buy insurance for the long run. We still have a critical component though: the certification of the ciphersuites. > Do you also have a preference for particular keys? Actually I might: several ciphers have a handful of "weak" keys; I may be paranoid and want to use a key exchange protocol that checks for them. Sent via Deja.com http://www.deja.com/ Before you buy.
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Wed, 03 Nov 1999 17:34:38 -0500 From: "Trevor Jackson, III" <fullmoon@aspi.net> Message-ID: <3820B87E.6EACA1DD@aspi.net> References: <7vpebt$qsa$1@nnrp1.deja.com> <381F84DD.ED21F158@aspi.net> <7vnr77$ncc$1@nnrp1.deja.com> Newsgroups: sci.crypt Lines: 146 dianelos@tecapro.com wrote: > In article <381F84DD.ED21F158@aspi.net>, > "Trevor Jackson, III" <fullmoon@aspi.net> wrote: > > dianelos@tecapro.com wrote: > >> I see your point, but this wouldn't work with email for example. Here > >> the choice of cipher must be made by me alone. > > > >How so? In a PK environment one would publish one's cipher set along > >with one's public key. It's still the intersection of the cipher sets > >of the two parties. > > Let's see: Normally, I compose the message and encrypt it off-line, > then I connect to Internet and send all my mail in batch mode. Good, that means you already have obtained the public keys of all of the recipients of your messages. When you got their public keys you also got their supported cipher list. > Oh, I > suppose I could encrypt it after connecting to the Internet and after > downloading a certified set of each addressee's set of ciphers and > choosing a cipher for each one. Why would you want to choose? It would normally be completely automatic to the point of transparency. All you have to do is order (sort or prioritize) your own list. > I suppose this can be done, but it > looks complicated. What if none of the ciphers in one addresse's set is > trusted by me? Then you cannot communicate. This problem is not created by having multiple ciphers supported at each end. This problem is created by having users insist upon particular ciphers. Note that if you insist upon ciphers {A1, A2, A3 } and your respondent insists upon { B1, B2 }, they you can still communicate securely in both your opinions, by using two ciphers, one of yours and one of his. Both of you will believe that the doubly encuphered messages are secure. If you _lack_ the cipher agility just described, you cannot ever convince both participants that their messages are secure. > What if my addressee does not have public keys? Then, as now, you would need to obtain a secret key from him. With the secret key comes the set of his ciphers. > What if my addressee uses a different PK protocol? Then you can't talk anyway. > What if I want to send one > message to 100 destinations? You have to encipher multiple times anyway because using the same key for broadcast messages creates an opportunity for attack. I'm not a protocol expert, barely even a student. But I know there's weakness in reusing message keys whether serially or in parallel. > More importantly: what if the standard (or widely used) PK system > suffers a catastrophic failure in the future? Yeah, what if? The ensuing disturbance would have nothing to do with cipher agility. > This is more probable to > happen with PK than with a symmetric cipher. Therefore it is even more > important to be able to change PK environments. Probably true. But AFAIK there is no reason to believe we can create "many" PK systems, whereas there is good reason to believe that we can create "many" symmetric ciphers. > > > (...) > >I would fear such a central repository. It adds a third party to the > >system, and that third party is going to be vulnerable to attacks that > >the original parties would not. > > A third party is not necessary if a group of people stick to a few > ciphersuites. Then I just have to name one key exchange protocol (or > several to be executed in parallel) and one cipher (or several to be > executed in series). Also consider that a PK environment normally > involves third parties too. In a networked world third parties are a > fact of life. Sure. As a key respository. Not as a repository for security implementations. The two aren;t anywhere near comparable. > > > Now, I don't claim that my suggestion is the best solution or that > public servers are an indispensable component to any solution. What I > do claim is that it is worthwhile to think about the feasibility of a > "protocol of protocols". I want to be able in the future to dynamically > change ciphersuites as a defense against unforeseen attacks and > catastrophic failures. The Y2K error is so costly because so many > programs all around the world are using one single, stupid (and de > facto standard) data structure. We should learn from that experience > and try to avoid a situation in the future where somebody discovers > that a standardized cryptographic primitive that forms part of almost > all security software is useless. In other words let us define a high > level standard that explains how to change a low level standard. An extremely ambitious goal. > > > >I also have an aversion to downloading security code on demand. It > >appears to me to be the inverse of a trojan. instead of an opponent > >penetrating my firewalls, security, permissions, etc. by subterfuge. I > >actually invite them in by regularly replacing the critical security > components of my infrastructure from an external source. > > Trojan horses are a huge problem but I wonder if a few trusted central > servers of certified code would not work *against* Trojan attacks. In > my original message I suggested that you should be able to instruct > your "code downloader" to only fetch code trusted by you. For example, > you could instruct it to only download code certified by NIST or, if > you prefer, by Schneier as well as by Shamir. Also *all* ciphersuites > in the central servers should be in source code too - a big problem > (but not insurmountable) for Trojan Horse designers. Finally, loading > new code can be a fully manual process. > > Anyway, I see what you mean. In many cases you would never want to use > the centralized code servers but you would be glad they are there just > in case something extraordinary happens. For example: many applications > will happily use the AES main winner as the only symmetric cipher > primitive. Other more conservative applications may include code for > both the AES-1 and the AES-2 winner (assuming NIST does choose two > winners), just in case that something very bad happened to AES-1. Now > you may argue that it is highly unlikely, but it is still realistically > possible that both AES-1 and AES-2 suffer a sudden catastrophic failure > in 50 years time. Then you will want to be able to instruct your > application to download the new cipher X from a centralized server - or > at least be able to introduce cipher X directly into the application. > Let us trust in standards, but let us also be prepared. > > Sent via Deja.com http://www.deja.com/ > Before you buy.
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: 23 Oct 1999 23:29:33 -0600 From: vjs@calcite.rhyolite.com (Vernon Schryver) Message-ID: <7uu5ft$f7v$1@calcite.rhyolite.com> References: <3812005b.8360995@news.io.com> Newsgroups: sci.crypt Lines: 162 In article <3812005b.8360995@news.io.com>, Terry Ritter <ritter@io.com> wrote: > ... >>How can you point to modems as a good example of the wonders of negotiating >>protocols? I think the politics and sausage warning applies. > >I think the real world applies: We have such modems. We use them. >They work. End of story. That might be the end of a fairy tale or a nightmare, but I thought you were talking about engineering. Modems do not work all of the time. A cipher negotiating protocol that failed as often as modems fail today in real life would not be something I'd want to trust my phone bill to, not to mention something that matters. > ... >I doubt I implied that modem negotiation is "clean." But it *is* >"background," and it *is* negotiation (both sides participate in the >final result), and it *is* "real world" -- it generally works in >practice. The "it generally works in practice" can be said about PPP, only more so. And again, who wants a cipher negotiating protocol that "generally works in practice"? Only salescritters or people with no technical knowledge can claim that either PPP or modems are examples that could cause a working engineer to be enthusaistic about negotiating ciphers. Sane, technically inclined people who look at modems, PPP, or any other "standardized", dynamic negotiating network protocol must be very skeptical of the idea. >Cipher negotiation can be far cleaner -- provided a single selection >mechanism is standardized. If not, then we may see the same sort of >ad hoc stuff we saw with modems. But "ad hoc" modem negotiation was your counter to the 10+ years of public experience with offically standardized, carefully architected, designed and tested PPP. As for "can be cleaner...", those words echo what was said about standardizing the negotiations between wide area routers in the leased-line IETF WG that was merged with the SLIP-replacment WG in about 1987 to form what is now the PPP working group. I think users are better served by the result (PPP) than by the old proprietary protocols, but no one can call PPP clean--at least no one honest and with a clue. Maybe Communism will work the next time it's tried too. But my money is on standards committees behaving like committees. > ... >I would say, "let's not do it like PPP." Exactly how would you do that? The problems with PPP negotiating are not any single technical issue, but the inevitable morass that comes with complicated network stuff in the best possible circumstances. >>I don't understand the "background" bit about cipher negotiating, since >>for all of modems, PPP, and ciphers, until the parties agree, the main >>event cannot work, and that's not exactly "background" > >Indeed, you do not understand the term "background," presumably >because you have not done your homework. I suggest actually reading >messages before disparaging their ideas. You might also look into my >recent article in IEEE Computer: > > http://www.io.com/~ritter/ARTS/R8INTW1.PDF > >or the previous discussion, which I have archived on my pages: > > http://www.io.com/~ritter/NEWS4/LIMCRYPT.HTM > >Here, "background" approximately means "not apparent to the user." >That is just what modem negotiation is about, although we may hear >modems, and need not hear or see cipher negotiation. > >To start any conversation in cipher, it is currently necessary to >acquire common keys. Everyone understands this. So everyone should >be well prepared to understand that we can *also* acquire a cipher >name, or even a cipher itself, in the same way, through the same >channel. This is not a big conceptual leap. > >Once we have a conversation in cipher, we can assign part of it to a >"control channel," where negotiation takes place (generally, although >not necessarily) hidden from the user. That would be "background" >cipher negotiation. > >Because the need is to change ciphers frequently, the desired >negotiation process is not one-time at the start, but rather, a >frequent or continuous process in different messages or sessions. Before repeating your old line yet again, you should do your own homework, which is to actually investigate at least one real, deployed network protocol that does the negotiating of the sort that you say is so easy. And by "investigate," I don't mean merely read some user documentation or repeat your dreams of how things would turn out if only people would listen to you. As for your "background" stuff--take your own advice and read what you are responding to before pontificating about homework. No matter on what "ground" the cipher negotiating is done, once the sender decides to switch to another cipher, data must soon stop flowing until the new cipher has been negotiated. You can call the cipher negotiating "background" if you want, but when the user-data stops flowing the notion is ... strained. When one party decides a new cipher is required, you must fairly soon either use a new cipher or stop moving data. Otherwise think what a bad guy could do. >>...well, not exactly >>for PPP, which, for example has the CCP (comopression) which is supposed to >>be negotiated in parallel with the main NCP's, which can start sending >>data before CCP converges. That is what the PPP implementations I've >>worked on do, but plenty of others don't. Again, theory vs. practice. > >I am a working engineer. > >Theory vs. practice. Shouldn't a working engineer know about the common, existing, widely *practiced* examples of the thing he is proposing? SSL is a closer example than modems or PPP. (I picked PPP because I know more about PPP than SSL.) Do you care to say something about SSL that will convince people that negotiating ciphers is a great idea? > ... >Well, since you are a "real designer," I'll just let you wander on in >your monomanical tirade, while I suggest that we *not* do things like >PPP. The biggest trouble with PPP is that it is a standardized network thing. Network things that are standards are always at least 95% politics, by which I mean everything that comes with design by committee and approval by standards committees. Negotiating ciphers such as you have proposed would necessarily be network things. Your repeated appeals to the word "standardized" mean that they would enjoy the attentions of standards committees. > ... >There is no other possibility, unless you wish to depend upon the >strength of a cipher which explicitly HAS *no* known or guaranteed >strength. Not having strength is not a trivial detail, this is the >essence of the reason for using a cipher. Before complaining of my monomanical tirades, you ought to notice a few of your own ...yes, you and others have pointed out with endless boring repetitions, the truth of the premise of that paragraph, that we have no guarantees, measurements, or even definitions of the true, theoretical strength of any practical cipher. However, as others have tirelessly responded, your claim that automated switching among lots of ciphers is the only alternative to a falling sky does not follow from that premise. >The ability to change ciphers offers each of us the power to choose >what cipher we want to use. This means no government organization is >edicting our use, or forcing it through market pressure. We get to >choose what to use, and what not to use, and to change our minds on a >daily basis. That is not a trivial advantage. Yes, it's good to be able to change ciphers. That does not imply anything one way or another about computers negotiating ciphers in real time. >>Other good (i.e. bad) examples of the inevitable perils of negotiating >>besides modems and PPP include TCP and HTTP. Most don't know about >>about MSS/PMTU or window size problems, but most people have seen >>"broken" web pages that don't work on some versons of some browsers. > >Gosh, I think we'll just have to have a complete specification. The equivalent failure mode of negotiated ciphers for a broken web page would be picking ROT26 as the cipher right after ROT13. Or one of the SSL security bugs. The world is full of self-described architects, designers, and inventors. Most are frauds who invent only self-delusions, hot air, snake oil, and promises to finally build a perptual motion machine that will work this time, (and help patent attourneys make the payments on their Mercedes.) The real architects, designers, and inventors not only desgin and invent, but also build real implementations that are useful in real life. So when will we see the implementation of negotiated/varying ciphers that you are building? Vernon Schryver vjs@rhyolite.com
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Sun, 24 Oct 1999 08:53:09 GMT From: ritter@io.com (Terry Ritter) Message-ID: <3812c8b2.9444970@news.io.com> References: <7uu5ft$f7v$1@calcite.rhyolite.com> Newsgroups: sci.crypt Lines: 398 On 23 Oct 1999 23:29:33 -0600, in <7uu5ft$f7v$1@calcite.rhyolite.com>, in sci.crypt vjs@calcite.rhyolite.com (Vernon Schryver) wrote: >In article <3812005b.8360995@news.io.com>, Terry Ritter <ritter@io.com> wrote: > >> ... >>>How can you point to modems as a good example of the wonders of negotiating >>>protocols? I think the politics and sausage warning applies. >> >>I think the real world applies: We have such modems. We use them. >>They work. End of story. > >That might be the end of a fairy tale or a nightmare, but I >thought you were talking about engineering. > >Modems do not work all of the time. A cipher negotiating protocol that >failed as often as modems fail today in real life would not be something >I'd want to trust my phone bill to, not to mention something that matters. Cipher negotiation is not in itself cryptographic. It can and should occur under the current cipher(s) and should be a straightforward selection. This negotiation occurs is not in the part of the chain which is affected by noise, line levels, or other dynamic qualities. Cipher negotiation is not the same situation as modem negotiation. Since modem negotiation is in fact used in practice to make dynamic connection-by-connection negotiated decisions, it shows that this is in fact practical in deployed systems. >> ... >>I doubt I implied that modem negotiation is "clean." But it *is* >>"background," and it *is* negotiation (both sides participate in the >>final result), and it *is* "real world" -- it generally works in >>practice. > >The "it generally works in practice" can be said about PPP, only more so. >And again, who wants a cipher negotiating protocol that "generally >works in practice"? PPP is not cipher negotiation. >Only salescritters or people with no technical knowledge can claim that >either PPP or modems are examples that could cause a working engineer to >be enthusaistic about negotiating ciphers. Sane, technically inclined >people who look at modems, PPP, or any other "standardized", dynamic >negotiating network protocol must be very skeptical of the idea. Just what is it that you don't get about requesting a cipher, then receiving an answer, yes, no, or a suggested alternative, all of which occurs in the error-corrected data? It is fine to be wairy of new ideas, but this seems somewhat OTT. >>Cipher negotiation can be far cleaner -- provided a single selection >>mechanism is standardized. If not, then we may see the same sort of >>ad hoc stuff we saw with modems. > >But "ad hoc" modem negotiation was your counter to the 10+ years of >public experience with offically standardized, carefully architected, >designed and tested PPP. The whole basis for cipher selection is very clean. >As for "can be cleaner...", those words echo what was said about >standardizing the negotiations between wide area routers in the leased-line >IETF WG that was merged with the SLIP-replacment WG in about 1987 to form >what is now the PPP working group. I think users are better served by >the result (PPP) than by the old proprietary protocols, but no one can >call PPP clean--at least no one honest and with a clue. > >Maybe Communism will work the next time it's tried too. >But my money is on standards committees behaving like committees. And just what standards committee would that be, exactly? >> ... >>I would say, "let's not do it like PPP." > >Exactly how would you do that? The problems with PPP negotiating are not >any single technical issue, but the inevitable morass that comes with >complicated network stuff in the best possible circumstances. Negotiating a cipher can be and should be distinct from using any particular cipher. This is not a complicated network stuff, but a simple selection protocol quite comparable to what two people would do if they were discussing which cipher to use on the phone. >>>I don't understand the "background" bit about cipher negotiating, since >>>for all of modems, PPP, and ciphers, until the parties agree, the main >>>event cannot work, and that's not exactly "background" >> >>Indeed, you do not understand the term "background," presumably >>because you have not done your homework. I suggest actually reading >>messages before disparaging their ideas. You might also look into my >>recent article in IEEE Computer: >> >> http://www.io.com/~ritter/ARTS/R8INTW1.PDF >> >>or the previous discussion, which I have archived on my pages: >> >> http://www.io.com/~ritter/NEWS4/LIMCRYPT.HTM >> >>Here, "background" approximately means "not apparent to the user." >>That is just what modem negotiation is about, although we may hear >>modems, and need not hear or see cipher negotiation. >> >>To start any conversation in cipher, it is currently necessary to >>acquire common keys. Everyone understands this. So everyone should >>be well prepared to understand that we can *also* acquire a cipher >>name, or even a cipher itself, in the same way, through the same >>channel. This is not a big conceptual leap. >> >>Once we have a conversation in cipher, we can assign part of it to a >>"control channel," where negotiation takes place (generally, although >>not necessarily) hidden from the user. That would be "background" >>cipher negotiation. >> >>Because the need is to change ciphers frequently, the desired >>negotiation process is not one-time at the start, but rather, a >>frequent or continuous process in different messages or sessions. > >Before repeating your old line yet again, you should do your own homework, >which is to actually investigate at least one real, deployed network >protocol that does the negotiating of the sort that you say is so easy. >And by "investigate," I don't mean merely read some user documentation or >repeat your dreams of how things would turn out if only people would listen >to you. I have presented the example that modems do in fact in practice negotiate their state, today, in mass fielded systems. I am sorry if you have trouble with your modems, but I have used modems from home since the early 80's, we typically still do use modems from home several times a day, and considering that they are working on lines designed for voice and not data, they generally work well, and in fact much better than they used to. >As for your "background" stuff--take your own advice and read what you >are responding to before pontificating about homework. No matter on what >"ground" the cipher negotiating is done, once the sender decides to switch >to another cipher, data must soon stop flowing until the new cipher has >been negotiated. Clearly, that is the wrong way to do it. The right way to do it is to come to a decision, and only then change the cipher. Until a decision is made, the data continue to flow under the old cipher. >You can call the cipher negotiating "background" if you >want, but when the user-data stops flowing the notion is ... strained. >When one party decides a new cipher is required, you must fairly soon >either use a new cipher or stop moving data. Otherwise think what a bad >guy could do. OK, what could a bad guy do? The conversation is under cipher, the negotiation is under cipher, and if the cipher takes several exchanges to change, then it does. If there is no alternative cipher, there can be no agreement, and so no change. If one party insists that a change occur, and no change is possible, then, obviously, communication stops. What is hard about this? >>>...well, not exactly >>>for PPP, which, for example has the CCP (comopression) which is supposed to >>>be negotiated in parallel with the main NCP's, which can start sending >>>data before CCP converges. That is what the PPP implementations I've >>>worked on do, but plenty of others don't. Again, theory vs. practice. >> >>I am a working engineer. >> >>Theory vs. practice. > >Shouldn't a working engineer know about the common, existing, widely >*practiced* examples of the thing he is proposing? SSL is a closer example >than modems or PPP. (I picked PPP because I know more about PPP than >SSL.) Do you care to say something about SSL that will convince people >that negotiating ciphers is a great idea? No, I only wish to say that cipher negotiation is realistic and possible in real systems; it can hardly be opposed out of hand as "impossible" technology. Changing ciphers is a great idea if we want to complicate any attack which requires the accumulation of ciphertext from a particular cipher. If, as we expect, opponents cannot distinguish the ciphers from their ciphertexts, they simply do not have the basis for most types of described attacks. I would call this a worthwhile motive for the modest additional complexity required to automatically switch ciphers. That is not the only motive, however. Another good motive is to make the secure communications path resilient against the known failure of our favorite ciphers. Only if the systems can automatically move to new ciphers can we hope to avoid massive disruption from the failure of something which cannot be guaranteed in an engineering sense. >> ... >>Well, since you are a "real designer," I'll just let you wander on in >>your monomanical tirade, while I suggest that we *not* do things like >>PPP. > >The biggest trouble with PPP is that it is a standardized network thing. >Network things that are standards are always at least 95% politics, by >which I mean everything that comes with design by committee and approval >by standards committees. Negotiating ciphers such as you have proposed >would necessarily be network things. Your repeated appeals to the word >"standardized" mean that they would enjoy the attentions of standards >committees. In my experience, many "standardized" technologies in fact start out as ad-hoc standards, and it is this genesis and the desire to stay with the mistakes of the past which -- as much as anything -- mark the problem. The virtually universal practice in both hardware and software is to hack out a solution and ship it, with minimal thought given to consequences. But "thought" is just what is going on here. Only if we get a reasonable concensus about *what* need be done will it *then* make sense to try to standardize *how* that will be done. >> ... >>There is no other possibility, unless you wish to depend upon the >>strength of a cipher which explicitly HAS *no* known or guaranteed >>strength. Not having strength is not a trivial detail, this is the >>essence of the reason for using a cipher. > >Before complaining of my monomanical tirades, you ought to notice a few >of your own ...yes, you and others have pointed out with endless boring >repetitions, the truth of the premise of that paragraph, that we have no >guarantees, measurements, or even definitions of the true, theoretical >strength of any practical cipher. However, as others have tirelessly >responded, your claim that automated switching among lots of ciphers is >the only alternative to a falling sky does not follow from that premise. I doubt that I have ever said any such thing. I do not say that switching among ciphers is the only possible solution. I have many times asked for alternative contributions to solving the fundamental problem. But since I have been arguing this for some years now, I don't expect that many degrees of freedom remain to be investigated. The security advantages which accrue from "automated switching" among locally-approved ciphers are many and broad. I think it is sufficient to notice that ciphers do not enjoy the same sort of performance specification that we normally expect from communications system components. If a hardware fails, or cannot keep up, or does not follow a spec'd protocol, we know that something is wrong; we can fix it or replace it. Similarly the software. But even if we find out that our cipher has failed, we cannot bitch, because a cipher carries no performance guarantees with respect to security. In what other component in a communications system would we tolerate a complete lack of specification about the fundamental role of that component? Now, what does switching do for us? Mainly, it gives us the freedom to change a component which is not and can not be guaranteed. But it also complicates attacks by making it difficult or impossible to distinguish the ciphertext from a particular cipher so it can be used to generate a particular attack. >>The ability to change ciphers offers each of us the power to choose >>what cipher we want to use. This means no government organization is >>edicting our use, or forcing it through market pressure. We get to >>choose what to use, and what not to use, and to change our minds on a >>daily basis. That is not a trivial advantage. > >Yes, it's good to be able to change ciphers. That does not imply anything >one way or another about computers negotiating ciphers in real time. First of all, I think your use "real time" is confusing. When we talk about "real time operating systems" we mean systems which have defined worst-case performance characteristics. But I see no need for any such limitation on negotiation. Certainly cipher negotiation would "real time" in the sense that negotiation information would flow during message time, but *not* in the sense that it had to be accomplished before the next message could occur. And any system which will benefit non-computer types must operate virtually on its own, with minimal setup and maintenance. In particular, it must be easy to stop using a particular cipher. If cipher changing is not the normal mode of operation, that is quite unlikely to work smoothly when needed. >>>Other good (i.e. bad) examples of the inevitable perils of negotiating >>>besides modems and PPP include TCP and HTTP. Most don't know about >>>about MSS/PMTU or window size problems, but most people have seen >>>"broken" web pages that don't work on some versons of some browsers. >> >>Gosh, I think we'll just have to have a complete specification. > >The equivalent failure mode of negotiated ciphers for a broken web page >would be picking ROT26 as the cipher right after ROT13. Or one of >the SSL security bugs. No, that would *not* be a failure of negotiation: That would be a problem with the content of the cipher selection set, and that content is a human decision. If humans want to allow the use of both ROT13 and ROT26, the system might well choose ROT13 and ROT26. But I thought we were talking about serious ciphers here, and the only counterpart to ROT26 in a serious cipher is the ability to use a buggy implementation. We don't normally depend upon *perfect* software, because we cannot assure any such thing. Consequently, some implementations -- even of the best ciphers -- *will* have bugs. Having frequent cipher changes at least takes us out of a buggy implementation into some other implementation fairly quickly. >The world is full of self-described architects, designers, and inventors. >Most are frauds who invent only self-delusions, hot air, snake oil, and >promises to finally build a perptual motion machine that will work this >time, (and help patent attourneys make the payments on their Mercedes.) Well, the world is *also* full of people who hack something together and then call themselves architects or designers; I like to think that there is something more involved. And while I can hardly speak for all those you have indicted here, I suppose we would all like to be more successful than we are. In cryptography, I have a well-documented 10-year history of publication in ink on paper, fundamental patents, and lately web page publications. You can read my papers on my pages. You can read how I describe my inventions, what they do, their reason for being, as well as the actual patents themselves if you are masochistic. You can read the detailed designs for my older cipher products. And, if you have the background, you can compare my work to the state of the art and come to your own conclusions. * Recently, I have been interested in the technical analysis of analog noise for cryptographic purposes, and I have about 20 pages of figures and graphs which build some interesting conclusions: http://www.io.com/~ritter/NOISE/NOISCHAR.HTM * Before that, I was interested in the construction of keyed orthogonal Latin squares of large order, and you can read about that too: http://www.io.com/~ritter/ARTS/NONLBBM.HTM * Before *that*, I was interested in the analysis of S-boxes through the measure of Boolean nonlinearity. Not only do I describe the measure, I include actual working code to do it: http://www.io.com/~ritter/JAVASCRP/NONLMEAS.HTM * All this is, of course, in addition to a crypto glossary of almost 400K, and my introduction to cryptography: http://www.io.com/~ritter/LEARNING.HTM As archived on my pages, I have carried many arguments onto sci.crypt, and I normally present not only my views, but also the opposing views and allow the readers to come to their own conclusions. While I am quite sure that others have been more productive or more effective or more . . . appropriate during this period, I have done what I have done. Perhaps you need to compare my work to the similar goods from those you described before you see the difference. But I'm not quite sure what all this has to do with the current conversation. >The real architects, designers, and inventors not only desgin and invent, >but also build real implementations that are useful in real life. Since when did *you* get to decide what makes a "real" designer or inventor? I would say that, with respect to true scientific innovation, it is the argument that matters, and *only* the argument. >So when >will we see the implementation of negotiated/varying ciphers that you are >building? I have some rather complete designs. But as I see it, there is little point in attempting to field such a product in an environment where "real" designers still think that cryptanalysis tells us that a standardized cipher must be strong, so we don't really need all this fancy cipher-change stuff. Perhaps things will change in a year or two. --- Terry Ritter ritter@io.com http://www.io.com/~ritter/ Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: 24 Oct 1999 09:52:33 -0600 From: vjs@calcite.rhyolite.com (Vernon Schryver) Message-ID: <7uva01$pm3$1@calcite.rhyolite.com> References: <3812c8b2.9444970@news.io.com> Newsgroups: sci.crypt Lines: 421 In article <3812c8b2.9444970@news.io.com>, Terry Ritter <ritter@io.com> wrote: > ... >>Modems do not work all of the time. A cipher negotiating protocol that >>failed as often as modems fail today in real life would not be something >>I'd want to trust my phone bill to, not to mention something that matters. > >Cipher negotiation is not in itself cryptographic. If cipher negotiation is not critical to keeping secrets, then there is no reason to do it. The 1st Amendment lets anyone claim that a failure in cipher negotiating could not possibly compromise security, but no one who has dealt with real life security protocols will believe it. It is an egregious offense against the dictum that theory and practice are not the same to imply that cipher negotiating would never open any security holes. > It can and should >occur under the current cipher(s) and should be a straightforward >selection. ... That's what they all said about PPP selecting MTU's, IP addreses, and authentication schemes, TCP doing PMTU discovery, and SSL. >Cipher negotiation is not the same situation as modem negotiation. >Since modem negotiation is in fact used in practice to make dynamic >connection-by-connection negotiated decisions, it shows that this is >in fact practical in deployed systems. I have never said or even implied that cipher negotiating is impossible. My original example, PPP, shows that negotiating things is possible. The issue is whether in practice you can design and deploy a cipher negotiating system that would not make people run away screaming. Haven't you noticed the signature "SSL isn't" of one author here? How will your cipher negotiating protocol be certain to not only avoid all of SSL's problems, but also all possible new problems? > ... >>>I doubt I implied that modem negotiation is "clean." But it *is* >>>"background," and it *is* negotiation (both sides participate in the >>>final result), and it *is* "real world" -- it generally works in >>>practice. >> >>The "it generally works in practice" can be said about PPP, only more so. >>And again, who wants a cipher negotiating protocol that "generally >>works in practice"? > >PPP is not cipher negotiation. It is at best intellectually dishonest to say that PPP is so different from cipher negotiating that the PPP experience is irrelevant. In both PPP and cipher negotiating, all that the computers do is agree on some parameters. Moreover, as I've mentioned, one of the biggest real life negotiating problem areas in PPP has been the negotiation of authentication protocol, picking among PAP, MD5 CHAP, MS-CHAP (which involves MD4 and DES), and MS-CHAPv2 (ditto, except I think they use MD5 also or instead). "MD4", "MD5", and "DES" refer to the familiar hash and encryption functions. One PPP peer says "let's try X", for X=its preferred authentication algorithm. The other peer says either "ok" or "no, instead let's use Y." The first says either "ok, let's use Y", or shuts down or restricts the link to traffic not needing authentication. Isn't that exactly what you envision for cipher negotiating? Read the forthcoming edition of James Carlson's PPP book in which he describes some of the many ways the PPP authentication negotiation fails in real life. In theory and in the RFC's, of course, it's perfect. > ... >Just what is it that you don't get about requesting a cipher, then >receiving an answer, yes, no, or a suggested alternative, all of which >occurs in the error-corrected data? It is fine to be wairy of new >ideas, but this seems somewhat OTT. My point is that "requesting an X, then receiving an answer, yes, no or suggested alternative" - is an idea is anything but new or untried. - is exactly PPP Configure-Requests, Configure-Naks, and Configure-Acks. - it is nothing like what occurs in "error-corrected data", except as I might explain things to someone with no idea of or interest in negotiating things or CRC's, forward error codes, and ARQ. > ... >The whole basis for cipher selection is very clean. That is statement, like others of yours in support of cipher negotiating, is like what the fellow who advocates extremely long keys says about his code and ciphers. It is at best an expression of a hope. > ... >And just what standards committee would that be, exactly? If you negotiate your ciphers for the purpose of protecting IP (including IPv6) data, the IETF would ensure it is involved eventually. If you move down a layer, you would get the ITU or an ad hoc committee like the ATM Forum or an official committee such as IEEE 802.3 or ANSI x.3. If you go up, say to protect HTTP, you'll be involved with the W3C or the IETF. In real life, whether you or I like it or not (I don't), if you are talking about a multi-vendor protocol, you will have standards committees involved. Have you not noticed where the next version of SSL is being done? If you use cipher negotiating to protect voice data, you'll find the CLEA forcing equipment vendors to get your protocol sanctioned by a standards committee to avoid fines for failing to include enough wire tapping. (See the recent big noises in the "raven" mailinglist of the IETF in which the IETF is trying to avoid getting involved in putting more tapping facilities into IP. The on-line press has been filled with reports of that circus.) >>> ... >>>I would say, "let's not do it like PPP." >> >>Exactly how would you do that? The problems with PPP negotiating are not >>any single technical issue, but the inevitable morass that comes with >>complicated network stuff in the best possible circumstances. > >Negotiating a cipher can be and should be distinct from using any >particular cipher. This is not a complicated network stuff, but a >simple selection protocol quite comparable to what two people would do >if they were discussing which cipher to use on the phone. Exactly the same theory is said still about all of PPP. Only salescritters and the clue challenged believe it. Much of PPP negotiating is for small numbers, with one peer proposing a value, and the other saying either "ok" or "let's do X instead." Almost all of the rest of PPP negotiating consists of one peer saying "let's do Z" and the peer saying either "yes" or "no". That's simpler than your cipher negotiating, but it also has lots of real life problems. > ... >I have presented the example that modems do in fact in practice >negotiate their state, today, in mass fielded systems. I am sorry if >you have trouble with your modems, but I have used modems from home >since the early 80's, we typically still do use modems from home >several times a day, and considering that they are working on lines >designed for voice and not data, they generally work well, and in fact >much better than they used to. And I have mentioned that I have been dealing with modems since the 1960's. that modem negotiating is at best ugly under the covers (as you agreed), that modems still sometimes fail to negotiate (as you agreed), and that the modem protocol war continues as demonstrated by the still unwinding v.90 battle. Who is going to be using your cipher negotiating protocol before it matures like modem protocols, before it works "much getter than [it] used to." Personally, I'll be keeping data I care about under other schemes a while longer than that. As evidence that cipher negotiating could not escape standards committees, note that major modem protocols for the last 10 years have involved the worst of standards committees, the ITU. > ... >>When one party decides a new cipher is required, you must fairly soon >>either use a new cipher or stop moving data. Otherwise think what a bad >>guy could do. > >OK, what could a bad guy do? The conversation is under cipher, the >negotiation is under cipher, and if the cipher takes several exchanges >to change, then it does. If there is no alternative cipher, there can >be no agreement, and so no change. If one party insists that a change >occur, and no change is possible, then, obviously, communication >stops. What is hard about this? If the initial cipher is absolutely secure, then there is no reason to ever change it or negotiate anything. You necessarily assume that the bad guys can break some ciphers. If the bad guy has a real-time break of a cipher you happen to use for a while, he can keep you from switching. For a real life example of the problems of negotiating ciphers, "what is hard about" SSL? > ... >No, I only wish to say that cipher negotiation is realistic and >possible in real systems; it can hardly be opposed out of hand as >"impossible" technology. I've not seen anyone claim negotiating ciphers is "impossible." Nothing I have said could be honestly interpreted as claiming impossibility. After all, I've been talking about real life protocols that mostly work. What I have been saying is that the inevitiable complications of cipher negotiating are inevitably both large and problematic. Worse, those inevitiable problems will include breaks in security. >Changing ciphers is a great idea if we want to complicate any attack >which requires the accumulation of ciphertext from a particular >cipher. If, as we expect, opponents cannot distinguish the ciphers >from their ciphertexts, they simply do not have the basis for most >types of described attacks. I would call this a worthwhile motive for >the modest additional complexity required to automatically switch >ciphers. I agree changing ciphers is an interesting idea. However, at best you demonstrate traits unbecoming a "practicing engineer" when you describe negotiating ciphers as "modest additional complexity." Good engineers don't pronounce on things they know nothing about, and they don't lie about things they do know about. >That is not the only motive, however. Another good motive is to make >the secure communications path resilient against the known failure of >our favorite ciphers. Only if the systems can automatically move to >new ciphers can we hope to avoid massive disruption from the failure >of something which cannot be guaranteed in an engineering sense. That conclusion is your thesis. You have not proven it. > ... >In my experience, many "standardized" technologies in fact start out >as ad-hoc standards, and it is this genesis and the desire to stay >with the mistakes of the past which -- as much as anything -- mark the >problem. In my experience, which has brushed against language as well as network standards and committees, the predecessor to the standards committee product is invariably smaller, cleaner, and more robust. What standards committees do is no more or less "ad hoc" than what any other committee, group, or individual does. There are no formulas for producing protocols. They are all "ad hoc," but some are more informed by past experience. >The virtually universal practice in both hardware and software is to >hack out a solution and ship it, with minimal thought given to >consequences. Maybe where you do your engineering, but not where I've been doing mine for the last 30+ years. > But "thought" is just what is going on here. No, what is going on here is standard netnews, talk with very little throught, and no significance. Name a single protocol that has ever been designed in a netnews group. Not even NNTP managed that trick. > Only if >we get a reasonable concensus about *what* need be done will it *then* >make sense to try to standardize *how* that will be done. I insist on considering at least sketches of "how" simultaneously with "what." The worst protocol standards (e.g. the ISO OSI suite or MAP and TOP) are created by committees deciding "what" before and independent of "how." Regardless, the only concensus that matters in the real world is among what I think of as "practicing engineers" (people who actually build things) and their customers. There is not a quorum of either for considering negotiating ciphers. > ... >>>There is no other possibility, unless you wish to depend upon the >>>strength of a cipher which explicitly HAS *no* known or guaranteed >>>strength. Not having strength is not a trivial detail, this is the >>>essence of the reason for using a cipher. >> >>Before complaining of my monomanical tirades, you ought to notice a few >>of your own ...yes, you and others have pointed out with endless boring >>repetitions, the truth of the premise of that paragraph, that we have no >>guarantees, measurements, or even definitions of the true, theoretical >>strength of any practical cipher. However, as others have tirelessly >>responded, your claim that automated switching among lots of ciphers is >>the only alternative to a falling sky does not follow from that premise. > >I doubt that I have ever said any such thing. I do not say that >switching among ciphers is the only possible solution. You said "There is no other possibility" in the words quoted above your claim that you did not say that. > ... >The security advantages which accrue from "automated switching" among >locally-approved ciphers are many and broad. ... No one disagrees with that. The trouble is that you go from that true statement to claims that negotiating ciphers is easy, safe, and non-fattening. I think it is none of those. I've designed and implemented more than 1 or 2 protocols since my first simplistic hack that made two computers talk to each other over phone lines in the 1960's, and merely implemented a lot more. > ... >>Yes, it's good to be able to change ciphers. That does not imply anything >>one way or another about computers negotiating ciphers in real time. > >First of all, I think your use "real time" is confusing. When we talk >about "real time operating systems" we mean systems which have defined >worst-case performance characteristics. I wish "real time operating systems" had something to do with "defined worst-case performance characteristics," but by 10 or 15 years ago, "defined" had been replaced by "rarely violated, we think." Now you must demand "hard realtime" to get more than a prayer and a salescritter promise. > But I see no need for any >such limitation on negotiation. Certainly cipher negotiation would >"real time" in the sense that negotiation information would flow >during message time, but *not* in the sense that it had to be >accomplished before the next message could occur. I carefully did not say "before the next message could occur," but intentionally wrote "fairly soon." >And any system which will benefit non-computer types must operate >virtually on its own, with minimal setup and maintenance. In >particular, it must be easy to stop using a particular cipher. If >cipher changing is not the normal mode of operation, that is quite >unlikely to work smoothly when needed. Replace "cipher" with any of the parameters negotiated with PPP or SSL, and I've heard those words many times. I'm not saying they are wrong, but that in practice they do not imply what you wish they did, that negotiating will work smoothly merely because it is central, and as proof, I've pointed to many real life examples. > ... >We don't normally depend upon *perfect* software, because we cannot >assure any such thing. Consequently, some implementations -- even of >the best ciphers -- *will* have bugs. Having frequent cipher changes >at least takes us out of a buggy implementation into some other >implementation fairly quickly. You could make money as a stand-up comedian for the IETF PPP Working Group with lines like that. I'm serious; you would get big laughs from people who have designed and built negotiating computer protocols by saying that negoiating necessarily gets you out of anything quickly. >>The world is full of self-described architects, designers, and inventors. >>Most are frauds who invent only self-delusions, hot air, snake oil, and >>promises to finally build a perptual motion machine that will work this >>time, (and help patent attourneys make the payments on their Mercedes.) > >Well, the world is *also* full of people who hack something together >and then call themselves architects or designers; I like to think that >there is something more involved. And while I can hardly speak for >all those you have indicted here, I suppose we would all like to be >more successful than we are. > >In cryptography, I have a well-documented 10-year history of >publication in ink on paper, fundamental patents, and lately web page >publications. You can read my papers on my pages. You can read how I > ... Have you implemented any of your ideas in commercial products? >>The real architects, designers, and inventors not only desgin and invent, >>but also build real implementations that are useful in real life. > >Since when did *you* get to decide what makes a "real" designer or >inventor? I would say that, with respect to true scientific >innovation, it is the argument that matters, and *only* the argument. Nonsense! Outside of math, arguments are mere hot air. Even the purest of theoreticians depend on experimentalists for validation. Besides sci.cript is about enginnering instead of science or math, despite the netnews hierarchy, and as you and others have implicitly been saying for months in rants about the lack of theory of cipher strength. No, don't bother pointing at the occassional elementary number theory or complexity notion. I spent too many years in math graduate school to be overawed by such things, especially when so many authors here get them wrong. >>So when >>will we see the implementation of negotiated/varying ciphers that you are >>building? > >I have some rather complete designs. But as I see it, there is little >point in attempting to field such a product in an environment where >"real" designers still think that cryptanalysis tells us that a >standardized cipher must be strong, so we don't really need all this >fancy cipher-change stuff. Perhaps things will change in a year or >two. To distinguish oneself from legions of cranks, all of whom have "rather complete designs" for antigravity machines, FTL drives, perpetual motion machines, and many other wonderful things, one must produce working implementations that other people can test drive. Vernon Schryver vjs@rhyolite.com
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: 25 Oct 1999 20:12:54 -0600 From: vjs@calcite.rhyolite.com (Vernon Schryver) Message-ID: <7v32n6$k72$1@calcite.rhyolite.com> References: <38147B53.4B9EDA7B@aspi.net> <7uva01$pm3$1@calcite.rhyolite.com> Newsgroups: sci.crypt Lines: 132 In article <38147B53.4B9EDA7B@aspi.net>, Trevor Jackson, III <fullmoon@aspi.net> wrote: > ... >> Haven't you noticed the signature "SSL isn't" of one author here? >> How will your cipher negotiating protocol be certain to not only >> avoid all of SSL's problems, but also all possible new problems? > >There is a fundamental difference between establishing a connection, a la PPP or >SSL, and altering the operation of an existing connection. The latter is simpler >in many ways, not the least of which is that fallback/revert is always possible As far as I understand it, that statement has no relation to that I understand to be PPP. > ... >> It is at best intellectually dishonest to say that PPP is so different >> from cipher negotiating that the PPP experience is irrelevant. In both >> PPP and cipher negotiating, all that the computers do is agree on some >> parameters. > >No. > >PPP has to build a connection where none exists. This eliminates the standard >communication primitives and requires a step-wise negotiation of the protocol in >order to build up support the standard communication primitives. That is completely wrong. All of PPP is built on "standard communications primitives," namely a pair of full-duplex streams of packets without errors but possibly with packet losses, and that preserve packet order. PPP requires the existence of "standard communications primitives" that are more restricted and powerful than those provided by UDP/IP. (UDP delivers packets potentially out of order). >In dynamic cipher negotiation (DCN for want of a better abbreviation) a viable >connection already exists. Like the usual, ordered, error-detected connection underneath all of PPP? Or does it require the reliable stream (i.e. not only no bad packets, but no packets lost) that can be negotiated with PPP, and that is required by some forms of PPP compression, including some that have the negotiation problems I've referred to? That's the flavor of PPP favored by Gandalf that is a form of x.25. Do seriously mean to claim that x.25 does not offer "standard communications primitives"? > It can be used to verify the correct interoperation of >the target cipher prior to committment. The trouble with negotiating protocols or ciphers is in picking a "target," or the equivalent of agreeing on the merchandise and the price. By the time you have a "target cipher" whose "correct interoperation" you can verify, you've already the problems in negotiating, just as by the time you carry home your melons from the market, the negotiating problems are long past. Well, some of the major PPP problems involve the equivalent of you deciding after you get home that you made a bad deal, and going back to the market to try to find and haggle with the vendor. If you say that the equivalent problems won't happen with negotiating ciphers, I'll not believe you. Note that some of the other major PPP problems are due to the sloppiness of a bunch of vendors who ignore the clear requirements in the main PPP RFC's concerning renegotiating parameters. Those errors have caused significant security problems. (I'm talking of the common junk that gives up upon receiving an LCP Configure-Request after reaching OPENED) > And since fallback/revert is always >available the complexity of error/dispute handling is dramatically reduced. That's another wonderfully funny statement. Those who have actually implemented protocols with "fallback/revert" know that such features are extremely fertile sources of major problems in the real world. We also know that the salescritters sell such features to unsuspecting users and system administrators as the opposite of what they usually are, sources of bugs and major sources of complexity. > ... >> Much of PPP negotiating is for small numbers, with one peer proposing a >> value, and the other saying either "ok" or "let's do X instead." Almost >> all of the rest of PPP negotiating consists of one peer saying "let's do >> Z" and the peer saying either "yes" or "no". That's simpler than >> your cipher negotiating, but it also has lots of real life problems. > >In what sense is is similar? We want one small number, the ID of the cipher. >What additional complexity do you see associated with cipher selection other than >cipher selection? (Yes that phrasing is purposefully chosen). Carefully phrased or not, I do not understand any technical content in that question. For an example that might answer the question, the job of the CCP (PPP compression control protocol) is to get the PPP peers to agree on a 16-bit ID for a compression algorithm. The point of the LCP authentication Conf-Req/Rej/Nak packets is to pick a similar, small ID of an authentication protocol. How is that harder than picking the ID of a cipher? >> ... >Please point to an example where a higher level user of a channel is unable to >detect the phase transition. Both PPP and SSL fail this test as the presence of >absence of a channel counts as detectable. What do you mean by "phase transition" Or "absence of a channel"? Do you seriously mean to claim or imply that PPP ever exists, works, or starts to work or something similar when there is no "channel" between the peers? I think SSL assumes that it has TCP/IP underneath, which is less than what any cipher negotiating protoocol will assume for transport. What do you think? No, please do not bother responding. Vernon Schryver vjs@rhyolite.com
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: 24 Oct 1999 10:13:34 -0600 From: vjs@calcite.rhyolite.com (Vernon Schryver) Message-ID: <7uvb7e$q7s$1@calcite.rhyolite.com> References: <38131CDC.40A35B01@aspi.net> <7uu5ft$f7v$1@calcite.rhyolite.com> Newsgroups: sci.crypt Lines: 91 In article <38131CDC.40A35B01@aspi.net>, Trevor Jackson, III <fullmoon@aspi.net> wrote: > ... >> Only salescritters or people with no technical knowledge can claim that >> either PPP or modems are examples that could cause a working engineer to >> be enthusaistic about negotiating ciphers. Sane, technically inclined >> people who look at modems, PPP, or any other "standardized", dynamic >> negotiating network protocol must be very skeptical of the idea. > >Any other? I think not. > >You can pick on negotiation failures typically those that evolved over time, which >usually means layers of kludge upon kludge, sometimes driven by commercial issues >(PPP), Base on that statement, you have no idea of the history or even nature of PPP. PPP in general and PPP negotiating in particular are as much as was possible the exact opposite of something "that evolved over time." (Before you argue with me about the history of PPP, please tell me under what name I can find your words in the IETF PPP WG archives.) > and sometimes driven by technological advances (modems). That notion of the history of modems is also as wrong, based on what I've observed since before dial-up 1200 bit/sec modems were available (1,200 bit/sec, not 12,000 bps). >OTOH, you have failed to note the cases in which negotiation is so successful that >it is almost invisible. Consider DECnet. Once a machine is configured there is >little chance of failure. You hook up the wires and the machine figures out wht >topology necessary to communicate with other machines. This is a negotiation >protocol that works. Have you ever worked inside a DECnet implementation? I have been paid to port and hack code that implemented Phase IV, and then to deal with problem reports from customers that the technical support people could not answer. To say the least, I do not agree with your claim that DECnet "is a negotation protocol that [always] works." Even the claim that DECnet was a "negotation protcol" is not quite true in my view. >Note that this class of error, noticing only the problems, is a basic wheel >approach which causes sampling error. >There is no alue to this sort of anecdotal horror story. If you want to address >the topic of negotiating protocols, please produce an issue that you believe will >be difficult to solve and lead to negotiation failures. You're evidently as much of a "practicing engineer" as Terry Ritter. My point is that in theory, there are no non-trivial problems that would need attention, but in practice there always are. In theory, there are no anecdotes that do not conform to theory. Practice consists of anecdotes. > ... >Not relevant. We aren't faced with "complicated network stuff" or anything >similar. Anyone adding one or more AES ciphers to an existing multi-cipher >product already the the problem and a solution. Adding several AES ciphers to an >existing single-cipher product is no harder than adding a single ("the") AES >cipher; negotitaion is required. That is wrong. Negotiation is not necessarily required, although the receiver does need to figure out or know by prior configuration which cipher is in use. "Negotiation" involves proposing, rejecting, counter-proposing, and accepting. "Negotiation" is not inolved in asking the wire for a network address and accepting whatever you get. It is also not merely looking at a header to identify a packet format or cipher. Asking for a DHCP or BOOTP address or picking a decryption scheme and key based on a packet header has as much to do with "negotiating" as buying groceries in a typical American supermarket, nothing whatsoever. > creating a new product is the only case in which >the requirement to negotiate cipher selection is an issue. Note that this is >going to be common for reasona of backward compatibility during the >changeover/upgrade period. Nonsense. Upward compatiblity does *not* need negotiating, but merely recognizing the old form. Negotiating is required if you want to have the sender and receiver have potentically non-overlapping sets of ciphers and to discover and agree on the best common cipher. It is also required by Terry Ritters proposals. Moreover, the "changeover/upgrade period" for protocols invariably lasts a very long time. A case study of how long that can be is in the endurance of DECnet Phase IV which has been officially obsolete and deprecated for more than 10 years, but which is still a common form of DECnet (where DECnet still exists). Because of embedded systems, changes in cipher protocols take even longer. > ... >You cannot just wish this requirement away. Nor can you ignore the ubiquity of >the issue and claim that multiple AES selections creates an abnormal condition. >As discussed above it is probably normal to have multiple ciphers. > ... And you cannot just wish requirements into existence. AES is not the first new cipher in history. Ciphers have been coming and going for decades. Still, negotiating ciphers is not universal, and where it is done, not without significant security problems in practice but not theory (e.g. SSL). Vernon Schryver vjs@rhyolite.com
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Sun, 24 Oct 1999 18:13:34 +0200 From: vjs@calcite.rhyolite.com (vjs@calcite.rhyolite.com) Message-ID: <fc.3b9aca0002b8f3503b9aca008f91dec6.10ab9@peg.dyndns.org> References: <7uvb7e$q7s$1@calcite.rhyolite.com> Newsgroups: sci.crypt Lines: 129 In article <38131CDC.40A35B01@aspi.net>, Trevor Jackson, III <fullmoon@aspi.net> wrote: >> ... >>> Only salescritters or people with no technical knowledge can claim that >>> either PPP or modems are examples that could cause a working engineer >to >>> be enthusaistic about negotiating ciphers. Sane, technically inclined >>> people who look at modems, PPP, or any other "standardized", dynamic >>> negotiating network protocol must be very skeptical of the idea. >> >>Any other? I think not. >> >>You can pick on negotiation failures typically those that evolved over >time, which >>usually means layers of kludge upon kludge, sometimes driven by >commercial issues >>(PPP), Base on that statement, you have no idea of the history or even nature of PPP. PPP in general and PPP negotiating in particular are as much as was possible the exact opposite of something "that evolved over time." (Before you argue with me about the history of PPP, please tell me under what name I can find your words in the IETF PPP WG archives.) >> and sometimes driven by technological advances (modems). That notion of the history of modems is also as wrong, based on what I've observed since before dial-up 1200 bit/sec modems were available (1,200 bit/sec, not 12,000 bps). >>OTOH, you have failed to note the cases in which negotiation is so >successful that >>it is almost invisible. Consider DECnet. Once a machine is configured >there is >>little chance of failure. You hook up the wires and the machine figures >out wht >>topology necessary to communicate with other machines. This is a >negotiation >>protocol that works. Have you ever worked inside a DECnet implementation? I have been paid to port and hack code that implemented Phase IV, and then to deal with problem reports from customers that the technical support people could not answer. To say the least, I do not agree with your claim that DECnet "is a negotation protocol that [always] works." Even the claim that DECnet was a "negotation protcol" is not quite true in my view. >>Note that this class of error, noticing only the problems, is a basic >wheel >>approach which causes sampling error. >>There is no alue to this sort of anecdotal horror story. If you want to >address >>the topic of negotiating protocols, please produce an issue that you >believe will >>be difficult to solve and lead to negotiation failures. You're evidently as much of a "practicing engineer" as Terry Ritter. My point is that in theory, there are no non-trivial problems that would need attention, but in practice there always are. In theory, there are no anecdotes that do not conform to theory. Practice consists of anecdotes. >> ... >>Not relevant. We aren't faced with "complicated network stuff" or >anything >>similar. Anyone adding one or more AES ciphers to an existing >multi-cipher >>product already the the problem and a solution. Adding several AES >ciphers to an >>existing single-cipher product is no harder than adding a single ("the") >AES >>cipher; negotitaion is required. That is wrong. Negotiation is not necessarily required, although the receiver does need to figure out or know by prior configuration which cipher is in use. "Negotiation" involves proposing, rejecting, counter-proposing, and accepting. "Negotiation" is not inolved in asking the wire for a network address and accepting whatever you get. It is also not merely looking at a header to identify a packet format or cipher. Asking for a DHCP or BOOTP address or picking a decryption scheme and key based on a packet header has as much to do with "negotiating" as buying groceries in a typical American supermarket, nothing whatsoever. >> creating a new product is the only case in >which >>the requirement to negotiate cipher selection is an issue. Note that >this is >>going to be common for reasona of backward compatibility during the >>changeover/upgrade period. Nonsense. Upward compatiblity does *not* need negotiating, but merely recognizing the old form. Negotiating is required if you want to have the sender and receiver have potentically non-overlapping sets of ciphers and to discover and agree on the best common cipher. It is also required by Terry Ritters proposals. Moreover, the "changeover/upgrade period" for protocols invariably lasts a very long time. A case study of how long that can be is in the endurance of DECnet Phase IV which has been officially obsolete and deprecated for more than 10 years, but which is still a common form of DECnet (where DECnet still exists). Because of embedded systems, changes in cipher protocols take even longer. >> ... >>You cannot just wish this requirement away. Nor can you ignore the >ubiquity of >>the issue and claim that multiple AES selections creates an abnormal >condition. >>As discussed above it is probably normal to have multiple ciphers. >> ... And you cannot just wish requirements into existence. AES is not the first new cipher in history. Ciphers have been coming and going for decades. Still, negotiating ciphers is not universal, and where it is done, not without significant security problems in practice but not theory (e.g. SSL). Vernon Schryver vjs@rhyolite.com {}{}{} Posted via Uncensored-News.Com, http://www.uncensored-news.com {}{}{} {}{}{}{} Only $8.95 A Month, - The Worlds Uncensored News Source {}{}{}{} {}{}{}{}{} Five News Servers with a BINARIES ONLY Server {}{}{}{}{}
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Mon, 25 Oct 1999 12:18:38 -0400 From: "Trevor Jackson, III" <fullmoon@aspi.net> Message-ID: <381482DE.B036BC49@aspi.net> References: <7uvb7e$q7s$1@calcite.rhyolite.com> Newsgroups: sci.crypt Lines: 174 Vernon Schryver wrote: > In article <38131CDC.40A35B01@aspi.net>, > Trevor Jackson, III <fullmoon@aspi.net> wrote: > > > ... > >> Only salescritters or people with no technical knowledge can claim that > >> either PPP or modems are examples that could cause a working engineer to > >> be enthusaistic about negotiating ciphers. Sane, technically inclined > >> people who look at modems, PPP, or any other "standardized", dynamic > >> negotiating network protocol must be very skeptical of the idea. > > > >Any other? I think not. > > > >You can pick on negotiation failures typically those that evolved over time, which > >usually means layers of kludge upon kludge, sometimes driven by commercial issues > >(PPP), > > Base on that statement, you have no idea of the history or even nature of > PPP. PPP in general and PPP negotiating in particular are as much as was > possible the exact opposite of something "that evolved over time." So. In a previous post you alluded to the fact that the first implementations weren't quite as functional or correct as later implementations. If this is not "evolution over time" what is the term you use for it? > (Before you argue with me about the history of PPP, please tell me under > what name I can find your words in the IETF PPP WG archives.) > > > and sometimes driven by technological advances (modems). > > That notion of the history of modems is also as wrong, based on what I've > observed since before dial-up 1200 bit/sec modems were available > (1,200 bit/sec, not 12,000 bps). Are we competing on ages or something? I've got half a dozen 300 baud modems floating around here someplace, and a couple of monster 1200 baud mini computer modems. I know what got us from there to here. It wasn't a trivial process. It was ugly then and is still ugly now. I do not belive this is an appropriate basis for comparison with dynamic cipher negotiation (DCN). > >OTOH, you have failed to note the cases in which negotiation is so successful that > >it is almost invisible. Consider DECnet. Once a machine is configured there is > >little chance of failure. You hook up the wires and the machine figures out wht > >topology necessary to communicate with other machines. This is a negotiation > >protocol that works. > > Have you ever worked inside a DECnet implementation? Yes. At the driver level. I'm sure you can identify a DRV-11B. > I have been paid to > port and hack code that implemented Phase IV, and then to deal with problem > reports from customers that the technical support people could not answer. > To say the least, I do not agree with your claim that DECnet "is a > negotation protocol that [always] works." Of course it does not always work. Nothing does. Point is that it is a vaible architecture. One still in use in high performance systems because it is perceived to be superior, and those making the decisions have measurements to prove it. > Even the claim that DECnet was a "negotation protcol" is not quite true > in my view. OK, let's argue that some other time. It certainly is a dynamic environment, which is enough to support the case I was presenting. > > > >Note that this class of error, noticing only the problems, is a basic wheel > >approach which causes sampling error. > >There is no alue to this sort of anecdotal horror story. If you want to address > >the topic of negotiating protocols, please produce an issue that you believe will > >be difficult to solve and lead to negotiation failures. > > You're evidently as much of a "practicing engineer" as Terry Ritter. > My point is that in theory, there are no non-trivial problems that would > need attention, but in practice there always are. > In theory, there are no anecdotes that do not conform to theory. > Practice consists of anecdotes. Garbage. I am nothing BUT a practicing engineer. Do you have an issue that you think will be difficult to solve or not? Are you simply raining on a parade or are you actually presenting a rational argument? > > > > ... > >Not relevant. We aren't faced with "complicated network stuff" or anything > >similar. Anyone adding one or more AES ciphers to an existing multi-cipher > >product already the the problem and a solution. Adding several AES ciphers to an > >existing single-cipher product is no harder than adding a single ("the") AES > >cipher; negotitaion is required. > > That is wrong. Negotiation is not necessarily required, although the > receiver does need to figure out or know by prior configuration which > cipher is in use. "Negotiation" involves proposing, rejecting, > counter-proposing, and accepting. No. In your experience negotiation may actually be an interactive process, and for DCN it could be made arbitrarily complex. But your argument appears to be that it is necessarily very complex. You have yet to support your position. In fact "negotiation" may imply more work than needs to be done. Perhaps you would feel more comfortable with the term "configuration". Whatever you call it, it could be a simple as one end sending propose-cipher-change accompanied by the target cipher and a sample encryption of a standard probe message, all covered by the current cipher. The other end sends either accept or reject, at which point the process is complete. Now to me, as a practicing engineer, a complex configuration change means upgrading the system software on a multi-user computer without disturbing the users except that they cannot type during the hardware reboot process. That happens to be the first project I undertook out of school. It worked. I belive that qualifies me to comment on the complexity of software negotiations. > "Negotiation" is not inolved in asking > the wire for a network address and accepting whatever you get. It is also > not merely looking at a header to identify a packet format or cipher. > Asking for a DHCP or BOOTP address or picking a decryption scheme and key > based on a packet header has as much to do with "negotiating" as buying > groceries in a typical American supermarket, nothing whatsoever. Your lack of experience is showing. Do you have a particular issue with cipher selection or are you reacting to the term "negotiation" instead of the referent the term indicates? > > > > creating a new product is the only case in which > >the requirement to negotiate cipher selection is an issue. Note that this is > >going to be common for reasona of backward compatibility during the > >changeover/upgrade period. > > Nonsense. Upward compatiblity does *not* need negotiating, but merely > recognizing the old form. Negotiating is required if you want to > have the sender and receiver have potentically non-overlapping sets > of ciphers and to discover and agree on the best common cipher. > It is also required by Terry Ritters proposals. > > Moreover, the "changeover/upgrade period" for protocols invariably lasts > a very long time. A case study of how long that can be is in the endurance > of DECnet Phase IV which has been officially obsolete and deprecated for > more than 10 years, but which is still a common form of DECnet (where > DECnet still exists). > Because of embedded systems, changes in cipher protocols take even longer. Exactly. This is why we should design in the requirement for flexibility as early as possible rather than wishing away the issues that madate it. > > > > ... > >You cannot just wish this requirement away. Nor can you ignore the ubiquity of > >the issue and claim that multiple AES selections creates an abnormal condition. > >As discussed above it is probably normal to have multiple ciphers. > > ... > > And you cannot just wish requirements into existence. > AES is not the first new cipher in history. Ciphers have been coming and > going for decades. Still, negotiating ciphers is not universal, and > where it is done, not without significant security problems in > practice but not theory (e.g. SSL). Your assertions support my conclusion and not your own. Thank you.
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: 25 Oct 1999 20:28:17 -0600 From: vjs@calcite.rhyolite.com (Vernon Schryver) Message-ID: <7v33k1$kh4$1@calcite.rhyolite.com> References: <381482DE.B036BC49@aspi.net> Newsgroups: sci.crypt Lines: 122 In article <381482DE.B036BC49@aspi.net>, Trevor Jackson, III <fullmoon@aspi.net> wrote: > ... >> >You can pick on negotiation failures typically those that evolved over time, which >> >usually means layers of kludge upon kludge, sometimes driven by commercial issues >> >(PPP), >> >> Base on that statement, you have no idea of the history or even nature of >> PPP. PPP in general and PPP negotiating in particular are as much as was >> possible the exact opposite of something "that evolved over time." > >So. In a previous post you alluded to the fact that the first implementations weren't >quite as functional or correct as later implementations. If this is not "evolution >over time" what is the term you use for it? Are you claiming that fixing problems in implementations has something to do with a *protocol* that you describe as "layers of kludge upon kludge"? You claimed that the PPP *protocol* involved "layers of kludge upon kludge." While some of the bugs in some of the PPP implementations might have been due to kludgy implementations, many were not. >> > and sometimes driven by technological advances (modems). >> >> That notion of the history of modems is also as wrong, based on what I've >> observed since before dial-up 1200 bit/sec modems were available >> (1,200 bit/sec, not 12,000 bps). > >Are we competing on ages or something? I've got half a dozen 300 baud modems floating > ... My impression of you is of a teenager typing in his grandfather's shop. There is great, provided you don't make up facts as you go along. You could also be an experienced system administrator. Again, that's would be a good thing, absent a habit of inventing technical facts. > ... >> Have you ever worked inside a DECnet implementation? > >Yes. At the driver level. I'm sure you can identify a DRV-11B. I'm sorry, but I do not believe that you have ever seen much DECnet or any other network code. Perhaps you installed or configured some VMS software or hardware. No one acquainted with DECnet internals would talk about as you do. >> >There is no alue to this sort of anecdotal horror story. If you want to address >> >the topic of negotiating protocols, please produce an issue that you believe will >> >be difficult to solve and lead to negotiation failures. >> >> You're evidently as much of a "practicing engineer" as Terry Ritter. >> My point is that in theory, there are no non-trivial problems that would >> need attention, but in practice there always are. >> In theory, there are no anecdotes that do not conform to theory. >> Practice consists of anecdotes. > >Garbage. I am nothing BUT a practicing engineer. I'm sorry, but I do not believe that is true as I define the notion. You could be a system administrator, system engineer, network engineer, or similar. Again, those are good things, although they do not involve much protocol or program design or implementation. >> > ... >> >Not relevant. We aren't faced with "complicated network stuff" or anything >> >similar. Anyone adding one or more AES ciphers to an existing multi-cipher >> >product already the the problem and a solution. Adding several AES ciphers to an >> >existing single-cipher product is no harder than adding a single ("the") AES >> >cipher; negotitaion is required. >> >> That is wrong. Negotiation is not necessarily required, although the >> receiver does need to figure out or know by prior configuration which >> cipher is in use. "Negotiation" involves proposing, rejecting, >> counter-proposing, and accepting. > >No. > >In your experience negotiation may actually be an interactive process, and for DCN it >could be made arbitrarily complex. But your argument appears to be that it is >necessarily very complex. You have yet to support your position. Either you or Terry Ritter described the dynamic cipher process as one system proposing a cipher and the other agreeing or rejecting it. That is necessarily your "interactive process" and what I call "negotiation." It is a good description of PPP and other negotiating protocols. It is also very different from the mechanisms used to handle upward compatibility. In those cases, the newer system recognizes the old stuff, and copes. There is no requesting, rejecting, and counter proposing between peers. The old system is by definition too stupid to understand the new stuff, and so the new system does whatever is necessary. >In fact "negotiation" may imply more work than needs to be done. Perhaps you would >feel more comfortable with the term "configuration". Whatever you call it, it could >be a simple as one end sending propose-cipher-change accompanied by the target cipher >and a sample encryption of a standard probe message, all covered by the current >cipher. The other end sends either accept or reject, at which point the process is >complete. Once again, that last is the sum total of the purpose of the PPP state machine, and it's inevitiable boundary cases, error paths,and other complications found when you write a complete state machine that are the root cause of the real world problems I keep talking about. >Now to me, as a practicing engineer, a complex configuration change means upgrading the >system software on a multi-user computer without disturbing the users except that they >cannot type during the hardware reboot process. That happens to be the first project I >undertook out of school. It worked. I belive that qualifies me to comment on the >complexity of software negotiations. No, while system installation, configuration, and upgrading are often major hassles and can be iterative, they are very different from what computers do in a negotiating network protocol. Please do not bother responding. Vernon Schryver vjs@rhyolite.com
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Mon, 25 Oct 1999 12:19:29 -0400 From: "Trevor Jackson, III" <fullmoon@aspi.net> Message-ID: <38148311.ADAFCFCB@aspi.net> References: <7uvb7e$q7s$1@calcite.rhyolite.com> Newsgroups: sci.crypt Lines: 175 Vernon Schryver wrote: > In article <38131CDC.40A35B01@aspi.net>, > Trevor Jackson, III <fullmoon@aspi.net> wrote: > > > ... > >> Only salescritters or people with no technical knowledge can claim that > >> either PPP or modems are examples that could cause a working engineer to > >> be enthusaistic about negotiating ciphers. Sane, technically inclined > >> people who look at modems, PPP, or any other "standardized", dynamic > >> negotiating network protocol must be very skeptical of the idea. > > > >Any other? I think not. > > > >You can pick on negotiation failures typically those that evolved over time, which > >usually means layers of kludge upon kludge, sometimes driven by commercial issues > >(PPP), > > Base on that statement, you have no idea of the history or even nature of > PPP. PPP in general and PPP negotiating in particular are as much as was > possible the exact opposite of something "that evolved over time." So. In a previous post you alluded to the fact that the first implementations weren't quite as functional or correct as later implementations. If this is not "evolution over time" what is the term you use for it? > (Before you argue with me about the history of PPP, please tell me under > what name I can find your words in the IETF PPP WG archives.) > > > and sometimes driven by technological advances (modems). > > That notion of the history of modems is also as wrong, based on what I've > observed since before dial-up 1200 bit/sec modems were available > (1,200 bit/sec, not 12,000 bps). Are we competing on ages or something? I've got half a dozen 300 baud modems floating around here someplace, and a couple of monster 1200 baud mini computer modems. I know what got us from there to here. It wasn't a trivial process. It was ugly then and is still ugly now. I do not belive this is an appropriate basis for comparison with dynamic cipher negotiation (DCN). > >OTOH, you have failed to note the cases in which negotiation is so successful that > >it is almost invisible. Consider DECnet. Once a machine is configured there is > >little chance of failure. You hook up the wires and the machine figures out wht > >topology necessary to communicate with other machines. This is a negotiation > >protocol that works. > > Have you ever worked inside a DECnet implementation? Yes. At the driver level. I'm sure you can identify a DRV-11B. > I have been paid to > port and hack code that implemented Phase IV, and then to deal with problem > reports from customers that the technical support people could not answer. > To say the least, I do not agree with your claim that DECnet "is a > negotation protocol that [always] works." Of course it does not always work. Nothing does. Point is that it is a vaible architecture. One still in use in high performance systems because it is perceived to be superior, and those making the decisions have measurements to prove it. > Even the claim that DECnet was a "negotation protcol" is not quite true > in my view. OK, let's argue that some other time. It certainly is a dynamic environment, which is enough to support the case I was presenting. > > > >Note that this class of error, noticing only the problems, is a basic wheel > >approach which causes sampling error. > >There is no alue to this sort of anecdotal horror story. If you want to address > >the topic of negotiating protocols, please produce an issue that you believe will > >be difficult to solve and lead to negotiation failures. > > You're evidently as much of a "practicing engineer" as Terry Ritter. > My point is that in theory, there are no non-trivial problems that would > need attention, but in practice there always are. > In theory, there are no anecdotes that do not conform to theory. > Practice consists of anecdotes. Garbage. I am nothing BUT a practicing engineer. Do you have an issue that you think will be difficult to solve or not? Are you simply raining on a parade or are you actually presenting a rational argument? > > > > ... > >Not relevant. We aren't faced with "complicated network stuff" or anything > >similar. Anyone adding one or more AES ciphers to an existing multi-cipher > >product already the the problem and a solution. Adding several AES ciphers to an > >existing single-cipher product is no harder than adding a single ("the") AES > >cipher; negotitaion is required. > > That is wrong. Negotiation is not necessarily required, although the > receiver does need to figure out or know by prior configuration which > cipher is in use. "Negotiation" involves proposing, rejecting, > counter-proposing, and accepting. No. In your experience negotiation may actually be an interactive process, and for DCN it could be made arbitrarily complex. But your argument appears to be that it is necessarily very complex. You have yet to support your position. In fact "negotiation" may imply more work than needs to be done. Perhaps you would feel more comfortable with the term "configuration". Whatever you call it, it could be a simple as one end sending propose-cipher-change accompanied by the target cipher and a sample encryption of a standard probe message, all covered by the current cipher. The other end sends either accept or reject, at which point the process is complete. Now to me, as a practicing engineer, a complex configuration change means upgrading the system software on a multi-user computer without disturbing the users except that they cannot type during the hardware reboot process. That happens to be the first project I undertook out of school. It worked. I belive that qualifies me to comment on the complexity of software negotiations. > "Negotiation" is not inolved in asking > the wire for a network address and accepting whatever you get. It is also > not merely looking at a header to identify a packet format or cipher. > Asking for a DHCP or BOOTP address or picking a decryption scheme and key > based on a packet header has as much to do with "negotiating" as buying > groceries in a typical American supermarket, nothing whatsoever. Your lack of experience is showing. Do you have a particular issue with cipher selection or are you reacting to the term "negotiation" instead of the referent the term indicates? > > > > creating a new product is the only case in which > >the requirement to negotiate cipher selection is an issue. Note that this is > >going to be common for reasona of backward compatibility during the > >changeover/upgrade period. > > Nonsense. Upward compatiblity does *not* need negotiating, but merely > recognizing the old form. Negotiating is required if you want to > have the sender and receiver have potentically non-overlapping sets > of ciphers and to discover and agree on the best common cipher. > It is also required by Terry Ritters proposals. > > Moreover, the "changeover/upgrade period" for protocols invariably lasts > a very long time. A case study of how long that can be is in the endurance > of DECnet Phase IV which has been officially obsolete and deprecated for > more than 10 years, but which is still a common form of DECnet (where > DECnet still exists). > Because of embedded systems, changes in cipher protocols take even longer. Exactly. This is why we should design in the requirement for flexibility as early as possible rather than wishing away the issues that madate it. > > > > ... > >You cannot just wish this requirement away. Nor can you ignore the ubiquity of > >the issue and claim that multiple AES selections creates an abnormal condition. > >As discussed above it is probably normal to have multiple ciphers. > > ... > > And you cannot just wish requirements into existence. > AES is not the first new cipher in history. Ciphers have been coming and > going for decades. Still, negotiating ciphers is not universal, and > where it is done, not without significant security problems in > practice but not theory (e.g. SSL). Your assertions support my conclusion and not your own. Thank you.
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Mon, 25 Oct 1999 00:14:16 -0600 From: jgfunj@vgrknf.arg (wtshaw) Message-ID: <jgfunj-2510990014160001@dial-243-047.itexas.net> References: <3812005b.8360995@news.io.com> Newsgroups: sci.crypt Lines: 46 In article <3812005b.8360995@news.io.com>, ritter@io.com (Terry Ritter) wrote: > > Cipher negotiation can be far cleaner -- provided a single selection > mechanism is standardized. If not, then we may see the same sort of > ad hoc stuff we saw with modems. ... > > Because the need is to change ciphers frequently, the desired > negotiation process is not one-time at the start, but rather, a > frequent or continuous process in different messages or sessions. > .... > > There is no other possibility, unless you wish to depend upon the > strength of a cipher which explicitly HAS *no* known or guaranteed > strength. Not having strength is not a trivial detail, this is the > essence of the reason for using a cipher. > > The ability to change ciphers offers each of us the power to choose > what cipher we want to use. This means no government organization is > edicting our use, or forcing it through market pressure. We get to > choose what to use, and what not to use, and to change our minds on a > daily basis. That is not a trivial advantage. > Well, how clean can it be: Figure that you have a list of ciphers which you will accept. It is up to the sender to speak in one or them, at least. Figure that you develop a means of generating a key for any of them, but from something which may be acceptable in form to anyone of them, text of some sufficient length. The recepient generates all the keys as needed, tries one at a time with an appropriate algorithm on the ciphertext. The system should lock to the one with the most appropriate recovered plaintext, likely only one that makes sense. To change cryptosystems, just do it; at the other end, detection falls out of lock as the current system fails to recover reasonable output, and go back to checking the various algorithms, getting the new system, locking until unlocked. Sounds simple enough to me, but who am I to judge? -- Sometime ago, Gates bought lots of shares of Apple. My preference is to keep the Worm out of the Apple.
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Mon, 25 Oct 1999 08:14:16 +0200 From: jgfunj@vgrknf.arg (jgfunj@vgrknf.arg) Message-ID: <fc.3b9aca00f7d881713b9aca008f91dec6.10ab1@peg.dyndns.org> References: <jgfunj-2510990014160001@dial-243-047.itexas.net> Newsgroups: sci.crypt Lines: 48 In article <3812005b.8360995@news.io.com>, ritter@io.com (Terry Ritter) wrote: >> >> Cipher negotiation can be far cleaner -- provided a single selection >> mechanism is standardized. If not, then we may see the same sort of >> ad hoc stuff we saw with modems. ... >> >> Because the need is to change ciphers frequently, the desired >> negotiation process is not one-time at the start, but rather, a >> frequent or continuous process in different messages or sessions. >> .... >> >> There is no other possibility, unless you wish to depend upon the >> strength of a cipher which explicitly HAS *no* known or guaranteed >> strength. Not having strength is not a trivial detail, this is the >> essence of the reason for using a cipher. >> >> The ability to change ciphers offers each of us the power to choose >> what cipher we want to use. This means no government organization is >> edicting our use, or forcing it through market pressure. We get to >> choose what to use, and what not to use, and to change our minds on a >> daily basis. That is not a trivial advantage. >> Well, how clean can it be: Figure that you have a list of ciphers which you will accept. It is up to the sender to speak in one or them, at least. Figure that you develop a means of generating a key for any of them, but from something which may be acceptable in form to anyone of them, text of some sufficient length. The recepient generates all the keys as needed, tries one at a time with an appropriate algorithm on the ciphertext. The system should lock to the one with the most appropriate recovered plaintext, likely only one that makes sense. To change cryptosystems, just do it; at the other end, detection falls out of lock as the current system fails to recover reasonable output, and go back to checking the various algorithms, getting the new system, locking until unlocked. Sounds simple enough to me, but who am I to judge? -- Sometime ago, Gates bought lots of shares of Apple. My preference is to keep the Worm out of the Apple. {}{}{} Posted via Uncensored-News.Com, http://www.uncensored-news.com {}{}{} {}{}{}{} Only $8.95 A Month, - The Worlds Uncensored News Source {}{}{}{} {}{}{}{}{} Five News Servers with a BINARIES ONLY Server {}{}{}{}{}
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: 25 Oct 1999 00:51:22 -0600 From: vjs@calcite.rhyolite.com (Vernon Schryver) Message-ID: <7v0ula$cc9$1@calcite.rhyolite.com> References: <jgfunj-2510990014160001@dial-243-047.itexas.net> Newsgroups: sci.crypt Lines: 41 In article <jgfunj-2510990014160001@dial-243-047.itexas.net>, wtshaw <jgfunj@vgrknf.arg> wrote: > ... >Well, how clean can it be: Figure that you have a list of ciphers which >you will accept. It is up to the sender to speak in one or them, at >least. > ... >To change cryptosystems, just do it; at the other end, detection falls out >of lock as the current system fails to recover reasonable output, and go >back to checking the various algorithms, getting the new system, locking >until unlocked. > >Sounds simple enough to me, but who am I to judge? Look at PPP compression for examples of complications. Compression is very much like encryption, as has been pointed out here many times, so you can't just shrug off the PPP compression follies. For example, what you do when both peers can handle both A and B, but one strongly prefers A while the other prefers B. Say one peer has AES type I hardware but does type II in 8-bit 3 MHz software, and vice versa for the other peer. What do you do, and why? For another example, look at the last ten (10) years of complications in the PPP IPCP IP address negotiations. In the initial theories, those problems were too trivial to worry about. It wasn't until systems got into the field that our noses were rubbed in the holes in the theories. The worst result of the compression negotiation complications (as well as egregious bugs by a large vendor or two, and a dose or two of embrace-and-extend by a very large software outfit) is that you can't count on your PPP data being compressed. The equivalent result for negotiating ciphers, not being able to count on your data being encrypted, strikes me as a little more serious. -- Vernon Schryver vjs@rhyolite.com
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Mon, 25 Oct 1999 08:51:22 +0200 From: vjs@calcite.rhyolite.com (vjs@calcite.rhyolite.com) Message-ID: <fc.3b9aca00502e21e63b9aca008f91dec6.10ab7@peg.dyndns.org> References: <7v0ula$cc9$1@calcite.rhyolite.com> Newsgroups: sci.crypt Lines: 43 In article <jgfunj-2510990014160001@dial-243-047.itexas.net>, wtshaw <jgfunj@vgrknf.arg> wrote: >> ... >>Well, how clean can it be: Figure that you have a list of ciphers which >>you will accept. It is up to the sender to speak in one or them, at >>least. >> ... >>To change cryptosystems, just do it; at the other end, detection falls >out >>of lock as the current system fails to recover reasonable output, and go >>back to checking the various algorithms, getting the new system, locking >>until unlocked. >> >>Sounds simple enough to me, but who am I to judge? Look at PPP compression for examples of complications. Compression is very much like encryption, as has been pointed out here many times, so you can't just shrug off the PPP compression follies. For example, what you do when both peers can handle both A and B, but one strongly prefers A while the other prefers B. Say one peer has AES type I hardware but does type II in 8-bit 3 MHz software, and vice versa for the other peer. What do you do, and why? For another example, look at the last ten (10) years of complications in the PPP IPCP IP address negotiations. In the initial theories, those problems were too trivial to worry about. It wasn't until systems got into the field that our noses were rubbed in the holes in the theories. The worst result of the compression negotiation complications (as well as egregious bugs by a large vendor or two, and a dose or two of embrace-and-extend by a very large software outfit) is that you can't count on your PPP data being compressed. The equivalent result for negotiating ciphers, not being able to count on your data being encrypted, strikes me as a little more serious. -- Vernon Schryver vjs@rhyolite.com {}{}{} Posted via Uncensored-News.Com, http://www.uncensored-news.com {}{}{} {}{}{}{} Only $8.95 A Month, - The Worlds Uncensored News Source {}{}{}{} {}{}{}{}{} Five News Servers with a BINARIES ONLY Server {}{}{}{}{}
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Mon, 25 Oct 1999 11:52:04 -0600 From: jgfunj@vgrknf.arg (wtshaw) Message-ID: <jgfunj-2510991152040001@dial-243-058.itexas.net> References: <7v0ula$cc9$1@calcite.rhyolite.com> Newsgroups: sci.crypt Lines: 19 In article <7v0ula$cc9$1@calcite.rhyolite.com>, vjs@calcite.rhyolite.com (Vernon Schryver) wrote: > > The worst result of the compression negotiation complications (as well as > egregious bugs by a large vendor or two, and a dose or two of > embrace-and-extend by a very large software outfit) is that you can't > count on your PPP data being compressed. The equivalent result for > negotiating ciphers, not being able to count on your data being encrypted, > strikes me as a little more serious. It does not follow that if you pick a sending cipher, from a list that you are ready to use, that you worry about your data not being encrypted. If someone will not accept the same cipher(s), then you have a problem, so you only negotiate one list of mutually acceptable ciphers. Compression has nothing to do with it, unless both of you agree on a cipher that uses it. -- Sometime ago, Gates bought lots of shares of Apple. My preference is to keep the Worm out of the Apple.
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Mon, 25 Oct 1999 12:20:51 -0400 From: "Trevor Jackson, III" <fullmoon@aspi.net> Message-ID: <38148363.5693C841@aspi.net> References: <jgfunj-2510990014160001@dial-243-047.itexas.net> Newsgroups: sci.crypt Lines: 55 wtshaw wrote: > In article <3812005b.8360995@news.io.com>, ritter@io.com (Terry Ritter) wrote: > > > > Cipher negotiation can be far cleaner -- provided a single selection > > mechanism is standardized. If not, then we may see the same sort of > > ad hoc stuff we saw with modems. > ... > > > > Because the need is to change ciphers frequently, the desired > > negotiation process is not one-time at the start, but rather, a > > frequent or continuous process in different messages or sessions. > > > .... > > > > There is no other possibility, unless you wish to depend upon the > > strength of a cipher which explicitly HAS *no* known or guaranteed > > strength. Not having strength is not a trivial detail, this is the > > essence of the reason for using a cipher. > > > > The ability to change ciphers offers each of us the power to choose > > what cipher we want to use. This means no government organization is > > edicting our use, or forcing it through market pressure. We get to > > choose what to use, and what not to use, and to change our minds on a > > daily basis. That is not a trivial advantage. > > > Well, how clean can it be: Figure that you have a list of ciphers which > you will accept. It is up to the sender to speak in one or them, at > least. > > Figure that you develop a means of generating a key for any of them, but > from something which may be acceptable in form to anyone of them, text of > some sufficient length. > > The recepient generates all the keys as needed, tries one at a time with > an appropriate algorithm on the ciphertext. The system should lock to the > one with the most appropriate recovered plaintext, likely only one that > makes sense. This becomes trivial if the initial message contains a standard plaintext. > > > To change cryptosystems, just do it; at the other end, detection falls out > of lock as the current system fails to recover reasonable output, and go > back to checking the various algorithms, getting the new system, locking > until unlocked. > > Sounds simple enough to me, but who am I to judge? > -- > Sometime ago, Gates bought lots of shares of Apple. > My preference is to keep the Worm out of the Apple.
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Tue, 26 Oct 1999 11:09:11 -0600 From: jgfunj@vgrknf.arg (wtshaw) Message-ID: <jgfunj-2610991109110001@dial-243-006.itexas.net> References: <38148363.5693C841@aspi.net> Newsgroups: sci.crypt Lines: 28 In article <38148363.5693C841@aspi.net>, "Trevor Jackson, III" <fullmoon@aspi.net> wrote: > wtshaw wrote: > > > The recepient generates all the keys as needed, tries one at a time with > > an appropriate algorithm on the ciphertext. The system should lock to the > > one with the most appropriate recovered plaintext, likely only one that > > makes sense. > > This becomes trivial if the initial message contains a standard plaintext. > From time to time I have put in code that looks for text in decryption. The simple GIGO is adequate to warn that text was not encrypted. If spaces are encrypted one way of the other it is simple to get an average word length, perhaps variance, or any of many liguistic tests as well. As you say, putting encrypted text at the beginning makes algorithm verification reasonable. > > > > To change cryptosystems, just do it; at the other end, detection falls out > > of lock as the current system fails to recover reasonable output, and go > > back to checking the various algorithms, getting the new system, locking > > until unlocked. > > -- Sometime ago, Gates bought lots of shares of Apple. My preference is to keep the Worm out of the Apple.
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Fri, 29 Oct 1999 03:21:24 GMT From: ritter@io.com (Terry Ritter) Message-ID: <38191286.5286277@news.io.com> References: <jgfunj-2510990014160001@dial-243-047.itexas.net> Newsgroups: sci.crypt Lines: 91 On Mon, 25 Oct 1999 00:14:16 -0600, in <jgfunj-2510990014160001@dial-243-047.itexas.net>, in sci.crypt jgfunj@vgrknf.arg (wtshaw) wrote: >In article <3812005b.8360995@news.io.com>, ritter@io.com (Terry Ritter) wrote: >> >> Cipher negotiation can be far cleaner -- provided a single selection >> mechanism is standardized. If not, then we may see the same sort of >> ad hoc stuff we saw with modems. >... >> >> Because the need is to change ciphers frequently, the desired >> negotiation process is not one-time at the start, but rather, a >> frequent or continuous process in different messages or sessions. >> >.... >> >> There is no other possibility, unless you wish to depend upon the >> strength of a cipher which explicitly HAS *no* known or guaranteed >> strength. Not having strength is not a trivial detail, this is the >> essence of the reason for using a cipher. >> >> The ability to change ciphers offers each of us the power to choose >> what cipher we want to use. This means no government organization is >> edicting our use, or forcing it through market pressure. We get to >> choose what to use, and what not to use, and to change our minds on a >> daily basis. That is not a trivial advantage. >> >Well, how clean can it be: Figure that you have a list of ciphers which >you will accept. It is up to the sender to speak in one or them, at >least. Either end could and should have their own list. Either end could propose a cipher from that list, or send the whole list. When the other end accepts, or sends back a cipher name that can be accepted, the cipher changes. If agreement never occurs, the user should be notified, but from the point of view of the cipher change state system, the next change simply has not yet occurred. Also I would support a different cipher in each direction, thus simplifying the negotiation process. >Figure that you develop a means of generating a key for any of them, but >from something which may be acceptable in form to anyone of them, text of >some sufficient length. I would require each cipher to have some sort of hash which takes a sequence of bytes to the internal keying value for that particular cipher. The sequence of bytes could be a textual keyphrase of almost arbitrary length, or just a random binary. In this way, we can use the same key with any cipher we pick, and do not have to pick keys of a particular form for each particular cipher. >The recepient generates all the keys as needed, tries one at a time with >an appropriate algorithm on the ciphertext. The system should lock to the >one with the most appropriate recovered plaintext, likely only one that >makes sense. I would require the cipher system to include a hash of the message with each message. This is not only to aid dynamically changing the cipher, but also because using the wrong key is, in my experience, the major sort of error which users encounter (assuming a stable implementation). It is important to detect common user errors. So, when the cipher changes, the cipher is *either* the last cipher used, being used again, or the new cipher, just proposed. We try the old one, then the new one. If the new one is OK, we accept it. If neither, the next time we get a message we try both again. >To change cryptosystems, just do it; at the other end, detection falls out >of lock as the current system fails to recover reasonable output, and go >back to checking the various algorithms, getting the new system, locking >until unlocked. > >Sounds simple enough to me, but who am I to judge? We can improve the efficiency quite a bit, but that is the general idea. Maybe "negotiation" is the wrong word for many people: Actually, it's a normal sort of handshake that we complete simply by using the new cipher. --- Terry Ritter ritter@io.com http://www.io.com/~ritter/ Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Tue, 26 Oct 1999 23:04:06 GMT From: dianelos@tecapro.com Message-ID: <7v5c14$q8q$1@nnrp1.deja.com> References: <3812005b.8360995@news.io.com> Newsgroups: sci.crypt Lines: 78 In article <3812005b.8360995@news.io.com>, ritter@io.com (Terry Ritter) wrote: > To start any conversation in cipher, it is currently necessary to > acquire common keys. Everyone understands this. So everyone should > be well prepared to understand that we can *also* acquire a cipher > name, or even a cipher itself, in the same way, through the same > channel. This is not a big conceptual leap. > > Once we have a conversation in cipher, we can assign part of it to a > "control channel," where negotiation takes place (...) I quite agree, but maybe the word "negotiation" is not the best one in this context. We can add to the encrypted data the code necessary for decrypting it. That is, we can create software objects that include both data and methods for processing it. In a world that is interconnected and software driven, you don't have to physically add code, just point to a place where certified code can be downloaded from (as you say just "name" it). If the code is in Java you have a solution that is global in scope and flexible. If you worry about speed publish code optimized for several hardware platforms. No negotiation between the communicating partners takes place for defining which security algorithms will be used. Simply, the one who receives an encrypted message (or a challenge for starting a secure session) checks to see if the code necessary for processing this is loaded locally. If not, it downloads it from a central repository, checks its signature, checks whether the signer is to be trusted, and executes the code (and adds it to the menu of code held locally for future use). Encryption technology can now grow unhindered by widely used standards that in the future may become unstable or be left behind. For this to work of course, we do need one certification standard we can trust for the long run. Everything else though becomes liquid. If you write your own email client and want to send mail encrypted by the second AES winner cascaded with 3DES and ABC and finally with XYZ, just publish Java code for your super-duper cipher in the central server, get it certified and assigned a number (or a name for that matter), and you are done. Your email client will be able to send encrypted mail to any other email client in the word which will know what to do to decrypt your messages – if it chooses to accept your messages. If you don't trust this liquid world and only trust the AES for your symmetric cipher, then nothing changes. You just send all your messages flagged as AES messages or even refuse to read any messages not flagged AES. In a Darwinian world, people who do choose the best algorithms will thrive; these may very well turn out to be the ones who choose the AES and not, say, your ciphers or mine. On the other hand, if we artificially restrict the free competition of algorithms, then in the end we shall all end using sub-par algorithms. My basic point is that if *you* own the information you are sending you might as well define how *you* want to protect it. In other words if you own information you should be able to structure it any way you like. I do believe in standards as a way to facilitate communication - but not as a way to limit how communication will take place. I don't think there are good technical reasons for restricting the structure of the communication - after all if you want to talk to a hardwired high speed link then you may just respect *its* protocols. OTOH I think there are many security and economic advantages for not imposing one micro-standard to everybody. I see some relation to the way a capitalistic society works: as long as you don't use an illegal method you can manage your properties any way you like. In this system of free competition, the ones who invent or choose the most effective methods thrive and drive the rest of the economy. I think that in the information society of the future we should also be careful to motivate rather than restrict the free competition of methods for managing information: the algorithms. I do see the need for the AES or maybe for a few widely respected ciphers. I do think that we need good and standardized security primitives. What we don't need is a high level inflexible standard that restricts us to use only one or one out of a few given primitives. Sent via Deja.com http://www.deja.com/ Before you buy.
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Wed, 20 Oct 1999 21:00:42 +0200 From: Mok-Kong Shen <mok-kong.shen@t-online.de> Message-ID: <380E1159.721F0732@t-online.de> References: <940429167.19519.0.nnrp-12.c2de6a96@news.demon.co.uk> Newsgroups: sci.crypt Lines: 31 Brian Gladman wrote: > > Although its quite possible that a better cipher might be constructed by > combining the techniques used in the AES algorithms in different ways, I am > rather uncertain that those who have the knowledge to do this would want to > repeat the process of algorithm development just undertaken for AES all over > again. > > Moreover, as an outsider to the field of cipher design, I have the > impression that the problem here is not so much how to jumble things up but > rather that of knowing whether the result is secure. I hence suspect that > more work on the cryptanalysis of the five AES finalists in their current > form may be more effective in improving algorithm security than the > synthesis of new algorithms right now. It is certainly advantageous to have the best people in the crypto field focus their attention to a few ciphers that are used by the general public so that any defects could be found as early as possible. I have little doubt that that will indeed be the case. We'll soon see a large number of papers on AES just as we have seen papers on DES in the past, I believe. On the other hand, I consider it a pity if some good ideas that are specific to the individual candidates fail to obtain their deserved attention simply because these candidates don't get into the final round. So I would like to see one or two competent professionals undertaking the task of carefully surveying all the submitted candidates and extracting out what is most valuable in each of them such that these knowledges could be appreciated and understood by all having interest in cryptology. M. K. Shen
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: 21 Oct 99 05:46:26 GMT From: jsavard@ecn.ab.ca () Message-ID: <380ea8b2.0@ecn.ab.ca> References: <940429167.19519.0.nnrp-12.c2de6a96@news.demon.co.uk> Newsgroups: sci.crypt Lines: 35 Brian Gladman (gladman@seven77.demon.co.uk) wrote: : Mok-Kong Shen <mok-kong.shen@t-online.de> wrote in message : news:380D8C32.F96649DF@t-online.de... : > Has anybody made serious thought of the possibility of extracting : > some of the good ideas from each submitted AES candidate and doing : > some variations (to avoid patent problems) and putting in some : > proper ideas of one's own to arrive at a new design? I mean one Well, I've gone beyond *thinking* about it. Look at Quadibloc II through Quadibloc VI on my web site. : Although its quite possible that a better cipher might be constructed by : combining the techniques used in the AES algorithms in different ways, I am : rather uncertain that those who have the knowledge to do this would want to : repeat the process of algorithm development just undertaken for AES all over : again. As you point out later, cipher _design_ isn't the hard part: : Moreover, as an outsider to the field of cipher design, I have the : impression that the problem here is not so much how to jumble things up but : rather that of knowing whether the result is secure. I hence suspect that : more work on the cryptanalysis of the five AES finalists in their current : form may be more effective in improving algorithm security than the : synthesis of new algorithms right now. But we can take the lessons learned from that cryptanalysis, and put together some somewhat overdesigned ciphers from it fairly easily. And Quadibloc III, in particular, shows what I've done to take a lesson from FROG, and design a single cipher that pretends to be multiple ciphers. John Savard
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Wed, 20 Oct 1999 21:00:50 +0200 From: Mok-Kong Shen <mok-kong.shen@t-online.de> Message-ID: <380E1162.B881144D@t-online.de> References: <380DFA11.48429AE1@aspi.net> <380D8C32.F96649DF@t-online.de> Newsgroups: sci.crypt Lines: 33 Trevor Jackson, III wrote: > > It seems that every language ever used has a legacy user community. Conglomerate > languages are difficult to work with (i.e., the complexity is a source of bugs). > Conglomerate ciphers would be a disaster because the complexity would be a source > of weakness. I don't like to revive a debate over PL/I that is now more than two decades old. (But let me say that I didn't even agree with the critic raised at that time that the language is a conglomerate.) My point in the previous post was that in my view there are probably good stuffs in each of the AES candidates and that these (the ideas) could be utilized in some way to advantage in some future designs. > > I believe that by careful combination, layering, one can effectively combine > ciphers to increase strength. But one cannot build ciphers as one builds lego > projects. Taking apart a few ciphers does not get you pieces that you can > naturally combine to create a new cipher. Design concepts, perhaps, are > reusable. But a good cipher needs a synergism and inner harmony reminiscent of > the most elegant math and physics theories. In my view it depends on the level of abstraction of getting the relevant stuffs. 'Physically' extracting from different ciphers and putting them together is impossible. At one level up you get bad ciphers. Another level up you get something better, and so on. It is the underlying idea (basic principle) that one needs. (Like in a math course one should learn the methodology of solving problems, while the concrete solution of specific problems in a given text book is by itself comparatively less important.) M. K. Shen
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Fri, 22 Oct 1999 11:55:22 +0200 From: Mok-Kong Shen <mok-kong.shen@t-online.de> Message-ID: <3810348A.8FF09BDA@t-online.de> References: <7uodib$vh6$1@nnrp1.deja.com> <940406238.7557.0.nnrp-07.c2de6a96@news.demon.co.uk> Newsgroups: sci.crypt Lines: 14 bryan.olson@uptronics.com wrote: > > I agree with what Massey said at the first AES conference, > that the number of rounds should increase with the key > size. Of the five finalists, Rijndael is the only one > that calls for more rounds when using longer keys. I can well inmagine that it is true that the number of rounds should increase with the key size in order to attain an optimal design, without however being able to state very concrete and firm arguments. Do you happen to remember the arguments of Massey? Would you please tell these? Thanks. M. K. Shen
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Wed, 20 Oct 1999 09:34:14 -0700 From: jlundell@resilience.com (Jonathan Lundell) Message-ID: <jlundell-2010990934140001@207.213.213.113> References: <380cb79d.5790473@news.visi.com> <19991019142122.19497.00000029@ng-cm1.aol.com> <380c880a.3619680@news.visi.com> Newsgroups: sci.crypt Lines: 17 In article <380cb79d.5790473@news.visi.com>, schneier@counterpane.com (Bruce Schneier) wrote: > >When "I" say parallel, I mean multiple encryption (Super AES) for very > >important data. I do not mean randomly picking one of many or any similar > >thing. > > I'm sorry. That sounds more like serial than parallel. At the risk of pointing out the obvious, what we have here is a breakdown of the "weak link" metaphor. "Multiple encryption", or cascading, I suppose, means serial encryption, yes. But the corresponding physical analogy in the "weak link" metaphor is parallel links, or chains. -- /Jonathan Lundell. jlundell@resilience.com
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: 19 Oct 1999 18:38:09 GMT From: djohn37050@aol.com (DJohn37050) Message-ID: <19991019143809.19497.00000032@ng-cm1.aol.com> References: <380f8b12.4395746@news.visi.com> Newsgroups: sci.crypt Lines: 36 X9F1 meetings are open, not closed. Anyone can attend, only members can vote. If anyone wants to make a counter-presentation they can, just get on the agenda. But it does seem to me that people are talking in circles. First group says: Anything is better than nothing which is about what we have now, so lets make it simple and choose one. Second group says: Hey, not so fast, what if one breaks? First: But that is complex. Second: Yes, and it can be handled. First: It is difficult to do right. Second: Yes, but if I want to do so, I should be able to do so. First: But it is complex and may not interoperate. Second: Life can be complex, negotiate to interoperate. First: But it will cost more. Second: Maybe not. In any case, if one breaks the cost is astronomical. X9F1: We have multiple asymmetric algs, it makes sense to also have multiple symmetric algs. First: Whoa, that was a dumb decision after a one-sided pitch, if it even was a decision. Second: It was a vote, actually 2 votes. First: Well, they did not know what they were doing. Second: Maybe they do. Both have their points and perspectives. I guess it will be an interesting 3rd AES conference. My attitude is yes, having more than one means someone may get it wrong, but this is not a reason not to have it. Do we have redundant computers on space missions? Why? Do we have redundant brake systems on cars? Why? It is simpler and cheaper not to do this, but there are reasons to add complexity. Safety and security reasons. Don Johnson
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Wed, 20 Oct 1999 11:32:08 +0200 From: Mok-Kong Shen <mok-kong.shen@t-online.de> Message-ID: <380D8C18.F251FF3A@t-online.de> References: <7ujled$1vrq@enews1.newsguy.com> <19991019143809.19497.00000032@ng-cm1.aol.com> Newsgroups: sci.crypt Lines: 18 Roger Schlafly wrote: > > And ciphers have a multiplicity of keys to choose from. If a > key is compromised, you switch to a different key. The AES > candidates have a very large key space. If a cipher has weakness that can be exploited, like DES in respect of differential analysis etc., a very large key space alone doesn't necessarily give one a very good and comfortable feeling of security, I am afraid. (I gave though recently in another thread that DES can be rendered immune to differential analysis simply via using variable keys for the blocks, a method which is evidently also applicable to AES.) M. K. Shen ----------------------------- http://home.t-online.de/home/mok-kong.shen
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: 20 Oct 1999 03:16:49 GMT From: djohn37050@aol.com (DJohn37050) Message-ID: <19991019231649.22027.00000075@ng-cm1.aol.com> References: <MPG.1276b7f2f5c996fd98971b@news.mindspring.com> Newsgroups: sci.crypt Lines: 11 Jerry, you have a GREAT reason to have more than one AES winner, in a satellite, the cost of more than one is small, but the cost of another satellite is huge. I am certain there are other examples like this. And what is the US government supposed to do if their only pick breaks? Hurry up and certify another algorithm? Guess and pick a non-certified one? It is clear to me that for SOME scenarios, it is mandatory to have more than one AES winner. Don Johnson
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Tue, 19 Oct 1999 23:38:11 -0400 From: "Trevor Jackson, III" <fullmoon@aspi.net> Message-ID: <380D3923.8B5E1D50@aspi.net> References: <19991019231649.22027.00000075@ng-cm1.aol.com> Newsgroups: sci.crypt Lines: 34 DJohn37050 wrote: > Jerry, you have a GREAT reason to have more than one AES winner, in a > satellite, the cost of more than one is small, but the cost of another > satellite is huge. > > I am certain there are other examples like this. > > And what is the US government supposed to do if their only pick breaks? Hurry > up and certify another algorithm? Guess and pick a non-certified one? It is > clear to me that for SOME scenarios, it is mandatory to have more than one AES > winner. Let's consider this in a bit more detail. What would happen if a suspicion were cast over "the" single AES winner? Not a catastrophic break, but, say, a non-constructive proof that a weakness of such-and-such work factor existed. We'd want to activate a backup. I just came from a Personal Protection course where, among other things, one learns the rules of various forms of fighting. Rule #1 of a gunfight is "Have a gun." To activate a backup on must "have a backup". If NIST's contest results were presented using a win/place/show ranking system we could use the "place" cipher as a secondary or backup mechanism to be deployed only in mission-critical systems. For truly serious systems, like NASA's man-rated systems criteria, we could provided a tertiary cipher with the "show" entry. This proposal suggests that NIST apply a _ranking_ to the ciphers rather than a binary accept/reject result. Given a clear "winner" most of the simplicity/cost/interoperability/standardization arguments disappear. We'd _have_ a winnner. But we'd also have alternates. Backups. Options in case of disaster or better optimization for particular applications.
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Wed, 20 Oct 1999 19:05:59 GMT From: bryan.olson@uptronics.com Message-ID: <7ul3qc$je6$1@nnrp1.deja.com> References: <380D3923.8B5E1D50@aspi.net> Newsgroups: sci.crypt Lines: 30 Trevor Jackson, III wrote: > I just came from a Personal Protection course where, among other things, one > learns the rules of various forms of fighting. Rule #1 of a gunfight is "Have a > gun." Nope. It's "Stay out of gunfights". > To activate a backup on must "have a backup". If NIST's > contest results were presented using a win/place/show ranking system [...] > For truly serious systems, like NASA's man-rated > systems criteria, we could provided a tertiary cipher > with the "show" entry. For truly serious privacy systems, how easily we can replace it if we find it's broken is far from the greatest of our worries. We can't un-send encrypted messages. When we encrypt a message under cipher X, we depend on X for as long as that message remains sensitive. --Bryan Sent via Deja.com http://www.deja.com/ Before you buy.
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Wed, 20 Oct 1999 16:38:10 -0400 From: "Trevor Jackson, III" <fullmoon@aspi.net> Message-ID: <380E2832.B7397664@aspi.net> References: <7ul3qc$je6$1@nnrp1.deja.com> Newsgroups: sci.crypt Lines: 41 bryan.olson@uptronics.com wrote: > Trevor Jackson, III wrote: > > > I just came from a Personal Protection course where, among other > things, one > > learns the rules of various forms of fighting. Rule #1 of a gunfight > is "Have a > > gun." > Nope. It's "Stay out of gunfights". That's a low-numbered rule of suvival. Different, enclosing domain. > > > > To activate a backup on must "have a backup". If NIST's > > contest results were presented using a win/place/show ranking system > [...] > > For truly serious systems, like NASA's man-rated > > systems criteria, we could provided a tertiary cipher > > with the "show" entry. > > For truly serious privacy systems, how easily > we can replace it if we find it's broken is far > from the greatest of our worries. We can't > un-send encrypted messages. When we encrypt a > message under cipher X, we depend on X for as > long as that message remains sensitive. Yes, absolutely. For those very serious situations I'd suggest multiple encipherment. For the high-volumne, short message lifetime applications, like banking networks, we'd want a backup in reserve to counteract the systemic effects of a post-release detection of weakness similar to what may be going on the the French banking system. Both of the above scenarios make multiple NIST selections valuable.
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Wed, 20 Oct 1999 12:52:06 -0600 From: jcoffin@taeus.com (Jerry Coffin) Message-ID: <MPG.1277a283679dedad98971e@news.mindspring.com> References: <19991019231649.22027.00000075@ng-cm1.aol.com> Newsgroups: sci.crypt Lines: 48 In article <19991019231649.22027.00000075@ng-cm1.aol.com>, djohn37050@aol.com says... > Jerry, you have a GREAT reason to have more than one AES winner, in a > satellite, the cost of more than one is small, but the cost of another > satellite is huge. > > I am certain there are other examples like this. > > And what is the US government supposed to do if their only pick breaks? Hurry > up and certify another algorithm? Guess and pick a non-certified one? It is > clear to me that for SOME scenarios, it is mandatory to have more than one AES > winner. I'm not sure I'd go _nearly_ this far. On one hand, I agree that having some sort of backup in a satellite is a good idea. OTOH, I don't think it necessarily makes a lot of sense to use communication satellites as the basis upon which decisions about AES are made. They're clearly a VERY limited market, and unless I'm badly mistaken, most satellites normally only communicate with a limited number of ground stations. The main reason more than one algorithm would be needed would be if there was a government agency that owned a satellite used for sensitive but unclassified information so they were mandated to use AES. I'm not aware of any government agencies in this situation: the military owns many satellites, but most of them are equipped to deal with classified information, which will presumably be placed outside the AES arena, much as it has been with DES. For other companies, etc., that own satellites, using two or more algorithms is fine, but there's no requirement that any of the necessarily be AES. In addition, the satellite could include only one algorithm, but implement it in an FPGA rather than hard-wired logic. In this case, when/if necessary, the satellite could be re-programmed remotely to implement a different algorithm. I don't know much about system architecture of satellites, it offhand it seems like it would be a bare minimum of good sense to make them as re-programmable as possible from the ground. To summarize: I don't think simply invoking "hardware designs" is a sufficient reason to say that AES must have only one algorithm. OTOH, I don't think invoking "satellites" is a sufficient reason to say that it must have more than one either. -- Later, Jerry. The universe is a figment of its own imagination.
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Wed, 20 Oct 1999 23:04:50 -0700 From: "Roger Schlafly" <real@ieee.org> Message-ID: <7umabi$144v@enews1.newsguy.com> References: <380e7293.821932@news.visi.com> <19991019231649.22027.00000075@ng-cm1.aol.com> Newsgroups: sci.crypt Lines: 16 Bruce Schneier <schneier@counterpane.com> wrote in message news:380e7293.821932@news.visi.com... > I give up. It's frustrating to argue real-world constraints with > people who don't deal with real-world constraints. People in this > thread have argued that 8-bit processors aren't important, that people > who use cryptography don't care about performance, that protocols to > negotiate arbitrary ciphers are more secure than single-cipher > protocols, that randomly choosing among a set of ciphers is more > secure than a single cipher, and a variety of other things. It's just > not worth my time anymore. I think they oppose standards for ideological or business reasons. Most of these arguments could be used against any standard.
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Thu, 21 Oct 1999 00:07:26 -0600 From: jcoffin@taeus.com (Jerry Coffin) Message-ID: <MPG.12785b5dcad647ba989731@news.mindspring.com> References: <380e7293.821932@news.visi.com> <19991019231649.22027.00000075@ng-cm1.aol.com> Newsgroups: sci.crypt Lines: 35 In article <380e7293.821932@news.visi.com>, schneier@counterpane.com says... > On 20 Oct 1999 03:16:49 GMT, djohn37050@aol.com (DJohn37050) wrote: > > >Jerry, you have a GREAT reason to have more than one AES winner, in a > >satellite, the cost of more than one is small, but the cost of another > >satellite is huge. > > > >I am certain there are other examples like this. > > It's a moronic example. Do you really think that satellites are > thrown away if there are software bugs? Even NASA probes have > uploadable software. In this case what prevents the opponent from uploading a bit of new programming that just sends him the key being used? The obvious thing would be a MAC on the programming message. Now, of course the opponent has two possible avenues of attack: breaking either the core cipher OR the MAC allows the enemy access to the satellite. This sounds suspiciously similar to the scenarios you describe as an undesirable result of having more than one winner in the AES competition. Maybe my example really was moronic, but if so I don't think uploadable programming of the cipher is what puts it into that category. I'm not sure I'd go so far as to call your response moronic, but at least as it was presented, it doesn't sound to me like a good way to enhance security. -- Later, Jerry. The universe is a figment of its own imagination.
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Thu, 21 Oct 1999 10:41:52 +0200 From: Mok-Kong Shen <mok-kong.shen@t-online.de> Message-ID: <380ED1D0.9B71B61F@t-online.de> References: <380e7293.821932@news.visi.com> <19991019231649.22027.00000075@ng-cm1.aol.com> Newsgroups: sci.crypt Lines: 32 Bruce Schneier wrote: > > I give up. It's frustrating to argue real-world constraints with > people who don't deal with real-world constraints. People in this > thread have argued that 8-bit processors aren't important, that people > who use cryptography don't care about performance, that protocols to > negotiate arbitrary ciphers are more secure than single-cipher > protocols, that randomly choosing among a set of ciphers is more > secure than a single cipher, and a variety of other things. It's just > not worth my time anymore. > > Good luck with your agenda. In one point Mr. Schneier has clearly and definitely erred, namely concerning his phrase about randomly choosing a cipher. Randomly choosing among a set of ciphers can NEVER be weaker than the weakest of the set. If ciphers in a set are of equal strength ( or not known to be of differing strength) then randomly choosing is evidently a superior stategy. If one cipher is stronger than the others, the usefulness of random choosing will depend on the strength differences and the cardinality of the set and can't be evaluated simply. On the assumption that there are 3 ciphers of the final round of AES that are equally or extremely nearly equally strong, it is almost sure that random choosing is a much better strategy. M. K. Shen ------------------------ http://home.t-online.de/home/mok-kong.shen M. K. Shen
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Thu, 21 Oct 1999 13:11:31 +0100 From: "Brian Gladman" <gladman@seven77.demon.co.uk> Message-ID: <940507920.9242.0.nnrp-14.c2de6a96@news.demon.co.uk> References: <380ED1D0.9B71B61F@t-online.de> Newsgroups: sci.crypt Lines: 62 Mok-Kong Shen <mok-kong.shen@t-online.de> wrote in message news:380ED1D0.9B71B61F@t-online.de... > Bruce Schneier wrote: > In one point Mr. Schneier has clearly and definitely erred, namely > concerning his phrase about randomly choosing a cipher. Randomly > choosing among a set of ciphers can NEVER be weaker than the > weakest of the set. If ciphers in a set are of equal strength ( > or not known to be of differing strength) then randomly choosing is > evidently a superior stategy. If one cipher is stronger than the > others, the usefulness of random choosing will depend on the > strength differences and the cardinality of the set and can't be > evaluated simply. On the assumption that there are 3 ciphers > of the final round of AES that are equally or extremely nearly > equally strong, it is almost sure that random choosing is a much > better strategy. I do think, however, that there have to be fair ground rules for such a comparison and I think this is what Bruce is saying. If there are, say, two ciphers to choose from then 1-bit is necessary to make this choice so it is reasonable to ask which would be stronger when this scheme using n-bit ciphers is compared with the use of a single cipher with an (n+1)-bit key. If we postulate that all ciphers achieve a strength implied by their keyspace, we will not have achieved anything other than increasing the complexity of our system. So we have to assume unequal strength ciphers in order to see possible advantages. But when the two cipher scheme is employed with algorithms of known strength it makes no sense to choose the weaker of the two so we also have to also assume that we do not know which of the algorithms is stronger. In the two algorithm scheme we will hence find that 50% of our messages will be more strongly protected and 50% less so. In contrast when we use a single algorithm, since we don't know which is stronger, we have to 'toss a coin' and we hence find that there is a 50% chance that we end up with either more or less protection for all our messages. Which outcome is better is pretty unclear. But we have an extra key bit to use so provided the weaker algortihm exceeds a strength implied by one half of its keyspace we will win on average by choosing a single algorithm rather than by choosing between two. Whether we can expect a weak algorithm to have given up more or less than half its keyspace I have no idea (we might look at some past failed algorithms to assess what the probabilities are here). In overall terms I agree with Bruce here - I am doubtful that any schemes of this type will achieve much other than increasing the complexity of our system and hence reducing the prospects of a correct system implementation. Deployed diversity (as distinct from diversity of choice during design) will increase the complexity of our system and this means that we really should see a big win if we are going to use it. There are good arguments for algorithm diversity but I personally doubt that they lie in this direction. Brian Gladman
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Fri, 22 Oct 1999 09:01:35 -0400 From: "Trevor Jackson, III" <fullmoon@aspi.net> Message-ID: <3810602F.DDB77E65@aspi.net> References: <7uotnb$n28$1@blowfish.isaac.cs.berkeley.edu> <940541039.4744.0.nnrp-03.c2de6a96@news.demon.co.uk> Newsgroups: sci.crypt Lines: 93 David Wagner wrote: > I have some rather large quibbles with your model. > > But let me first state up front that I believe very much in your general > methodology. If we can form a reasonable model and make some quantitive > risk estimates on the basis of that model, that would be a powerful > argument for whether to select multiple winners or not. How can you form quantitative risk estimates? Could you provide an example of such a calculation? I'm reminded of NASA's quantitative risk estimate that the odds of a shuttle disaster were 1:100,000. Do you intend your estimates to be (contrary to NASA's) defensible? Testable? Scientifically verifiable? What standard of rigor would you accept as useful? > Now, back to my quibbles. I have a big bone to pick with your model; I > believe it is unrepresentative in a number of important ways. I'll list > just two: > 1. It counts the total amount of work required to break _all_ messages. > This is asking too much of the adversary; it is already disastrous > if the adversary can read only 10% of our traffic. IMHO a better > metric would be the expected number of messages that can be read by > an adversary with a given amount of resources. > 2. In practice, we can do better than random selection of our ciphers. > While we may not have perfect knowledge on which algorithms are most > secure, we can form some rough estimate or some approximate relative > ranking. How? The error range on our estimates is so large that for all intents and purposes all ciphers with similar key size and no known weaknesses are approximately equal. On what basis should we select? strength: see above. performance: depends strongly on application context. After we've weeded out the weaker ciphers there's no dominating property that provides the equivalent of a pareto-optimal choice. Since there are multiple dimensions to the feature/benefit space it probably isn't possible to objectively order the remaining candidates. If, for instance, we had three or four criteria and five candidates none of which dominate or almost dominate in all criteria the selection of a cipher for a specific application is sensitive to the weights the particular application environment places on each criteria. Selecting a single winner in the general case means selecting without regard to the criteria weights or by averaging the specific environment weights in some way. The averaging process, or the decision to ignore criteria weights completely, means that the selection of a general "winner" by that method is a NOP. It means nothing to the designer/implementor faced with a particular application. In almost every case the designer/implementor is better off applying the criteria weights particular to his problem in order to choose from a set whose elements are diverse. OTOH, consideration of the actual criteria and their importance (ranking) may produce a trivial solution. One cipher _might_ stand out so much that it's choice is obvious. Extrema do occur. However, this is the case in which a unique selection by NIST is gilding the lily. They only have to point out the superiority of the obvious winner, Selecting secondary (place & show) ciphers would not dilute the preference for the "winner". > Although we can't be sure which AES finalist is strongest, > surely our best experts can do better than mere coin-flipping at > picking the best algorithm! If not, there's little point in taking > the AES process any further. This is exactly the point of multiple selections. There's no reason to take the AES process further than the point at which we say "no known weakness". > If you take these factors into consideration, I claim that the conclusion > regarding multiple ciphers changes drastically. > > I'd like to take this opportunity to plug my own model. I put together > a more sophisticated and (I like to believe) more credible model of the > risks in an earlier sci.crypt post, about a month or two ago. On the > basis of this model, I argued that using multiple ciphers would actually > decrease overall security. These posts inspired some lengthy discussions > from others on the merits of the proposed model. > > Since we seem to see eye-to-eye at least on the methodology, if not on > the model, I'd like to invite you to take a look at those earlier postings. > If I can convince you to take a look, I'd appreciate any feedback you (or > anyone else) might have. Let me know if you'd like me to forward you a > copy of my earlier posts. I would be interested in what you consider the definitive statement of your model.
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Fri, 22 Oct 1999 20:04:33 +0200 From: Mok-Kong Shen <mok-kong.shen@t-online.de> Message-ID: <3810A731.D4206CFA@t-online.de> References: <3810602F.DDB77E65@aspi.net> Newsgroups: sci.crypt Lines: 41 Trevor Jackson, III wrote: > > On what basis should we select? strength: see above. performance: depends > strongly on application context. > > After we've weeded out the weaker ciphers there's no dominating property that > provides the equivalent of a pareto-optimal choice. Since there are multiple > dimensions to the feature/benefit space it probably isn't possible to > objectively order the remaining candidates. > > If, for instance, we had three or four criteria and five candidates none of > which dominate or almost dominate in all criteria the selection of a cipher for > a specific application is sensitive to the weights the particular application > environment places on each criteria. Selecting a single winner in the general > case means selecting without regard to the criteria weights or by averaging the > specific environment weights in some way. > > The averaging process, or the decision to ignore criteria weights completely, > means that the selection of a general "winner" by that method is a NOP. It > means nothing to the designer/implementor faced with a particular application. > In almost every case the designer/implementor is better off applying the > criteria weights particular to his problem in order to choose from a set whose > elements are diverse. > > OTOH, consideration of the actual criteria and their importance (ranking) may > produce a trivial solution. One cipher _might_ stand out so much that it's > choice is obvious. Extrema do occur. However, this is the case in which a > unique selection by NIST is gilding the lily. They only have to point out the > superiority of the obvious winner, Selecting secondary (place & show) ciphers > would not dilute the preference for the "winner". Very well said. Because of the inherent difficulty of quantifying crypto strength, I believe it will be much more difficult to rank the top three AES candidates than to rank three cars of the same price category. It will be more like ranking the top three girls in the miss world contest. All girls are pretty but everybody will have his subjective ranking not necessarily identical to that pronounced by the jury. M. K. Shen
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Sat, 23 Oct 1999 18:41:57 GMT From: ritter@io.com (Terry Ritter) Message-ID: <381200e4.8497981@news.io.com> References: <940507920.9242.0.nnrp-14.c2de6a96@news.demon.co.uk> Newsgroups: sci.crypt Lines: 134 On Thu, 21 Oct 1999 13:11:31 +0100, in <940507920.9242.0.nnrp-14.c2de6a96@news.demon.co.uk>, in sci.crypt "Brian Gladman" <gladman@seven77.demon.co.uk> wrote: >Mok-Kong Shen <mok-kong.shen@t-online.de> wrote in message >news:380ED1D0.9B71B61F@t-online.de... >> Bruce Schneier wrote: > >> In one point Mr. Schneier has clearly and definitely erred, namely >> concerning his phrase about randomly choosing a cipher. Randomly >> choosing among a set of ciphers can NEVER be weaker than the >> weakest of the set. If ciphers in a set are of equal strength ( >> or not known to be of differing strength) then randomly choosing is >> evidently a superior stategy. If one cipher is stronger than the >> others, the usefulness of random choosing will depend on the >> strength differences and the cardinality of the set and can't be >> evaluated simply. On the assumption that there are 3 ciphers >> of the final round of AES that are equally or extremely nearly >> equally strong, it is almost sure that random choosing is a much >> better strategy. > >I do think, however, that there have to be fair ground rules for such a >comparison and I think this is what Bruce is saying. I think it fascinating how many people seem to feel that Schneier's words need their personal interpretation, and that they are qualified to do that. Something is wrong here: Schneier is a professional author. Presumably he understands his words. If something he presents requires interpretation by someone else, not only has he not presented it right, it actually (gasp!) may be wrong. If he says something outrageous, let it stand. Criticize exactly what he says. We will never know what he means if his words are free to be re-interpreted at will by all and sundry. I find it likely that each new interpretation is due more to the interpreter than the original content. Let messages stand or fall on their content, the exact words, exactly as they appear. People can clarify their own errors or misinterpretations. Then we get the real scoop instead of a masticated mess. >If there are, say, two ciphers to choose from then 1-bit is necessary to >make this choice so it is reasonable to ask which would be stronger when >this scheme using n-bit ciphers is compared with the use of a single cipher >with an (n+1)-bit key. Well, yes, it would be "reasonable" to ask which would be stronger, *IF* we could measure strength. But in the *real* world (that would be the thing Schneier talks about), we *cannot* measure strength. We do not use weak ciphers, so any cipher we do use has unknown strength. So, obviously, it is NOT "reasonable" to ask which cipher would be stronger -- if one also expects a reply. >If we postulate that all ciphers achieve a strength implied by their >keyspace, That is a ridiculous postulation in any case. >we will not have achieved anything other than increasing the >complexity of our system. So we have to assume unequal strength ciphers in >order to see possible advantages. But when the two cipher scheme is >employed with algorithms of known strength it makes no sense to choose the >weaker of the two so we also have to also assume that we do not know which >of the algorithms is stronger. But we do not use weak ciphers, and that means virtually any cipher which has even theoretical breaks. So we can never expect to know the strengths of the ciphers we use. We may find out about one cipher some day, and then we will change ciphers and *still* not know how strong the cipher we use actually may be. >In the two algorithm scheme we will hence find that 50% of our messages will >be more strongly protected and 50% less so. In contrast when we use a single >algorithm, since we don't know which is stronger, we have to 'toss a coin' >and we hence find that there is a 50% chance that we end up with either more >or less protection for all our messages. Which outcome is better is pretty >unclear. By doing that we have put all our eggs in one basket. We thus depend upon the strength of that basket -- a strength we can neither prove nor measure. We are depending upon the strength of a particular cipher, and that is something which cannot be depended upon. The primary advantage of choosing among multiple ciphers is NOT to provide keyspace, but instead to allow changing to a new cipher. This is an advantage because changing to a new cipher obviously terminates any break which had been applied to the old cipher. You can claim all the analysis you want, but you cannot claim a known strength. And without that, you *cannot* depend upon that cipher. One of the fundamental problems we have in the real world with ciphers is that we cannot tell when they have been broken and are exposing our data. We cannot tell. Now what do we do about it? >But we have an extra key bit to use so provided the weaker algortihm exceeds >a strength implied by one half of its keyspace we will win on average by >choosing a single algorithm rather than by choosing between two. Whether >we can expect a weak algorithm to have given up more or less than half its >keyspace I have no idea (we might look at some past failed algorithms to >assess what the probabilities are here). The issue in breaking ciphers is only rarely keyspace. >In overall terms I agree with Bruce here - I am doubtful that any schemes of >this type will achieve much other than increasing the complexity of our >system and hence reducing the prospects of a correct system implementation. Nonsense. We choose a cipher. We use it. We choose another cipher. We use that. Yup, pretty tough. >Deployed diversity (as distinct from diversity of choice during design) will >increase the complexity of our system and this means that we really should >see a big win if we are going to use it. > >There are good arguments for algorithm diversity but I personally doubt that >they lie in this direction. Then you need to re-think your position. --- Terry Ritter ritter@io.com http://www.io.com/~ritter/ Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: 23 Oct 99 21:54:43 GMT From: jsavard@ecn.ab.ca () Message-ID: <38122ea3.0@ecn.ab.ca> References: <381200e4.8497981@news.io.com> Newsgroups: sci.crypt Lines: 18 Terry Ritter (ritter@io.com) wrote: : If he says something outrageous, let it stand. Criticize exactly what : he says. At the risk of being seen to be blowing my own horn, I did just that recently in response to an article in a recent issue of Crypto-Gram. And soon enough, he clarified himself, so now it is clear that he means that user-memorized secrets can't provide security in the case of systems designed for use by unmotivated employees or consumers, not that it is absolutely impossible for them to be the basis of secure cryptographic keys. Since Mr. Schneier has such a good reputation, however, there is a tendency to assume he won't intentionally say something that doesn't make sense. Those of us not basking in public adulation must watch our words more carefully. John Savard
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Sun, 24 Oct 1999 00:49:12 +0200 From: Mok-Kong Shen <mok-kong.shen@t-online.de> Message-ID: <38123B68.CF22A21F@t-online.de> References: <7ut49g$2t3v@enews3.newsguy.com> <381200e4.8497981@news.io.com> Newsgroups: sci.crypt Lines: 34 Roger Schlafly wrote: > > Terry Ritter <ritter@io.com> wrote in message > news:381200e4.8497981@news.io.com... > > Well, yes, it would be "reasonable" to ask which would be stronger, > > *IF* we could measure strength. But in the *real* world (that would > > be the thing Schneier talks about), we *cannot* measure strength. We > > do not use weak ciphers, so any cipher we do use has unknown strength. > > Your extremism on this issue is rather amusing, but it is also absurd. > It is like saying that you cannot measure building strength -- all you > can do is wait for an earthquake and see if the building falls down. > We have building codes and structural engineers to assure building > strength. Sure, when the earthquake comes, there might be some > surprises. But if you want a strong house, then there are steps you > can take that will almost certainly give you a stronger house. Engineers test building materials in laboratories. With that knowledge and the theory of mechanics (including elasticity and plasticity) and the estimated loading they design their structures employing a factor of safety that is contained in the standards of building construction. For complicated structures, where a satisfactory computation is difficult, one also builds a model to be tested. There are formulae that allow the results of the model to be transferred to the prototype. Do you think that you can draw parallels with the design and investigation of strength of crypto algorithms? Consider just the simplest point: You can apply a load to a beam until it crashes and anyone can do the same and obtain the same result. How do you apply 'something' in the first place to a component of a cipher until it is broken? And how do you know whether a cleverer person may not need less than that 'something' to cause it to be broken? M. K. Shen
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Mon, 25 Oct 1999 07:58:48 +0200 From: jgfunj@vgrknf.arg (jgfunj@vgrknf.arg) Message-ID: <fc.3b9aca0064361c543b9aca004dfd3b8d.10aaf@peg.dyndns.org> References: <jgfunj-2410992358480001@dial-243-047.itexas.net> <381200e4.8497981@news.io.com> Newsgroups: sci.crypt Lines: 29 In article <381200e4.8497981@news.io.com>, ritter@io.com (Terry Ritter) wrote: >> On Thu, 21 Oct 1999 13:11:31 +0100, in >> <940507920.9242.0.nnrp-14.c2de6a96@news.demon.co.uk>, in sci.crypt >> "Brian Gladman" <gladman@seven77.demon.co.uk> wrote: >> >> >If we postulate that all ciphers achieve a strength implied by their >> >keyspace, >> >> That is a ridiculous postulation in any case. Keyspace depends on what you do with it. >> .... >> The primary advantage of choosing among multiple ciphers is NOT to >> provide keyspace, but instead to allow changing to a new cipher. This >> is an advantage because changing to a new cipher obviously terminates >> any break which had been applied to the old cipher. You can claim all >> the analysis you want, but you cannot claim a known strength. And >> without that, you *cannot* depend upon that cipher. >>..... >> The issue in breaking ciphers is only rarely keyspace. Ah..so much depends on the meaning of strength. -- Sometime ago, Gates bought lots of shares of Apple. My preference is to keep the Worm out of the Apple. {}{}{} Posted via Uncensored-News.Com, http://www.uncensored-news.com {}{}{} {}{}{}{} Only $8.95 A Month, - The Worlds Uncensored News Source {}{}{}{} {}{}{}{}{} Five News Servers with a BINARIES ONLY Server {}{}{}{}{}
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Sun, 24 Oct 1999 03:39:23 GMT From: dianelos@tecapro.com Message-ID: <7utv1b$ldc$1@nnrp1.deja.com> References: <940507920.9242.0.nnrp-14.c2de6a96@news.demon.co.uk> Newsgroups: sci.crypt Lines: 71 In article <940507920.9242.0.nnrp-14.c2de6a96@news.demon.co.uk>, "Brian Gladman" <gladman@seven77.demon.co.uk> wrote: >... >If there are, say, two ciphers to choose from then 1-bit is necessary >to make this choice so it is reasonable to ask which would be stronger >when this scheme using n-bit ciphers is compared with the use of a >single cipher with an (n+1)-bit key. Interestingly enough, I discussed precisely this question in an older post: Take two ciphers A and B with keys of N bits. These ciphers must be independent in the sense that physically breaking one does not help in breaking the other. (By "physical break" I mean the work necessary to recover the key when the cipher is already cryptanalyzed; "logical break" would be the work necessary to successfully cryptanalyze a cipher" - in what follows we discuss physical break only). Let us suppose that these ciphers are not perfect; and therefore there exists a method (known or unknown) to break them, which is more efficient than brute force, i.e. the trying of all possible keys. For ciphers A and B there exists then a method to break them at a cost comparable to 2^ (N*k) operations where k<1 (2^N corresponds to brute forcing them). If you increase the key length by 1 bit, then you would need 2^((N+1)*k) =2^N * 2^k operations to break A or B (here I assume A and B are equally strong, a similar analysis can be done for the case k_A<>k_B ). If you create a new cipher C with a key of N+1 bits where the last bit is used to choose either A or B as the working cipher with a key of N bits, then you must apply the A-attack, and with 50% probability the B- attack also. The reason is that you don't know whether A or B has been used; so you try the attack against A to see if it succeds. With 50% probability it won't succeed and you will have to implement the attack against B also. Here I assume that the best way to identify which cipher is being used is that by breaking the cipher – with modern ciphers I think this is a valid assumption. So the cost for breaking C is 2^(N*k)+0.5*2^(N*k)=3/2 * 2^(N*k). Therefore you need more effort to break C with a key of N+1 bits, than either A or B with a key of N+1 bits, as long as k is less then ln (3/2)/ln(2) = 0.58. If instead of two ciphers, you started with 2^M different ciphers, then the results are more dramatic. The average effort required for breaking the resulting cipher is now 2^(N*K-1)* (2^M+1) and it will be stronger as long as k < 1/M*(ln(2^M+1)/ln(2) -1) or for large M: k < 1 - 1/M. So, unless you are prety certain that your cipher is perfect (k=1) then you are better off choosing one cipher from as large a pool (M>>1) as possible. In a way, we get a security amplifier with not cost in speed. Let us assume, for example, that four AES finalists survive with a flawless security record. Instead of using any one of them with a 128 bit key we could use the "fourAES" cipher with a 130 bit key. This cipher will be stronger as long as k<0.66, i.e. as long as we assume there exists an (unknown) attack that can break the AES finalists with less than 2^(0.66*128)=2^84 cost. Is this a good assumption? Today, an attack of 2^84 cost against a 128 bit AES candidate would certainly kill it. What are the chances that in the next 50 years cryptanalysis will improve to the level that such powerful attacks are discovered against an AES finalist class cipher? The answer to that question is anybody's guess, but it would be best to be on the safe side. Observe that in my discussion above, the choosing of the cipher depends on they key. It is not done randomly which would requiere us to add information to the ciphertext about which cipher has been used. The latter is probably a bad idea if we assume that the attacker has sufficient resources to cryptanalyze all alternate ciphers - in that case the attacker would first attack the ciphertexts produced by the weakest cipher. Sent via Deja.com http://www.deja.com/ Before you buy.
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Sun, 24 Oct 1999 07:13:22 GMT From: ritter@io.com (Terry Ritter) Message-ID: <3812b166.3480429@news.io.com> References: <7utv1b$ldc$1@nnrp1.deja.com> Newsgroups: sci.crypt Lines: 49 On Sun, 24 Oct 1999 03:39:23 GMT, in <7utv1b$ldc$1@nnrp1.deja.com>, in sci.crypt dianelos@tecapro.com wrote: >[...] >Observe that in my discussion above, the choosing of the cipher depends >on they key. It is not done randomly which would requiere us to add >information to the ciphertext about which cipher has been used. Something seems wrong with this observation: Keys we use for actual data encryption generally are *message keys*, and in fact *should* be random values. Using a random message key value to select a cipher sounds rather similar to using a random value to select a cipher. Nor would additional information generally be needed, unless the message key value was so tightly drawn as to have already been used completely. In general, it is not a good idea to scrimp on the message key size. While we might hope that a message key value would be 100 percent unpredictable, it is wiser to plan for full cipher strength with less unpredictability, by using a larger message key. >The >latter is probably a bad idea if we assume that the attacker has >sufficient resources to cryptanalyze all alternate ciphers - in that >case the attacker would first attack the ciphertexts produced by the >weakest cipher. We certainly would hope that any attacker could not distinguish between ciphertexts produced by one cipher and another. One might even think that an ability to identify a particular cipher from its ciphertext alone would be a straightforward indication of cipher weakness. Obviously an attacker could try all ciphertexts under the weakest cipher first, but if the attack requires messages from only a particular cipher, how would the attacker know which messages to use? When the cipher itself is changed dynamically on a message-by-message basis, there should be no way to distinguish the subset of ciphertexts produced by a particular cipher. It would thus seem to be hard for an attacker to even collect the required amount of single-cipher ciphertext, let alone start any actual attack. --- Terry Ritter ritter@io.com http://www.io.com/~ritter/ Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Mon, 25 Oct 1999 04:35:01 +0200 From: dianelos@tecapro.com (dianelos@tecapro.com) Message-ID: <fc.3b9aca0027318a663b9aca004dfd3b8d.10a9a@peg.dyndns.org> References: <7v0fkl$8tu$1@nnrp1.deja.com> <3812b166.3480429@news.io.com> Newsgroups: sci.crypt Lines: 123 In article <3812b166.3480429@news.io.com>, ritter@io.com (Terry Ritter) wrote: >> On Sun, 24 Oct 1999 03:39:23 GMT, in <7utv1b$ldc$1@nnrp1.deja.com>, in >> sci.crypt dianelos@tecapro.com wrote: >> >>>[...] >>>Observe that in my discussion above, the choosing of the cipher >>>depends on they key. It is not done randomly which would requiere us >>>to add information to the ciphertext about which cipher has been >>>used. >> >> Something seems wrong with this observation: Keys we use for actual >> data encryption generally are *message keys*, and in fact *should* be >> random values. Using a random message key value to select a cipher >> sounds rather similar to using a random value to select a cipher. Well, I meant this: If you choose ciphers from the pool in a way that depends on the key then, by definition, the attacker will not know a priori which cipher is being used for each block. If you choose the ciphers by any other method then, by definition, the attacker will always know which cipher is being used: the attacker can know everything except the key. Now if the attacker *does* know which cipher has been used for each ciphertext block, then he can attack the ciphertext encrypted by the weakest cipher. Consider this: even though we in the public don't know the lower bound of security of the individual ciphers we must assume that a powerful attacker does know. We also can assume that these lower bounds vary a lot - it would be strange indeed if different ciphers were very similar in their lower bound of security. So in a pool of four ciphers it is quite probable that one (the "lemon") is orders of magnitude weaker than the others and that the attacker knows this. Let us assume the lemon falls to a known plaintext attack that requires a small number of known plaintexts. It is true that the attacker will now have to collect four times more data for the lemon, but this quantity will be a trifle compared to the plaintext that must be known for attacking any of the other three ciphers. Therefore the attacker will easily break 25% of the communications recovering almost all intelligence. Instead of using this method, we would be better off choosing one cipher by chance sticking to it. The situation is very different is the choice of ciphers is unknown to the attacker, and for that it is necessary that the choice of the ciphers depend on the key. (There is curious exception: to encrypt the next block choose the cipher completely at random and send only the resulting ciphertext. To decrypt, try in sequence the various ciphers until you get intelligible plaintext.) >> We certainly would hope that any attacker could not distinguish >> between ciphertexts produced by one cipher and another. One might >> even think that an ability to identify a particular cipher from its >> ciphertext alone would be a straightforward indication of cipher >> weakness. I agree. >> Obviously an attacker could try all ciphertexts under the weakest >> cipher first, but if the attack requires messages from only a >> particular cipher, how would the attacker know which messages to use? >> >> When the cipher itself is changed dynamically on a message-by-message >> basis, there should be no way to distinguish the subset of ciphertexts >> produced by a particular cipher. It would thus seem to be hard for an >> attacker to even collect the required amount of single-cipher >> ciphertext, let alone start any actual attack. When the cipher choice is changed dynamically in a way that the attacker cannot predict, then we do get some very interesting properties even if the pool contains only two or three ciphers: It seems a ciphertext only attack on the weak cipher will not work, because the attacker will not know which ciphertext blocks belong to it. Known or chosen plaintext attacks will apparently not work either and for the same reason: even if the attacker chooses the entire plaintext stream, he cannot collect and analyze the ciphertext blocks that have been encrypted with the lemon. It does appear that mixing ciphers can be very useful, but only if the attacker cannot predict their sequence. How does one achieve this? Using a few bits of the key to index one in a pool of N ciphers is not the best way, because then all blocks will be encrypted with the same cipher. The attacker applies the lemon- attack and with 1/N probability it will work. Using the key to start a PRN sequence is not the best solution either: If the key is reused then the first block will always be encrypted with the same cipher. I think the best solution is to use an IV as well as the key to start a PRN sequence. One possibility: Pool N ciphers. Define random IV and add it to the ciphertext. T(0) = IV H(0) = Key To encrypt the i-the block T(i): H(i) = Hash( H(i-1) xor T(i-1) ) index(i) = H(i) mod N C(i) = encrypt( index(i) ) ( T(i), Key ) Here is another possibility. Let us assume we trust four of the AES finalists (which use 128 bit blocks). index = least significant 2 bits of key H = IV Step A: H = encrypt( index ) ( H, Key) Step B: Use 63 groups of 2 bits of H to index a cipher and encrypt the first 63 blocks of plaintext. Step C: index = last 2 bits of H Step D: go to Step A The ciphertext increases in one block and speed decreases about 2% One more thought. Mixing ciphers in a secret sequence seems to be useful even if only two ciphers are used. What about using only one cipher while changing the direction of the encryption, i.e. use it sometimes to encrypt and sometimes to decrypt depending on the secret sequence? Sent via Deja.com http://www.deja.com/ Before you buy. {}{}{} Posted via Uncensored-News.Com, http://www.uncensored-news.com {}{}{} {}{}{}{} Only $8.95 A Month, - The Worlds Uncensored News Source {}{}{}{} {}{}{}{}{} Five News Servers with a BINARIES ONLY Server {}{}{}{}{}
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Mon, 25 Oct 1999 10:06:22 +0200 From: Mok-Kong Shen <mok-kong.shen@t-online.de> Message-ID: <38140F7E.48AEB54B@t-online.de> References: <7v0fkl$8tu$1@nnrp1.deja.com> <3812b166.3480429@news.io.com> Newsgroups: sci.crypt Lines: 26 dianelos@tecapro.com wrote: > > Now if the attacker *does* know which cipher has been used for each > ciphertext block, then he can attack the ciphertext encrypted by the > weakest cipher. Consider this: even though we in the public don't know > the lower bound of security of the individual ciphers we must assume > that a powerful attacker does know. We also can assume that these lower > bounds vary a lot - it would be strange indeed if different ciphers > were very similar in their lower bound of security. So in a pool of > four ciphers it is quite probable that one (the "lemon") is orders of > magnitude weaker than the others and that the attacker knows this. Let > us assume the lemon falls to a known plaintext attack that requires a > small number of known plaintexts. It is true that the attacker will now > have to collect four times more data for the lemon, but this quantity > will be a trifle compared to the plaintext that must be known for > attacking any of the other three ciphers. Therefore the attacker will > easily break 25% of the communications recovering almost all > intelligence. Instead of using this method, we would be better off > choosing one cipher by chance sticking to it. A tiny remark: Using variable keys as proposed by me in another thread, such attacks presumably have to be considered in a different perspective. M. K. Shen
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Mon, 25 Oct 1999 10:06:22 +0200 From: mok-kong.shen@t-online.de (mok-kong.shen@t-online.de) Message-ID: <fc.3b9aca001bd038733b9aca004dfd3b8d.10abf@peg.dyndns.org> References: <38140F7E.48AEB54B@t-online.de> Newsgroups: sci.crypt Lines: 27 dianelos@tecapro.com wrote: >> >> Now if the attacker *does* know which cipher has been used for each >> ciphertext block, then he can attack the ciphertext encrypted by the >> weakest cipher. Consider this: even though we in the public don't know >> the lower bound of security of the individual ciphers we must assume >> that a powerful attacker does know. We also can assume that these lower >> bounds vary a lot - it would be strange indeed if different ciphers >> were very similar in their lower bound of security. So in a pool of >> four ciphers it is quite probable that one (the "lemon") is orders of >> magnitude weaker than the others and that the attacker knows this. Let >> us assume the lemon falls to a known plaintext attack that requires a >> small number of known plaintexts. It is true that the attacker will now >> have to collect four times more data for the lemon, but this quantity >> will be a trifle compared to the plaintext that must be known for >> attacking any of the other three ciphers. Therefore the attacker will >> easily break 25% of the communications recovering almost all >> intelligence. Instead of using this method, we would be better off >> choosing one cipher by chance sticking to it. A tiny remark: Using variable keys as proposed by me in another thread, such attacks presumably have to be considered in a different perspective. M. K. Shen {}{}{} Posted via Uncensored-News.Com, http://www.uncensored-news.com {}{}{} {}{}{}{} Only $8.95 A Month, - The Worlds Uncensored News Source {}{}{}{} {}{}{}{}{} Five News Servers with a BINARIES ONLY Server {}{}{}{}{}
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Mon, 25 Oct 1999 12:25:38 -0400 From: "Trevor Jackson, III" <fullmoon@aspi.net> Message-ID: <38148482.9BFC5B7C@aspi.net> References: <7v0fkl$8tu$1@nnrp1.deja.com> <3812b166.3480429@news.io.com> Newsgroups: sci.crypt Lines: 136 dianelos@tecapro.com wrote: > In article <3812b166.3480429@news.io.com>, > ritter@io.com (Terry Ritter) wrote: > > > On Sun, 24 Oct 1999 03:39:23 GMT, in <7utv1b$ldc$1@nnrp1.deja.com>, in > > sci.crypt dianelos@tecapro.com wrote: > > > >>[...] > >>Observe that in my discussion above, the choosing of the cipher > >>depends on they key. It is not done randomly which would requiere us > >>to add information to the ciphertext about which cipher has been > >>used. > > > > Something seems wrong with this observation: Keys we use for actual > > data encryption generally are *message keys*, and in fact *should* be > > random values. Using a random message key value to select a cipher > > sounds rather similar to using a random value to select a cipher. > > Well, I meant this: If you choose ciphers from the pool in a way that > depends on the key then, by definition, the attacker will not know a > priori which cipher is being used for each block. If you choose the > ciphers by any other method then, by definition, the attacker will > always know which cipher is being used: the attacker can know > everything except the key. > > Now if the attacker *does* know which cipher has been used for each > ciphertext block, then he can attack the ciphertext encrypted by the > weakest cipher. Consider this: even though we in the public don't know > the lower bound of security of the individual ciphers we must assume > that a powerful attacker does know. We also can assume that these lower > bounds vary a lot - it would be strange indeed if different ciphers > were very similar in their lower bound of security. So in a pool of > four ciphers it is quite probable that one (the "lemon") is orders of > magnitude weaker than the others and that the attacker knows this. Let > us assume the lemon falls to a known plaintext attack that requires a > small number of known plaintexts. It is true that the attacker will now > have to collect four times more data for the lemon, but this quantity > will be a trifle compared to the plaintext that must be known for > attacking any of the other three ciphers. Therefore the attacker will > easily break 25% of the communications recovering almost all > intelligence. Instead of using this method, we would be better off > choosing one cipher by chance sticking to it. > > The situation is very different is the choice of ciphers is unknown to > the attacker, and for that it is necessary that the choice of the > ciphers depend on the key. (There is curious exception: to encrypt the > next block choose the cipher completely at random and send only the > resulting ciphertext. To decrypt, try in sequence the various ciphers > until you get intelligible plaintext.) It appears to me to be extremely difficult to define "intelligible plaintext". If the plaintext space is so well defined that it is the difference between plaintext and noise is detectable than an inadequate compression has been used. And if I'm sening noise, e.g., a message key, it is impossible by definition. > > > > We certainly would hope that any attacker could not distinguish > > between ciphertexts produced by one cipher and another. One might > > even think that an ability to identify a particular cipher from its > > ciphertext alone would be a straightforward indication of cipher > > weakness. > > I agree. > > > Obviously an attacker could try all ciphertexts under the weakest > > cipher first, but if the attack requires messages from only a > > particular cipher, how would the attacker know which messages to use? > > > > When the cipher itself is changed dynamically on a message-by-message > > basis, there should be no way to distinguish the subset of ciphertexts > > produced by a particular cipher. It would thus seem to be hard for an > > attacker to even collect the required amount of single-cipher > > ciphertext, let alone start any actual attack. > > When the cipher choice is changed dynamically in a way that the > attacker cannot predict, then we do get some very interesting > properties even if the pool contains only two or three ciphers: It > seems a ciphertext only attack on the weak cipher will not work, > because the attacker will not know which ciphertext blocks belong to > it. Known or chosen plaintext attacks will apparently not work either > and for the same reason: even if the attacker chooses the entire > plaintext stream, he cannot collect and analyze the ciphertext blocks > that have been encrypted with the lemon. It does appear that mixing > ciphers can be very useful, but only if the attacker cannot predict > their sequence. > > How does one achieve this? Using a few bits of the key to index one in > a pool of N ciphers is not the best way, because then all blocks will > be encrypted with the same cipher. The attacker applies the lemon- > attack and with 1/N probability it will work. Using the key to start a > PRN sequence is not the best solution either: If the key is reused then > the first block will always be encrypted with the same cipher. I think > the best solution is to use an IV as well as the key to start a PRN > sequence. One possibility: > > Pool N ciphers. > Define random IV and add it to the ciphertext. > T(0) = IV > H(0) = Key > > To encrypt the i-the block T(i): > > H(i) = Hash( H(i-1) xor T(i-1) ) > index(i) = H(i) mod N > C(i) = encrypt( index(i) ) ( T(i), Key ) > > Here is another possibility. Let us assume we trust four of the AES > finalists (which use 128 bit blocks). > > index = least significant 2 bits of key > H = IV > > Step A: H = encrypt( index ) ( H, Key) > Step B: Use 63 groups of 2 bits of H to index a cipher and encrypt the > first 63 blocks of plaintext. > Step C: index = last 2 bits of H > Step D: go to Step A > > The ciphertext increases in one block and speed decreases about 2% > > One more thought. Mixing ciphers in a secret sequence seems to be > useful even if only two ciphers are used. What about using only one > cipher while changing the direction of the encryption, i.e. use it > sometimes to encrypt and sometimes to decrypt depending on the secret > sequence? > > Sent via Deja.com http://www.deja.com/ > Before you buy.
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Mon, 25 Oct 1999 18:25:38 +0200 From: fullmoon@aspi.net (fullmoon@aspi.net) Message-ID: <fc.3b9aca00d0dffd663b9aca004dfd3b8d.10af6@peg.dyndns.org> References: <38148482.9BFC5B7C@aspi.net> Newsgroups: sci.crypt Lines: 137 dianelos@tecapro.com wrote: >> In article <3812b166.3480429@news.io.com>, >> ritter@io.com (Terry Ritter) wrote: >> >> > On Sun, 24 Oct 1999 03:39:23 GMT, in <7utv1b$ldc$1@nnrp1.deja.com>, in >> > sci.crypt dianelos@tecapro.com wrote: >> > >> >>[...] >> >>Observe that in my discussion above, the choosing of the cipher >> >>depends on they key. It is not done randomly which would requiere us >> >>to add information to the ciphertext about which cipher has been >> >>used. >> > >> > Something seems wrong with this observation: Keys we use for actual >> > data encryption generally are *message keys*, and in fact *should* be >> > random values. Using a random message key value to select a cipher >> > sounds rather similar to using a random value to select a cipher. >> >> Well, I meant this: If you choose ciphers from the pool in a way that >> depends on the key then, by definition, the attacker will not know a >> priori which cipher is being used for each block. If you choose the >> ciphers by any other method then, by definition, the attacker will >> always know which cipher is being used: the attacker can know >> everything except the key. >> >> Now if the attacker *does* know which cipher has been used for each >> ciphertext block, then he can attack the ciphertext encrypted by the >> weakest cipher. Consider this: even though we in the public don't know >> the lower bound of security of the individual ciphers we must assume >> that a powerful attacker does know. We also can assume that these lower >> bounds vary a lot - it would be strange indeed if different ciphers >> were very similar in their lower bound of security. So in a pool of >> four ciphers it is quite probable that one (the "lemon") is orders of >> magnitude weaker than the others and that the attacker knows this. Let >> us assume the lemon falls to a known plaintext attack that requires a >> small number of known plaintexts. It is true that the attacker will now >> have to collect four times more data for the lemon, but this quantity >> will be a trifle compared to the plaintext that must be known for >> attacking any of the other three ciphers. Therefore the attacker will >> easily break 25% of the communications recovering almost all >> intelligence. Instead of using this method, we would be better off >> choosing one cipher by chance sticking to it. >> >> The situation is very different is the choice of ciphers is unknown to >> the attacker, and for that it is necessary that the choice of the >> ciphers depend on the key. (There is curious exception: to encrypt the >> next block choose the cipher completely at random and send only the >> resulting ciphertext. To decrypt, try in sequence the various ciphers >> until you get intelligible plaintext.) It appears to me to be extremely difficult to define "intelligible plaintext". If the plaintext space is so well defined that it is the difference between plaintext and noise is detectable than an inadequate compression has been used. And if I'm sening noise, e.g., a message key, it is impossible by definition. >> >> >> > We certainly would hope that any attacker could not distinguish >> > between ciphertexts produced by one cipher and another. One might >> > even think that an ability to identify a particular cipher from its >> > ciphertext alone would be a straightforward indication of cipher >> > weakness. >> >> I agree. >> >> > Obviously an attacker could try all ciphertexts under the weakest >> > cipher first, but if the attack requires messages from only a >> > particular cipher, how would the attacker know which messages to use? >> > >> > When the cipher itself is changed dynamically on a message-by-message >> > basis, there should be no way to distinguish the subset of ciphertexts >> > produced by a particular cipher. It would thus seem to be hard for an >> > attacker to even collect the required amount of single-cipher >> > ciphertext, let alone start any actual attack. >> >> When the cipher choice is changed dynamically in a way that the >> attacker cannot predict, then we do get some very interesting >> properties even if the pool contains only two or three ciphers: It >> seems a ciphertext only attack on the weak cipher will not work, >> because the attacker will not know which ciphertext blocks belong to >> it. Known or chosen plaintext attacks will apparently not work either >> and for the same reason: even if the attacker chooses the entire >> plaintext stream, he cannot collect and analyze the ciphertext blocks >> that have been encrypted with the lemon. It does appear that mixing >> ciphers can be very useful, but only if the attacker cannot predict >> their sequence. >> >> How does one achieve this? Using a few bits of the key to index one in >> a pool of N ciphers is not the best way, because then all blocks will >> be encrypted with the same cipher. The attacker applies the lemon- >> attack and with 1/N probability it will work. Using the key to start a >> PRN sequence is not the best solution either: If the key is reused then >> the first block will always be encrypted with the same cipher. I think >> the best solution is to use an IV as well as the key to start a PRN >> sequence. One possibility: >> >> Pool N ciphers. >> Define random IV and add it to the ciphertext. >> T(0) = IV >> H(0) = Key >> >> To encrypt the i-the block T(i): >> >> H(i) = Hash( H(i-1) xor T(i-1) ) >> index(i) = H(i) mod N >> C(i) = encrypt( index(i) ) ( T(i), Key ) >> >> Here is another possibility. Let us assume we trust four of the AES >> finalists (which use 128 bit blocks). >> >> index = least significant 2 bits of key >> H = IV >> >> Step A: H = encrypt( index ) ( H, Key) >> Step B: Use 63 groups of 2 bits of H to index a cipher and encrypt the >> first 63 blocks of plaintext. >> Step C: index = last 2 bits of H >> Step D: go to Step A >> >> The ciphertext increases in one block and speed decreases about 2% >> >> One more thought. Mixing ciphers in a secret sequence seems to be >> useful even if only two ciphers are used. What about using only one >> cipher while changing the direction of the encryption, i.e. use it >> sometimes to encrypt and sometimes to decrypt depending on the secret >> sequence? >> >> Sent via Deja.com http://www.deja.com/ >> Before you buy. {}{}{} Posted via Uncensored-News.Com, http://www.uncensored-news.com {}{}{} {}{}{}{} Only $8.95 A Month, - The Worlds Uncensored News Source {}{}{}{} {}{}{}{}{} Five News Servers with a BINARIES ONLY Server {}{}{}{}{}
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Tue, 26 Oct 1999 14:08:45 GMT From: dianelos@tecapro.com Message-ID: <7v4cla$1og$1@nnrp1.deja.com> References: <38148482.9BFC5B7C@aspi.net> Newsgroups: sci.crypt Lines: 35 In article <38148482.9BFC5B7C@aspi.net>, "Trevor Jackson, III" <fullmoon@aspi.net> wrote: > dianelos@tecapro.com wrote: >>The situation is very different is the choice of ciphers is unknown to >>the attacker, and for that it is necessary that the choice of the >>ciphers depend on the key. (There is curious exception: to encrypt the >>next block choose the cipher completely at random and send only the >>resulting ciphertext. To decrypt, try in sequence the various ciphers >>until you get intelligible plaintext.) > >It appears to me to be extremely difficult to define "intelligible >plaintext". If the plaintext space is so well defined that it is the >difference between plaintext and noise is detectable than an >inadequate compression has been used. If the plaintext is compressed then you decompress it and see if it is intellible. >And if I'm sening noise, e.g., a message key, it is impossible by >definition. If you are sending a random key then you can add its hash. There are always ways to send intellible plaintext. What is interesting about this method is that it is now impossible for the attacker to know which block has been encrypted by which cipher and this renders any attack that requires more than 30 or so plaintexts impossible too. If you encrypt using four ciphers then decryption speed will be on average 2.5 times slower, but with the speed of modern ciphers this is not a big problem. Sent via Deja.com http://www.deja.com/ Before you buy.
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Thu, 28 Oct 1999 22:10:37 GMT From: dianelos@tecapro.com Message-ID: <7vahkq$i4d$1@nnrp1.deja.com> References: <7v4cla$1og$1@nnrp1.deja.com> Newsgroups: sci.crypt Lines: 87 > "Trevor Jackson, III" <fullmoon@aspi.net> wrote: > (...) >>It appears to me to be extremely difficult to define "intelligible >>plaintext". An update on how to send "intelligible plaintext" while using two ciphers in random sequence: Take two ciphers that work with 128 bit blocks; Twofish and Rijndael are free and are good choices. Now implement the following protocol that works on blocks of 120 bits of plaintext. For each block compute a hash digest of 8 bits and concatenate it to the plaintext block; randomly choose one of the two ciphers, encrypt the block and send the ciphertext. Also, decrypt this ciphertext with the other cipher, compute the hash of the 120 first bits of the result and compare it with the original hash. If they are equal then add 1 to the plaintext and repeat the whole process. To decrypt try both ciphers and check the hash. If one hash is correct and the other is not then use the plaintext that produced the correct hash. If both hashes are correct then we have a collision. Read the next ciphertext block and check the hashes again. If they are equal (double collision with probability 2^(- 16)) then compare the 120 bit plaintext block created now with the previous 120 bit block; if the current block equals the previous block plus one, then you have identified the correct cipher. There is a extremely low probability (2^ (-136)) of a triple collision in which both plaintexts come out alright. If you worry about such low probabilities, implement a protocol that loops around until the 8 bit hash doesn't collide. This protocol is slow: to encrypt one block it uses a little over one encryption and one decryption plus the time necessary to produce one random bit; to decrypt it uses a little over two decryptions. Taking into account the very high speeds achieved by modern ciphers, almost all applications could live with this. The ciphertext stream is about 7% larger. Why use this protocol instead of cascading two ciphers (with roughly the same cost in speed)? I think the difference is this: By cascading two ciphers you greatly increase the cost of most known attacks but there is a chance that in the future a new attack will work even against the cascade. Using two ciphers in random sequence wipes out whole classes of attacks. Any attack against a cipher that requires a lot of previous knowledge (more than about 30 plaintexts) will not work. Some observations: 1. The 8 bit hash need not be "cryptographically secure". In this context any fast hash function works fine. Probably even a simple xor of all bytes would be sufficient. 2. The random number generator must be unpredictable. For high volume work you will need a hardware based RNG (how fast is the new Pentium chip in this?). For lower speeds (certainly for Internet client requirements) you can use the PC itself as an entropy generator. I think that Yarrow does something like this. I've written code myself that collects entropy in the background using exact timing information for mouse and keyboard events, hard disc access, etc; you can add a hash of the state of the stack, and so on. (I like to call this an "Almost Random Number Generator" or ARNG.) 3. Other variations. Instead of randomizing the cipher, we can design similar protocols that randomize the encryption direction or randomize the key. Examples: Use one cipher in a random sequence of encryptions or decryptions. Use two ciphers each one with its particular key. Use two ciphers and two keys for a protocol that is 4 times slower. 4. The following variant is more efficient (you pay 1% in speed and 1% in space), but may be less secure: Use blocks of 127 bits of plaintext to which you add 1 random bit. This random bit defines which cipher will encrypt the next block. I believe that this protocol is not as secure as the previous ones, because the information about which cipher will be used is explicit. Conclusion: Normally, the attacker is supposed to know everything except the secret key. In addition to this, the proposed protocol denies the attacker knowledge about which cipher has been used for each block. Anything that denies the attacker knowledge is a valid defense. I think that this protocol makes it almost impossible to apply conventional cryptanalytic attacks at a modest cost in speed and space. Sent via Deja.com http://www.deja.com/ Before you buy.
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Sun, 24 Oct 1999 01:08:06 -0700 From: "Roger Schlafly" <real@ieee.org> Message-ID: <7uueot$oia@enews3.newsguy.com> References: <7utv1b$ldc$1@nnrp1.deja.com> Newsgroups: sci.crypt Lines: 14 <dianelos@tecapro.com> wrote in message news:7utv1b$ldc$1@nnrp1.deja.com... > Let us assume, for example, that four AES finalists survive with a > flawless security record. Instead of using any one of them with a 128 > bit key we could use the "fourAES" cipher with a 130 bit key. This > cipher will be stronger as long as k<0.66, i.e. as long as we assume > there exists an (unknown) attack that can break the AES finalists with > less than 2^(0.66*128)=2^84 cost. Even if your analysis is correct, it is stronger by only a trivial amount. It would be more secure to just increase the key size by a few bits.
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Sun, 24 Oct 1999 09:05:43 GMT From: ritter@io.com (Terry Ritter) Message-ID: <3812cb38.10091467@news.io.com> References: <7uueot$oia@enews3.newsguy.com> Newsgroups: sci.crypt Lines: 38 On Sun, 24 Oct 1999 01:08:06 -0700, in <7uueot$oia@enews3.newsguy.com>, in sci.crypt "Roger Schlafly" <real@ieee.org> wrote: ><dianelos@tecapro.com> wrote in message news:7utv1b$ldc$1@nnrp1.deja.com... >> Let us assume, for example, that four AES finalists survive with a >> flawless security record. Instead of using any one of them with a 128 >> bit key we could use the "fourAES" cipher with a 130 bit key. This >> cipher will be stronger as long as k<0.66, i.e. as long as we assume >> there exists an (unknown) attack that can break the AES finalists with >> less than 2^(0.66*128)=2^84 cost. > >Even if your analysis is correct, it is stronger by only a trivial >amount. It would be more secure to just increase the key size >by a few bits. Using different ciphers is fundamentally different from simply increasing the keyspace. We have plenty of keyspace, or could have it if we wanted it. Using different ciphers is not an attempt to gain more keyspace. One difference is that we expect a particular attack on a cipher to work independent of key. Adding keyspace is probably not going to make a successful attack much more difficult. But we do *not* expect the same attack (other than in handwave generalities) to work on a *different* cipher. By changing the cipher we thus terminate any existing break which we cannot expect to know about anyway. We also complicate the ciphertext situation for anyone trying to distinguish the particular ciphertext belonging to a particular cipher. Accumulating ciphertext from a particular cipher would seem to be necessary for most real attacks. --- Terry Ritter ritter@io.com http://www.io.com/~ritter/ Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Sun, 24 Oct 1999 21:26:59 GMT From: dianelos@tecapro.com Message-ID: <7uvtj0$t7e$1@nnrp1.deja.com> References: <7uueot$oia@enews3.newsguy.com> Newsgroups: sci.crypt Lines: 62 In article <7uueot$oia@enews3.newsguy.com>, "Roger Schlafly" <real@ieee.org> wrote: > Even if your analysis is correct, it is stronger by only a trivial > amount. It would be more secure to just increase the key size > by a few bits. If my analysis is correct then it shows that it does make sense to use a pool of independent ciphers because it increases security (against any attack) without decreasing the speed of the system. Now, I agree that if the pool is not very large then the practical advantage is negligible. If somebody discovered a k=0.5 attack against the AES class ciphers then the "fourAES" cipher I described would increase the cost of attack only in 25% (not even one additional bit of security). Using multiple ciphers becomes interesting only with M>>1. Let us for a moment assume we had 2^128 independent ciphers (M=128). If we use only one of them with a key of 256 bits and somebody discovers an k=0.2 attack then we get a cipher with 256*0.2=51 bits of effective security, i.e. we have a catastrophic failure in our hands. If, on the other hand, we use all of them with a key of 128 bits and use the other 128 bits of the key to index the pool of ciphers, then the average cost of the attack 2^(k*N-1)*(2^M+1)=2^153, i.e. it would afford us a very significant 153 bits of security. How do we get 2^128 ciphers? First of all observe that each individual cipher can be very weak indeed. For large M, the cost of breaking the "pooled" cipher would be 2^(k*N+M-1), i.e. that cipher's strength would be k*N+M-1 bits. Even if k=0.01, i.e. even if each individual cipher offers only 1.28 bits of security, the "pooled" cipher would still offer 128.28 bits of security. So the question here is how to produce a great many independent ciphers without much thought about the strength of each individual one. The best way I can imagine to achieve this is to create a cipher generator: take a large number of bits out of the key and use them to produce a cipher (code+tables). Use the rest of the key plus the plaintext blocks to drive that cipher and produce the ciphertext. This is almost exactly what my Frog algorithm does. Only about 5.6% of the key material is really used as key data. The rest is used for building tables and for "expressing" code. The AES specifications didn't allow assembly code - therefore the only code variability I included in my AES candidate was key dependent addresses. Frog is not unique in that respect. Twofish can also be considered a "pool" of 2^64 ciphers because it uses that many key dependent tables. The big question for any such cipher is whether the cipher instances are independent. I have written a more generalized version of Frog that works like a compiler and literally produces code. That version generates key dependent instructions as well as key and data dependent addresses. Therefore, arguably, the generalized version of Frog covers a much more "variable" subset of the cipher space, which brings it nearer to the ideal of a generator that produces independent ciphers. Sent via Deja.com http://www.deja.com/ Before you buy.
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: 26 Oct 1999 12:27:50 -0700 From: daw@blowfish.isaac.cs.berkeley.edu (David Wagner) Message-ID: <7v4vbm$q05$1@blowfish.isaac.cs.berkeley.edu> References: <7uvtj0$t7e$1@nnrp1.deja.com> Newsgroups: sci.crypt Lines: 22 In article <7uvtj0$t7e$1@nnrp1.deja.com>, <dianelos@tecapro.com> wrote: > The best way I can imagine to achieve this is to create a cipher > generator: take a large number of bits out of the key and use them to > produce a cipher (code+tables). Use the rest of the key plus the > plaintext blocks to drive that cipher and produce the ciphertext. > > This is almost exactly what my Frog algorithm does. Only about 5.6% of > the key material is really used as key data. The rest is used for > building tables and for "expressing" code. The problem is that it is very challenging to ensure that all of the resulting ciphers truly are "independent" of each other. If they're not "independent", your argument for security breaks down. In particular, it might be that you could attack N "dependent" ciphers with not much more complexity than that required to attack 1 such cipher. I can think of some very natural examples of this phenomenom. FROG is one good example; there are very large classes of "ciphers" which can be attacked by a differential attack that needs the same chosen plaintext queries for all such ciphers, and thus not knowing which "cipher" is in use doesn't hurt the attacker too much.
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Wed, 27 Oct 1999 20:13:08 GMT From: dianelos@tecapro.com Message-ID: <7v7mcg$fq3$1@nnrp1.deja.com> References: <7v4vbm$q05$1@blowfish.isaac.cs.berkeley.edu> Newsgroups: sci.crypt Lines: 33 In article <7v4vbm$q05$1@blowfish.isaac.cs.berkeley.edu>, daw@blowfish.isaac.cs.berkeley.edu (David Wagner) wrote: > In article <7uvtj0$t7e$1@nnrp1.deja.com>, <dianelos@tecapro.com> wrote: >>The best way I can imagine to achieve this is to create a cipher >>generator: take a large number of bits out of the key and use them to >>produce a cipher (code+tables). Use the rest of the key plus the >>plaintext blocks to drive that cipher and produce the ciphertext. >> >>This is almost exactly what my Frog algorithm does. Only about 5.6% of >>the key material is really used as key data. The rest is used for >>building tables and for "expressing" code. > >The problem is that it is very challenging to ensure that all of the >resulting ciphers truly are "independent" of each other. Very challenging indeed. Any ideas about how it could be done? >If they're not "independent", your argument for security breaks down. >In particular, it might be that you could attack N "dependent" ciphers >with not much more complexity than that required to attack 1 such >cipher. > >I can think of some very natural examples of this phenomenom. FROG is >one good example; (...) What I wanted to say was that Frog can be viewed as a cipher generator - not that it is a generator that produces independent ciphers. Sorry for the ambiguity. Sent via Deja.com http://www.deja.com/ Before you buy.
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Thu, 28 Oct 1999 14:15:21 -0600 From: jgfunj@vgrknf.arg (wtshaw) Message-ID: <jgfunj-2810991415210001@dial-243-062.itexas.net> References: <7v7mcg$fq3$1@nnrp1.deja.com> Newsgroups: sci.crypt Lines: 32 In article <7v7mcg$fq3$1@nnrp1.deja.com>, dianelos@tecapro.com wrote: > In article <7v4vbm$q05$1@blowfish.isaac.cs.berkeley.edu>, > daw@blowfish.isaac.cs.berkeley.edu (David Wagner) wrote: > > In article <7uvtj0$t7e$1@nnrp1.deja.com>, <dianelos@tecapro.com> > wrote: > >>The best way I can imagine to achieve this is to create a cipher > >>generator: take a large number of bits out of the key and use them to > >>produce a cipher (code+tables). Use the rest of the key plus the > >>plaintext blocks to drive that cipher and produce the ciphertext. > >> > >>This is almost exactly what my Frog algorithm does. Only about 5.6% of > >>the key material is really used as key data. The rest is used for > >>building tables and for "expressing" code. > > > >The problem is that it is very challenging to ensure that all of the > >resulting ciphers truly are "independent" of each other. > > Very challenging indeed. Any ideas about how it could be done? > How do you elliminate redundancy in anything? Strangely, the answer might be in another thread, some sort of compression to work against *sameness*, or, at least some sort of tests to reject obvious problems, as in a *check* for randomness, which still miss something critical. A similiar problem exists with multialphabetic ciphers, where commonality is to be avoided. You either fight by contruction, and/or qualify with filters, which sounds most appropriate to be debated regarding a noted issue in entirely a different newsgroup. As to cipher/key problems, some methods prove tolerable. -- To make a mountain out of a molehill, just add dirt.
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: 26 Oct 1999 12:04:07 -0700 From: daw@blowfish.isaac.cs.berkeley.edu (David Wagner) Message-ID: <7v4tv7$pv5$1@blowfish.isaac.cs.berkeley.edu> References: <7utv1b$ldc$1@nnrp1.deja.com> Newsgroups: sci.crypt Lines: 22 In article <7utv1b$ldc$1@nnrp1.deja.com>, <dianelos@tecapro.com> wrote: > Take two ciphers A and B with keys of N bits. These ciphers must be > independent in the sense that physically breaking one does not help in > breaking the other. [...] For ciphers A and B > there exists then a method to break them at a cost comparable to 2^ > (N*k) operations where k<1 (2^N corresponds to brute forcing them). If > you increase the key length by 1 bit, then you would need 2^((N+1)*k) > =2^N * 2^k operations to break A or B [...] Why do you assume that the complexity of attack is linear in the keylength? To put the question differently: why should we expect that increasing the key length will increase the complexity of attack proportionally? In most of the cryptanalytic (shortcut) attacks I can think of, the complexity of attack is essentially independent of the key length. Since the argument is predicated on this assumption, and since the assumption seems unlikely, I'm not sure how much we can really conclude from the argument. (Correct me if I'm misunderstanding.) Is there some way to generalize the argument to work without such a strong "linearity" assumption on the complexity of shortcut attacks?
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Wed, 27 Oct 1999 20:05:21 GMT From: dianelos@tecapro.com Message-ID: <7v7ltu$fdh$1@nnrp1.deja.com> References: <7v4tv7$pv5$1@blowfish.isaac.cs.berkeley.edu> Newsgroups: sci.crypt Lines: 81 In article <7v4tv7$pv5$1@blowfish.isaac.cs.berkeley.edu>, daw@blowfish.isaac.cs.berkeley.edu (David Wagner) wrote: > In article <7utv1b$ldc$1@nnrp1.deja.com>, <dianelos@tecapro.com> wrote: >>Take two ciphers A and B with keys of N bits. These ciphers must be >>independent in the sense that physically breaking one does not help in >>breaking the other. [...] For ciphers A and B >>there exists then a method to break them at a cost comparable to 2^ >>(N*k) operations where k<1 (2^N corresponds to brute forcing them). If >>you increase the key length by 1 bit, then you would need 2^((N+1)*k) >>=2^N * 2^k operations to break A or B [...] > >Why do you assume that the complexity of attack is linear in the >keylength? To put the question differently: why should we expect that >increasing the key length will increase the complexity of attack >proportionally? > >In most of the cryptanalytic (shortcut) attacks I can think of, the >complexity of attack is essentially independent of the key length. > >Since the argument is predicated on this assumption, and since the >assumption seems unlikely, I'm not sure how much we can really >conclude from the argument. (Correct me if I'm misunderstanding.) It seems to me that if an attack's complexity grows slower than linear in the key length then the argument becomes stronger, because even if that attack's complexity did grow linearly the method described would produce a stronger cipher against that attack. In other words, even if we assume that the component ciphers are stronger than what they probably are we can construct an even stronger cipher. A similar argument can be made for the observation that the component ciphers will not really be equally strong: assume that all are as strong as the strongest one and then proceed to construct a cipher that is stronger still. Formally we can express this as follows: For all sets of ciphers and for key bit lengths of N in the range [Nmin,Nmax] there exists k<=1 so that the cost of breaking any one of them is greater or equal 2^(k*N). Nmin, Nmax is the fixed range of key lengths that interest us. 2^(Nmax- Nmin) must greater than the number of ciphers in the set. Let us now choose any two independent ciphers A and B and specify N=Nmin and Nmax=Nmin+1. Then cost(A,N) >= 2^(k*N) cost(B,N) >= 2^(k*N) cost(A,N+1) >= 2^(k*(N+1)) cost(B,N+1) >= 2^(k*(N+1)) Construct a cipher C with keys of N+1 bits and use the last bit of the key to decide whether to apply A or B. Then cost(C,N+1) = cost(A,N)+cost(B,N)/2 >= 3/2 * 2^(k*N) >= 3/2 * 2^(-k) * 2^(k*N + k) >= 3/2 * 2^(-k) * cost(A,N+1) 3/2 * 2^(-k) > 1 => cost(C,N+1) > cost(A,N+1) or: k < ln(3/2)/ln(2) => cost(C,N+1) > cost(A,N+1) So we have constructed a cipher C which is on average stronger than A or B (as long as A and B are rather weak). If the set has 2^M ciphers then the cost of the attack is 2^(k*N1)* (2^M+1). If M is large then no matter how weak the component ciphers are (k->0), any attack against C will have complexity greater than M-1. I am not sure about the practical significance of this. Proving that a huge set of ciphers is independent may be as difficult to do as proving that a cipher is strong. On the other hand, if we build a generator that produces desperately different ciphers we may trust its quality of independence more than we now trust the strength of any conventional design. Sent via Deja.com http://www.deja.com/ Before you buy.
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: 22 Oct 1999 08:00:41 +0100 From: Paul Crowley <paul@hedonism.demon.co.uk> Message-ID: <87r9inhobr.fsf@hedonism.demon.co.uk> References: <380ED1D0.9B71B61F@t-online.de> Newsgroups: sci.crypt Lines: 17 Mok-Kong Shen <mok-kong.shen@t-online.de> writes: > In one point Mr. Schneier has clearly and definitely erred, namely > concerning his phrase about randomly choosing a cipher. Randomly > choosing among a set of ciphers can NEVER be weaker than the > weakest of the set. False. If one cipher has an attack requiring 2^20 plaintexts and 2^50 work, and the other 2^30 plaintexts and 2^30 work, then an attacker will be able to recover messages providing they can mount *either* attack, thus making the overall system weaker than either cipher used on its own. Cipher strength is not measured on a single linear scale. -- __ \/ o\ paul@hedonism.demon.co.uk Got a Linux strategy? \ / /\__/ Paul Crowley http://www.hedonism.demon.co.uk/paul/ /~\
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Fri, 22 Oct 1999 20:04:27 +0200 From: Mok-Kong Shen <mok-kong.shen@t-online.de> Message-ID: <3810A72B.6CE17EA4@t-online.de> References: <87r9inhobr.fsf@hedonism.demon.co.uk> Newsgroups: sci.crypt Lines: 29 Paul Crowley wrote: > > Mok-Kong Shen <mok-kong.shen@t-online.de> writes: > > In one point Mr. Schneier has clearly and definitely erred, namely > > concerning his phrase about randomly choosing a cipher. Randomly > > choosing among a set of ciphers can NEVER be weaker than the > > weakest of the set. > > False. If one cipher has an attack requiring 2^20 plaintexts and 2^50 > work, and the other 2^30 plaintexts and 2^30 work, then an attacker > will be able to recover messages providing they can mount *either* > attack, thus making the overall system weaker than either cipher used > on its own. Sorry that I don't quite understand. In one case we have C1, C2, C3, C4, .... In other case we have something like C1, C2', C3', C4, ..... where the primes refer to encipherment by the alternate algorithm. Now the analyst doesn't have a priori knowlege of which message is enciphered by which algorithm. Why is the second scheme weaker? Could you explain in a bit detail? > > Cipher strength is not measured on a single linear scale. The bigger problem is there is no exact scale at all, not even a non-linear scale that is scientifically rigorously sound like the scale to measure distance. M. K. Shehn
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Sat, 23 Oct 1999 22:52:51 GMT From: ritter@io.com (Terry Ritter) Message-ID: <38123c26.23603548@news.io.com> References: <87r9inhobr.fsf@hedonism.demon.co.uk> Newsgroups: sci.crypt Lines: 41 On 22 Oct 1999 08:00:41 +0100, in <87r9inhobr.fsf@hedonism.demon.co.uk>, in sci.crypt Paul Crowley <paul@hedonism.demon.co.uk> wrote: >Mok-Kong Shen <mok-kong.shen@t-online.de> writes: >> In one point Mr. Schneier has clearly and definitely erred, namely >> concerning his phrase about randomly choosing a cipher. Randomly >> choosing among a set of ciphers can NEVER be weaker than the >> weakest of the set. > >False. If one cipher has an attack requiring 2^20 plaintexts and 2^50 >work, and the other 2^30 plaintexts and 2^30 work, then an attacker >will be able to recover messages providing they can mount *either* >attack, thus making the overall system weaker than either cipher used >on its own. I have no idea what this can possibly mean. Even if the opponent has both lower values, here 2^20 plaintext and 2^30 work, how does that help? He needs to satisfy *all* requirements for *any* *one* attack; he cannot mix and match. Then we have the issue of "recover messages." Which messages? All messages, or just that proportion which was protected under the weaker cipher? Clearly, it is the part rather than the whole which is recovered by the lesser attack. But if we are in fact using the lesser cipher, that is our whole. Ideally we would never use an attackable cipher. If we knew the strengths of ciphers, that what we would do. Unfortunately, we do *not* know the strengths of ciphers which we use, so we can hardly choose between them. The alternative to using a variety of ciphers, of course, is to depend upon something which explicitly cannot be depended upon. --- Terry Ritter ritter@io.com http://www.io.com/~ritter/ Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Thu, 21 Oct 1999 11:21:19 +0100 From: "Brian Gladman" <gladman@seven77.demon.co.uk> Message-ID: <940501283.15899.0.nnrp-12.c2de6a96@news.demon.co.uk> References: <380e7293.821932@news.visi.com> <19991019231649.22027.00000075@ng-cm1.aol.com> Newsgroups: sci.crypt Lines: 57 Bruce Schneier <schneier@counterpane.com> wrote in message news:380e7293.821932@news.visi.com... > On 20 Oct 1999 03:16:49 GMT, djohn37050@aol.com (DJohn37050) wrote: > > >Jerry, you have a GREAT reason to have more than one AES winner, in a > >satellite, the cost of more than one is small, but the cost of another > >satellite is huge. > > > >I am certain there are other examples like this. > > It's a moronic example. Do you really think that satellites are > thrown away if there are software bugs? Even NASA probes have > uploadable software. "Yes" is the short answer for at least some satellites. How many satellites do you know of where (1) encryption is employed, and (2) it is implemented in software or field updatable hardware? For communications and surveillance satellites that use encryption to protect their primary channels (as distinct from control channels) the bandwidths would typically be far too high for the use of software based encryption. Moreover, encryption hardware would not necessarily be field updatable because this would conflict with other requirements. And satellite control channels are especially critical and hence require very high levels of protection from a wide range of possible attacks. In consequence it would not be unreasonable to consider multiple encryption layers (sequential encryption) in this part of the overall design. On what experience base do you assert that satellites are a 'moronic example' of the practical use of encryption? Encryption on satellites is inevitably specilaised and hence unrepresentative of typical use. But I think that 'moronic' goes too far. > I give up. It's frustrating to argue real-world constraints with > people who don't deal with real-world constraints. People in this [snip] I am not sure whether you are characterising the whole thread with this remark or just this sub-thread. I certainly agree that sci.crypt is a difficult place to have a serious debate about such matters because it is always necessary to apply a 'common sense' filter to so much of what is said (I only rarely join in for just this reason). But between the 'noise' there has been a serious debate going on and I know for certain that a number of those who are arguing for multiple AES algorithms are very well aware of real world constraints. Moreover, spurious and purely academic arguments have not been the exclusive preserve of those who argue for an AES outcome that is more than the announcement of a single winner. Brian Gladman
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Thu, 21 Oct 1999 11:40:17 -0700 From: "Roger Schlafly" <real@ieee.org> Message-ID: <7unmk8$mqh$1@nntp1.atl.mindspring.net> References: <940501283.15899.0.nnrp-12.c2de6a96@news.demon.co.uk> Newsgroups: sci.crypt Lines: 16 Brian Gladman <gladman@seven77.demon.co.uk> wrote in message news:940501283.15899.0.nnrp-12.c2de6a96@news.demon.co.uk... > On what experience base do you assert that satellites are a 'moronic > example' of the practical use of encryption? Encryption on satellites is > inevitably specilaised and hence unrepresentative of typical use. But I > think that 'moronic' goes too far. I'm sorry, but I agree with Bruce. It is a moronic example. Satellite folks do worry about catastrophic failure, but not about AES flaws. Even if there is a security failure, it will almost certainly not be because the AES block cipher has some sort of weakness. There are 100s of other problems, each of which is millions of times more likely to go wrong.
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Thu, 21 Oct 1999 14:17:59 -0600 From: jcoffin@taeus.com (Jerry Coffin) Message-ID: <MPG.127921664e5eb6398973c@news.mindspring.com> References: <7unmk8$mqh$1@nntp1.atl.mindspring.net> Newsgroups: sci.crypt Lines: 46 In article <7unmk8$mqh$1@nntp1.atl.mindspring.net>, real@ieee.org says... > Brian Gladman <gladman@seven77.demon.co.uk> wrote in message > news:940501283.15899.0.nnrp-12.c2de6a96@news.demon.co.uk... > > On what experience base do you assert that satellites are a 'moronic > > example' of the practical use of encryption? Encryption on satellites is > > inevitably specilaised and hence unrepresentative of typical use. But I > > think that 'moronic' goes too far. > > I'm sorry, but I agree with Bruce. It is a moronic example. > Satellite folks do worry about catastrophic failure, but not > about AES flaws. Even if there is a security failure, it will > almost certainly not be because the AES block cipher has > some sort of weakness. There are 100s of other problems, > each of which is millions of times more likely to go wrong. Hmm...let's see. Bruce says failure of AES isn't a problem because it would be made reprogrammable (while ignoring the security implications of doing that). You say the designer would NOT worry about AES failing, in which case he'd almost certainly hard-wire since this would keep from introducing the other security problems, as well as saving quite a bit of money and power. So, if I'm understanding this correctly, when you say "I agree with Bruce" you really mean "Bruce's conclusion was right, but his reasoning was completely wrong from beginning to end." Is that correct? Or are you saying the designer really WOULD put the AES in programmable logic despite not being concerned with it possibly failing? If so, why would he do that? I'd also note that programmable logic is quite expensive and does NOT make particularly efficient use of die area -- I'm willing to bet that a hardwired implementation of (say) three of the five AES finalists would cost less to build than using a CPLD large enough to hold any one of them, and would consume less power as well. Most of the reasons originally given to favor a single algorithm would almost certainly work in reverse if, as a consequence, the single algorithm were placed in programmable logic. -- Later, Jerry. The universe is a figment of its own imagination.
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Thu, 21 Oct 1999 23:15:28 -0700 From: "Roger Schlafly" <real@ieee.org> Message-ID: <7uovc0$1bss@enews2.newsguy.com> References: <MPG.127921664e5eb6398973c@news.mindspring.com> Newsgroups: sci.crypt Lines: 13 Jerry Coffin <jcoffin@taeus.com> wrote in message news:MPG.127921664e5eb6398973c@news.mindspring.com... > Hmm...let's see. Bruce says failure of AES isn't a problem because it > would be made reprogrammable (while ignoring the security implications > of doing that). The system will have many portions. The portions you are worried about, you put in software. Otherwise, in hardware. Either way, it is not a problem. At least, not a problem that is going to be solved by multiple AES winners.
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Fri, 22 Oct 1999 09:03:35 -0400 From: "Trevor Jackson, III" <fullmoon@aspi.net> Message-ID: <381060A7.B68AD67E@aspi.net> References: <7uovc0$1bss@enews2.newsguy.com> Newsgroups: sci.crypt Lines: 16 Roger Schlafly wrote: > Jerry Coffin <jcoffin@taeus.com> wrote in message > news:MPG.127921664e5eb6398973c@news.mindspring.com... > > Hmm...let's see. Bruce says failure of AES isn't a problem because it > > would be made reprogrammable (while ignoring the security implications > > of doing that). > > The system will have many portions. The portions you are worried > about, you put in software. Otherwise, in hardware. Either way, it > is not a problem. At least, not a problem that is going to be solved > by multiple AES winners. Are you speaking Ex Cathedra or are we permitted to know the reasoning behind your pronouncement?
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Fri, 22 Oct 1999 14:13:51 -0600 From: jcoffin@taeus.com (Jerry Coffin) Message-ID: <MPG.127a5c0e2fb09c8989746@news.mindspring.com> References: <7uovc0$1bss@enews2.newsguy.com> Newsgroups: sci.crypt Lines: 64 In article <7uovc0$1bss@enews2.newsguy.com>, real@ieee.org says... > Jerry Coffin <jcoffin@taeus.com> wrote in message > news:MPG.127921664e5eb6398973c@news.mindspring.com... > > Hmm...let's see. Bruce says failure of AES isn't a problem because it > > would be made reprogrammable (while ignoring the security implications > > of doing that). > > The system will have many portions. The portions you are worried > about, you put in software. Otherwise, in hardware. Either way, it > is not a problem. At least, not a problem that is going to be solved > by multiple AES winners. I take little comfort from your assurance that "Either way, it is not a problem." My only comfort is derived from the fact that you apparently haven't and won't design any systems upon which my life or the peace of the world depend. The reality is exactly the opposite: whichever decision you make, there WILL be a problem, and having multiple hard-coded algorithms DOES provide a credible solution to at least most of the problem. If you hardwire a single algorithm, security is lost when/if that algorithm is broken. If you decide to cure that by making the single algorithm re- programmable, then you have to protect the programming capability with another algorithm. In addition, by putting the algorithm into re- programmable hardware, you lose much of the benefit of putting it into hardware at all. Having multiple algorithms deals with this in a relatively simple fashion: you hardwire multiple algorithms. You have a message to switch from each algorithm to the next, but allows NO other control over the satellite's actions at all. If you hardwire one algorithm, the satellite is secure until that algorithm is broken. If you make the algorithm re-programmable, your satellite is secure until one of two algorithms is broken. If you have five hardwired algorithms, your satellite is secure until all five algorithms are broken. If there's a flaw in the logic here, please be so kind as to point it out. A simple statement that "this doesn't really cure any problem" will not work. If you're looking at the single hardwired algorithm, then you have to show that breaking one algorithm is just as difficult as breaking N algorithms (1<N<=5). If you want to back up Bruce's idea of the algorithm being programmable, then you have to show that breaking your choice of 2 algorithms is just as difficult as breaking all N algorithms (again, 1<N<=5). I simply don't see ANY logical way to conclude anything of the sort. I've already made one post that pointed out that I don't think satellite design is a mainstream market that should be considered heavily in AES selection. Bryan Gladman has echoed that from a much more authoritative position. Neither of these, however, has any effect on Bruce's claim that my example was "moronic" or your's that "Either way, it makes no difference". -- Later, Jerry. The universe is a figment of its own imagination.
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: 22 Oct 1999 14:07:23 -0700 From: daw@blowfish.isaac.cs.berkeley.edu (David Wagner) Message-ID: <7uqjmb$oei$1@blowfish.isaac.cs.berkeley.edu> References: <MPG.127a5c0e2fb09c8989746@news.mindspring.com> Newsgroups: sci.crypt Lines: 20 In article <MPG.127a5c0e2fb09c8989746@news.mindspring.com>, Jerry Coffin <jcoffin@taeus.com> wrote: > If you hardwire one algorithm, the satellite is secure until that > algorithm is broken. If you make the algorithm re-programmable, your > satellite is secure until one of two algorithms is broken. If you > have five hardwired algorithms, your satellite is secure until all > five algorithms are broken. > > If there's a flaw in the logic here, please be so kind as to point it > out. You seem to assume that you will know when someone breaks your algorithm. History suggests that this is unlikely -- the adversaries who are most likely to spend a lot of effort patiently searching for weaknesses are also the ones who are least likely to tell you when they break your cipher. I think it is more prudent to assume that if you select somehow from a list of five algorithms for each connection, you may end up with a system that is only as strong as the weakest of the five algorithms.
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Fri, 22 Oct 1999 16:31:08 -0600 From: jcoffin@taeus.com (Jerry Coffin) Message-ID: <MPG.127a8eb5cdf3aebe98974a@news.mindspring.com> References: <7uqjmb$oei$1@blowfish.isaac.cs.berkeley.edu> Newsgroups: sci.crypt Lines: 74 In article <7uqjmb$oei$1@blowfish.isaac.cs.berkeley.edu>, daw@blowfish.isaac.cs.berkeley.edu says... > In article <MPG.127a5c0e2fb09c8989746@news.mindspring.com>, > Jerry Coffin <jcoffin@taeus.com> wrote: > > If you hardwire one algorithm, the satellite is secure until that > > algorithm is broken. If you make the algorithm re-programmable, your > > satellite is secure until one of two algorithms is broken. If you > > have five hardwired algorithms, your satellite is secure until all > > five algorithms are broken. > > > > If there's a flaw in the logic here, please be so kind as to point it > > out. > > You seem to assume that you will know when someone breaks your algorithm. Yes, more or less. > History suggests that this is unlikely -- the adversaries who are most > likely to spend a lot of effort patiently searching for weaknesses are > also the ones who are least likely to tell you when they break your cipher. Of course. OTOH, if you're at all prudent about things, you can get a pretty fair idea that your security is breaking down somewhere, and when that happens, you can at least take SOME action if your investigation indicates that the cipher may be what's causing a problem. Your suggestion seems to be that since you MAY not know when you have a problem, that it's best to stick your head in the sand and simply assume that you'll never have a problem, at least in this area. > I think it is more prudent to assume that if you select somehow from a > list of five algorithms for each connection, you may end up with a system > that is only as strong as the weakest of the five algorithms. WHY? I've already suggested a method that, AT WORST is at least as strong as the method you suggest. You're basically asking that I assume that whoever designs the system is an idiot. You're asking that if I design a system, I that ignore the best method I know and intentionally weaken the system. The phrase "straw man" comes to mind here: you're basically asking that if I don't select the method you consider good, that the only alternative I consider is one we both already know is bad. If no third alterative existed, then your position might be a reasonable one, but it seems pretty clear to me that if you include a number of ciphers and simply never use any but one, then the security is no worse than if you'd only ever included one in the first place. IOW, the worst possible case with my suggestion is as strong as your suggestion. Even in this worst-case scenarios, I think having multiple AES winners improves security. The funding for cryptanalysis and number of serious cryptanalysts in the world are both quite limited. If AES selects a number of different winning algorithms, that research capability is likely to be spread more or less evenly among those winners rather all being concentrated on one. This is likely to reduce the possibility of any one being broken in any specific period of time. In addition, if an opponent KNOWS that at the first sign of a problem, you can switch from one cipher to another, he's less likely to invest the (typically large) amount of money necessary to build specialized hardware to break the first cipher to start with. Thus, until there were really serious theoretical problems found with _all_ the winners, it would be substantially less likely that anybody would invest the money necessary to really decrypt any of them. -- Later, Jerry. The universe is a figment of its own imagination.
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: 22 Oct 1999 23:46:29 GMT From: djohn37050@aol.com (DJohn37050) Message-ID: <19991022194629.28474.00000026@ng-ck1.aol.com> References: <MPG.127a8eb5cdf3aebe98974a@news.mindspring.com> Newsgroups: sci.crypt Lines: 6 Yes, the effect of having multiple algs increasing the cost/benefit ratio to an attacker was mentioned in my AES paper. This means it is entirely possible that a flaw will not be found (or found as fast) if multiple winners are picked than would be found if there is only one. In one case, jackpot; in the other, switch to backup. Don Johnson
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: 22 Oct 1999 17:28:57 -0700 From: daw@blowfish.isaac.cs.berkeley.edu (David Wagner) Message-ID: <7uqvg9$ol1$1@blowfish.isaac.cs.berkeley.edu> References: <MPG.127a8eb5cdf3aebe98974a@news.mindspring.com> Newsgroups: sci.crypt Lines: 82 In article <MPG.127a8eb5cdf3aebe98974a@news.mindspring.com>, Jerry Coffin <jcoffin@taeus.com> wrote: > Your suggestion seems to be that since you MAY not know when you have > a problem, that it's best to stick your head in the sand and simply > assume that you'll never have a problem, at least in this area. That's not what I said at all. Please try to understand my reasoning before dismissing it out of hand; there may be a fatal flaw in my arguments, but I don't think this is it. > > I think it is more prudent to assume that if you select somehow from a > > list of five algorithms for each connection, you may end up with a system > > that is only as strong as the weakest of the five algorithms. > > WHY? I've already suggested a method that, AT WORST is at least as > strong as the method you suggest. Maybe it is, maybe it isn't. That's a very strong claim; I'd like to show that it's not only wrong, but it's backwards. Watch closely. Suppose unbeknownst to us, one of the AES finalists ("the lemon") is fatally flawed, but the rest are totally strong. In other words, let's assume that our adversaries are able to read traffic encrypted under "the lemon", but we don't realize this. Now, there are two ways we could have designed our cryptosystems: 1. Scenario: We picked one lucky finalist as the single AES winner. That cipher, and no other, becomes deployed everywhere. Risk: If we pick "the lemon" as our winner, all of traffic is readable. Expected result: With probability at most 1/5, all our traffic is readable. With prob. at least 4/5, all our traffic is secure. 2. Scenario: All five finalists were designed as winners; the idea is that, for each new connection, one picks a new key at random _and_ a new cipher (from the five finalists) at random. This is what is done in deployed systems worldwide. Risk: Every connection that uses "the lemon" is insecure. Expected result: With probability 1, exactly 1/5 of our traffic can be read by the adversary. Tell me if I'm wrong, but I think #2 summarizes your suggested approach, and #1 summarizes the "conventional wisdom" approach. Let's compare the two approaches. I claim that #1 is a much better situation to be in. Consider: In many cases when we send the same confidential data across multiple connections. For instance, if we want to keep it a secret that our company is about to be bought out by Microsoft, we might have lots of encrypted telephone conversations where company employees discuss the impact of that amongst themselves. If the adversary is able to break the encryption associated with any one of those phone conversations, he has all the information we wanted to hide, and we lose lots of money; from our point of view, if he can crack one of them, it's as bad as if he could crack them all. Now it should become clear why approach #1 is preferable. In scenario #2, if we have dozens of conversations about the impending buyout, we can be sure that at least one of those conversations will have used "the lemon" and thus will be exposed. Thus, in scenario #2, we are guaranteed to get screwed and to lose money. In contrast, in scenario #1, we lose money only if NIST got unlucky when picking a winner for the AES. Thus, in scenario #1, we have at most a 1/5 probability of getting screwed. Personally, I'd rather take the <= 1/5 probability of getting screwed than take the scenario where I'm guaranteed to get screwed! Now let's compare to what you claimed. You claimed (if I understand correctly) that #2 is "AT WORST" at least as strong as #1. Yet it should now be clear that #2 is weaker than #1: substantially weaker, even. In fact, I'd claim that you have the statement backwards: the correct statement is "scenario #1 (picking a single winner) is AT WORST at least as strong as scenario #2 (picking multiple winners), and probably stronger". So, where did I go wrong?
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Fri, 22 Oct 1999 20:48:17 -0600 From: jcoffin@taeus.com (Jerry Coffin) Message-ID: <MPG.127acf919169e8c98974d@news.mindspring.com> References: <7uqvg9$ol1$1@blowfish.isaac.cs.berkeley.edu> Newsgroups: sci.crypt Lines: 130 In article <7uqvg9$ol1$1@blowfish.isaac.cs.berkeley.edu>, daw@blowfish.isaac.cs.berkeley.edu says... [ ... ] > 2. Scenario: All five finalists were designed as winners; the idea is > that, for each new connection, one picks a new key at random _and_ > a new cipher (from the five finalists) at random. This is what is > done in deployed systems worldwide. > > Risk: Every connection that uses "the lemon" is insecure. > > Expected result: With probability 1, exactly 1/5 of our traffic can > be read by the adversary. This bears no relationship to what I proposed at all. What I proposed was that you start with one cipher. You use it for ALL communication. When and if you are given reason to believe this cipher is or will become compromised, you switch to the second. When/if you are given reason to believe that is or may become compromised, you switch to the third. This continues until you run out of ciphers. Now, there some people have proposed ordering the ciphers in the standard -- I.e. the standard itself say something to the effect that: "here are algorithms 1, 2 and 3" and they'd be used in that order. I don't agree with this approach. I believe AES should stick to algorithms, not protocols. Protocols are (at least IMO) an entirely separate kettle of fish from algorithms, and should be kept separate both in the implementation and the standards -- right now FIPS 46-2 describes a single algorithm; other standards deal with how to do chaining, how to do protocols, etc., and I think that's the way things should stay. The one place you'd see something in AES that deal with algorithm selection would be a bit like the progression from FIPS 46-2 to FIPS 46-3 -- this changes the recommendation from DES to 3DES. In a later version of AES, there might be a change from (say) three algorithms to two if one of the existing algorithms was found to have a substantial weakness. The basic difference would be that in the AES, there would be more than one algorithm described -- nothing more. Nothing about which one is preferred, how to pick between them, negotiate usage, etc. Ultimately, ensuring interoperability goes WELL beyond the algorithm, and does NOT belong in AES, IMO. One proposal has suggested that one particular algorithm be chosen to include in all possible AES implementations. IMO, this would be pointless since it's still far to weak to ensure anything approaching interoperability (just as the single algorithm in DES doesn't ensure interoperability between products). > Tell me if I'm wrong, but I think #2 summarizes your suggested approach, > and #1 summarizes the "conventional wisdom" approach. I'm not sure how you could have gotten this impression from my last message, but as I said above, it's not merely a bit mistaken, but dead wrong from beginning to end. > Let's compare the two approaches. I claim that #1 is a much better > situation to be in. Consider: In many cases when we send the same > confidential data across multiple connections. I claim that #3 is a better situation to be in. First of all, I think your idea that there's one "lemon" and four "winners" is unrealistic. The believe all the algorithms are well enough designed that there's not going to be a quick, simple break on any of them. Even so, I think #2 is _probably_ a better scenario than #1. I think it's safe to say that breaking AES by key-space exhaustion isn't something to worry about. Most other forms of attack we know about involve collecting large amounts of text encrypted with the cipher under attack. If the text is encrypted randomly with N different ciphers, then it takes approximately N times as long to collect a sufficient amount of text to attack a single cipher. This means it is N times as likely that the key will be changed before a sufficient amount of text can be collected. > Now it should become clear why approach #1 is preferable. In scenario > #2, if we have dozens of conversations about the impending buyout, we > can be sure that at least one of those conversations will have used > "the lemon" and thus will be exposed. Thus, in scenario #2, we are guaranteed > to get screwed and to lose money. In contrast, in scenario #1, we lose > money only if NIST got unlucky when picking a winner for the AES. Thus, > in scenario #1, we have at most a 1/5 probability of getting screwed. I think you're ignoring a great deal of what you know about cryptanalysis. You know perfectly well that a single conversation (or email message) is likely to provide an insufficient amount of encrypted text to mount a successful attack on anything. The opponent will likely have to collect data from (at least) millions of conversations before an attack becomes feasible at all. By using 5 ciphers, the length of time before any attack becomes feasible at all is multiplied by 5 as well. IOW, chances are 5 times as high that the opponent won't be able to break anything until after the news is publicly available anyway. > Now let's compare to what you claimed. You claimed (if I understand > correctly) that #2 is "AT WORST" at least as strong as #1. Yet it should > now be clear that #2 is weaker than #1: substantially weaker, even. I hadn't claimed anything about #2. I was quite clear in stating that was I was offering was completely different from #2, and I'm still quite clear about that -- I didn't think #2 was the optimal approach and I still don't. Despite this, given the amount of encrypted text likely to be needed for a successful attack on any of the ciphers, not to mention the amount of research necessary to create a practical attack in the first place, and the dilution of research that will take place if multiple winners are selected, I think #2 is STILL probably superior to #1. > In fact, I'd claim that you have the statement backwards: the correct > statement is "scenario #1 (picking a single winner) is AT WORST at least > as strong as scenario #2 (picking multiple winners), and probably stronger". > > So, where did I go wrong? Almost everywhere. You started by ignoring what I'd written, and trying to put me down as advocating something entirely different than I really wrote about at all. You continued by ignoring most of what you've known about cryptanalysis for years. You finished by ignoring the effect of diluting research over a number of algorithms instead of nearly the entire world's efforts in cryptanalysis being aimed at one specific algorithm. I'm not sure there aren't any other defects in your argument, but those three seem quite obvious. -- Later, Jerry. The universe is a figment of its own imagination.
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: 22 Oct 1999 21:28:52 -0700 From: daw@blowfish.isaac.cs.berkeley.edu (David Wagner) Message-ID: <7urdi4$op0$1@blowfish.isaac.cs.berkeley.edu> References: <MPG.127acf919169e8c98974d@news.mindspring.com> Newsgroups: sci.crypt Lines: 30 In article <MPG.127acf919169e8c98974d@news.mindspring.com>, Jerry Coffin <jcoffin@taeus.com> wrote: > This bears no relationship to what I proposed at all. What I proposed > was that you start with one cipher. You use it for ALL communication. > When and if you are given reason to believe this cipher is or will > become compromised, you switch to the second. When/if you are given > reason to believe that is or may become compromised, you switch to the > third. This continues until you run out of ciphers. Ahh, you're right, I misunderstood. I apologize profusely. Ok, now we're back to the problem of detecting when the opponent has broken our cipher. In any case, there's clearly a cost-benefit tradeoff (in some systems, anyway) between (1) cost and (2) ease of switching ciphers if a flaw is found, and I'd claim that the right balance point will be different for different applications. Forcing folks to implement multiple _alternates_ (runners-up) if they want to comply with the AES does make it easier to switch ciphers at some future time if necessary, but it's not clear to me that it's the right design choice to force on _all_ deployed systems. My preference would be to have exactly one MUST-implement "AES winner". Then, if you like, you can pick several optional alternates that you MAY implement at your discretion; I don't care about that part. (I'm using the words MUST and MAY as in the meaning established for IETF standards.) Would you agree to such an approach? Or do you feel we need to force multiple MUST-implement ciphers on everyone in the world who wants to claim AES-compliance?
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Sat, 23 Oct 1999 11:04:16 +0200 From: Mok-Kong Shen <mok-kong.shen@t-online.de> Message-ID: <38117A10.EBF78F3F@t-online.de> References: <7urdi4$op0$1@blowfish.isaac.cs.berkeley.edu> Newsgroups: sci.crypt Lines: 15 David Wagner wrote: > > My preference would be to have exactly one MUST-implement "AES winner". > Then, if you like, you can pick several optional alternates that you MAY > implement at your discretion; I don't care about that part. (I'm using > the words MUST and MAY as in the meaning established for IETF standards.) I conjecture that this is acceptable to the majority. This means however, as I said in a previous follow-up, that NIST, besides picking a winner, has to testify the usefulness of a couple of other candidates in formal documents with details of the same nature as the winner. M. K. Shen
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Sat, 23 Oct 1999 18:04:26 +0200 From: Mok-Kong Shen <mok-kong.shen@t-online.de> Message-ID: <3811DC8A.3D1E5CE@t-online.de> References: <3811AD98.43C6F1DC@aspi.net> <38117A10.EBF78F3F@t-online.de> Newsgroups: sci.crypt Lines: 24 Trevor Jackson, III wrote: > > Mok-Kong Shen wrote: > > I conjecture that this is acceptable to the majority. This means > > however, as I said in a previous follow-up, that NIST, besides > > picking a winner, has to testify the usefulness of a couple of > > other candidates in formal documents with details of the same nature > > as the winner. > > I disagree. A MUST-implement requirement forces every designer to include the > MUST cipher even if it will never be used. I.e., the MAY cipher might so > dominate the application environment that it is the obvious choice. What > benefit is there in forcing implementors to waste their effort on unnecessary > hoops just to get approval? But I believe one could be satisfied with a compromise. I guess that the possibility of NIST announcing, say, 3 candidates to be 'the' (all entirely equivalent) standards is fiable. So letting one be the must and the others be may could be a practicable solution out of the dilema. Note that one must not use the MUST implementation at all. (I am aware that my viewpoint is critisizable. ) M. K. Shen
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Sun, 24 Oct 1999 10:18:04 +0200 From: Mok-Kong Shen <mok-kong.shen@t-online.de> Message-ID: <3812C0BC.A85E70E8@t-online.de> References: <381272E4.6F192CC@aspi.net> <381233F1.1A2332BA@t-online.de> Newsgroups: sci.crypt Lines: 54 Trevor Jackson, III wrote: > > Mok-Kong Shen wrote: > > > Trevor Jackson, III wrote: > > > > > > What do you belive is the difference between a MUST implement feature and a MAY > > > implement feature? > > > > I am not sure in which sense your question is posed. > > You suggested that NIST recommend one MUST implement cipher and several MAY implement > ciphers. They you said that implementors would not have to implement the MUST > implement algorithm. This last statement appears to contradict the definition of > MUST implement. It appears that you think the MUST implement cipher you think NIST > should recommend is and implementation option. The MAY-implement ciphers are > obviously optional as well. So why did you distingush between MUST and MAY if the > difference makes no difference? I am quite sure that you mis-read my sentences. I am quoting my previous post below: But I believe one could be satisfied with a compromise. I guess that the possibility of NIST announcing, say, 3 candidates to be 'the' (all entirely equivalent) standards is fiable. So letting one be the must and the others be may could be a practicable solution out of the dilema. Note that one must not use the MUST implementation at all. (I am aware that my viewpoint is critisizable. ) I way saying that one (the user) must not use the MUST implementation, not that the implementor may omit the MUST implementation. This implies that, if e.g. there are rumors that the winner were broken, he can simply drop that. While the analogy with standards in programming languages is only partly appropriate (because we are in our case considering a number of candidates that are functionally equivalent to one another, not certain features that are necessary and others that are not necessary in all situations) I do like to mention that the language COBOL has 3 levels in its standard. All implementor must implement the first level (without that no meaningful program can be written), those that also implement the higher levels can claim that their products provide these higher level features. So the market demand will determine what kind of complilers at what price category one will have. In our case a manufacturer that also implements the two MAY algorithms can claim that the user can have a random choice of the three available algorithms or do multiple encryption with them. Those users that have very have good faith in the winner can buy a product that only implements that at a lower price. Since all implementations have the MUST algorithm, all users can at least communicate with that and the issue of interoperability vanishes. M. K. Shen ----------------------- http://home.t-online.de/home/mok-kong.shen
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Sat, 23 Oct 1999 08:41:32 -0400 From: "Trevor Jackson, III" <fullmoon@aspi.net> Message-ID: <3811ACFC.B07D4E1D@aspi.net> References: <7urdi4$op0$1@blowfish.isaac.cs.berkeley.edu> Newsgroups: sci.crypt Lines: 39 David Wagner wrote: > In article <MPG.127acf919169e8c98974d@news.mindspring.com>, > Jerry Coffin <jcoffin@taeus.com> wrote: > > This bears no relationship to what I proposed at all. What I proposed > > was that you start with one cipher. You use it for ALL communication. > > When and if you are given reason to believe this cipher is or will > > become compromised, you switch to the second. When/if you are given > > reason to believe that is or may become compromised, you switch to the > > third. This continues until you run out of ciphers. > > Ahh, you're right, I misunderstood. I apologize profusely. > > Ok, now we're back to the problem of detecting when the opponent has > broken our cipher. > > In any case, there's clearly a cost-benefit tradeoff (in some systems, > anyway) between (1) cost and (2) ease of switching ciphers if a flaw is > found, and I'd claim that the right balance point will be different for > different applications. Forcing folks to implement multiple _alternates_ > (runners-up) if they want to comply with the AES does make it easier to > switch ciphers at some future time if necessary, but it's not clear to > me that it's the right design choice to force on _all_ deployed systems. > > My preference would be to have exactly one MUST-implement "AES winner". > Then, if you like, you can pick several optional alternates that you MAY > implement at your discretion; I don't care about that part. (I'm using > the words MUST and MAY as in the meaning established for IETF standards.) > > Would you agree to such an approach? Or do you feel we need to force > multiple MUST-implement ciphers on everyone in the world who wants to claim > AES-compliance? Why have any MUST implement ciphers at all. The AES contest is not defined to be an interoperability issue. It is defined to be a threshold test for USG acceptance of security products. Thus if NIST chooses a set of AES algorithms any cipher from that set would satisfy the minimum security threshold and thus be "AES compliant".
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Sat, 23 Oct 1999 11:22:05 -0700 From: "Roger Schlafly" <real@ieee.org> Message-ID: <7usubj$2pib@enews3.newsguy.com> References: <3811ACFC.B07D4E1D@aspi.net> Newsgroups: sci.crypt Lines: 18 Trevor Jackson, III <fullmoon@aspi.net> wrote in message news:3811ACFC.B07D4E1D@aspi.net... > Why have any MUST implement ciphers at all. The AES contest is not defined to > be an interoperability issue. It is defined to be a threshold test for USG > acceptance of security products. Thus if NIST chooses a set of AES algorithms > any cipher from that set would satisfy the minimum security threshold and thus > be "AES compliant". All other things being equal, interoperability is a good thing. That goes without saying. But even if NIST's role is only one of acceptance testing, its job is a lot easier with 1 cipher, than with 5 or 15.
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Sat, 23 Oct 1999 22:49:12 -0400 From: "Trevor Jackson, III" <fullmoon@aspi.net> Message-ID: <381273A8.F638A516@aspi.net> References: <7usubj$2pib@enews3.newsguy.com> Newsgroups: sci.crypt Lines: 29 Roger Schlafly wrote: > Trevor Jackson, III <fullmoon@aspi.net> wrote in message > news:3811ACFC.B07D4E1D@aspi.net... > > Why have any MUST implement ciphers at all. The AES contest is not > defined to > > be an interoperability issue. It is defined to be a threshold test for > USG > > acceptance of security products. Thus if NIST chooses a set of AES > algorithms > > any cipher from that set would satisfy the minimum security threshold and > thus > > be "AES compliant". > > All other things being equal, interoperability is a good thing. That goes > without saying. But even if NIST's role is only one of acceptance testing, > its job is a lot easier with 1 cipher, than with 5 or 15. Since when did the ease of the job become and issue? Why should we care how hard it is? The only think worth considering is the value of the result. A single selection is vastly less valuable (to the USG as well as the security world) than a set of ciphers. Besides, even if acceptance testing _were_ the goal, which it is not, it's not that hard. It's an engineering problem. You give it to an engineer and he solves it. It cannot be made harder than that.
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: 23 Oct 1999 15:04:20 GMT From: djohn37050@aol.com (DJohn37050) Message-ID: <19991023110420.02050.00000283@ng-fa1.aol.com> References: <7urdi4$op0$1@blowfish.isaac.cs.berkeley.edu> Newsgroups: sci.crypt Lines: 3 Yes, my take is that NIST should say there are multiples winners and let the market sort it out. Don Johnson
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Sat, 23 Oct 1999 10:52:40 -0700 From: "Roger Schlafly" <real@ieee.org> Message-ID: <7usske$2oif@enews3.newsguy.com> References: <19991023110420.02050.00000283@ng-fa1.aol.com> Newsgroups: sci.crypt Lines: 12 DJohn37050 <djohn37050@aol.com> wrote in message news:19991023110420.02050.00000283@ng-fa1.aol.com... > Yes, my take is that NIST should say there are multiples winners and let the > market sort it out. Why should NIST even be involved at all? You seem to have a theory that more ciphers are always better, so why not let anyone use any cipher he wants, and "let the market sort it out"?
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Sat, 23 Oct 1999 12:42:48 -0600 From: jgfunj@vgrknf.arg (wtshaw) Message-ID: <jgfunj-2310991242490001@dial-243-032.itexas.net> References: <7urdi4$op0$1@blowfish.isaac.cs.berkeley.edu> Newsgroups: sci.crypt Lines: 11 In article <7urdi4$op0$1@blowfish.isaac.cs.berkeley.edu>, daw@blowfish.isaac.cs.berkeley.edu (David Wagner) wrote: > Ok, now we're back to the problem of detecting when the opponent has > broken our cipher. > The opponent will likely not tell, and will seek to cover information recovered with another and believable source. -- SSL isn't.
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Sat, 23 Oct 1999 08:38:28 -0400 From: "Trevor Jackson, III" <fullmoon@aspi.net> Message-ID: <3811AC44.EE814058@aspi.net> References: <MPG.127acf919169e8c98974d@news.mindspring.com> Newsgroups: sci.crypt Lines: 34 Jerry Coffin wrote: > Now, there some people have proposed ordering the ciphers in the > standard -- I.e. the standard itself say something to the effect that: > "here are algorithms 1, 2 and 3" and they'd be used in that order. I > don't agree with this approach. I believe AES should stick to > algorithms, not protocols. Protocols are (at least IMO) an entirely > separate kettle of fish from algorithms, and should be kept separate > both in the implementation and the standards -- right now FIPS 46-2 > describes a single algorithm; other standards deal with how to do > chaining, how to do protocols, etc., and I think that's the way things > should stay. The one place you'd see something in AES that deal with > algorithm selection would be a bit like the progression from FIPS 46-2 > to FIPS 46-3 -- this changes the recommendation from DES to 3DES. In > a later version of AES, there might be a change from (say) three > algorithms to two if one of the existing algorithms was found to have > a substantial weakness. > > The basic difference would be that in the AES, there would be more > than one algorithm described -- nothing more. Nothing about which one > is preferred, how to pick between them, negotiate usage, etc. > Ultimately, ensuring interoperability goes WELL beyond the algorithm, > and does NOT belong in AES, IMO. One proposal has suggested that one > particular algorithm be chosen to include in all possible AES > implementations. IMO, this would be pointless since it's still far to > weak to ensure anything approaching interoperability (just as the > single algorithm in DES doesn't ensure interoperability between > products). This logic leaves me no choice. I am forced to agree. The "output" of hte AES contest chold be a set of ciphers. NMNL.
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Fri, 22 Oct 1999 23:58:43 -0400 From: "Trevor Jackson, III" <fullmoon@aspi.net> Message-ID: <38113273.CCB2D39C@aspi.net> References: <7uqvg9$ol1$1@blowfish.isaac.cs.berkeley.edu> Newsgroups: sci.crypt Lines: 95 David Wagner wrote: > In article <MPG.127a8eb5cdf3aebe98974a@news.mindspring.com>, > Jerry Coffin <jcoffin@taeus.com> wrote: > > Your suggestion seems to be that since you MAY not know when you have > > a problem, that it's best to stick your head in the sand and simply > > assume that you'll never have a problem, at least in this area. > > That's not what I said at all. Please try to understand my reasoning > before dismissing it out of hand; there may be a fatal flaw in my > arguments, but I don't think this is it. > > > > I think it is more prudent to assume that if you select somehow from a > > > list of five algorithms for each connection, you may end up with a system > > > that is only as strong as the weakest of the five algorithms. > > > > WHY? I've already suggested a method that, AT WORST is at least as > > strong as the method you suggest. > > Maybe it is, maybe it isn't. > > That's a very strong claim; I'd like to show that it's not only wrong, > but it's backwards. Watch closely. > > Suppose unbeknownst to us, one of the AES finalists ("the lemon") is > fatally flawed, but the rest are totally strong. In other words, let's > assume that our adversaries are able to read traffic encrypted under > "the lemon", but we don't realize this. > > Now, there are two ways we could have designed our cryptosystems: > > 1. Scenario: We picked one lucky finalist as the single AES winner. > That cipher, and no other, becomes deployed everywhere. > > Risk: If we pick "the lemon" as our winner, all of traffic is readable. > > Expected result: With probability at most 1/5, all our traffic > is readable. With prob. at least 4/5, all our traffic is secure. > > 2. Scenario: All five finalists were designed as winners; the idea is > that, for each new connection, one picks a new key at random _and_ > a new cipher (from the five finalists) at random. This is what is > done in deployed systems worldwide. > > Risk: Every connection that uses "the lemon" is insecure. > > Expected result: With probability 1, exactly 1/5 of our traffic can > be read by the adversary. > Tell me if I'm wrong, but I think #2 summarizes your suggested approach, > and #1 summarizes the "conventional wisdom" approach. #2 is not a valid summary of his suggestion. You assumed that all five ciphers were in use. He assumed serial use of multiple ciphers. I.e., only one cipher is in use, similar to #1 above. But in the case that a sour taste is detected, all traffic switches to another cipher. This variant, #1+switching, is clearly superior to the original #1. > > > Let's compare the two approaches. I claim that #1 is a much better > situation to be in. Consider: In many cases when we send the same > confidential data across multiple connections. > > For instance, if we want to keep it a secret that our company is about > to be bought out by Microsoft, we might have lots of encrypted telephone > conversations where company employees discuss the impact of that amongst > themselves. If the adversary is able to break the encryption associated > with any one of those phone conversations, he has all the information > we wanted to hide, and we lose lots of money; from our point of view, if > he can crack one of them, it's as bad as if he could crack them all. > > Now it should become clear why approach #1 is preferable. In scenario > #2, if we have dozens of conversations about the impending buyout, we > can be sure that at least one of those conversations will have used > "the lemon" and thus will be exposed. Thus, in scenario #2, we are guaranteed > to get screwed and to lose money. In contrast, in scenario #1, we lose > money only if NIST got unlucky when picking a winner for the AES. Thus, > in scenario #1, we have at most a 1/5 probability of getting screwed. > > Personally, I'd rather take the <= 1/5 probability of getting screwed > than take the scenario where I'm guaranteed to get screwed! > > Now let's compare to what you claimed. You claimed (if I understand > correctly) that #2 is "AT WORST" at least as strong as #1. Yet it should > now be clear that #2 is weaker than #1: substantially weaker, even. > > In fact, I'd claim that you have the statement backwards: the correct > statement is "scenario #1 (picking a single winner) is AT WORST at least > as strong as scenario #2 (picking multiple winners), and probably stronger". > > So, where did I go wrong?
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Sat, 23 Oct 1999 11:04:11 +0200 From: Mok-Kong Shen <mok-kong.shen@t-online.de> Message-ID: <38117A0B.48803CF9@t-online.de> References: <7uqvg9$ol1$1@blowfish.isaac.cs.berkeley.edu> Newsgroups: sci.crypt Lines: 34 David Wagner wrote: > > Suppose unbeknownst to us, one of the AES finalists ("the lemon") is > fatally flawed, but the rest are totally strong. In other words, let's > assume that our adversaries are able to read traffic encrypted under > "the lemon", but we don't realize this. > > Now, there are two ways we could have designed our cryptosystems: > > 1. Scenario: We picked one lucky finalist as the single AES winner. > That cipher, and no other, becomes deployed everywhere. > > Risk: If we pick "the lemon" as our winner, all of traffic is readable. > > Expected result: With probability at most 1/5, all our traffic > is readable. With prob. at least 4/5, all our traffic is secure. > > 2. Scenario: All five finalists were designed as winners; the idea is > that, for each new connection, one picks a new key at random _and_ > a new cipher (from the five finalists) at random. This is what is > done in deployed systems worldwide. > > Risk: Every connection that uses "the lemon" is insecure. > > Expected result: With probability 1, exactly 1/5 of our traffic can > be read by the adversary. Question: Why did you use 'at most' and 'at least' in the first paragraph above instead of 'exactly' ('exactly' is albeit used in the second paragraph cited)? Could you please explain a little bit? M. K. Shen
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: 24 Oct 1999 13:28:44 -0400 From: juola@mathcs.duq.edu (Patrick Juola) Message-ID: <7uvfkc$uoh$1@quine.mathcs.duq.edu> References: <7uqvg9$ol1$1@blowfish.isaac.cs.berkeley.edu> Newsgroups: sci.crypt Lines: 56 In article <7uqvg9$ol1$1@blowfish.isaac.cs.berkeley.edu>, David Wagner <daw@blowfish.isaac.cs.berkeley.edu> wrote: >In article <MPG.127a8eb5cdf3aebe98974a@news.mindspring.com>, >Jerry Coffin <jcoffin@taeus.com> wrote: >Now, there are two ways we could have designed our cryptosystems: > >1. Scenario: We picked one lucky finalist as the single AES winner. > That cipher, and no other, becomes deployed everywhere. > > Risk: If we pick "the lemon" as our winner, all of traffic is readable. > > Expected result: With probability at most 1/5, all our traffic > is readable. With prob. at least 4/5, all our traffic is secure. > >2. Scenario: All five finalists were designed as winners; the idea is > that, for each new connection, one picks a new key at random _and_ > a new cipher (from the five finalists) at random. This is what is > done in deployed systems worldwide. > > Risk: Every connection that uses "the lemon" is insecure. > > Expected result: With probability 1, exactly 1/5 of our traffic can > be read by the adversary. > >Tell me if I'm wrong, but I think #2 summarizes your suggested approach, >and #1 summarizes the "conventional wisdom" approach. > >Let's compare the two approaches. I claim that #1 is a much better >situation to be in. Consider: In many cases when we send the same >confidential data across multiple connections. > >For instance, if we want to keep it a secret that our company is about >to be bought out by Microsoft, we might have lots of encrypted telephone >conversations where company employees discuss the impact of that amongst >themselves. If the adversary is able to break the encryption associated >with any one of those phone conversations, he has all the information >we wanted to hide, and we lose lots of money; from our point of view, if >he can crack one of them, it's as bad as if he could crack them all. > >Now it should become clear why approach #1 is preferable. In scenario >#2, if we have dozens of conversations about the impending buyout, we >can be sure that at least one of those conversations will have used >"the lemon" and thus will be exposed. It gets worse. The exposed messages in situation #2 will provide cribs for unexposed messages and make the cryptanalysis of those messages much easier. So even if the actual secret that you wanted to keep was only sent via a "secure" method, any related messages encrypted with the "lemon" will reveal enough plaintext to sugggest probable plaintext in the "secure" message. So I think the expected result of situation #2 would be more accurately expresse that "with probability 1, more than 1/5 of our traffic can be read by the adversary." -kitten
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: 25 Oct 1999 08:08:20 +0100 From: Paul Crowley <paul@hedonism.demon.co.uk> Message-ID: <873duzlxy4.fsf@hedonism.demon.co.uk> References: <7uvfkc$uoh$1@quine.mathcs.duq.edu> Newsgroups: sci.crypt Lines: 14 juola@mathcs.duq.edu (Patrick Juola) writes: > It gets worse. The exposed messages in situation #2 will provide cribs > for unexposed messages and make the cryptanalysis of those messages > much easier. David Wagner's model assumes that only one of the five ciphers used is weak, and therefore that the others will be resistant to a known plaintext attack. If more than one is weak, I suspect this is only one of many ways that interactions between them can be used to reduce the security of the system as a whole. -- __ \/ o\ paul@hedonism.demon.co.uk Got a Linux strategy? \ / /\__/ Paul Crowley http://www.hedonism.demon.co.uk/paul/ /~\
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Sat, 23 Oct 1999 11:04:05 +0200 From: Mok-Kong Shen <mok-kong.shen@t-online.de> Message-ID: <38117A05.BF2985B5@t-online.de> References: <7uqjmb$oei$1@blowfish.isaac.cs.berkeley.edu> Newsgroups: sci.crypt Lines: 19 David Wagner wrote: > > I think it is more prudent to assume that if you select somehow from a > list of five algorithms for each connection, you may end up with a system > that is only as strong as the weakest of the five algorithms. I suppose that this has been stated before: If one randomly choose from a set of algorithms of different strength, then one has a chance of (sometimes) using the weakest algorithm. The weakness of the whole has to be weight-summed according to the probability of usage. One can of course take the standpoint that it could be catastrophical if the weakest algorithm ever gets used and hence the weakest algorithm determines everything. That's a thoroughly viable standpoint. But, if one assumes that a few of the finalists of AES are (yet) unable to be differentiated from one another in respect of strength (a scenario that I believe to be certain), then there is no weakest algorithm to be considered. M. K. Shen
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Fri, 22 Oct 1999 00:02:36 +0100 From: "Brian Gladman" <gladman@seven77.demon.co.uk> Message-ID: <940546985.6817.0.nnrp-08.c2de6a96@news.demon.co.uk> References: <7unmk8$mqh$1@nntp1.atl.mindspring.net> Newsgroups: sci.crypt Lines: 41 Roger Schlafly <real@ieee.org> wrote in message news:7unmk8$mqh$1@nntp1.atl.mindspring.net... > Brian Gladman <gladman@seven77.demon.co.uk> wrote in message > news:940501283.15899.0.nnrp-12.c2de6a96@news.demon.co.uk... > > On what experience base do you assert that satellites are a 'moronic > > example' of the practical use of encryption? Encryption on satellites is > > inevitably specilaised and hence unrepresentative of typical use. But I > > think that 'moronic' goes too far. > > I'm sorry, but I agree with Bruce. It is a moronic example. > Satellite folks do worry about catastrophic failure, but not > about AES flaws. Even if there is a security failure, it will > almost certainly not be because the AES block cipher has > some sort of weakness. There are 100s of other problems, > each of which is millions of times more likely to go wrong. From 1980 to 1988 I was responsible for the UKs defence computing and communications research programme, including satellite based systems and aspects of the UK's civil R&D programme in this field. And from 1988 to 1995 I was Director of Strategic Communications in the UK Minsistry of Defence where I directed the acquisiton of UK and NATO satellite communications systems. You are totally wrong - we did worry about the possible impact of cryptographic failures on both defence and civil satellite systems. AES algorithms were not around at the time but had they been, and had their use been contemplated, I am completely confident that the possibility that they might fail would have been on our long list of potential problems for consideration during system design and development. As I said in my previous post, the satellite example is unrepresentative of typical encryption use but to characterise it as 'moronic' goes too far. IMHO the use of such an emotive term says more about those who choose to use it than it ever does about the person (Don Johnson?) who first suggested the satellite example. Brian Gladman
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: 21 Oct 1999 23:14:56 GMT From: djohn37050@aol.com (DJohn37050) Message-ID: <19991021191456.26924.00000195@ng-bj1.aol.com> References: <940546985.6817.0.nnrp-08.c2de6a96@news.demon.co.uk> Newsgroups: sci.crypt Lines: 2 I did not come up with the satellite example, but I thot it a good one. Don Johnson
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Thu, 21 Oct 1999 23:07:46 -0700 From: "Roger Schlafly" <real@ieee.org> Message-ID: <7uouti$1blv@enews2.newsguy.com> References: <940546985.6817.0.nnrp-08.c2de6a96@news.demon.co.uk> Newsgroups: sci.crypt Lines: 19 Brian Gladman <gladman@seven77.demon.co.uk> wrote in message news:940546985.6817.0.nnrp-08.c2de6a96@news.demon.co.uk... > From 1980 to 1988 I was responsible for the UKs defence computing and > communications research programme, including satellite based systems and > ... > You are totally wrong - we did worry about the possible impact of > cryptographic failures on both defence and civil satellite systems. If you know so much about communications satellites, then I am sure you choose your words carefully. I'll bet you did worry about cryptographic failures. I hope someone did, anyway. There are a lot of possible problems -- theft of keys, leakage of key bits, broken random number generator, protocol failure, various hardware failures that might reveal too much, or lock out too much, etc. I'd lose a lot of sleep over some of these possibilities if I were in charge. But worrying about weaknesses in the AES block cipher -- NOT.
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Fri, 22 Oct 1999 13:20:14 +0100 From: "Brian Gladman" <gladman@seven77.demon.co.uk> Message-ID: <940594844.5782.0.nnrp-11.c2de6a96@news.demon.co.uk> References: <7uouti$1blv@enews2.newsguy.com> Newsgroups: sci.crypt Lines: 36 Roger Schlafly <real@ieee.org> wrote in message news:7uouti$1blv@enews2.newsguy.com... > Brian Gladman <gladman@seven77.demon.co.uk> wrote in message > news:940546985.6817.0.nnrp-08.c2de6a96@news.demon.co.uk... > > From 1980 to 1988 I was responsible for the UKs defence computing and > > communications research programme, including satellite based systems and > > ... > > You are totally wrong - we did worry about the possible impact of > > cryptographic failures on both defence and civil satellite systems. > > If you know so much about communications satellites, then I am sure > you choose your words carefully. I'll bet you did worry about > cryptographic failures. I hope someone did, anyway. There are a lot > of possible problems -- theft of keys, leakage of key bits, broken > random number generator, protocol failure, various hardware failures > that might reveal too much, or lock out too much, etc. I'd lose a lot > of sleep over some of these possibilities if I were in charge. But > worrying about weaknesses in the AES block cipher -- NOT. Precisely why should I ignore this particular possibility while considering all others? I can only assume that you are guessing that the probability of failure is sufficiently low to be ignored. Given the history of cryptography I prefer to take a more cautious approach. But returning to the main point at immediate issue, I do not consider the satellite example to be 'moronic' and nothing you have said has convinced me otherwise. And I remain disappointed that Bruce used this emotive and somewhat uncharitable term to describe it. But I see little point in continuing this debate - I am content to leave it up to others to judge whether this was an accurate characterisation. Brian Gladman
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: 22 Oct 1999 08:14:58 +0100 From: Paul Crowley <paul@hedonism.demon.co.uk> Message-ID: <87puy7hnnx.fsf@hedonism.demon.co.uk> References: <940501283.15899.0.nnrp-12.c2de6a96@news.demon.co.uk> Newsgroups: sci.crypt Lines: 11 OK, so satellites have the crypto hard-wired. This doesn't preclude the possibility of implementing a fix in software if a weakness is found in the cipher: you could perhaps change the mode of operation, the number of rounds, or the key schedule, or some similar tweak to frustrate the attack discovered. It's not what you might like best; but it's supposed to be very unlikely that an attack will be found, and it's nice to know you're not helpless if it is. -- __ \/ o\ paul@hedonism.demon.co.uk Got a Linux strategy? \ / /\__/ Paul Crowley http://www.hedonism.demon.co.uk/paul/ /~\
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Sat, 23 Oct 1999 18:26:12 GMT From: ritter@io.com (Terry Ritter) Message-ID: <3811fd8e.7643988@news.io.com> References: <87puy7hnnx.fsf@hedonism.demon.co.uk> Newsgroups: sci.crypt Lines: 41 On 22 Oct 1999 08:14:58 +0100, in <87puy7hnnx.fsf@hedonism.demon.co.uk>, in sci.crypt Paul Crowley <paul@hedonism.demon.co.uk> wrote: >OK, so satellites have the crypto hard-wired. This doesn't preclude >the possibility of implementing a fix in software if a weakness is >found in the cipher: you could perhaps change the mode of operation, >the number of rounds, or the key schedule, or some similar tweak to >frustrate the attack discovered. It's not what you might like best; >but it's supposed to be very unlikely that an attack will be found, >and it's nice to know you're not helpless if it is. In the satellite example, adding fixes to the crypto may be possible, if there are a limited number of ground stations communicating with the satellite. But when a cipher is to be used by many, to change it is to introduce incompatibilities, delays, and vast costs. And during the change-over delay we have the poor situation of no acceptable cipher at all. To avoid this, any cipher system designed for mass use should be built so that alternate ciphers can be used. And to reassure ourselves that this feature remains available, it should be used regularly. In my experience, both hardware and software often contain supposed "features" which do not work in practice, and we do not find this until we actually try to use that feature. Of course, the larger reason for changing ciphers is that we cannot (in general) know whether our cipher is broken. Clearly, using a broken cipher is not conducive to successful cryptography. So if we insist on continually using the same cipher, we may in fact continue to expose our data. If we assume that most ciphers are not broken, changing ciphers at least gives us a good chance of ending the period during which our information was exposed. Our alternative is to never end the period of exposure. --- Terry Ritter ritter@io.com http://www.io.com/~ritter/ Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: 22 Oct 1999 17:09:05 -0700 From: daw@blowfish.isaac.cs.berkeley.edu (David Wagner) Message-ID: <7uqub1$ok9$1@blowfish.isaac.cs.berkeley.edu> References: <940579277.29462.0.nnrp-11.c2de6a96@news.demon.co.uk> <7uotnb$n28$1@blowfish.isaac.cs.berkeley.edu> Newsgroups: sci.crypt Lines: 33 I temporarily mirrored my earlier posts at http://www.cs.berkeley.edu/~daw/tmp/multiple-ciphers.html The arguments are currently a bit sketchy, and need to be refined a bit before one can draw any definite conclusions about the AES. I hope to find time to get a chance to write a better presentation at some point in the future, but in the meantime I hope you'll forgive those shortcomings. I think there are one or two interesting insights that might come out of this sort of analysis (but they are still only preliminary indications, so take them with a huge grain of salt): 1. When the same information is sent in different messages (so that compromise of any one message in a group is almost as bad as compromise as all of them in the group), then putting all our eggs in one basket is a _good_ idea. Using a different cipher to encrypt every message in the group runs the risk that we'll get only the strength of the weakest of the ciphers, which is undesirable. 2. When we can make some informed guesses at the relative ranking of the available ciphers (with regard to security) and gain any advantage over random coin flipping, it is to our advantage to exploit that information rather than merely selecting ciphers at random. 3. It's better to focus all our cryptanalysis resources on one cipher, rather than to split it up among ciphers. Ideally we'd like a cipher that we can be sure is safe; of course we'll never attain that ideal, but we'd do well to try to come as close to it as possible. The problem becomes most acute when the adversary's analysis resources are much greater than our own---in this case, it is in our interests to narrow the analysis gap as much as possible by focusing all our attention on analysis of one cipher, to gain as much assurance as possible. These claims are all stated in an informal, intuitive, and non-rigorous style, but in some sense they are at least somewhat backed up by the quantitative analysis I did (at least, if you believe that my model is representative).
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Fri, 22 Oct 1999 23:51:36 -0400 From: "Trevor Jackson, III" <fullmoon@aspi.net> Message-ID: <381130C8.69ED831@aspi.net> References: <7uqub1$ok9$1@blowfish.isaac.cs.berkeley.edu> Newsgroups: sci.crypt Lines: 74 David Wagner wrote: > I temporarily mirrored my earlier posts at > http://www.cs.berkeley.edu/~daw/tmp/multiple-ciphers.html > The arguments are currently a bit sketchy, and need to be refined a bit > before one can draw any definite conclusions about the AES. I hope to > find time to get a chance to write a better presentation at some point > in the future, but in the meantime I hope you'll forgive those shortcomings. > > I think there are one or two interesting insights that might come out > of this sort of analysis (but they are still only preliminary indications, > so take them with a huge grain of salt): > 1. When the same information is sent in different messages (so that > compromise of any one message in a group is almost as bad as compromise > as all of them in the group), then putting all our eggs in one > basket is a _good_ idea. Using a different cipher to encrypt every > message in the group runs the risk that we'll get only the strength > of the weakest of the ciphers, which is undesirable. > 2. When we can make some informed guesses at the relative ranking of > the available ciphers (with regard to security) and gain any advantage > over random coin flipping, it is to our advantage to exploit that > information rather than merely selecting ciphers at random. > 3. It's better to focus all our cryptanalysis resources on one cipher, > rather than to split it up among ciphers. Ideally we'd like a cipher > that we can be sure is safe; of course we'll never attain that ideal, > but we'd do well to try to come as close to it as possible. The > problem becomes most acute when the adversary's analysis resources > are much greater than our own---in this case, it is in our interests > to narrow the analysis gap as much as possible by focusing all our > attention on analysis of one cipher, to gain as much assurance as > possible. Items 1 & 2 appear sensible, but I suspect they harbor some illusions about our knowledge of cipher strength. In the case of 2, for example, if the best we can do is guess about the relative ranking of ciphers, then we're guessing whether there is a best cipher within a given set, and further guessing that we are able to detect that superlative. I.e., we might be fooling ourselves about the degree to which one cipher is stronger than another, and in pursuit of a guess, forego some of the benefits of diversity. Item 3 is clearly a philosophical issue that may not be resolvable. It is an issue worth exploring. But I must take exception to the concluding remark. I dispute that any amout of concentrated analysis of one cipher gives us any assurance as to it's strength. We can only report failure to find weakness. Like being judged Not Guilty by a Court, it cannot be transformed into any kind of endorsement. Personally I agree that some concentration of effort is useful because if there is a weakness that can be found with a reasonable amout of work we'll increase the chances that we find the easy weaknesses and thus weed out clearly bad ciphers. Evolution is not based on the popular phrase "survival of the fittest". It is based on the death, or non-reproduction, of the unfit. Thus, rather than chase a grail (show a cipher strong), I prefer to preserve a [small] set of ciphers as viable options, concentrating on eliminating from the set those that don't belong there. Consider that concentrating all available effort on a single candidate might backfire. After all that effort isn't aimed at "strengthening" the cipher but at finding a weakness in it. We know it cannot show the candidate strong, but a successful concentration of effort might show it weak. What do we do then? The can't win/might lose outcome of this approach appears to be improvable. > These claims are all stated in an informal, intuitive, and non-rigorous > style, but in some sense they are at least somewhat backed up by the > quantitative analysis I did (at least, if you believe that my model is > representative). I have not read your analyses yet, but I will do so. Do you believe the results of your analysis are testable? Reproducible?
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Sat, 23 Oct 1999 09:23:00 -0400 From: "Trevor Jackson, III" <fullmoon@aspi.net> Message-ID: <3811B6B4.A5FA99EC@aspi.net> References: <7uqub1$ok9$1@blowfish.isaac.cs.berkeley.edu> Newsgroups: sci.crypt Lines: 22 David Wagner wrote: > I temporarily mirrored my earlier posts at > http://www.cs.berkeley.edu/~daw/tmp/multiple-ciphers.html > The arguments are currently a bit sketchy, and need to be refined a bit > before one can draw any definite conclusions about the AES. I hope to > find time to get a chance to write a better presentation at some point > in the future, but in the meantime I hope you'll forgive those shortcomings. > I response to the above referenced paper, my only comment is that the model you've proposed lacks any characterization of the dilution effect of multiple ciphers upon adversarial resource allocation. In particular the assumption that the probability of a break is monotonicly related to the effort spent on designing and testing it and independent of the effort spent on cracking it. This assumption appears to be dangerously close to the Labor Theory of Value. I believe it to be false. Thus, since I question the foundation of the model, I do not credit the conclusions with any signifigance.
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: 26 Oct 1999 11:44:08 -0700 From: daw@blowfish.isaac.cs.berkeley.edu (David Wagner) Message-ID: <7v4spo$pt6$1@blowfish.isaac.cs.berkeley.edu> References: <3811B6B4.A5FA99EC@aspi.net> Newsgroups: sci.crypt Lines: 19 In article <3811B6B4.A5FA99EC@aspi.net>, Trevor Jackson, III <fullmoon@aspi.net> wrote: > I response to the above referenced paper, my only comment is that the model > you've proposed lacks any characterization of the dilution effect of multiple > ciphers upon adversarial resource allocation. In particular the assumption that > the probability of a break is monotonicly related to the effort spent on > designing and testing it and independent of the effort spent on cracking it. Yes, you're absolutely right. I had in mind the implicit assumption that that adversary's analysis resources would be so much larger than ours that they could be considered essentially infinite, or at least large enough that dilution effects still were negligible -- so that, if a cipher had a hole, the adversary would find it. I suppose this is in line with the tradition of making conservative assumptions about the adversary's capabilities, although it might cause inaccuracies for the modelling purposes. Thanks for pointing that out. At the very least, it is an assumption which should have been made explicit; moreover, it seems to be a partial limitation of the model. I appreciate the feedback.
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Sat, 23 Oct 1999 22:53:02 GMT From: ritter@io.com (Terry Ritter) Message-ID: <38123c48.23637250@news.io.com> References: <7uqub1$ok9$1@blowfish.isaac.cs.berkeley.edu> Newsgroups: sci.crypt Lines: 172 On 22 Oct 1999 17:09:05 -0700, in <7uqub1$ok9$1@blowfish.isaac.cs.berkeley.edu>, in sci.crypt daw@blowfish.isaac.cs.berkeley.edu (David Wagner) wrote: >I temporarily mirrored my earlier posts at > http://www.cs.berkeley.edu/~daw/tmp/multiple-ciphers.html >The arguments are currently a bit sketchy, and need to be refined a bit >before one can draw any definite conclusions about the AES. I hope to >find time to get a chance to write a better presentation at some point >in the future, but in the meantime I hope you'll forgive those shortcomings. This appears to be the same old stuff to which I have already replied in detail. Oddly, you do not seem to give the opposing arguments equal space on your web page. You thus leave the false impression that the only serious opposition arguments were those you addressed, and you did not quote those arguments. You have made a biased presentation of a biased thesis. That is not a good start. >I think there are one or two interesting insights that might come out >of this sort of analysis (but they are still only preliminary indications, >so take them with a huge grain of salt): >1. When the same information is sent in different messages (so that > compromise of any one message in a group is almost as bad as compromise > as all of them in the group), then putting all our eggs in one > basket is a _good_ idea. Using a different cipher to encrypt every > message in the group runs the risk that we'll get only the strength > of the weakest of the ciphers, which is undesirable. As I have shown before, this silently assumes that we know something about the strength of the cipher which is the unstated alternative. In order to use the term "good" we must compare one alternative with the other. In order to make a comparison, we must examine the alternatives. When we do, we see that the one cipher we might use could be the weakest of them all. And this can happen even if a break is known for every other cipher except the one we choose. The result in that case is that we will continue to use that same weak cipher forever. Shall we postulate a distribution of various strengths in the ciphers, and then the probability of having such-and-such strength? Surely the expectation from choosing the one cipher at random would be the same as moving among all the ciphers at random. In any case, such a strengths of ciphers we would use. We do not know the strengths, we do not even know that any of the ciphers has any strength at all. We can of course *assume* strength, but then the assumptions become our results. On the other hand, there are consequences of choosing one cipher which are *not* in question: For one thing, having a single cipher means that the majority of worthwhile communications are protected by that one cipher. The selected cipher thus becomes the ideal single target for opposition research. Far more effort will be spent on trying to break the cipher by people who will not reveal their results than was ever spent by academics during the original vetting. To the extent that effort implies looking for -- and thus, occasionally finding -- previously unknown weakness, having any single cipher sets up the ideal situation for that cipher to be broken in secret. And setting us up to use a cipher which is broken, but which we do not know is broken, is the worst possible kind of cryptography. Another consequence of choosing one cipher is that cipher systems using that cipher need support only one cipher. This means that even if academics discover the cipher is weak, the fielded systems will generally have no easy way to switch to another cipher, and there will be tremendous financial pressure to hide or simply ignore any such results. The result of course is a weakening of the communications structure which cryptography was introduced to avoid. I claim that unless these issues are included in the model, the model cannot be expected to provide any insight into reality. >2. When we can make some informed guesses at the relative ranking of > the available ciphers (with regard to security) and gain any advantage > over random coin flipping, it is to our advantage to exploit that > information rather than merely selecting ciphers at random. Clearly, in any system which selects among ciphers for use, we only use ciphers which are not known to be broken. Therefore, we have no information about strength for any of the ciphers we do use. I would argue that while there can of course be "guesses" with respect to strength, there simply ARE NO "*informed* guesses." This is because strength occurs in the context of the abilities of our opponent, and we do not know that context. Thus you are assuming information which does not (and I think *can* not) exist. No scientific basis exists for extrapolating from any tests of weakness which have been applied, to other -- unknown -- tests of weakness. There is no scientific basis for "informed" guesses about ciphers which have passed all tests. Indeed, I would argue that even known weaknesses which are impractical are generally irrelevant to real use. >3. It's better to focus all our cryptanalysis resources on one cipher, > rather than to split it up among ciphers. Ideally we'd like a cipher > that we can be sure is safe; of course we'll never attain that ideal, > but we'd do well to try to come as close to it as possible. This may in fact be the essence of the opposition to the multiple-cipher model. But it is false. We have no measure for cipher strength. We have no indication whether additional effort has brought us "nearer" to a result or not. Added resources may be doing *something*, but we have no idea whether that "something" is progressing toward exposing a flaw or not. We have no understanding of the size of the search space, and so have no idea what proportion of it we have addressed. Frankly, it does not matter how much effort we put into analyzing a cipher, if we do not find a weakness and our opponents do. There is no scientific basis for assuming that our efforts will be rewarded proportionally, or even at all. Cryptanalysis simply does not testify about the strength of ciphers which have no known weakness. And if we do have only one cipher, and continue the examination after selection, when we get results we have to either contend with changing a massive installed base, or keep quiet about a true weakness. In either case, this sets up cryptanalysts as the "fall guys." >The > problem becomes most acute when the adversary's analysis resources > are much greater than our own---in this case, it is in our interests > to narrow the analysis gap as much as possible by focusing all our > attention on analysis of one cipher, to gain as much assurance as > possible. An "analysis gap" implies some form of quantification. Two things come to mind: effort, and results. If the issue is effort, we have no hope that a handful of academics, working from basically their own grants, can possibly approach the work which will be put into breaking a standard cipher. I would expect that the sum of all opposing efforts would be orders of magnitude above anything academics can do during the vetting process. And the more information which is protected by that cipher, the more resources will be made available to attack it. Further, these attack attempts will continue over a much longer period than the original vetting. Any attempt to try to "narrow" the gap is thus completely unrealistic. If the issue is results, we only get results on *weakness*. So the instant we get any serious results on a cipher, that cipher becomes undesirable. If that happens to the standard cipher, what do we do? What are the costs of switching, what will the delays be, and what will be the situation during those delays? These costs are incurred by the choice of a single cipher, do not occur with systems which naturally change ciphers, and so the costs should appear in any comparison between the two approaches. >These claims are all stated in an informal, intuitive, and non-rigorous >style, but in some sense they are at least somewhat backed up by the >quantitative analysis I did (at least, if you believe that my model is >representative). Not only do *I* not so believe, it is hard to imagine that *anyone* could possibly believe that your model represents useful reality. Trust me: You do not want to publish this. --- Terry Ritter ritter@io.com http://www.io.com/~ritter/ Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: 26 Oct 1999 11:59:14 -0700 From: daw@blowfish.isaac.cs.berkeley.edu (David Wagner) Message-ID: <7v4tm2$puf$1@blowfish.isaac.cs.berkeley.edu> References: <38123c48.23637250@news.io.com> Newsgroups: sci.crypt Lines: 21 In article <38123c48.23637250@news.io.com>, Terry Ritter <ritter@io.com> wrote: > This appears to be the same old stuff to which I have already replied > in detail. Oddly, you do not seem to give the opposing arguments > equal space on your web page. Yes, you're right. You (and several others) have given some excellent feedback which has definitely helped me, and which was not directly incorporated into that web page. But the goal wasn't to provide a comprehensive survey of the strengths and weaknesses of the model. (I have to leave that for later, due to lack of time.) It was just intended as a quick "5-minute" hack to provide a relatively brief introduction to the proposed model, with a pointer to more extensive discussion on it on Dejanews. I don't have time for more. It's not clear to me how this demonstrates some sort of bias on my part, but I apologize if I caused any confusion. As to the rest of your comments in this post, we've already discussed them in detail, as you say, so I'm not convinced that replying will really advance the discussion much. Still, if I get a chance, I'll try to reply.

Terry Ritter, his current address, and his top page.

Last updated: 2001-06-05