December 2003 - cypherpunks-legacy

Re: EE Times on PRZ
by jalicqui＠prairienet.org 17 Dec '03

17 Dec '03

Strick wrote: >THUS SPAKE jalicqui(a)prairienet.org (Jeff Licquia): ># Another quote from the article posted elsewhere said that, "PGP, which is ># based on the Diffie-Hellman public-key technology developed in the 1970s..." ># This is technically true, since all public-key work (including RSA) is based ># to some extent on DH. It could be, however, that the author is confusing > >DH uses "discrete log" as the hard problem, and very straightforward >mathematics. > >RSA uses "factoring" as the hard problem, and a very clever back door. > >How do you decide if one is based on the other? Sorry, I wasn't perfectly clear. Of course, RSA is not based on Diffie-Hellman specifically; what I mean is that all public-key work is based on that general paper, which "invented" public-key cryptography. I think this very confusion may be plaguing the writer of the aforementioned article. ># public-key technology with Diffie-Hellman public-key in particular, which ># (as I understand it) is not particularly secure. > >It's still up in the air, isn't it, whether the discrete log or >factoring is the harder to crack. My intuition is they're the >same hard. It was my impression that DH had a further weakness not related to the difficulty of the hard problem. As my copy of Schneider is at home, I must defer to ignorance at this point.

1 0

Factorisation and Discrete Logs (was Re: EE Times on PRZ)
by dwa＠mirage.svl.trw.com 17 Dec '03

17 Dec '03

strick wrote: > > DH uses "discrete log" as the hard problem, and very straightforward > mathematics. > > RSA uses "factoring" as the hard problem, and a very clever back door. > > How do you decide if one is based on the other? > > # public-key technology with Diffie-Hellman public-key in particular, which > # (as I understand it) is not particularly secure. > > It's still up in the air, isn't it, whether the discrete log or > factoring is the harder to crack. My intuition is they're the > same hard. > > I know of no problem with DH that RSA doesn't have similar problems. > > strick It seems to me that factoring a large number is no harder than finding a discrete logarithm. Assume, for the moment, that an efficient method of computing discrete logs has been discovered, rendering systems like Diffie-Hellman key exchange unusuable. I contend that RSA is now equally unusable. The following variant of the Pollard p-1 method should provide an efficient factorisation method for an RSA modulus, say N. Choose, at random, "a" such that gcd(a,N) = 1. Compute x such that: a^x = 1 (mod N) [ Discrete log time! ] Partially factor x; say x = f * f * f ... where f is not necessarily prime. 1 2 3 n Note that it is usually easy to partially factor a "random" large integer. Simply using trial division up to some limit; or, at worst, pollard rho or pollard p-1 (on x) should suffice. If you're truly unlucky, pick another value for a. Compute: M = a^(10000! * f) (mod N) Where f is some partial factor of x. gcd(M-1,N) should yield a non-trivial factor of N. If it doesn't, another choice of f and/or a should work. I'm by no means a professional mathematician, but it seems that this scheme should work. Comments, anyone? Dana W. Albrecht dwa(a)mirage.svl.trw.com

4 3

Re: TEMPEST
by joelm＠eskimo.com 17 Dec '03

17 Dec '03

Tim May wrote: >TEMPEST has very little to do with Cypherpunks goals, actually. First, >buying such a gadget, tweaking it, exploring capabilities, etc., would >lead to what? The ability to park a van in front of someone's house >and--maybe--monitor their screens? We already know this is possible. >(You all knew that, didn't you?) If a Cypherpunk goal is to champion electronic privacy, it seems to me that it is important to fully understand any threats to the methods used to ensure privacy. The old Sun Tzu "know your enemy" philosophy. If I was running a Data Haven, I'd want to understand how and if my system could be passively eavesdropped on, and what countermeasures to take to minimize the risk. (Second or third down the list from knowing my encryption algorithm was secure.) Granted, I'd spend more efforts with firewalls because a hacker/cracker attack would be a more realistic threat, but if there was even the most remote chance that a government agency/well-funded concern with TEMPEST capability was interested in me, I'd sure like to make their job more difficult. The thing that I find frustrating about TEMPEST, is most informed people say "yes, it's possible," but I have encountered only breadcrumbs of real-world, technical information and sources on it (the VanEck article, the BBC tape, Grady Ward's paper, etc.). This is what prompted the original message to the list. Yes, TEMPEST is real. But what I'm trying to do is shift out TEMPEST reality (and capabilities) from the magical black-box in parked vans tales. Joel McNamara joelm(a)eskimo.com - finger for PGP key

2 1

Threats in real life - what are we worried about?
by Matt Blaze 17 Dec '03

17 Dec '03

Tim May writes: > TEMPEST has very little to do with Cypherpunks goals, actually. First, > buying such a gadget, tweaking it, exploring capabilities, etc., would > lead to what? The ability to park a van in front of someone's house > and--maybe--monitor their screens? We already know this is possible. > (You all knew that, didn't you?) I disagree. "TEMPEST" risks and countermeasures are but one entry on a long list of subjects in which our ignorance (and that of the civilian security community in general) may well come back to bite us. Granted, this is the "cypherpunks" list, not the "securitypunks" list, but it behooves anybody interested in developing strong mechanisms to accomplish some security objective to be at least acquainted with how those mechanisms fit in the larger picture. One of the most dangerous aspects of cryptology (more dangerous, perhaps, than fact that there are almost no solid theorems that tell us how secure practical ciphers really are) is that you can measure it. It's all too tempting to misuse an estimate for the cryptographic work factor for some cipher as if it were some kind of overall security metric for the systems in which it is deployed. In real life, there are lots of ways to violate system security, including cryptanalysis, protocol attacks, Trojan horses, viruses, electromagnetic monitoring, physical compromise, rubber hose cryptanalysis, OS bug exploitation, application bug exploitation, hardware bug exploitation, user error exploitation, physical monitoring, social engineering, court orders, dumpster diving, and so on and so on. Most of us on the list like to think about cryptography and cryptographic protocols, and that's fine, but it isn't the same as thinking about building secure systems that are strong enough to withstand attackers who aren't willing to restrict themselves to a strictly cryptographic threat model. Unfortunately, the world outside the cypherpunks list isn't much better off than we are in understanding these "informal", but all too real, threats. Thinking about some of them would, I think, go a long way toward contributing to "Cypherpunk goals" as I understand them. (Practical TEMPEST shielding is one such problem. Another good one is the almost completely ignored problem of storing secret keys on networked computers. Still another is the problem of using security software remotely with limited local computation. There are lots more.) That said, no one can force these discussions to happen, and no one, much less me, has a right to complain that everyone else is talking about the "wrong stuff". So let me raise a question: Given existing crypto tools (PGP, etc), what are the top ten practical attacks against the privacy of stored data and electronic mail? Who are the bad guys? What tools do we need to limit these threats? I'll post my own thoughts later. -matt

1 0

Re: EE Times on PRZ
by Andrew Lowenstern 17 Dec '03

17 Dec '03

jalicqui(a)prairienet.org (Jeff Licquia) wrote: > It was my impression that DH had a further weakness not related to > the difficulty of the hard problem. As my copy of Schneider is at > home, I must defer to ignorance at this point. My understanding is that once you do the computation to solve a DH exchange you can use that information to easily solve any exchange under the same generator and modulus. So it's important to at least use large enough numbers to make this unfeasable. I think it was Suns SecureRPC that shipped with a fixed (and not big enough) generator and modulus and was not secure (assuming someone had already done the pre-computation). Maybe this is what you were thinking of? As always, proper generation of components is an important consideration in implementing public-key systems. andrew

1 0

Law of Electronic Commerce -- seminar announcement
by rah＠shipwright.com 17 Dec '03

17 Dec '03

FWIW, Bob Hettinga >From: nsb(a)radiomail.net >Date: Wed, 18 Jan 1995 14:16:54 -0800 >To: inet-marketing(a)einet.net, www-buyinfo(a)allegra.att.com, > edi-new(a)tegsun.harvard.edu, ietf-edi(a)byu.edu >Original-From: "NSB's Portable (via RadioMail)" <nsb(a)radiomail.net> >Subject: Law of Electronic Commerce -- seminar announcement >Reply-To: Nathaniel Borenstein <nsb(a)nsb.fv.com> (via RadioMail) > >To help educate business professionals about electronic commerce, >First Virtual (TM) Holdings Incorporated is pleased to lend promotional >support to: > > Law of Electronic Commerce > On-line Seminar > Starting January 30, March 13, and May 9, 1995 > Future Dates to Be Announced > >The National Computer Security Association announces a new form of >professional education -- an on-line seminar. It is education >delivered through the NCSA InfoSecurity Forum on CompuServe. >(Internet delivery is also available.) For 30 days, attorney >Benjamin Wright will convene a seminar covering The Law of >Electronic Commerce -- EDI and E-mail Contracts and Records. > >Participants will attend the seminar by exchanging computer >messages with Wright in a private discussion forum. Thus, no one >will have to travel or miss time away from the office or home. > >The seminar is designed for security managers, Online and MIS >professionals, EDI managers, purchasing managers who use EDI and E- >mail, lawyers, accountants and auditors. Topics on the agenda: > >1. Electronic Contracts >2. Electronic Data Interchange (EDI) and Electronic Funds Transfer >3. Electronic Signatures >4. EDI Trading Partner Agreements >5. Value-Added Network Agreements >6. Electronic & Optical Evidence >7. EDI & Optical Tax Records >8. UCC Article 4A >9. Electronic Healthcare Data >10. E-mail Privacy > >Tuition is $350 for NCSA members and $395 for non-members. (Group >discounts are available.) > >The starting dates for the next three sessions of the seminar are >January 30, March 13, and May 9, 1995. > >Special Guest Lecturers: > > Nathaniel Borenstein, Chief Scientist, > First Virtual Holdings Incorporated > > Richard K. Crone of KPMG Peat Marwick LLP, > electronic banking expert > >Views expressed in the seminar are those of the individuals expressing >them and not necessarily those of sponsors, employers or anyone else. > >To register on-line, or for more information and a free brochure, point >your browser at the following URL: > >http://www.infohaus.com/sponsored/ncsa-seminar.html > >Or write to: > >National Computer Security Association >10 South Courthouse Ave. >Carlisle, PA 17013 >Tel: (800) 488-4595 >Tel: (717) 258-1816 >Fax: (717) 243-8642 >bwrigh01(a)reach.com > > (This Notice May Be Distributed Freely) ----------------- Robert Hettinga (rah(a)shipwright.com) "There is no difference between someone Shipwright Development Corporation who eats too little and sees Heaven and 44 Farquhar Street someone who drinks too much and sees Boston, MA 02331 USA snakes." -- Bertrand Russell (617) 323-7923

1 0

Re: Another problem w/Data Havens...
by pstemari＠erinet.com 17 Dec '03

17 Dec '03

At 05:05 PM 1/17/95 -0700, Ben.Goren(a)asu.edu wrote: > ... That's the main reason why I like my idea of having a trusted encryptor. >Nobody's suggested that the current timestamp operators would be in Deep >Doo-Doo if they timestampped some piece of thoughtcrime; why should >somebody who encrypts be any different? ... Quite possibly the timestampers would be in trouble, the risk for them is the same as the risk for the remailers and the DH operators. As long as some piece of info is considered to be a thought-crime, everyone who accepts info from a wide range of sources is at risk. > ... The service could even be advertised as a different form of timestamping >(or notarizing). Not only do you get the file back signed, but you get it >back encrypted and signed. ... That would still be a useful service, however, but it does transfer the risk from the DH operator to the encryptor. Since he isn't leaving evidence on a hard drive, his window of vunerability is somewhat less. --Paul J. Ste. Marie pstemari(a)well.sf.ca.us, pstemari(a)erinet.com

1 0

Re: Does encrypted equal safe?
by pstemari＠erinet.com 17 Dec '03

17 Dec '03

At 04:55 PM 1/17/95, Sandy Sandfort wrote: > ... In my law school they taught that the burden of proof in a >criminal case was on the government. Unless of course the case involves porn, drugs, etc, in which case the current practice in the American legal system places the onus on the accused, regardless of what the Constitution requires. Civil forfeiture is a fine example of this, along with requiring porn producers to demonstrate the age of their models, etc ad nauseum. --Paul J. Ste. Marie pstemari(a)well.sf.ca.us, pstemari(a)erinet.com

1 0

Re: Another problem w/Data Havens...
by wcs＠anchor.ho.att.com 17 Dec '03

17 Dec '03

Michael wrote: > This entire discussion is completely unnecessary. There are ways > of removing operator liability without examining the submission at all. Liability is a legal issue, not a technical one. (Catchability is a technical issue.) The basic ways to remove liability are to either run your system where the local laws don't object to information storage, or to reduce the operator's involvement to levels that the local legal system will tolerate. The former case is easy, if you can rent computer space in a country with a non-meddling government and good net access (or an easily rentable government :-).) For those of us in the latter situation, the discussion's still useful... On Mon, 16 Jan 1995, Johnathan Corgan wrote: > > It just occurred to me when reading this another method for ensuring > > the "I can't tell what's in it" condition with a data haven operator. > > Why not use a secret sharing system where the contraband data is > > split into a number of pieces and sent to different havens? Good, but still has most of the same old risks. Alice asks Dave's Data Haven to store stuff, and later retrieves it. Dave doesn't want to be able to know what's in it. There are three main threat periods - at receipt of the data, during storage, and at retrieval. Secret sharing is great for the storage period, assuming the data havens are in different jurisdictions and the cops can't force the operator (Dave) to go retrieve all the pieces. However, at receipt of the data, it's all in one place, Dave's inbox. If Alice encrypted it safely, or secret-shared it herself, great! But if Alice is a narc trying to entrap Dave with plaintext ThoughtCrime, or Alice's key has been compromised, anything in Dave's inbox is still toast, even if anything that's been split and stored is safer than if it had been stored unsplit. So he either needs to split it fast, shortening the window, or find a way to blind his mail before processing it, or split it before reading it. Splitting before reading isn't impossible in a stream environment. Define a protocol that looks like SMTP, but opens up three outgoing streams as well as an incoming stream, and uses standard mail formats. While reading the headers from Alice (either the real contents or just the handshakes at the beginning), Dave's receiver thinks about them and sends some meaningful headers to Moe, Larry, and Curly. Once the message body starts, instead of storing the incoming bytes, Dave sends every other byte to Moe or Larry, and the xors to Curly.* If he wants to get fancy, he can even encrypt the data with a stream cypher as he goes along, giving half the key to each of them. That way, Dave's system really only has knowledge of the headers, plus one line at a time of incriminating data on the fly. And his partners can't give anything away either; they're just stooges. * If the connections to and storage by Moe and Larry are reliable enough, Curly doesn't really need to be involved, but the xor business lets you reconstruct everything from just two parts. Bill "Privacy is not a crime!"

7 8

Re: Another problem w/Data Havens...
by Ben.Goren＠asu.edu 17 Dec '03

17 Dec '03

At 4:33 PM 1/18/95, Paul J. Ste. Marie wrote: >[. . .] As long as >some piece of info is considered to be a thought-crime, everyone who accepts >info from a wide range of sources is at risk. We might have a test case right now for part of that idea--the Scientologists. They're essentially claiming that the various newsgroups should be shut down because somebody put thoughtcrime on them. I would posit that the operator of any automated data transmission/massaging service is not responsible for the data that passes through her equipment. Consider, for example, if I used a bang path to route an illicit email note through, say, apple.com. Does that make Apple Computer responsible for what I send? Tying in with some of Eric's comments, this could be viewed as a fundamental flaw in the 'net: it's the sender, generally, who initiates and controls the connection, not the recipient. We could view this as an advantage: how can you blame me for what somebody else does to my computer without my knowledge, especially if I have no way to stop it short of getting off the 'net completely? >> ... The service could even be advertised as a different form of timestamping >>(or notarizing). Not only do you get the file back signed, but you get it >>back encrypted and signed. ... > >That would still be a useful service, however, but it does transfer the risk >from the DH operator to the encryptor. Since he isn't leaving evidence on a >hard drive, his window of vunerability is somewhat less. Less to nonexistent. If no human sees it on the encrypting site, no human can be responsible for it. "They" would have to ban the service outright, or try to prove that you knew that your site would be used for illicit purposes. If putting a warning to not export crypto software on an ftp site is sufficient protection--and, judging from the number of sites which do no more than that, it is--then a simple statement that the service is not to be used for any illegal purpose should do fine here. > --Paul J. Ste. Marie > pstemari(a)well.sf.ca.us, pstemari(a)erinet.com b& -- Ben.Goren(a)asu.edu, Arizona State University School of Music Finger ben(a)tux.music.asu.edu for PGP public key ID 0x875B059.

2 1