December 2003 - cypherpunks-legacy

Re: DC net Implementation
by acspring＠knoware.nl 17 Dec '03

17 Dec '03

> >Using a central node to coordinate the DC-net traffic requires that the >participants trust that central node. If the central node is evil, >I think there are things it could do to identify message senders. For >example, instead of doing a single collation of N messages, it could >do N collations of N-1 messages, and find out who sent a message by >seeing in which collation that message doesn't show up. > A collation of N-1 nodes will always produce garbage; the whole set is needed for the message to fall out. Example C wishes to broadcast the number 10. A sends 5 to B B sends 11 to C C sends 7 to D D sends 14 to A A sends 14 - 5 = 9 to Central node B sends 5 - 11 = -6 C sends 11 - 7 + 10 = 14 D sends 7 - 14 = -7 Central node computes 9 - 6 + 14 - 7 = 10; Collating the subset ABC yields 17 Collating ABD yields -4 ACD yields 16 BCD yields 1 What Jim McCoy was talking about (I think: please correct me) was that there are attacks on this protocol, that can prevent messages from being transmitted; or alter messages in transit. Example: B wants to jam the transmission. He simply violates the protocol. A sends 14 - 5 = 9 to Central node B sends 5 - 11 + 8 = 2 (the +8 is static) C sends 11 - 7 + 10 = 14 D sends 7 - 14 = -7 Now the message sums up to 18, instead of 10 as C intended. Worse than that; If B knows that 10 is going to be broadcast, he can force the message to be any value he wants, by properly choosing his jamming signal. There's an even nastier trick you can play with the vanilla DC protocol. Two adjacent members can conspire to set up a 3rd. Let's say the DC Cell gets busted by the Feds for posting the illegal number 10 to the Internet. The guilty party is C, but C and D can lie about the number they shared and make it look like A. C testifies, "I received an 11 from B and sent a -3 to D" D testifies, "I received a 3 from C and sent a 4 to A" That makes A's calculation look off by 10, the number of the message. A testifies, "You liar! You gave me 14!" Who's lying? I'm not sure is these constitute bugs or "features" of the DC protocol; since the goal is to obscure the source of the message, allowing jammers and spoofers may preserve plausible deniability at the cost of network reliability; then again, maybe I'm just being lazy. -- You have violated Robot's Rules of Order and will be asked to leave the future immediately. Thank You.

1 0

Re: Islands in the Net
by Amanda Walker 17 Dec '03

17 Dec '03

Tim May writes: > We "locally clear" (approximately the same as "readable on its face") > cash and commercial paper because of an assumption that forgery > is difficult and unlikely. When forgery becomes common in some > area, merchants carry lists of suspected numbers, IDs, etc., and > the "readable on its face" criterion erodes. Exactly. What allows something to be used as an economic unit are its uniqueness and liquidity. Real assets are unique simply by virtue of being physical objects, and are liquid (in the long run) by virtue of having inherent value. I don't worry about someone forging my house, for example, and even things like gold coins or other precious metals are much easier to verify than to forge, and once verified can be exchanged for real assets without reference to the entity which originally issued them (for example, the value in a Krugerrand is that it's gold, not the fact that it was issued by South Africa). Precious metals and the like are borderline, for all practical purposes we can view them as having inherent value, since people have assigned them value for all of recorded history. Currency, however, has no inherent value. Its only value lies in its being made up of unique tokens which can be exchanged for real assets. If a token ceases to be unique, it ceases to have value (except perhaps as a curiousity-- there may well be people who collect counterfeit money, for all I know). Also, if it loses its ability to be exchanged for real assets it likewise loses its value (e.g., Confederate dollars from the Civil War). Digital cash poses two problems. The first is that digital information is easier to duplicate than to verify, and a successful forgery is absolutely indistinguishable from the original, since it is the information itself that is the token, not any phsyical instantiation of it. The other is that to be successful, digital cash needs to be liquid. For a token to be liquid, it must be backed by real assets. Governments are the classical examples of entities which have sufficient resources to back a currency, although cartels in the private sector can also do so (VISA/ MasterCard, for example). So far, though, no one has solved either the uniqueness problem or the liquidity problem for digital cash. As a result, it might be more realistically be called "digital scrip", at least so far. > This is the sense in which I meant that "Money sure isn't like this." Indeed, mainly because existing currency is either physical objects or data controlled by the banking system and overseen by governments. Right now, digital currency only works by being a pointer to a token, not the token itself. > We need to find a way to get back to exploring the various nifty > systems that are being described in the crypto papers, but which lack > any real implementation. Speaking as someone who has a sharp interest in such things, and the resources to apply to them, I have to say that the current regulatory environment serves as a large barrier. If industry's hands are tied, then this all has to be done in "free time" or academia... This slows things down immensely. If it weren't for the Department of State holding the export-control sword over our heads, we'd already have things like digital purchasing, online user registration, digital sigs & encryption by default in email, and so on. Amanda Walker InterCon Systems Corporation

2 1

DECEMBER '94: Object/Document Security BOF
by Eric Blossom 17 Dec '03

17 Dec '03

Group Name: Object/Document Security BOF (ios) IETF Area : Security Area Date/Time : Wednesday, December 7, 1994 0930-1200 =============== The purpose of this BOF is to present information and to discuss ideas associated with document/object security, store and forward security, and third-party security services. The general idea of creating protected objects (e.g. signed documents, encrypted files) which can be accessed and transferred by a variety of applications is being discussed in several contexts - store and forward extensions to GSSAPI, PEM-MIME work, www security, etc. We would like to discuss requirements and constraints for a general capability for protected objects and explore the need for a common approach to providing these types of services. The BOF is scheduled for 9:30am Wednedsay December 7th. The IOS (Information Object Security) BOF is within the Security Directorate. If you're interested in this area, we hope you can attend. We are planning to present some of our ideas on the requirements and goals for general protected objects as well as details on an Information Object Security project BBN is currently working on for ARPA (short summary below). This project has developed security tools for protection of documents and objects as well as for invoking and performing trusted third party services. We're looking for anyone else who would like agenda time to either present specific work/ideas or to discuss requirements and other contexts for protected objects. If you'd like to volunteer either send a message to jlowry(a)bbn.com or just show up and we can sort out the agenda there. Finally there will be a discussion to determine whether there is interest in continuing. Should a mailing-list be formed ? Is there enough interest and focus to attempt creation of a working group charter ? After the BOF, we're prepared to demonstrate prototype IOS tools for any interested parties. ******** IOS Project These tools allow the users to apply multiple parallel and sequential signatures and annotations to objects/documents, and to provide access control and confidentiality protections to these objects/documents. There are a number of utilities available to perform certificate validation and maintain a cache of certificates. Included in the tool set is an ASN.1 to C++ compiler. Third-party services are also under investigation and the issues of a trusted time-stamp server, third-party involvement in non-repudiation, and proof of delivery, submission, and receipt are addressed. Documents describing the IOS project tools and architecture are available for anonymous ftp from the server ftp.bbn.com in the directory /pub/outgoing/ios_docs.

1 0

I-D ACTION:draft-atkinson-ipng-sec-00.txt
by Eric Blossom 17 Dec '03

17 Dec '03

A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IPv6 Security Architecture Author(s) : R. Atkinson Filename : draft-atkinson-ipng-sec-00.txt Pages : 13 Date : 11/16/1994 The Internet community is making a transition from version 4 of the Internet Protocol (IPv4) to version 6 of the Internet Protocol (IPv6). [Hi94] This memo describes the security mechanisms integrated into version 6 of the Internet Protocol (IPv6) and the services that they provide. Each security mechanism is specified in a separate document. It also describes how security mechanisms outside the scope of the IPng effort (e.g. key management) relate to the IPv6 security mechanisms. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-atkinson-ipng-sec-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-atkinson-ipng-sec-00.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.2) o Europe Address: nic.nordu.net (192.36.148.17) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv(a)ds.internic.net. In the body type: "FILE /internet-drafts/draft-atkinson-ipng-sec-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. For questions, please mail to Internet-Drafts(a)cnri.reston.va.us. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft.

1 0

I-D ACTION:draft-atkinson-ipng-esp-00.txt
by Eric Blossom 17 Dec '03

17 Dec '03

A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IPv6 Encapsulating Security Payload (ESP) Author(s) : R. Atkinson Filename : draft-atkinson-ipng-esp-00.txt Pages : 12 Date : 11/16/1994 This memo describes the IPv6 Encapsulating Security Payload (ESP). ESP seeks to provide integrity and confidentiality to IPv6 datagrams. It may also provide authentication, depending on which algorithm and algorithm mode are used. Non-repudiation and protection from traffic analysis are not provided by ESP. The IPv6 Authentication Header (AH) might provide non-repudiation if used with certain authentication algorithms. The IPv6 Authentication Header may be used in conjunction with ESP to provide authentication. Users desiring integrity and authentication without confidentiality should use the IPv6 Authentication Header (AH) instead of ESP. This document assumes that the reader is familiar with the related document "IPv6 Security Architecture", which defines the overall security architecture for IPv6 and provides important background for this specification. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-atkinson-ipng-esp-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-atkinson-ipng-esp-00.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.2) o Europe Address: nic.nordu.net (192.36.148.17) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv(a)ds.internic.net. In the body type: "FILE /internet-drafts/draft-atkinson-ipng-esp-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. For questions, please mail to Internet-Drafts(a)cnri.reston.va.us. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft.

1 0

Cash
by dwa＠mirage.svl.trw.com 17 Dec '03

17 Dec '03

>From alt.2600... In article 8imYglW00iV8M5q0dV(a)andrew.cmu.edu, Andrew Lewis Tepper <at15+(a)andrew.cmu.edu> writes: > Imbedded in 1991 series $20 bills (and I assume all later and higher > bills) are thin plastic(?) strips with metallic writing on them. If > you're careful you can remove them with a razorblade by slitting the > bill's top edge and gently pulling it out. I've heard that airports will > soon have "Money Detectors" that will count total cash carried per > person. I'd like to figure out how the system works. I also think it > would be cool for people to collect all the strips in any money they > ever came in contact with and keep those in their wallets. Soon it would > look like everyone was walking around with $100K's of cash, rendering > their system useless. > > Andy > In article oh9(a)crl2.crl.com, eric(a)crl.com (Eric Fredricksen) writes: > Anarch (anarch(a)cse.ucsc.edu) wrote: > : They're in tens, too (don't know about ones and fives). I've never been > : able to remove one completely, but I've exposed the ends. Do you know > : how many there are in each bill, and where? I know in tens there's at > : least one, about a fifth of the way in from the left side (looking at > : the front). > > They're easy to remove. Just rip the bill diagonally from the edge to > the strip on either side of it, and pull the little triangle you just > made. The strip comes with it. Show it to your friends. > Assuming this is true, it would seem that even good, old fashioned, paper currency doesn't provide the level of anonymity that one would think. Scary... Dana W. Albrecht dwa(a)mirage.svl.trw.com

3 2

No Subject
by Anonymous 17 Dec '03

17 Dec '03

Can someone please list the mail-to-news gateways that are available, and any discrepancies aboyr message acceptance based on SUBJECT: line. Thanks, - spooge

2 1

Re: Cash
by jamiel＠sybase.com 17 Dec '03

17 Dec '03

At 12:25 PM 11/18/94, Dana Albrecht wrote: >>From alt.2600... > >In article 8imYglW00iV8M5q0dV(a)andrew.cmu.edu, Andrew Lewis Tepper ><at15+(a)andrew.cmu.edu> writes: >> bill's top edge and gently pulling it out. I've heard that airports will >> soon have "Money Detectors" that will count total cash carried per >> person. I'd like to figure out how the system works. I also think it This one has been flying around ever since the strips were put in place. It has been refuted as techically infeasable. (I don't remember the exact arguement, it had to do with the strips being mostly nonreactive and there being no real way to count how many/what denomination is in a stack.) >Assuming this is true, it would seem that even good, old fashioned, >paper currency doesn't provide the level of anonymity that one >would think. Scary... Also, realize that some places to look for that strip and if you pull it it might not be accepted (most places that check only look at $50s and $100s, though). -j

2 1

No Subject
by nobody＠jpunix.com 17 Dec '03

17 Dec '03

"George Miranda" writes: > I'm curious as to how one goes about setting up a snake or a tentacle G'day Larry, fancy updating your Privacy and Anonymity FAQ? You should have the time before getting booted off this latest account :-; - John Doe

1 0

Inman
by rishab＠dxm.ernet.in 17 Dec '03

17 Dec '03

> In class today, Inman mentioned that his privacy had been invaded during > the nomination process; when asked for elaboration, he cited cases of the > press going around asking questions about his wife and sons. So Inman > seems sensitive to issues of privacy, but in this case, they seem to be > primarily associated with invasions of privacy by the media rather than by > the government. I seem to remember that Inman was quoted as having said many NSA-ish things in the past; I think this was mentioned on the list during his nomination process - Inman appeared to spooky to be bothered about individual privacy from 'National Security' spooks themselves. ----------------------------------------------------------------------------- Rishab Aiyer Ghosh "Clean the air! clean the sky! wash the wind! rishab(a)dxm.ernet.in take stone from stone and wash them..." rishab(a)arbornet.org Voice/Fax/Data +91 11 6853410 Voicemail +91 11 3760335 H 34C Saket, New Delhi 110017, INDIA

1 0