December 2003 - cypherpunks-legacy

Re: PGP CAKware & IETF controlled Open-PGP standard
by Omegaman 17 Dec '03

17 Dec '03

Adam Back writes: > Jonathan Seybold <jseybold(a)pgp.com> writes: > > Adam, one aspect of your suggestion puzzles me: > > One thing which concerns me most is KNOWING when a message I send > > (or receive) could be read by someone else. The PGP CMR scheme makes this > > very clear: if there is an extra CMR key, the message may be read by > > whomever controls that key, if not, only the recipient may decrypt the > > message. > > If, however, the message is secretly re-encrypted to a corporate > > storage key AFTER it is received, I will never know that. > > You will if you mark the key with this information. This is a straw man anyway. You don't know this now. Someone you are communicating with could already be forwarding plaintext to a third party unbeknownst to the sender. This is a "do you trust the recipient" issue. > What I _am_ arguing is that in designing systems to provide companies > with data recovery mechanisms that you should a) not weaken security > more than necessary, and b) that it would be nice if you used a method > which doesn't introduce GAK compliancy for communications keys. > > I presented I think in plenty of detail an alternate mechanism which > is both non-GAK compliant, and more secure. So what is the problem? > Is there a technical flaw in my solution? No. But there is in their's(PGP Inc.) as I think you and others have amply demonstrated. The technical issues alone are enough to reject usage of PGP5.5's CMR features. It intrigues me that there has been virtual silence from PGP employees on the technical issues. Only Hal Finney via the IETF-Open-PGP has come anywhere near commenting upon this. I haven't seen anyone from PGP Inc. comment on your data-recovery implementation ideas. In my optimistic moments, I take this as a sign that internally, PGP inc. is giving consideration to producting more sensible and effective solutions. (Maybe even as outlined here) > > This means, I believe, that they should NEVER INVOLVE HIDDEN BACK > > DOORS THAT USERS ARE NOT AWARE OF. > > Agreed. You can flag backdoors with either solution. See above. The prescence of flags does not prevent this. By definition I might add ;). Trust issues, etc. are involved. > It works well enough, but it could be made much more secure, by > separating storage key functionality from transient message key > functionality. This would also give you the chance to resolve the > articificially created need for GAK compliancy, which arises because > you are being forced by this lack of distinction between key > functionalities to use one key for both long term storage and what > should be transient communications key usage. Hal Finney's description of key sttributes indicate that implementing separate storage keys would not be hard for PGP Inc to implement in the next release. > Decentralised control is good, of course, but the pgp5.5 and SMTP > policy enforcer is a ready to roll GAK system. Of course, other companies could have (and will) implement similar systems. That PGP, with it's reputation and stated policies, would is surprising. Hopefully, PGP will live up to their reputation by realizing this misstep and correcting it with a more secure, less GAK-compliant implementation. > The PGP bashing PGP observes is an attempt by the pro-privacy crypto > community to influence PGP to re-think the GAK compliancy, and to > point out the more secure way to implement corporate recovery of > stored email messages without GAK compliancy. > > I reserve the right to bash any company which attempts to field GAK > compliant software. The "bashing" in this notoriously harsh forum has been rather tender in my view. Perhaps the perception of "bashing" is based on recognition (and guilt) that the CMR mechanism is flawed and goes against "the spirit of PGP." Methinks, y'all doth protest too much. -- --------------------------------------------------------------------- Omegaman <mailto:omegam@cmq.com>|"When they kick out your front door, PGP Key fingerprint = | How are you gonna come? 6D 31 C3 00 77 8C D1 C2 | With your hands upon your head, 59 0A 01 E3 AF 81 94 63 | Or on the trigger of your gun?" Send email with "get key" as the| -- The Clash, "Guns of Brixton" "Subject:"to get my public key | _London_Calling_ , 1980 ---------------------------------------------------------------------

1 0

Equal rights for receivers
by Anonymous 17 Dec '03

17 Dec '03

Remind me again: Why was it OK when the SENDER could choose to encrypt to an additional key, but it's a threat to the free world if the RECEIVER is allowed to request the same thing?

2 2

Rules of Engagement on Video
by Jim Burnes 17 Dec '03

17 Dec '03

I know this isn't directly cypher related, but oh well. An award winning film, "Waco: the rules of engagement" is now available on video. Previously running at Art Houses and Film Festivals it was produced by a few revolutionary media people. Somehow it occurred to them that all the right-wingers had beaten them to the punch making civil rights abuses known to the public. Can't have any of that now, can we? Why should *they* have all the fun? Anyway its been lauded as a very well balanced work. Not like those other people -- talking about evil, new world order conspiracies. ;-) Probably most noteworthy is the included FLIR FBI footage (Forward Looking InfraRed) which, under expert scrutiny, appears to show LEFs raining automatic fire down on citizen units trying to escape the final conflagration. Here expert scrutiny is defined as the head of research for the army night vision development group. Its definitely the cure for those times when GAK starts looking like reasonable, sensible and prudent alternative. I have absolutely no involvement or monetary connection to these people. I just wish they would have put it on video first. "Is your religion BATF approved?" ---------- Forwarded message ---------- Date: Wed, 15 Oct 1997 12:34:04 -0700 (PDT) From: SomFord Entertainment <somford(a)worldnet.att.net> To: somford(a)worldnet.att.net Subject: "Waco: The Rules of Engagement" Video Order Form Thanks for your interest in obtaining the video of "Waco: The Rules of Engagement". We are pleased to announce that it is finally available! Please check the website periodically for ongoing reviews, press, announcements and updates to the order form. http://www.waco93.com/ "Waco: The Rules of Engagement" Video Order Form Print, Complete, And Mail This Form With Check Or Money Order To: SomFord Entertainment, 8778 Sunset Bl., Los Angeles, CA 90069 Questions: 310-289-3900 1. E-Mail Address:............................................... 2. First Name:................................................... 3. Last Name:.................................................... 4. Street Address:............................................... 5. Apt. No., Other Info:......................................... 6. City:......................................................... 7. State/Province:............................................... 8. Country:...................................................... 9. Postal Code:.................................................. 10. Phone:....................................................... 11. "Waco: The Rules of Engagement" Video.........Quantity:...... $25.00 for 1 tape. $22.50 each for 5 tapes. $20.00 each for 10 tapes. Bookstores and Catalogues, Call for Bulk Order Info. All Prices Include Domestic Shipping and Handling. CA Residents Please Add 8.25% Sales Tax. 12. Total:....................................................... Make Check or Money Order Payable to: SomFord Entertainment. Comments Or Special Delivery Instructions:....................... Please allow three weeks for delivery. Thank you for your order

3 2

New Mailing List: Terrorism
by John Gilmore 17 Dec '03

17 Dec '03

Sounds like some "civil rights oriented" EMS, fire, law enforcement, intelligence community, etc people should join, and let the rest of us know what they are doing... John From: churton.budd(a)mediccom.org (Churton Budd) Date: Sat, 11 Oct 1997 10:55:40 GMT TERRORISM --------- TERRORISM is intended for discussion about terrorism response and prevention, including intelligence gathering and emergency responses. Topics include weapons of mass destruction, suspicious activities, educational and funding opportunities, politics, and response ideas. TERRORISM is an open forum to EMS, fire, law enforcement, intelligence community, disaster preparedness & response, and military personnel with an interest in preventing and responding to terrorist incidents. Announcements about new educational opportunities and grants are welcome, as are new products, services, or technologies directly related to terrorism response. Listname: terrorism Post to: terrorism(a)mediccom.org subscription command: subscribe terrorism sent to: listserv(a)mediccom.org

1 0

why Phil Zimmermann should be speaking out against pgp5.5 and CMR
by Adam Back 17 Dec '03

17 Dec '03

(Readers may notice PRZ's email address on the Cc line, this is an open letter addressed to him). In the debate on the controversial pgp5.5 commerical message recover (CMR) system, I noticed someone made the comment that they couldn't see what the big deal is with enforced multiple crypto recipients who aren't also message recipients, as pgp2.x has had non-enforced multiple crypto recipients for ages. I will put the case for why this practice should be avoided for security reasons. I would like to also put the case of why the enforced multiple crypto recipient construct should be avoided in building messaging systems where the designers would like to avoid building GAK compliant systems. The security reasoning is simple: there are is an extra door into the encrypted data: via the CMR key. Introducing an extra door reduces security, because there are now two keys which could be compromised to gain access to the data. That was simple. Possibly not that major a problem, perhaps both keys are so well secured that the additional leakage is academic. In that case, fair enough. Now the GAK compliant case: Firstly it is important to understand the subtle but very significant difference between enforced crypto recipients who aren't message recipients and normal pgp2.x style multiple crypto recipients. This difference is as much to do with the way that mail clients and plugins have used the pgp2.x multiple crypto recipients in fielded systems as with the actual messaging packet differences. A message recipient is someone who's email address is listed in a To: Cc: or Bcc: field in your mail client. A crypto recipient is someone who will be able to decrypt the message. Pgp is a hybrid crypto system, a message consists of the email encrypted with a randomly generated symmetric key, the session key. The session key is in turn encrypted to the public key of the recipient, these are called Public Key Encrypted (PKE) packets. To implement multiple crypto recipients pgp simply tacks on as many PKE packets as there are crypto recipients; each PKE packet being the session key encrypted to the public key of one of the crypto recipients. Now in most fielded PGP email plugins, and clients which take notice of Cc: and Bcc: fields, the number of crypto recipients ties directly with the number of message recipients. This makes it difficult therefore for the existing systems to automate encryption to a third party without software modifications. If a company which is hoping to become a market leader (a hint PGP) were to retain this functionality, GAKkers would find it difficult to use this software to effectively impose GAK. Sure you can Cc: your message to the NSA key. This would be voluntary GAK. Carl Ellison and a number of others suggested this whimsically years back. As in "What's all the fuss about voluntary key escrow, I'll implement voluntary key escrow for you right now, get DIRNSA to generate a key, and I'll sign it, and put it on the keyservers -- end of problem". Carl Ellison had a very good point. The government doesn't want voluntary key escrow, they want as some suspected all along mandatory key escrow, they want GAK (the GAK term is coincidentally another Carl Ellison meme). The reason this is voluntary GAK is that the user in most mail systems would have to go to some concious effort to do this, and may forget some of the time. (It's difficult to make "forgetting" a 5 year jailable offense). Now I'm well aware that some email clients, and MTAs will no doubt allow you to forward copies of all your email transparently to another party. (Please don't flood us with replies describing such functionality). But this is not really the point; it doesn't matter if you can forward copies of your encrypted email "thoughtpolice(a)nsa.gov" -- they can't decrypt it with out the recipients key. Now we come to the danger of PGP Inc's CMR mechanism. CMR breaks this traditional premise that the crypto recipients correspond one-to-one with the message recipients. What it allows is instructions to be given in a public key that tell the software to encrypt messages intended for the owner of this key to two message recipients. This means that for example: If Phil Zimmermann is using his own companies pgp5.0 mail client (and I presume he is), that if the US Government were to pass a law requiring everyone to generate new CMR keys that he would be able to comply without changing his software. This is why I would argue that even pgp5.0 is GAK compliant, it knows how to understand CMR public keys. (I am not actually sure if the pgp5.0 mail client can generate CMR public keys, but the pgp5.5 one can for sure, I'd welcome clarification on this point). The new mandatory GAK law would mean that if he didn't generate a CMR key he would go to jail. So he complies. The terms of the law dictate that the CMR recipeint in individual's mail clients must be "thoughtpolice(a)nsa.gov". Now the next time one of PRZ's favourite resistance groups that he likes to tell us stories about send him an email thanking him for the useful piece of software he provided them with, the USG can listen in because the pgp5.0 software which the resistance fighters have presumably also upgraded to will understand PRZ's CMR key. The USG will if it suits their purposes sell this information to the government in the originating country, and they will have the death squads go kill the resistance fighters if they can determine their identities from the leaked message. This kind of makes a mockery of what PRZ and the PGP brand stands for. Now the pgp 5.5 defenders at PGP Inc will jump up at this point and tell us that this is not so because pgp 5.0 has ability to strip out the second enforced recipient. Well it does. However, PGP Inc has come up with another related clever innovation: their SMTP policy enforcer. This ensures that when resistance fighters attempt to send PRZ email inside the PGP Inc offices (where they will be presumably field testing their GAKware software suite), that if they do take off the CMR recipient, that their mail will bounce. So not being technical crypto gurus, they will try not taking it off next time and the NSA will read the mail again, resulting in the resitance fighters death. Or perhaps alternatively if they really did want to send him email for an important reason, like perhaps to warn him that the corrupt government they were fighting against was going to introduce a law of mandating the use of pgp5.5 by all ISPs and individuals, they would have no way to reach him. This would suit PRZ quite well, because he probably wouldn't want to hear that. Actually it is possibly not fair to pick on PRZ, as I consider it somewhat likely than PRZ is dragging his feet internally to PGP, but is powerless to stop the corporate mindset now at the helm. And if so I apologise for making points at his expense. But also it is important that if PRZ is against this move, that he speak up. That act would have major significance in altering PGP Incs mind. It might also result in a parting of the ways, but I understand from attenders at a physical cypherpunks meeting in the US that PRZ when quizzed about PGP Inc corporate mentality meaning the company would eventually sell out to GAK, relayed that he would quit rather than have be associated with this. 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

Re: Encryption Program
by Randall Farmer 17 Dec '03

17 Dec '03

Although I don't know the PRNG in Visual Basic (the one 3dmx uses) well enough to do much real analysis, the description of an attempt to correct a problem in it shows a weakness in the "enhanced" version...here's a slightly abridged/clarified copy of the message I sent the author about it. ------------------------------------------------------------------------------- <headers snipped> ... > While it is true that PRNG's are not very good, Well, there isn't any big problem with PRNGs as a class -- RC4 is based on a PRNG, and it's okay to use as long as you know its limitations (i.e., just so you don't try using the same key twice or anything similarly silly). ... > I believe I found a way around that problem...I used a syst[e]m of cubic > arrays. The program first creates sixteen cubic arrays, and fills them one > space at a time with random characters. When the stream of characters to be > XORed with the plaintext is generated, it picks a random cube and a random > location with[in] that cube. I can't do much real analysis since I don't know how Visual Basic's PRNG works, but with a truly secure PRNG like one you would see in a good stream cipher, you can't predict x bits of the PRNG's output with more than 1/2^x probability of bring right without doing exhaustive search of the keyspace. However, your arrays almost surely won't be filled with the *exact* same quantity of each character, so, even if the bytes in your PRNG's output are selected randomly from the arrays, some bytes are more likely to be a byte in your "enhanced" PRNG's output than others. Therefore, given a bunch of the stream, one can guess the next 8 bits of the PRNG's output with more than 1/256 probability of being right, meaning your PRNG doesn't fit the bill. To sum it up, no matter what Visual Basic's PRNG does, that method *can't* be 100% secure. ... --------------------------------------------------------------------------- Randall Farmer rfarmer(a)hiwaay.net http://hiwaay.net/~rfarmer

1 0

Re: proposal: commercial data recovery
by goddesshera＠juno.com 17 Dec '03

17 Dec '03

On Tue, Oct 14, 1997 at 10:37:21AM +0100, Adam Back wrote: > > If we take the design goal of designing a commercial data recovery > system which is not GAK compliant, we can most succinctly state this > design goal as the task of ensuring that: I take a certain sad pleasure in reminding people that among my first posts on this list I warned that cypherpunks had better design a commercial key recovery system, or one they didn't like would be forced down their throats. Attila now spouts my line exactly, Adam is busy designing (though he still can't bring himself to use the term 'key recovery', being meme-dominated as he is), and Tim nods approvingly. Good luck, gentlemen -- you should have been doing this a year ago. -- Kent Crispin "No reason to get excited", kent(a)songbird.com the thief he kindly spoke... PGP fingerprint: B1 8B 72 ED 55 21 5E 44 61 F4 58 0F 72 10 65 55 http://songbird.com/kent/pgp_key.html This message was automatically remailed. The sender is unknown, unlogged, and nonreplyable. Send complaints and blocking requests to <goddesshera(a)juno.com>.

1 0

Re: the case for separate comms keys
by pgut001＠cs.auckland.ac.nz 17 Dec '03

17 Dec '03

Death rays from Mars made Adam Back <aba(a)dcs.ex.ac.uk> write: >You can also acheive the same flexibility with an extra indirection with >symmetric storage keys (optionally held in escrow). In fact I think this is >what later versions of Peter Gutmann's SFS do. The reason he uses for this is >that it allows you to change your passphrase without re-encrypting the whole >disk, because the _actual_ disk encryption key is encrypted itself with the >hash of your passphrase, rather than using the hash of the passphrase directly >as the key. There are also a few other reasons for doing this, and I've extended the idea used in SFS for use with my cryptlib encryption toolkit. Instead of encrypting just the key, you also encrypt the algorithm details, ie: E ( algorithm, algorithmInfo, key ) passphrase E ( data ) algorithm, algorithmInfo, key This makes the job of an attacker somewhat harder because even if they have some means of performing a reasonable attack on the second encryption step, they won't know exactly what it is, so even if it only has a 40-bit key they might need to search half a dozen algorithms before finding the right one. This makes it a lot harder to just brute-force everything going past in the hope of finding something useful. This is especially entertaining for algorithms like RC5 and Safer, where you can produce dozens of variations by playing with algorithm parameters, in effect adding extra bits to the key length. As Adam mentions, you can also escrow[0] the second key (which SFS does using a threshold scheme with the parameters controlled by the user). In this way the user can change their password without destroying the ability of the escrow to access the data. Finally, using the session-key mechanism means you never encrypt two lots of data using the same key, and means you can encrypt a single message for multiple recipients just like the public-key equivalent. Peter. [0] This is "escrow" used in the true sense, not the GAK euphemism. It's completely under the control of the user, it's optional, and it's intended for recovery of stored data when you forget the passphrase.

1 0

Re: CVS: cvs.openbsd.org: ports
by Warner Losh 17 Dec '03

17 Dec '03

In message <E0xLTBc-0001Bo-00(a)rover.village.org> uk1o(a)rz.uni-karlsruhe.de writes: : How about suggesting a make variable HAS_LIBCRYPT to the FreeBSD people? : We could set it in <bsd.own.mk> or something like this (to a value : meaning "we don't have it and we don't need it either), and FreeBSD could : do similar. The problem isn't in the BSD make files, but rather in the makefiles of the ports. True, many FreeBSD ports' patches add -lcrypt blindly to the makefile, but that could change. : Another way were patching the third party program's Makefile accordingly. : We should introduce a patches-${OPSYS} directory having precedence before : the patches directory of a port. Thus we could maintain our special patches : for ports which need them while continuing to use the FreeBSD ports where : they work out of the box. I see now that this is already implemented in : <bsd.port.mk>, so we could just USE that. There already is the patches-${OPSYS} that can be used for this purpose. Warner

1 0

I have seen the future.....
by tech21＠tectel.com 17 Dec '03

17 Dec '03

I HAVE SEEN THE FUTURE And it will change your world soon... I receive a lot of telephone calls. All of them interesting-some of them fascinating. Seldom though, do I receive a call that I would truly refer to as "compelling." That is, of course, until my phone rang about 3 weeks ago. I still can't believe it. Odd call. Gentleman wanted some information-specific information. Of course I had a few questions that I needed answered first. "What's the product?" "Can't tell you," came a rather hollow reply. "Can't tell me? Why not?" I pressed, becoming increasingly more curious-and irritated-by the moment. Seeming to change the subject he said, "We want you to come take a look, and give us your opinion." "Come where? And give you my opinion on what?" "We'll send you a plane ticket." Three days later, I found myself staring out the window of that early morning Delta flight as we made our final approach, wondering what in the world I have got myself into. Met with the founders and the young man who had invented the technology. I guess it was about 55 minutes into the presentation that I understood what these guys were up to, and the profound effect this was going to have upon the world-our world. While I sat there riveted on the CEO's every word, transfixed by the passion emanating from his steel blue eyes, I felt like some character in a spy novel, conspiring on a plot to overthrow the government. One day, I'll tell you the whole story. What you ask could have such a profound effect upon our world? THE TOTAL DESTRUCTION OF THE TELE-COMMUNICATION INDUSTRY AS IT CURRENTLY EXISTS!! I've recently been invited to the high technology company discussed above. It is a new publicly traded company. It will be the Microsoft of the telephone industry. It is extremely well funded and has patented high technology. The proprietary technology is the most significant advance in over 100 years of tele-communications. Protected by 2 patents covering 48 applications, we have a private network infrastructure at a pre-opening investment of approximately 23 million dollars. We are not re-sellers of Long Distance time; rather a direct competitor to AT&T and others. To illustrate the potential of this proprietary technology: the internal cost of AT&T to complete a call is calculated at approximately 3 cents per minute; MCI and Sprint the second and third largest competitor based on cost of approximately 4 cents per minute. Our private network "compression technology" can accomplish the same call for as little as 2/ 100th of a cent per minute. For example, AT&T and MCI just announced they were going to cut their basic rates by 5% during the daytime and 15% during the nighttime. On a 15 minute coast to coast call AT&T's new price will be $4.65 during the day for their average customer, our regular price to every customer every day (24 hours per day, 7 days per week) is $1.18. We can afford to beat AT&T pricing because of our technology. But you ask, do I have to use any special equipment. Absolutely not. Just pick up the phone and call the party you want to reach. Pricing is only the tip of the iceberg with our new technology. Our multimedia products are going to make your life so much easier. Star Trek is here, right now and our smart communications platform will bring it to you. AT&T, MCI, and Sprint, look out there is a new major player in town. We will only work with a limited number of individuals to launch this company. If you think you have what it takes or have proven that you do, do not wait a moment longer. This is a ground floor business opportunity, with a compensation package potentially 300% more lucrative than our nearest competitors. Would you agree I have something here that spells opportunity? If yes, we need to talk further, immediately. Call for information and cassette 1-800-741-6240 or e-mail us at technology(a)tectel.com Please indicate your name, address, and telephone number in the body of your response. ************************************************************ Removal Instructions... It is in no way my intention to send anything to anyone who is not interested in the information; If you would like to receive future updates, simply reply to this message with "subscribe" in the subject line to subscribe(a)tectel.com and indicate your name, address, and telephone number in the body of your response. Please complete all information. If we do not hear from you, you will be automatically removed from future updates and will not be contacted again.

1 0