December 2003 - cypherpunks-legacy

Re: Leahy bill nightmare scenario?
by jim bell 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- At 06:14 AM 3/8/96 GMT, Dan Weinstein wrote: >On Wed, 06 Mar 1996 16:59:36 -0800, you wrote: > >>At that point, Bob is GUILTY of violation of the Leahy bill, because his >>encrypted anonymous remailer: >> >>1. Uses encryption to thwart message tracing, and thus the "criminal >>investigation." >> >>2. Bob has already been informed that his system will be used for illegal >>purposes; the cops have the messages to prove he has been told. He's GUILTY >>GUILTY GUILTY, he will definitely lose the system and possibly whatever >>residence it runs in, and will probably have to pay a huge fine to boot. > >This is not my understanding. I believe that Bob has to be commiting >a felony himself before they can get him under the current phrasing. Well, first, the section's phrasing is screwed up. Whether this is the fault of VTW, who posted the text, or the original bill I do not know. Second, if what they're charging is the hindrance of an felony investigation, it isn't clear to me why they would be limiting the charging of that "crime" to only those actually who have committed a felony. (logic isn't the normal mode of thought for a government employee, you realize.) Third, all they have to do is to "suspect" the person of a felony, and a "felony investigation" starts. That would presumably make him guilty of the Leahy bill's provision, regardless of whether he is actually participating in the crime supposedly being investigated. Fourth, I gave what I considered to be a clear example of the hypothetical misuse of an encrypted remailer by the cops, one that would arguably make the remailer operator guilty of some "reasonable" anti-kiddie-porn statute. At that point, _he_is_ the target of the investigation. Unless you can show that this kind of action by the government is impossible, I consider it to be not merely possible but almost certain to occur. Fifth, it isn't clear what amount of knowledge is necessary to "trigger" this clause, especially in its current flawed state. Since ISP's and encrypted remailers might know, in general, that their systems can and probably are being used for SOME criminal activity, even if they can't identify it or the user, or decrypt it, etc, a broad interpretation of the resulting law could easily de-facto prohibit any business practices (i.e., allowing users to use encryption) that prevents full-scale monitoring and/or tracing. This is only the beginning of the problems with this section. If you can explain why nothing I've described could possibly occur, I welcome a contrary explanation. But I would also ask this: Why, exactly, do we need this section? We've already been told that the opponents of this bill will fight it tooth-and-nail under its current wording; if that's the case then the presence of this section is inadequate to appease their unhappiness. Therefore, we shouldn't include it in the bill at all; it does no good. Any explanations, Dan? BTW, I'm not the source of those recent anonymous notes on Cypherpunks criticizing you for the support of this bill. As you by now have guessed, I'm not at all reticent about standing up and being counted and identified. Jim Bell jimbell(a)pacifier.com Klaatu Burada Nikto -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMUBjH/qHVDBboB2dAQEeEAQAm5V7jTZWZo1MIIaL1WlQjQHdSlAOCMNJ 7j7tfpH6peWM23T7iGhZT3AckqPYwLxV8u6N96SFxaQDJ+IiCRyBRO+5qxr6sxXk A9BCkmRxzorsqeViyIVev9lzMcljtTiZmTQ7KIAToSZD4+12xQgROLZRYtf1/tlv E7ypJHLtsFM= =2MNi -----END PGP SIGNATURE-----

1 0

Re: Quotations
by jim bell 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- At 09:17 AM 3/8/96 -0500, A. Padgett Peterson P.E. Information Security wrote: >Mr. Bell posted: >>Note to the rest of you: Observe how Mr. Peterson carefully avoids quoting >>any material that was contained in my notes to him. This makes his failure >>to respond to my points less clear. This is entirely intentional on his part. > >The reason I avoided references is that the E-Mail in question was sent off >line to him personally. 1. Peterson admits he "avoided" references. 2. The "reason" he gave (that the material was sent to me personally) does not justify or even explain his failing to quote my material and respond to it. He could have just as easily sent me email that contained responses to all of my comments, had he chosen to do so. > Fortunately I do not expect others to respect that >so avoid saying anything that cannot be made public. I do not "respect" sleazy people, and especially sleazy people who are trying to evade the issues and their failure to be able to address the matters under discussion by hiding it in email. I refuse to assist others in hiding their dishonesty by such a tactic. Since the matter started out as a public discussion, I chose to keep it public and still choose this. > However in such cases >I do not feel any need to requote everything I am responding to. Except that your failure to quote that material was clearly intended to disguise the fact that you had no satisfactory response (even by your own standards!) to my commentary. This is typical of you. Jim Bell jimbell(a)pacifier.com -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMUBtIPqHVDBboB2dAQFZoQP6AjnijC6gNXWewtrRs3PMYLQn/nUQSQ31 vEQcQMVd+M0siyiv9DdARNGM/Vt6vfxuEIRrfZFw3uUTjLJvjHi7MxsD8BEGUbCZ z1+6OA8y3ei7yJ7h3zL7lFi+0m76lA0Njp3HSscRXPkNPAGJR7WnMlJcl6ELsDv5 WZygZS8ivlo= =JTFh -----END PGP SIGNATURE-----

1 0

News on RSA vs. Cylink Injunctions and Patents
by baldwin 17 Dec '03

17 Dec '03

The following press release from RSA may be of interest to the folks on this list. --Bob ----------------------------------- Subject: NEWS: Cylink loses in attempt to enjoin RSA licensing REDWOOD CITY, Calif.--(BUSINESS WIRE)--March 8, 1996--In a ruling filed March 4, the Honorable Spencer Williams, U.S. District Court Judge for the Northern District of California, denied Cylink Corporation's motion seeking an injunction against RSA Data Security, Inc.'s licensing of its BSAFE/TIPEM toolkit software. Cylink contends that RSA's software infringes its Stanford patents and that licensing required an additional grant from Cylink, despite the fact that RSA already has a license. After hearing oral arguments on Feb. 29, Judge Williams denied Cylink's motion from the bench and later issued a written order explaining that "several factors weigh against finding that (Cylink) has shown a likelihood of success on the merits." In denying the motion the court found that "RSA has raised serious question (sic) regarding the validity of the first of the Stanford patents, the Diffie-Hellman patent." With respect to Cylink's other patent, the Hellman-Merkle patent, the court had this to say: "(I)t is questionable whether the patent warrants such broad coverage." Thus, Cylink has "failed to demonstrate a likelihood of success on the merits." RSA had initiated the lawsuit against CKC, a wholly owned subsidiary of Cylink, because CKC was threatening RSA's customers in an effort to induce them to purchase sublicenses to the Stanford patents. RSA's action seeks a court determination that the patents are invalid, not infringed and/or RSA's licensing does not exceed its existing rights under the patents. Cylink/CKC responded by filing its motion for preliminary injunction which was denied by the court as described above. In a related matter, the arbitration panel which is handling the winding up and dissolution of Public Key Partners ("PKP"), the entity that formerly held the licensing rights to the MIT and Stanford patents, ruled that: "In addition to the claims discussed above and in our prior rulings, Cylink presented the claim, but did not prove, that RSA breached its fiduciary duty to PKP by providing patent licenses to third parties." The arbitration panel also found that PKP was obligated to reimburse RSA for the costs and attorney's fees incurred in other related litigation, including a patent lawsuit brought by Cylink to invalidate the MIT patent. "The court confirmed that RSA has existing rights to the Stanford patents, and although Cylink knew this, it has forced RSA to investigate. In that process, we have found a number of disturbing facts about the Stanford patents," said Jim Bidzos, president of RSA. He went on to add: "Cylink's losing its motion is likely only a surprise to Cylink who thinks they can achieve through the courts what they haven't been able to accomplish in the marketplace."

3 2

Re: Vexatious Litigants (was: SurfWatch)
by Henry Huang 17 Dec '03

17 Dec '03

On Mar 7, 22:29, Timothy C. May wrote: > At 2:38 AM 3/8/96, Bill Frantz wrote: > >At 6:59 PM 3/7/96 -0800, Timothy C. May wrote: > >>If SurfWatch can be sued for a "bad review," then Siskel and Ebert had > >>better find a new line of work. > > > >As long as a reviewer corrects errors, as SurfWatch seems to be willing to > >do, I think they are relativly suit-proof. If they don't, well - anyone > >can be sued for anything. I'll let the lawyers comment on the possibility > >of success. > > My point was that "opinions" (such as movie reviews) are not "tortable" > (don't know the legal name), unless specific inaccuracies can be > demonstrated, and even then it is hard. Siskel and Ebert have undoubtedly > destroyed the box office prospects of many a movie with their "thumbs down" > diss of death, but I know of no successful (or even adjudicated) lawsuits > on this basis. Thanks for the clarification. However, this line of argument applies only to "third-party" ratings systems. Right now, Microsoft/RSAC/SurfWatch and SafeSurf/Cybersitter/etc. are setting up competing standards which would essentially force people to "self-rate" their own sites, or else be blocked out by browsers configured to reject unrated sites (a feature Microsoft plans to add to its Internet Explorer). The question I have is if these systems were widely implemented, could an Web page author or provider of content be sued for "mislabeling" their page? If so, under what circumstances? Could the RSAC attach legal requirements to the use of their system, and open up such a loophole (similar to how Sun attaches conditions to the use of its "Java" logo)? If it's possible, the implications of this are pretty dire. The RSAC itself reports that many retailers refuse to stock software that's not labeled according to their standards. If Web sites were similarly coerced into not only labeling their pages, but abiding by any arbitrary conditions attached to *use* of those standards, things could get pretty ugly. Hell, who needs the Gov't when industry can censor more efficiently? -H

1 0

Can you say "market opportunity"?
by rah＠shipwright.com 17 Dec '03

17 Dec '03

I knew you could... Cheers, Bob --- begin forwarded text Comments: Authenticated sender is <bigmac(a)digicash.com> From: "Marcel van der Peijl" <bigmac(a)digicash.com> Organization: DigiCash bv To: ecash(a)digicash.com Date: Fri, 8 Mar 1996 16:09:26 +0100 Subject: MT ecash censoring? Priority: normal Sender: owner-ecash(a)digicash.com Precedence: bulk I would like to state here that the policy of Mark Twain Bank on what merchants can or can not sell with ecash is NOT the official policy of DigiCash. We can not and do not force our banking licensees any restrictions on the kind of material they sell. On the other hand, we can also not forbid them to put restrictions on that. There are laws that require MT to comply with local (St. Louis MO USA) regulations even when things being sold are acceptible in both the merchant's and the buyer's country. I don't know for sure if this is relevant in this specific case, and I would also like to hear a comment from Mark Twain at this moment. We do not know their exact policy. // Marcel van der Peijl, DigiCash bv, http://www.digicash.com/~bigmac/ // "Sacred cows make the best hamburger." -- Mark Twain --- end forwarded text ----------------- Robert Hettinga (rah(a)shipwright.com) e$, 44 Farquhar Street, Boston, MA 02131 USA "Reality is not optional." --Thomas Sowell The e$ Home Page: http://thumper.vmeng.com/pub/rah/

1 0

question re. PGP CharSet
by max.muzi＠altair.it 17 Dec '03

17 Dec '03

Apparently, the mechanism for overriding PGP configuration settings by means of command-line arguments does not work properly with the option "charset" (at least with version 2.6.1i). Anyone know why? Actually, PGP does understand the option "+charset", as it does not yield an "invalid argument" error message, but it looks like it does not take that option into consideration. While I know most people need not switch from one charset to another every day, some of them (like me) do not have completely migrated to Windows yet and would still like to use the MS-DOS standard charset (cp850) from time to time without having to re-edit or substituting the PGP config file each time. But I guess it's not possible, is it? Thanks, Max PS: [off-topic] Anybody know how one can have the MS-DOS keyboard driver use the standard Windows char table (LATIN1 aka iso-8859-1)? ~~ Massimiliano Muzi ['mu:tsi] <max.muzi(a)altair.it> http://www.geocities.com/Athens/2027/max-muzi.html PGP public key available on keyservers. "Eternal nothingness is OK if you are dressed for it" msg date/time: Friday 8 March 1996, 12:38 GMT+1

1 0

Re: Web of Trust vs other models
by Hal 17 Dec '03

17 Dec '03

From: Bill Stewart <stewarts(a)ix.netcom.com> > > Meanwhile, Don Kitchen at one point collected all the data off the > MIT keyserver for analysis, which is a much different problem than > random signatures. I found that the chain from some middle point, > such as Phil Zimmermann's or Derek Atkins's key was about 12-14 levels > deep, averaging about 6, which compares interestingly with the > default PGP depth limit of4. From my key, it was pretty deep, > especially since my certification from Phil Karn was from one of > his older keys, which is why I asked Derek to sign my key... Let's not forget that the web of trust only works if you personally know and trust the next-to-last person in the chain (the one who signed the key you are interested in). Chain length doesn't matter if you've never heard of the last signer. Hal

1 0

steganographic trick
by Vladimir Z. Nuri 17 Dec '03

17 Dec '03

here is an interesting trick/algorithm that I've not seen before, although I admit I'm not intimately familiar with all the crypto formulas that others here may be aware of, so this may have been toyed with before. in pondering steganography, it seems to me there could be made a distinction between two types. in the "classic" type, say hiding data in the low bits of a digitized image, the whole existence of an encrypted "covert" message is totally concealed. that is, not only is the message concealed but the existence of it is as well. now consider a different kind of steganography, in which it is clear there is an encrypted piece of data. the problem with all steganographic crypto is that to use your data, you have to have your stego tools handy, and the "feds" could see these tools and accuse you of hiding data. imagine an application where you freely admit that you have your cryptographic tools, and that you are even willing to tell the "feds" the key for your data. they run the crypto program, and indeed the file decrypts. however, unknown to them, you have given them a key that decrypts the file into something meaningful yet benign, such as a cookie recipe, not your plans for the overthrow of the state. in other words, "interlaced" or "coincident" within the same file is your secret data. given one key, it decrypts into one set of data, and given another key, it decrypts into another set of data. there are probably many different ways to do this. of course the distinction of what I am proposing and two different files, each with different keys (which is already feasible), is not all that crisp. anyway, I pursued this anyway to come up with an algorithm. pick a large prime, P. now pick two other large primes that are less than sqrt(P), P1, P2 (actually all that is required is that P1*P2 < P). the data in the file is organized into blocks of information modulo P. P1 is the "harmless" key for message 1 (M1), and P2 is the "real" key for message 2 (M2). now the trick is to put data into your file one "piece" at a time such that it decrypts into either the corresponding "piece" of M1 given decryption by P1, or M2 given P2. I think some people can anticipate what comes next: the encoding of the data for M1 is contained in the "segment M" modulo P1, and M2 is contained modulo P2. the chinese remainder theorem lets us find the unique number N such that N mod P1 = M1, and N mod P2 = M2. "N" is the data that is stored in the file. I'm being a little sloppy in notation here: the overall message is broken into segments mod P-- the above algorithm is simply repeated over each "segment". given all the caveats about complexity of factoring etc., if P1, P2 are large and not "close" to each other (i.e. one could find P1 by searching in the "vicinity" of P2), this would be a secure algorithm as far as I can tell. to decrypt, the file is broken up into pieces mod P, and then each of these pieces has a value mod P1 or mod P2 that is used as the value of that piece. hence, we have an algorithm in which data is stored "coincident" or "adjacent" in a file. the feds could potentially observe that the key you give them, P1 < sqrt(P), and realize that there is "room" left over to store a secret message. but if you store all your files that way, they have nothing to go on. in fact you could assert, "yes, that was once a file with two messages in it, but I deleted the other one. it's key used to be Px". Px is a random number. of course, this method could be expanded so that any file has any number of secret pieces interspersed in it, each only available given knowledge of its secret key. again, the same thing can be accomplished by concatenating multiple files, each with a different key, or even alternating bytes or bits in a file, but I thought it would be interesting to find something that had this "coincident" or "adjacent" property based on the modulo and large prime properties used everywhere in modern crypto.

2 1

Re: Leahy bill nightmare scenario?
by Dan Weinstein 17 Dec '03

17 Dec '03

On 8 Mar 96 at 9:24, you wrote: > -----BEGIN PGP SIGNED MESSAGE----- > > At 06:14 AM 3/8/96 GMT, Dan Weinstein wrote: > >On Wed, 06 Mar 1996 16:59:36 -0800, you wrote: > > > >>At that point, Bob is GUILTY of violation of the Leahy bill, > >>because his encrypted anonymous remailer: > >> > >>1. Uses encryption to thwart message tracing, and thus the > >>"criminal investigation." > >> > >>2. Bob has already been informed that his system will be used for > >>illegal purposes; the cops have the messages to prove he has been > >>told. He's GUILTY GUILTY GUILTY, he will definitely lose the > >>system and possibly whatever residence it runs in, and will > >>probably have to pay a huge fine to boot. > > > >This is not my understanding. I believe that Bob has to be > >commiting a felony himself before they can get him under the > >current phrasing. > > Well, first, the section's phrasing is screwed up. Whether this is > the fault of VTW, who posted the text, or the original bill I do not > know. I have yet to see the original bill myself, it is not posted on Thomas yet, but I too have ready the VTW version. > Second, if what they're charging is the hindrance of an > felony investigation, it isn't clear to me why they would be > limiting the charging of that "crime" to only those actually who > have committed a felony. (logic isn't the normal mode of thought for > a government employee, you realize.) I agree with your concerns here, but I find it hard to believe that the courts would allow a broader interpretation. > Third, all they have to do is to "suspect" the person of a felony, > and a > "felony investigation" starts. That would presumably make him > guilty of the Leahy bill's provision, regardless of whether he is > actually participating in the crime supposedly being investigated. Here you are dead wrong, the bill specifically states: "in furtherance of a felony." Its like those laws that let them charge someone with murder in the first if someone dies while you are commiting another felony. They must prove the original felony before they can get you on the murder one. The real purpose of this provision, as I read it, is to give longer sentences to criminals that use crypto. > Fourth, I gave what I considered to be a clear example of the > hypothetical misuse of an encrypted remailer by the cops, one that > would arguably make the remailer operator guilty of some > "reasonable" anti-kiddie-porn statute. At that point, _he_is_ the > target of the investigation. Unless you can show that this kind of > action by the government is impossible, I consider it to be not > merely possible but almost certain to occur. Again, the problem I see with your scenario is that I don't believe that the courts will interpret it that way. My interpretation is that if they serve a warrent and I don't decrypt for them and they can prove a felony, then I will be subject to the listed punishment. > Fifth, it isn't clear what amount of knowledge is necessary to > "trigger" this clause, especially in its current flawed state. > Since ISP's and encrypted remailers might know, in general, that > their systems can and probably are being used for SOME criminal > activity, even if they can't identify it or the user, or decrypt it, > etc, a broad interpretation of the resulting law could easily > de-facto prohibit any business practices (i.e., allowing users to > use encryption) that prevents full-scale monitoring and/or tracing. I disagree, it states you must "willfully endeavor" to use the encryption as a means of obstructing the investigation. To me, this means that it is the motivation for using the encryption. If I set up an encrypting remailer for the purpose of allowing free exchange of ideas, I don't believe I would be liable under this law. The only way I could see a remailer charged under this is if he had solid evidence that a specific user was violating the law, and took no action. > This is only the beginning of the problems with this section. If > you can explain why nothing I've described could possibly occur, I > welcome a contrary explanation. I see some real problems too, but I do not see the problems with this provision to be enough to condemn the entire bill. I would like to see this portion of the bill ammended to make it clear that only those actually involved in commiting the felony would be held responsible. > But I would also ask this: Why, exactly, do we need this section? > We've already been told that the opponents of this bill will fight > it tooth-and-nail under its current wording; if that's the case then > the presence of this section is inadequate to appease their > unhappiness. Therefore, we shouldn't include it in the bill at all; > it does no good. > > Any explanations, Dan? You are talking about the fringe, this, I think, was added as an attempt to bring in those that are in the middle. That is, Those that see the need to prevent the use of encryption as a means of obstructing justice, but feel that we should also have a right to privacy. To say that there is no delema here is ridiculous, crime is a serious problem that we are already having a terrible time dealing with. I think Leahy realizes that this provision will be about as useful as the "use a gun, go to jail" laws, but wants to give those in the middle to say that they bill will help prevent crime. > BTW, I'm not the source of those recent anonymous notes on > Cypherpunks criticizing you for the support of this bill. As you by > now have guessed, I'm not at all reticent about standing up and > being counted and identified. > > Jim Bell > jimbell(a)pacifier.com > > Klaatu Burada Nikto Good movie. Dan Weinstein djw(a)vplus.com http://www.vplus.com/~djw PGP public key is available from my Home Page. All opinions expressed above are mine. "I understand by 'freedom of Spirit' something quite definite - the unconditional will to say No, where it is dangerous to say No. Friedrich Nietzsche

1 0

Re: TCP/IP Stego (was CU-SeeMe)
by mccoy＠communities.com 17 Dec '03

17 Dec '03

JonWeinke(a)aol.com writes: > >> -It can be applied by two routers which are in the middle >> of the connection. [...] > >You seem to be oblivious to the fact that this technique is only useful for >ISP's, corporate networks, etc. that the average home computer user will >never have access to. I know that, I was just pointing out advantages you overlooked. I guess that the fact that I probably know more ISP operators and techs then non-geeks who use the net made this part more obvious to me. The original technique of doing stego on packets is still valid, and by adding it in to a WinSock lib or linux tcp/ip implementation the user can send hidden messages just by connecting to a friendly stego-enhanced web server out on the net and doing some casual browsing. The difference between the two methods is, as I said before, exactly the same as the difference between TCP/IP and UUCP. Hiding info in images or sound files works fine for "email" or file storage but has no chance of being an interactive protocol, sometimes you need to get things done in real-time. > If I want to send a WAV file of my 2 year old son >saying "Hi, gramma" (or a 24-bit color TIFF of him practicing nose-picking >techniques) to my relatives, that is not overtly suspicious behavior, even if >it has a slight amount of background noise (or graininess). But your relatives are not the people who you need to communicate secrets with securely. These gross stego hacks to sound and image files are best used to make postings to various binary Usenet newsgroups. Broadcast the message and then put it in a place where many people will download it but only a few will know that it contains the hidden info. Sending this stuff via email is just begging for traffic analysis at the very least... >As long as I >don't stego too many bits in the file, and I strip out any overt "I'm crypto" >headers, it will be impossible to prove that stego techniques were used on a >file. Finding random bits where random bits normally live cannot be used to >prove anything. Provided the bits are random in the way that they should be... The low-order bits in such files were chosen by implementors of stego programs because modification would not be noticed by the person viewing or listening to the file, not necessarily because there was actually randomness at this level which could be replaced. Does anyone know of a survey of images or sound files which tested the statistical randomness of these bits? They may not be as random as people think they are. jim

1 0