December 2003 - cypherpunks-legacy

Dark is faster than Light
by nobody＠REPLAY.COM 17 Dec '03

17 Dec '03

Bell Labs Proves Existence of Dark Suckers For years it has been believed that electric bulbs emitted light. However, recent information from Bell Labs has proven otherwise. Electric bulbs don't emit light, they suck dark. Thus they now call these bulbs dark suckers. The dark sucker theory, according to a Bell Labs spokesperson, proves the existence of dark, that dark has mass heavier than that of light, and that dark is faster than light. The basis of the dark sucker theory is that electric bulbs suck dark. Take for example, the dark suckers in the room where you are. There is less dark right next to them than there is elsewhere. The larger the dark sucker, the greater its capacity to suck dark. Dark suckers in a parking lot have a much greater capacity than the ones in this room. As with all things, dark suckers don't last forever. Once they are full of dark, they can no longer suck. This is proven by the black spot on a full dark sucker. A candle is a primitive dark sucker. A new candle has a white wick. You will notice that after the first use, the wick turns black, representing all the dark which has been sucked into it. If you hold a pencil next to the wick of an operating candle, the tip will turn black because it got in the path of the dark flowing into the candle. Unfortunately, these primitive dark suckers have a very limited range. There are also portable dark suckers. The bulbs in these can't handle all of the dark by themselves, and must be aided by a dark storage unit. When the dark storage unit is full, it must be either emptied or replaced before the portable dark sucker can operate again. Dark has mass. When dark goes into a dark sucker, friction from this mass generates heat. Thus it is not wise to touch an operating dark sucker. Candles present a special problem, as the dark must travel in the solid wick instead of through glass. This generates a great amount of heat. Thus it can be very dangerous to touch an operating candle. Dark is also heavier than light. If you swim deeper and deeper, you notice it gets slowly darker and darker. When you reach a depth of approximately fifty feet, you are in total darkness. This is because the heavier dark sinks to the bottom of the lake and the lighter light floats to the top. The immense power of dark can be utilized to mans advantage. We can collect the dark that has settled to the bottom of lakes and push it through turbines, which generate electricity and help push it to the ocean where it may be safely stored. Prior to turbines, it was much more difficult to get dark from the rivers and lakes to the ocean. The Indians recognized this problem, and tried to solve it. When on a river in a canoe travelling in the same direction as the flow of the dark, they paddled slowly, so as not to stop the flow of dark, but when they traveled against the flow of dark, they paddled quickly so as to help push the dark along its way. Finally, we must prove that dark is faster than light. If you were to stand in an illuminated room in front of a closed, dark closet, then slowly open the closet door, you would see the light slowly enter the closet, but since the dark is so fast, you would not be able to see the dark leave the closet. In conclusion, Bell Labs stated that dark suckers make all our lives much easier. So the next time you look at an electric bulb remember that it is indeed a dark sucker.

1 0

PGP, CMR, and OpenPGP
by Fisher Mark 17 Dec '03

17 Dec '03

As a Corporate Security Officer, I personally would prefer a solution like Adam Back's CDR that leaves the copy of the corporate data on the user's hard drive to the current PGP CMR. As long as the email data didn't need to be encrypted during local storage (i.e. encrypted against the possibility of industrial espionage), I wouldn't care whether the copy of the corporate data was encrypted -- actually it would be a lot easier to leave it in plain text (as I think Tim May suggested). (A single file in Unix mail(1) file format would make a nice auditing/reporting tool, so you could remember what you had sent to whom all in one place.) Corporate keys as in PGP CMR just means another key to manage that provides a single point of weakness in the company's security architecture. Without forcing everyone to run on a secure OS on hardware they can't directly access (i.e. no desktop computers), any additional security provided by a CMR system (as in providing unalterable records of encrypted email that was sent) can be easily bypassed. OpenPGP, meanwhile, should work on non-GAK/CAK solutions, while PGP Inc. should come up with a new product name (like 'BizSecure' only less whimsical) for its line of corporate encryption programs. (It might even be better business for PGP to set up a wholly-owned subsidiary, whose name does not even incorporate the term 'PGP' or its derivatives, for marketing such products, as those products would not be tainted by personal privacy reputation of the name 'PGP'.) 'BizSecure' and its kindred would then interoperate with OpenPGP standards only to the extent of the common non-GAK/CAK functionality of the two systems. ========================================================== Mark Leighton Fisher Thomson Consumer Electronics fisherm(a)indy.tce.com Indianapolis, IN "Their walls are built of cannon balls, their motto is 'Don't Tread on Me'"

2 1

Re: Remailers and ecash (fwd)
by Fisher Mark 17 Dec '03

17 Dec '03

Picking up a thread of a few weeks ago (sometimes life intervenes)... What I propose is: employee -> encryptor -> email -> remailer -> delivermail -> recipient -> decrypt which forces the opponent to both monitor traffic much more closely (to get around the traffic analysis-resistance of remailers) and to decrypt the actual messages. The point being to force the opponent to employ other, less safe (more chance of discovery) techniques, like bribing your employees or sending in agents as employees of the cleaning company, etc., etc. This use of remailers I think could be worth money to corporations. Unless you are a truly huge corporation, you are not going to be in a position to set up private email links with everyone you need a private email link to. Using the Internet, while deploying security measures appropriate to the application, is just too cost-effective. My proposal is just that using encryption and remailers together gives you more security than either technique will alone, perhaps enough that commercial remailers could flourish. ========================================================== Mark Leighton Fisher Thomson Consumer Electronics fisherm(a)indy.tce.com Indianapolis, IN "Their walls are built of cannon balls, their motto is 'Don't Tread on Me'"

1 0

Re: GAK "service" charges (Re: EC refutes GAK)
by pgut001＠cs.auckland.ac.nz 17 Dec '03

17 Dec '03

Adam Back <aba(a)dcs.ex.ac.uk> writes: >Peter Gutmann <pgut001(a)cs.auckland.ac.nz> writes: >>[multiple terabyte CDrom based keying material] >Reckon they'll twig, and charge you per megabyte to offer you the "service" >of allowing them to "recover" your communications in real time. Yes, but how will they phrase the requirements? A CD is a single key (in fact 1,000 CD's are all part of a single key)... this leads to the same problem I heard of here a few years ago w.r.t. outlawing gangs: "It would be impossible to word any comprehensive anti-gang legislation in a manner which didn't also outlaw the police". The same goes for certain aspects of escrowing, any escrow rules which are in any way practical and useable will also be open to all sorts of creative interpretation ("You must deposit a copy of your encryption key with the government" -> "Here's the key. Where can I park the forklift that moves the container of CD's?"). Peter.

2 1

Re: SMTP Encryption Exten
by harka＠nycmetro.com 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- -=> Quoting In:ericm@lne.com to Harka <=- In> If your mail goes to an intermediate MX site, it'll sit in the In> clear on the disk there until its sent to its final In> destination. Even if all mailers supported ssmtp, the mail In> would not be secure. True, but an encrypted tunnel to fetch your e-mail will at least render wiretaps on your phone-line useless. While that doesn't really matter if all your e-mail is PGP-encrypted, the truth is that a lot of e-mail is still in the clear. That at least would be protected to a degree... Btw., does anybody know if there's an crypto-enhanced direct-dial-up program such as minicom out there? Ciao Harka ... "Use a Cipher - Be Free!" -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQEVAgUBNE0TyjltEBIEF0MBAQEsawf/SyzCJ5vHC9gvn9aX4Efuxt9rNe6UqXoh 78ZpKba5X0QvkvPyG+4TAopLZUXL5Qjs5TKQmEhBcCnw4+bHv36T4nzaDPNKsD39 RFtCddWgpF1pIUQ7GIdY/mMTh5UGMibXgqU9Z1kZKP0j8pJJPn4aK1uSas+Yne69 /OdDX3PBBgbw66DxOqjdE6+pC0v5LS1janXUuEMXo8nV1MfpBnStI9ORAcyNeCtu H8KlnQcLwUhuEnTn/VeEwRZJIFPf3hUFcuxVdcooHgqDbY9d+zbSsFiqVE3EyMji bSiBTMK9N/jQ7VFllhkqLihJbA/Q27KP4M6hV4NMqDdh3Sfv6Bd7iw== =jbpL -----END PGP SIGNATURE----- If encryption is outlawed, only outlaws will have encryption...

1 0

Bill Gates, the Bully Savior, from The Netly News
by Declan McCullagh 17 Dec '03

17 Dec '03

***************** http://cgi.pathfinder.com/netly/opinion/0,1042,1517,00.html The Netly News Network (http://netlynews.com/) October 21, 1997 Bill Gates, the Bully Savior by Declan McCullagh (declan(a)well.com) When the Justice Department yesterday accused Microsoft of using its operating system near-monopoly to violate the law, the government did more than attack the world's largest software company. It also handed Microsoft's chief competitor, Netscape, a major business -- and political -- victory. Netscape has long been urging the Clinton administration to rein in Bill Gates. For years its lobbyists have bent the ears of powerful Washington policymakers. And, unlike many other Silicon Valley chiefs, Netscape's Jim Barksdale -- a veteran of such highly regulated companies as Federal Express and McCaw Cellular -- appears to truly understand how Washington works. So was Janet Reno motivated by politics, or law? "Fundamentally, I think it's a legal issue," says Ed Black, president of the Computer and Communications Industry Association. "But to say whenever the wealthiest man in America and one of the most powerful companies in America is challenged by a cabinet official, you can't say there's no political impact. You're in a political world at that level." When asked to name the most pressing issues Netscape faces in Washington, company lobbyists rattle off a long list of topics from encryption to copyright and education. But antitrust has always topped the list. This, after all, is the company's primary policy goal: to stop what it considers to be Microsoft's predatory practices. "This is not a Netscape-Microsoft issue," says Netscape's public policy counsel Peter Harter. "This is not a browser war. This is about obeying the law." Perhaps. But clearly Netscape has been complaining to the government about Internet Explorer since the Microsoft browser first hit the Net. Naturally, the company cheered Janet Reno's suggestion that Microsoft be punished with a fine of up to $1 million a day. "We're very supportive of the actions the Department of Justice has taken," Roberta Katz, Netscape's chief counsel, told the Netly News last night. "This lawsuit is about preserving competition as we move to the era of digital commerce." It is, of course, also an efficient way for Netscape to protect its commanding share of the browser market. "Bill Gates is a successful rival who makes it difficult for others to do business. Rather than compete against him head to head in the market, competitors turn to antitrust laws," says Don Boudreaux, a professor of law and economics at Clemson University. "What people at Netscape probably don't like is the fact that Internet Explorer is a good product." Netscape has slowly been emerging as the grand marshal in the Everyone But Microsoft parade. Last year Netscape hired the heavyweight Silicon Valley law firm of Wilson, Sonsini, Goodrich & Rosati, whose partner Gary Reback is a veteran anti-Microsoft campaigner. In November 1994 Reback prepared -- after a request from the Department of Justice, which was investigating Microsoft -- a 100-page white paper on behalf of three anonymous high tech clients. The theme: Microsoft's apparent anticompetitive behavior. [...] ------------------------- Declan McCullagh Time Inc. The Netly News Network Washington Correspondent http://netlynews.com/

1 0

CDR design document
by Adam Back 17 Dec '03

17 Dec '03

Here is a proposal for consideration for inclusion in the OpenPGP standard: http://www.dcs.ex.ac.uk/~aba/cdr/ (Also attached text version below [1]) It describes a mechanism for commercial data recovery which attempts to minimise the security risks inherent in allowing disaster recovery of stored encrypted documents. The CDR design also avoids the security risks in building systems which send recovery information over open communications networks, as the CMR proposal currently does. The CDR design offers the option of more ergonomic recovery from forgotten passphrase. CDR allows for more secure use to be made of the existing pgp5.0 key expiry functionality when applied to communications-only keys because they can be deleted with out loss of data-availability, providing a form of PFS which is backwards compatible with pgp5.0 and pgp5.5 clients. Comments? The only change addition to the standard required is to create a distinction between a storage only key and a communications only key. This distinction could be made via the use of an extra flag, ideally so that keyrings can remain standardised and interchangeable between different implementations. The document can also be viewed as a recommendation to implementors of how to avoid security risks (and related government abuse risks) in implementing data recovery systems. I would like to see the OpenPGP standard accomodate both the CMR and CDR design so that each can fly on it's technical merits. (And political merits, cryptography being a highly political field, a politically unpopular design may suffer for other than technical reasons). Adam [1] http://www.dcs.ex.ac.uk/~aba/cdr/ ==============================8<============================== Commercial Data Recovery This document describes a mechanism, Commercial Data Recovery (CDR), to allow companies to recover stored encrypted information as part of a disaster recovery plan. Introduction This document is centered around the OpenPGP standard, and therefore explores first what is possible within the existing standard. Several of the CDR variants presented can be achieved entirely within the pgp5.0 standard without adding any new functionality. Commercial disaster recovery requirement PGP is commonly used for two purposes: file encryption, and encryption of email communications. The situation arises in a commercial setting that individuals are protecting information which the company would like to be able to recover in the event of disaster: in the event of the user forgetting his passphrase, or in the event of the unexpected death of the employee. Stored files which the company may require the ability to recover include encrypted files stored in the files system, on backup tapes, or on floppy disks; and encrypted sent and recieved emails stored in mail client folders. Security vs Availability There is a security risk in adding data recovery mechanisms: the additional risk that recovery procedure is used by other than the owners of the data to recover plaintext. A central goal of the CDR design described in this document is to minimise this security risk. Keys used to encrypt email which is transmitted over the Internet are more valuable to an attacker than keys used to encrypt stored files because of the relative ease with which an attacker can obtain copies of emailed ciphertext. Stored encrypted files in contrast are protected by all the physical security systems the company is relying on to protect it's paper files, plaintext data stored on disks, and backup tapes. For this reason the CDR approach treats communications keys as more sensitive than keys used to encrypt locally stored information. Separate Signature and Encryption Keys added in pgp5.0 This section describes a feature added to PGP with the pgp5.0 release: separate signature and encryption keys. Readers familiar with pgp5.0 functionality may like to skip this section. pgp2.x RSA keys pgp2.x (and pgp1.x) only had direct support for one type of public key: the RSA public key. RSA public keys were used both as signature keys, and as encryption keys to transfer session keys. The ability to generate RSA keys, and to interoperate with pgp2.x is retained in pgp5.x. pgp5.x El Gamal (DH) encryption and DSA signature keys One reason for the introduction of separate key functionalities is the addition, starting with pgp5.0, of the DSA digital signature algorithm which can only function as a signature system. In addition the El Gamal (EG) public key system which was also added with pgp5.0 is used only as a public key encryption system. (There are some El Gamal variants which can be used to produce digital signatures, but these are not used in pgp5.0). (El Gamal is a Diffie-Hellman (DH) variant which is sometimes also referred to confusingly as DH.) The DSA is itself a DH signature variant. Patent issues Another significant reason for the adoption of EG and DSA in particular is the freedom from patent encumbrances these algorithms now enjoy. RSA by contrast is patented, and unpatented algorithms are generally preferred for internet standards. Key expiry feature added in pgp5.0 One general security principle is that keys used to protect communications should be replaced periodically to reduce the value to an attacker of an individual key. Migration path The pgp5.0 standard provides support for this functionality in terms of the ability to attach expiry dates to signature and encryption keys. (In the pgp5.0 and pgp5.5 clients the signature and encryption keys are treated as a pair, and are given the same expiry information, but both the pgp5.0 and pgp5.5 clients can already cope with signature-only keys and encryption-only keys with different expiry information.) Web of Trust In pgp5.0 with the EG public keys, the Web of Trust (WoT) is based on the signature keys only. The users signature key is authenticated in the web of trust. The user signs his own encryption key thereby transferring trust to it. This ensures that encryption keys can be expired and replaced without affecting the web of trust. Limited Perfect Forward Secrecy Perfect Forward Secrecy (PFS) refers the technique of destroying old communications keys to ensure that past traffic can not be compromised after the point of re-keying. One way to use the pgp5.0 key expiry facilities is to have signature and encryption keys with very different expiry periods. For example a signature key could be given no expiry period (the pgp5.0 standard supports expiry periods of `forever'), and encryption keys could be given an expiry period of 6 months. To obtain PFS, a more secure way of dealing with expired encryption keys is to actually irretrievably delete them. This then simulates PFS: an attacker is unable to decrypt traffic encrypted with old communications keys even if he is able to coerce co-operation from the recipient. No one can be coerced because the key has been deleted. It seems reasonable that some users may want to use key expiry for this purpose, and this does not require any modifications to the existing pgp5.0 standard. Key expiry problems for stored encrypted data One problem introduced by key expiry is that any stored data encrypted to the expired key becomes less available. For security reasons the expired key should ideally be deleted, and in this case access to the data is lost. Alternatives are to attempt to store the old keys more securely, this then presents the problem that some stored data is harder to access than other data, and presents additional key management problems for old keys which will be confusing for users. Re-encrypting after key expiry One method to solve this problem is to re-encrypt all of the encrypted files at the point of re-keying. However this method has disadvantages in that not all of the encrypted data may be easily available. Some of the encrypted data may be on backup tapes, on floppy disks, or stored inside `zip' or `tar' archives on the disk and hence may be missed. Separate storage keys The simplest solution to this problem seems to be to encrypt to a separate storage key. Within the pgp5.0 standard this storage key would be a separate El Gamal key with a long expiry date. With this system we then have three types of keys: signature-only keys, communications-only keys and storage-only keys. This could require minimal or even no modifications to the pgp5.0 standard, storage and encryption keys could be differentiated between by: * location storage-only key is stored in (for example a separate keyring) * application being configured to use a chosen encryption key as the storage-only key by giving a keyID * convention on expiry dates (expiry date `forever' could be storage key, other values could be communications keys) * extra flag to indicate a storage-only key Once the separation of key types is made, the security benefits of re-keying can be more fully obtained. Sent and recieved email folders To maintain availability after re-keying of encrypted sent and received emails archived in mail folders, the email plaintext would be encrypted with the storage-only key. This then means that data availability for encrypted files on disk, floppy disk, and backup tape is maintained; and that availability for archived sent and received emails is maintained. Storage Recovery If the system is being used in a commercial setting, disaster recovery can be provided by storing recovery information to allow recovery of the storage-only key. There is still some additional danger over the case where there is no recovery procedure: the risk that an attacker may be able to compromise the recovery information. However because the encrypted data is all protected by the companies existing physical security mechanisms the security risk is minimised. Another form of storage recovery would be to include recovery information with each file, and this would be a valid combination achieved by placing CMR-style requests for additional crypto-recipients on the CDR storage-only key. However this practice makes recovery from forgotten passphrase more problematic: to restore user access to the data after forgotten passphrase, the recovery agent would have to decrypt all stored files (be they on hard disk, backup tape, floppy disk, or stored inside `zip' or other archives), then the user would have to generate a new storage-only key, and re-encrypt all of the files. Given the frequency with which users are prone to forgetting passphrases implementors may decide to avoid this option for ergonomics reasons. CDR vs CMR PGP Inc has an alternative data recovery proposal called Commercial Message Recovery (CMR). The CMR proposal involves sending recovery information with the message in the form of a second crypto recipient. In addition mechanisms are provided in the form of a proposed CMR public key extension to the IETF OpenPGP standard which indicates a request to the sender to include this recovery information. In addition facilities are provided in the form of PGP Inc's SMTP policy enforcer to partially enforce the inclusion of this recovery information by bouncing mail which does not include it. Security comparison PGP Inc's CMR proposal makes re-keying problematic because data is archived in email folders still encrypted to the encryption key. This tends to encourage the practice of having very long term communication encryption keys. Indeed the beta pgp5.0 implementation the author tried makes the recommendation that most users would give keys an expiry period of `forever'. In addition a security risk with the CMR proposal is that an attacker is able to obtain via coercion, bribery or burglary the CMR key used to encrypt the traffic for this key. With a purloined CMR recovery key, and given the long life time encouraged for such keys the previously passive attacker may be able to recover years worth of old traffic. Another risk is that companies may for simplicity have only one CMR key, thereby putting at risk the entire companies secured communications over periods of years. This is naturally a bad practice, and one which is discouraged by PGP Inc also, but the author remains cynically confident that some corporate users will ignore such advice. Privacy Comparison PGP Inc proposese the CMR communications recovery mechanism as a privacy respecting method of achieving data recovery. The privacy features of the CMR proposal are that there are proposed flags which are attached to a public key to indicate statement of intent about plaintext handling to the sender who is about to use the public key. Three statements of intent are possible with the current CMR proposal: * personal key (no flags set) * company use key, company may read message, please encrypt to listed company CMR recovery key(s) (recovery flag set) * company may read message, encrypt to listed CMR recovery key(s) or the message will be bounced (strict recovery flag set) PGP Inc's statement of intent in plaintext handling is a useful concept, in that it explains explicitly to the sender who will be able to read the message, and how the plaintext will be handled. Statement of intents are always advisory, in that they are impossible to enforce; however they are useful in encouraging ethical behaviour in this regard. Statement of intent messages are independent of recovery mechanism, and apply equally to the CDR mechanism described in this document. In fact the author would like to encourage a fuller set of statement of intent flags for both sender and recipient, allowing keys to be marked with intents: * personal key, messages not archived * personal key, messages archived * key used for company business, messages not archived * key used for company business, messages archived * key used for company business, messages archived and recoverable And, in addition a similar privacy argument could be made to allow the sender to express his preferences with regard to plaintext handling on a per message basis. This could generalise the -m function of pgp2.x which instructs the recipient not to save to a file. (The -m flag is the sort of electronic version of `please burn this document after reading', this flag is mildly enforced by the pgp2.x command line application). These set of flags would allow a sender to send a `normal communication message', or a `official statement, please archive with recovery if available', or `sensitive do not archive' and so on. A privacy respecting implementation could provide support for these functionalities. Whilst obviously easy to over-ride, this is felt to be a useful exercise in encouraging respect for privacy. In addition the recipient should have ability where company policy allows to choose which messages to archive, and which to archive with company recovery information. >From a privacy perspective the CDR and CMR proposals are approximately equivalent; the statement of intent flags, and the social value of encouraging companies to respect privacy are useful in both. Government access to communication key politics Another aspect of the whole data recovery area is that the US government, French government, and UK government (as well as other governments) have expressed an unhealthy interest in obtaining private individuals, and companies communications keys. Many privacy advocates view this development with fear, as it seems to many a particularly Orwellian development. Usually the Government Access to Communication Key (GACK) attempts try to deflect criticism by focussing on unrelated issues as a vehicle to introducing GACK: * Terrorist attacks and requirement for emergency government access to communications traffic * Government assistance for companies to recover stored plaintext via key escrow infrastructure. * Assisting electronic commerce by helping put in place Certification Authorities and digital signature laws However readers who have followed GACK politics will recognise the above for what they are: attempts to put in place GACK via indirect routes (respectively: the four horsemen of the infocalypse argument (the fallacy that terrorists will obey laws and use encryption systems which have government backdoors), the Clipper I, II and III attemps (various attempts by the US government to bribe and bully companies into building a GACK architecture), and the UK TTP (Trusted Third Party) proposal where `TTPs' are a euphamism for a Certification Authority (CA) which has been coerced by law to keep individuals private keys). Scenarios governments might shortly try this to request master keys for communications might be France, where the government is changing from a position of no encryption software without license, to a position of unlicensed encryption software being allowed provided that the governments has a back door into the communications. Other examples being perhaps the UK (with it's highly controversial TTP licensing proposals), or the US with the administration and law enforcement community pushing hard for access to communications keys. It is likely, particularly in the UK, and US in the authors opinion, that government backdoors would be demanded in carefully orchestrated stages, designed to minimise public opposition. There might be trials where the traditionally more regulated financial organisations were required to comply, next perhaps government funded research labs, and business organisations accustomed to large amounts of government regulation Only towards the end would people using government funded networks (academics), Internet services providers (ISPs) and individuals be regulated. The final phases may use a terrorist activity, or national emergency, or other scandal as justification for increasing the requirements. It is likely also that the justification will be in terms of wholesome sounding public safety safeguards. Political Comparison PGP Inc's CMR proposal loses heavily in the political argument in the author's opinion because the protocol design supports the practice of allowing third and fourth party access to communications traffic. Particularly with the multiple CMR key requests per key which are rumored to be coming in the next version of PGP, it will be easy technically for a government to request that one of the recovery keys belong to the government. Governments already have the political will to have access to communications; the barriers are technical, and individual's resistance to the notion. The danger with the CMR proposal is that it could become the enabling technology for push button suveillance, the enabling technology for wide scale secret service signals intelligence keyword scanning. This probably not what it's proposers intend, however the danger is there in building the technology. The CDR proposal on the other hand focusses on recovery information of stored information only, and as a design principle avoids sending recovery information over open networks. Whislt governments may be interested to obtain storage keys, they have much less value, because the ciphertext is much harder to obtain. Also non-compliance is much harder to detect: a government law enforcement agency would not know if an individual was actually using storage software with government backdoor key access without physically obtaining the storage media. For most individuals the point at which governments executes a dawn raid is a point at which the individual is already in trouble. The CDR proposal is much closer to the status quo in political terms.

2 2

re: index.html
by Anonymous 17 Dec '03

17 Dec '03

> U.S. SAID VULNERABLE TO COMPUTER ATTACK > > "Today, the right command sent over the Internet to a power > generating station's control computer could be just as effective as > a backpack full of explosives and the perpetrator would be harder to > identify and apprehend," the panel wrote in its executive summary to > the report. "Today, we decided to hook up the computer that controls the power supply of several states to the most hostile WAN in history. OMIGOD, THERE'S AN INSECURE POWER GENERATION CONTROL COMPUTER HOOKED UP TO THE INTERNET! Everyone in the US, $2 please, so we can fix it." > > The report recommends stepping up research and establishing a > nationwide program to educate people on the scope of the problem. It > also recommends revising existing laws to ensure protection against > electronic attacks through the Internet. > This sounds like a bad cyberpunk novel. Two crackers in some hotel room in a hyper-crowded city in Japan, hacking the "power control network". Suddenly, one of them stops and says, "Shit." The other looks up, startled. The first says, "I forgot. This is against the law." A pause. Then they both start rolling around a floor covered with anti- static bags, polystyrene, and fast-food cartons laughing until they turn blue. > > "Law has failed to keep pace with technology. Some laws capable of > promoting assurance are not as clear or effective as they could be," > the panel wrote. > When I hear the "Law has failed to keep pace with technology" mantra, I get the feeling that lawmakers want license to pretend that Moore's Law applies to them, as well. Double the amount of criminal laws and regs every 18-24 months. > "We identified existing laws that could help the government take the > lead and serve as a model of standards and practices for the private > sector," it wrote. "We identified other areas of law that can enable > infrastructure owners and operators to take precautions > proportionate to the threat." "We think we can do what we want with what we already have. Give us the money anyway." Nuke them from orbit. It's the only way to be sure. Golem

1 0

Re: Your "RIGHT" to Speak to Big Brother
by Brian B. Riley 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/20/97 11:13 PM, Eric Cordian (emc(a)wire.insync.net) passed this wisdom: >And there you have it. The people's right to provide their >neighbor's proprietary information their government shall not be >infringed. How Constitutional-Sounding. can you say INSLAW ????? they are sooooo trustworthy! -----BEGIN PGP SIGNATURE----- Version: PGP for Personal Privacy 5.0 Charset: noconv iQA/AwUBNE08NcdZgC62U/gIEQJ2/wCaAwcjQLogUeAp7eBQk8n73OhmCjYAoON9 Z3FYtXeYgUYXlChaGYXu1IBk =Rho8 -----END PGP SIGNATURE----- Brian B. Riley --> http://www.macconnect.com/~brianbr For PGP Keys <mailto:brianbr@together.net?subject=Get%20PGP%20Key> "Civilization is the progress toward a society of privacy. The savage's whole existence is public, ruled by the laws of his tribe. Civilization is the process of setting man free from men." -- Ayn Rand - The Fountainhead (1943)

1 0

wanted dead or alive: pgp5.5 key pair
by Adam Back 17 Dec '03

17 Dec '03

Could some kind soul who has downloaded pgp5.5 for business (I think it is available in the US from www.pgp.com) create a key with a CMR key extension. I guess this means generating two keys: XYZ Corp recovery key <snoopy(a)xyz.com> and then: XYZ Corp Sales <sales(a)xyz.com> with the sales person's key set up to have a strict requirement to encrypt to the XYZ "message recovery" key. Could this kind soul then mail me, (or post here I guess would be even more useful) both the private and public keys of both of them. Enciphering minds want to find out how pgp5.0 reacts to this key :-) (The question is really does pgp5.0 encrypt to the CMR key). (btw for the curious as to why my previous message was had a date of 22nd Feb ... I had to set my clock back to get pgp5.0 beta to function as the one I have had expired, and I forgot to set the clock forward again). Adam -- Now officially an EAR violation... Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/ print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<> )]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`

3 2