December 2003 - cypherpunks-legacy

Re: subpoenas of personal papers
by Ron Davis 17 Dec '03

17 Dec '03

>I just saw a news story that bears on one of the perpetual questions on >this newsgroup: can you be compelled to turn over your encryption >key? In Doe vs. U.S. (93-523), the Supreme Court declined to rule on >whether or not someone can be forced to turn over his personal >appointment calendar. By doing so, they let stand an Appeals Court >(2nd Circuit) that he could *not* invoke the Fifth Amendment. That >court ruled that ``testimony'' was protected, but not personal papers. >There was a Supreme Court ruling in 1886 protecting such papers, but >that's been eroded over the years, and the Supreme Court has ruled >several times that business records are not protected. And in a >concurring opinion in 1986, O'Connor wrote ``The Fifth Amendment >provides absolutely no protection for the contents of private papers of >any kind''. Being a relative newbie to cypherpunks I realize I'm posting at my own risk... It is my understanding that you can be compelled to at least provide decrypted information. In other words the court can say, "We want your PGP e-mail, deliever it to us in an unencrypted form." A question may be how they could prove you didn't alter the information while decrypting. This could be acomplished by supervising you while you decrypted the info, with attorneys for both parties present. Of course an attorney could still argue you could change it and want the court to do the actual decryption, therefore demanding you turn over your key. ___________________________________________________________________________ "I want to know God's thoughts...the rest are details." -- Albert Einstein _________________________________________ Ron Davis rondavis(a)datawatch.com Datawatch, Research Triangle Park, NC (919)549-0711

1 0

REMAIL: Cover traffic
by Hal 17 Dec '03

17 Dec '03

Several people have suggested that the remailers could send bogus messages amongst themselves in order to allow more "confusion and diffusion" of the other messages passing through the remailer network. The remailers could then batch up incoming messages fairly frequently and still have many messages in a batch. The problem with this that I see is that, looking at the remailer network as a whole, you still may have one message in and one message out a short while later. The fact that it was temporarily mixed up with a bunch of other messages doesn't help much if this message is the only one to leave the network. If the Opponent has the ability to monitor all traffic into and out of all nodes of the network (as he would have to do anyway to defeat remailers even without this cover traffic) then he will easily be able to find the messages which are not aimed at other remailers. For cover traffic to be useful, it would have to be indistinguishable from real traffic as it enters and leaves the network. So messages aimed at known "bit bucket" addresses, or at a few cooperating individuals who accept and discard incoming addresses (the same thing, really) will not help. Hal

2 1

archiving on inet
by Jim choate 17 Dec '03

17 Dec '03

I want to thank everyone for their input on this topic, very enlightening... Seems to me that if a work is by simply being created has a copyright on it then every inet provider who stores material a hard drive could be prosecuted for copyright infringement. There has been some question raised as to why this is important to cpunks, it goes like this. If we are going to creat a workable system then some form of release has to be done so that work that goes over inet is public unless explicity noted as copyrighted and must include a fair use statement OR it must be in a form that prohibits casual access. What this last point means to me is that if it is copyrighted it should be encrypted. This encryptred file would have a address and public key attacked. To unlock the file you would contact the author and fulfill their requirements for fair use (ie pay money for a book). The author would then send a private key to the user who coul then unlock the file and use it. Anyone who had possession of a unlocked file without a private key and being on the authors list of authorized users would be committing a clear case of theft. Anyone who gave a third party a valid private key would be committing conspiracy. At this point I expect my home node to come online in a couple of weeks (we may have finaly solved the bugs that kept us down) and should start allowing public access a week or so after that. Each user who calls my system will need agree to a statement of something like the following: I, (username), agree that any material which I create on this system or one of its satellite systems is public domain. I also agree that this statement is binding to my physical person and not to a particular handle or name that I may choose to use or change. I further agree that any material of commercial or of a copyrighted nature MUST contain a fair use policy that prohibits ONLY commercial use AND will contain a real address by which any person may contact me for further interaction. I further agree that any file which is of a commercial or copyrighted nature and does not fulfill the above conditions MUST be encrypted and contain in plain-text a address whereby a person may contact me for access the un-encrypted material. I further agree that as long a the file is encrypted OR contains a fair use statement I wiwll not bring any legal proceeding against ANY provider or user in Internet or other electronic system this material may be transfered to for storage. Does anyone see any problems with such a proviso?

3 3

Re: REMAIL: Cover traffic
by jim＠bilbo.suite.com 17 Dec '03

17 Dec '03

There's a subtle difference between the "send bogus messages thru random set of remailers back to yourself" protocol versus the "round-robin send bogus message to remailer peers" protocol. I don't know if it matters, but it's worth pointing out. In a simple round-robin protocol, bogus messages won't be contained within nested digital envelopes. When a remailer receives a bogus message from one of its peers, it will unwrap the outermost digital envelope, and, walla, a bogus message. You could modify the round-robin protocol to create more complex, multi-hop bogus messages (first hop is the next remailer peer, all other hops randomly chosen), but then your basically back to the first protocol. Is it important that your remailer peers know when you send them bogus messages? I suppose it depends on how many of your remailer peers are really operated by the Bad Guys. <shrug> Jim_Miller(a)suite.com

1 0

Did NSA know about Public Key before Diffie and Hellman did?
by tcmay＠netcom.com 17 Dec '03

17 Dec '03

Did the National Security Agency and its crew of mathematicians know about public key cryptography before Diffie, Hellman, and Merkle made their mid-70s discovery? There have long been rumors that they did, but others say it hit them like a ton of bricks, that is, it surprised them. This question came up again on sci.crypt recently, and I cautiously offered the comments of a "source with deep ties to the public key community." This was Whit Diffe, who told us about this at a Cypherpunks meeting several months back, but I wasn't sure how public the information was or if Whit wanted his name attached to this revelation. In any case, Steve Bellovin, who of course is on this list himself, wrote the attached article for sci.crypt. I think it's pretty interesting and helps to clarify the history of public key crypto, a topic of some interest here on this list. Enjoy! --Tim Newsgroups: sci.crypt From: smb(a)research.att.com (Steven Bellovin) Subject: Re: HELP! National Security Decision Directive 145 Message-ID: <1994Jan15.192102.26379(a)ulysses.att.com> Date: Sat, 15 Jan 1994 19:21:02 GMT Distribution: usa Organization: AT&T Bell Laboratories In article <tcmayCJKzyn.CDt(a)netcom.com>, tcmay(a)netcom.com (Timothy C. May) writes: > Lucien Van Elsen (lucien(a)watson.ibm.com) wrote: > : >>>>> Matt Blaze writes: > : > I recently got a copy of NSAM #160, dealing with requirements for > : > permissive action links on weapons systems, just by asking the JFK library > : > to initiate a declassification review. > > : So, does it shed any light on the rumor that came up at the ACM security > : conference that the NSA (or some other government body) knew about public > : key encrytion back then? > > A source with deep ties to the public key community says that Gus > Simmons, heavily involved in the creation of PALs while at Sandia > until recently, told him that the mid-70s announcement of public key > hit them like a ton of bricks, as something completely unexpected. You don't need to cite anonymous sources; at the Festcolloquium in his honor at the Fairfax conference, Simmons said it publicly. He said that he was on a plane to Australia, to give a talk, when he read the famous Martin Gardener column. He promptly tore up his slides and wrote up a new talk. On the other hand -- when a retiree from NSA alluded to NSAM 160, Simmons was the one who supplied the memo number. Both of them agreed that it was (at the least) the forerunner of public key systems. Did the NSA have PK in the mid-60's? The memo doesn't indicate that, at least in the declassified portions. A device meeting the requirements spelled out in the memo could have been constructed without PK, using hardware available back then. Envision a device with a core memory holding a key, an input line, a set of output lines, and some transistor and/or SSI comparator circuitry, all embedded in epoxy. You get exactly *one* chance to enter the right input value, since core memory uses destructive read-out, and there would be no reason to include writeback circuits. This isn't a design that would have been proof against a sophisticated enemy (let's be precise: against the USSR), but that was not a design goal. It would have stopped random maniacs, deranged weapons officers, and immediate battlefield use by enemy forces -- and those were the threats to be guarded against. I'm quite skeptical that -- with 1963 technology -- a high-reliabilty PK design could have been built. And high reliability was an explicit design goal. Now -- there was a portion of the memo, near the end, that wasn't released. In the context of the memo, that section *could* have spelled out long- term research efforts that would have led to public-key cryptography. And frankly, given the number and caliber of mathematicians who worked for NSA, if the right question was asked I think there's no doubt that they would have found an answer. According to Diffie's paper, it took just two years from the initial conception to when RSA was developed. Would NSA have taken much longer? I doubt it. As for why Simmons didn't know of it -- it does strike me as believable that NSA regarded the technique as too sensitive to use for PALs. After all, I claim that a secure (enough) nuclear command and control system could have been built without PK -- so why discuss it with someone who (to NSA) didn't have ``need to know''. Granted, PK would have strengthened the guarantees -- but security is a matter of engineering against a whole spectrum of risks, and balancing the tradeoffs; there's nothing that says you should favor one threat over others because the solution is sexier. You or I might have made different choices -- but I don't think my scenario is out of the question. --Steve Bellovin -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)netcom.com | anonymous networks, digital pseudonyms, zero 408-688-5409 | knowledge, reputations, information markets, W.A.S.T.E.: Aptos, CA | black markets, collapse of governments. Higher Power:2**859433 | Public Key: PGP and MailSafe available.

1 0

Re: subpoenas of personal papers
by rxt109＠psu.edu 17 Dec '03

17 Dec '03

>I just saw a news story that bears on one of the perpetual questions on >this newsgroup: can you be compelled to turn over your encryption >key? In Doe vs. U.S. (93-523), the Supreme Court declined to rule on Just thought that I'd throw in my somewhat unrelated $.02... Here at Penn State University, a hacker/crakcer/whatever was caught on one of our mainframes back in 89 or 90 and he had some files encrypted with DES on his minidisk. The authorities asked him for the passphrase and told him that if he refused that they'd crack it with a Cray in something like six hours. He ultimately gave in but I wonder if it would have been legal for the authorities to brute force a passphrase on the file...this is relatively unbroken legal ground. Of course, this is DES which was made weak enough to be breakable. PGP is a much different story. -- --**--**-- R X T 1 0 9 @ E M A I L . P S U . E D U --**--**-- Bob Torres Use an electronic envelope... plato(a)phantom.com Support the use of cryptography. PGP public key available..

4 4

Could I possibly be deleted, please...
by Thure 17 Dec '03

17 Dec '03

The volume is far too high for mee. Thanx. / Bjoern

1 0

Mondex Digital Cash System (fwd)
by Stanton McCandlish 17 Dec '03

17 Dec '03

Barlow thought this might be of interest to y'all... Forwarded message:

1 0

Randomness of a bit string
by tcmay＠netcom.com 17 Dec '03

17 Dec '03

Here's a short article I wrote for sci.crypt aboout "randomness" of a bit string and the Kolmogorov-Chaitin definition that a string is random if and only if it has no shorter description than itself. This has some fascinating tie-ins to "cryptoregular" strings, which are strings which appear to be "regular" (a variant of randomness, meaning all digits are equally represented...high entropy) but which, with the right transformation, suddenly lose their regularity. (For you practical engineering folks, noise sources and other physical randomness sources will in most cases be enough, even if the randomness can never be "proved.") --Tim May Newsgroups: sci.crypt From: tcmay(a)netcom.com (Timothy C. May) Subject: Re: Randomness of a bit string Message-ID: <tcmayCK5CtF.23H(a)netcom.com> Date: Mon, 24 Jan 1994 18:32:03 GMT Bruce Grant (bgrant(a)umcc.umcc.umich.edu) wrote: : The usefulness of a one-time pad seems to hinge on whether the sequence : of key bits is really random. Could someone post a short, not too : technical definition of randomness of a bit string? In particular, is : this a mathematical property, or just a general measure of whether the : string is "predictable"? Does it depend on the nature of the cryptanalyst : or only on the string of bits? (In other words, if the key is based on : an Albanian translation of "Mary had a little lamb" is it random if you : don't know Albanian?) : Could a program test a key for randomness, or is this meaningless? A fascinating question! The answer lies at the heart of what we mean by randomness, complexity, predictability, regularity, and falls into the field of Kolmogorov-Chaitin complexity, or algorithmic information theory. Also called "descriptive complexity." Basic definition: A random string has no shorter description than itself. That is, it is incompressible. (Practically, we know "random strings" won't compress much...sometimes a compressor will shorten them, sometimes it will lengthen them. The notion above, that random strings will not compress, is very general and applies in the limit, not for some particular instance of a string--and some particular instance, e.g., "1 0 0 0 1 1 0" will of course have a good chance of having some particular compressions, some short description.) One consequence is "regularity": all digits of a base will be equally represented in the limit. Another consequence, as noted in one of the other followups to this question, is unpredictability of the next element or bit in a sequence. (Predictability of bits would imply a compression.) Cryptography is an interesting situtation. Charles Bennett talks about "cryptoregular" strings in a paper in the "Physics of Computation" Proceedings (1992, IEEE Press). A cryptoregular string _appears_ to have high entropy ("maximum randomness") and regularity (all symbols equally represented), and thus to be "random." But application of the _key_ will show the string is actually low entropy ("Mary had a little lamb, it's fleece was white as snow...") and is very compressible (the name of the song is the compressed version, for example). Good cryptography means cryptoregular strings. A fascinating discovery by Chaitin and others (Kolmogorov, Solomnoff, Martin-Lof, Levin all worked in this area) is that one can never prove a given sequence or string is "random." As in some diabolically clever IQ test, an apparently random sequence may have some shorter description, or compression, that means it does not fit this definition of randomness. Having said this, it is clear that for practical purposes, many sources used to generate "random numbers," e.g., noise diodes, alpha particles, tosses of a coin, etc., are "effectively random" (don't ask me to define this!) in that no compression/prediction will ever be done, though we can never be absolutely certain one does not exist! A nice book on this stuff just came out: "An Introduction to Kolmogorov Complexity and Its Applications," by Li and Vitanyi, 1993, Springer-Verlag. Cryptography per se is not mentioned (a disappointing lapse), but the ideas are widely applicable. --Tim May -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)netcom.com | anonymous networks, digital pseudonyms, zero 408-688-5409 | knowledge, reputations, information markets, W.A.S.T.E.: Aptos, CA | black markets, collapse of governments. Higher Power:2**859433 | Public Key: PGP and MailSafe available.

5 8

Re: Could I possibly be deleted, please...
by lware＠voxel.com 17 Dec '03

17 Dec '03

Please remove me as well . . . Thanks, Lance

1 0