December 2003 - cypherpunks-legacy

Plan 9's auth() function - partialy secure distributed computing
by Jim Choate 17 Dec '03

17 Dec '03

Forwarded message: >From ravage(a)ssz.com Tue Jan 13 17:51:44 1998 Date: Tue, 13 Jan 1998 17:51:42 -0600 From: Jim Choate <ravage(a)ssz.com> Message-Id: <199801132351.RAA29535(a)einstein.ssz.com> X-within-URL: http://plan9.bell-labs.com/magic/man2html/6/auth To: ravage(a)einstein.ssz.com Subject: auth [search] [index] delim $$ define lbr ' roman "{" ' define rbr ' roman "}" ' NAME ticket - authentication service DESCRIPTION This manual page describes the protocols used to authorize connections, confirm the identities of users and machines, and maintain the associated databases. The machine that provides these services is called the authentication server (AS). The AS may be a stand-alone machine or a general-use machine such as a CPU server. The network database ndb(6) holds for each public machine, such as a CPU server or file server, the name of the authentication server that machine uses. Each machine contains three values important to authentication; a 56-bit DES key, a 28-byte authentication ID, and a 48-byte authentication domain name. The ID is a user name and identifies who is currently responsible for the kernel running on that machine. The domain name identifies the machines across which the ID is valid. Together, the ID and domain name identify the owner of a key. When a terminal boots, the user is prompted for user name and password. The user name becomes the terminal's authentication ID. The password is converted using passtokey (see auth(2)) into a 56-bit DES key and saved as the machine's key. The authentication domain is set to the null string. If possible, the terminal validates the key with the AS before saving it. For Internet machines the correct AS to ask is found using bootp(8). For Datakit machines the AS is a system called p9auth on the same Datakit node as the file server the terminal booted from. When a CPU or file server boots, it reads the key, ID, and domain name from non-volatile RAM. This allows servers to reboot without operator intervention. The details of any authentication are mixed with the semantics of the particular service they are authenticating so we describe them one case at a time. The following definitions will be used in the descriptions: $CH sub c$ an 8-byte random challenge from a client $CH sub s$ an 8-byte random challenge from a server $K sub s$ server's key $K sub c$ client's key $K sub n$ a nonce key created for a ticket $K lbr m rbr$ message $m$ encrypted with key $K$ $ID sub s$ server's ID $DN sub s$ server's authentication domain name $ID sub c$ client's ID $UID sub c$ user's name on the client $UID sub s$ user's name on the server A number of constants defined in auth.h are also used: AuthTreq, AuthChal, AuthOK, AuthErr, AuthTs, AuthTc, AuthAs, and AuthAc. File Service File service sessions are long-lived connections between a client host and a file server. Processes belonging to different users share the session. Whenever a user process on the client mounts a file server (see bind(2)), it must authenticate itself. There are four players in an authentication: the server, the client kernel, the user process on the client, and the authentication server. The goal of the authentication protocol is to convince the server that the client may validly speak for the user process. To reduce the number of messages for each authentication, common information is exchanged once at the beginning of the session within a session message (see attach(5)): Client->Server Tsession($CH sub c$) Server->Client Rsession(${CH sub s},~{ID sub s},~{DN sub s}$) Each time a user mounts a file server connection, an attach message is sent identifying/authenticating the user: Client->Server Tattach($K sub s lbr AuthTs, ~ {CH sub s},~{UID sub c}, ~ {UID sub s}, ~ K sub n rbr , ~ {K sub n} lbr AuthAc, ~ {CH sub s}, count rbr )$ Server->Client Rattach($ K sub n lbr AuthAs,~{CH sub c},~count rbr$) The part of the attach request encrypted with $Ksubs$ is called a ticket. Since it is encrypted in the server's secret key, this message is guaranteed to have originated on the AS. The part encrypted with the $K sub n$ found in the ticket is called an authenticator. The authenticator is generated by the client kernel and guarantees that the ticket was not stolen. The count is incremented with each mount to make every authenticator unique, thus foiling replay attacks. The server is itself authenticated by the authenticator it sends as a reply to the attach. Tickets are created by the AS at the request of a user process. The AS contains a database of which $ID sub c$'s may speak for which $UID sub c$'s. If the $ID sub c$ may speak for the $UID sub c$, two tickets are returned. UserProc->AS $AuthTreq, ~ CH sub s , ~ ID sub s , ~ DN sub s , ~ ID sub c , ~ UID sub c$ AS->UserProc $AuthOK, ~ K sub c lbr AuthTc, ~ CH sub s , ~ UID sub c , ~ UID sub s , ~ K sub n rbr , ~ K sub s lbr AuthTs, ~ CH sub s , ~ UID sub c , ~ UID sub s , ~ K sub n rbr$ Otherwise an error message is returned. AS->UserProc $AuthErr$, 64-byte error string The user passes both tickets to the client's kernel using the fauth system call (see fsession(2)). The kernel decrypts the ticket encrypted with $K sub c$. If $UID sub c$ matches the user's login ID, the tickets are remembered for any subsequent attaches by that user of that file server session. Otherwise, the ticket is assumed stolen and an error is returned. Remote Execution A number of applications require a process on one machine to start a process with the same user ID on a server machine. Examples are cpu(1), rx (see con(1)), and exportfs(4). The called process replies to the connection with a ticket request. Server->UserProc $AuthTreq, ~ CH sub s , ~ ID sub s , ~ DN sub s , ~ xxx, ~ xxx$ Here xxx indicates a field whose contents do not matter. The calling process adds its machine's $ID sub c$ and its $UID sub c$ to the request and follows the protocol outlined above to get two tickets from the AS. The process passes the $K sub s$ encrypted ticket plus an authenticator generated by /dev/authenticator from the $K sub c$ ticket to the remote server, which writes them to the kernel to set the user ID (see cons(3)). The server replies with its own authenticator which can be written to the kernel along with the $K sub c$ encrypted ticket to confirm the server's identity (see cons(3)). UserProc->Server $ K sub s lbr AuthTs, ~ CH sub s , ~ UID sub c , ~ UID sub s , ~ K sub n rbr , ~ K sub n lbr AuthAc, ~ CH sub s , ~ 0 rbr $ Server->UserProc $K sub n lbr AuthAs, ~ CH sub s , ~ 0 rbr$ Challenge Box A user may also start a process on a CPU server from a non Plan 9 machine using commands such as con, telnet, or ftp (see con(1) and ftpfs(4)). In these situations, the user can authenticate using a hand-held DES encryptor. The telnet or FTP daemon first sends a ticket request to the authentication server. If the AS has keys for both the $ID sub c$ and $UID sub c$ in the ticket request it returns a challenge as a hexadecimal number. Daemon->AS $AuthChal, ~ CH sub c , ~ ID sub c , ~ DN sub s , ~ ID sub c , ~ UID sub c $ AS->Daemon $AuthOK$, 16-byte ASCII challenge Otherwise, it returns a null-terminated 64-byte error string. AS->Daemon $AuthErr$, 64-byte error string The daemon relays the challenge to the calling program, which displays the challenge on the user's screen. The user encrypts it and types in the result, which is relayed back to the AS. The AS checks it against the expected response and returns either a ticket or an error. Daemon->AS 16-byte ASCII response AS->Daemon $AuthOK, ~ K sub c lbr AuthTs, ~ CH sub c , ~ UID sub c , ~ UID sub c , ~ K sub n rbr$ or AS->Daemon $AuthErr$, 64-byte error string Finally, the daemon passes the ticket to the kernel to set the user ID (see cons(3)). Password Change Any user can change the key stored for him or her on the AS. Once again we start by passing a ticket request to the AS. Only the user ID in the request is meaningful. The AS replies with a single ticket (or an error message) encrypted in the user's personal key. The user encrypts both the old and new keys with the $K sub n$ from the returned ticket and sends that back to the AS. The AS checks the reply for validity and replies with an AuthOK byte or an error message. UserProc->AS $AuthPass, ~ xxx, ~ xxx, ~ xxx, ~ xxx, ~ UID sub c$ AS->UserProc $AuthOK, ~ K sub c lbr AuthTc, ~ xxx, ~ xxx, ~ xxx, ~ K sub n rbr$ UserProc->AS $K sub u lbr AuthPass, ~ roman "old password", ~ roman "new password" rbr$ AS->UserProc $AuthOK$ or AS->UserProc $AuthErr$, 64-byte error string Data Base An ndb(2) database file exists for the authentication server. The attribute types used by the AS are hostid and uid. The value in the hostid is a client host's ID. The values in the uid pairs in the same entry list which users that host ID make speak for. A uid value of * means the host ID may speak for all users. A uid value of !user means the host ID may not speak for user. For example: hostid=bootes uid=!sys uid=!adm uid=* is interpreted as bootes may speak for any user except sys and adm. FILES /lib/ndb/auth database file /lib/ndb/auth.* hash files for /lib/ndb/auth SEE ALSO fsession(2), auth(2), cons(3), attach(5), auth(8) Copyright © 1995 Lucent Technologies. All rights reserved.

1 0

Plan 9 ordering info [rather expensive]
by Jim Choate 17 Dec '03

17 Dec '03

If you're interested in getting Plan 9 in CD format: Harcourt Brace & Co. 800-782-4479 Plan 9 (full distribution on CD w/ source) ISBN 0-03-017143-1 $367.50 + 8% s/h + state tax (8.25% in Tx) Usualy takes 24 hours to setup an account with them. Apparently they don't ship this through retailers. When I called this morning for up to date info the #3 selection for individuals and professional didn't work. Just select the operator option and be done with it. I advised them their VRU didn't work correctly. If you talk to EJ tell her thanks again. If you just want to play then go to plan9.att.com and get the disk set they offer for playing around. It lacks all source but it will install a minimal system on an Intel box. Should work on most systems though I do suggest that you use a SCSI based system. ____________________________________________________________________ | | | Those who make peaceful revolution impossible will make | | violent revolution inevitable. | | | | John F. Kennedy | | | | | | _____ The Armadillo Group | | ,::////;::-. Austin, Tx. USA | | /:'///// ``::>/|/ http://www.ssz.com/ | | .', |||| `/( e\ | | -====~~mm-'`-```-mm --'- Jim Choate | | ravage(a)ssz.com | | 512-451-7087 | |____________________________________________________________________|

1 0

Don't shoot the messenger (Re: 1 Question to Dr. Froomkin...) (fwd)
by Jim Choate 17 Dec '03

17 Dec '03

Forwarded message: > Date: Tue, 13 Jan 1998 18:38:43 GMT > From: Adam Back <aba(a)dcs.ex.ac.uk> > Subject: Don't shoot the messenger (Re: 1 Question to Dr. Froomkin...) > It appears to me that your comments to Michael are based on your views > on the undesirability of the way the US judicial system operates in > practice today. Michael is merely offering his expert opinion on how > various questions would likely be interpreted by the current legal > system. Ok. It's not just the US judicial system, include the executive and legislative branches as well. > Screams of "and you think this is a good idea?" and "but what about > the constitution" are misdirected; I strongly suspect each of the > three posters I mention above share your distaste for the redefinition > of meanings and blatant disregard for the fairly clear meanings of the > constitution. You propose speaking softly will resolve the issue? If so why speak at all since that is the softest speech of all. Your position seems to be that if a question is hard then it should be avoided because it might offend the sensibilities? You propose that justice would be better served if it were all masked in innuendo and euphamism? Perhaps, that is no reason not to take them to task when they expound a position using fallacious arguments. Further, Dr. Froomkin is a law professor who *trains* future lawyers. If anyone should be held to task for their actions and views it is those who are deciding what tomorrows world will look like and the people charged with those decisions. There is a fundamental ethical responsibility for conservatism and literalism in those enterprises that simply isn't present in most other 'jobs'. We aren't playing horseshoes or handgrenades - close enough is not good enough. There is a fundamental difference between Lawyers, Doctors, & Soldiers and the vast majority of other human endeavours. In short, they are given the lattitude to decide events that directly and immediatley impact human life. Engineers, Pilots, hamburger flippers, etc. are seldom in a position as a matter of course of their practicing their vocation to decide whether a person will live or die. Because of this exclusion from commen behavioral limitations they should receive *less* latitude and trust in their actions instead of more (which is what is happening today). Ulitmately, when a lawyer fails in their duty to use *every* legal recourse a person sits in a room and gets to listen to the hiss of cyanide drop into the acid. When these people make a mistake there is no 'fixing' it. Sometimes "I'm sorry" just doesn't cut it. It is entirely too important to be complacent or trust without verification (thanks to Pres. Reagan for that one). The road to hell is paved with good intentions. We'll just have to agree to disagree here. If they take the job they take the responsibility to answer for their actions to any and every citizen that asks for it. However inconvenient, uncomfortable, or rude the question may be posed because the *next* citizen they ask to trust them may be the one asking the question. Never forget that but by the grace of God there go you. If you want to trust your future to somebody who 'shuts down' because somebody says "spin doctor bullshit" or strenously defends their views be my guest. Me, I want a MUCH more mature and determined individual handling me and my decendants future. I want to experience that strength of conviction from them not a yellow streak. ____________________________________________________________________ | | | Those who make peaceful revolution impossible will make | | violent revolution inevitable. | | | | John F. Kennedy | | | | | | _____ The Armadillo Group | | ,::////;::-. Austin, Tx. USA | | /:'///// ``::>/|/ http://www.ssz.com/ | | .', |||| `/( e\ | | -====~~mm-'`-```-mm --'- Jim Choate | | ravage(a)ssz.com | | 512-451-7087 | |____________________________________________________________________|

2 1

British Ministers Adopt Unbreakable Crypto
by Eric Cordian 17 Dec '03

17 Dec '03

The UK is replacing the traditional "red boxes" used by ministers to carry their work home with them with high tech laptops. They will use a signet ring and fingerprints to control access to the computer. There will be a "Duress Finger." :) ----- LONDON (AP) -- It's a briefcase even James Bond could love. Britain's more adventurous Cabinet ministers soon will be spiriting laptop computers inside their signature ``Red Box'' briefcases, complete with fingerprint recognition systems and silent alarms. The stacks of papers, briefing documents and constituency correspondence that now go home with each minister in lead-lined red briefcases will be replaced in a few months by a specially designed super-secure laptop -- capable of carrying infinitely more homework. At $4,000 each, the prototypes unveiled Tuesday are seen as a symbol of the modern Britain so often touted by the Labor Party and are being billed as a way to make government work more efficiently. They will not, however, be foisted on ministers who prefer the old-fashioned paper route -- but those holdouts will miss an electronic voice that chirps ``Good morning, minister'' each time the computer is turned on. Each computer, built into the briefcase, will come with a security system that uses a signet ring and fingerprints to control access to the computer. Ministers who eschew jewelry can have the signet ring's smart-card incorporated into another device, such as a keychain or pen. The fingerprint function also requires an alternate finger to be programmed in case the minister cuts the one designated, thereby corrupting the fingerprint. ``It has certainly been billed as very James Bond-ish and I suppose we are 'Q,' '' said Alan Rushworth, managing director of Rhea International, the company that designed the security system, likening himself to the 007 character who outfits James Bond with all his gadgets. ``There is even a duress finger,'' Rushworth said. ``That is for if a terrorist or gunman has a gun to the minister's head forcing him to open the computer. It will appear to function normally but doesn't, and sends a silent alarm to the Cabinet Office.'' No ``top secret'' documents will be loaded on the computers because such material is seldom transmitted electronically for security reasons, a government spokeswoman said. Even American security experts could not breach the computer's security system, Rushworth boasted. ``The Cabinet office has used its best government hackers for extensive penetration testing and they couldn't break it,'' he said. ``It has also been tried by our cousins on the other side of the Atlantic -- and they couldn't get in either.'' -- Eric Michael Cordian 0+ O:.T:.O:. Mathematical Munitions Division "Do What Thou Wilt Shall Be The Whole Of The Law"

1 0

plan 9 features (Re: autonomous agents (fwd)) (fwd)
by Jim Choate 17 Dec '03

17 Dec '03

Forwarded message: > Date: Wed, 14 Jan 1998 00:33:14 GMT > From: Adam Back <aba(a)dcs.ex.ac.uk> > Subject: plan 9 features (Re: autonomous agents (fwd)) > Sounds interesting. I am not familiar with plan 9 besides the > enthusings of a colleague reminiscing about the work done at York > Univ, UK with plan 9. > > Java has a lot going for it as a candidate due to portability and code > distribution support. I think the only thing missing from java is the > bidding and scheduling mechanisms. Your other forwarded message on > plan 9 looks interesting also. I have been working on a potential distributed data haven model using the Plan 9 architecture. I have finaly amassed enough machines where I can actualy dedicate the i/o, process, and file servers on seperate machines. The problem that I see for the immediate future is getting nodes that don't happen to reside on my premises for additional testing in about a year. I don't have a clue to how to get people to spend $400 bucks for the software (which the ATT license prohibits from commercial use) *and* dedicate several machines to the enterprise. But I'm not going to give up, maybe some folks will volunteer just to do it...:) I took the liberty of forwarding the man page for the auth() function to the cpunks list. It describes the 56-bit DES based authentication mechanism. I personaly don't care for DES so at some point I will be looking to replace that mechanism with an alternative. I also need to take some time and look at porting the Plan 9 file server adapter for Unix to Win95/NT. Either that or I mount the file systems to a suitably enhanced Linux box and then export from there. This would imply that the Win95/NT boxes need to be on the physical network of the Linux box or else excessive opportunities for MITM attacks are present. Not that simply being on the same network provides complete protection either. I hope that OpenNT will provide enough Unix-like features to minimize the port effort. The Plan 9 mechanism also needs to be enhanced in such a way that besides the access token involving encryption the actual transfer of packets are also content encrypted. This has potential compatibility problems with un-enhanced Plan 9 servers that I haven't had a chance to look at. Once I have a system up and running it will allow non-Plan 9 systems to access the resources by using what is called 'hand-held DES encryptors'. Unfortunately, there is not a real description of how this is to be accomplished in a real-world manner. My hope is to have something available sometime this summer that will allow folks to play with it at least in a limited way. If you get the chance and have the resources you should look into at least getting the Plan 9 documents. They're like $150 but call and verify that price since I didn't this morning. Also note, there are now two releases of Plan 9 floating around out there. The only distinction I am aware of is one is the 'old' release and the current is the 'new' release. Don't have a clue as to how to tell them apart or what compatibility problems will exist. My best estimate is that in about a month I will have the resources to install and begin developing the model. I am currently between employers (I don't work at Tivoli-IBM anymore) so I'm job hunting in the Austin area over the next few weeks. I'll make reports to the list on the results as I manage to get results. I don't know about Java on Plan 9, I'll look into it. Take care. ____________________________________________________________________ | | | Those who make peaceful revolution impossible will make | | violent revolution inevitable. | | | | John F. Kennedy | | | | | | _____ The Armadillo Group | | ,::////;::-. Austin, Tx. USA | | /:'///// ``::>/|/ http://www.ssz.com/ | | .', |||| `/( e\ | | -====~~mm-'`-```-mm --'- Jim Choate | | ravage(a)ssz.com | | 512-451-7087 | |____________________________________________________________________|

1 0

Re: (eternity) Automating BlackNet Services
by Adam Back 17 Dec '03

17 Dec '03

Scratch Monkey writes: > Here's a way to do an automated "high risk" server, using many of the > same methods as the eternity implementation but with longer delays and > more security for the server. This design ties in pretty well with what I understood Tim May's suggestion to be of using BlackNet to provide eternity services. I notice that you are assuming that all document delivery would be via digital dead-drop (alt.anonymous.messages). Depending on the usage pattern of this service it has the potential to be higher bandwidth than by Eternity USENET design. The BlackNet with dead-drop only scheme you propose will become more expensive in bandwidth than Eternity USENET at the point at which the volume of satisfied document requests being posted to USENET for different recipients exceeds the volume required to repost the traffic at the desired update rate. This is because you may have multiple requests for the same document, all of which must be posted to alt.anonymous.messages. One thing you could do to reduce this overhead would be to combine requests for the same document. To do this you could add an extra delay to satisfying requests to increase the chances of accumulating more requests for the same document. Alternatively, documents which were sent out within the last 24 hours or so could have just the bulk symmetric key encrypted for the subsequent recipients sent together with a message-id. (A separated multiple crypto recipient block). A more subtle problem you would probably want to address with this design is that you don't really want anonymous requested documents to be linkable, so you would need to do stealth encoding of the messages. This tends to be more complex for multiple recipients, but it is doable, and is made easier by standardising on public key size. In general I think I consider my Eternity USENET design more secure than your design and of similar overhead depending on whether the usage pattern results in lower bandwidth. I make this claim because users are offered better security with E-USENET because they are completely anonymous, and don't need to submit requests. They can passively read E-USENET, perhaps on a university campus, or with a satellite USENET feed. The readers are much harder to detect. This is significant because remailers are complex to use, and the users should be assumed to be less technically able (ie more likely to screw up remailer usage). Publisher anonymity is of basically the same security. A lower bandwidth alternative, to either E-USENET or what you have termed Automated BlackNet alternative is therefore to send messages via use-once mixmaster remailer reply blocks of the sort used by some nymservers. Clearly this is also lower security because the user must creating reply blocks which ultimately point back to himself. However the performance win is big. With this architecture BlackNet can win significantly over E-USENET because the volume is reduced to just indexes of available documents. Also I consider indexes are probably low enough risk for people to mirror on the web or cache on the web or whatever. My E-USENET prototype design has a separate index mechanism. (I understand there is some magic inside mixmaster which prevents packet replay, which helps avoid message flood attacks, though didn't locate the code fragment responsible for this functionality when I examined the sources.) Also I found your use of hashes and passwords so that the server does not necessarily know what it is serving interesting. I have similar functionality in my prototype E-USENET implementation. I mainly included the functionality because the prototype is also being used as an publically accessible eternity USENET proxy, to allow the operator to marginally reduce risks. I think this approach is of marginal value, in that the attacker will be easily able to compile an index from the same information as users. This is really a form of secret splitting: the key is one part, and the data the other part. The key can be considered to be part of the URL. > Both the client and server software should be trivial to write, and in > fact I am working on that now. The server is partially written, but I am > at a handicap because I do not have access to usenet at this time. If > anyone knows of some canned code (preferably sh or c, but perl would work) > that will perform functions such as "Retrieve list of articles in > newsgroup x" and "Retrieve article number y", a pointer would be nice. http://www.dcs.ex.ac.uk/~aba/eternity/ I have done most of the work already I think. What you are trying to do is so similar that you should be able to acheive what you want with some light hacking of my perl code. For testing purposes I am in the same position as you; dialup ppp connection and linux machine. What I did was to implement both newspool access code, and NNTP access code. For local testing I just create a dummy news-spool. The eternity distribution comes with a few documents in this dummy news spool. A real local news spool would work also. Then you can simulate everything you want offline. You can change the config file to switch to an open access NNTP news-server at any time for a live test. All the code to read USENET is there, and to scan chosen NNTP headers, etc. I would highly recommend perl as a rapid prototyping language. What you see took 3 days (long days, mind, motivation was at an all time high around then). Adam

1 0

(fwd) Automating BlackNet Services
by Adam Back 17 Dec '03

17 Dec '03

Scratch Monkey, a nym, described this BlackNet variant on the eternity list(*), which raises some interesting issues I think. I am currently forwarding eternity discussion backwards and forwards between the lists and adding Cc's on my replies. Adam (*) To subscribe see http://www.dcs.ex.ac.uk/~aba/eternity/ there is a CGI form to subscribe, or send message with body "subscribe eternity" to majordomo(a)internexus.net. ------- Start of forwarded message ------- To: eternity(a)internexus.net From: nobody(a)REPLAY.COM (Anonymous) Organization: Replay Associates, L.L.P. Subject: (eternity) Automating BlackNet Services Sender: owner-eternity(a)internexus.net Precedence: bulk On Tue, 13 Jan 1998, Adam Back wrote: > This suggests that another approach would be to have two classes of > services. Users of high risk documents can put up with 24 hour turn > around, and lower risk documents can be served by an alternate > service, intermediate risk documents can exist by using low risk > resources until detection. Here's a way to do an automated "high risk" server, using many of the same methods as the eternity implementation but with longer delays and more security for the server. For now I am calling this scheme (which is not much more than an automated participant in the BlackNet scheme) ABNS, for Automated BlackNet Server. 1) Server program resides on host with large disk and full news feed. 2) Server program watches alt.anonymous.messages. 3) Alice anonymously posts data to alt.anonymous.messages, in a format similar to eternity documents. However, the data would typicaly be encrypted to the public key(s) of the 4) Server notices the message, processes it and stores the data. 5) Bob anonymously posts a request for a document to alt.anonymous.messages. 6) Server notices the request, and anonymously posts a public key to alt.anonymous.messages along with a statement that the requested document is available. 7) Bob notices the post from the server, and anonymously posts a second request to alt.anonymous.messages, this time encrypted with the server's public key. This second request could include Bob's public key. 8) The server notices and decrypts the second request, and anonymously posts the requested document to alt.anonymous.messages, encrypted with Bob's public key if one was provided. The reason for steps 6 and 7 are to prevent multiple servers from responding to the same request with (potentialy) very large files. Of course, if Bob knew the data was available from a particular ABNS, he could skip steps 5 and 6. Both the client and server software should be trivial to write, and in fact I am working on that now. The server is partially written, but I am at a handicap because I do not have access to usenet at this time. If anyone knows of some canned code (preferably sh or c, but perl would work) that will perform functions such as "Retrieve list of articles in newsgroup x" and "Retrieve article number y", a pointer would be nice. So far, this is not too exciting, but the addition of a couple of extra technologies could make it very usefull... If the "Steganographic File System" being proposed by Ross Anderson comes to fruition, the ABNS could recieve a filename and password as part of each submission, and then promptly 'forget' them. In this way, not only does the server not have access to the contents of the file, it doesn't even know what files it has! Retrieval requests would include the appropriate information to enable the server to fetch the data. The addition of digital cash to the picture would make it really viable, because the server could charge for storage, or retrieval, or both. So picture this: Alice has some data she wants to sell. She encrypts this data to the public key of an ABNS, along with the filename and password to be used for file access and an amount of cash sufficient to pay for storage costs for maybe 6 months. She would also specify a 'value' for the data, which the ABNS will charge for access to this data and of which Alice will recieve a cut. She could also send a small advertisement (for which here storage fees should be minimal) as a separate document, and give it a value of zero. The server decrypts the message and verifies the cash. It then stores the file in the designated filename/password location in the SFS (stego file system). It makes a hash of the filename/password, and stores this hash in a 'table of contents' file that would also contain: - - the 'paid-until' date for the data. - - the public key of the submitter. - - the 'price' for the data It would then forget the filename and password. Bob learns of the existance of the data (how? I haven't thought about that yet but it doesn't seem to me that it would present much of a problem) and wishes to purchase it. He sends a message to the server by encrypting to the server's public key and posting to alt.anonymous.messages. In his message he includes the filename/password of the data he wants, along with an appropriate amount of cash and Bob's public key. The server decrypts Bob's request: - - First, it pockets the cash. (Everything else is just to keep customers) - - It then creates a hash based on the filename/password of the data that Bob is requesting. - - It looks up that hash in the table of contents file. - - If it is not found, it anonymously posts a message encrypted to Bob's public key indicating that the data is not available, but that Bob now has a line of credit at this particular ABNS. :) - - If it _does_ find the hash in the contents file, it checks the paid-until date. - - If the file is not paid up, the server treats it as if the file were not present (and in fact, it deletes the file at this time, something it could not do without the filename/password that Bob supplied). - - If the file is present, and storage fees are paid up, and Bob has enclosed enough cash (or has enough credit), the ABNS accesses the file in the stego filesystem and anon-posts it to Bob's public key. - - The server then forgets the filename/password, but remembers the hash. - - Of the 'fee' collected from Bob, the server allocates it as follows: - 70% is kept. - 10% is credited to the hash retrieved by Bob, to extend it's "Paid up" time. This means that documents that bring in a lot of money can pay for thier own storage costs, without the contributer needing to keep paying. - 20% is encrypted to the public key listed in the table of contents and posted to alt.anonymous.messages, as a royalty to the contributor. Of course, this is just one possible policy for the server to have. Market forces will shape the eventual pricing scheme. I'm actualy not sure if such a system would be used, because Alice may have no motivation to send her data to an ABNS when she can run the server herself and take 100% of the money. Comments on this aspect of operation would be appreciated. Either way, the same software could be used. I hope to post initial versions within a couple of weeks, assuming I can hack myself some account with nntp access for testing. -Scratch Monkey- 85d8e7d860504ba9e90527e7e89210d7 This is a new persistant nym. PGP key(s) will be posted soon, and I will verify that the keys belong to the same person who posted this message by providing the string that produces the md5 hash above.

1 0

mirroring services, web accounts for ecash
by Adam Back 17 Dec '03

17 Dec '03

Some meta-level thoughts on the eternity service document availability problem: Many of the problems with designing an eternity service are introduced by trying to build real time accessibility of data (with similar response times for documents to those offered by web servers). The BlackNet model can quite ably provide eternity like services with perhaps 24 hour turn around on documents. Everything is operated by digital dead drop (via say news:alt.anonymous.messages), or mixmaster remailers. This suggests that another approach would be to have two classes of services. Users of high risk documents can put up with 24 hour turn around, and lower risk documents can be served by an alternate service, intermediate risk documents can exist by using low risk resources until detection. The low risk document service could be just an automated mirroring service, and could for example explicitly state that illegal materials in server localities will be removed on the server operator becoming aware of this fact, or perhaps on receipt of court notification. This presents the kind of "we aim to discourage illegal materials" persona that commercial ISPs like to present to the police and spooks. It might also be useful to partially automate the differences in types of material which can be hosted in various jurisdictions. Scandinavian countries might be used for pornography in the 14 - 21 year old range; other jurisdictions useful for copyright music materials, where music royalties are collected by a blank media tax; the US might be useful for publication of materials critical of Islamic beliefs, and so on, in each case the materials being strictly legal in the server locality. The mirroring service could be offered by mirror site operators as a public service for locally controversial materials, or services could be charged for to improve long term availability. If the mirroring service is automated, it is likely that materials will slip through the gaps in the system (especially if it is designed with this property in mind), much like warez used to be traded in funny named directories on badly configured ftp servers, or world read and writeable ftp incoming directories. The operator says "darn warez pirates" and removes the offending warez when he is notified. But it might stay up for a few weeks, and URLs spread quickly, and there are lots of open access sites. Another less controversial "host" service which warez pirates might be likely to get away with abusing would be simple web space available for ecash. Lance Cottrell already offers this such anonymous web accounts. If many ISPs start offering this kind of service, the pirates will be more easily able to keep going by hopping from account to account, as accounts are closed for breach of policy, in a similar way that spammers treat accounts as disposable. A TAZ server could even offer a persistent virtual URL to a migrating warez file collection located either on mirroring sites, or on anonymous ecash paid web accounts. (TAZ servers just offer a layer of indirection, see Ian Goldberg and Dave Wagner's paper: http://www.cs.berkeley.edu/~daw/cs268/ ) Adam

3 5

Freedom Forum report (freedom of association) (fwd)
by Jim Choate 17 Dec '03

17 Dec '03

Forwarded message: > Date: Tue, 13 Jan 1998 18:55:24 -0700 > From: Jim Burnes <jim.burnes(a)ssds.com> > Subject: Freedom Forum report (freedom of association) > (It is left as an excercise to the reader to figure out why > prohibition > needed an amendment to the constitution while prohibition of > other > mind altering substances did not ;-) What amazes me is that such groups as NORML and other pro-drug organizations have not had their lawyers raise this issue. As far as I can tell nobody has *ever* raised this issue in regards to the drug prohibitions. ____________________________________________________________________ | | | Those who make peaceful revolution impossible will make | | violent revolution inevitable. | | | | John F. Kennedy | | | | | | _____ The Armadillo Group | | ,::////;::-. Austin, Tx. USA | | /:'///// ``::>/|/ http://www.ssz.com/ | | .', |||| `/( e\ | | -====~~mm-'`-```-mm --'- Jim Choate | | ravage(a)ssz.com | | 512-451-7087 | |____________________________________________________________________|

1 0

Rincin AP
by nobody＠REPLAY.COM 17 Dec '03

17 Dec '03

Forward from Terrorism list: From: JCHV72A(a)prodigy.com (MR JAMES P DENNEY) Date: Tue, 13 Jan 1998 19:45:44, -0500 To: TERRORISM(a)mediccom.org Subject: RICIN ALERT Bureau of Narcotic Enforcement Merced/Mariposa Narcotic Task Force RE: RICIN Alert The Sacramento Regional Office of the Bureau of Narcotic Enforcement has offered this alert to all it's personnel: "The following alert has been confirmed and is being shared throughout the law enforcement and intelligence community. This alert advises that nationwide trend among drug traffickers is to "bait" law enforcement officers with a white powder called RICIN. RICIN is a derivative of Castor beans and looks like powder methamphetamine. It is highly toxic and if it contacts human skin, it is fatal. The death process takes several days, depending upon the dosage, and is almost impossible to detect during an autopsy. Forensic experts advise that if you field test RICIN in the Scott Reagent Kit, it will foam and bubble extensively. The test will also produce a gas that is very similar to mustard gas and can also be lethal if inhaled. RICIN is 6,000 times more lethal than cyanide and there is no antidote. Symptoms of contact exposure to RICIN are: Fever, cough, weakness, and hypothermia, progressing to dangerously low blood pressure, heart failure and death. Due to this situation, in the event of suspect drug seziures, do not come into direct skin contact with any powdered substances, and exhibit caution of field testing any powdered substances." We are forwarding this advisory to all California EMS Agencies and recommend that each agency contact the local hospitals in their area. We are unaware if RICIN can be detected on a toxicological exam. There is a potential for someone, other than law enforcement, to become contaminated with this substance. -----

1 0