December 2003 - cypherpunks-legacy

Re: Nanotechnology
by nobody＠REPLAY.COM 17 Dec '03

17 Dec '03

> 1 coulomb/second = 6.24 x 10^18 atoms/sec. Assuming an atomic spacing > of roughly 10^-10 meters, at that rate it'd take you about 18.5 days to > construct one side of the cube with a thickness of 1mm, or almost four > months to build another cube. I'd guesstimate another 4 months to build > the electronics for it. And then you'd need some way to assemble the > pieces. ok, but how do you build a 10-cm cube inside of a 10-cm cube? :)

2 1

Re: Nanotechnology (fwd)
by Jim Choate 17 Dec '03

17 Dec '03

Forwarded message: > Date: Sat, 17 Jan 1998 21:22:59 +0100 (MET) > Subject: Re: Nanotechnology > From: nobody(a)REPLAY.COM (Anonymous) > > 1 coulomb/second = 6.24 x 10^18 atoms/sec. There are a couple of things incorrect with this. A Coulomb is 1N of e-/s, not atoms. N atoms is called a Mole. N, or Avagadro's Number, is 6.023E23 not 6.24E18 ____________________________________________________________________ | | | The most powerful passion in life is not love or hate, | | but the desire to edit somebody elses words. | | | | Sign in Ed Barsis' office | | | | _____ The Armadillo Group | | ,::////;::-. Austin, Tx. USA | | /:'///// ``::>/|/ http://www.ssz.com/ | | .', |||| `/( e\ | | -====~~mm-'`-```-mm --'- Jim Choate | | ravage(a)ssz.com | | 512-451-7087 | |____________________________________________________________________|

1 0

Re: how to release code if the programmer is a target for (fwd)
by Jim Choate 17 Dec '03

17 Dec '03

Forwarded message: > Date: Sat, 17 Jan 1998 12:12:08 -0800 > From: Jonathan Wienke <JonWienk(a)ix.netcom.com> > Subject: Re: how to release code if the programmer is a target for (fwd) > However, if Alice has had my key for 6 months, and has verified the > signatures on 100 of my Cypherpunks posts, and my signature on GunzenBombs > Pyro-Technologies latest checks out, she can be pretty confident that I > actually signed it. On the other hand, if she didn't already have it, and > got a fake key and document from Mallet, Alice would not be able to use the > fake key to verify the signatures on my prior Cypherpunks posts. This > ought to be a red-flagged clue that something is rotten in Denmark... That's all fine and dandy, however, we *are* talking about an eternity server architecture that delivers documents to an end user in a secure manner on demand with no mechanism, by design, to determine the original source. In this case there would by definition be *no* history to verify against. It is in fact this lack of history from the users perspective that causes the authenticity problem in the first place. Further, a point that seems to have been forgotten, we are talking about signed and not encrypted documents. Of course there are some similar problems if we do include the encryption of the data itself into the protocol. ____________________________________________________________________ | | | The most powerful passion in life is not love or hate, | | but the desire to edit somebody elses words. | | | | Sign in Ed Barsis' office | | | | _____ The Armadillo Group | | ,::////;::-. Austin, Tx. USA | | /:'///// ``::>/|/ http://www.ssz.com/ | | .', |||| `/( e\ | | -====~~mm-'`-```-mm --'- Jim Choate | | ravage(a)ssz.com | | 512-451-7087 | |____________________________________________________________________| ____________________________________________________________________ | | | The most powerful passion in life is not love or hate, | | but the desire to edit somebody elses words. | | | | Sign in Ed Barsis' office | | | | _____ The Armadillo Group | | ,::////;::-. Austin, Tx. USA | | /:'///// ``::>/|/ http://www.ssz.com/ | | .', |||| `/( e\ | | -====~~mm-'`-```-mm --'- Jim Choate | | ravage(a)ssz.com | | 512-451-7087 | |____________________________________________________________________|

1 0

REPLY to Mitchells RESPONSE.
by bill payne 17 Dec '03

17 Dec '03

Saturday 1/17/98 3:37 PM John Young Attached is our REPLY to Mitchells RESPONSE. Morales will have it filed on Tuesday. Monday is MLK day. Morales will send a FILED stamped copy to you. Later bill UNITED STATES DISTRICT COURT FOR THE DISTRICT OF NEW MEXICO William H. Payne ) Arthur R. Morales ) ) Plaintiffs, ) ) v ) CIV NO 97 0266 ) SC/DJS ) Lieutenant General Kenneth A. Minihan, USAF ) Director, National Security Agency ) National Security Agency ) ) Defendant ) REPLY TO DEFENDANT'S RESPONSE TO PLAINTIFFS' MOTION FOR SUMMARY JUDGMENT BASED ON EVIDENCE FROM ADMISSIONS 1 COMES NOW plaintiffs Payne [Payne] and Morales [Morales] [Plaintiffs], pro se litigants to exercise their rights guaranteed under the Constitution, Rules of Civil Procedure, and Local Civil Rules to respond to Defendant's MOTION filed on 98 JAN-5 within the 14 days allowed by local rule 7.3(b)(4). 2 US Attorney Mitchell [Mitchell] writes, Counsel for Defendant was not served with copies of any of said Requests for Admissions until sometime after the individuals had been served.2 Mitchell WAS SERVED PLAINTIFFS' FIRST SET OF REQUEST FOR ADMISSION TO NSA DIRECTOR KENNETH MINIHAN I HEREBY CERTIFY that a copy of the foregoing request for admissions was mailed to Jan Elizabeth Mitchell, Assistant US Attorney, 525 Silver SW, ABQ, NM 87102 this Monday November 3, 1997. Michell was not served with any other admissions since Mitchell is not representing others. Plaintiffs' served Defendant Minihan properly. And Minihan failed to respond to Minihan's admissions within the time allotted by law. 3 US Attorney Mitchell writes, As grounds for the Motion and Memorandum, Defendant argued that Plaintiffs had blatantly disregarded this Court's Order pertaining to the conduct of discovery and the deadline for discovery in this Freedom of Information Act action. Judges Svet and Campos willfully violated Plaintiffs' right to Discovery. And thereby earned criminal complaint affidavits filed with judge Scalia of the Supreme Court. 4 US Attorney Mitchell writes, In Defendant's Motion and Memorandum, Counsel for Defendant also objected to Plaintiffs' sua sponte decision to modify the Court's June 11 Order to reflect the delay of the Court's October 7 Order and the establishment, without leave of this Court, of new deadlines for discovery, motions practice, and the filing of the PreTrial Order. (Motion and Memorandum 9, at 4.) Judge Svet and Campos attempt to deny Plaintiffs' right to Discovery, again, earned Svet and Campos criminal complaint affidavits. Plaintiffs exercise their right under the Federal Rules of Civil Procedure and the Constitution to conduct Discovery WITHOUT LEAVE OF COURT! 5 US Attorney Mitchell writes, By their own request, Plaintiffs sought to stay a ruling on the Defendant's Motion and Memorandum. Absent any ruling on either the Motion and Memorandum or Plaintiffs' Response, Defendant Minihan, employees of NSA, and employees of Sandia National Laboratory, were not obligated to respond to the Requests for Admissions as provided by Fed.R.Civ.P. 36.3 For Plaintiffs to now assert in their "Motion for Summary Judgment On Based On Evidence From Admissions" that because the individuals have not responded to the Requests for Admissions they are deemed admitted, flies in the face of their own prayer to this Court to stay a ruling on the Defendant's Motion to strike the Requests for Admissions until the Supreme Court takes action. Plaintiffs' have REPEATEDLY asked judge Svet and Campos to disqualify themselves from any rulings on this case because Campos and Svet do NOT obey the Federal Rules of Civil Procedure. Replace judges Svet and Campos because these judges have demonstrated, IN WRITING, they do not follow the Federal Rules of Civil Procedure. Plaintiffs' pleas are directed a replacement judge[s]. Not Svet and Campos. Therefore, Svet and Campos' failure to remove themselves does not stop the legal process. Mitchell cites NO law to support her claim that time constraints imposed under Fed.R.Civ.P. 36.3 are inapplicable as a result of Svet's and Campos' failure to remove themselves. 6 US Attorney Mitchell writes, Defendant requests that this Court either rule upon Defendant's Motion and Memorandum granting the request to strike the Requests for Admissions, or grant Plaintiffs' request to stay this action pending the issuance of the order sought by Plaintiffs in another forum. Should this Court deny Defendant's Motion and Memorandum, Defendant respectfully requests that the individuals to whom Requests for Admissions are appropriate in this action be given the thirty days to respond to said admissions as provided by the Federal Rules of Civil Procedure. REPLACEMENT JUDGES of the Court should realize the outcome of the lawsuit has attained international interest as a result of the 1 bungled NSA spy sting on Iran 2 US government agencies NSA, NIST, and the FBI's attempt to control cryptography. Mitchell's DEFENDANT'S RESPONSE TO PLAINTIFFS' MOTION FOR SUMMARY JUDGMENT BASED ON EVIDENCE FROM ADMISSIONS was posted on Internet at jya.com, click cryptome nsasuit8.htm USA/NSA Responds to Payne/Morales Motion January 16, 1998 Importance of this posting is summed-up in the Toronto Sun, Jan. 11, 1998 US, Iran Need Each Other by Eric Margolis Iran launched a surprise charm offensive last week, throwing Washington into serious confusion. In a lengthy interview on CNN, Iran's new president, Mohammad Khatami, skillfully analyzed the bitter relations between the two nations and cautiously extended an olive branch to Washington, calling for an end to their 19-year cold war. Khatami's diplomatic ju-jitsu flummoxed the Clinton administration, which was busy trying to rally international support against Tehran - and to overthrow Iran's elected government. Both capitals are split over the question of relations. In Washington, the military establishment and conservative Republicans have inflated Iran into a bogeyman to justify military budgets and keep U.S. forces in the Mideast. ... America incited Iraq to invade Iran in 1980. They did this to crush the Islamic revolution, then provided massive war aid to Saddam Hussein. Half a million Iranians died. The US got caught involved in genocide. Using high tech. This is one subject of this lawsuit. Albuquerque Journal Tuesday 1/13/98 carried the editorial. Khatami Move Is Profile in Courage Richard Reeves Syndicated Columnist LOS ANGELES - If an American leader had done what Iranian President Mohammed Khatami did last Wednesday, it would have been hailed as a profile in courage. ... Miscalculation! We armed and pampered Saddam Hussein in the hope that Iraq would destroy Iran. Now that's policy and behavior to think about. Here is something to think about: If Presidents Eisenhower and Kennedy had pursued any kind of sensible policy toward Cuba and Fidel Castro - opposed to the policy of trying to assassinate him - there never would have been a Cuban missile crisis. I think Iranians have financed and encouraged terrorism against the interests of the United States and Israel. I would not be surprised at all if something like proof emerges soon, perhaps anonymously, from the CIA and other government agencies, where many officials have built their careers on sanctioning and isolating Iran, to try to straighten the backbones of the president and people of the United States. If they succeed, America fails. What would be more effective in closing down Iranian terrorism? More hostility, sanctions and charges? Or beginning the process toward more normal relations with a country positioned and born to be great? ... Clearly genocide fits into Now that's policy and behavior to think about. The wired world is watching what this Court, hopefully minus judges Svet and Campos, will do. What is there to be? A series of possibly unfortunate events? Or does this Court order release the lawfully requested documents to help settle this American tragedy? WHEREFORE. 7 Have replacement judges of this Court DENY Mitchell's Plaintiffs requested a stay. Absent a ruling from this Court denying their request, they cannot proceed to assert that the Requests for Admissions are deemed admitted. Accordingly, Plaintiffs' "Motion For Summary Judgment On Based On Evidence From Admissions" must be denied. for reason that Mitchell's request to subvert both the Discovery processes and its time limits have no basis in law. And appears to plead to judges who do not obey the Federal Rules of Civil Procedure. 9 IMMEDIATELY ORDER Defendant to release the requested documents in the interest of national safety so that this matter can be settled. Aggrieved victims of US genocide are reading these pleadings. Respectfully submitted, _________________________ William H. Payne 13015 Calle de Sandias NE Albuquerque, NM 87111 _________________________ Arthur R. Morales 1024 Los Arboles NW Albuquerque, NM 87107 Pro se litigants CERTIFICATE OF SERVICE I HEREBY CERTIFY that a copy of the foregoing memorandum was mailed to Lieutenant General Kenneth A. Minihan, USAF, Director, National Security Agency, National Security Agency, 9800 Savage Road, Fort George G. Meade, MD 20755-6000 and hand delivered to John J. Kelly, US Attorney, 525 Silver SW, ABQ, NM 87102 this Tuesday January 20, 1997. 5

1 0

Re: how to release code if the programmer is a target for (fwd)
by Ryan Lackey 17 Dec '03

17 Dec '03

<daemon(a)ATHENA.MIT.EDU> (Jim Choate) writes: > > That's all fine and dandy, however, we *are* talking about an eternity server > architecture that delivers documents to an end user in a secure manner on > demand with no mechanism, by design, to determine the original source. In > this case there would by definition be *no* history to verify against. > > It is in fact this lack of history from the users perspective that causes > the authenticity problem in the first place. Further, a point that seems > to have been forgotten, we are talking about signed and not encrypted > documents. Of course there are some similar problems if we do include the > encryption of the data itself into the protocol. Eternity delivers data. It's up to the user to verify that the data is what they want, be it PGP signed by the pope, a working cryptosystem, or whatever. In this sense, it's no different than random email or whatever as an untrusted transport medium. The original question was how to verify the eternity server source code. I assume the following: * a potentially corrupted author (give rdl $100 000 and he'll probably make a minor modification which has no apparent mal effects, give him $100 000 000 and he'll be a hired gun). The author is optionally anonymous. * A community of publically-known cypherpunks and code-verifiers, not all of which are corrupted, but some of which may be. * A random user who has the public keys of at least (thresh) number of the cypherpunks, optionally the key of the author of the document/product before the system becomes questionable, perhaps by looking in the NY Times for 1 Jan 1999 which has a full page ad taken out by Cypherpunks Anonymous with the PGP public keys for the 100 leading cypherpunks. * The piece of code to be verified is bloody long, that is, longer than any one cypherpunk can afford to verify alone (shooting practice, installing the minefields and poison gas sprinkler system, etc. take lots of time) * The user can tell by visual inspection that a small compilation system does what they want it to do, and can understand basic logic enough to tell what signatures imply. Then: 1) The author releases the code into the network in an optionally anonymous way. There is no reason to trust the code -- even if it is signed with rdl's eternity dds signing key, no one has any reason to believe that it isn't an NSA front, since rdl is assumed to be corrupt, signing anything put in front of him (as long as sufficient money is put there too) 2) The user wants to run the code, because it's Just That Cool. 3) No one can verify the entire code. So, Cypherpunks begin signing small sections of the code with their own previously-established key. Their keys are established as their reputation is established on the list, or perhaps by personally meeting these people, in the traditional PGP web of trust scheme. There is no central Cypherpunks Registry, just a decentralized mesh. 4) The user executes the compilation script. This script looks at the pgp signatures, sees which ones it can verify from keys it already has accepted as valid by (3), and, if there are verified good keys from at least the minimum number of people in every critical section of the code, it is added to the compile-me-source-tree. If there are enough people for every critical section (the user defines all aspects of this), the source tree is set up for compilation, and compilation can proceed. The user knows that every piece of the code in the system has been verified to their standards -- even if the author of the code is an evil NSA sleeper agent, it has gotten by independent review by at least a user-defined-number of people per section. I fail to see how the specifics of Eternity are relevant -- it's just basically a PGP web of trust issue. The transport is irrelevant -- it's untrusted code until it's been verified by people the user trusts. Implementing a keyserver in Eternity has the same issues -- you still need to deal with the PGP web of trust issues. Signing my secret alias key with my own key as the only signature and uploading it to eternity would fail to provide privacy, just as it would if I posted it anonymously to the mailing list. One working system is the buildup of "reputation capital" by an identity using the key. Again, this is entirely irrelevant to the Eternity server -- verifying document authenticity is better handled at the client side. Eternity should be set up so as long as your ecash is good, your document is stored -- if I want to store my document under the name "disney's greatest hits" when it really contains necrophilic kiddie-porn and microsoft warez, that's my business. The client software for interacting with Eternity, however, might do well to have a good document authentication interface. And perhaps third-party authentication services could pop up, willing to sign documents that just meet gross criteria for valid indexing. You could then download the key for that service somehow, then use the service happily. The abstract issue has been beaten to death on cypherpunks many times. I just assert that Eternity is no different from "the Net", "the Web", "remailer networks", "Blacknet", etc. in issues of document verification and anonymous reputation capital. -- Ryan Lackey rdl(a)mit.edu http://mit.edu/rdl/

1 0

Re: how to release code if the programmer is a target for (fwd)
by Jim Choate 17 Dec '03

17 Dec '03

Forwarded message: > Subject: Re: how to release code if the programmer is a target for (fwd) > From: Ryan Lackey <rdl(a)mit.edu> > Date: 17 Jan 1998 19:07:10 -0500 > Eternity delivers data. It's up to the user to verify that the data is > what they want > The original question was how to verify the eternity server source code. How are these fundamently different? Assume for a moment that as a user of an eternity server the source is the data I want. > I assume the following: > * a potentially corrupted author (give rdl $100 000 and he'll probably > make a minor modification which has no apparent mal effects, give him > $100 000 000 and he'll be a hired gun). The author is optionally > anonymous. The point I am making is that whether the author is corrupt or not is irrelevant. > * A community of publically-known cypherpunks and code-verifiers, > not all of which are corrupted, but some of which may be. Ok. > * A random user who has the public keys of at least (thresh) number of the > cypherpunks, optionally the key of the author of the document/product before > the system becomes questionable, perhaps by looking in the NY Times > for 1 Jan 1999 which has a full page ad taken out by Cypherpunks Anonymous > with the PGP public keys for the 100 leading cypherpunks. Pretty expensive and rather unrealistic I suspect. Where does this random user come from? What is '(thresh)'? What good would an anonymous key signature provide? You can't verify it within the web of trust model, that would imply the author wasn't anonymous which takes us back to the 'friends' attack. How do we know that some number of these cypherpunks aren't turned? Are you proposing that the user test all 100 of the signatures? Which realisticaly is the only way to verify any given one of them. Not very many people will go to that extreme simply for grins and giggles. > * The piece of code to be verified is bloody long, that is, longer than > any one cypherpunk can afford to verify alone (shooting practice, > installing the minefields and poison gas sprinkler system, etc. take > lots of time) The standard is programs over ~10k lines is not comprehensible by a single individual on a line by line basis. > * The user can tell by visual inspection that a small compilation > system does what they want it to do, and can understand basic logic > enough to tell what signatures imply. 'small compilation system' of what? What who wants it to do? The author? Mallet? The end user? > Then: > 1) The author releases the code into the network in an optionally > anonymous way. There is no reason to trust the code -- even if it > is signed with rdl's eternity dds signing key, no one has any reason > to believe that it isn't an NSA front, since rdl is assumed to be > corrupt, signing anything put in front of him (as long as sufficient > money is put there too) It isn't the key of the author or the eternity server that is under attack by Mallet. It is the security of the individual user who is under assault. > 2) The user wants to run the code, because it's Just That Cool. We're talking here about users who want to get data that is illegal or otherwise incriminating or dangerous to one group or another. In particular let's consider the situation of a Lebanese freedom fighter in Isreal or perhaps a 'Free Burma' revolutionary in China. > 3) No one can verify the entire code. So, Cypherpunks begin signing > small sections of the code with their own previously-established key. > Their keys are established as their reputation is established on > the list, or perhaps by personally meeting these people, in the > traditional PGP web of trust scheme. There is no central Cypherpunks > Registry, just a decentralized mesh. Which doesn't effect the ability of Mallet to resign that code at the users end in order to break the users local security. > 4) The user executes the compilation script. [material describing script verification deleted] Mallet can re-write said script, especialy with the sorts of latency that the Eternity Server forces on the end user, such that it is consistent with the bogus keys the end-user gets. It is simply much easier to write scripts in a day than say 10 minutes. > I fail to see how the specifics of Eternity are relevant -- it's > just basically a PGP web of trust issue. The transport is irrelevant -- > it's untrusted code until it's been verified by people the user > trusts. The end user may not have people available to trust is the point. The reason the transport mechanism is relevant is that it is much easier to spoof a verification script if the user is not going to be surprised with 24 hour turn around on requests, whereas a responce time measured in minutes lessens the window of opportunity to Mallet significantly. It may come as a surprise to you and others but not everyone in the world can pick up a phone and call a 100 people all over the world and not raise some suspicion. > Implementing a keyserver in Eternity has the same issues While it is perfectly permissible to design Eternity or any data haven with inherent key servers, I believe it is a bad idea from a design perspective because it makes the code even larger, decreases the potential for monetary motives for indipendant key servers to appear, and if the server is compromised then the key server is also. It is more expensive if Mallet can be forced to deal with two indipendenat operators then a single monolithic operator. [rest deleted] ____________________________________________________________________ | | | The most powerful passion in life is not love or hate, | | but the desire to edit somebody elses words. | | | | Sign in Ed Barsis' office | | | | _____ The Armadillo Group | | ,::////;::-. Austin, Tx. USA | | /:'///// ``::>/|/ http://www.ssz.com/ | | .', |||| `/( e\ | | -====~~mm-'`-```-mm --'- Jim Choate | | ravage(a)ssz.com | | 512-451-7087 | |____________________________________________________________________|

2 1

uh,
by wabe 17 Dec '03

17 Dec '03

--What is that weird lawsuit all about wheresome director of the NSA is getting sued forsomething? Does anyone know?-wabe --digsig EojdyErVslc/s6aQeIHwnOlMw3lUKJhdZc/ZeCNfe7H L4ctAUj8gI6C830BTXaeFrhHME7aCeT3ev4HKbeT 4HICjjQYriAdlICrERT+zrSEtB1bkK+b6iRoC6a0y

5 8

Eternity - an alternative aproach (take 2)
by Kay Ping 17 Dec '03

17 Dec '03

"Romeo, she is a female Homo Sapiens, not a full rotation of the Earth during the season when the incident solar radioation is at a higher angle" "Yes, I know that. It was just a metaphore." I got several comments about my posting, all of them about the possibility of detecting the location of radio transmitters or receivers. You just didn't get it, did you? I was using radio as a METAPHORE for the use of broadcast to provide anonymity to receivers and packets with false source addresses for the anonymity of transmitters. You can read the original posting at http://infinity.nus.sg/cypherpunks/current/0107.html ----------------- Kay Ping nop 'til you drop finger kping(a)nym.alias.net for key DF 6D 91 18 A6 59 41 96 - 89 01 69 B7 9D0 4 AE 53

1 0

Unofficial transcript of Bernstein hearing published
by John Gilmore 17 Dec '03

17 Dec '03

EFF has published an unofficial transcript of the hearing in front of three judges at the Ninth Circuit Court of Appeals in San Francisco on December 8. The hearing discussed whether the export controls on cryptography are an unconstitutional prior restraint on publication. See http://www.eff.org/pub/Privacy/ITAR_export/Bernstein_case/Legal/ There is no news on the judges' decision from that hearing. John Gilmore Electronic Frontier Foundation

2 1

Re: (eternity) Eternity as a secure filesystem/backup medium
by Ryan Lackey 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- > Since documents placed on eternity by specification last forever (assuming, > of course, that > eternity will too) and assuming that computational power and cryptanalysis > will always > get better (say for arguments sake that moore's law continues to be held) - > doesn't that > mean that it will be feasible (in time) to break all eternity documents? :) Documents by specification last only as long as someone is willing to pay to keep them up. This is not necessarily forever. Once your DBC escrow "account" runs out, the data is worthless -- someone could then choose to store it on their own, and potentially charge others for this in a recursive model, but there is no reason why a piece of data must remain in Eternity forever if no one cares enough about it to pay to have it stored. > > Of course "in time" may very well be a very long (or astronomical) time, > but dependent on the crypto > used who knows what rate "feasible" breaking of a particular algorithm > might progress at, say > in d(key length)/d(year)? Can we assume that using Moore's law this is at > least 1 bit every > 18 months for symmetric crypto? Perhaps we might see this relationship > through the RSA challenges > over time. I am designing Eternity DDS with IDEA/3DES/Blowfish level private-key crypto and an equivalent level of DH/RSA public key crypto. These will be strong (provided back door attacks, fundamental breakthroughs in cryptography, etc. are not made...a bet I'm forced to make, even though I don't like it) well into the future. How far? I think unless Quantum Cryptanalysis becomes a reality, the underlying hard problems will not be solved through anything but a fundamental change in mathematics. As Prof. Micali said, "Gauss (Karl Friedrich Gauss, the reknowned mathematician/physicist/general smart guy) worked on these problems. The test of whether a problem is sufficiently hard to be a basis for a cryptosystem is if Gauss tried to solve it and failed." or something similar. > > [If Wiener's $1m DES machine in '93 took 7 hours, in today's technology $1m > in 1998 dollars should > be able to do this in less than 100 minutes, shouldn't it?] I don't think anyone would argue that 56bit is secure enough for anything but ephermeal channel authentication. I'd make the same argument for 64bit -- if you had a purpose-built machine with an intelligent key distribution system, a well nigh unlimited budget (read: US Military), and PE's which contained either ultrahigh performance GaAs logic or massively parallel on a single chip silicon logic, you could probably brute force a 64bit algorithm. Do the math, though, for 128bit. There are traditional analyses which include the amount of silicon on the earth, the number of atoms in the universe, etc. The general consensus is that traditional techniques are not feasible for brute forcing 128bit ciphers before the heat death of the universe. > > Since documents cannot be retracted or re-encrypted you really have to > assume that someday they > will be broken. This really turns the notion of what crypto to use for > encrypting eternity documents > into an upfront question of "how long do I want this information to be > secure?". 20 years? 50 years? > 100 years? > > matt Actually, Eternity is no different than emailing a file, given a SIGINT capability at the attacker which allows all internet traffic to be monitored. If the data is still relevant and worth breaking in 50 years, they could just intercept the encrypted email, store it in a government vault for 50 years, then attack it (even more amusingly, they could simply post it to Eternity themselves, encrypted with their own key :), a true turn about). If you do not postulate that level of signals collection capability on the part of the attacker, yeah, Eternity is a bit different than email. But I think that would be an unreasonable model of the attacker. - -- Ryan Lackey rdl(a)mit.edu http://mit.edu/rdl/ -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQEVAwUBNMISuKwefxtEUY69AQFB1Qf9GWDn6bwhWyJcDY0Liypo21ntpH5yzORu RXwkPSI8pbmqhVZAVGXC1WbcqY0pYn7vPRFq5AKszFsjpTOOYiHwsugmVKjrxVww GRKSBqn308aAjMogNtPwEfohJrQxOED/Hy7ykV6gHV76pUFoMazQ4OdUL2iM1hLF cCMzwtpfJM5eWvyLeQcQq307998epJ9hF1e3Sn4v6ZKEPIlr0yqr5tvM7/XWxC2s 6t82EUPmOZIbn75QQqLBIFK5MlOLuvalFr0xR3u7fYltOczAMC23hx7Tjk65e9a4 6XSeEXyMp2j2GWqcE5lUZp4OnewZvSoFhEj0rDo5PEN9ce0mJEKMow== =7IBY -----END PGP SIGNATURE-----

2 1