One problem we have with commercial cryptography is that of assuring that the cipher we think we get does not also include ways to expose our keys or data. Software is thought to be a problem, because it so easily can be changed at any time, so hardware is thought to be a solution. Unfortunately, while we can at least hope to inspect software source code, we will not be able to inspect a chip design. We thus cannot know whether or not anything else is on the chip, and that is a fundamental problem.
In this discussion I suggest exhaustive testing of scaled-down designs, but even that is unlikely to expose everything. As one writer notes, even if the chip does not create extra data, a particular plaintext value could switch the encryption off, or make it trivial.
We would like to use chips for ciphering because they cannot be changed by our opponents, but we cannot use those chips because we cannot show that the chip itself does not reveal our keys or data.
Subject: Re: Retail distributors of DES chips? Date: Fri, 26 May 2000 08:07:15 +0100 From: David Hopwood <hopwood@zetnet.co.uk> Message-ID: <392E22A3.7047BB1A@zetnet.co.uk> References: <slrn8iqcbm.872.mdw@mull.ncipher.com> <8ggtvr$gfc$1@nnrp1.deja.com> Newsgroups: sci.crypt Lines: 54 -----BEGIN PGP SIGNED MESSAGE----- Mark Wooding wrote: > Tom St Denis <stdenis@compmore.net> wrote: > > > That's not true. This cipher could simply be > > > > Ek(P) = P xor K > > > > unless you test it. > > Yes, but the point is that, in theory, DES is completely deterministic. > If you have a DES chip, you can feed known keys and plaintexts in it, > and verify that you get the right answers against some other known and > trusted implementation. You can even give it `trick questions' every > now and then while it's in production use, checking its results, to make > sure it's not randomly deciding to emit leaked key material instead of > giving the right answers every now and then. I'd hope that most serious > users of black-box cryptography hardware or software did something like > this. Testing isn't sufficient. Consider: DES'[K](P) = DES[K](P), if P != backdoor = K, if P == backdoor Then with a single chosen plaintext, the key is revealed. Assuming the backdoor plaintext is chosen randomly, no amount of testing that takes less than 2^63 expected work will find it. > With DSA, if you don't trust the hardware, you're stuffed. Indeed, but that's just as true for any other algorithm - it's just a little bit more involved for someone to work out how to stuff you. - - -- David Hopwood <hopwood@zetnet.co.uk> PGP public key: http://www.users.zetnet.co.uk/hopwood/public.asc RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01 -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv iQEVAwUBOS4ieDkCAxeYt5gVAQHOUQf8DAJuAiDxIHLRNvbijTsAuzC8VIMALsvx ZRD5YX9XhVSIERnaGcB5VTzsbJVfwXfjG5BqTHf6CamR6pCP3SWPdEHNU1sVBdVd U7vjOqYHUd7aIP+t6MTHx1/oswc/IowMfJ53DUoqYwHhKnKX/oWpZBhucz8EpcVZ sxaXdGLL0AKzwQhrKDAkvGrH87WJOqynF/UP06tCJGl2ydJ0SNK319IlK6UOZ0+t bDfNxNPtA9lLgRbm/gJzrcF67z+TLUFjNnO7wz0J2VDgIllH5QDfg6cfHkcHMZFG 0JcyarBUxiqUsV9Aa9icM27HGTN5AqkQes6OuRQbPjGNthOyzZTwMQ== =3cHu -----END PGP SIGNATURE-----
Subject: Re: Retail distributors of DES chips? Date: 26 May 2000 08:34:03 GMT From: mdw@nsict.org (Mark Wooding) Message-ID: <slrn8isdnq.872.mdw@mull.ncipher.com> References: <392E22A3.7047BB1A@zetnet.co.uk> Newsgroups: sci.crypt Lines: 12 David Hopwood <hopwood@zetnet.co.uk> wrote: > Then with a single chosen plaintext, the key is revealed. Assuming the > backdoor plaintext is chosen randomly, no amount of testing that takes > less than 2^63 expected work will find it. True. Bleugh. Moral: make sure that everything which does cryptography for you is trustworthy. -- [mdw]
Subject: Re: Retail distributors of DES chips? Date: Tue, 30 May 2000 11:31:50 GMT From: ritter@io.com (Terry Ritter) Message-ID: <3933a63e.4824026@news.io.com> References: <slrn8isdnq.872.mdw@mull.ncipher.com> Newsgroups: sci.crypt Lines: 26 On 26 May 2000 08:34:03 GMT, in <slrn8isdnq.872.mdw@mull.ncipher.com>, in sci.crypt mdw@nsict.org (Mark Wooding) wrote: >David Hopwood <hopwood@zetnet.co.uk> wrote: > >> Then with a single chosen plaintext, the key is revealed. Assuming the >> backdoor plaintext is chosen randomly, no amount of testing that takes >> less than 2^63 expected work will find it. > >True. Bleugh. > >Moral: make sure that everything which does cryptography for you is >trustworthy. But how shall we measure this "trustworthy" property so we can "make sure" that it exists? There is an alternative, and I have been promoting it for several years: Use *scalable* cipher designs, so we can perform an extensive or even exhaustive analysis of the tiny scaled-down version. --- Terry Ritter ritter@io.com http://www.io.com/~ritter/ Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
Subject: Re: Retail distributors of DES chips? Date: 30 May 2000 11:43:35 GMT From: mdw@nsict.org (Mark Wooding) Message-ID: <slrn8j7ab3.2gd.mdw@mull.ncipher.com> References: <3933a63e.4824026@news.io.com> Newsgroups: sci.crypt Lines: 16 Terry Ritter <ritter@io.com> wrote: > But how shall we measure this "trustworthy" property so we can "make > sure" that it exists? > > There is an alternative, and I have been promoting it for several > years: Use *scalable* cipher designs, so we can perform an extensive > or even exhaustive analysis of the tiny scaled-down version. Sorry to interrupt while you're on your hobby horse, Terry, but I was referring to *implementations* of existing cipher designs. The discussion in hand is about the possibility of hardware implementations of strong (as a matter of hypothesis) having been deliberately compromised by the vendor. Cipher design doesn't help here. -- [mdw] Bytes: 2293
Subject: Re: Retail distributors of DES chips? Date: Tue, 30 May 2000 08:45:43 -0700 From: ritter <ritterNOriSPAM@io.com.invalid> Message-ID: <04c7825c.2cf14a2f@usw-ex0101-005.remarq.com> References: <slrn8j7ab3.2gd.mdw@mull.ncipher.com> Newsgroups: sci.crypt Lines: 63 In article <slrn8j7ab3.2gd.mdw@mull.ncipher.com>, mdw@nsict.org (Mark Wooding) wrote: >Terry Ritter <ritter@io.com> wrote: > >> But how shall we measure this "trustworthy" property so we can "make >> sure" that it exists? >> >> There is an alternative, and I have been promoting it for several >> years: Use *scalable* cipher designs, so we can perform an extensive >> or even exhaustive analysis of the tiny scaled-down version. > >Sorry to interrupt while you're on your hobby horse, Terry, but I was >referring to *implementations* of existing cipher designs. Oh, well, if "implementation" is the distinction, then perhaps you will tell us just how you *test* for the "trustworthy" property in *implementations*. Or maybe your idea of "trustworthy" is the real hobby-horse ride being so rudely interrupted. >The >discussion in hand is about the possibility of hardware implementations >of strong (as a matter of hypothesis) having been deliberately >compromised by the vendor. Cipher design doesn't help here. "Software" is just another name for the customization of hardware digital systems. In general, when we want a complete understanding of what is present in a digital system, we must have exhaustive tests. Such tests are impossible in real size cipher systems, either hardware or software. Only tiny systems allow exhaustive tests, only scalable ciphers allow us to build tiny systems directly related to real ones, and only exhaustive testing allows us to know that nothing else is there. Perhaps that is clearer now. That said, I think we can test a cipher chip to a software implementation, using the property that we have a particular 1:1 transformation, and that no more information comes out than goes in. But that means the chip cannot pick any "random" system-level values (no message keys, no IV's). It also means that if *the* *cipher* is exposing key in the structure of the ciphering itself, we will not find that. Ooops! --- Terry Ritter ritter@io.com http://www.io.com/~ritter/ Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM * Sent from RemarQ http://www.remarq.com The Internet's Discussion Network * The fastest and easiest way to search and participate in Usenet - Free! Bytes: 2179
Subject: Re: Retail distributors of DES chips? Date: Tue, 30 May 2000 08:55:34 -0700 From: tomstd <tomNOtoSPAM@dasoft.org.invalid> Message-ID: <2549eb78.5e41e319@usw-ex0104-032.remarq.com> References: <04c7825c.2cf14a2f@usw-ex0101-005.remarq.com> Newsgroups: sci.crypt Lines: 63 In article <04c7825c.2cf14a2f@usw-ex0101-005.remarq.com>, ritter <ritterNOriSPAM@io.com.invalid> wrote: > >In article <slrn8j7ab3.2gd.mdw@mull.ncipher.com>, mdw@nsict.org >(Mark Wooding) wrote: >>Terry Ritter <ritter@io.com> wrote: >> >>> But how shall we measure this "trustworthy" property so we can >"make >>> sure" that it exists? >>> >>> There is an alternative, and I have been promoting it for >several >>> years: Use *scalable* cipher designs, so we can perform an >extensive >>> or even exhaustive analysis of the tiny scaled-down version. >> >>Sorry to interrupt while you're on your hobby horse, Terry, but >I was >>referring to *implementations* of existing cipher designs. > >Oh, well, if "implementation" is the distinction, >then perhaps you will tell us just how you *test* for >the "trustworthy" property in *implementations*. > >Or maybe your idea of "trustworthy" is the real >hobby-horse ride being so rudely interrupted. > > >>The >>discussion in hand is about the possibility of hardware >implementations >>of strong (as a matter of hypothesis) having been deliberately >>compromised by the vendor. Cipher design doesn't help here. > >"Software" is just another name for the >customization of hardware digital systems. In >general, when we want a complete understanding of >what is present in a digital system, we must have >exhaustive tests. Such tests are impossible in real >size cipher systems, either hardware or software. >Only tiny systems allow exhaustive tests, only >scalable ciphers allow us to build tiny systems >directly related to real ones, and only exhaustive >testing allows us to know that nothing else is there. > >Perhaps that is clearer now. Yup it's clear you are not answering the question. His question was the possibility of DES being fudge-up by some naughty person. Not whether DES was strong or not, whether the CHIP was. Not like you do bad work, but you are plugging it in the wrong spot my friend. Tom * Sent from RemarQ http://www.remarq.com The Internet's Discussion Network * The fastest and easiest way to search and participate in Usenet - Free! Bytes: 3509
Subject: Re: Retail distributors of DES chips? Date: Tue, 30 May 2000 14:56:45 -0700 From: ritter <ritterNOriSPAM@io.com.invalid> Message-ID: <13f3a7dc.c18ca6c1@usw-ex0105-040.remarq.com> References: <2549eb78.5e41e319@usw-ex0104-032.remarq.com> Newsgroups: sci.crypt Lines: 97 In article <2549eb78.5e41e319@usw-ex0104-032.remarq.com>, tomstd <tomNOtoSPAM@dasoft.org.invalid> wrote: >In article <04c7825c.2cf14a2f@usw-ex0101-005.remarq.com>, ritter ><ritterNOriSPAM@io.com.invalid> wrote: >> >>In article <slrn8j7ab3.2gd.mdw@mull.ncipher.com>, mdw@nsict.org >>(Mark Wooding) wrote: >>>Terry Ritter <ritter@io.com> wrote: >>> >>>> But how shall we measure this "trustworthy" property so we >can >>"make >>>> sure" that it exists? >>>> >>>> There is an alternative, and I have been promoting it for >>several >>>> years: Use *scalable* cipher designs, so we can perform an >>extensive >>>> or even exhaustive analysis of the tiny scaled-down version. >>> >>>Sorry to interrupt while you're on your hobby horse, Terry, but >>I was >>>referring to *implementations* of existing cipher designs. >> >>Oh, well, if "implementation" is the distinction, >>then perhaps you will tell us just how you *test* for >>the "trustworthy" property in *implementations*. >> >>Or maybe your idea of "trustworthy" is the real >>hobby-horse ride being so rudely interrupted. >> >> >>>The >>>discussion in hand is about the possibility of hardware >>implementations >>>of strong (as a matter of hypothesis) having been deliberately >>>compromised by the vendor. Cipher design doesn't help here. >> >>"Software" is just another name for the >>customization of hardware digital systems. In >>general, when we want a complete understanding of >>what is present in a digital system, we must have >>exhaustive tests. Such tests are impossible in real >>size cipher systems, either hardware or software. >>Only tiny systems allow exhaustive tests, only >>scalable ciphers allow us to build tiny systems >>directly related to real ones, and only exhaustive >>testing allows us to know that nothing else is there. >> >>Perhaps that is clearer now. > >Yup it's clear you are not answering the question. > >His question was the possibility of DES being fudge-up by some >naughty person. Not whether DES was strong or not, whether the >CHIP was. Really? Well, here it is: >>>>>Well, One of the things I have been considering is the >>>>>possibility of malicious software. >>>>>That's why I was considering using a chip. >>>>>That way there is absolutely no possibility >>>>>that anythink will be placed in any >>>>>subliminal channels. The issue I have addressed is the idea that "there is absolutely no possibility" of a subliminal channel on a chip. That is false, thus making the only real advantage of hardware that new subliminal channels are unlikely to be added -- unless of course there is a programmable subsection that we don't know about. What we really want is a cipher subsystem -- hardware or software -- which demonstrably produces no more data than we send to it. To assure this, we might send in a buffer of data, and then use that same buffer with the original length as the result. There must be (at this level) no subsystem-selected or produced random values. >Not like you do bad work, but you are plugging it in the wrong >spot my friend. Really? Perhaps you have a deeper insight you would like to share with us. --- Terry Ritter ritter@io.com http://www.io.com/~ritter/ Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM * Sent from RemarQ http://www.remarq.com The Internet's Discussion Network * The fastest and easiest way to search and participate in Usenet - Free!
Subject: Re: Retail distributors of DES chips? Date: Wed, 31 May 2000 02:34:29 GMT From: zapzing <zapzing@my-deja.com> Message-ID: <8h1tnk$bra$1@nnrp1.deja.com> References: <13f3a7dc.c18ca6c1@usw-ex0105-040.remarq.com> Newsgroups: sci.crypt Lines: 143 Well first of all I would like to say how flattered I am that you boys are haveing a flame war over me. Oh, what the heck, I *will* say it. I'm flattered that you boys are haveing a flame war over me. Now on to the meatier issues. In article <13f3a7dc.c18ca6c1@usw-ex0105-040.remarq.com>, ritter <ritterNOriSPAM@io.com.invalid> wrote: > In article <2549eb78.5e41e319@usw-ex0104-032.remarq.com>, tomstd > <tomNOtoSPAM@dasoft.org.invalid> wrote: > >In article <04c7825c.2cf14a2f@usw-ex0101-005.remarq.com>, ritter > ><ritterNOriSPAM@io.com.invalid> wrote: > >> > >>In article <slrn8j7ab3.2gd.mdw@mull.ncipher.com>, mdw@nsict.org > >>(Mark Wooding) wrote: > >>>Terry Ritter <ritter@io.com> wrote: > >>> > >>>> But how shall we measure this "trustworthy" property so we > >can > >>"make > >>>> sure" that it exists? > >>>> > >>>> There is an alternative, and I have been promoting it for > >>several > >>>> years: Use *scalable* cipher designs, so we can perform an > >>extensive > >>>> or even exhaustive analysis of the tiny scaled-down version. > >>> > >>>Sorry to interrupt while you're on your hobby horse, Terry, > but > >>I was > >>>referring to *implementations* of existing cipher designs. > >> > >>Oh, well, if "implementation" is the distinction, > >>then perhaps you will tell us just how you *test* for > >>the "trustworthy" property in *implementations*. > >> > >>Or maybe your idea of "trustworthy" is the real > >>hobby-horse ride being so rudely interrupted. > >> > >> > >>>The > >>>discussion in hand is about the possibility of hardware > >>implementations > >>>of strong (as a matter of hypothesis) having been deliberately > >>>compromised by the vendor. Cipher design doesn't help here. > >> > >>"Software" is just another name for the > >>customization of hardware digital systems. In > >>general, when we want a complete understanding of > >>what is present in a digital system, we must have > >>exhaustive tests. Such tests are impossible in real > >>size cipher systems, either hardware or software. > >>Only tiny systems allow exhaustive tests, only > >>scalable ciphers allow us to build tiny systems > >>directly related to real ones, and only exhaustive > >>testing allows us to know that nothing else is there. > >> > >>Perhaps that is clearer now. > > > >Yup it's clear you are not answering the question. > > > >His question was the possibility of DES being fudge-up by some > >naughty person. Not whether DES was strong or not, whether the > >CHIP was. > > Really? Well, here it is: > > >>>>>Well, One of the things I have been considering is the > >>>>>possibility of malicious software. > >>>>>That's why I was considering using a chip. > >>>>>That way there is absolutely no possibility > >>>>>that anythink will be placed in any > >>>>>subliminal channels. > Yup. I absolutely positively did say that. But later on it occured to me that since "trick questions" could eliminate the possibility of hardware subliminal channels, and also a sort of hardware attack where the algorithm used reverts to one that is significantly weaker, I chose to include that defense against malicious hardware in my defensive arsenal, too. > The issue I have addressed is the idea that "there > is absolutely no possibility" of a subliminal > channel on a chip. That is false, thus making the > only real advantage of hardware that new subliminal > channels are unlikely to be added -- unless of course > there is a programmable subsection that we don't know > about. > > What we really want is a cipher subsystem -- hardware > or software -- which demonstrably produces no more > data than we send to it. To assure this, we might > send in a buffer of data, and then use that same > buffer with the original length as the result. There > must be (at this level) no subsystem-selected or > produced random values. > And I'm glad you pointed that out because only hardware can assure us that no *more* data is being transmitted than we want. After all, a software system could do everything we wanted it to do, and then sneak through some other information in the FAT table, for instance. Such as the key, for example. > >Not like you do bad work, but you are plugging it in the wrong > >spot my friend. > Really? Perhaps you have a deeper insight you > would like to share with us. > The way I see it the problem with a scaleable cipher as a defense against a malicious attacker (hardware *or* software), is that the attacker might make it so that the cipher performed as expected in a small system but then reverted to a significantly weaker algorithm when it was scaled up a certain amount. Finally I would just like to say that this thread has indeed brought in many issues that were not in the original post, and these have made it possible for me to include more defenses in my plan than it had originally. This is, of course, a good thing. But it can be confusing if you have "missed a few episodes". So perhaps it is best not to "shoot from the hip" (even if you think you have just been shot at!). -- If you know about a retail source of inexpensive DES chips, please let me know, thanks. Sent via Deja.com http://www.deja.com/ Before you buy.
Subject: Re: Retail distributors of DES chips? Date: Fri, 02 Jun 2000 19:01:06 GMT From: ritter@io.com (Terry Ritter) Message-ID: <39380450.5905971@news.io.com> References: <8h1tnk$bra$1@nnrp1.deja.com> Newsgroups: sci.crypt Lines: 80 On Wed, 31 May 2000 02:34:29 GMT, in <8h1tnk$bra$1@nnrp1.deja.com>, in sci.crypt zapzing <zapzing@my-deja.com> wrote: >[...] >In article <13f3a7dc.c18ca6c1@usw-ex0105-040.remarq.com>, > ritter <ritterNOriSPAM@io.com.invalid> wrote: >[...] >> What we really want is a cipher subsystem -- hardware >> or software -- which demonstrably produces no more >> data than we send to it. To assure this, we might >> send in a buffer of data, and then use that same >> buffer with the original length as the result. There >> must be (at this level) no subsystem-selected or >> produced random values. >> > >And I'm glad you pointed that out because only >hardware can assure us that no *more* data is >being transmitted than we want. After all, a >software system could do everything we wanted >it to do, and then sneak through some other >information in the FAT table, for instance. >Such as the key, for example. But unless you advocate having *all* *hardware*, front to back, your chip will eventually communicate to software, where you pick up the same problem. Why should an opponent worry about subverting a cipher when they can simply send the latest key over the net? The advantage of the software is the possibility of certifying the source code to the object code (compile it, or check the result with a cryptographic hash), and then reviewing the source to assure that it does not have bad things. We cannot hope to review hardware designs that way. >[...] >The way I see it the problem with a scaleable cipher >as a defense against a malicious attacker (hardware >*or* software), is that the attacker might make it >so that the cipher performed as expected in a small >system but then reverted to a significantly weaker >algorithm when it was scaled up a certain amount. It certainly is necessary to check the source. Some ciphers will have no internal state-machine or special cases, so security dangers will stand out. I think that probably the larger issue is to have some guarantee that the object code we certify is that which is actually running. I suspect that a suitably-modified OS could pretend to be running our code and actually run something else. But when we cannot depend upon the OS (and we can't), hardware isn't going to help. First, we can't certify commercial hardware, and second, an insecure OS runs that hardware, or claims to. >Finally I would just like to say that this thread >has indeed brought in many issues that were not >in the original post, and these have made it >possible for me to include more defenses in my >plan than it had originally. This is, of course, >a good thing. But it can be confusing if you have >"missed a few episodes". So perhaps it is best >not to "shoot from the hip" (even if you think >you have just been shot at!). I think we all do what we can. It is in the nature of Usenet that some messages may not get all places; if those particular messages are critical, the conversation becomes hard to follow. My ISP makes things more interesting by first getting and then erasing messages at random. But in a normal conversation, losing one or more comments is not usually a significant problem. --- Terry Ritter ritter@io.com http://www.io.com/~ritter/ Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
Subject: Re: Retail distributors of DES chips? Date: Mon, 05 Jun 2000 20:40:12 GMT From: zapzing <zapzing@my-deja.com> Message-ID: <8hh379$k4h$1@nnrp1.deja.com> References: <39380450.5905971@news.io.com> Newsgroups: sci.crypt Lines: 116 In article <39380450.5905971@news.io.com>, ritter@io.com (Terry Ritter) wrote: > > On Wed, 31 May 2000 02:34:29 GMT, in <8h1tnk$bra$1@nnrp1.deja.com>, in > sci.crypt zapzing <zapzing@my-deja.com> wrote: > > >[...] > >In article <13f3a7dc.c18ca6c1@usw-ex0105-040.remarq.com>, > > ritter <ritterNOriSPAM@io.com.invalid> wrote: > > >[...] > >> What we really want is a cipher subsystem -- hardware > >> or software -- which demonstrably produces no more > >> data than we send to it. To assure this, we might > >> send in a buffer of data, and then use that same > >> buffer with the original length as the result. There > >> must be (at this level) no subsystem-selected or > >> produced random values. > >> > > > >And I'm glad you pointed that out because only > >hardware can assure us that no *more* data is > >being transmitted than we want. After all, a > >software system could do everything we wanted > >it to do, and then sneak through some other > >information in the FAT table, for instance. > >Such as the key, for example. > > But unless you advocate having *all* *hardware*, front to back, your > chip will eventually communicate to software, where you pick up the > same problem. Why should an opponent worry about subverting a cipher > when they can simply send the latest key over the net? > Well, not exactly. At least, that's what I'm hoping. For the system I'm working on, the computer would basically have an "encrypted hard drive" which would mean that there would be hardware encryption between the RAM, Processor, etc. and the HD and/or floppy drive. Basically, the RAM, CPU, etc. is "inside" and the HD and floppy are "outside". It works if there is no possible residue left in RAM. I don't like having to assume that, but there is no choice. Perhaps there is something that could be done after the computer is turned off, to get rid of any information that might be lingering in RAM. like powering it up on and off several times. Perhaps with lower than recommended supply voltage. (Does anyone know anything about that?) > The advantage of the software is the possibility of certifying the > source code to the object code (compile it, or check the result with a > cryptographic hash), and then reviewing the source to assure that it > does not have bad things. We cannot hope to review hardware designs > that way. > No, we can't. But if we take, say, a chip for doing DES we can be pretty sure that it actually does do DES at least most of the time. If we put several chips together, perhaps with a hardware permutation between them (is this called a "plugboard"?) then we can decrease the level of uncertainty. Doing a trial decryption of the data reduces uncertainty even further.Though,it's true, not ever eliminating it entirely. As far as I can tell, this can't be done in software. If we make our algorithm perfectly secure, and iterate it a zillion times, that is still no guarantee that the OS will, out of the kindness of it's heart, actually do what we requested of it. > >[...] > >The way I see it the problem with a scaleable cipher > >as a defense against a malicious attacker (hardware > >*or* software), is that the attacker might make it > >so that the cipher performed as expected in a small > >system but then reverted to a significantly weaker > >algorithm when it was scaled up a certain amount. > > It certainly is necessary to check the source. Some ciphers will have > no internal state-machine or special cases, so security dangers will > stand out. > > I think that probably the larger issue is to have some guarantee that > the object code we certify is that which is actually running. I > suspect that a suitably-modified OS could pretend to be running our > code and actually run something else. But when we cannot depend upon > the OS (and we can't), hardware isn't going to help. First, we can't > certify commercial hardware, and second, an insecure OS runs that > hardware, or claims to. > Well I disagree that we cannot certify commercial hardware. Discrete components can be certified by buying them in batches and destructively testing some of them by slicing them open. If we're talking about chips, we can give them "trick questions" by testing the chip against known test vectors. Do a thousand test vectors and you pretty much know that the chip will do the right thing at least 999 times out of a thousand. You can deal with the 1/1000 chance by using superencryption, plugboards, etc. -- If you know about a retail source of inexpensive DES chips, please let me know, thanks. Sent via Deja.com http://www.deja.com/ Before you buy.
Subject: Re: Retail distributors of DES chips? Date: Thu, 08 Jun 2000 19:31:03 GMT From: sarnold_intertrust@my-deja.com Message-ID: <8hos9n$eir$1@nnrp1.deja.com> References: <8hh379$k4h$1@nnrp1.deja.com> Newsgroups: sci.crypt Lines: 41 In article <8hh379$k4h$1@nnrp1.deja.com>, zapzing <zapzing@my-deja.com> wrote: > Well, not exactly. At least, that's what I'm hoping. > For the system I'm working on, the computer would > basically have an "encrypted hard drive" which > would mean that there would be hardware encryption > between the RAM, Processor, etc. and the HD and/or > floppy drive. Basically, the RAM, CPU, etc. is > "inside" and the HD and floppy are "outside". It > works if there is no possible residue left in RAM. > I don't like having to assume that, but there is > no choice. The good people at OpenBSD.org are working on a way of making their swap area encrypted so that RAM contents exist in plaintext only in RAM and in the CPU. There are also several projects dealing with encrypted filesystems that work with Linux. Maybe you could mix the OpenBSD encrypted swap with the linux encrypted filesystem to get basically what you are wanting, but without dealing with hardware. It could be a lot cheaper. > Perhaps there is something that could be done after > the computer is turned off, to get rid of any > information that might be lingering in RAM. > like powering it up on and off several times. > Perhaps with lower than recommended supply voltage. > (Does anyone know anything about that?) Well, if you have access to the OS source, you could have it malloc() many many blocks of RAM and fill the contents with prng output, maybe several times over depending on how paranoid you are. As a simple rc.shutdown script, I wonder how far one could get with a simple: dd if=/dev/random of=/dev/mem bs=1024k count=256 ? It might not be pretty... but it might also work. :) Sent via Deja.com http://www.deja.com/ Before you buy.
Subject: Re: Retail distributors of DES chips? Date: Fri, 09 Jun 2000 02:10:50 GMT From: zapzing <zapzing@my-deja.com> Message-ID: <8hpjmu$dv$1@nnrp1.deja.com> References: <8hos9n$eir$1@nnrp1.deja.com> Newsgroups: sci.crypt Lines: 53 In article <8hos9n$eir$1@nnrp1.deja.com>, sarnold_intertrust@my-deja.com wrote: > In article <8hh379$k4h$1@nnrp1.deja.com>, > zapzing <zapzing@my-deja.com> wrote: > > > Well, not exactly. At least, that's what I'm hoping. > > For the system I'm working on, the computer would > > basically have an "encrypted hard drive" which > > would mean that there would be hardware encryption > > between the RAM, Processor, etc. and the HD and/or > > floppy drive. Basically, the RAM, CPU, etc. is > > "inside" and the HD and floppy are "outside". It > > works if there is no possible residue left in RAM. > > I don't like having to assume that, but there is > > no choice. > > The good people at OpenBSD.org are working on a way of making their swap > area encrypted so that RAM contents exist in plaintext only in RAM and > in the CPU. There are also several projects dealing with encrypted > filesystems that work with Linux. Maybe you could mix the OpenBSD > encrypted swap with the linux encrypted filesystem to get basically what > you are wanting, but without dealing with hardware. It could be a lot > cheaper. Or, better yet, just get alot of RAM so that a swap area is unneccessaty. > > > Perhaps there is something that could be done after > > the computer is turned off, to get rid of any > > information that might be lingering in RAM. > > like powering it up on and off several times. > > Perhaps with lower than recommended supply voltage. > > (Does anyone know anything about that?) > > Well, if you have access to the OS source, you could have it malloc() > many many blocks of RAM and fill the contents with prng output, maybe > several times over depending on how paranoid you are. Ah but I do not trust the OS you see. That is why I was looking for a hardware solution. -- If you know about a retail source of inexpensive DES chips, please let me know, thanks. Sent via Deja.com http://www.deja.com/ Before you buy.
Subject: Re: Retail distributors of DES chips? Date: 30 May 2000 21:08:24 GMT From: mdw@nsict.org (Mark Wooding) Message-ID: <slrn8j8be8.t2q.mdw@tux.nsict.org> References: <04c7825c.2cf14a2f@usw-ex0101-005.remarq.com> Newsgroups: sci.crypt Lines: 31 ritter <ritterNOriSPAM@io.com.invalid> wrote: > Or maybe your idea of "trustworthy" is the real hobby-horse ride being > so rudely interrupted. I think we're off at a tangent here still... I intended `trustworthy' to mean that, in the considered opinion of the security officer using the component, it is worthy of the trust placed in it. That's a decision for the user to make, based on whatever criteria he or she wants to use. > That said, I think we can test a cipher chip to a software > implementation, using the property that we have a particular 1:1 > transformation, and that no more information comes out than goes in. Except that, as mentioned upthread, the chip may have been programmed to yield the key (or some simple function of it) only when a particular plaintext or sequence of plaintexts is submitted for encryption, or some other unlikely event occurs. As you quite rightly point out, testing doesn't help, but this isn't the fault of the cipher this time -- the cipher could be completely secure and it wouldn't fix the problem -- but the fact that we can't look inside the implementation means we can't tell whether it's actually doing what it said on the box. > But that means the chip cannot pick any "random" system-level values > (no message keys, no IV's). Except it might `sometimes', depending on external stimuli. -- [mdw]
Subject: Re: Retail distributors of DES chips? Date: Fri, 02 Jun 2000 19:01:26 GMT From: ritter@io.com (Terry Ritter) Message-ID: <39380475.5942846@news.io.com> References: <slrn8j8be8.t2q.mdw@tux.nsict.org> Newsgroups: sci.crypt Lines: 69 On 30 May 2000 21:08:24 GMT, in <slrn8j8be8.t2q.mdw@tux.nsict.org>, in sci.crypt mdw@nsict.org (Mark Wooding) wrote: >ritter <ritterNOriSPAM@io.com.invalid> wrote: > >> Or maybe your idea of "trustworthy" is the real hobby-horse ride being >> so rudely interrupted. > >I think we're off at a tangent here still... > >I intended `trustworthy' to mean that, in the considered opinion of the >security officer using the component, it is worthy of the trust placed >in it. That's a decision for the user to make, based on whatever >criteria he or she wants to use. Will we now have users deciding upon the "trustworthy"-ness of a cipher? Which users are those? I have a real problem with this use of "trust." Scientifically speaking, absent a mathematical proof which applies in practice, we cannot "trust" *any* cipher. Even if we try a more casual definition, users simply do not have the information which we normally associate with "trust": not *knowing* a cipher is broken is not grounds for "trust," yet that is the best one can realistically expect. >> That said, I think we can test a cipher chip to a software >> implementation, using the property that we have a particular 1:1 >> transformation, and that no more information comes out than goes in. > >Except that, as mentioned upthread, the chip may have been programmed to >yield the key (or some simple function of it) only when a particular >plaintext or sequence of plaintexts is submitted for encryption, or some >other unlikely event occurs. As you quite rightly point out, testing >doesn't help, but this isn't the fault of the cipher this time -- the >cipher could be completely secure and it wouldn't fix the problem -- but >the fact that we can't look inside the implementation means we can't >tell whether it's actually doing what it said on the box. Nevertheless, this inability to certify something at real size is directly addressed by scalable ciphers. I don't know if we can do that in hardware. But in software, we can have ciphers which use the exact same code and which are parameterized to produce small blocks. Then we *can* hope to provide an exhaustive test of the reduced code, which also is the expanded code. If we can certify that the object code corresponds to the source code, and we have that source, some ciphers will expose security-risk internal state-machines and special cases better than other ciphers. This is a cipher issue. All of which means that we absolutely cannot certify a commercial hardware implementation of real size. But the direction of the discussion, as far as one can tell, is that hardware is better. >> But that means the chip cannot pick any "random" system-level values >> (no message keys, no IV's). > >Except it might `sometimes', depending on external stimuli. Let me say that differently: We cannot hope to certify a chip which picks its own "random" values unless we get into the guts and know how those values are produced, and can show that no other values get substituted for them. In a commercial chip, we can't. --- Terry Ritter ritter@io.com http://www.io.com/~ritter/ Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
Subject: Re: Retail distributors of DES chips? Date: Thu, 08 Jun 2000 02:26:11 +0200 From: Thor Arne Johansen <thorj@ibas.no> Message-ID: <393EE823.F3D6A72F@ibas.no> References: <8grsik$3o0$1@nnrp1.deja.com> <8gqjuu$i8k$1@mach.thp.univie.ac.at> Newsgroups: sci.crypt Lines: 8 If after all this flaming/discussion/exploration you're still interested in a DES chip, you should check out: http://www.pcc.pijnenburg.nl/ BR, Thor A. Johansen
Terry Ritter, his current address, and his top page.
Last updated: 2001-06-11