Re: Digital Contracts: Lie in X.509, Go to Jail
At 4:06 AM -0700 10/20/99, Ryan Lackey wrote: Anyone want to try redistribution in the US? I could order 10-20 copies from Stefan Brands, assuming he's willing to sell in quantity, and then handle resale in the US for e-gold or US checks or regular postal money orders or whatever. If you're interested, email me. You can sell them through Amazon zStores and Amazon will accept credit cards for you. Robert Hettinga wrote: If we had bearer microcash, this wouldn't be a problem, yes? ;-). No. The complexity of international distribution agreements and general stupidity are much bigger factors than cash settlement costs. Two of my books are translated into Spanish. The US is the second largest Spanish speaking market in the world. Can I get the Spanish editions distributed here? No way! Until then, it's F=MA, same as it ever was. Mechanical Engineers usually quote the law as: "F=MA and you can't push a rope." Arnold Reinhold
Re: Digital Contracts: Lie in X.509, Go to Jail
At 9:20 AM +1000 10/20/99, Julian Assange wrote: Robert Hettinga [EMAIL PROTECTED] writes: Evidently, there are only 500 in the first printing, but I bet Stefan didn't give them *all* away. :-). I bet that if you put in a special order to Amazon with the ISBN and the publisher in it, they'll manage to sell one to you on order. Upon receiving a bunch of orders for the book from some place like Amazon, if and when the publisher sells out, they'll probably print some more, or at least make a deal to print it on this side of the pond. Cheers, RAH Amazon only sells books distributed in the United States. That's not quite true, as the US publishers of Harry Potter found out. You can easily order from England http://amazon.co.uk and Germany http://amazon.de Unfortunately, neither list 'Rethinking Public Key Infrastructures..." Ponsen and Looijen have a web site http://www.p-l.nl/ That's as far as I got. Arnold Reinhold
Re: having source code for your CPU chip -- NOT
At 6:38 PM -0400 9/23/99, Eli Brandt wrote: Arnold Reinhold wrote: Perry, if you really believe that the question of whether a given lump of object code contains a Thompson Trap is formally undecidable I'd be interested in seeing a proof. Otherwise Herr Goedel has nothing to do with this. That sure smells undecidable to me. Any non-trivial predicate P on Turing machines (non-trivial meaning that both P and not-P are non-empty) is undecidable by Rice's Theorem. There are technical issues in encoding onto the tape all possible interactions with the world -- the theorem doesn't apply if some inputs are deemed illegal -- but, hey, it's all countably infinite; re-encode with the naturals. I am not asking about the class of all Turing machines, just one particular lump of object code OC that happens to be a compiler--say the C++ compiler on the Red Hat 6.0 distribution. And the question is whether OC, which was compiled from a particular source file SF, only contains code attributable to SF or contains some additional self-propagating code inserted by the compiler OCprev that produced OC. SF is trusted by assumption. Only OCprev is suspect. You can even modify SF to some extent, say to turn off optimization or to produce an auxiliary file that matches object code to source statements. If you can answer this question just one time then Thompson's attack can be defeated. This problem is not remotely undecidable. One way to solve it is to write a new compiler from scratch OCalt. Then see if (OCalt(SF))(SF) = OC. As others have pointed out, you can also attempt to ascribe each byte of object code to the source that generated it. The practical impact of this is not immediately apparent. All non-trivial theorem-proving about programs is futile in this same sense, but people do it, or try. They have a lot of difficulties less arcane than running into the pathological cases constructed to prove these undecidability theorems. Your argument reminds me of claims I always hear that nothing can be measured because of the Heisenberg Uncertainty principle. I do feel your pain. More like disgust, actually. Too many computer scientists engage in this sort of name dropping, citing theorems that generally apply only in some infinite limit and specifically do not apply to the case at hand. Most people in the industry, who think an uncountable cardinal has something to do with electing the Pope, take their pronouncements on faith and just give up. The fact is almost nothing in crypto is on a rigorous mathematical foundation. No one has proved that factoring or discrete logs are hard problems (at least not publicly). Yet almost all the difficulties in building trustable systems do not lie in undecidablility results but in human failings. The Open Source model, in my opinion, is the best hope of creating trusted systems we have. Designing a process that can demonstrate that a given system is totally derived from a body of published code is an important goal. The Thompson paper is a often cited as proof that this cannot be done. It deserves to be debunked. Arnold Reinhold
Re: having source code for your CPU chip -- NOT
First of all, I've always thought that Thompson's paper was excessively defeatist. It should be possible to bootstrap an open source C++ compiler from a simple C subset and then have several grouts independently produce subset C compilers in assembler code. Or compile it on ancient machines, e.g. PDP-11 using original compilers. The bad guys can't have anticipated that far ahead. [You sound like Hilbert, hoping that the consistency and completeness of the Principia could be proven using "only" finitistic methods. --Perry] Having said that, perhaps the Open CPU requires open CAD software as well. It should be possible to verify masks against the design and physical chips against the mask. Finally, I wonder if it might be possible to implement a RISC CPU on an FPGA. It might even be possible to write a CPU generator that made layout choices at random so that it would be unlikely that any two FPGA CPU would have the same layout. This would make it hard to build a trap door into the FPGA itself. Arnold Reinhold At 6:58 PM -0700 9/19/99, John Gilmore wrote: On the other hand, having the actual CPU source, we could stop worrying about Intel's ID gaffs, and RNG support, and "know" it is built correctly. Even if you designed the chip and contracted out the fabrication, you will not know that it is built correctly. Even if you ran the fab and shuttled the wafers from machine to machine yourself. I have done design verification for complex chips (in the SPARCstation-1 and -2). You can certainly test that it does everything you designed it to do. You can't test for the *absence* of backdoors or trojan horses. If someone jiggered your CAD software to insert circuitry that turns on the supervisor bit for one instruction if you execute seventeen ADDs in a row, you'll never find it unless someone points you at it. (And it won't be in your "source code", only in your physical circuitry. You could find it in the photographic masks, or in a chip, nowhere else.) Remember Ken Thompson's _Reflections on Trusting Trust_: http://www.acm.org/classics/sep95/ It's a very short paper, readable by everyone on the list. Read it now! You'll be shocked. John
Re: Intel RNG
I do not see anything "reasonable" in the excuses Anonymous attributes to Intel not allowing access to raw RNG bits. If Intel wants developers to use their RNG API they need only publish it. Professional programmers these days respect APIs and realize they risk future problems if the do not follow them. I am not sure who a "naive user" of a hardware RNG might be, but I think courts would consider any software engineer knowledgeable enough to be responsible for reading the warnings included in the documentation. And if the raw bits are close to white, the consequences of using them directly in most cryptographic applications is negligible. The old "lawyers made me do it" argument is really thin here. Finally, the notion that selling a few six-figure driver kits is material to Intel's bottom line is hard to credit. Random number generation is a vital part of any security system. It is important check raw bits regularly to verify, to the extent possible, that no failure has occurred. Some bias in the raw bits may be valuable here, particularly if it can be correlated with and physical parameter such as bus voltage or chip temperature. Intel's reluctance to publish details of the RNG interface and to make raw bits available to system designers is troublesome and suspect. Arnold Reinhold At 12:00 AM +0200 9/17/99, Anonymous wrote: ... Bram asks: If Intel's RNG really is producing a reliable one bit of entropy per one bit of output, why don't they just make it accessible without whitening? There are a number of reasonable possibilities for why Intel prefers to provide the post-whitened output: The main one is that they want people to access the chip via a standard API which provides high quality random bits. This is normal software engineering practice. It gives Intel freedom in the future to make changes to the chip interface and accommodate them in the driver. For example, they could move the von Neumann bias remover into software if they desired, and the change would be transparent to software which used the chip. Or perhaps they could go in the other direction and put some kind of SHA-like whitener onto the chip in order to reduce the software load. Using a standard API for high quality random bits allows this kind of design flexibility without concerns about breaking applications which rely on the previous architecture. They are also concerned, with the current architecture, that naive users may use the output of the chip directly without passing it through the software layers which are necessary to make it fully random. Of course most people would hopefully not be foolish enough to do this, but Intel may be worried about liability issues if they publish the internal interface to a "random number generator" which is not fully random. Intel is probably also be motivated by profit. Got to keep that stock going up, you know. Apparently they are charging a great deal of money (six figures) for access to the RNG library. If they openly published the interface to the chip they would not be able to make this kind of money off of their software driver. Now, although these reasons are all valid to varying degrees, it is likely that the interface will be published despite these concerns. There is little that Intel can do to stop people from reverse engineering their driver and publishing the interface (anonymously, if necessary). This issue will therefore probably be moot in a few months.
Re: Why did White House change its mind on crypto?
I think we should take Deputy Secretary of Defense John Hambre at his word (from the White House briefing): "MR. HAMRE: ... The national security establishment -- the Department of Defense, the intelligence community -- strongly supports this strategy. Indeed, we created the first draft of the strategy and presented it to our colleagues in the interagency process. We in the Defense Department did it because I think we feel the problem more intensively than does anyone else in the United States. We are the largest-single entity that operates in cyberspace. No one is as large as we are. We are just as vulnerable in cyberspace as is anybody, and we strongly need the sorts of protections that come with strong encryption and a key infrastructure that we're calling for in this strategy." I suspect his security experts realized that export controls were ineffective in keeping crypto out of the hands of bad guys and that the DOD was suffering because the commercial products on which it depends lack strong security. Arnold Reinhold
Re: Power analysis of AES candidates
At 1:35 PM -0700 9/14/99, John Gilmore wrote: At 10:32 AM -0700 9/13/99, Eugene Leitl wrote: Why don't you just erase flash when a pressure change (hull breach) is detected. Using double-walled hull, to look for shortcuts. You can also couple this to light detection, and whatnot. Arnold Reinhold said: in several places) that would monitor on-chip supply voltage and keep the program from executing sensitive code for some period if dV/dt were too high. If the cap or Li battery were disconnected, the What are you guys talking about? Differential power analysis doesn't require any physical attack, nor does it deal with voltage variations. (You are probably thinking of Shamir's fault-injection attacks.) Differential power analysis measures the current consumption of the part as it operates, completely outside the device. OK a recap of where we are: A suggestion was made that a large capacitor or Lithium battery be used to reduce the power fluctuations that DPA depends on. That was countered by pointing out that an attacker could physically disconnect the battery or cap (Maybe x-ray the package, find the relatively fat connection and drill it out). Mr. Leitl suggested pressure and light sensors to detect the drilling, which I find dubious, even if each smart card has a different pressure. I suggested that a simple on-chip circuit could inform on-board CPU that a disconnect may have occurred. This circuit would measure fluctuations in the supply voltage. Mr. Ohm has demonstrated that current variations usually imply voltage variations. Mr. Brandt now questions whether a cap can be large enough to defeat DPA, since the attacker can increase the number of runs and the required N varies linearly with C. I would like to point out that using one or more RC stages changes the equation considerably, and, in the extreme, the CPU could be powered entirely by a capacitor or battery during the sensitive computations, with all connection to the outside temporarily broken. Arnold Reinhold
Re: Power analysis of AES candidates
At 10:32 AM -0700 9/13/99, Eugene Leitl wrote: Why don't you just erase flash when a pressure change (hull breach) is detected. Using double-walled hull, to look for shortcuts. You can also couple this to light detection, and whatnot. Andreas Bogk writes: Russell Nelson [EMAIL PROTECTED] writes: There's some question about how hard it will be to design hardware that will be DPA-resistant for different algorithms. Big on-chip caps. Lithium batteries. Tamper-resistant housings. [...] A sophisticated attacker could measure the pressure in each compartment and work in a pressurized, darkened room. One thought I had is to include a circuit on chip (perhaps duplicated in several places) that would monitor on-chip supply voltage and keep the program from executing sensitive code for some period if dV/dt were too high. If the cap or Li battery were disconnected, the circuit would see continuous fluctuations and shut the processor down. A accidental power glitch would only cause a short delay in execution. If an attacker can get to the chip and disable these power monitor circuits, he can probably also put a logic analyzer on the memory lines and extract the key that way. Arnold Reinhold
RE: Paul Brown on Solitiare randomness flaw?
At 2:01 PM +0200 9/14/99, Kuehn, Ulrich wrote: Hi, please find here included a mail from Holger Klawitter, the author of one of the mentioned palm cipher programs... He would have liked to recieve the critique himself. Ulrich --- [quoted form Holger Klawitter [EMAIL PROTECTED]] http://www.klawitter.de/palm/cipher.html uses IDEA to encrypt the clipboard, but it's ascii armouring would make it hard to manually transmit ciphertext, if I understand what he is doing. One of the major drawbacks of the Palm pilot is the maximum length of a note which is 4096 bytes. ASCII Armouring makes text longer so I decided to use an armour with 7bit significance. If the demand proves to be more base 64 encoding I'll be happy to switch. Sorry, I was not critiquing Holger's program here, but rather considering its suitability for an application very different from its original purpose. The problem was how to enable a human rights worker in the field to send and receive coded messages. Such a worker might not have access to e-mail, so it is desirable that messages be capable of transmission via snail-mail, FAX, voice, Morse code, carved coconut shells or whatever. In this situation, even base-64 would be a pain. In its original contest, 7/8 encoding makes sense. Passphrase length is limited to 16 characters, which is unfortunate. Also, I wonder if the lack of a keyboard would make it a pain to enter persnickety text like passphrases and ciphertext. I think you've predicted my answer. In general, I think forcing a user to pick a short password is a bad idea. Even though entering a long password or passphrase on a Pilot is awkward, that choice should be left to the user. A password consisting of 16 random letters of the Roman alphabet offers 75 bits of entropy. That is adequate for strong security, but barely. If a user wants a strong passphrase that is easy to remember, 16 characters is hopeless. The consensus recommendation for long term security is 90 bits. To get that from 16 random characters, each character must be drawn from an alphabet of 50 symbols. Side note to document what some people really (believe to) want: I got some request for storing the passord in a database in order not to have to type it in so often. Of course, I denied the request :-) I agree that this is a dumb request if the program is only being used to protect files on the Pilot. But I wouldn't dismiss the suggestion quite so fast if the program is also being for communications security. One possible solution might be to allow two passwords, one of which is stored on the pilot in encrypted form, with the second password as the key. Arnold Reinhold
Re: Paul Brown on Solitiare randomness flaw?
At 5:05 PM -0400 9/9/99, Thomas W. Kellar wrote: I wrote a rc4 based encryption/decryption program for my TI86. You can enter an alphabetic key (up to 256 characters). Enter some uppercase only alphabetic plaintext, then it displays decimal numbers representing the encryption of the plaintext. In decrypt mode you enter your key, then the decimal numbers previously produced and it displays your plaintext again. I used B. Schneier's description in _Applied Cryptography_ 2nd ed as the basis for the rc4. If anyone wants a copy of it, send me a note. As a USA citizen residing in the USA, I believe you are supposed to be similarly situated before I can send it to you. Take a look at http://ciphersaber.gurus.com for some additional stuff you should add to you program, like an initialization vector (IV) to prevent the same key from being used twice. You will also find some test vectors there. Considering that the key can only have 28 possible values for each octet, there is probably not much security in it. (A..Z plus space and = sign) The good news is that you are completely wrong. I suspect you have been brain-washed by all the password advice out there that says you must use numbers and special characters. Hogwash! 28 values are more than enough for strong security. Even 26 will do. If you pick letters at random from [A-Z], each letter gives you 4.7 bits of entropy. 28 values makes it 4.8 bits per letter. That means a 90-bit password would be 19 letters long. (The consensus is that 90 bits is enough for long term strong security.) Here is what one would look like: otvga dzkgr ekhao woya If you use a 96 character alphabet (upper and lower case, numbers and special characters) you get 6.58 bits per character. That means your 90-bit password would take only14 characters. For example: ,If7m w*R. m?4Q That is a little shorter, but harder to remember or enter. I don't think the saving is worth it. You can also use a 7 word diceware passphrase (see http://www.diceware.com) For example: onion bedim zero km sousa nell rimy I think the last is the easiest to remember, but tastes vary. All are equally secure! Arnold Reinhold
Re: Paul Brown on Solitiare randomness flaw?
At 8:32 PM -0700 9/8/99, Bill Stewart wrote: At 09:23 AM 9/8/99 -0400, Arnold Reinhold wrote: ... Staples stocks the TI-83+ at $92.99. So for under a hundred bucks and a little time spent in TIBasic programming you can own an off-the-shelf coding machine using strong encryption, interoperable with CipherSaber programs on other platforms, in a reasonably portable and innocent-looking package. And it will still do math. Of course, you can get a low-end Palm Pilot for about $130-150 (or cheaper if you buy used from somebody upgrading.) More memory, and you don't have to program in Basic. Are you saying that there are existing encryption programs for the Pilot or that there are better languages to program it in? (Basic really isn't bad for something like RC4) I searched around, but didn't much in the way of Pilot strong crypto applications. http://www.isaac.cs.berkeley.edu/pilot/ has some tools, but doesn't seem to have a complete stand-alone encryption program. http://www.klawitter.de/palm/cipher.html uses IDEA to encrypt the clipboard, but it's ascii armouring would make it hard to manually transmit ciphertext, if I understand what he is doing. Passphrase length is limited to 16 characters, which is unfortunate. Also, I wonder if the lack of a keyboard would make it a pain to enter persnickety text like passphrases and ciphertext. Tastes may vary on this. The Pilot form factor is a lot better -- the TI Graphing calculators are biggish. Anyone know a really small calculator or palm top with enough programmability? Securing computers that are attached to networks is still a daunting problem. TI, Pilot or whatever, a small device that does strong encryption and is never connected to anything could prove very useful. Arnold Reinhold
Re: Paul Brown on Solitiare randomness flaw?
At 1:49 PM -0400 9/6/99, [EMAIL PROTECTED] wrote: On Mon, 6 Sep 1999, Arnold Reinhold wrote: If a field worker might have access to a computer in country but would not be in a position to use PGP, I'd suggest CipherSaber, which is based on RC4 and is simple enough to program from memory (see http://ciphersaber.gurus.com). Almost all PCs come with Qbasic built in or on the CD-ROM. I haven't tried it, but CipherSaber should fit easily into most of the newer graphing calculators (The $200 TI-92+ even has a qwerty keyboard. See http://www.ti.com/calc). Yeah, I have no doubt that RC4 could be implemented quite easily on TI calculators (certainly on the 85, 86, 92 and 89 .. and probably on the 82 and 83 as well .. though I haven't programmed them). The 82 has a maximum list length of 99 values, which would make it a pain to implement RC4's 256 byte S array. The others look more than capable. They all have alphanumeric displays and a full alphabet on their keyboards. I did MD5 on my 92 awhile back. In TI Basic? I'm impressed. BTW, several of these units also permit assembly language programming. The 83/83+ is Z80 based. The 89/92+ are 68000 based, with 188K of RAM. PGP isn't out of the question on those. A couple of points in making an actual crypto application on the TI (as opposed to just doing an algorithm): Transferring ciphertext from the TI to a computer would require a utility on the computer to wrap up the ciphertext to make it look like a list to the TI. Then the TI can do nice, easy subscripting to access the list. A table might be needed to display the plaintext, since I don't know if they use ASCII. I was thinking of the calculators more as stand-alone cipher machines, a la Enigma, but with modern, strong encryption (RC4). Ciphertext would be entered or written down as hex pairs or even 3-digit decimal numbers. The ciphertext could be transmitted via FAX, e-mail, snail mail or, tediously, by voice. As long as CipherSaber's 10-byte IV is sent correctly, a single ciphertext garble will only cause the corresponding plaintext letter to be wrong. FAX has an advantage in that it is harder to screen for ciphertext than e-mail and it is more universally available. An interesting variant would be to restrict plaintext to the 26 letters of the alphabet (same as Enigma and Solitiare). Ciphertext would then also be composed of letters of the alphabet. A simple way to do this would be to discard RC4 cipher stream output bytes that are greater than 233. (234 = 9*26). Reduce cipher stream bytes that are not discarded modulo 26, and then add or subtract them from the numerical value of the letter (A=0, B=1,...). This should be at least as strong as RC4. The values will be at least as uniformly distributed as RC4, you are using less entropy per cycle and the discarded bytes provide added mixing. Ciphertext would be the same size as plaintext except for the IV. The IV could be sent as 20 hex digits coded as [A-P]. For a small to medium network, another alternative is to base the IV on the date and time of the message, along with some code indicating the sender, perhaps the numerical value of the sender's initials. Remember, the IV only has to be unique. Of course it wouldn't be much more effort to support both 26 symbol and 256 symbol modes. Staples stocks the TI-83+ at $92.99. So for under a hundred bucks and a little time spent in TIBasic programming you can own an off-the-shelf coding machine using strong encryption, interoperable with CipherSaber programs on other platforms, in a reasonably portable and innocent-looking package. And it will still do math. Anyone care to try it? Arnold Reinhold
