December 2003 - cypherpunks-legacy

The Anti-Briefing...
by pcw＠access.digex.net 17 Dec '03

17 Dec '03

I'm sure the "Briefing" is quite impressive and it includes several strong arguments for government surveillance. There are bound to be more than a few kids that are alive today thanks to eavesdropping and the quick thinking of folks in FBI, NSA et al. That being said, I'm sure that there is also an "anti-Briefing" that can be given that illustrates that the huge cost of redesigning the phone system and forcing businesses and people to operate without protection. Here are some examples from the recent press that I think are good arguments for why strong crypto won't change the status quo. 1) A recent video tape on the news showed some convicted bad guy doing drugs and having sex with one of his convict buddies. They just happened to be in a side room of the prison that had a video camera. Some people tried to make political hay by saying that the prisons were really coddling the prisons too much. But prisons already have all of the enforcement tools that the police wish they had. They can strip search people without a warrant. They can read all of their mail and listen in to all conversations with visitors who aren't their lawyer. But there are still drugs in the prison. So how do they expect to eradicate drugs in the real world? 2) There are persistent rumors that Tim McVeigh et al were under some sort of surveillance. I know of no facts to back this up. I've heard some people say that they feel it was part of a sting operation that failed because the bomb actually went off. Who knows? But the World Trade Center bombers were under surveillance and that failed. This doesn't show that surveillance is bad, it just shows that it isn't perfect. 3) Pachinko machines and cell phones have both used weak crypto. Whoops. The gangsters figured out how to break the crippled system. There must more examples but I'm typing from memory. The point is that full surveillance rarely stops crime altogether, but it may make a dent. The question is whether it is worth redesigning our phone system and computer networks to introduce even more weakness just because the police can use this weakness. Some might argue that if weak crypto can save one child's life than it is worth it. This is a strong, sentimental argument, but it really doesn't reflect the reality of the tradeoff. We could spend a lot more money on airlines, trains and cars and save a few kids lives, but the cost could be phenomenal. The fact is that government enforced weak crypto is a tradeoff. We pay for the ease of the police surveillance because we make life simpler for crooks who make their living eavesdropping and circumventing security systems. The big question is whether the tradeoff is worth it.

2 1

Re: Mixmaster version usable with POP?
by loki＠infonex.com 17 Dec '03

17 Dec '03

At 5:22 PM 5/25/96, E. ALLEN SMITH wrote: > One application of an anonymous remailer that has come up is using POP >to get into an account via which remailing could be done without the remailer >having to run on the machine receiving/sending the mail. It would instead occur >on a machine running the remailer software and equipped for doing POP. Has >anyone written a mixmaster version (or additions onto Mixmaster) that will do >this automatically? > While having the entire remailer with logs and private key in a >different country would still be best, if an anonymous POP account were used >this would still shield the remailer operator from forced disclosure. It would >also cut down on the costs; for instance, offshore.com.ai's monthly price for >a UNIX shell account is 50$ a month, but theirs for an email-only account is >20$ a month (albeit with only 20 M/month of mail). > Thanks, > -Allen While there is not an "out of the box" version of Mixmaster like this, it would be easy to do. The UNIX POP clients I have seen just dump the mail into a mbox formated file. A simple script could be written to yank out the messages one at a time, and feed them to Mixmaster (or mail-in or whatever). In fact, the more recent versions of Mixmaster should be able to swallow the file whole, pulling out the mixmaster messages itself. This modification was made to support "subway" remailers, which want to send a fixed number of messages (in one email) each time period. -Lance ---------------------------------------------------------- Lance Cottrell loki(a)obscura.com PGP 2.6 key available by finger or server. Mixmaster, the next generation remailer, is now available! http://www.obscura.com/~loki/Welcome.html or FTP to obscura.com "Love is a snowmobile racing across the tundra. Suddenly it flips over, pinning you underneath. At night the ice weasels come." --Nietzsche ----------------------------------------------------------

2 1

Re: Children's Privacy Act
by Bruce Baugh 17 Dec '03

17 Dec '03

At 11:34 PM 5/24/96 -0700, tcmay(a)got.net (Timothy C. May) wrote: >If I have compiled records, dossiers, etc., as I most assuredly have (got >to fill up those MO disks with something), this is "my" information. Mine >in the sense that others can't dictate to me what I do with it. I don't see that this is necessarily true for information any more than it is property. Property can be bought, sold, traded, given away, made...but it can also be stolen. Just as I have a right to complain if you walk off with my couch without my permission, so if you walk off with data on my blood chemistry or credit history without my permission. -- Bruce Baugh bruce(a)aracnet.com http://www.aracnet.com/~bruce

2 1

Software Fame and Fortune
by jya＠pipeline.com 17 Dec '03

17 Dec '03

The EcoMist of May 25 has a special survey (80 kb) of the global software industry, which, the report claims, is the next fountainhead of computer fame and fortune, thanks to the Internet, and the successor to the H/W fairy tales. It barely mentions crypto -- described as a prime commercial product of Israel's defense industry and the key to secure fame and fortune! It can be read-only at: http://pwp.usa.pipeline.com/~jya/software.txt

3 2

Re: Layman's explanation for limits on escrowed encryption ...
by E. ALLEN SMITH 17 Dec '03

17 Dec '03

From: IN%"unicorn(a)schloss.li" "Black Unicorn" 24-MAY-1996 15:07:57.78 >On Wed, 22 May 1996, Ernest Hua wrote: >> Could someone with some knowledge of NSA/DoS/FBI intentions please >> explain why key length limitations are necessary for escrowed >> encryption? >To deal with the possibility that someone might slip through the cracks of >the escrow process. >Insurance. Hmm.... what were the normal key-length recommendations again? This appears to imply that the NSA can break at least 64-bit, and probably 80-bit, encryption. How does this translate into public key lengths? E.g., how many normal bits is a 1024-bit PGP key equivalent to? -Allen

3 3

Re: Runtime info flow in Java
by norm＠netcom.com 17 Dec '03

17 Dec '03

At 9:09 AM 5/24/96, Lucky Green wrote: .... >I walked away from your presentation of KeyKOS with the impression that a >capability system to be secure it would have to be implemented at the OS >level. >Can you build a such a system on top of an insecure OS, as Java would have >to do? .... I agree with everything that Bill Frantz said. I certainly didn't mean to imply that a system such as Java could not be secure. I can't think about a whole system at once. We developed KeyKOS over a span of several years and we were able to convince the NCSC it had a firm security foundation. The NCSC convinced us to do some formal descriptions of our system to articulate some of our previously undescribed programming patterns. These said in a somewhat mathematical way how capabilities work. (Like you can't do something to zot unless you have a capability to zot. etc.) Object references in C++ and Java pretty much conform to these capability patterns. In Java you can get an object reference only when you create the object or some one passes it to you (or you get it thru a shared variable). In C++ you can also get an object reference by casting and other chicanery. None of these formalities seemed the least bit surprising. There was no deep mathematical insight here. It was merely restating the familiar in very different terms. The exercise did lead us over some old territory with new eyes and we saw some easily eliminated covert channels that we had been unaware of. We do not have a complete map between capabilities and Java. There are things about Java that we have not mapped to capabilities yet. For instance any piece of code in a Java program that can declare a reference to an object of classs Zot is also able to invoke any of the public constructors for Zot. This may be too strong an ability. (In KeyKos you could create a zot just in case you held the capability to the zot creator.) Perhaps you put all of the constructing code in static methods for Zot and make all constructors private. It is important that some code be able to construct Zot instances that other code is unable to construct. Java's security manager classes are not capability like. They seem to us too much like merely a series of plausible decisions for which we can see no general principles. Each decision makes sense but we have no feeling that they are complete. I suppose that the above sounds as if I am saying "Trust us. We know all about security.". Unless the end user is able to understand just what the lattitude that the applets in his machine have, he has no security. Java will not be secure until the security principles can be understood by the intelligent end-user. I think that you must make graphically explicit which agents in the computer have access to the phone. You may be keeping secrets because untrusted agents can't phone home, or because they can't see the secrets. Current user interface design is predicated on the idea that such issues should not concern the end user. I dearly wish that when some application in my Mac complains that it can't get the phone, there were a way for me to find out who was using the phone and take it away from him. I would also like to easily deny applications access to the phone. Even more I would like to explicitly grant phone access to an application just as I must plug my modem into the phone line before it can transmit bits from my house. In such a system I could begin to reason about where the secrets were going or why things didn't work. Access to the phone should be via a capability. The same goes for TCP connections, the ability to send a user data gram to a given IP address. Access to a random stream of bits should be via a capability. Access to a particular file or directory should be a capability. etc. etc. Everything should be a capability!!!

2 1

Re: Java Crypto API questions
by shamrock＠netcom.com 17 Dec '03

17 Dec '03

At 8:15 5/31/96, Moltar Ramone wrote: >My guess would be that the first of these two points answers the second. >Everything is exportable -- except signed third-party security packages. >My bet would be that the exportable code would not be more than RC4-40 or >perhaps 1DES, but that a signed package would go to RC4-128, 3DES, and >RSA-1024. However, the signature on that package would be on the >condition that the vendor/distributor of that package follow all export >regulations. Where does this leave foreign vendors? Will Sun sign the 3DES package of a foreign vendor? Disclaimer: My opinions are my own, not those of my employer. -- Lucky Green <mailto:shamrock@netcom.com> PGP encrypted mail preferred.

5 4

The Full NRC Crypto Report
by jya＠pipeline.com 17 Dec '03

17 Dec '03

We got a copy of the full 434-page NRC report today at the D.C. public meeting, headed noted "May 30, 1996, Prepublication Copy subject to Further Editorial Correction." We are now scanning it and would be interested to know if anyone else is doing so we don't duplicate the task. The full report consists of 32 pages of intro, 276 pages of main text in 8 parts, and 126 pages of 14 appendices. We note that the CSTB Web version of the Overview does not include the Contents of the full report as did the printed Overview available at the meeting. We will post the Contents here shortly to give a taste. And later give a Web site for the Thing. BTW, there was a press briefing on the report at 11:00 AM, so stories may be in the works.

1 0

unsubscibe
by Cyber9090＠aol.com 17 Dec '03

17 Dec '03

unsubscibe cypherpunks cyber9090(a)aol.com

1 0

unsubscibe
by Cyber9090＠aol.com 17 Dec '03

17 Dec '03

unsubscibe cyberpunks cyber9090(a)aol.com

1 0