December 2003 - cypherpunks-legacy

Strange Unix behavior dealing with utmp - anyone recognize this?
by fc＠all.net 17 Dec '03

17 Dec '03

I was sending out a few hundred 25K emails over a period of a minute or so when my systemn encountered this thrilling sequence: Dec 7 22:11:56 all vmunix: file:<3>zs1: silo overflow Dec 7 22:11:57 all syslogd: /etc/utmp: File table overflow Dec 7 22:11:56 all vmunix: table is ful<3>zs1: silo overflow It appears to be some sort of file table overflow related to the syslog daemon. The message repeats numerous times and I think it has to do with the number of messages sent over a short time, however: I regularly send far more messages without this error It lost the processes that were generating these messages so I had to redo part of the mailing. Does anyone recognize the symptom, and does this open a potential for attack by stress? (e.g., if you can get something to fail in this way can the failure cause something to be missed?) Just thought I'd mention it. -> See: Info-Sec Heaven at URL http://all.net/ Management Analytics - 216-686-0090 - PO Box 1480, Hudson, OH 44236

1 0

(no subject)
by Nicholas Philp 17 Dec '03

17 Dec '03

WE WANT SOME PUSSY PICTURES

2 1

Re: [FYI] FBI Training Eastern European Police
by Dave Del Torto 17 Dec '03

17 Dec '03

At 8:22 PM 12/6/95, anonymous-remailer(a)shell.portal.com wrote: [elided] >I'm certain that the FBI and other law-enforcement officials might >also learn by living in a city where the East truly meets the West. > >Budapest is a beautiful old city of bridges, not just literally but >figuratively. It's where anyone in the world can find comfort. [much elided] Hey "Alice," This is a very persipicatious set of observations about Budapest, a city I lived/worked in for a while (you sound like you know it rather well yourself). The level of technical CS knowledge in Bp is comparable to, or better than, many other cities (except maybe for Moscow and St. Petersburg) in the former Bloc. Your comments also provide good insights into why it's technically and geographically important to cypherpunks: it's the petri disk for many of our cpunk brethren over there. The fact that the FBI has chosen Bp as one of their entry-points into the region impacts our policy discussions here, particularly since our LE types are making contact with the former secret police in that region, and especially so given the stationing of US Troops in Kaposvar as we type (southern Hungary) for easy entry into Bosnia. Anyone who attended CFP 95 may also remember some of Esther Dyson's lunchtime comments about the Russian mafia (which has a strong presence in Bp) and the growth of crypto's use both by the gangsters and LE officers. Some of the most powerful crypto may be emanating from these regions and it would be wise for us to try and track TLA activities in that area. I won't drag this topic out any further, but if anyone comes across similar info about our various TLAs operations over there, I hope they'll at least share it with me, if not the list. dave PS: I hope Perry's paying attention. ;)

1 0

Anyone Remember socket.c?
by mpd＠netcom.com 17 Dec '03

17 Dec '03

Fellow 'Punks, A while back on the list, someone posted a very short C program called socket.c, which, when given a port number and an excutable, would fork off copies of a given application for anyone who connected to the port. I saved the program at the time, but seem to have deleted it. I realize it would be trivial to write, but don't want to have to look at nasty network #include files. If someone could either post it to the list again, or email me a copy, I will be eternally greatful. -- Mike Duvos $ PGP 2.6 Public Key available $ mpd(a)netcom.com $ via Finger. $

1 0

Java musings
by Adam Shostack 17 Dec '03

17 Dec '03

Some musings on policies, threats and liabilities of Java, Livescript and other downloadable applets. I. Policies. The recent Livescript problem was predictable. Building an execution environment to safely handle all the myriad of tricks that programmers will throw at it is not a simple or easy task. People will make mistakes in the design and execution of these environments. Right now, many people are chasing the idea of applets; its neat, sexy, and everyone wants in. But, for many users, and many environments, certain capabilities may be inappropriate. There has already been loud complaining in many forums about the lack of site configurable Certification authorities, lack of site control over Java features. A site needs to be able to decide who to trust, and who should be able to make these decisions, in a manner that a user can not easily override. The ease of configuration of trust parameters in Netscape is neat for personal use, but inappropriate for business. When Java gets its ability to check signatures, expect complaints about lack of site configuration of trust hierarchies. (Yes, as opposed to web of trust. As a bank, I want to be able to control what code can run with a very explicit hierarchy.) All applets are not created equal. All user requirements are not equal. Applets are not created equal. Some are created in house to do certain things, like watch the price of two stocks relative to one another. If an applet is created in house, signed off on by the InfoSec people, then there's no reason (assuming strong integrity checking) to deny it access to local disk, arbitrary network access, etc. However, for various reasons (notably compartmentalization, aka defense in depth), it is desirable to restrict disk (and possibly network) access to certain addresses. Something akin to chroot(), tagging of packets outside the applications control to make firewall filtering easy, filtering of available addresses to send to (only talk on local subnet). The ability to assign various levels of privilege to code that runs on a virtual machine will be essential. The ability to limit these privileges must be reserved in some way to those with site security responsibilities. The security people, in turn, will need the ability to delegate. This can perhaps be provided based on a least trusted basis. Code starts out in a small, tight environment, with no access to anything other than the (protected) processor, and a promote() function which does authorization checking before granting new levels of privileges in certain areas. Access to disk, access to local and remote network services, and the ability to pull the browser to a new URL are all privileges that should be orthogonally configurable, by site, by machine, or by applet. All user requirements are not equal. This should be obvious. Not all users need Java or Livescript. If a user is using Netscape to look at man pages, access to Java and livescript is not very important. Access to unsigned Java applets may or may not meet the site security policy. At home, I might happily look at them. In the office, I might have a very different approach. A bank teller might need access to applets developed by the bank for various things, but not need access to anything over the internet. He would need to be able to access the local lan servers. The need of users to get to different resources, and work under different levels of protection calls out for mandatory strong authentication in applets. In other words, a better design might be only execute applets with some (verified) signature attached to them. The language in which the applet was written is important. More important is the ability of users and management to set policies, and see those policies enforced by applications. I could then set my browser only to run Livescripts signed by someone I know (or an agency that vets them for bugs), and only run Java with minimal trust in the absence of signatures. II. Threats and liabilities A malicious applet, running amok on a machine, with the same disk & network access as a user, can send off to the world anything it thinks interesting. However, there are times when letting an applet at certain files, or giving it heavy network access, might be very useful. I'll take as an example Anderson Consulting's demo BargainFinder (http://bf.cstar.ac.com/bf/) BargainFinder is a way to search 9 music stores on the web for an album, with one form. 3 of the stores are blocking the searches. In addition, a cypherpunk might wonder if the searches and their origins are being logged. Thats not very useful for those of us who look forward to perfect marketplace information for consumer goods. Let me sketch BargainFinder2, as powered by Java. Instead of going to Anderson for the page, you download BF to your local machine. It does the searching, same as BF1 did, but with no blocking possible. You find your CD at the best price. Perhaps BF is rental-ware, perhaps its someone advertising their Java coding skills. But its clear that this applet needs to be able to access the network freely. Its also plain that it won't be written for 6 platforms. It might be written for Windows, but the Java market might be larger still, and thus more attractive. (Not to mention that the network interface is mostly taken care of. no Winsock version worries.) Other applets, say a Ecash wallet manager that interfaces with Quicken, needs access to your local disk, and needs to be able to respond to incoming network queries from shops. Granular control of the access that applets have thus seems to be needed. Making Java 'secure' is not enough, because people will 'turn off' all the security to make one applet work. It might also be interesting to consider automatically updating software, that can replace itself from time to time, after verifying that a signature is correct. Although, that does raise the value of stealing a key from some well known, trusted applet vendor. To summarize, 'security' in the vauge sense that Java promises, while useful, needs granularity to allow it to fulfill its potential. Comments are welcome. Adam -- "It is seldom that liberty of any kind is lost all at once." -Hume

1 0

GAK solutions was: Is there a lawyer in the house?
by Pat Farrell 17 Dec '03

17 Dec '03

In message Thu, 7 Dec 95 16:27:23 EST, cme(a)acm.org writes: > It could be even worse. I was on a panel last year with Scott Charney > (sp?) (I believe from DoJ) during which he commented that if you give > your secret key to anyone -- e.g., your own company -- then you have > given up the presumption of privacy. Interesting. At the NIST meeting, criteria #5 deals with decrypting a conversation with only the key from one end. I thought that would be hard to implement. But during the discussion, they called on Miles Smid [sp?] who was obviously a NIST employee/consultant with real knowledge. He suggested that you could encrypt the session key with the public key of both parties, and send it along. This would allow single ended GAK. This is not far from the idea that CME proposed that the NSA/FBI/CIA publish public keys, and we'll hack a voluntary version of PGP that encrypts the session key with the LEA public key -- instant voluntary Key Escrow. Miles Smid's idea seemed reasonable, until you realize that he intends you to escrow your private key... Pat Pat Farrell Grad Student http://www.isse.gmu.edu/students/pfarrell Info. Systems & Software Engineering, George Mason University, Fairfax, VA PGP key available on homepage #include <standard.disclaimer>

1 0

Re: Is there a lawyer in the house?
by tcmay＠got.net 17 Dec '03

17 Dec '03

At 2:27 AM 12/8/95, sameer wrote: >> > You mean if you give me your key the police can get it from me without a >> > warrant? What if I don't want to give it up, and you don't? How would the >> > police get it without a warrant? >> >> Yes. Unless it could be shown there their was an expactation of privacy >> in the transfer, or that there was an understanding that you intended this >> to be a confidential matter. Or in the alternative, that the > > I do not understand. > >Alice has Alice gives Bob her key. Cop wants Alice's key. Cop tells >Bob "I want Alice's key, you need to give it to me. I don't have a >warrant." > >How is this different from >Bob has key. Cop want's Bob's key. Cop tells Bob "I want your key, >you need to give it to me. I don't have a warrant." > > > sheesh, what a fucked up legal system. ^^^^^^^^^ EXON WARNING! This message has just exposed the author, the toad.com system, and all those who pass it on to fines of not less than $10,000! But I share Sameer's confusion. If cops show up at my door, they must, it seems to me, present proper warrants before they can _enter_ my premises, or _search_ my premises. Something given to me, whether a letter, a key, a photo, etc., is essentially *my property* and may not simply be taken away from without due process. I hope Black Unicorn is incorrect in his point. --Tim Views here are not the views of my Internet Service Provider or Government. ---------:---------:---------:---------:---------:---------:---------:---- Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)got.net 408-728-0152 | anonymous networks, digital pseudonyms, zero Corralitos, CA | knowledge, reputations, information markets, Higher Power: 2^756839 | black markets, collapse of governments. "National borders are just speed bumps on the information superhighway."

2 1

Re: GAK solutions was: Is there a lawyer in the house?
by Carl Ellison 17 Dec '03

17 Dec '03

[By the way, I know that my sig on that message was bogus. I made the mistake of editing the message after signing it and sent it before I stopped to think.] >Date: Thu, 07 Dec 1995 22:07:00 -0400 (EDT) >From: Pat Farrell <pfarrell(a)netcom.com> >Subject: GAK solutions was: Is there a lawyer in the house? >Interesting. At the NIST meeting, criteria #5 deals with decrypting >a conversation with only the key from one end. > >I thought that would be hard to implement. But during the discussion, >they called on Miles Smid [sp?] who was obviously a NIST employee/consultant >with real knowledge. He suggested that you could encrypt the >session key with the public key of both parties, and send it along. >This would allow single ended GAK. Miles Smid is a NIST employee who is quite knowledgeable about crypto and Clipper. >This is not far from the idea that CME proposed that the NSA/FBI/CIA >publish public keys, and we'll hack a voluntary version of PGP that >encrypts the session key with the LEA public key -- instant >voluntary Key Escrow. I still think that's the only way the gov't will get GAK -- :) - Carl +--------------------------------------------------------------------------+ |Carl M. Ellison cme(a)acm.org http://www.clark.net/pub/cme | |PGP: E0414C79B5AF36750217BC1A57386478 & 61E2DE7FCB9D7984E9C8048BA63221A2 | | ``Officer, officer, arrest that man! He's whistling a dirty song.'' | +---------------------------------------------- Jean Ellison (aka Mother) -+

1 0

Re: GAK solutions was: Is there a lawyer in the house?
by Carl Ellison 17 Dec '03

17 Dec '03

>>This is not far from the idea that CME proposed that the NSA/FBI/CIA >>publish public keys, and we'll hack a voluntary version of PGP that >>encrypts the session key with the LEA public key -- instant >>voluntary Key Escrow. > >I still think that's the only way the gov't will get GAK -- :) Actually, the real proposal (http://www.clark.net/pub/cme/html/no-ke.html) is to have them give me their public keys. I would sign and post them. The world's citizens would then add them to their public keyrings and, when they feel like volunteering GAK, would include these agencies as crypto-recipients -- on a per-message basis. No meetings -- no hassle -- nearly 0 cost -- and the gov't could have GAK tomorrow. - Carl +--------------------------------------------------------------------------+ |Carl M. Ellison cme(a)acm.org http://www.clark.net/pub/cme | |PGP: E0414C79B5AF36750217BC1A57386478 & 61E2DE7FCB9D7984E9C8048BA63221A2 | | ``Officer, officer, arrest that man! He's whistling a dirty song.'' | +---------------------------------------------- Jean Ellison (aka Mother) -+

1 0

Re: PGP
by Adam Hupp 17 Dec '03

17 Dec '03

Sorry...I was always taught that the user should not be mandated to finish the job of the programmer. Please, do not take me wrong, PGP is a remarkable tool...but I was not aware I had iron out the bugs. That part is the easiest to do compared with the genius of the program... but I still should not have to do it. This is not "ironing out bugs". It is configuring the program to run on your version of Unix. -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6 mQBtAzCNppQAAAEDALhWZl7IuGZ9zZT5bACo0b/1L0Nv0C72vKHIO3IHh+cwpHHa 2Ozb9aeO0UvXGwkkZIYgUm0EvmzKh7yb1GTLvBp5kXpR3I9w+Yj4LGlBDERpUWw6 x4ED49pwDnz1Hl5FBQAFEbQYYXNoIDxhaHVwcEBwcmltZW5ldC5jb20+ =PtJK -----END PGP PUBLIC KEY BLOCK-----

1 0