- cypherpunks-legacy - lists.cpunks.org

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

17 Dec '03

semprini(a)theschool.com wrote: > > I don't think I'm out of line here in saying that all this spoofing of > other users is a bit childish. I'm sure there are better > things one could find to do with one's time. (Possibly work on > cracking RSA's 128- bit key?) > > --Dylan I already cracked it. The message is: "Sorry, but we ran out of cash."

1 0

Have some fun
by suzy1＠aol.com 17 Dec '03

17 Dec '03

TEN MINUTES FREE! Just for you if you're over 18. Five minutes in our Private Show AND five minutes in our Voyeur Show. Try it to see if you like it. Adults only! We support the AOL Browser! http://www.babequest.com Signup for free and use your free time.

1 0

Re: Secure phone
by bureau42 Anonymous Remailer 17 Dec '03

17 Dec '03

John Deters wrote: > At 12:44 PM 10/7/97 -0700, Eric Blossom you wrote: > >I wrote: > >> Therefore, man-in-the-middle can be more precisely described as an > >> unauthenticated end-point problem. Therefore, without authentication, > >> there is no defense (yet) against MITM attacks. > >I concur from the theoretical point of view. > It would be easy enough to "trick" the MITM into exposing their existance > anyway, just by using digits that come up in conversation. > A sudden dropout of sound (or "accidental" loss of > connection) while the MITM recognizes the trap and tries to backpedal will > be instantly noticed. Human protocols are resilient, whereas mathematical > protocols are precise. Speaking from a practical standpoint, since I have been the target of a variety of electronic surveillance for over a quarter of a century, the Man-in-the-Middle rarely operates so well that there are not a number of small anomalies that one cannot spot in the quality and/or flow of the service they are receiving. On the other hand, they rarely screw up so badly as to make it glaringly obvious what they are doing. The main thing, when one has reason to believe that quality or technical problems may be the result of MITM, is to take subtle actions such as the one suggested above, in order to force the MITM to adjust on-the-fly to situations that you create in order to monitor the monitor. e.g. - "Call me in 5 minutes at 555-PAY-PHONE for the secret code." If you already have a shill using that pay phone to monitor sudden anomalies in the function, fine, but it is ususally sufficient to take a call at the phone in five minutes, and the results of a quick patch will be noticeable. - "Do you have a radio playing, or something?" Hi-tech MITMs use a white-noise system designed to provide a cover for noise from their equipment, and a statement such as the above will invariably cause them to adjust it, usually resulting in a greater clarity or greater fuzziness on the line. Similar analysis of one's email, particularly if you have several recipients who can send you full feedback on timing/routing, etc., can reveal consistent differences between letters to your mom, and your death threats against the King (as well as letter to your mom which contain death threats against the King). Bottom line: If you are sending something worthy of being monitored, then your actions and methodologies should reflect the belief that you *are* being monitored. Please destroy your hard drive after reading this post. TruthMonger

1 0

Re: What's really in PGP 5.5?
by Anonymous 17 Dec '03

17 Dec '03

> There are two reasons which are given as to why someone might want to > have GAK installed for company use. > > 1. to allow access to important material lost in the mail system in the > event that an employee is hit by a bus > > 2. to allow management to spot check the emails being sent and received > > > Argument 1 seems pretty flimsy to me. I reiterate my comment in an earlier > post: who in their right mind keeps their _only_ copy of ultra valuable > company information bouncing around in the email system? Did those arguing > for this position not notice that sometimes email gets lost in transit? > > Regardless, if PGP claims to be catering to those who use this argument, and > to not want to try that hard to make it impossible to by-pass, the more > secure, and less GAK friendly way to do it is to have the mail client > software archive the email sent and received. Two problems. First, not all mail clients let you archive the mail in a different form than how it arrived. Netscape 3 worked like this, maybe 4 too. If the mail comes in encrypted just to an employee key, that is how it will be stored, and no business access is possible. Second, what if an employee doesn't come back from vacation? You've got messages sitting in his inbox which go back three weeks. All encrypted to his personal key, which is gone. It's been long enough that the senders may not have backups any more. It's all lost, and at best the company is going to put its partners and customers to a great deal of inconvenience by making them re-send everything they've sent in the last three weeks, not to mention making the company look incompetent.

5 4

update.340 (fwd)
by Jim Choate 17 Dec '03

17 Dec '03

Forwarded message: >From physnews(a)aip.org Wed Oct 8 14:08:52 1997 Date: Wed, 8 Oct 97 09:47:35 EDT From: physnews(a)aip.org (AIP listserver) Message-Id: <9710081347.AA08262(a)aip.org> To: physnews-mailing(a)aip.org Subject: update.340 PHYSICS NEWS UPDATE The American Institute of Physics Bulletin of Physics News Number 340 October 8, 1997 by Phillip F. Schewe and Ben Stein TURNING ONIONS INTO DIAMONDS. Nano-diamonds can be created without high pressure by squeezing carbon "onions" (nested buckyball-like structures) with ion beams. Graphite material can be made into diamond the hard way, with the use of high pressure (above 10^6 atmospheres), high temperature, and the use of catalysts. But recently scientists have been able to bombard carbon onions with electron beams and now ion beams as well, and have been able to convert the onions almost completely into diamonds, up to 100 nm in size. Researchers at the Max Planck Institute in Stuttgart (Florian Banhart, banhart(a)wselix.mpi-stuttgart.mpg.de) use a beam of neon ions to pelt the onions, which act like miniature pressure cells. With larger ion accelerators, one should be able to make macroscopic amounts of irradiation-induced diamond. (Experimental work: Wesolowski et al., Applied Physics Letters, 6 Oct. 1997; theory paper (Zaiser and Banhart) upcoming in Physical Review Letters; figure at www.aip.org/physnews/graphics.) MOLECULAR HYDROGEN SHOULD BECOME SUPERFLUID if placed on the right surface, say physicists at the University of Illinois (David Ceperley, ceperley(a)ncsa.uiuc.edu) Superfluids, substances that flow without friction, are few in number: liquid helium-4, special gases of rubidium and sodium atoms (in the form of Bose-Einstein condensates), pairs of helium-3 atoms, and pairs of electrons (which flow through superconductors). The trouble with getting hydrogen molecules (H2) to become superfluid is that they are all too ready to combine with each other into H2 solids. By laying them on a silver substrate and by salting them with a pinch of alkali metal atoms, the H2's should be able to resist the tendency to solidify all the way down to zero temperature. At 1.2 K they would become a superfluid, the Illinois theorists predict. They believe this can be carried out over the next year, after which experimentalists could explore unique hybrid superfluids, such as H2/He-4 mixtures. (M.C. Gordillo and D.M. Ceperley, Physical Review Letters, 13 Oct; see figure at www.aip.org/physnews/graphics) A POLYMER THAT CAN TRANSFER ENERGY BETWEEN DIFFERENT LIGHT BEAMS has been demonstrated by researchers at UC-San Diego (W.E. Moerner, 619-822-0453), opening possibilities for inexpensive and easily manufacturable "optical transistors" that can amplify or attenuate a light beam. The San Diego polymer is an example of a "photorefractive" material, a material that adjusts its structure and electronic properties when two or more light beams combine on it to form an interference pattern. On these materials, light from one beam can bend in such a way as to bounce back in the direction of a second beam, adding energy to it. Inorganic versions of these materials exist, but they are difficult to make and can cost thousands of dollars for a tiny cube. Moerner constructed a polymer whose three main components carried out essential tasks: buckyballs offer electrons, poly (n-vinyl carbazole) (PVK) molecules carry these electrons along their backbone, and PDCST molecules stretch or contract, changing the way light bends in these regions. The researchers demonstrated a "net gain" of about 5, in which one of the laser beams shining on the material gained energy. These materials have numerous possible applications, including correcting distorted images. (Science, 25 July.)

1 0

data recovery good, key recovery bad (Re: Are we all looking at the same PGP 5.5 ?)
by Adam Back 17 Dec '03

17 Dec '03

[I've moved this thread to cypherpunks, it was on cryptography, and Perry (cryptography moderator) just killed the thread. Some of the participants may not be on cpunks, so keep them on the cc if you want them to see your replies] Marc Horowitz <marc(a)cygnus.com> writes: > >> > What makes you think that all critical email is on disk in the clear? > >> > >> Nothing: it could be on disk encrypted. eg. Encrypted files encrypted > >> with storage keys, or encrypted partition encrypted with storage key, > >> or encrypted sent or received email encrypted with storage key. > > Well, if it's encrypted on disk, then "you read the disk" doesn't get > you very far. You need to be able to decrypt the information on the disk. Of course you do. Lets say you are using Peter Gutmanns encrypted filesystem setup. So, if you figure the info on the disk is important, you give a copy of the key to the company lawyer, put it in the fire proof safe, secret split it, whatever tickles your fancy. The advantage of this is that the email software it is no use to the GAKkers, because it doesn't have mildly enforced extra crypto recipients, and it doesn't get the business community used to the idea of shipping email around with extra doors into it. PGP Inc's pgp5.5 could be used by the government to weedle their way into mandatory key escrow. Say that they start requiring companies to use this software, then when lots of companies start using it, they start asking companies for a copy of the company master key. Bingo key escrow, courtesy of PGP Inc. Next they "encourage" ISPs to use it also. > >> The way to do it is as described above. Archive the email, encrypt it > >> to a starage key. Build that functionality into the MUA if you fancy. > >> But _don't_ give extra access to keys used for communications only. > > There is no extra access to communication keys. There is so! His mail said that there was a policy flag in the public key, and an additional public key for the corporate back door. That policy flag effectively said this key has attached to it a request that you encrypt to this extra crypto recipient. In some cases an additional flag will be set which says "if you do not comply with the request to encrypt to the extra crypto recipient, the recipient will not see the mail". PGP Inc's method of enforcing this is an SMTP policy enforcer which bounces mail without the extra crypto recipient. There, that is an extra access to the communication (via an extra route to accessing the session key). Uhhh, I think I just realised why we are talking at cross purposes... you meant extra access to the recipients private key. I consider this an artificial straw man, erected by Jon. Sure it's an independently dumb idea to have lots of people sharing private keys. But the system is still GAK friendly. And it does allow extra parties access to the message. The worry is that government becomes that second party. Do you really care about the details of mandatory GAK, when and if it comes in. Do you care whether the government has a copy of your private encryption key, or whether the system is setup with un-bypassable second crypto recipient of the USG/NSA etc. Can't see that it makes much difference at that point. Both methods can be bypassed theoretically anyway, by super encrypting or any other subliminal channels kicking around in the protocols. So I can't see that arguments about how easy they are to bypass hold much water. Frisbeeing a disk out the window is far easier a way to bypass anyway. Or just blabbing. > >> Hint: you will note that Freeh and friends aren't interested in > >> storage keys. You can see why the above systems is less GAK friendly > >> right? > > Freeh wants storage keys, too. He wants *all* the keys. Yeah he probably does. But he wants your communications keys a lot more. You know why that is? Because he has your communications because you're broadcasting them across the Internet. He'd like to read them. However he doesn't have your disk, and he'd have to break into your offices to get it, or issue you with a supeona or whatever. I'm sure he'd love to read your disk too, but your disk isn't sitting on an NFS mount over the internet. (Is it!?) Fortunately, the internet couldn't handle the strain, otherwise you might see calls for you to rent your disk space of government disk farms, and the government would then be very interested in demanding a copy of your storage keys. So, if even if we use corporate key backup for storage keys, this is still more along the lines of the status quo. They want your documents, they've gotta come and get them. What we'all are getting worked up about here is that Freeh and friends want to be able to key word search our damn communications on fishing expeditions. > Email is a funny thing. It's sort of storage, and sort of > communications. I can understand wanting to recover it from a > communications aspect. They don't call SMTP "store-and-forward" for > nothing. There is no information in the body of the message which is required for it to get to it's destination. All you need is the SMTP headers. You clearly can't end-to-end encrypt the communications routing information. (You could layer it though, like perhaps remailers, with each hop only knowing what it needs to know to do it's job; however at that point you can run into problems: you can't bounce back a delivery failure part way along the route.) > You'll notice that if I delete the messages after receiving it, it > can't be recovered. If I don't, it can. Sound like storage to me. So? The point is that you shouldn't be mixing key purposes. Communications private keys should be used to protect communication and shouldn't be given to anyone else, even your company. Storage keys might be sensible things to backup within the company in case of accidental death. Actually I disagree with what you said: you said "if I delete the message after receiving it, it can't be recovered", it might easily be recovered in lots of ways: 1. feds have tap on your line, feds rubber hose your long term private key out of you 2. your sender has kept a copy in the clear 3. your sender has kept a copy encrypted with a poor passphrase which the feds guess/or rubber hose from him 4. your sender used encrypt-to-self, and has poor passphrase/is passphrase rubber hosed 5. your sender kept a copy which still had you as a crypto recipient (as well as himself with encrypt-to-self), and the feds arrive at your door anyway. Point is, as long as you've got the private keys, it is potentially stored, courtesy of your favourite TLA. This is why you should use forward secrecy, or at least mimic it, by having a long term signature key, and generating a new public key for encryption every week/month, and revoking and destroying the old one. > >> I figure it's not that major a deal. But for those that want it, the > >> most secure, simultaneously least GAK friendly way to do it is to > >> archive and encrypt with separate storage keys. > > This is *exactly* what PGP does: it encrypts with the recipient key, > and the recovery key. Yes, it does, and that is GAK friendly. But that is not what I described above. The difference between what I describe above (quoted a few lines up), and what PGP is doing is that PGP's messages are sent across the internet encrypted to the "recovery key". This is GAK friendly because it is easy to implement GAK with it, you just make that "recovery key" the NSA's "recovery key" (or to avoid newspeak terms perhaps that should be government backdoor master key). Then they coerce ISPs and corporates to include a PGP SMTP policy enforcer which insists on all email having a second crypto recipient of the NSA's backdoor master key. The system is a beautiful GAK system, everything you need for a fully working GAK system is right there on sale by PGP Inc. With what I described, GAK is not possible. What I described is: the MUA archives sent email, and archives received email (after decryption) with none of this process leaking outside the corporate lan (that is it may involve communication inside the LAN). The archives can be encrypted, and you can have a corporate master key with access to these archives. But none of this goes over the Internet. > At this point, I'm not sure if we disagree or not. I'm not sure either, please let me know if I've explained myself this time! I'm worried that the hard time I'm having getting people to grok that escrowing comms keys is a bad idea if you're opposed to mandatory GAK is indicative of the success of the memes being spread by Freeh's crowd. PGP Inc are especially worrying, as they are in a position to influence the balance of whether we get GAK or not, and they appear to be helping GAK out somewhat. Whether this is complicit or whether they don't see that the fact they've implemented a fairly feasible GAK system as that significant in the argument, I'm not sure. However, I think the argument it is relatively straight-forward: companies care about backup of their data. They don't care about backup of their communications. So why backup communications keys? And why include the backup packet in the communication itself? For those companies who have been persuaded that they ought to read email received and email sent, you can implement this without weakening comms security as PGP have done with pgp5.5 for business which is to have a second crypto recipient for backup/backdoor being sent with the message over the internet. All you do for backup or company backdoor is to build in whatever storage, and encrypted archiving functions you wish into the MUA, or internal mail system. That is GAK unfriendly. If PGP Inc is still GAK unfriendly, and hasn't sold out to government, it should be doing something with similar properties to those I described above: not having backdoor second recipient access to traffic. What they have done is implemented a fully functional GAK system. (I get the feeling that sooner or later we're going to get a PRZ penned company position statement. I hope they get it right. I encourage them to re-think.) 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`

1 0

What's really in PGP 5.5?
by Anonymous 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Ryan Anderson wrote: >>What you call "fragility" is properly called "security". Would you >>describe 128-bit keys as more "fragile" than 40-bit keys? Why is PGP, >>Inc. inventing propaganda terms for the authorities? > >Okay, call it security but the point is, if you're protecting documents vital >to your company using encryption (say the design of a new product) and the >person who knows the passphrase dies, you've just lost a great deal of money. > >PGP for Business Security gives the business a way to have a backup key that >can read that person's information. Frankly, it might not be able to read >anybody elses, from the description given. > >This is a feature that any business (that understands encryption) will want. > >They can easily store the secret keys of the other id someplace secure, and >never retrieve them until someone dies. Disavow knowledge of them to >government, etc. heck, the keys can even be in the primary person's >posession. (Perhaps stored in a safe-deposit box, or without a passphrase, >etc.) Decrypting files and decrypting messages are not the same problem. The PGP product has SMTP support - it is explicitly designed to weaken transmitted messages. Just like Clipper. [Jon Callas wrote:] >>It is fascinating to me that every example you use does not involve >>decrypting transmitted messages. Yet, that is the feature which is >>under discussion. > >Amazingly, he gave an example where, had encryption been used, the >project would have stopped, and restarted because the person with the >keys was incapacitated. Are you just being combative here? No. I am making the distinction between files and messages. It is quite easy to use a key for encrypting files which is different from encrypting your messages. The key for encrypting files can then given to the appropriate company officer. It has been possible to use PGP in this mode forever. What is new is the feature set which will make it very easy to impose GAK on the customers of PGP. According to Mr. Schneier, the code is just sitting there in all their products waiting to be compiled in. >>The demand for the ability to decrypt encrypted messages in the >>corporate environment can easily be measured with this test: how >>many companies have a policy that requires employees to record all >>outgoing mail? > >Well, any company giving stock advice (and governed by SEC rules on >stock tips, etc.) is already require to have all outgoing mail >approved (e-mail and snail), so does it matter if they record it or >not? The answer to the question I posed is "No". The example you cite requires the company to review message before transmission, not afterward. After transmission, the recipient of the message can submit it as evidence to the SEC should there be an impropriety. This is no different from the way it works now. There is probably a context issue here. It sounds like you do not share the context within which many people on this list are operating. The Big Problem for PGP, Inc. right now is that in 18 months or so their products may be illegal to use within the United States. While many of the rank and file in the company may be willing to accept corporate dissolution under those circumstances, the board, the investors, and the senior management are unlikely to welcome that option. So, they are preparing for that situation. They are releasing products with GAK support right now. By the time it becomes mandated by law, it will be easy to compile the well tested features into all of the products, or just discontinue their line of privacy products and sell only their Big Brother Inside products. The corporate key becomes the government key with the stroke of a pen. PGP, Inc. is betting that they'll win either way. If GAK goes down in flames again, they can still trade on their reputation for being The Good Guys. If GAK becomes mandated by law: "We didn't want to do it, but we had no choice." Some of us may be in the habit of thinking of PGP, Inc. as the hero. However, the problem with organizations is that they are easily corrupted. Does this mean everybody in the organization is now working for the government? No, it does not. Most likely there are many PGP, Inc. employees who are feeling uncomfortable with this new development but they are being given the same lines we are getting. Many of these people are probably getting an additional "inside scoop" from their leaders that explains the "real" strategy. Hopefully, the rank and file at PGP knows that people you like and see in the hallways every day will still lie to you if they think their career depends on it. Monty Cantsin Editor in Chief Smile Magazine http://www.neoism.org/squares/smile_index.html http://www.neoism.org/squares/cantsin_10.html -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQEVAwUBNDuw65aWtjSmRH/5AQGwLgf7BBYy2HO30eDXO2YLqkgtuOxAcnQU19AO DOKIa3jwU723ICgWD00dPW1GegKL5LaRfp3a+Xtd+qjHaFs0IlXr4kJGv1wiCJhu sRKxmSi3g1aGIfiF48uMef5bbzPL27b3u78rJds+E44LP9zEnieBcACBp+3977W0 0N0k7ADY6ME+zmc4f5D5aLdJa8gprOCPj1nF6esspkMuDDu5iH/YY/GT6VprRCub NojEXPS/uB6tgTS4vDfenL8UWUUqjXQof8MrRoMAG6dsjvNEyU5WlhbnDgyh9nF5 DbuP9+oA8DHYSmEGzTxD4oG7mGwb+NMMuYOyg3xC1H8ou2Ajv0kfOg== =UtlQ -----END PGP SIGNATURE-----

2 1

Re: FCPUNX:CDT complains to my editors after post to cypherpunks
by James A. Donald 17 Dec '03

17 Dec '03

At 09:34 AM 9/26/97 -0700, Tim May wrote: > The larger issue is that the CDT/VTW "players" are showing their > willingness to trade away the civil liberties of us all for a few minor > tidbits thrown (they think) to corporate sponsors. CDT may not necessarily be pursuing the interests of its corporate sponsors. Legislation in congress, any legislation, the worse the better, will promote corporate donations to CDT. This does not meen that the corps want legislation. Indeed, this is a chronic problem with such mundane non civil liberties lobbies as the milk lobby. Big business sends their lobbyists to Washington, where they are corrupted by contact with politicians. --------------------------------------------------------------------- | We have the right to defend ourselves | http://www.jim.com/jamesd/ and our property, because of the kind | of animals that we are. True law | James A. Donald derives from this right, not from the | arbitrary power of the state. | jamesd(a)echeque.com

1 0

No Subject
by Zooko Journeyman 17 Dec '03

17 Dec '03

~h ~h ~h ~h ~v

1 0

Starting now, online town hall meeting with Rep. Dreier at www.democracy.net
by shabbir＠democracy.net 17 Dec '03

17 Dec '03

In just a few minutes, we'll be starting the online town hall meeting with Rep. David Dreier (R-CA). Dreier is a key member of Congress for the net community: he's on the Rules committee, which has the fate of SAFE in its hands. He's also been a leader in integrating Congressional committees and the net. Check it out http://www.democracy.net/ -Shabbir

1 0