December 2003 - cypherpunks-legacy

Re: SSL trouble
by Will French 17 Dec '03

17 Dec '03

Scott Brickner writes: > We've identified several forms of "real-world retaliation:" > 1) "Result hoarding" - failure to report a found key > 2) "Segment hoarding" - requesting more segments than one can hope to search > 3) Denial of service - preventing access to the server Perhaps I wasn't clear... by real-world retaliation, I'm referring to being sued, thrown in jail, belabored about the head with blunt objects, etc. The three basic defenses I have are: (a) not getting people angry, (b) not letting them know who to be angry at, or (c) the threat of counter-retaliation. The "random" method is of type (b). I think you are focusing a bit too much on theoretical efficiency and not enough on bottom-line practicality. A 37% waste factor is better than staying in bed and wasting it all. >> I _don't_ care about the procedures, as long as I can get >> the information I need to go my own way. > So what information wouldn't you be getting? To "go your own > way", you need exactly the same information that the client > workstations use to test one key. The difference in your code > and the clients exists solely in how they determine the next > key to try. Yes, this is currently true, but there was a suggestion of witholding part of the challenge in order to keep people honest, or something like that. I didn't quite understand it, but I didn't like it. Will French <wfrench(a)interport.net>

1 0

Re: Florida Drivers Permits and a Hello
by d-jones＠ix.netcom.com 17 Dec '03

17 Dec '03

>What possible value could the LEAs get by having your thumbprint digitally >encoded on your driver's license? It's not like the average cop-on-the-beat >is qualified to lift a fingerprint and compare it. Even if he was, how >does it benefit that the fingerprint is on the license? > >This seems silly. There are device that will electronicly read fingerprints available now. So with such a device, the LEO would know instantly if you were who you said that you were.

4 3

Netscape's RNG
by Ian Goldberg 17 Dec '03

17 Dec '03

Someone on the list (sorry, I forget who), suggested that Netscape's RNG be looked at to see if the secret part of the SSL RC4/40 master key could be determined more directly. I used gdb on the Solaris version. SSL_GenerateRandomBytes() is called when random bytes are needed. It initializes the RNG, if necessary, and then calls RNG_GenerateRandomBytes. When I run "netscape https://banking.wellsfargo.com/", SSL_GenerateRandomBytes() is called 3 times; the first time, 32 bytes are produced (I don't know what they're for); the second time, 16 bytes are produced (the Challenge data); the third time, 64 bytes are produced, the first 16 of which are the master key (the first 11 of which are sent in the clear, and the next 5 are our goal). Here's my own hand-reverse-assembly of RNG_GenerateRandomBytes: (Correctness not actually guaranteed in any way...) -----8<-----8<----- struct RNG { unsigned char md5bytes[0x10]; unsigned char randbytes[0x10]; int size; void *md5data; }; RNG_GenerateRandomBytes(struct RNG *i0, char *i1, int i2) { char buf[0x20]; int o1,o2; while (i2 > i0->size) { memcpy(i1, &(i0->randbytes)+0x10-i0->size, i0->size); i1 += i0->size; i2 -= io->size; if (err = MD5_Begin(i0->md5data)) return err; if (err = MD5_Update(i0->md5data, &(i0->md5bytes), 0x10)) return err; if (err = MD5_End(i0->md5data, &(i0->randbytes), buf, 0x10)) return err; i0->size = 0x10; o2 = 0; o1 = &(i0->md5bytes[0x0f]); do { if ((*o1)++) break; --o1; } while (++o2 <= 0x0f); } /* i2 <= i0->size */ memcpy(i1, &(i0->randbytes)+0x10-i0->size, i2); i0->size -= i2; return 0; } -----8<-----8<----- It looks like that Compilers course came in handy... So it's not linear congruential. I guess the next step is to figure out how it's seeded, but that not for me to do (at least not tonight...). Here's another question about a more direct method: The 5 secret bytes are encrypted with the server's public (RSA?) key. Does the server use the same public key every time? How do you read the public key, given the Certificate Data (what's the format of the certificate)? Is it feasible to try to attack the public key with a massively parallel (Internet) factoring program (a la RSA-129)? Assuming that the modulus is _big_, it still is worthy to note that, unlike cracking individual challenges, cracking the public key will compromise _all_ communications with that server (until they catch on and pay $$$ for another key (I think?)). Just some thoughts, - Ian "it's only 10pm _here_, but it's 2am in Nova Scotia!"

1 0

NIST Key Escrow meeting
by Flame Remailer 17 Dec '03

17 Dec '03

Subject: NIST Key Escrow Meeting Discussion Papers Key Escrow Issues Meeting, September 6-7, 1995 Discussion Paper #1 Issues -- Export of Software Key Escrowed Encryption On August 17, 1995, the Administration announced its proposal to permit the ready export of software encryption provided that the products use algorithms with key space that does not exceed 64 bits and the key(s) required to decrypt messages/files are escrowed with approved escrow agents. Under the proposal, products will be reviewed to verify that they satisfy the criteria and, if so, they will be transferred to the Commodity Control List administered by the Department of Commerce where the products can be exported under a general license (in much the same way that 40-bit RC2/RC4 encryption is licensed today). We are working toward creating broadly stated criteria that are in the nature of performance specifications. To meet these criteria, encryption products will need to implement key escrow mechanisms that cannot be readily altered or bypassed so as to defeat the purposes of key escrowing. The criteria, when finalized and published, will state the objectives, but not the exact technical method(s), by which those objectives are satisfied. This is to provide software publishers the flexibility to design methods for meeting our stated objectives in a manner that is compatible with the design of their products. There are, therefore, a number of questions we must work together to answer in order to draft effective criteria. These questions are: * Avoiding multiple encryption -- How can the product be designed so as to prevent doubling (or tripling, etc.) the key space of the algorithm? * Disabling the key escrow mechanism -- How can products be made resistant to alteration that would disable or circumvent the key escrow mechanism? How can the "static patch" problem be avoided? How can this be tested? * Access to escrow information -- What mechanisms must be designed into encryption products to allow authorized access to escrowed keys? This likely includes the identity of the key escrow agent(s) and a serial number for the key escrow agent to use to identify the key(s)/component(s) necessary to decrypt the message. What other information will be necessary to be provided to the escrow agent to identify the necessary key(s)/component(s)? Are there other comparable viable approaches? * Non-escrowed use -- How can products be made so that they do not function with non-escrowed products (or tampered escrowed products)? How can this be tested? * Limiting surveillance -- How can products be designed so that information both sent and received by the user can be decrypted without release of keys of other users? * Practical Key Access -- How can mechanisms be designed so that repeated involvement of escrow agents is not required for decryption for multiple files/messages during the specified access period? * Assurance that keys are escrowed -- How can it be assured that key escrow products are indeed satisfactorily escrowed? For example, products could be required to be escrowed at time of manufacture or be made inoperable until properly escrowed. * Ability to re-escrow keys -- How can products be designed so that new keys can be escrowed at the user's discretion with a U.S. Government approved escrow agent? * Certified escrow agents -- Can products be designed so that only escrow agents certified by the U.S. government (domestic, or under suitable arrangements, foreign) are utilized? What should be the criteria for an acceptable U.S. escrow agent? -------------- With your input, we are hopeful that this effort will lead to definitive criteria, which will facilitate the development of exportable products and help minimize the time required to obtain export licenses. The Administration seeks to finalize such criteria and make formal conforming modifications to the export regulations before the end of 1995. Note: These issues will be discussed at the Key Escrow Issues Meeting to be held September 6-7, 1995 (9:00 a.m. - 5:00 p.m.) at the National Institute of Standards and Technology (Gaithersburg, Maryland). The meeting will be open to the public, although seating is limited. Advance registration is requested, please contact Arlene Carlton on 301/975-3240, fax: 301/948-1784 or e- mail: carlton(a)micf.nist.gov. 8/25/94 ----------------------------- Key Escrow Issues Meeting, September 6-7, 1995 Discussion Paper #2 Discussion Issues: Desirable Characteristics for Key Escrow Agents In the government's recent announcement of its intent to allow the export of 64-bit software key escrow encryption products, one stipulation was that the keys would be escrowed with an approved key escrow agent.(*1) Exactly what qualifications/considerations are appropriate for approval as a key escrow agent have not been defined. Some of the issues which need to be discussed and resolved include the following: * What kinds of organizations should be excluded from consideration as approved key escrow agents? * What sort of legal agreement between the government and the key escrow agent is necessary to stipulate the responsibilities of the agent? Should this include the terms and conditions under which release of a key is required? * How will liability for unauthorized release of key be handled? * Should, for example, intentionally misreleasing or destroying a key be criminalized? Should this include other actions? * How can the government's needs for confidentiality of key release be handled? * Should approval of key escrow agents be tied to a public key infrastructure (for digital signatures and other purposes)? * What procedures need to be developed for the storage and safeguarding of keys? * What are the acceptable performance criteria (e.g., around- the-clock availability, accessibility, reliability, etc.) for approved key escrow agents? * Under what circumstances will key escrow agents in foreign countries be approved? * What process will be used to approve escrow agents? Costs/who pays? --------- (*1) "Approved," for the purposes of this discussion, means that the government (or its agent) has formally granted permission for an organization to hold keys for exportable encryption products. Note: These issues will be discussed at the Key Escrow Issues Meeting to be held September 6-7, 1995 (9:00 a.m. - 5:00 p.m.) at the National Institute of Standards and Technology (Gaithersburg, Maryland). The meeting will be open to the public, although seating is limited. Advance registration is requested, please contact Arlene Carlton on 301/975-3240, fax: 301/948-1784 or e-mail: carlton(a)micf.nist.gov.

1 0

The illegal markets of cyberspace
by Christian Wettergren 17 Dec '03

17 Dec '03

I guess I'll get a bunch of cypherpunkers on me now, even though I have the disclaimers/clarifications there. I am not opposed to anonymous services at all, ok? The inital idea behind this note, my main conclusion, is that NSA and others wont be able to estimate the amount of free computing power available "out there". The note outlines what I consider a probable scenario that will invalidate their estimates with a few orders of magnitude. If that is not enough, one can always bring out the big jack hammer: An combiner Internet Worm/SSL Bruter kidnaping the net for a number of hours. /Christian ---- To: Risks Digest This is a short note I wrote the other day. It points out a potential future risk, and also show existing problems with the FSP "proto-market". Also note that I am not opposed to anonymous services per se, I am only pointing out possible misuses of the technology. There are just as big risks in not deploying encryption and anonymous services, in going forward with a world without privacy and private spaces. /Christian THE ILLEGAL MARKETS OF CYBERSPACE by Christian Wettergren, cwe(a)it.kth.se Given the recent Brute-SSL efforts, together with the BlackNets and an eventual ecash exchange, there is a quite interesting situation emerging. The future markets of Cyberspace will be trading computing power, storage capacity and communications bandwidth, in addition to the more usually mentioned goods. This market for computing capabilities can be used for legitimate purposes as well as for illegal ones. I will here concentrate on the illegal uses, since they will prove to be a challenge to control. Computing power can yield pay-off in actual money, as the bruteSSL effort has quite convincingly shown. This can create a market for hiring computing power for illegal purposes. The actors on such a market can be quite safe, given the anonymity of the BlackNet and the tracelessness of ecash (DigiCash). There are other goods on the market as well; storage capacity and communication bandwidth. How would such a market be operated? The supply of "goods" for the market could be created by hackers breaking in to other's systems and hiring out the stolen capacity. The intruder could install a backdoor into a foreign system that would accept issued cryptographic access codes that would expire after a certain amount of time or usage. This makes it possible for the intruder to operate the business without having to go near the "scene of the crime". There is of course a certain risk that the intruder might lose the system to the hiring party, but that isn't such a big deal, since first of all its not his system, and second of all he may have booby-trapped the system for this case. The intruder would break into computers en masse, and install the backdoors as indicated above. They would then offer the stolen merchandise onto a BlackNet-like arrangement. Potential buyers would express their interests, and the broker of the BlackNet would connect the two together. The buyer and seller would agree on a price. The buyer would deposit the access codes, the seller the anonymous ecash by the broker, and the broker would effect the deal, taking a share of the profit. The buyer can then exchange his ecash for real money, or do whatever he wants with it. The seller brutes away onto whatever he wants, why not the SWIFT international banking system? The usage of stolen CPU cycles must of course be done in a careful way. The intruder would probably install some safeguards against excessive use, in his own interest. These safeguards could feature; * only using spare cycles, * monitoring superuser and sysadm activities, * hiding the process from system utilities like ps, * backing off during daytime hours etc. Other merchandise Storage capacity can be traded in a similar way, by setting up backdoor file server processes that listenes for the proper access codes. This kind of capacity could be used as anonymous post boxes, where you store secrets that you don't want to store at home, even if they are encrypted. It could also be used for bulk storage if it is cheaper than buying a new harddrive. Since this storage isn't offered by the proper owner, he can easily be very competetive. :-) There are of course a number of catches trading with stolen disk capacity, but they can quite easily be circumvented. To counter the privacy issue, all stored files will be encrypted by the submitter. This also eliminates potential evidence, if the proper owner discovers the illegal use of his resources. There is also a certain risk of losing the files if the area is discovered. This can be countered by storing the files in several locations. There is a third risk of traffic analysis of the file server. This analysis can be complicated by having a system of file servers that exchange files with each other, moving them around. In this scheme a buyer can submit a file in one location, and it can be stored in a totally different location. It will take a concerted action by several system owners to track down all their unwanted guests, so it is more likely they will only shut down the file server on their own system. Underground bases Trading communication bandwidth is somewhat more involved than the two previous ones, and cannot be traded without a portion of disk and cycles. It can however be worth a great deal to a potential buyer. Buyers of communication bandwidth is most likely setting up a service that is sold for profit. This service can probably not tolerate day-light and accountability, and hence needs to be anonymous. A good example of such a service is the emerging FSP-server black market, which has been souring during the last year and a half. (There have been lists circulating with several hundreds of FSP servers.) An FSP server is an anonymous file server where the users can freely upload and download files. These "black markets" of file exchanges has been used to trade porn, pirated music and pirated software. A site in Sweden recently caught students that had started such a server. 3 Gb/day went out through the server, and an estimated worth of $2 million in pirated PC programs were exchanged over it during it's three weeks of operation. The high volumes in the server was mainly due to the large amounts of available bandwidth out from the site. The example is not entirely good, since there is no money or ecash exchange in this case. The thing traded currently in the FSP buisness is instead the mere existance of a server, trading one piece of server access info for another. This is mainly because of lack of features in the FSP code, and not a fundamental feature of any such market. Communication bandwidth/service space rental is traded in a similar way as the other merchandise over the BlackNet system, with ecash exchange. The service provider will probably keep on using the site until the proper owner discovers it, since it is a hassle to move the service while running. What is the size of this potential market? I consider the estimates below conservative. Any illegal market would probably be much bigger, and constantly try to expand. Internet now has well over 3 million reachable computers. Lets assume 1 percent of them could be broken into at any one time, i.e 30.000 computers. Each computer is probably good for 5-10 MIPS, but assume we can use on average 1 MIPS without risk for discoverage. (We can probably use more during non-office hours, but maybe nothing during the day.) You can certainly use 10 Mb of ddisk storage on each computer without problems. This adds up to a constant 30 GIPS in computing power, and 300 Gb's of storage. And I believe this is a very conservative estimate, as I said. Conclusions I think it is quite likely that markets similar to those described above will emerge in a few years. There is already one primitive example of such a market in the FSP buisness, and we will most likely see more elaborate forms soon. The developement will accelerate once there is targets which will yield interesting pay-offs. Another conclusion is that all current estimates on available privately available CPU power for bruteforcing is likely to be _wrong_ in the face of such markets. The net has now shown several cases of doing the supposedly impossible; RSA-129, SSL1, SSL2, RC40 etc. The SSL2 effort, although impressive, I believe has only revealed a miniscule piece of what is possible to do. Observe that the current effort has all used volounteers, has not used any of the easily accessible super computers on the net, nor has used any intrusion techniques to round up CPU. The ultimate technique would be to have a well-writen worm raid the Net for CPU power, maybe only being active for a few hours. The worm could penetrate a substantial fraction of the Internet, if fed the right database of possible attacks on different vendors. The last, and most obvious conclusion perhaps, is that all sites should be concerned about their security. There is more to steal in your system than your supposedly worthless information, and I would say that the laws are quite unclear on the issue of liability in any of the above situations. At least if you haven't taken proper precautions. By the way, the above mechanisms can be used to create perfectly legit and proper markets as well. Don't confuse the phenomenas with the techniques. [BlackNet is a creation of Tim May <tcmay(a)got.net>, and possibly other cypherpunkers. A black market broker announces a public key widely on Internet, stating the market's existance. Potential buyers and sellers encrypt their requests and offers with the public key and posts the encrypted info in a newsgroup somewhere. The broker can then match up buyers and sellers. Ecash can be used to transfer funds, and the broker will get his share of the deal. This scheme is close to impossible to traffic analyse.]

1 0

Re: The BIG Lie (Jesus Confesses)
by nobody＠neva.org 17 Dec '03

17 Dec '03

Patrick Oonk wrote: > > Is this what the cypherpunks list has become ? Discussions about religion ? We killed this thread but after three days it rose again. > If so, I am out of here... Don't let lightning strike you in the ass on your way out.

2 1

SSL and MIPS...
by Christian Wettergren 17 Dec '03

17 Dec '03

Hi! How much computing power did we actually use, in terms of MIPS/FLOPS*hours? An unloaded SS10 that didn't swap went at approximately 16400 keys/s. How many MIPS is an SS10 approximately? How does different algoritms compare? DES, RC40, RSA512 etc? Or if I pose the question differently, what can you do with 30 GIPS for a day? /Christian

1 0

Not enough phone competition? Answer: regulate more!
by Declan McCullagh 17 Dec '03

17 Dec '03

<B>By JEANNINE AVERSA<P> <B>Associated Press Writer<P> WASHINGTON (AP) - Just 18 months after Congress deregulated the communications industry, the nation's top telephone regulator asked lawmakers Thursday for more tools to bring Americans local phone competition. "So far, scarcely any local competition has been delivered to residential or business consumers," Federal Communications Commission Chairman Reed Hundt said in a speech to the American Enterprise Institute. "We have a major challenge to introduce competition in the local telephone markets and that challenge is not yet being met," he said. Hundt asked Congress to write into law provisions: -Giving the FCC authority to set national pricing rules for those seeking access to local phone networks. -Requiring courts to defer to reasonable FCC judgments in disputes over the telecommunications law. -Consolidating appeals over the telecommunications law and FCC rules before a single unspecified court. -Creating a national policy to enforce the telecommunications law, giving the FCC power to compensate injured parties. The FCC now can order violators to stop breaking the law and fine offenders. Congressional hearings into the slow pace of local phone competition are slated for this fall. Sen. John McCain, R-Ariz., chairman of the Commerce Committee that oversees telecommunications policy, said when asked about the proposals, "I do not think that giving the FCC more authority to regulate is the answer." [...]

3 2

CFS and Securedrive
by don＠cs.byu.edu 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- From: Patrick Lear <plear(a)ekrl.COM> >Does anyone have any experience with the SecureDrive program and if so >can you make any comments about it? I found it very easy to use and very well designed. My only complaint was that it prints out a * every time you enter a character of your passphrase. Other than that, it's a very good product. Too bad Wollersheim didn't have it for his client list... Unfortunately, I switched to linux shortly afterwards. I have yet to get CFS compiled. (Oh, Matt, by the way, is that README.linux supposed to be current, because it's a little...errr...cryptic.) For those of you who would like to see CFS, the unix encryption system, some dastardly felon exported it and it's on utopia.hacktic.nl. (I did a diff against it with my copy, by the way, and it _hasn't_ been tampered with) Don -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQB1AwUBMEQDU8La+QKZS485AQEVewMAxN56v4mUZoe5AJSt64ZLRS+KwPiyG/WU 3PxTFGNjxL7l36Z4o2BMN6Bc195gYcxSUfjzvnfegN7gQU2/96IiNLd5b2QTsWJA WW56L92yJkxWYeYoQRRhRP1+Emj2fqaX =aU+M -----END PGP SIGNATURE-----

1 0

Re: Florida Drivers Permits
by jpb＠shadow.net 17 Dec '03

17 Dec '03

>Better would be to figure out the encoding scheme and post it here. I like this, myself. It'd be nice to be able to have the picture of my choosing instead of a digitized thumbprint...

3 2