- cypherpunks-legacy - lists.cpunks.org

An update on MS private key (in)security issues
by pgut001＠cs.auckland.ac.nz 17 Dec '03

17 Dec '03

A fortnight ago I posted a message exposing a number of weaknesses in the way various Microsoft security products handle users private keys. A few days before I was due to vanish for a security conference (where it was very difficult to contact me), the article started getting a bit of attention. This is a general response which clarifies several issues relating to the original message. First, Russ Cooper (moderator of the NT Bugtraq mailing list) made some wildly inaccurate claims about the article. I've had a bit of feedback which indicated that it wasn't even worth dignifying this stuff with a response but I've written one anyway, at least for the original NT Bugtraq messages he posted (the stuff he put on a web page is just more of the same). You can find it at http://www.cs.auckland.ac.nz/~pgut001/pubs/breakms2.txt (even if you don't want to plough through the whole thing, you might want to read the last two paragraphs for a giggle). After this, Microsofts spin doctors leaped into action and posted a response to the article. I've replied to this one in a bit more detail, since it raises several important issues. Comments on Microsofts Response ------------------------------- >Microsoft's Response to Recent Questions on the Recovery of Private Keys from >various Microsoft Products >[...] >With the exception of the details about a possible PKCS-12 attack, all the >issues raised in the recent discussions are specifically aimed at Microsoft's >base CSPs, not at CryptoAPI. The base CSPs are the royalty-free, >software-based CSPs provided with Windows NT 4.0, Windows 95, and Internet >Explorer. These attacks do not apply in general to other CryptoAPI CSPs and do >not indicate any fundamental concerns with the security of the CryptoAPI >architecture or applications built upon it. This statement is mere obfuscation. As Microsoft have said, every single (recent) copy of Windows NT, Windows'95, and MSIE (and, presumably, other products like IIS and Outlook, which rely on them) ship with these CSP's, therefore every recent system comes with this security hole installed by default. In addition, the CryptExportKey() function is a standard CryptAPI function, which is described by Microsoft with the text "The CryptExportKey function is used to export cryptographic keys out of a cryptographic service provider in a secure manner" (obviously some new use of the term "secure" with which I wasn't previously familiar). There's nothing in there that says "Only the Microsoft CSP's support this" (some may not support it, but by Microsofts own admission the default used on any recent system does indeed exhibit this flaw). >Microsoft products do not "store" private key material using PKCS-12, contrary >to recent descriptions on the Internet. I was unfortunately somewhat unclear in my article, I've fixed up the online version at http://www.cs.auckland.ac.nz/~pgut001/pubs/breakms.txt. To summarise, if you want to get at an exported key stored on disk, you can use the pre-4.0 key file/PKCS #12 key file flaws. If you want to get at the current users key, you can use the CryptExportKey() flaw. >The example of breaking a PKCS-12 data blob, which was given in discussion on >the Internet, is not an attack on the "weak" cryptography of PKCS-12. Rather, >it is simply a dictionary attack (long known and well understood in >cryptography), This statement is accurate. As Microsoft have said, dictionary attacks have been known to the computer industry for a long, long time (several decades). For example the Unix password encryption uses 25 iterations of DES to protect users passwords from dictionary attacks (this is rather inadequate now, but was appropriate more than two decades ago when it was introduced). If this is a well-known flaw which the entire industry has known about for decades, why are Microsoft's very latest "security" products so extremely vulnerable to it? As I mentioned in my writeup, I published an attack on the exact format used in older MS products more than 1 1/2 years ago, but Microsoft made no attempt to fix this problem at the time. It wasn't until I published the current writeup that they finally addressed it. >One statement by the original poster argues that Microsoft managed to design a >security format that actually makes it easier to break into the protected >data. As stated above, a number of well respected companies were involved >extensively in the design and review of PKCS-12 before it became a standard. The problem is that Microsoft ignored the other companies recommendations for increasing security. I'll refer people back to the original writeup for mention of the various security features which were added to PKCS #12 and subsequently ignored by Microsoft. PKCS #12 is just a basic modification of PFX, which was a purely Microsoft invention, and Microsofts implementation of PKCS #12 does indeed make it very easy to perform the attack I described (you'd have to read my writeup for the full technical details in which I describe each individual flaw which, as each is exploited in turn, make it progressively easier and easier to recover a users private key). In addition (as I mentioned in my original message), Microsoft use RC2/40 to encrypt the private keys, which means that no matter how good a password you choose, the default PKCS #12 format private key produced by MSIE can be recovered in a few days with fairly modest computing power. There already exists a Windows screen saver which will recover RC2/40 keys for S/MIME messages, and the prize of an RSA private key is a much higher motivating factor than the "Hello, how are you?" typically found in an S/MIME message. As Microsoft point out, Netscape can indeed handle RC2/40-encrypted files, however they usually use triple DES and not RC2/40 (they encrypt the private key components - the really valuable part of the PKCS #12 payload - with triple DES and the other odds and ends with RC2/40). Since Netscape also iterate the password and MAC processing, they aren't vulnerable to the attacks which the Microsoft software is vulnerable to, even though both are based on the same PKCS #12 standard. >Exploiting Internet Explorer > >One of the fundamental requirements to perform any possible cryptographic >attack discussed in the recent postings is the assumption that a malicious >entity could somehow access to data on a user's computer system, without the >permission or knowledge of the user. This is a large leap of faith. > >Users that are using Public Key Certificates today are generally sophisticated >and savvy users, Bwahahahahaha! Sorry, I guess I should explain that in more precise terms. Now I'm not trying to claim that the average Win95 user isn't as sophisticated and savvy as Microsoft seem to think, or that relying entirely on the sophistication of the average Win95 user for security is a dangerous move. However these statements do seem to completely ignore the reality of the situation. Let me go into the background of the weaknesses a bit further. When I tested the weaknesses, I asked some "guinea pig" users to send me their exported keys, with the promise that I'd destroy the keys and not keep any record of where the keys came from and so on. Because of this I can't give exact figures, however here are a few data points: - More than half the keys (I can't remember the exact figure) were in the older, pre-4.x format. This indicates that the majority of users (or at least of the crypto-using guinea pigs) are still running old versions of MSIE which contain a number of widely-publicised problems, including precisely the weaknesses required to run arbitrary code on the machine or read files off the machine. One of the respondents commented that the key was "the key I use with Outlook", I'm not sure what that says about the origins of the key. Another key was one used with IIS for a web site which runs an online commerce service that processes credit-card based orders. This must have been an older version of IIS since the key was in the pre-4.x format. - When I asked two of the people why they were still using an old version, the responses were "It came installed with the machine when we bought it" and "It does what I want, so I haven't upgraded". I expect most users of the older version would have a similar reason for using it. In a company of 20 people (some of whom participated in this test), only two were running 4.x. These people are all highly competent software developers (presumably this includes them in the group of "sophisticated and savvy users" which MS were referring to), however none of the remaining 18 wanted to risk installing MSIE 4 because of the extent with which it messed with their system, possibly jeopardising their development work. Therefore most of these "sophisticated and savvy users" were still running old, insecure versions of MSIE, and weren't going to upgrade any time soon. - For the two remaining 4.x users in the company, both are still using straight, unpatched 4.0 because they considered it painful enough to download all of 4.0 and they didn't want to bother with an upgrade just yet. This makes them vulnerable to the bug pointed out in the l0pht advisory. - When I informed one of the guinea pigs of the recovered password, his response was "Now I'll have to change my login password" (the others generally restricted themselves to some variation of "Oops"). This comment confirms that users do indeed sometimes use their login password to protect their private keys, so that a successful attack recovers not only their private keys but their login password as well. - One respondent commented that most of the code they downloaded from the net was unsigned, but they ran it anyway. This is probably typical of the average user. Although I've only been back for two days, I haven't yet managed to find anyone who has applied all the latest patches and kludges to their system which makes them immune to these problems. This includes at least one person who has a code signing key which could be used to sign malicious ActiveX controls. Therefore all of the guinea pigs could in theory have their private keys stolen. >Attacks against Authenticode signing keys > >[...] > >However, it is extremely unlikely anyone could be successful with a simplistic >strategy for stealing Authenticode signing keys and then using them. See my comments about about this. I could, right now, obtain at least one Authenticode signing key with which I could create a malicious ActiveX control. I'm sure that if I were serious about this I could obtain a number of others. >Second, anyone signing code using Authenticode technology is extremely >unlikely to leave their key material sitting on an end user machine routinely >used for browsing the Internet. I see no basis for this claim. Every developer I know uses the same machine for both code development and web browsing (in fact a number of users keep a copy of MSIE or Netscape permantly running on their machine so that they'll have something to do between compiles). Microsoft's statement seems to imply that users will be running two machines, one dedicated entirely to web browsing and the other to code signing. I find this extremely unlikely. >Attacks on Encrypted Key material > >There is some confusion over the algorithms and methods that Microsoft uses to >provide protection of encrypted key material in Internet Explorer when using >the standard Microsoft base CSPs. There were changes between Internet Explorer >3.0x and Internet Explorer 4.x specifically to address any possible concern. And the astounding thing was that, despite a complete rewrite of the code, the newer version offers no extra security at all, as my article points out. Both are equally weak, you just need to attack them in slightly different ways. >Key export attacks > >The original Internet posting raises concern about the CryptoAPI interface >CryptExportKey(). This function is fully documented and does indeed export >private key material in an encrypted format. The statement from Microsoft omits one important point here. Myself and another security researcher have been trying to tell Microsoft for more than four months (probably a lot longer, I didn't log the earlier mail) that this is a very serious security flaw. In all cases Microsoft's response was some variation of "We don't see this as a flaw". It wasn't until my warning was published that they finally addressed the problem, and even in this case (the program to set the CRYPT_USER_PROTECTED flag) it's only a quick hack to plaster over the cracks and allow them to declare the problem fixed. In fact it doesn't fix the problem at all. I'll post details in a fortnight or so when I've had time to test things, please don't ask me about this until then. >The presence of the CryptExportKey() function is to support functionality such >as migrating key material between machines for a user or creating a backup >copy of a key. It should be noted however, that many CSPs, including most >hardware based CSPs, do not allow exportable private keys and will return and >error in response to a CryptExportKey() request. However the CSP's installed by default on every recent system do allow the export. The fact that there may exist, somewhere, an implementation which doesn't exhibit this flaw really doesn't help the majority of users. >The posting also asserts that an ActiveX control could be downloaded from a >web page, simply ask for the current users key, ship the key off for >collection by an unscrupulous person, and then delete itself without a trace. > >If users run unsigned code, or code from an unknown origin, a number of >unpleasant things can happen. This could indeed occur if the key as been >marked exportable and the CRYPT_USER_PROTECTED flag is not set. Which was, until my warning, the automatic default action for Verisign, and is still the automatic default for many other CA's. This means that keys generated right up until a few days ago (and in some cases keys being generated right now) have, by default, no protection whatsoever. In addition I've just been sent mail to say that CRYPT_USER_PROTECTED still isn't the default with Verisign, you have to click a box asking for extra security or you get the usual default of no protection. To add to the confusion, a lot of documentation (including the Microsoft Developer Network (MSDN) online documentation on Microsofts web site) describes the CRYPT_USER_PROTECTED flag with "The Microsoft RSA Base Provider ignores this flag", which can cause programmers to leave it out when it is *essential* it is always included. Incidentally, MSDN also claims that Microsoft are "supporting" PFX, which is in direct contrast with the claims in their press release. >There was also discussion of 16 dialog boxes appearing to the user for their >password if the CRYPT_USER_PROTECTED flag is set. Certainly asking the user >too many times would be better than too few times, however in our tests, under >extreme (and uncommon cases), a user might be asked for their password at most >four times when a key is used with the Microsoft base CSPs. Perhaps the claim >came from an early beta release. The 16 dialog boxes problem was present in 4.0, and it's been confirmed as still being present in 4.01. This was apparently verified on Microsoft's own CryptoAPI mailing list (the claimed "beta" version was actually MSIE 4.0 final). >Microsoft is constantly working to improve the security of our products. Myself and another person had been trying to convince Microsoft for more than four months that things like CryptExportKey() are a major security hole. Their response each time has been some variation of "We don't see this as a problem". It simply wasn't possible to get them to acknowledge these flaws, therefore my posting of the details wasn't "irresponsible" (as some have claimed) but a necessity in order to get them fixed. When I pointed out several months ago that Microsoft were using, in their pre-4.x products, an exported key format which was identical to the one which I broke more than 1 1/2 years ago, their response was "What's the problem with this?". I would have liked to have included URL's for the CryptoAPI mailing list archives to prove that Microsoft were warned of these problems some time ago, but the CryptoAPI archive seems to be temporarily offline. Risks of a Private Key Compromise --------------------------------- One or two respondents have tried to play down the seriousness of a private key compromise, saying that I exaggerated the dangers in my original message. What I wanted to point out was how extremely valuable a users private key is, and how disappointingly little concern Microsoft seem to have for protecting this valuable resource. For example Garfinkel and Spaffords "Web Security and Commerce" (O'Reilly, 1997) contains the warning: "Today's PC's are no better at storing private keys once they have been generated. Even though both Navigator and Internet Explorer can store keys encrypted, they have to be decrypted to be used. All an attacker has to do is write a program that manages to get itself run on the users computer (for example by using [...] Microsoft's ActiveX technology), waits for the key to be decrypted, and then sends the key out over the network" (p.120). Including a function like CryptExportKey() (which hands over a users private key) makes this very attack possible. The potential damage which can be caused with a misappropriated private key is enormous. Consider the relative risks in the compromise of a logon password and a private key. With a logon password, the worst an attacker can do (apart from stealing possibly valuable data) is to trash the victims hard drive, which involves reinstalling the operating system (an action which many users are intimately familiar with). In contrast an attacker who obtains a private key can potentially drain the victims credit card, clean out their bank account (if the victim uses one of the emerging online banking services), sign documents in their name, and so on. The implications of that last point can be quite serious. Take for example the Utah digital signature act, which was used as a model by a number of other states who implemented or are implementing digital signature legislation. Under the Utah act, digitally signed documents are given the same evidentiary weight as notarised documents, and someone trying to overcome this has to provide "clear and convincing evidence" that the document is fraudulent, which is difficult since it bears a valid signature from the users key (this fact has been used in the past to criticise digital signature laws based on this act). In addition, under the Utah act and derived acts, anyone who loses their private key bears unlimited liability for the loss (in contrast, consumer liability for credit card loss is limited to $50). This leads to the spectre of a malicious attacker who has the ability to issue notarised documents in your name for which you carry unlimited liability. This is a lot more important than someone reformatting your hard drive, or stealing last months sales figures. Peter.

2 1

Knapsack-based cryptosystems
by Eamon Daly 17 Dec '03

17 Dec '03

Some convoluted questions for knowledgeable c'punks: What's the state-of-the-art in cryptanalysis of knapsack-based cryptosystems? I know the fate of Merkle-Hellman, Graham- Shamir etc. as written by Brickell and Odlyzko in _Contemporary Cryptology_ (edited by Simmons). What of the Chor-Rivest cryptosystem (I'm aware of the attack in Eurocrypt 95)? Finally, has any work been done on cryptanalysis of the dense compact knapsack-based cryptosystem of Glenn Orton? ("A Multiple-Iterated Trapdoor for Dense Compact Knapsacks" in _Eurocrypt 94_) Thanks for any information. Eamon Daly

1 0

Scientists in Black
by John Young 17 Dec '03

17 Dec '03

In "Scientists in Black,"Jeffrey Richelson, noted intel author, surveys use of vast archives of classified intelligence data by select civilian scientists under the Medea program (SciAm, Feburary 1998). http://jya.com/sib.htm (40K with 4 images) Thanks to PJP for pointing.

1 0

Wooden sculpture
by bill payne 17 Dec '03

17 Dec '03

Friday 6/26/98 7:44 PM John Young I am reading http://www.jya.com/gak-fails.htm Tonight I retrieved a wooden sculpture given to me by numerical analyst LINPACK http://av.yahoo.com/bin/query?p=linpack&z=2&hc=0&hs=0 Richard Hanson. That's him! http://www.vni.com/products/imsl/hanson.html Hanson gave me the sculpture in about 1978. Hanson and I have been colleagues for about 25 years. I will forward it to you. With initials on the bottom. And, of course, YOU must pass on the sculpture to the NEXT DESERVING. Our buddies aren't happy about what happened. http://www.wpiran.org/ Allahu akbar ... and keep up wind. Until we get SETTLMENT, of course. Settlment must include support payments for Iranian mothers who lost sons in the Iraq/Iran war, retirement benfits for them, health insurance and a LETTER OF APOLOGY. All paid for by NSA and the CIA. We are ALL working for settlment. bill http://www.apcatalog.com/cgi-bin/AP?ISBN=0125475705&LOCATION=US&FORM=FORM2 http://www-hto.usc.edu/software/seqaln/doc/html/gfsr.3.html

1 0

Re: Netscape gives in to key escrow
by tcmay＠got.net 17 Dec '03

17 Dec '03

With the assumption that this is not a troll, and giving the writer some slack on account of the non-native-English-language origin, I'll respond to a few of his or her points: At 10:45 AM 12/1/95, JR(a)ns.cnb.uam.es wrote: >With regard to all this waving about Netscape giving in to key scrow... Key _escrow_, though "scrow" is perhaps just as accurate as the improperly-named "key escrow" (hint: escrow is something done voluntarily, not the situation here with GAK). >First one question, and then some considerations. The question: > >- How much of Netscape stock is in the hands of Netscape? I mean in the hands >of the people that work in/for the Company? And how much is in outsiders whose >only interest is earning as much as possible? A small fraction of the shares are now for sale. The exact numbers can be gotten from the Netscape offering prospectus (ironically, I tried to hunt for it in Infoseek, but Netscape claimed it was busy the 10 or so times I tried to run Infoseek on "Netscape"...no conspiracy, just crowding, even at 1:45 a.m. PST). In particular, the billion dollars' worth of Netscape stock (and/or options) that Jim Clark holds is mostly not on the open market (and won't be for years). Having said this, I think all of the shareholders, either of issued shares or as-yet-unissued shares, are interested in maximizing share value. Not surprising. Importantly--and maybe this is the real point JR is making--we on the Cypherpunks list are probably *not* interested in Netscape's stock price. But who cares? Our role is not to maximize Netscape stock price, but to talk about what is "right" and what is not right. And GAK is definitely not right, to the vast majority of us. >That is, my friends, the key point. When Netscape began selling shares, and >before and after that, they were (and still are) widely criticized in this >list. They were "criticized" not because they went public with their stock but because of their security mistakes, made more important by their sudden prominence. The Net/Web is being built up of beams, struts, and bricks, and it's important to point out flaws that make the beams buckle and structures collapse. ... >So, now we have that most of Netscape is owned by people that either don't >care but for money, or fundamental activists. And then, those people have to >take decisions. ??? I don't get the point you're making. Sure, most of Netscape stock that is publically traded is owned by investors. On the other hand, most of the stock that is not yet issued or is tied up in unexercised stock options is in a sense owned by people who care how well the stock does. >And then they are faced with confronting their government who tells them what >to do if they don't want to have problems. And who probably offers some hidden >compensations to get their support (maybe tax reliefs?). And who menaces with >countermeasures if they don't agree. Well, this is the point, isn't it? I doubt there are such things as "tax reliefs" for Netscape--these things are done pretty much out in the open in the U.S., and any special tax treatment would be widely noticed--but there may indeed have been "discussions" with senior management at Netscape. Several of us have already speculated in broad terms on this. Look, I don't impute personal malice to Jim Clark. I do, however, believe in "institutional evil," in the sense that a GAK regiment which says, for example, that anyone who keeps a diary must "escrow" copies of it with the local police is an "evil" idea, counter to the Western notions of liberty and justice. Thus, for whatever reason Jim Clark came out in support of GAK, we must criticize it. And take positive steps to counter it (which I think we are doing). >What did you expect Netscape to do? The guys with the money and the control >won't face all the small shareholders and tell them they are going to be >"evil" against the gov. and the priests and the religious organizations, >and that they will face gov. restrictions, give up political and economic >advantages, etc.. to satisfy a bunch of cypher >punks that are continuously >complaining publicly against the company and don't even buy shares. First, a viable strategy is to simply do nothing. Ignore the goverment's protestations, drag one's feet, shrug, etc. Jim Clark could simply have said nothing. (Recall that Bill Gates came out recently saying that strong encryption is inevitable...Clark could have either said nothing, or said something similar to what Gates said.) Second, the issue is not "satisfying" a "bunch of cypherpunks." If Netscape truly pushes for GAK, and people reject GAK and Netscape, then this will surely hurt shareholder value. (Frankly, I expect one or more stories to appear in the next few days about the budding "Friends Don't Let Friends Use Netscape" and "Just Say No to Netscape" movements. Whether this will hurt the stock is unclear.) >Sitting back and complaining won't help crypto, freedom or anything for that >matter at all. > >That said, before blaming more on Netscape and asking a starting company >whose major aset is still shareholders instead of sales, we should think >better about the correct strategy. > >Now, who's gonna offer some constructive ideas for a change? I say that the ideas being discussed are in fact "constructive" ideas. I won't reiterate them all here, but they clearly involve concrete action (e.g., modifying server software to issue warnings to Netscape users, or encouragement of alternatives to Netscape). What more are you expecting? Have you been reading what people are actually discussing doing and actually already doing? --Tim May Views here are not the views of my Internet Service Provider or Government. ---------:---------:---------:---------:---------:---------:---------:---- Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)got.net 408-728-0152 | anonymous networks, digital pseudonyms, zero Corralitos, CA | knowledge, reputations, information markets, Higher Power: 2^756839 | black markets, collapse of governments. "National borders are just speed bumps on the information superhighway."

1 0

Re: Barring access to Netscape
by Frank Stuart 17 Dec '03

17 Dec '03

>If Netscape really does go the GAK route, I will unilaterally >do this to the Cypherpunk Archives (or something similar, like every >request flashing up briefly and then client-pulling the GAK pages). After talking to a couple of people, and playing around some, this seems to be a better choice. That way, you can actually send information (including a list of where to get other browsers) instead of just garbage to netscape users. Is anyone aware of browsers other than Netscape that do client pulls? A simple filter to do (and undo) this would still be useful, I think so that users can easily fix all their documents. Fortunately, that would be very easy to write. >I've been told that many media-types go to the archives whenever c'punks >make the news. How much of an effect do y'all think it'll have if they >can't do it with Netscape? > >Shouldn't be too hard to hack this into Apache. That's not a bad idea either. Hopefully, Netscape will post a retraction (soon!) and none of this will be necessary. Frank Stuart | (Admiral Grace) Hopper's Law: fstuart(a)vetmed.auburn.edu | It's easier to get forgiveness than permission.

3 2

NSA advanced knowledge
by Rich Salz 17 Dec '03

17 Dec '03

Is there any indication that the NSA knew about public-key before it entered the open literature?

2 1

nsa and netscape
by Bob Bruen, MIT Lab for Nuclear Science 17 Dec '03

17 Dec '03

The following came from a government source. I thought it might be of interest. Bob -------------------------------------------------------------------------- At yesterdays FNC (Federal Networking Council) meeting it was mentioned in passing that NSA has given Netscape a grant of $5 Million (yes $5M) to beef up the security features of Netscape. More info will be forthcoming on this.

5 4

Gilbert Vernam
by bill payne 17 Dec '03

17 Dec '03

Tuesday 2/3/98 7:02 AM John Young J Orlin Grabbe The crypto problem was solved in 1918. Vernam and Maugborne [sp?] did the work. Gilbert Vernam in 1918. Vernam used two tapes of random characters to generate the additional characters. With the same tapes at each end set to the same start position this system was unbreakable. The Germans decided that the distribution of these key tapes presented too great an operational problem and the Lorenz machine uses a complicated mechanical gearing and cam system to generate a pseudo random sequence with very long period and 10^19 complexity. They thought this was good enough to ensure unbreakability, it wasn't! Fushimi's implementation of Lewis and my GFSR algorithm has period of 2^521 - 1. And LOTS of possible starting seeds. John Young kindly posted my article on putting non-singular binary matrices in one-to-one correspondence with the natural numbers. Although the period of a shift register can be 2^521 - 1, 521 bits determines THE EXACT SEQUENCE of the remaining 2^521 - 522 bits. Pseudorandom numbers generators have an easier job than bits used for cryptography. Pseudorandom number generators merely have to deceive statistical tests. Orlin Recall the GIANT radio transmitter in the south of Russia, perhaps Baku. I heard on PBS TV that it was transmitting a shift register sequence. The Russians were apparently trying to communicate with underwater submarines. NSA crypto algorithms mostly rely on shift register sequences - both linear and NON-LINEAR. The R register in my SAND report posted at jya.com implements a non-linear SECRET/NSI feedback algorithm. Perhaps someone may have to put NSA's SECRET/NSI R register non-linear feedback function out on the web some time. So that every one can have a good laugh, of course. Like for the SECRET/NSI number 31 algorithm step. John Young Judge Svet made a ruling. I sent a copy to you by snail mail. Later, bill Title: Colossus Rebuild The Colossus Rebuild Project by Anthony E Sale, FBCS A bit of History Colossus was designed and built at the Post Office Research Laboratories at Dollis Hill in North London in 1943 by a team led by Dr Tommy Flowers to help Bletchley Park in decoding the intercepted German telegraphic cipher traffic enciphered using the Lorenz SZ42 cipher machine. Lorenz SZ42 cipher machine at Bletchley Park This cipher machine enciphered electrical teleprinter signals which used the international 5 bit Baudot teleprinter code. It enciphered the input plain text by adding to it successively two characters before transmission. Because this addition was bit by bit modulo 2, at the receiving end with the Lorenz machine set to the same start position, the same two characters were added again to the received characters revealing the original plain text. This scheme had been developed in America by Gilbert Vernam in 1918. Vernam used two tapes of random characters to generate the additional characters. With the same tapes at each end set to the same start position this system was unbreakable. The Germans decided that the distribution of these key tapes presented too great an operational problem and the Lorenz machine uses a complicated mechanical gearing and cam system to generate a pseudo random sequence with very long period and 10^19 complexity. They thought this was good enough to ensure unbreakability, it wasn't! A bibliography of works discussing the Lorenz cipher has been compiled by Frode Weierud is availabe here by permission. As is a book chapter describing the Swedish effort to crack Lorenz. The German high command thought that the Lorenz machine was completely unbreakable and used it for their most secret messages, literally from Hitler to his generals and between generals. The interception and deciphering of these messages gave Generals Eisenhower and Montgomery vital information prior to and after D Day in 1944. Colossus was the world's first large electronic valve programmable logic calculator, not just one but ten of them were built and operational in Bletchley Park the home of Allied WW II codebreaking. The question of what is the worlds first computer is less a question of history than a question of definition. The Mark 1 at Manchester (1948) is a strong contender. A view of Colossus Colossus found the wheel settings used by the German Lorenz machine operator for a particular message. When these had been found, which took about two hours, they were plugged up on the Tunny machine. It was this machine which actually deciphered the message. This is the Tunny room in Bletchley Park in 1945. Colossus, hardware details Input: cipher text punched onto 5 hole paper tape read at 5,000 characters per second by optical reader Output: Buffered onto relays: Typewriter printing onto paper roll Processor: Memory 5 characters of 5 bits held in a shift register. Clock speed 5kc/s derived from input tape sprocket holes. Internally generated bit streams totalling 501 bits in rings of lengths equal to the number of mechanical lugs on each of the 12 Lorenz wheels. A large number of pluggable logic gates. 20 decade counters arranged as 5 by 4 decades. 2,500 valves. Power supplies +200v to -150v at up to 10A. Power consumption 4.5KWatt Size: Two banks of racks 7ft 6inches high by 16ft wide spaced 6 ft apart. Bedstead, 7ft 6inches high 4ft wide by 10ft long Colossus, operating cycles The basic machine cycle: read a character from tape, get bits from bit stream generators, perform up to 100 logic operations, clock result into decade counters. The cycle determined by the input tape: The intercepted enciphered text tape is joined into a continuous loop with about 150 blank characters in the join. Specially punched start and stop holes indicate the beginning and end of the cipher text. On receipt of start hole pulse: Start bit stream generators and send sampling pulses to reader output. Execute basic machine cycle until receipt of stop hole pulse: Staticise counter states onto relays. After a delay, reset counters and reset bit stream generators to a new start position. Colossus programming All programmes hard wired, some permanently, some pluggable. Conditional jumping possible between alternative programmes depending on counter outputs. The Rebuild Work on the rebuild started two years ago with the collection of all available information about Colossus, including a series of official photographs taken in 1945. The first stage was to produce accurate machine drawings of the frames for Colossus (all the original machine drawings had been burnt in 1960). This involved three months of eyestrain pouring over the photographs and using 3D projections to transfer the details to a CAD system, EasyCad running on a 486 PC. Next problem was the optical paper tape reader system. The details of this are not shown in any of the photographs. However I managed to locate Dr Arnold Lynch who designed the reader system in 1942. Although well into his 80's Dr Lynch came to my house and using my CAD system we re-engineered the reader system to his original specifications. Then I built it and here it is. It uses original Colossus hard vacuum photocells, shown here on the left and a mask onto which the image of the tape is projected by a Colossus lense. All the racks are now in place. Here are some of the decade counters. We are also rebuilding the Tunny machine. The current state of Colossus: Jan 96 Examples of most of the circuit panels are now working and the whole machine is working at one bit level. We are now rapidly cloning circuit panels to populate all the racks. I need lots more valves: EF36, 37 or 37A pentodes, 6J5 triodes, 6V6 tetrodes and GT1C gas filled triode thyratrons. The 6J5's and 6V6's should be the large glass versions to look right. Please send any contributions, valves or money, to me (Tony Sale) at "The Colossus Rebuild Project, 15 Northampton Road, Bromham, Beds MK43 8QB" tel: 01234 822788 email: TSale(a)qufaro.demon.co.uk Come and see the Colossus Rebuild, the Lorenz machine and codebreaking exhibitions in Bletchley Park. This page was created by Tony Sale (tsale(a)qufaro.demon.co.uk) of the Bletchley Park Trust, and has been modified by Jeff Goldberg (J.Goldberg(a)Cranfield.ac.uk) of the Cranfield University Computer Centre. Title: Cryptome Cryptome JYA/Urban Deadline OpEd _______________________________________________________________________________________ File Topic Date _______________________________________________________________________________________ sib.htm Scientists in Black February 3, 1998 CAP The Cryptographic Analysis Program (offsite) February 2, 1998 Arne Beurling The Geheimschreiber Secret (offsite) February 2, 1998 Army Stegano US Army Steganography (offsite) February 2, 1998 <A HREF="http://www.cranfield.ac.uk/ccc/bpark/colossus.htm ">Colossus Rebuilding Colossus (offsite) February 2, 1998 Frode Crypto Cryptology Papers (offsite) February 2, 1998 jimbell9.htm Jim Bell Update February 2, 1998 echelon-boost NSA Surveillance System Boosted (offsite) February 2, 1998 cn020298.txt Crypto News February 2, 1998 bxa020298.txt BXA Meet on Export Rules and Procedures February 2, 1998 cs020298.txt Rules to Challenge Customs Seizures (63K) February 2, 1998 usg020298.txt USG Secret Meets February 2, 1998 echelon.htm NSA Global Surveillance System February 2, 1998 cathedral.htm The Cathedral and the Bazaar February 1, 1998 natsec-rule.htm Protection of National Security Information February 1, 1998 47cfr216.txt National Communications Issuance System (106K) February 1, 1998 47cfr213.txt Emergency Telecomms Precedence System (17K) February 1, 1998 47cfr202.txt National Security Emergency Plans & Ops (27K) February 1, 1998 47cfr201.txt Policy for Telecomms During Emergencies (12K) February 1, 1998 44cfr336.txt Facilities for National Security Emergency (14K) February 1, 1998 44cfr334.txt FEMA Graduated Mobilization Response (14K) February 1, 1998 32cfr322.txt Privacy Act Exemption for NSA Records (40K) February 1, 1998 32cfr299.txt National Security Agency FOIA Program (8K) February 1, 1998 32cfr2101.txt National Security Council FOIA Requests (24K) February 1, 1998 32cfr185.txt Military Support to Civil Authorities (52K) February 1, 1998 31cfr9.txt Effects of Imported Articles on National Security February 1, 1998 22cfr124.txt Contracts, Off-Shore Buys, Defense Services (42K) February 1, 1998 22cfr123.txt Licenses for the Export of Defense Articles (51K) February 1, 1998 22cfr121.txt United States Munitions List (92K) February 1, 1998 _______________________________________________________________________________________ ntia-dnsdrft.htm Draft Proposal for New Domain Name System January 30, 1998 korczak.txt Boris Korczak: CIA Agent Seeks Payment January 30, 1998 pm87.txt Prez on Terrorist Threat to Middle East Peace January 30, 1998 leahy-wipo.txt Senator Leahy on Ratifying WIPO Treaties January 30, 1998 32cfr147.txt DoD: Policies for Access to Classified Info January 30, 1998 32cfr148.txt DoD: Facilities for Storing Classified Info January 30, 1998 32cfr149.txt DoD: National Policy on Technical Surveillance January 30, 1998 ntia012798.htm RFC: Self-Regulation for Privacy Protection January 30, 1998 cylinked.htm Latest: Cylinked to Organized Crime? January 29, 1998 websoft-warn.htm Web Software Warning January 29, 1998 scant-peril.htm U.S. Spy Agencies Pauline Peril January 29, 1998 mossburg.htm E-Comm Forum on E-Authentication and DigSig January 29, 1998 pollard.htm Bankers O Table on E-Authentication and DigSig January 29, 1998 brown.htm Secret Service on Financial Instruments Fraud Janaury 29, 1998 rpk-hack.htm Invite to Hack RPK InvisiMail January 29, 1998 nrc012998.txt Generic Letter on Y2K Readiness for Nuke Plants January 29, 1998 fc012998.txt FinCEN RFC on Information Collection January 29, 1998 dtc012998.txt Arms Export to Saudi Arabia January 29, 1998 nsa-etc-nf.htm NSA, Echelon, Trade & Crypto/Netscape & Fortify January 28, 1998 dod012898.txt DoD Blacklist of Higher Education January 28, 1998 47usc1002.txt Interception of Digital and Other Communications January 28, 1998 cn012898.txt Crypto News January 28, 1998 cn012798.txt Crypto News January 27, 1998 bxa-fy98.txt BXA Funding FY 1998 January 27, 1998 cia-tsang.htm CIA Concedes Spying on Americans January 26, 1998 atpc.htm EU-Parliament: Technologies of Political Control January 26, 1998 us-crypto.htm US Crypto Policy January 25, 1998 pg-nzcrypto.htm New Zealand Crypto Policy January 24, 1998 ra-ukcrypto.htm UK Crypto Policy January 24, 1998 whp012398.htm Payne/Morales vs. NSA: Reply to Defendant January 23, 1998 kellner.htm Intellectuals and New Technologies (66K) January 23, 1998 bxa012398.txt BXA Penalizes Export Violator January 23, 1998 osd012398.txt Compensation of North Viet-Imprisoned Operatives January 23, 1998 dod012398.txt Defense Dept Secret Meets January 23, 1998 walton-pk.htm GCHQ: The Pre-History of Public Key Cryptography January 22, 1998 primer The Proliferation Primer (offsite) January 22, 1998 sh105-238.txt Proliferation and US Export Controls (196K) January 22, 1998 sh105-267.txt Safety and Reliability of US Nukes (347K) January 22, 1998 acda012298.txt Arms Control Secret Meet January 22, 1998 pd012298.txt Prez Notice on Mideast Terrorism Emergency January 22, 1998 bia012298.txt Rule on Indian Casinos January 22, 1998 cn012198.txt Crypto News January 21, 1998 fc98.htm Financial Cryptography '98 January 20, 1998 doj-ssgsup.htm Supplement to Fed Guide for Seizing Computers January 20, 1998 cn-netreg.htm New Chinese Internet Regulations January 20, 1998 pg-get-MSkey.htm How to Recover Private Keys for Microsoft Wares January 20, 1998 ietf-dea-97.htm IETF Draft Encryption Algorithms 1997 January 20, 1998 radio-rec.htm Update: Locating Radio Receivers; Encoder Stolen January 20, 1998 pipenet.htm PipeNet Description January 20, 1998 dod012098.txt Defense Dept Secret Meets January 20, 1998 bernstein12.htm Transcript of Bernstein Hearing January 19, 1998 fbi-umbc.htm Barry Smith (FBI) to Speak on Encryption Policy January 18, 1998 de-snoop.htm Update: German Surveillance State January 17, 1998 bxa-wa-rule.htm Update 2: BXA Rule on the Wassenaar Arrangement January 16, 1998 pd98-10.htm Prez OKs China's Nuclear Controls January 16, 1998 tcryptol Theory of Cryptography Library (offsite) January 16, 1998 cn011698.htm Crypto News January 16, 1998 nsasuit8.htm USA/NSA Responds to Payne/Morales Motion Janaury 16, 1998 dod011698.txt Defense Dept Secret Meets January 16, 1998 bxa011398.txt Materials Advisory Meet January 15, 1998 crypto-kong.htm Announcing Crypto Kong January 15, 1998 occ-dstc.htm OCC OKs CA as Authorized Banking Activity January 14, 1998 aes-980820 Advanced Encryption Standard Conference (offsite) January 14, 1998 ustr010898.txt Update: Telecommunications Trade Agreements January 14, 1998 rc2.htm Rivest Describes RC2 Encryption Algorithm January 13, 1998 fc011398.txt FinCEN Regulates Card Clubs January 13, 1998 ta011298.txt Key Management Infrastructure Meet January 12, 1998 nist011298.txt Transmission-Electron Microscopy Meet January 12, 1998 doa011298.txt Army Hazard Containment Invention January 12, 1998 gps-jam.htm GPS Jamming January 11, 1998 arthur.htm The Force of An Idea: Theory of USA v. Microsoft January 10, 1998 RSA-stego.htm Batch RSA for Stego Data January 9, 1998 batch-DSA.htm Batch DSA January 9, 1998 cell-track.htm Update 2: Mobile Cell Phone Surveillance January 9, 1998 fiat-rsa.htm Fiat's Batch RSA January 9, 1998 aes010798.htm Update: Advanced Encryption Standard January 9, 1998 doj010998.txt RFC: USA v. IBM/STK Antitrust Suit January 9, 1998 bmd010898.txt Ballistic Missile Defense Secret Meet January 9, 1998 nih010898.txt Commercialization of Medical Data January 9, 1998 fas-pde Prez Directives/Executive Orders (offsite) January 7, 1998 ussc-ecopy.htm Sentencing for Electronic Copyright Violations January 6, 1998 ussc010698.txt RFC: US Sentencing Guidelines (254K) January 6, 1997 mercier.htm Terrorists, WMD, and the US Army Reserve January 6, 1998 terror-rnd.htm US Counterterrorism R&D Program January 6, 1998 belet Bob East Letter on AP/Jim Bell/IRS (offsite) January 6, 1998 pitfalls Schneier: Security Pitfalls in Crypto (offsite) January 5, 1998 dsb010598.txt Defense Science Board Secret Meets January 5, 1998 ntia010598.txt Funds for Public Telecommunications January 5, 1998 cn010598.txt Electronic Surveillance News January 5, 1998 csda.htm Cypherpunks Smartcard Developer Association January 4, 1998 aimd-98-21.htm Executive Guide: Info Security Management (139K) January 3, 1998 blast-mono.htm Blast Resistant Doors Monograph January 3, 1998 tempest-door.htm Electromagnetic Shielding/TEMPEST Door January 3, 1998 ehj.htm Banned Basque Video: Democratic Alternative January 3, 1998 fda010298.htm Policy for External Penile Rigidity Devices January 2, 1998 doe010298.htm Defense Nuclear Facilities Safety Plan January 2, 1998 dos010298.txt Meet on Global Communications and Info Policy January 2, 1998 doa010298.txt Army Science Board Meet January 2, 1998 _______________________________________________________________________________________ Cryptomb 2 June-December 1997 Cryptomb 1 To May 31 1997 (site stats) DoE: Pay Bill Payne DoJ: Free Jim Bell

1 0

RE: The Continued Attack on Cash (Was: "The Right of Anonymity"...)
by James O'Toole 17 Dec '03

17 Dec '03

Tim, the "social pressure" I was referring to is the process through which the obstacles to privacy-protecting measures are created and enforced. Examples include both government regulation, which derives part of its support from publicity connecting cash with money laundering with drugs and/or crime, as well as finality/liability rules within non-government financial consortiums, which may strongly encourage proof-of-identity. Let's take your example of the Institute of Applied Ontology (IAO) corporate Amex card (Ax)... Even with no relevant government regulations, we may find that Ax's agreement with merchants requires Ax to at least either pay the merchant or reveal to the merchant all relevant information known to Ax about the cardholder. The right contract terms between the merchant and Amex will be good for them, and may be good for most consumers, and could easily be sub-optimal for the subset of consumers who highly value privacy. The impracticality of negotiating special terms with each merchant means that the best plan to get the privacy/anonymity you want may be to set up a card such that Amex will be willing to operate without knowing much about the cardholder. I assume that's the intent of your IAO corporate Ax card. What allocation of the liability for card usage do you expect among Amex, IAO, and the cardholder? Amex will want the liability allocated to IAO and the cardholder, and if Amex does not possess traceable identity information on the cardholder, then Amex will want an enforceable promise to pay from IAO. To get this, or even to get funds in advance from IAO, we will find that Amex ends up knowing a lot about the identity of IAO or one of its officers. Pretty soon we'll run up against the problem of whether Tim May can configure a corporate in the U.S. to be operated by people who don't know who he is, and who can't find out who he is (when properly encouraged to cooperate by Ken Starr...). With or without government regulation, the most reliable people you can hire to operate that corporation for you may only want to do so if they are given the opportunity to somehow "know" you. I think you can probably use a bank in a privacy-enhancing-locale such as Switzerland as an effective intermediary in Amex card issuance, but if you really don't want the bank to know who you are, you'll probably need a corporate intermediary between you and the bank, with nominee officers. The real trick is probably to structure the whole thing so that neither the bank nor the nominee officers have anything to lose, including their reputations. As long as part of their reputation is that they don't act as front men for drug dealers and criminals, we may find that they keep trying to find out enough about who you are to satisfy themselves that you are a good guy. That's the social pressure flexing its muscles. >An interesting question about the Privacy Card product is whether the >social pressure against it is strong enough to defeat its privacy whenever >the product is well advertised. In other words, will a privacy product >survive in spite of its own publicity in our current environment, or can Corporate cards are already widely accepted...most of you probably have a card issued to you through your employing institution. I see no "social pressure" to block usage of my Institute of Applied Ontology corporate AmEx card. The real roadblock is that government makes such privacy-protecting measures either difficult or illegal. --Tim May The Feds have shown their hand: they want a ban on domestic cryptography ---------:---------:---------:---------:---------:---------:---------:---- Timothy C. May | Crypto Anarchy: encryption, digital money, ComSec 3DES: 408-728-0152 | anonymous networks, digital pseudonyms, zero W.A.S.T.E.: Corralitos, CA | knowledge, reputations, information markets, Higher Power: 2^2,976,221 | black markets, collapse of governments. "National borders aren't even speed bumps on the information superhighway."

2 1