From majordom Tue Mar 4 20:31:08 1997 Return-Path: Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA08992; Tue, 4 Mar 97 20:31:08 EST Received: from banana-jr.itd.nrl.navy.mil by itd.nrl.navy.mil (4.1/SMI-4.1) id AA08972; Tue, 4 Mar 97 20:30:34 EST Date: Tue, 4 Mar 1997 20:30:41 -0500 (EST) From: "Michael G. Reed" To: Wei Dai Cc: David Goldschlag , shamrock@netcom.com, goldschlag@itd.nrl.navy.mil, syverson@nrl.navy.mil, daw@cs.berkeley.edu, mccoy@communities.com, onions@itd.nrl.navy.mil Subject: Re: Onion Routing In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-onions@itd.nrl.navy.mil Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- On Tue, 4 Mar 1997, Wei Dai wrote: |>There are no references, other than two pieces of email that describe the |>original idea. It is somewhat similar to Onion Routing, but focuses on |>streams rather than packets. I implemented a prototype, but then realized |>that even with constant bandwidth padding, there are a number of attacks |>possible on my original design. I'm currently trying to (but not really |>devoting much time on it) analyze the protocol more clearly. Onion Routing is stream based as well. It runs on top of TCP. To try to do this at the packet level is ludicrously large overhead (we have a reference to a paper that talked about a prototype system that did it at the IP layer, but there were some BIG problems with overhead and handling ICMP messages that may be bounced back to the sender for any packet sent). |>Besides possible attacks, I'm also concerned about possible abuses of |>anonymous routing systems. Have you thought about how to prevent things |>like hackers breaking into computer systems while maintaining anonymity |>with the Onion Routers? That is a political question, and to date, we have tried to only deal with the technological issues instead of the political ones. As soon as we start dealing with political issues, this thing will fall apart. Back in touch with reality though, we are adding the ability for either end of an anonymous connection to blacklist sites or restrict which protocols they support. I would prefer we follow up this discussion on the onion mailing list. The list is unmoderated (and brand spanking new :-). Send mail to Majordomo@itd.nrl.navy.mil with the line "subscribe onions". This will allow us to better track questions/comments/improvements/etc to the system (ie, make sure no one is out of the loop on possible changes to the system). Thanks! - -Michael -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMxzMxU8Qx019l0ClAQGDQgP/QQFrJe8rMa7RrqonvFc5Yj3bsQGPVdOE 8511aIq2+MheuWEXITz6yqAlm6uoxF0okClHHQQOQqwIoXoKHG1JMkTRBEwrXsCJ v9fLBY9cBfwpRRSZQsZH8/wRXJPZ+/o6i/ypCRtQ79naOqHuDRrKi/ruw36Z7jIE iO9pxEHZkls= =QQqM -----END PGP SIGNATURE----- From majordom Wed Mar 5 00:22:34 1997 Return-Path: Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA13239; Wed, 5 Mar 97 00:22:34 EST Received: from homer.communities.com by itd.nrl.navy.mil (4.1/SMI-4.1) id AA13220; Wed, 5 Mar 97 00:22:20 EST Received: from [205.162.51.35] (pericles.communities.com [205.162.51.35]) by homer.communities.com (8.7.5/8.7.3) with ESMTP id WAA27990; Tue, 4 Mar 1997 22:57:08 -0800 X-Sender: mccoy@mail.communities.com (Unverified) Message-Id: In-Reply-To: <199703050150.UAA03701@golem.itd.nrl.navy.mil> References: (message from Wei Dai on Tue, 4 Mar 1997 16:59:24 -0800 (PST)) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 5 Mar 1997 00:21:20 -0500 To: David Goldschlag From: Jim McCoy Subject: Re: Onion Routing Cc: weidai@eskimo.com, onions@itd.nrl.navy.mil Sender: owner-onions@itd.nrl.navy.mil Precedence: bulk David Goldschlag writes: >The abuse you noted, that hackers can break into systems anonymously, >was pointed out in a somewhat happy way by someone who funds computer >security work. Anonymous connections will force better defense. While it may seem like a poor excuse, I am not sure that the identity and authorization problem is something which the basic system should concern itself with. There are a variety of existing methods which can be attached at the entry and exit points of the system (e.g. SSL client cert, SPKI certs and credentials, etc.) It is not as if re-routing packets through poorly logged systems is that difficult now... >Our first network topology for onion routing is a closed system: you >must enter the network somewhere and that point knows where you've >come from and where you are going. So there is some tracking there. >We have another topology where the network knows who you are at entry, >but not where you are going. That introduces more concerns. But you >still need to identify yourself at entry to the network. Entry and exit authorization and authentication should be, IMHO, a local decision. The exit authorization is probably the most important when considering the hacking aspect, transport and application level gatekeepers would probably be best. The exit point is probably going to be the one shouldering the burden of responsibility for such problems, so making it possible for the exit points to enforce a policy regarding this would probably be the best solution. jim From majordom Wed Mar 5 04:54:04 1997 Return-Path: Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA16706; Wed, 5 Mar 97 04:54:04 EST Received: from freya.cs.umass.edu by itd.nrl.navy.mil (4.1/SMI-4.1) id AA16700; Wed, 5 Mar 97 04:53:48 EST Received: from opine.cs.umass.edu (opine.cs.umass.edu [128.119.41.246]) by freya.cs.umass.edu (8.7.6/8.6.9) with SMTP id EAA26696; Wed, 5 Mar 1997 04:53:47 -0500 Message-Id: <331D42AB.3F54@cs.umass.edu> Date: Wed, 05 Mar 1997 04:53:47 -0500 From: Lewis McCarthy Organization: Theoretical Computer Science Group, UMass-Amherst, X-Mailer: Mozilla 3.01Gold (X11; U; OSF1 V3.2 alpha) Mime-Version: 1.0 To: onions@itd.nrl.navy.mil Cc: Wei Dai Subject: Re: Onion Routing / Policy References: (message from Wei Dai on Tue, 4 Mar 1997 16:59:24 -0800 (PST)) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-onions@itd.nrl.navy.mil Precedence: bulk David Goldschlag writes: > Anonymous connections will force better defense. Anonymous communication mechanisms seem to produce the nice side effect of encouraging people to make their local policy decisions conscious and explicit. Then they start to realize that widely- deployed security mechanisms are very useful for exercising local control over their electronic interactions with other people. The anonymous remailers have stimulated interest in local mail policy controls. When you yank away the origination information that people took for granted (although it was never truly reliable), they have to face the fact that they're fumbling blindly in the dark until they take positive steps to inform the authorization process. -- Lewis http://www.cs.umass.edu/~lmccarth/lmkey.asc "Overwhelmed by 21 documents? Let LiveTopics guide you!" --AltaVista From majordom Wed Mar 5 05:21:36 1997 Return-Path: Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA17078; Wed, 5 Mar 97 05:21:36 EST Received: from freya.cs.umass.edu by itd.nrl.navy.mil (4.1/SMI-4.1) id AA17070; Wed, 5 Mar 97 05:21:28 EST Received: from opine.cs.umass.edu (opine.cs.umass.edu [128.119.41.246]) by freya.cs.umass.edu (8.7.6/8.6.9) with SMTP id FAA26891; Wed, 5 Mar 1997 05:21:27 -0500 Message-Id: <331D4927.FF6@cs.umass.edu> Date: Wed, 05 Mar 1997 05:21:27 -0500 From: Lewis McCarthy Organization: Theoretical Computer Science Group, UMass-Amherst, X-Mailer: Mozilla 3.01Gold (X11; U; OSF1 V3.2 alpha) Mime-Version: 1.0 To: onions@itd.nrl.navy.mil Cc: Wei Dai Subject: Re: Onion Routing / Authentication Points References: (message from Wei Dai on Tue, 4 Mar 1997 16:59:24 -0800 (PST)) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-onions@itd.nrl.navy.mil Precedence: bulk Jim McCoy writes: > It is not as if re-routing > packets through poorly logged systems is that difficult now... Agreed -- and I don't really foresee that condition changing. [...] > The exit authorization is probably the most important when > considering the hacking aspect, transport and application level > gatekeepers would probably be best. The exit point is probably going > to be the one shouldering the burden of responsibility [...] For auditing purposes, it seems to be desirable for a host on the apparent return path to be able to check its logs and say "they went that-a-way" after an intrusion. Then the first host (working backwards) that didn't authenticate the prior link (or had its logs detectably wiped) catches some heat. If the first such host turns out to be a .mil then the backdraft is likely to be pretty significant. I guess I'm arguing that an organization has a motive to authenticate both at the latest exit point in its administrative domain, and at the earliest entry point in its admin. domain. These points may be distinct. -- Lewis http://www.cs.umass.edu/~lmccarth/lmkey.asc "Overwhelmed by 21 documents? Let LiveTopics guide you!" --AltaVista From majordom Fri Mar 7 08:04:53 1997 Return-Path: Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA24009; Fri, 7 Mar 97 08:04:53 EST Received: from banana-jr.itd.nrl.navy.mil by itd.nrl.navy.mil (4.1/SMI-4.1) id AA23997; Fri, 7 Mar 97 08:04:44 EST Date: Fri, 7 Mar 1997 08:04:52 -0500 (EST) From: "Michael G. Reed" To: onions@itd.nrl.navy.mil Subject: Logging... Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-onions@itd.nrl.navy.mil Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- All- Just a question I wanted to bounce off people: What do you all want to see in terms of logging in a system like this? There are a number of very good arguments on both sides of the fence. Currently, a *LOT* of information is logged, but this is so we can continue to debug the system. By its very nature, this system is a beast to debug, so we do keep a lot around for now. My view is that *ALL* logging that does not report an explicit error in the protocol should be removed. This has the side effect of making it impossible to track a connection back once it is terminated (assuming all core nodes also discard their internal identifiers or reuse them -- I trash them as soon as I can right now and reuse is governed by random probability). If a connection is still in place, then the path can be determined with the help of all core routers taking part in the connection (a bitch even at that, but possible). A few people have commented that 'traceability' may be desirable for legal reasons, but I would argue the contrary. Would it not be possible to consider the system as a Common Carrier in the telephony sense (ie, they cannot be held responsible for the actions of the users, they are merely a conduit that anyone can use) or does this then mandate that we have a way to tap the communications channels (impossible except at the endpoints)? Comments? - -Michael -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMyASeE8Qx019l0ClAQHkvgP/e7JZ65QsX5Ik5WAFlyn+U102c0h+lelH K880Du7bBxIZ8T526akJI7LzFZQY8eNSSqverWl8Jofe4PZ5zWc1pv1VmQKDsCJd SWKw6rfCa92fqXd6nUxzwaWlu5gKbtWkhguFvbobbC38MnQ7z8utgp+I1stIz8vw rdAg+hfYd0E= =brOn -----END PGP SIGNATURE----- From majordom Fri Mar 7 15:11:31 1997 Return-Path: Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA16179; Fri, 7 Mar 97 15:11:31 EST Received: from netcom12.netcom.com by itd.nrl.navy.mil (4.1/SMI-4.1) id AA16173; Fri, 7 Mar 97 15:11:24 EST Received: from sfbayarea (h96-223.ccnet.com [192.215.96.223]) by netcom12.netcom.com (8.6.13/Netcom) id MAA16670; Fri, 7 Mar 1997 12:11:22 -0800 Message-Id: <3.0.32.19970307121225.006f05a8@netcom9.netcom.com> X-Sender: shamrock@netcom9.netcom.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 07 Mar 1997 12:12:36 -0800 To: "Michael G. Reed" , onions@itd.nrl.navy.mil From: Lucky Green Subject: Re: Logging... Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-onions@itd.nrl.navy.mil Precedence: bulk At 08:04 AM 3/7/97 -0500, Michael G. Reed wrote: >-----BEGIN PGP SIGNED MESSAGE----- > >All- > Just a question I wanted to bounce off people: What do you all >want to see in terms of logging in a system like this? There are a >number of very good arguments on both sides of the fence. Currently, >a *LOT* of information is logged, but this is so we can continue to >debug the system. Sure. During debugging, logging is required. > By its very nature, this system is a beast to >debug, so we do keep a lot around for now. My view is that *ALL* >logging that does not report an explicit error in the protocol should >be removed. I agree. > This has the side effect of making it impossible to track >a connection back once it is terminated (assuming all core nodes also >discard their internal identifiers or reuse them -- I trash them as >soon as I can right now and reuse is governed by random probability). >If a connection is still in place, then the path can be determined >with the help of all core routers taking part in the connection (a >bitch even at that, but possible). A few people have commented that >'traceability' may be desirable for legal reasons, but I would argue >the contrary. The user should assume that all traffic at all sites not under his direct control is logged except one site. If the system then still provides full untraceability, it is designed well. If not, you need to rework the design. This is just like with Mixmasters. You assume that one Mixmaster is not logging internally, but that it is watched from the outside. You further assume that all other Mixmasters in the chain may be fully compromised. In production mode, the operators should not log anything but exceptions. But the user shouldn't have to rely on this. -- Lucky Green PGP encrypted mail preferred "I do believe that where there is a choice only between cowardice and violence, I would advise violence." Mahatma Gandhi From majordom Sun Mar 9 13:48:47 1997 Return-Path: Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA25136; Sun, 9 Mar 97 13:48:47 EST Received: from golem.itd.nrl.navy.mil by itd.nrl.navy.mil (4.1/SMI-4.1) id AA25128; Sun, 9 Mar 97 13:48:38 EST Received: (from goldschl@localhost) by golem.itd.nrl.navy.mil (8.8.5/8.7.3) id NAA01094; Sun, 9 Mar 1997 13:48:31 -0500 (EST) Date: Sun, 9 Mar 1997 13:48:31 -0500 (EST) Message-Id: <199703091848.NAA01094@golem.itd.nrl.navy.mil> From: David Goldschlag To: shamrock@netcom.com Cc: reed@itd.nrl.navy.mil, onions@itd.nrl.navy.mil In-Reply-To: <3.0.32.19970307121225.006f05a8@netcom9.netcom.com> (message from Lucky Green on Fri, 07 Mar 1997 12:12:36 -0800) Subject: Re: Logging... Sender: owner-onions@itd.nrl.navy.mil Precedence: bulk Regarding logs. I agree with Michael that we should remove all logging (except for errors) once we are finished with the limited test. But that doesn't address Shamrock's question: The user should assume that all traffic at all sites not under his direct control is logged except one site. If the system then still provides full untraceability, it is designed well. If not, you need to rework the design. This is just like with Mixmasters. You assume that one Mixmaster is not logging internally, but that it is watched from the outside. You further assume that all other Mixmasters in the chain may be fully compromised. We are essentially doing real-time mixing, under the hypothesis that if there is sufficient traffic, one does not need to delay traffic very much to do good mixing, nor does one need to add padding. If the network is not heavily utilized, we will need to add padding. The unanswered question is what is the balance between the delay needed to do mixing, the utilization level, and padding. If we need to add lots of padding even when the network is heavily utilized, then our approach will not be viable, because it will not use the network efficiently. Our goal is a system that many people will use, but that provides strong protection. If the first onion router in an anonymous connection is compromised, then everything is revealed, since (in our current model) the first onion router knows both endpoints of a connection. If all onion routers but the first in an anonymous connection are compromised, then the connection can be tracked back to the first onion router. If that onion router lives on a firewall and the connection originated from inside the firewall, then the source site will be revealed, but not the particular machine. If connections to that onion router are not hidden, then the set of source machines is revealed also. This weakness applies to mix based remailers also, I think, except that the set of source machines may be larger, because mail may be delayed for a while at the first remailer. If the first onion router and some intermediate onion router in the anonymous connection are not compromised, then it is hard to match incoming to outgoing traffic at the intermediate onion router. Now if attacks can be active, and traffic between nodes can be interrupted, and the uncompromised node does not respond by padding traffic, then more information can be obtained. David. From majordom Sun Mar 9 18:02:47 1997 Return-Path: Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA28209; Sun, 9 Mar 97 18:02:47 EST Received: from netcom12.netcom.com by itd.nrl.navy.mil (4.1/SMI-4.1) id AA28197; Sun, 9 Mar 97 18:02:37 EST Received: from sfbayarea (h96-131.ccnet.com [192.215.96.131]) by netcom12.netcom.com (8.6.13/Netcom) id PAA27000; Sun, 9 Mar 1997 15:02:33 -0800 Message-Id: <3.0.32.19970309150344.006f0624@netcom9.netcom.com> X-Sender: shamrock@netcom9.netcom.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Sun, 09 Mar 1997 15:04:06 -0800 To: David Goldschlag From: Lucky Green Subject: Re: Logging... Cc: reed@itd.nrl.navy.mil, onions@itd.nrl.navy.mil, raph@acm.org, jeremey@veriweb.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-onions@itd.nrl.navy.mil Precedence: bulk At 01:48 PM 3/9/97 -0500, David Goldschlag wrote: > >Regarding logs. I agree with Michael that we should remove all >logging (except for errors) once we are finished with the limited >test. But that doesn't address Shamrock's question: When are you going to make the source available? I have talked with a number of folks that are interested in running (improved) onion routers. [We discussed Onion Routers, Pipe-Net, and Raph Levien's new proposal at yesterday's monthly Cypherpunks meeting. I am cc'ing some of the participants.] >We are essentially doing real-time mixing, under the hypothesis that >if there is sufficient traffic, one does not need to delay traffic >very much to do good mixing, nor does one need to add padding. I believe this hypothesis can not be safely made. Traffic patterns vary widely, depending on the time of day and other factors. The attacker doesn't need much correlation to conduct traffic analysis. The system should be secure from traffic analysis even when there are only two users on the network. This can be achieved by moving the first proxy on the user's machine and keeping the data streams constant within each segment of the network. > If the >network is not heavily utilized, we will need to add padding. The >unanswered question is what is the balance between the delay needed to >do mixing, the utilization level, and padding. If we need to add lots >of padding even when the network is heavily utilized, then our >approach will not be viable, because it will not use the network >efficiently. Our goal is a system that many people will use, but that >provides strong protection. Using the Pipe-Net approach, the load on the network remains constant until the pipe is saturated. [Note that the heavier the network usage, the less padding is added. If the network is fully utilized, no padding is added.] If you are correct in your assumption that the network will be widely used than using a Pipe-Net approach will not add much overhead. If however there will be times of low network usage, the constant bandwidth pipes will protect the users that use the network at that time. One question may be what to do if the load saturates the pipe. If that happens, you can add delays. As long as the last proxy is on the user's machine, these artificial delays won't create a traffic analysis opportunity. >If the first onion router in an anonymous connection is compromised, >then everything is revealed, since (in our current model) the first >onion router knows both endpoints of a connection. No router should ever know more than the previous and the next router. Except of course the "router" sitting on the user's machine, which would simply be a client side HTTP proxy. >If the first onion router and some intermediate onion router in the >anonymous connection are not compromised, then it is hard to match >incoming to outgoing traffic at the intermediate onion router. Now if >attacks can be active, and traffic between nodes can be interrupted, >and the uncompromised node does not respond by padding traffic, then >more information can be obtained. That's why padding is a must. [Raph, I would encourage you to post your system to this list. It addresses a different set of problems, but they are certainly related to the issue of anonymous web browsing.] -- Lucky Green PGP encrypted mail preferred "I do believe that where there is a choice only between cowardice and violence, I would advise violence." Mahatma Gandhi From majordom Mon Mar 10 04:39:31 1997 Return-Path: Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA06061; Mon, 10 Mar 97 04:39:31 EST Received: from einstein.veriweb.com by itd.nrl.navy.mil (4.1/SMI-4.1) id AA06054; Mon, 10 Mar 97 04:39:20 EST Received: (from jeremey@localhost) by einstein.veriweb.com (8.8.5/8.6.9) id BAA09519; Mon, 10 Mar 1997 01:42:57 GMT Message-Id: <3323671D.7E9F12DE@veriweb.com> Date: Mon, 10 Mar 1997 01:42:53 +0000 From: Jeremey Barrett Organization: VeriWeb Internet Corp. X-Mailer: Mozilla 3.01 (X11; U; Linux 2.0.11 i586) To: shamrock@netcom.com Cc: David Goldschlag , reed@itd.nrl.navy.mil, onions@itd.nrl.navy.mil, raph@acm.org Subject: Re: Logging... References: <3.0.32.19970309150344.006f0624@netcom9.netcom.com> Sender: owner-onions@itd.nrl.navy.mil Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Lucky Green wrote: > > At 01:48 PM 3/9/97 -0500, David Goldschlag wrote: > > > >Regarding logs. I agree with Michael that we should remove all > >logging (except for errors) once we are finished with the limited > >test. But that doesn't address Shamrock's question: > > When are you going to make the source available? I have talked with a > number of folks that are interested in running (improved) onion routers. > > [We discussed Onion Routers, Pipe-Net, and Raph Levien's new proposal at > yesterday's monthly Cypherpunks meeting. I am cc'ing some of the > participants.] > > >We are essentially doing real-time mixing, under the hypothesis that > >if there is sufficient traffic, one does not need to delay traffic > >very much to do good mixing, nor does one need to add padding. > > I believe this hypothesis can not be safely made. Traffic patterns vary > widely, depending on the time of day and other factors. The attacker > doesn't need much correlation to conduct traffic analysis. This is true, plus even in peak traffic periods, you probably will not get "even" traffic. It will likely be bursty, or at least it _may_ be bursty. So traffic analysis may or may not be possible based on the time of day and luck of the draw. It would be best to be resistant to traffic analysis always, as Lucky suggests. Timing attacks are a concern, though probably hard to implement. If I can watch traffic entering and leaving the (core) nodes, then I can pretty well guess, for any given load, who's going where. i.e. if it takes 3 seconds for a request to enter the network at one point and pop out at another, then an educated guess about who's talking to who requires no active attack. That's not to say it's easy. This also is not affected by constant traffic, unless the constant traffic is sufficiently "real" traffic that outbound (to "real" hosts) connections are created so fast that differentiating them is hard. Having large numbers of routers certainly makes this much more difficult. > > The system should be secure from traffic analysis even when there are > only two users on the network. This can be achieved by moving the first > proxy on the user's machine and keeping the data streams constant > within each segment of the network. > > > If the > >network is not heavily utilized, we will need to add padding. The > >unanswered question is what is the balance between the delay needed to > >do mixing, the utilization level, and padding. If we need to add lots > >of padding even when the network is heavily utilized, then our > >approach will not be viable, because it will not use the network > >efficiently. Our goal is a system that many people will use, but that > >provides strong protection. > > Using the Pipe-Net approach, the load on the network remains constant > until the pipe is saturated. [Note that the heavier the network usage, > the less padding is added. If the network is fully utilized, no padding > is added.] If you are correct in your assumption that the network will > be widely used than using a Pipe-Net approach will not add much > overhead. If however there will be times of low network usage, the > constant bandwidth pipes will protect the users that use the network at > that time. > > One question may be what to do if the load saturates the pipe. If that > happens, you can add delays. As long as the last proxy is on the user's > machine, these artificial delays won't create a traffic analysis > opportunity. I don't see what can be learned from a saturated net. If all the data is real and the net is running at full capacity, then that's optimal. > > >If the first onion router in an anonymous connection is compromised, > >then everything is revealed, since (in our current model) the first > >onion router knows both endpoints of a connection. > > No router should ever know more than the previous and the next router. > Except of course the "router" sitting on the user's machine, which would > simply be a client side HTTP proxy. In this case, the client side proxy is the first router. It's compromise is equal to compromising the first router in the net if no client side proxies exist. > > >If the first onion router and some intermediate onion router in the > >anonymous connection are not compromised, then it is hard to match > >incoming to outgoing traffic at the intermediate onion router. Now if > >attacks can be active, and traffic between nodes can be interrupted, > >and the uncompromised node does not respond by padding traffic, then > >more information can be obtained. > > That's why padding is a must. Agreed. But again, if you take the core Pipe-Net (by core I mean not counting client side proxies) routers and consider them one black box, then timing things entering and leaving the black box is dangerous, if the number of such things is manageable. BTW I'm very sleepy, so shoot anything that's incoherent or blatantly obvious :-) Jeremey. - -- =-----------------------------------------------------------------------= Jeremey Barrett VeriWeb Internet Corp. Crypto, Ecash, Commerce Systems http://www.veriweb.com/ PGP Key fingerprint = 3B 42 1E D4 4B 17 0D 80 DC 59 6F 59 04 C3 83 64 =-----------------------------------------------------------------------= -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMyNnIS/fy+vkqMxNAQFrPAP/YdCkOf8x9mXuX4at77VrHhVZeHaw4Bat up03pc4P0n0c/7N8SqUVZYzISXSFILgkUXdcHmcFOHkr+bU/gX20L6k+F9NUD4qN dZNBlSkhu+ylAxXaXkH7hX2+J8oyj1RmfGEjkil7AVmxBAdTj5FZFxz2P/+u12tS PVpEh4h+GIQ= =6Zbs -----END PGP SIGNATURE----- From majordom Mon Mar 10 07:05:14 1997 Return-Path: Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA08001; Mon, 10 Mar 97 07:05:14 EST Received: from einstein.veriweb.com by itd.nrl.navy.mil (4.1/SMI-4.1) id AA07988; Mon, 10 Mar 97 07:05:04 EST Received: (from jeremey@localhost) by einstein.veriweb.com (8.8.5/8.6.9) id EAA09665 for onions@itd.nrl.navy.mil; Mon, 10 Mar 1997 04:08:49 GMT Message-Id: <33238945.54014F73@veriweb.com> Date: Mon, 10 Mar 1997 04:08:37 +0000 From: Jeremey Barrett Organization: VeriWeb Internet Corp. X-Mailer: Mozilla 3.01 (X11; U; Linux 2.0.11 i586) To: onions@itd.nrl.navy.mil Subject: Onion routing: thoughts References: <3.0.32.19970309150344.006f0624@netcom9.netcom.com> Sender: owner-onions@itd.nrl.navy.mil Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Since I just joined the list, I'm gonna recap what's in my head and what I think the issues are. Please add or remove items if necessary: Some potential problems with onion routing as described in the "Hiding Routing Information" paper (some of these are addressed in the paper itself): o The assumption that usage will be constant and high may not be not valid o Traffic analysis in a non-optimal (i.e. not evenly utilized all the time) net will not be difficult (just follow the packets) The solution to this seems to be constant utilization by simply sending data all the time, real or not. o Timing attacks are effective during low-use of the net, even if the net is saturated with fake data. (If a manageable number of routers exist. Large numbers make this more difficult). One possible solution to this would be the initiator sending a bunch of fake onions around, so that the endpoint cannot easily be indentified. Unfortunately, this might involve _alot_ of fake onions. However, as the usage of the net increased, the number of fakes required would decrease. o Some information may be obtained by denial of service attacks at particular points. Depending on the number of connections at the moment, etc, it may be possible to induce a traceable chain of "destroy" messages. This again argues for constant data streams between routers. Some other thoughts: All in all, I think a "Pretty Good Onion Router" is a good idea. I would love to be able to hit web sites without them knowing where I'm coming from, where the performance is good and I'm fairly secure in the knowledge that only someone really determined and skilled could trace me, if at all. So my suggestion is that once a "Pretty Good Onion Router" system is in place, then we focus on making it as bulletproof as possible. Have "boomerang" (my term, dunno if a real one exists) routes been considered? A boomerang route would be forward-only. i.e. rather than an onion containing the responder's proxy node as the endpoint, it would contain itself. Then the onion would describe a forward-only path from a router back to itself. The responder's proxy node would get a slightly different packet, identifying it as "the" node. Rather than specify both forward and reverse crypto operations, only forward would be specified. All operations up to the responder's proxy node would be decryption, all subsequent operations would be encryption. This might have several benefits: o The endpoint, even with no dummy data being sent around, is more difficult to identify. o Intermediate nodes could be given fake responder requests, and return data along the circuit just as the real one does. The real data would be indistinguishable from the fake. This would also further compliate endpoint determination, since all the routers appear to be endpoints. o Looking at it, the real endpoint is no different at all from the fake ones, if fake endpoint requests are sent to all routers. The initiator would need to include a connection id for each router, so the correct data could be indentified. Some drawbacks: o The initiator must receive all the fake data as well as the real. (this might also be a feature) o Generating fake requests may not be easy (at least to always be believable). What gets sent _to_ the fake connections as "data"? (for HTTP, what URL do you ask for?) o This may not work very well (or not any better anyway) for anything other than HTTP, NNTP, or similar. (I can't see this working well for telnet) o Other as-yet-unforseen things I'm too tired to think of. Responses and flames please :-) Jeremey. - -- =-----------------------------------------------------------------------= Jeremey Barrett VeriWeb Internet Corp. Crypto, Ecash, Commerce Systems http://www.veriweb.com/ PGP Key fingerprint = 3B 42 1E D4 4B 17 0D 80 DC 59 6F 59 04 C3 83 64 =-----------------------------------------------------------------------= -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMyOJTy/fy+vkqMxNAQFs3gP9GkH3OZMp5RTHUvPTaDO62WChgyxs7Hgd WCfBILuMZkdH6Wx+/YYTNqFflnMr0J8eQ8r6d3i/hct0b0Zdjs2p2txXPL3vwSdF ncf5NhUcOnFJh8JucjKtblzuP5E1xSdBC49afIg4HL4kHiUxEr2xAaUkLRlFvmac ADCVb1GKoYA= =CDew -----END PGP SIGNATURE----- From majordom Mon Mar 10 11:14:16 1997 Return-Path: Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA20199; Mon, 10 Mar 97 11:14:16 EST Received: from golem.itd.nrl.navy.mil by itd.nrl.navy.mil (4.1/SMI-4.1) id AA20170; Mon, 10 Mar 97 11:13:54 EST Received: (from goldschl@localhost) by golem.itd.nrl.navy.mil (8.8.5/8.7.3) id LAA01552; Mon, 10 Mar 1997 11:13:48 -0500 (EST) Date: Mon, 10 Mar 1997 11:13:48 -0500 (EST) Message-Id: <199703101613.LAA01552@golem.itd.nrl.navy.mil> From: David Goldschlag To: onions@itd.nrl.navy.mil Cc: jeremey@veriweb.com In-Reply-To: <33238945.54014F73@veriweb.com> (message from Jeremey Barrett on Mon, 10 Mar 1997 04:08:37 +0000) Subject: Re: Onion routing: thoughts Sender: owner-onions@itd.nrl.navy.mil Precedence: bulk Thanks for your summary. Here is our position about onion routing. Onion routing provides four mechanisms: (1) Mechanisms for maintaining the topology of the network. (2) Onion routers that support anonymous connections that reliably carry data bidirectionally between some first onion router and some last onion router. (3) An onion creation mechanism that defines and creates the anonymous connection. (4) Interfaces between the anonymous connections and other applications. We currently provide application level proxies for HTTP, SMTP, and RLOGIN, and anonymizing versions of those proxies. Other interfaces may collect data at the IP level. Currently, our onion creation mechanism lives on the first onion router, but it does not need to. There are trade-offs associated with the location of that mechanism. There are three ways to add extra data into the onion routing network. Onion routers do not pad data in an anonymous connection. That can be done outside the system. Onion routers do not introduce extra anonymous connections to confuse traffic analysis. That too can be done outside the system. Our implementation of onion routing does define a padding cell that can carry dummy traffic between two onion routers. Our onion routers do not produce such cells, but do ignore such cells. Our position on padding is that constant utilization of an onion routing network may not be necessary to complicate traffic analysis. We still have to validate this hypothesis. If constant utilization is necessary, the system will not scale well, will use network resources inefficiently, and will not be widely adopted. It may be necessary to smooth out utilization through the three padding approaches described above, and onion routing provides an infrastructure within which these questions can be answered and solutions explored. Our goal is not pretty good onion routers. Our goal is a communications infrastructure that is resistant to traffic analysis, that can efficiently deliver traffic throughout the network, and that will be widely deployed. David. From majordom Mon Mar 10 15:40:18 1997 Return-Path: Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA04398; Mon, 10 Mar 97 15:40:18 EST Received: from banana-jr.itd.nrl.navy.mil by itd.nrl.navy.mil (4.1/SMI-4.1) id AA04382; Mon, 10 Mar 97 15:40:08 EST Date: Mon, 10 Mar 1997 15:40:14 -0500 (EST) From: "Michael G. Reed" To: onions@itd.nrl.navy.mil Subject: Re: Logging... In-Reply-To: <3.0.32.19970309150344.006f0624@netcom9.netcom.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-onions@itd.nrl.navy.mil Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- NOTE: Cc's trimmed since the onions mailing lists contained all the people addressed initially. On Sun, 9 Mar 1997, Lucky Green wrote: |>When are you going to make the source available? I have talked with a |>number of folks that are interested in running (improved) onion routers. The source will be made available when we can make it available. The first cut of tests will be with binary only distribution and these tests are SOLELY for the purpose of getting some hard numbers on the performance of the system and identifying some of the bottlenecks -- there is only so much I can do in my lab, and only so many people have $25k machines at their disposal to run tests...we need some real-world numbers on real-world systems, on the real-world Internet. The system, as it is written today, will most likely undergo some major structural changes (some are already planned, some more will probably become evident once we get some more numbers on system performance) in the weeks to come and it is far to premature to distribute source widely. |>[We discussed Onion Routers, Pipe-Net, and Raph Levien's new proposal at |>yesterday's monthly Cypherpunks meeting. I am cc'ing some of the |>participants.] Which cypherpunks meeting are you referring to? DC? Bay Area? Where? We would be interested in hearing those discussions and participating in the future if possible...the more feedback we can get, the better the system will be. |>>We are essentially doing real-time mixing, under the hypothesis that |>>if there is sufficient traffic, one does not need to delay traffic |>>very much to do good mixing, nor does one need to add padding. |> |>I believe this hypothesis can not be safely made. Traffic patterns vary |>widely, depending on the time of day and other factors. The attacker |>doesn't need much correlation to conduct traffic analysis. This is true, but this also assumes that said attacker has sniffers at the entry to *EVERY* onion-router on the internet...miss only one and you have a problem. We are not suggesting that padding is not necessary. Certainly, there will be times (lots of times) we need to pad data. *BUT* just throwing padding at the problem does *NOT* solve it (this has been shown). |>The system should be secure from traffic analysis even when there are only |>two users on the network. This can be achieved by moving the first proxy on |>the user's machine and keeping the data streams constant within each |>segment of the network. Keeping data streams constant on the Internet is infeasible unless they are of such pathetically low bandwidth as to make them unusable. Simply put, at the layer of the network stack we are operating at, and given the current congestion on the major backbones (including packet loss), I think it is a pipe-dream (pardon the pun) to think you will be able to hit constant (full) bandwidth with padding. In terms of moving the onion creation to the local machine, that is possible (and even defined) in our system. As a matter of fact, that is one of the fundamental shifts that we are looking at making in the system, and it is documented in some detail in the papers. |>One question may be what to do if the load saturates the pipe. If that |>happens, you can add delays. As long as the last proxy is on the user's |>machine, these artificial delays won't create a traffic analysis opportunity. Ah, but *WHERE* do the delays appear? Anywhere down the length of the circuit for which you have no information about utilization and therefore you much rely on the system to throttle you down...the problem does not go away simply by moving the last hop. |>>If the first onion router in an anonymous connection is compromised, |>>then everything is revealed, since (in our current model) the first |>>onion router knows both endpoints of a connection. |> |>No router should ever know more than the previous and the next router. |>Except of course the "router" sitting on the user's machine, which would |>simply be a client side HTTP proxy. Yes, and in the topology you just described, the "router" on the user's machine is the first onion-router, thus only it knows the whole path. - -Michael -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMyRxs08Qx019l0ClAQEDuQP+JO/z0X09htcPTYAfbbZgXv1evH2QbzyU BsESObmrczv5VpuyIPiOzDwgsrX6GXc9aRM3gPyktU8VqOFn9ggBSW7S/2MfRSXE bP7JWtM80ese3vJjIiJuoNf1hZySoiNe1sG1StXDRw6wxdtzuwGNZ339nLm3j14O N3BBD7JJrf0= =A/Mi -----END PGP SIGNATURE----- From majordom Mon Mar 10 15:56:31 1997 Return-Path: Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA05166; Mon, 10 Mar 97 15:56:31 EST Received: from banana-jr.itd.nrl.navy.mil by itd.nrl.navy.mil (4.1/SMI-4.1) id AA05160; Mon, 10 Mar 97 15:56:22 EST Date: Mon, 10 Mar 1997 15:56:32 -0500 (EST) From: "Michael G. Reed" To: onions@itd.nrl.navy.mil Subject: Re: Onion routing: thoughts In-Reply-To: <33238945.54014F73@veriweb.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-onions@itd.nrl.navy.mil Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- On Mon, 10 Mar 1997, Jeremey Barrett wrote: |> o The assumption that usage will be constant and high may not be not |> valid This is true. We really do not know what the demand will be yet for the service, but if you look at how overloaded the Anonymizer is most of the time, I think we can assume it will be moderate at the least. |> o Traffic analysis in a non-optimal (i.e. not evenly utilized all |> the time) net will not be difficult (just follow the packets) |> The solution to this seems to be constant utilization by simply |> sending data all the time, real or not. As I said before, simple padding does not solve the problem. The onion routers themselves know what is pad and what is not (unless you create dummy connection and pad through the connections in which case the first and last onion router knows it pad but not the intermediates and this doesn't solve the link-level padding problem). |> o Timing attacks are effective during low-use of the net, even if |> the net is saturated with fake data. (If a manageable number of |> routers exist. Large numbers make this more difficult). |> |> One possible solution to this would be the initiator sending |> a bunch of fake onions around, so that the endpoint cannot |> easily be indentified. Unfortunately, this might involve _alot_ |> of fake onions. However, as the usage of the net increased, the |> number of fakes required would decrease. Simply having more endpoints to the system does not increase the difficulty to track coincidences...you need data moving into and out of the overall network to make it more difficult. Either dummy services, or just meaningless requests on pre-defined protocols. |> o Some information may be obtained by denial of service attacks at |> particular points. Depending on the number of connections at the |> moment, etc, it may be possible to induce a traceable chain of |> "destroy" messages. This again argues for constant data streams |> between routers. The "Destroy flurry" that we describe when a thick-pipe goes down is a problem, but it's one that we haven't been able to come up with a good solution for. We have a couple of possibilities (including delaying the destruction of the circuits that went through that thick pipe and dropping them at random intervals thereafter), but are still looking at that. |> All in all, I think a "Pretty Good Onion Router" is a good idea. |> I would love to be able to hit web sites without them knowing |> where I'm coming from, where the performance is good and I'm fairly |> secure in the knowledge that only someone really determined and |> skilled could trace me, if at all. So my suggestion is that once |> a "Pretty Good Onion Router" system is in place, then we focus on |> making it as bulletproof as possible. While "Pretty Good" might be good enough for some, we are really looking to get this right, get a RFC out there, and get this thing deployed world-wide as soon as possible. That doesn't allow for "Pretty Good". It means we do some experimenting now, draw on the best and brightest that are available, and get input from people during this initial period to DO IT RIGHT THE FIRST TIME. Of course this means it won't be out next week, but I think the general population would prefer something that works the first time than an evolution of shoddy systems that really were never right. |> Have "boomerang" (my term, dunno if a real one exists) routes |> been considered? A boomerang route would be forward-only. i.e. |> rather than an onion containing the responder's proxy node as the |> endpoint, it would contain itself. Then the onion would describe |> a forward-only path from a router back to itself. The responder's |> proxy node would get a slightly different packet, identifying |> it as "the" node. Rather than specify both forward and reverse |> crypto operations, only forward would be specified. All operations |> up to the responder's proxy node would be decryption, all subsequent |> operations would be encryption. I'm not sure I follow this completely (or what the motivation is for it completely), can you elaborate some more on it? Thanks! - -Michael -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMyR1g08Qx019l0ClAQFudAQApnaTxMg9h23v8VWk06QBlq6D0oa1i/xK fITKJUZuRs+WVDZMhhCVouEDggsBZL4o6yQ15TMbnCDx9rpi+LIA7CZom3UtZf7T pi1/1o9WPI9Q++EnRA1x+xkoVaKiXhMTR0e+8Ic0L/mzOjK+/y+2nXVDeiUJaJXR pf4vnaOBRuQ= =D7Gv -----END PGP SIGNATURE----- From majordom Mon Mar 10 16:55:22 1997 Return-Path: Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA08201; Mon, 10 Mar 97 16:55:22 EST Received: from golem.itd.nrl.navy.mil by itd.nrl.navy.mil (4.1/SMI-4.1) id AA08189; Mon, 10 Mar 97 16:55:14 EST Received: (from goldschl@localhost) by golem.itd.nrl.navy.mil (8.8.5/8.7.3) id QAA01659; Mon, 10 Mar 1997 16:55:09 -0500 (EST) Date: Mon, 10 Mar 1997 16:55:09 -0500 (EST) Message-Id: <199703102155.QAA01659@golem.itd.nrl.navy.mil> From: David Goldschlag To: onions@itd.nrl.navy.mil Subject: discussion points Sender: owner-onions@itd.nrl.navy.mil Precedence: bulk Hi, We are planning to release code this week for testing. Testsers have to agree not to redistribute code. Soon we hope to put the code on a site that will re-distribute within the US. It would be useful to start a discussion about what we are trying to hide and what may do that hiding. I'm looking for communication models, attack models, carefully stated requirements, and justified solutions. For example, precisely what do we by "assume only a single uncompromised onion router?" As another example, if two sites connect (encrypted) to remote onion routers at roughly the same time, it is more likely that they are communicating than if they didn't connect at roughly the same time. This is hard to protect against. Do we need constant utilization or is smoothing sufficient? Do we want to add noice to individual connections? Do we want terminal onion router to terminal onion router padding (noise connections)? Do we want padding between neighboring onion routers? I'm looking to leverage off the expertise in this list, so we can build strong hiding around the onion routing infrastructure. Thanks, David. From majordom Mon Mar 10 17:05:15 1997 Return-Path: Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA08718; Mon, 10 Mar 97 17:05:15 EST Received: from einstein.veriweb.com by itd.nrl.navy.mil (4.1/SMI-4.1) id AA08680; Mon, 10 Mar 97 17:05:02 EST Received: (from jeremey@localhost) by einstein.veriweb.com (8.8.5/8.6.9) id OAA10237; Mon, 10 Mar 1997 14:08:35 -0800 Message-Id: <3324865F.1512DC9A@veriweb.com> Date: Mon, 10 Mar 1997 22:08:31 +0000 From: Jeremey Barrett Organization: VeriWeb Internet Corp. X-Mailer: Mozilla 3.01 (X11; U; Linux 2.0.11 i586) To: "Michael G. Reed" Cc: onions@itd.nrl.navy.mil Subject: Re: Onion routing: thoughts References: Sender: owner-onions@itd.nrl.navy.mil Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Michael G. Reed wrote: > > |> o Timing attacks are effective during low-use of the net, even if > |> the net is saturated with fake data. (If a manageable number of > |> routers exist. Large numbers make this more difficult). > |> > |> One possible solution to this would be the initiator sending > |> a bunch of fake onions around, so that the endpoint cannot > |> easily be indentified. Unfortunately, this might involve _alot_ > |> of fake onions. However, as the usage of the net increased, the > |> number of fakes required would decrease. > > Simply having more endpoints to the system does not increase the > difficulty to track coincidences...you need data moving into and out of > the overall network to make it more difficult. Either dummy services, > or just meaningless requests on pre-defined protocols. I agree. But more endpoints does mean you have to monitor more points of entry/exit to identify coincidences reliably. > > |> All in all, I think a "Pretty Good Onion Router" is a good idea. > |> I would love to be able to hit web sites without them knowing > |> where I'm coming from, where the performance is good and I'm fairly > |> secure in the knowledge that only someone really determined and > |> skilled could trace me, if at all. So my suggestion is that once > |> a "Pretty Good Onion Router" system is in place, then we focus on > |> making it as bulletproof as possible. > > While "Pretty Good" might be good enough for some, we are really > looking to get this right, get a RFC out there, and get this thing > deployed world-wide as soon as possible. That doesn't allow for > "Pretty Good". It means we do some experimenting now, draw on the > best and brightest that are available, and get input from people > during this initial period to DO IT RIGHT THE FIRST TIME. Of course > this means it won't be out next week, but I think the general > population would prefer something that works the first time than an > evolution of shoddy systems that really were never right. I agree completely. I intended "Pretty Good" in the spirit of PGP. There is a danger of trying to solve _too_ much and never getting anything done. That's not to say I think that will happen here. > > |> Have "boomerang" (my term, dunno if a real one exists) routes > |> been considered? A boomerang route would be forward-only. i.e. > |> rather than an onion containing the responder's proxy node as the > |> endpoint, it would contain itself. Then the onion would describe > |> a forward-only path from a router back to itself. The responder's > |> proxy node would get a slightly different packet, identifying > |> it as "the" node. Rather than specify both forward and reverse > |> crypto operations, only forward would be specified. All operations > |> up to the responder's proxy node would be decryption, all > |> subsequent operations would be encryption. > > I'm not sure I follow this completely (or what the motivation is for it > completely), can you elaborate some more on it? Thanks! > Instead of a connection with two endpoints, the idea is a connection with only one (obvious) endpoint. The first router, let's say on the user's machine, creates an onion which identifies a chain of routers such that it (the first router) is the _endpoint_ of the route. Now it sends a "data" message along the route. The router which receives a data message in the clear (after applying the crypto operation) is the one which goes and satisfies the data request. Once the data is retrieved, it applies an outgoing crypto operation and sends the data along the route, still in the forward direction. No messages travel backwards. A simple analogy is a circle as opposed to a line. I can see a few potential advantages here: o The node which actually satisfies the data request cannot be identified simply by being the terminating node of a connection, since the terminating node is the same as the first router. o You can't "follow" packets to one end or the other because they always complete the route back to the sender. o Rather than "destroy" messages in the event a router in the circuit dies, "reroute" messages could be used. The reroute messages would make their way along the circuit, resulting in the first router sending another onion, such that the previous "endpoint", which may have data waiting to send on the route, is still identified as the endpoint. The identity of the "endpoint" router is still not given away. In a point to point route, if destroy messages can be traced, then the endpoint is identified. o This scheme may make sending dummy traffic better/easier. I'm throwing this idea on the table, not necessarily suggesting it's use. I'm not entirely sure what the consequences of it would be, I need to think about it more. The idea is somewhat analagous to nym.alias.net and similar nym servers, where the nym is the "endpoint", the remailer path to the nym is the route up to the "endpoint", and the reply block is the route after the "endpoint". I put "endpoint" in quotes because it is not the actual end of the route. Any thoughts welcome. Jeremey. - -- =-----------------------------------------------------------------------= Jeremey Barrett VeriWeb Internet Corp. Crypto, Ecash, Commerce Systems http://www.veriweb.com/ PGP Key fingerprint = 3B 42 1E D4 4B 17 0D 80 DC 59 6F 59 04 C3 83 64 =-----------------------------------------------------------------------= -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMySGYi/fy+vkqMxNAQFSGgQAja2167/+biJTY4AphGhTK4IunI7GJvmQ S7wJrxQD6z/W9kaDK105xLwkdx7WyHUol6NycU6CZlL5PeCFpcOr9q9CI1j6IUOE kX1RnO46o7lAaAi+sdKbesJoZbx1/8nWs9AoobKfk7+Kz26VUPWRo492BYYKRrf5 pz2TjasgBF8= =FRIa -----END PGP SIGNATURE----- From majordom Mon Mar 10 17:16:00 1997 Return-Path: Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA09228; Mon, 10 Mar 97 17:16:00 EST Received: from einstein.veriweb.com by itd.nrl.navy.mil (4.1/SMI-4.1) id AA09222; Mon, 10 Mar 97 17:15:53 EST Received: (from jeremey@localhost) by einstein.veriweb.com (8.8.5/8.6.9) id OAA10255; Mon, 10 Mar 1997 14:19:24 -0800 Message-Id: <332488E9.69573EE3@veriweb.com> Date: Mon, 10 Mar 1997 22:19:21 +0000 From: Jeremey Barrett Organization: VeriWeb Internet Corp. X-Mailer: Mozilla 3.01 (X11; U; Linux 2.0.11 i586) To: "Michael G. Reed" Cc: onions@itd.nrl.navy.mil Subject: Re: Onion routing: thoughts References: Sender: owner-onions@itd.nrl.navy.mil Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Michael G. Reed wrote: > > I'm not sure I follow this completely (or what the motivation is for it > completely), can you elaborate some more on it? Thanks! > I don't think my last explanation was so clear either. Simply put: the return path from responder to initiator need not be the same as the path from initiator to responder. Probably the best way to do this is for the initiator to identify himself as the endpoint in the onion he sends around. Jeremey. - -- =-----------------------------------------------------------------------= Jeremey Barrett VeriWeb Internet Corp. Crypto, Ecash, Commerce Systems http://www.veriweb.com/ PGP Key fingerprint = 3B 42 1E D4 4B 17 0D 80 DC 59 6F 59 04 C3 83 64 =-----------------------------------------------------------------------= -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMySI6y/fy+vkqMxNAQEH7gP/ZfvoJ3jaASrIggKTAptVCYFU/r0fBU/K 6YmX0AqVjNWJdeiv+xmonnhNCVnjdSvdV1Rmi1rSz6syQ6O/Z/mWTerBV5/tMMzW tcz6YDQ+f6M7I5ZB2Ck2EyOubIeP9pguMPvsKu17dee/1V0zN9CkZqdAPkNGnsaa nB+Q+PNbY/4= =MgJ+ -----END PGP SIGNATURE----- From majordom Mon Mar 10 17:38:36 1997 Return-Path: Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA10100; Mon, 10 Mar 97 17:38:36 EST Received: from carnap.itd.nrl.navy.mil by itd.nrl.navy.mil (4.1/SMI-4.1) id AA10094; Mon, 10 Mar 97 17:38:30 EST From: syverson@itd.nrl.navy.mil (Paul Syverson) Received: (from syverson@localhost) by carnap.itd.nrl.navy.mil (8.8.5/8.7.3) id RAA09625; Mon, 10 Mar 1997 17:38:28 -0500 (EST) Date: Mon, 10 Mar 1997 17:38:28 -0500 (EST) Message-Id: <199703102238.RAA09625@carnap.itd.nrl.navy.mil> To: jeremey@veriweb.com Subject: Re: Onion routing: thoughts Cc: onions@itd.nrl.navy.mil X-Sun-Charset: US-ASCII Sender: owner-onions@itd.nrl.navy.mil Precedence: bulk > > I don't think my last explanation was so clear either. Simply put: the > return path from responder to initiator need not be the same as the > path from initiator to responder. Probably the best way to do this is > for the initiator to identify himself as the endpoint in the onion > he sends around. > That's one possibility. Another that is mentioned in some of our papers but won't appear on the first code release is a reply onion. Basically, this is an onion that the initiator can send to a particular responder (or broadcast or multicast it from the far end of an onion route, or even post anonymously). It identifies the first node to which it should be sent and, when used, creates an anonymous connection back to the initiator. Once the connection is established, it is as if the initiator had created it (in terms of how data is processed). The advantage here is that the initiator need not identify himself to give the responder a different route back to himself. And, he need not trust the responder to protect the anonymity of that route. We have mostly considered this from the perspective of allowing, e.g., replies to email, especially after the initial connection is gone. Or, allowing replies to anonymously posted requests. You raise an interesting idea that I don't recall previously discussing with my colleagues: viz using a reply onion in the context of the connection through which it was sent. aloha, Paul From majordom Mon Mar 10 19:07:55 1997 Return-Path: Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA12338; Mon, 10 Mar 97 19:07:55 EST Received: from banana-jr.itd.nrl.navy.mil by itd.nrl.navy.mil (4.1/SMI-4.1) id AA12332; Mon, 10 Mar 97 19:07:48 EST Date: Mon, 10 Mar 1997 19:07:54 -0500 (EST) From: "Michael G. Reed" To: onions@itd.nrl.navy.mil Subject: Re: Onion routing: thoughts In-Reply-To: <199703102238.RAA09625@carnap.itd.nrl.navy.mil> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-onions@itd.nrl.navy.mil Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- On Mon, 10 Mar 1997, Paul Syverson wrote: |>> I don't think my last explanation was so clear either. Simply put: the |>> return path from responder to initiator need not be the same as the |>> path from initiator to responder. Probably the best way to do this is |>> for the initiator to identify himself as the endpoint in the onion |>> he sends around. |>> |>That's one possibility. Another that is mentioned in some of our papers |>but won't appear on the first code release is a reply onion. |>Basically, this is an onion that the initiator can send to a particular |>responder (or broadcast or multicast it from the far end of an onion |>route, or even post anonymously). It identifies the first node to which |>it should be sent and, when used, creates an anonymous connection back |>to the initiator. Once the connection is established, it is as if the |>initiator had created it (in terms of how data is processed). The |>advantage here is that the initiator need not identify himself to give |>the responder a different route back to himself. And, he need not |>trust the responder to protect the anonymity of that route. We have |>mostly considered this from the perspective of allowing, e.g., replies |>to email, especially after the initial connection is gone. Or, |>allowing replies to anonymously posted requests. You raise an |>interesting idea that I don't recall previously discussing with my |>colleagues: viz using a reply onion in the context of the connection |>through which it was sent. Actually, we did entertain the possibility of asymmetric routes at one time but discarded them for a couple of reasons: 1) In your earlier argument, you said something to the effect "each onion router decrypts his layer and the onion-router that gets plaintext knows he has to respond" -- PROBLEM. How do you know you have plaintext? Imbedded CRC or Hash in each DATA cell? This is a *LOT* of overhead, (cell data payload is 44 bytes -- to accommodate ATM, we would need to decrease this for every byte of hash stored...not the kind of tradeoff I really want to make right now), and potentially buys you nothing (there is the finite chance that a still encrypted cell could hash correctly and match causing an onion router to mis-think he's the recipient...small, but possible chance). This actually came up when we considered how to send in-band commands within DATA cells to control intermediate onion routers. The idea was shot down since we could figure out how to do it without adding another cell type (which we didn't want to do since it would expose information and be trackable by onion-routers along the route). 2) Crypto Overhead. Remember, we're think real-time, or near real-time applications here. We already spend a staggering amount of time on our RSA operations...this is still true even with hand coded assembly implementations for the V9 UltraSparc architecture and running it on dual processor Ultra2 machines...Five RSA encrypt operations is already a major burden, but ten would probably be unbearable...if this is only for padding/garbage data and is not done too frequently, it would be acceptable, but for every connection, I think it would kill us via the crypto overhead. Now if we move to hardware for the crypto, or if the pentium assembly version proves to be faster (we think it should be on a comparable MHz machine, but have yet to try to port this to Solaris x86), this may no longer be the case. 3) The longer the chain, the higher the probability that any one "thick pipe" going down will kill your connection. Plus, you start to run into the possibility of going through a think pipe multiple times REALLY killing overall system bandwidth by just bouncing back and forth. I'm not saying 5 hops is the magic number (really, I don't even remember how we came up with 5 in the current implementation, but it seemed like a good count at the time), but I would be *VERY* surprised if anyone suggested less than 5 hops, and many more doesn't seem to buy you that much. Remember, you only need to trust that ONE onion router out there in the world that you route through is behaving to have a secure connection (that and, of course, the first node being uncompromised). If you can't trust 40% on the onion routers in the world (really 20% if you don't include your first hop which you must trust with your life :-), then we have a larger problem to deal with. I'm not degrading the idea, it has some interesting applications that the system could probably use...these were just the reasons we shot it down before in our discussions...if I've missed anything (or there is a good counter argument), please clue me in :-) This is the kind of discussions we're hope to happen -- ones that open doors that we missed, or shed some light to you all as to why we made some of our design decisions. Thanks! - -Michael -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMySiX08Qx019l0ClAQE2BAP/W+cTwtA1M7xmyzCi6Iytx59oPPInN2jb AH/oall/0NMoOFEivMG7lCroEu/flOmOH4WUx7mTdtVVsVrR+l9+uqHgngT9UB+z P2OKLSJxGFZeEbXOgVf3SNTwa8+8XO//yjp7fhNcpyNiI+RsA7cwcyEUVSEDjmCl az05sCe/MpU= =/9PH -----END PGP SIGNATURE----- From majordom Mon Mar 10 21:04:48 1997 Return-Path: Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA14634; Mon, 10 Mar 97 21:04:48 EST Received: from mail.eskimo.com by itd.nrl.navy.mil (4.1/SMI-4.1) id AA14628; Mon, 10 Mar 97 21:04:39 EST Received: from eskimo.com (eskimo.com [204.122.16.13]) by mail.eskimo.com (8.7.6/8.6.12) with SMTP id SAA05083 for ; Mon, 10 Mar 1997 18:04:27 -0800 (PST) Date: Mon, 10 Mar 1997 18:03:26 -0800 (PST) From: Wei Dai To: onions@itd.nrl.navy.mil Subject: Re: Onion routing: thoughts In-Reply-To: <199703101613.LAA01552@golem.itd.nrl.navy.mil> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-onions@itd.nrl.navy.mil Precedence: bulk On Mon, 10 Mar 1997, David Goldschlag wrote: > Our position on padding is that constant utilization of an onion > routing network may not be necessary to complicate traffic analysis. > We still have to validate this hypothesis. If constant utilization is > necessary, the system will not scale well, will use network resources > inefficiently, and will not be widely adopted. I think it should be easy to show that constant utilization is necessary. It is the case for Chaum's Mix-Net (see http://www.eskimo.com/~weidai/traffic.txt), and Onion Routing seems closely related. I am convinced that anonymous routing cannot be relatively efficient. Indeed it may be worse than you expect - to defend against certain active attacks (that introduce errors into the network and analyze their propagation and correction) it may be necessary to propagate errors throughout the network so that local errors are made global. > Our goal is not pretty good onion routers. Our goal is a > communications infrastructure that is resistant to traffic analysis, > that can efficiently deliver traffic throughout the network, and that > will be widely deployed. Since you are so serious about getting it right the first time, I think a formal proof of security for your protocol would be extremely helpful. It could be done, perhaps, by following the approaches of David Chaum (for DC-Net) and Dan Simon (for Mix-Net). The proof for Onion Routing may be much more difficult, but it would be especially useful considering the large range of possible attacks and the ease of overlooking a protocol flaw. Whether or not an anonymous routing system will be widely deployed is not simply a technical issue. I think it also depends on political realities and economic incentives. I am glad (but also very curious) that the Navy should show so much interest in it. Certainly it improves the chances quite a bit. Wei Dai From majordom Tue Mar 11 02:43:55 1997 Return-Path: Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA20833; Tue, 11 Mar 97 02:43:55 EST Received: from freya.cs.umass.edu by itd.nrl.navy.mil (4.1/SMI-4.1) id AA20827; Tue, 11 Mar 97 02:43:45 EST Received: from opine.cs.umass.edu (opine.cs.umass.edu [128.119.41.246]) by freya.cs.umass.edu (8.7.6/8.6.9) with SMTP id CAA27693 for ; Tue, 11 Mar 1997 02:43:44 -0500 Message-Id: <33250D30.167E@cs.umass.edu> Date: Tue, 11 Mar 1997 02:43:44 -0500 From: Lewis McCarthy Organization: Theoretical Computer Science Group, UMass-Amherst, X-Mailer: Mozilla 3.01Gold (X11; U; OSF1 V3.2 alpha) Mime-Version: 1.0 To: Onion Routing Mailing List Subject: Re: Onion routing: thoughts References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-onions@itd.nrl.navy.mil Precedence: bulk Wei Dai writes: > I am convinced that anonymous routing cannot be relatively efficient. > Indeed it may be worse than you expect - to defend against certain > active attacks (that introduce errors into the network and analyze > their propagation and correction) it may be necessary to propagate > errors throughout the network so that local errors are made global. In the general case, I suspect this is true. One general type of tactic of an active traffic analyst is to cause some parts of the anonymizing network to offer different service quality than others for a spell, and deduce information from the results. Any active attacker worth its salt can always degrade service quality somewhere in the anon-net. So any successful defensive attempt to balance the service quality across all the nodes must involve adjusting some nodes' service quality downwards to meet the current minimum level. In the worst case a node somewhere has crashed (i.e. suspended service for a long time period relative to the usual delivery interval), in which case it seems that the entire anon-net needs to grind to a halt temporarily. (Some out-of-band mechanism must communicate updated local service quality information reliably and quickly.) As the anon-net scales up, the mean-time-to-mandated-temporary-failure of the whole anon-net soars, assuming independent node failures. Experience with the Mixmaster network, at least, suggests that the mean-time-to-failure of a single node may be surprisingly short in practice. [...] > by following the approaches of David Chaum (for DC-Net) > and Dan Simon (for Mix-Net). [...] Can you give pointers to Dan Simon's work regarding MIXes? I didn't realize he had looked at this. -- Lewis http://www.cs.umass.edu/~lmccarth/lmkey.asc Onion recipes: http://www.plntationprod.com/Documents/recipe.html From majordom Tue Mar 11 16:47:26 1997 Return-Path: Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA27366; Tue, 11 Mar 97 16:47:26 EST Received: from einstein.veriweb.com by itd.nrl.navy.mil (4.1/SMI-4.1) id AA27358; Tue, 11 Mar 97 16:47:15 EST Received: (from jeremey@localhost) by einstein.veriweb.com (8.8.5/8.6.9) id NAA10929; Tue, 11 Mar 1997 13:50:49 -0800 Message-Id: <3325D3B6.10ED6A29@veriweb.com> Date: Tue, 11 Mar 1997 21:50:46 +0000 From: Jeremey Barrett Organization: VeriWeb Internet Corp. X-Mailer: Mozilla 3.01 (X11; U; Linux 2.0.11 i586) To: "Michael G. Reed" Cc: onions@itd.nrl.navy.mil Subject: [LONG] Re: Asymmetric routes References: Sender: owner-onions@itd.nrl.navy.mil Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Michael G. Reed writes: > Actually, we did entertain the possibility of asymmetric routes at one > time but discarded them for a couple of reasons: > > 1) In your earlier argument, you said something to the effect "each > onion router decrypts his layer and the onion-router that gets > plaintext knows he has to respond" -- PROBLEM. How do you know you > have plaintext? For one, you know you are the responder. So on any given route, if you're the responder, then you must have plaintext. Alternatively, one bit in the data itself would do. > Imbedded CRC or Hash in each DATA cell? This is a > *LOT* of overhead, (cell data payload is 44 bytes -- to accommodate > ATM, we would need to decrease this for every byte of hash > stored...not the kind of tradeoff I really want to make right now), > and potentially buys you nothing (there is the finite chance that a > still encrypted cell could hash correctly and match causing an onion > router to mis-think he's the recipient...small, but possible chance). > This actually came up when we considered how to send in-band commands > within DATA cells to control intermediate onion routers. The idea was > shot down since we could figure out how to do it without adding > another cell type (which we didn't want to do since it would expose > information and be trackable by onion-routers along the route). If a small header is prepended to the data and then treated as data in crypto operations, no information should be leaked. Certainly a hash or CRC just to figure out if you have plaintext would be bad and wasteful. Perhaps I'm missing something though. Here's what I've got in my head at the moment. Please point out flaws. I'm not sure myself that this is useful. It may only be interesting. :-) o Initiator creates a circular route back to himself by sending a simple onion (no "reply" onion as such) which traces a route back to himself. No other router is aware of being the responder. o Data messages look like this: ----------------- | HDR | DATAMSG | ----------------- Where HDR is the "visible" header (routers use this to identify the message as "data". DATAMSG looks like this: ------------------ | DATAHDR | DATA | ------------------ Where DATAHDR is 1 byte or so. Basically just bits set or not set. One of the bits is the plaintext bit. Another would be the ignore bit. Maybe other stuff. o The initiator choose one of the routers on the circuit as the responder. The initiator applies crypto operations to the data message to send such that the chosen responder gets plaintext. Included with the first data message is a set of crypto operations for the chosen responder to apply to any data it sends along the route. (or perhaps that is the only data in the first data message). o Using 2 intermediate hops (not including initiator or responder), data messages look like this: -------------------------------------------- | HDR | DATAHDR | DATAHDR | DATAHDR | DATA | -------------------------------------------- Since the initiator has applied 3 crypto operations to the final DATAHDR and DATA, neither intermediate router knows who has the plaintext. And the initiator has applied 2 crypto operations to the second DATAHDR, so the first intermediate router doesn't know what the second has either. Both the first and second DATAHDR fields are 0 (or at least the plaintext bit and ignore bits are not set). The third DATAHDR has the plaintext bit set. Again, this is just an onion with layers being peeled off (but no RSA). Padding could be added to make it difficult to deduce the number of hops. o When the responder gets the data message, it applies the normal crypto operation and obtains plaintext. The responder immediately passes the same data message along the rest of the route by applying the "reply-block" crypto operations in succession, and creating the necessary DATAHDR fields (which involves applying the correct number of crypto operations to them as well). In the DATAHDR which will reach the initiator, the plaintext _and_ ignore bits are set. The only knowledge the responder gains is the length of the return route. o The initiator gets the same data message it sent to the responder, but now with both plaintext and ignore bits set. It discards and does not forward the message. o When the responder has data ready to send to the initiator, it constructs DATAHDR's again, but with the plaintext bit and _not_ the ignore bit set (in the last DATAHDR). o Much the same process repeats, but the responder is now acting like the initiator. The initiator gets the response data, and gives it to the application or whoever. It also sets the ignore bit and sends the data back to the responder, who discards it. In this way, all messages always complete the circuit, making the responder difficult to identify. In fact, it is difficult to distinguish a response from a request (I realize these terms are more applicable to HTTP-like protocols than things like telnet). The same route can be reused, even with different responders. > > 2) Crypto Overhead. Remember, we're think real-time, or near > real-time applications here. We already spend a staggering amount of > time on our RSA operations...this is still true even with hand coded > assembly implementations for the V9 UltraSparc architecture and > running it on dual processor Ultra2 machines...Five RSA encrypt > operations is already a major burden, but ten would probably be > unbearable...if this is only for padding/garbage data and is not done > too frequently, it would be acceptable, but for every connection, I > think it would kill us via the crypto overhead. Now if we move to > hardware for the crypto, or if the pentium assembly version proves to > be faster (we think it should be on a comparable MHz machine, but have > yet to try to port this to Solaris x86), this may no longer be the > case. Yes, double the RSA operations is a problem. If routes can be reused significantly, this is less of a problem. > > 3) The longer the chain, the higher the probability that any one > "thick pipe" going down will kill your connection. Plus, you start to > run into the possibility of going through a think pipe multiple times > REALLY killing overall system bandwidth by just bouncing back and > forth. I'm not saying 5 hops is the magic number (really, I don't > even remember how we came up with 5 in the current implementation, but > it seemed like a good count at the time), but I would be *VERY* > surprised if anyone suggested less than 5 hops, and many more doesn't > seem to buy you that much. Remember, you only need to trust that ONE > onion router out there in the world that you route through is behaving > to have a secure connection (that and, of course, the first node being > uncompromised). If you can't trust 40% on the onion routers in the > world (really 20% if you don't include your first hop which you must > trust with your life :-), then we have a larger problem to deal with. > The longer the route, the more potential it will fail. That is always going to be the case. Breaks in the chain can be rerouted around so that no data is lost (if the mechanisms are in place. i.e. the initiator would need to send a connection identifier as part of the data to the responder. Then the same identifier could be used to replace the route with another). For remailers, I rarely use more than 3 hops. I'm not sure what the magic number is for onion routers, but 5 seems reasonable. Jeremey. - -- =-----------------------------------------------------------------------= Jeremey Barrett VeriWeb Internet Corp. Crypto, Ecash, Commerce Systems http://www.veriweb.com/ PGP Key fingerprint = 3B 42 1E D4 4B 17 0D 80 DC 59 6F 59 04 C3 83 64 =-----------------------------------------------------------------------= -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMyXTuC/fy+vkqMxNAQHM3QQAhL80OEO0oSGLMcjRMBuiOfRYxefmxZ9f 9LoE9gC7GyQkaE9RL5ikmPpZjJgR8+3ydHZGu9skfSFBltL2rDLk6eK0iv9p8IGB 97oO4JuX/jMAa7epY/wfWl0MjfUoqcIK4hUFEaGCYcTiZiBvlm+P7l+i8qAYwgst v3N2vUvU2G8= =ORQz -----END PGP SIGNATURE----- From majordom Tue Mar 11 19:02:25 1997 Return-Path: Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA02225; Tue, 11 Mar 97 19:02:25 EST Received: from freya.cs.umass.edu by itd.nrl.navy.mil (4.1/SMI-4.1) id AA02219; Tue, 11 Mar 97 19:02:18 EST Received: from opine.cs.umass.edu (opine.cs.umass.edu [128.119.41.246]) by freya.cs.umass.edu (8.7.6/8.6.9) with SMTP id TAA24274 for ; Tue, 11 Mar 1997 19:02:17 -0500 Message-Id: <3325F288.31DF@cs.umass.edu> Date: Tue, 11 Mar 1997 19:02:16 -0500 From: Lewis McCarthy Organization: Theoretical Computer Science Group, UMass-Amherst, X-Mailer: Mozilla 3.01Gold (X11; U; OSF1 V3.2 alpha) Mime-Version: 1.0 To: Onion Routing Mailing List Subject: Simon et al.'s work on anonymous networks Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-onions@itd.nrl.navy.mil Precedence: bulk Answering my own question, I noticed Dan Simon's Crypto `96 paper "Anonymous Communication and Anonymous Cash", which concentrates on the latter topic. It includes a reference to a STOC `93 paper by Rackoff & Simon: "Cryptographic Defense Against Traffic Analysis". -- Lewis http://www.cs.umass.edu/~lmccarth/lmkey.asc "Overwhelmed by 21 documents? Let LiveTopics guide you!" --AltaVista From majordom Wed Mar 12 04:40:26 1997 Return-Path: Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA11927; Wed, 12 Mar 97 04:40:26 EST Received: from ccnet4.ccnet.com by itd.nrl.navy.mil (4.1/SMI-4.1) id AA11920; Wed, 12 Mar 97 04:40:17 EST Received: from sfbayarea.ccnet.com (h108-14-139.ccnet.com [199.108.14.139]) by ccnet4.ccnet.com (8.7.1/8.6.12) with SMTP id BAA28696 for ; Wed, 12 Mar 1997 01:41:26 -0800 (PST) Message-Id: <3.0.32.19970312014106.007053dc@netcom9.netcom.com> X-Sender: shamrock@netcom9.netcom.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 12 Mar 1997 01:41:28 -0800 To: onions@itd.nrl.navy.mil From: Lucky Green Subject: Re: discussion points Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-onions@itd.nrl.navy.mil Precedence: bulk At 04:55 PM 3/10/97 -0500, David Goldschlag wrote: > >Hi, > >We are planning to release code this week for testing. Testsers have >to agree not to redistribute code. Soon we hope to put the code on a >site that will re-distribute within the US. I am a US citizen living in the US and would appreciate any source you have. >It would be useful to start a discussion about what we are trying to >hide and what may do that hiding. I'm looking for communication >models, attack models, carefully stated requirements, and justified >solutions. Seems I am going to have to write that paper after all... >For example, precisely what do we by "assume only a single >uncompromised onion router?" Assume the adversary monitors all in and outgoing connections. Further assume, the adversary operates all but one core onion router. >As another example, if two sites connect (encrypted) to remote onion >routers at roughly the same time, it is more likely that they are >communicating than if they didn't connect at roughly the same time. >This is hard to protect against. That's where constant bandwidth _will_ make the difference. >Do we need constant utilization or is smoothing sufficient? Smoothing is insufficient. Traffic analysis is a statistical attack. With "smoothing" you just force the attacker to obtain more data. >Do we want to add noice to individual connections? Absolutely. >Do we want terminal onion router to terminal onion router padding >(noise connections)? That might be a good idea. But don't look at it as noise. If the circuits will be constantly saturated, as you predict, padding will not be needed. >Do we want padding between neighboring onion routers? Sure. > >I'm looking to leverage off the expertise in this list, so we can >build strong hiding around the onion routing infrastructure. I don't know anybody that has longer and deeper thought about these issues than the subscribers to this list. Onion routing is a good idea. It just needs to take some other research into account. -- Lucky Green PGP encrypted mail preferred "I do believe that where there is a choice only between cowardice and violence, I would advise violence." Mahatma Gandhi From majordom Wed Mar 12 07:45:38 1997 Return-Path: Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA15792; Wed, 12 Mar 97 07:45:38 EST Received: from banana-jr.itd.nrl.navy.mil by itd.nrl.navy.mil (4.1/SMI-4.1) id AA15786; Wed, 12 Mar 97 07:45:31 EST Date: Wed, 12 Mar 1997 07:45:40 -0500 (EST) From: "Michael G. Reed" To: onions@itd.nrl.navy.mil Subject: Re: discussion points In-Reply-To: <3.0.32.19970312014106.007053dc@netcom9.netcom.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-onions@itd.nrl.navy.mil Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- On Wed, 12 Mar 1997, Lucky Green wrote: |>>For example, precisely what do we by "assume only a single |>>uncompromised onion router?" |> |>Assume the adversary monitors all in and outgoing connections. Further |>assume, the adversary operates all but one core onion router. If this is the assumption, then everything is a moot point. If some adversary operates all but one core onion router he KNOWS with 100% certainty where the connection originated though. Then it is only a matter of time and watching (how carefully it can be watched may vary) that onion router or doing other statistical attacks on the (now) known plaintext coming out of all of the nodes before he knows everything. This is ludicrous. If you really can't trust some percent of the onion routers out there in the world (even half), then the whole effort is a waste in the first place. By "trust" I don't mean completely trust in that you would use them as your first hop, but trust at least to the level that they are not actively attacking you and are behaving relatively well. You only need one completely honest node farther down stream to make the link passively untraceable (and depending on the implementation one may be sufficient to make it actively untraceable, but I'm not positive about that). |>>As another example, if two sites connect (encrypted) to remote onion |>>routers at roughly the same time, it is more likely that they are |>>communicating than if they didn't connect at roughly the same time. |>>This is hard to protect against. |> |>That's where constant bandwidth _will_ make the difference. No, constant bandwidth makes absolutely NO difference in this situation. This is an attack which looks at coincidences of NEW connections going IN TO and OUT OF the network...not data flow within the network, but timing on new connections. Bandwidth means nothing here. |>>Do we need constant utilization or is smoothing sufficient? |> |>Smoothing is insufficient. Traffic analysis is a statistical attack. With |>"smoothing" you just force the attacker to obtain more data. See my next message regarding bandwidth concerns... |>>Do we want to add noice to individual connections? |> |>Absolutely. This can be done a number of ways including: 1) letting the higher level protocol do it, 2) Inserting it into DATA cells somehow (possibly by having cells with illegal lengths...only the last router would be able to determine this, which might, in turn, give you some more information to attack the connection), or 3) Adding a new cell type (BAD idea since it introduces markers that can be tracked independent of the other cell types). To somewhat quote Monte Python, "#3 is right-out". Furthermore, I really have to think some more about #2 before I would consider adding it. #1 is by far the best, but we are trying to coexist with UNMODIFIED internet applications, so this is difficult. |>>Do we want padding between neighboring onion routers? |> |>Sure. Inter-node padding does not solve the problem of "bad" nodes. It will help confound external observers, but a bad node will always know what is padding on node to node padding. End to end padding could be hidden from all but the last node, and protocol padding could be hidden from all nodes. |>I don't know anybody that has longer and deeper thought about these issues |>than the subscribers to this list. Onion routing is a good idea. It just |>needs to take some other research into account. Research or practical experience? We are researchers. That is our job description. That is what we get paid to do. There are more PhD's walking around this base than some college campuses. We publish constantly in academic circles, we attend conferences, we participate in the larger academic world. Please do not assume that since we work for the government that we are uninformed, undereducated, GAK-loving idiots. What we lack is the practical experience in this area -- most of what we do is theory, theory, theory...very little applied (at least in the computer security area). Thus the prototype where we've already learned a great deal about where the theoretical models break down in the real world. Thus all the discussions with people running other MIX variants in the world (both in research labs and actually out there on the Internet). Thus the need for a wider participation and the push for a general RFC that can be accepted by the whole Internet community. Please don't view this as an "us vs. them" environment...we want the same level (and possibly even higher level) of security that you want out of this system...help us do that. Sorry for the venting, but I've received one to many emails in the last two weeks from very uninformed people that have just rubbed me the wrong way. - -Michael -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMyaleE8Qx019l0ClAQFsEwP9EklbraP0303MgkTFVHu8mxvy0Vlh3spY Cw6MCrr0ntwQyGwYucrUuLXtl/3t3rTnyESdaYNxFzHdCiDZVJIMAizwyM8gN6ue 9rkW0uL4iIxZxSWqWFeD2kn1NjnrJC6dSZNQvuTTglyz1MIJd+Kbzb/ebbR3waBm 2b15LsJItzo= =Lz6C -----END PGP SIGNATURE----- From majordom Wed Mar 12 08:59:35 1997 Return-Path: Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA19068; Wed, 12 Mar 97 08:59:35 EST Received: from banana-jr.itd.nrl.navy.mil by itd.nrl.navy.mil (4.1/SMI-4.1) id AA19060; Wed, 12 Mar 97 08:59:28 EST Date: Wed, 12 Mar 1997 08:59:37 -0500 (EST) From: "Michael G. Reed" To: Onion Routing List Subject: Bandwidth/Padding/etc... Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-onions@itd.nrl.navy.mil Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- All, There have been a number of discussions about padding and bandwidth usage. I just want to point out some technical arguments that we need to consider when designing how the system will pad and to what extent padding can be achieved. First is that we are running on top of a reliable delivery mechanism of which we have little, if no, control -- namely TCP/IP. We do not have direct access to the outbound wire like a real router does, so saying things like "we will use or pad to 100% bandwidth" is really meaningless. Padding "to full network or link capacity" only makes sense in terms of actual control of the wire. Since we cannot achieve real control of the wire in our implementation, we need to look at a different definition. One possible solution is to place onion routers on dedicated links to the Internet. Not really likely, and not really a viable option. Another solution is to predefine and reserve some amount of guaranteed capacity between nodes. While this is possible with ATM and will be possible with IPv6 in general, it is not possible on the current Internet. So again, we need to weaken our definition of what capacity and usable bandwidth are. If we do "data smoothing", we can fluctuate bandwidth with available capacity of the Internet. I'm not talking real short term smoothing, but prolonged smoothing where we change individual link utilization over time with regard to how much traffic we are sending, and how much traffic exists on the physical links outside of our system. I think data smoothing offers a more robust system than just enforcing a hard capacity since that hard capacity would have to be based on the slowest, most unreliable link in the system. Remember, we are running on top of TCP/IP...there will be packet loss, packet rerouting, packet retransmission. We need the ability to back-off nodes, or else we run the risk of swamping network links in our effort to attain perfect utilization of whatever capacity we define. What it all really comes down to is what our threat model is, and what we can do on the existing Internet. I think it is unreasonable to wait for IPv6, or to say we will only deploy on ATM clouds. Furthermore, I think it is unreasonable to enforce artifically low link capacities because of one bad link somewhere. I urge people to comment on all of this. - -Michael -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMya2zU8Qx019l0ClAQE/eAP/YsHo3ciKtimwgVvkDRKNlHHQJw3v3JNG Gy6v8chwYkFkLfi2iUKqceC3lqd4GyBuvpLULTSMUEP/tvoNQVezTd8SUkMQeHlA TOp+Jr7g+EKlSyS+I6UzJK2nyvr7i3Tq/+9PDngCbcar82jJJX8fioQ8zUQJi825 I8nzndORkC8= =GFSM -----END PGP SIGNATURE----- From majordom Wed Mar 12 14:58:29 1997 Return-Path: Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA09150; Wed, 12 Mar 97 14:58:29 EST Received: from callisto.hip.berkeley.edu by itd.nrl.navy.mil (4.1/SMI-4.1) id AA09127; Wed, 12 Mar 97 14:57:55 EST Received: (from raph@localhost) by callisto.hip.berkeley.edu (8.6.12/8.6.12) id LAA06135; Wed, 12 Mar 1997 11:58:48 -0800 Message-Id: <33270AF3.26B6B0D@acm.org> Date: Wed, 12 Mar 1997 11:58:43 -0800 From: Raph Levien X-Mailer: Mozilla 3.0 (X11; U; Linux 1.2.13 i586) Mime-Version: 1.0 To: Onion Routing List Cc: eric@remailer.net Subject: Vulnerabilities of anonymous routing Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-onions@itd.nrl.navy.mil Precedence: bulk I wanted to put in my two cents on some of the topics here, even though I'm a bit swamped right now. I'll start with a few comments about what it means to successfully analyze anonymized traffic, outline a few attacks that seem fruitful, add a few words about "constant bandwidth" and (for those who have the patience) end with an invitation. It seems to me that the best way to model traffic analysis is _distinguishability_. Is it possible to distinguish, from observable traffic patterns, the case when Alice is browsing Bob's homepage from the case when Alice is not? More formally, what is the probability that an adversary would make the correct guess. If that's significantly better than chance, then traffic analysis is in some sense feasible. Of course, the powers of the adversary depend on what we're trying to model (passively observing some traffic, observing all traffic, actively inserting traffic, operating compromised onion routers, etc.). This may seem like an obvious definition of traffic analysis, but it gets us closer to the way cryptographic primitives are defined (PRNGs come to mind), and has some implications for how to prove resistance to traffic analysis. More on this later when I touch on constant bandwidth. Now for some attacks. The first attack assumes passive observing of traffic volume at all endpoints. No assumptions are made about the center portion. Thus, the central portion can be implemented as onion routing, DC-nets, or whatever, and is modelled simply as a probability distribution of time delays. For anonymous Web browsing, performance dictates that the mean is fairly small (on the order of a few seconds), and the random nature of onion routing mixing suggests that a Gaussian distribution will be fairly accurate. Given these assumptions, traffic analysis reduces to a signal processing problem - separating the signal from the noise. The signal is right there for all to see (a bump in traffic at Alice, followed by a bump in traffic a few seconds later at Bob), but may possibly be obscured by the noise. A first cut at the problem is simply to calculate a correlation matrix of all inputs to the network with all outputs. To improve the accuracy of the correlation, the input events are convolved (in time) with the model of the anonymizing network. This convolution also makes it easy to deal with discrete event traffic flows as opposed to continuous flows. The resulting correlation matrix will contain the desired signal, but will also contain quite a bit of noise. In particular, correlations between patterns of browsing will cause spurious positive signals in the matrix (more concretely, if Alice browses the Dilbert page every morning when she gets to work, and Bob browses CNN, then the correlation matrix will show positive numbers for Alice/CNN and Bob/Dilbert). I haven't gone into the math, but I think it should be possible to remove much of this cross-correlation noise. Most crudely, the cross-correlation noise will be concentrated in low frequencies, so it should be possible to simply filter it out. On the other hand, we're assuming that all traffic volumes are known, so it should be possible to estimate the cross-correlations accurately and correct for them. Eric Hughes has suggested entropy optimization techniques (of roughly the same kind as used to reconstruct images in computed tomography), and it seems likely that this approach would be fruitful. As a research topic, the next obvious place to look is the information content in Web browsing patterns. The low frequency components will be dominated by noise, and the high frequency components (i.e. finer than a few seconds) will be filtered out by the mixing process. I believe that there is still plenty of information content in between, but ultimately this has to be determined empirically. Adding active attacks can help. The present-day Web makes these quite easy. For example, Java applets which refresh information periodically are becoming popular. It would be easy for such an applet to modulate the timing so as to maximize the information content and minimize cross-correlation with other traffic patterns. No doubt the design of CDMA phones can provide design inspiration. One characteristic of this attack is that integration over longer time periods helps. In general, the signal will scale linearly with the number of samples, while the noise will only scale as the square root. Thus, by doing a million samples, you gain a factor of a thousand in signal to noise ratio. Just as with Paul Kocher's timing attacks, merely adding noise to the signal (i.e. random delays) does not protect against the attack. Thanks to Eric Hughes for many of the ideas presented here. The second attack uses reliability information. This attack is devastating against anonymous servers, much more so than anonymous browsers. However, in the Web today, the distinction between servers and browsers is not airtight. I'll describe the attack for servers first and then touch on how to make browsers act as servers. The assumption for this attack against servers is that the adversary has access to reliability information for both the physical nodes and the pseudonymous servers. This assumption is quite reasonable. Reliability information for the pseudonymous servers must be public information, because either you can access the page or you can't. In addition, onion routing forces the reliability information of physical nodes to be public information, otherwise it would be impossible to build onions that had a high probability of working. (experience with the remailer list highlights this fact - even with fairly decent statistics gathering, and with all information fully public, the reliability of chains of 5 remailers is usually no higher than 90-95% - see http://kiwi.cs.berkeley.edu/remailer-chains for the current stats) Again, traffic analysis is performed by correlating the reliability info for the physical and pseudonymous servers. It's possible to do even better than plain correlation, though, because if the physical server is down, the corresponding pseudonymous server _must_ also be down. Thus, when a physical server goes down, the list of pseudonymous servers that are still up can be excluded from the possibile pseudonymous server associated with that physical server. If this exclusion process narrows down the list of possible servers to one, then that's much stronger evidence than merely a high correlation. This particular type of analysis makes it particularly difficult to overwhelm the signal with noise. If the servers are quite unreliable, then there's lots of signal to analyze. On the other hand, by making the servers very reliable, you also eliminate the noise. If only one server is down at any given time, it becomes trivial to analyze them. Thus, I consider this attack to be among the most fruitful when it is feasible. Now, how to generalize this attack to browsing? One easy way I can think of is to apply the same Java applet technique, only this time geared to detecting sudden disruptions. For example, the applet could cause the browser to reload a small HTML file periodically, functioning as a watchdog. To distinguish server failures from people getting bored with the page they're watching, the applet sends a message to the server when it terminates normally. Thus, whenever a physical server goes down, the applet's server looks for the watchdog sequences to suddenly cease. If these are fairly rare events, and if there are many simultaneous connections, it would count as strong evidence. I can envision somewhat less effective passive attacks too, for example based on Markov models of typical browsing behavior. Again, if typical browsing behavior can be distinguished from sudden disruptions of service, that's all the leverage needed for traffic analysis. Many of these ideas in this second attack are due to Lewis McCarthy. Now for some discussion of constant bandwidth. As I see it, the main idea of constant bandwidth is to make it impossible, by definition, to distinguish between different patterns of traffic. To extend the random number analogy, they are the analog of truly random numbers (i.e. a flat distribution of probabilities) as opposed to pseudorandom numbers (i.e. a highly uneven distribution, but hopefully one which cannot be distinguished from a flat one). The analogy to Paul Kocher's timing attacks is again instructive. The distinguishability criterion is helpful, I believe. As long as the signal is made indistinguishable on some level (for example, calling write() on the socket at a constant rate, with a constant number of bytes), it doesn't matter if there are variations on other levels (for example, IP variability). Thus, I think that the discussion of needing IPv6 or ATM is moot. To address some of the points that Michael made about "us vs. them," I'm very happy to see the NRL doing this research. I have no doubt that you guys have what it takes to pull this project off. I'm also happy to see that your goal is to resist serious traffic analysis (as opposed to hiding browsing patterns from your little sister). We cypherpunks have been thinking about these problems for quite some time, as they are central to our agenda, but too often we sit around and talk about them rather than actually building things. However, it seems clear that the problem of building an anonymous network strongly resistant to traffic analysis is _hard,_ quite a bit harder than your Oakland paper draft seems to credit. If you're going to make the claim that the system you build is resistant in this way, then you'll also have to show how it holds up against very best attacks that can be mounted, not just the straightforward marker tracking attack as described in section 6 of the Oakland draft. As promised, finally an invitation. I think it would be great if the onion routing people could get together with a group of cypherpunks who have put some thought into this problem. Since the onion routing people will be in the Bay Area for Oakland, and since most of the relevant cypherpunks live here (with Lewis McCarthy being the most notable exception), I'd like to organize a dinner at my apartment sometime during the Oakland conference. I live about six blocks from the Claremont hotel where the conference is held, and I'm willing to try some onion recipes. I think this would really give us the chance to talk seriously about network anonymity, and get to know each other better. I've got to get back to writing my paper now. I probably won't have time in the next couple of weeks to respond to followups, but hope to be able to do so after I get back from out of town. Raph P.S. One correction to the Oakland draft. The discussion of anonymous reply mail in section 9 seems to me to be inaccurate. The nymservers implement an "encrypted reply block" which seems to me to be fully analogous to reply onions. In this model, the nymserver functions as the "client proxy", mapping human-readable e-mail addresses to encrypted reply blocks, while the other remailers in the chain simply forward and encrypt the mail statelessly. Under the assumption that passing through a remailer really hides the connection (i.e. discounting the traffic correlation attacks outlined above), it suffices that a single remailer be uncompromised to protect the traffic. From majordom Wed Mar 12 15:46:15 1997 Return-Path: Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA11284; Wed, 12 Mar 97 15:46:15 EST Received: from carnap.itd.nrl.navy.mil by itd.nrl.navy.mil (4.1/SMI-4.1) id AA11278; Wed, 12 Mar 97 15:46:09 EST From: syverson@itd.nrl.navy.mil (Paul Syverson) Received: (from syverson@localhost) by carnap.itd.nrl.navy.mil (8.8.5/8.7.3) id PAA10646 for onions@itd.nrl.navy.mil; Wed, 12 Mar 1997 15:46:05 -0500 (EST) Date: Wed, 12 Mar 1997 15:46:05 -0500 (EST) Message-Id: <199703122046.PAA10646@carnap.itd.nrl.navy.mil> To: onions@itd.nrl.navy.mil Subject: A quick observation on terminology X-Sun-Charset: US-ASCII Sender: owner-onions@itd.nrl.navy.mil Precedence: bulk I've noticed that many postings treat `traffic analysis' as including (at least) confirming that Alice and Bob are communicating given that one specifically targets them as potential communicants. If this is standard terminology, so be it. If it's not set in stone, however, I think this should be called something like traffic pattern confirmation. Analysis is determining who is talking to whom (or who is Alice talking to, or who is talking to Bob). Compare `cryptanalysis', which usually does not include confirming correct guesses of keys or discovering keys by exhaustively rejecting bad guesses. Traffic analysis (sensu stricto) and traffic pattern confirmation may both be important to guard against, but they are distinct threats. aloha, Paul P.S. Email may be the most efficient mechanism ever devised for creating offense where none was intended. If we start telling each other how smart (or dumb) we are, things will probably quickly degenerate to... well, to the usual level of email discussions. Sincerely, Paul Syverson Floral Park-Bellerose (Elementary) School Class of 1970 From majordom Wed Mar 12 17:20:10 1997 Return-Path: Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA16071; Wed, 12 Mar 97 17:20:10 EST Received: from ccnet4.ccnet.com by itd.nrl.navy.mil (4.1/SMI-4.1) id AA16037; Wed, 12 Mar 97 17:19:56 EST Received: from sfbayarea.ccnet.com (h108-14-159.ccnet.com [199.108.14.159]) by ccnet4.ccnet.com (8.7.1/8.6.12) with SMTP id OAA07020 for ; Wed, 12 Mar 1997 14:21:04 -0800 (PST) Message-Id: <3.0.32.19970312132106.006e1adc@netcom9.netcom.com> X-Sender: shamrock@netcom9.netcom.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 12 Mar 1997 14:21:03 -0800 To: Onion Routing List From: Lucky Green Subject: Re: Bandwidth/Padding/etc... Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-onions@itd.nrl.navy.mil Precedence: bulk At 08:59 AM 3/12/97 -0500, Michael G. Reed wrote: > If we do "data smoothing", we can fluctuate bandwidth with >available capacity of the Internet. I'm not talking real short term >smoothing, but prolonged smoothing where we change individual link >utilization over time with regard to how much traffic we are sending, >and how much traffic exists on the physical links outside of our >system. I think data smoothing offers a more robust system than just >enforcing a hard capacity since that hard capacity would have to be >based on the slowest, most unreliable link in the system. The idea of "smoothing" has merit. When it was first mentioned, I thought you were talking about a high frequency smoothing. But if you mean by smoothing a low frequency smoothing, say adding and removing available bandwidth along well established daily usage patterns, then smoothing may not provide the attacker with more information than a constant bandwidth pipe would. > What it all really comes down to is what our threat model is, >and what we can do on the existing Internet. I think it is >unreasonable to wait for IPv6, or to say we will only deploy on ATM >clouds. Furthermore, I think it is unreasonable to enforce >artifically low link capacities because of one bad link somewhere. I >urge people to comment on all of this. Agreed. It all comes down to the treat model. I assume a very resourceful adversary that can monitor the entire network, or at least large parts of it. The adversary in my threat model also can conduct active attacks. What is your threat model? As to the link capacity, I believe the core routers should be on high capacity links that can be assumed to be mostly stable. The link between a core router and the user's proxy must of course be assumed to be unstable. -- Lucky Green PGP encrypted mail preferred "I do believe that where there is a choice only between cowardice and violence, I would advise violence." Mahatma Gandhi From majordom Wed Mar 12 17:20:14 1997 Return-Path: Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA16082; Wed, 12 Mar 97 17:20:14 EST Received: from ccnet4.ccnet.com by itd.nrl.navy.mil (4.1/SMI-4.1) id AA16043; Wed, 12 Mar 97 17:19:59 EST Received: from sfbayarea.ccnet.com (h108-14-159.ccnet.com [199.108.14.159]) by ccnet4.ccnet.com (8.7.1/8.6.12) with SMTP id OAA07025; Wed, 12 Mar 1997 14:21:06 -0800 (PST) Message-Id: <3.0.32.19970312142049.00710208@netcom9.netcom.com> X-Sender: shamrock@netcom9.netcom.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 12 Mar 1997 14:21:04 -0800 To: "Michael G. Reed" , onions@itd.nrl.navy.mil From: Lucky Green Subject: Re: discussion points Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-onions@itd.nrl.navy.mil Precedence: bulk At 07:45 AM 3/12/97 -0500, Michael G. Reed wrote: >If this is the assumption, then everything is a moot point. If some >adversary operates all but one core onion router he KNOWS with 100% >certainty where the connection originated though. Not necessarily. Assume for a moment the uncompromised router is the node a user's proxy connects into. The attacker knows all incoming plaintext data for all the users who connect to the uncompromised node. Depending on how many users connect to that node, and how many of them keep the connection up most of the time, the attacker may or may not be able to determine the ultimate browser. >|>>As another example, if two sites connect (encrypted) to remote onion >|>>routers at roughly the same time, it is more likely that they are >|>>communicating than if they didn't connect at roughly the same time. >|>>This is hard to protect against. >|> >|>That's where constant bandwidth _will_ make the difference. > >No, constant bandwidth makes absolutely NO difference in this >situation. This is an attack which looks at coincidences of NEW >connections going IN TO and OUT OF the network...not data flow within >the network, but timing on new connections. Bandwidth means nothing >here. Upon re-reading your original post, I agree that constant bandwidth amongst the routers will not help against a passive attacker in this case. What will help, however, is constant bandwidth between the user's proxy and the first core router. If the user makes a connection to an onion router in the morning and leaves it up until the evening, the passive attacker learns nothing. Other than your work hours, that is :-) [about noise] >This can be done a number of ways including: 1) letting the higher >level protocol do it, 2) Inserting it into DATA cells somehow >(possibly by having cells with illegal lengths...only the last router >would be able to determine this, which might, in turn, give you some >more information to attack the connection), or 3) Adding a new cell >type (BAD idea since it introduces markers that can be tracked >independent of the other cell types). To somewhat quote Monte Python, >"#3 is right-out". Furthermore, I really have to think some more >about #2 before I would consider adding it. #1 is by far the best, >but we are trying to coexist with UNMODIFIED internet applications, so >this is difficult. Of course you want to interoperate with unmodified Internet applications. That's why you should use a client side proxy. What happens at the other side of the proxy is yours to choose. It could be as simple as a steam cipher into which the proxy xor's the data. [Client side proxies are the future. My thanks go to Jim McCoy for convincing me of that. In fact, the average user's machine will probably run multiple chained proxies for the same protocol: An onion routing proxy to access the network, followed by SafePassage to increase SSL strength from 40 to 128 bit, followed by a decrypting proxy for webpages that are stored encrypted, followed by CookieCutter, to get rid of unwanted cookies, etc. That's four chained proxies for HTTP alone. [As a side bar, proxies@communities.com is the list where we are currently discussing specs for a "universal" client side proxy that allows for dynamic loading of proxy modules.] >|>>Do we want padding between neighboring onion routers? >|> >|>Sure. > >Inter-node padding does not solve the problem of "bad" nodes. Agreed. >It will >help confound external observers, but a bad node will always know what >is padding on node to node padding. End to end padding could be >hidden from all but the last node, It might help to think of the "last node" as something that resides on the user's machine. >and protocol padding could be >hidden from all nodes. Wouldn't that require a proxy on the accessed website? >|>I don't know anybody that has longer and deeper thought about these issues >|>than the subscribers to this list. Onion routing is a good idea. It just >|>needs to take some other research into account. > >Research or practical experience? We are researchers. That is our >job description. That is what we get paid to do. There are more >PhD's walking around this base than some college campuses. We publish >constantly in academic circles, we attend conferences, we participate >in the larger academic world. Please do not assume that since we work >for the government that we are uninformed, undereducated, GAK-loving >idiots. The mere fact that you are working on Onion Routers proves that you have a clue and are none of the things that you seem I am assuming. I assure you, I am not assuming any of the traits you mention. > What we lack is the practical experience in this area -- most >of what we do is theory, theory, theory...very little applied (at >least in the computer security area). Thus the prototype where we've >already learned a great deal about where the theoretical models break >down in the real world. Thus all the discussions with people running >other MIX variants in the world (both in research labs and actually >out there on the Internet). Thus the need for a wider participation >and the push for a general RFC that can be accepted by the whole >Internet community. Please don't view this as an "us vs. them" >environment...we want the same level (and possibly even higher level) >of security that you want out of this system...help us do that. Which is exactly the reason why I am talking with you, published your URL to the relevant mailing lists, and convinced people I knew to be knowledgable about this topic to subscribe to this list. This is not an "us vs. them" for any person on the list that I know. And I probably know most, if not all subscribers (other than the one's from NRL, whom I first met at FC'97). Most of the non-NRL subscribers on this list are, or have been, subscribers to the Cypherpunks mailing list. The overriding goal was to secure the communications infrastructure and achieve privacy by preventing the adversary from gaining information about an individual or corporation by being able to read or traffic analyze the communications. Classical COMSEC. The old Cypherpunks and the US Navy are facing the same problem and are therefore looking at similar solutions. You need broad public use of the system to provide you with cover traffic and we want to see such a system deployed to provide the citizens with privacy. We are allies, not enemies. It is in this spirit of cooperation that we are pointing out issues with your design that some of us believe require fixing before the system can achieve our common goal. We all want to see the best design possible to be deployed, because we all know that no other design will ever achieve the broad penetration that we seek. Let's all work together on making that design a reality. Thanks, -- Lucky Green PGP encrypted mail preferred "I do believe that where there is a choice only between cowardice and violence, I would advise violence." Mahatma Gandhi From majordom Thu Mar 13 08:02:54 1997 Return-Path: Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA06969; Thu, 13 Mar 97 08:02:54 EST Received: from banana-jr.itd.nrl.navy.mil by itd.nrl.navy.mil (4.1/SMI-4.1) id AA06959; Thu, 13 Mar 97 08:02:42 EST Date: Thu, 13 Mar 1997 08:02:52 -0500 (EST) From: "Michael G. Reed" To: Onion Routing List Subject: Re: [LONG] Re: Asymmetric routes In-Reply-To: <33271F49.595B884E@veriweb.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-onions@itd.nrl.navy.mil Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- On Wed, 12 Mar 1997, Jeremey Barrett wrote: |>Another possible implementation would be for the initiator to supply |>"prebuilt" DATAHDRs to the responder. Then the initiator would only |>need to supply one crytpo operation/key to the responder. The responder |>can still tell the length of the return route from the size of the |>DATAHDRs it gets, but does not have the keys to encrypt. Actually, |>the initiator could fool the responder and append several bogus DATAHDRs |>if necessary, eliminating even that possibility. The overhead is |>getting ugly here, given 44-byte messages. This looks like it would work, and as long as you didn't need to do it too frequently the overhead may be acceptible. Given the level of complication we've just described in the last few messages, I'm reluctant to jump to impliment this though...I'm not entirely sure how much power we gain from this change or how much better this defeats our threat model. Looks like it gives us a lot more robustness against node failure, but I'm not sure what else it gives us. - -Michael -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMyf7AE8Qx019l0ClAQFIzwP9FwaIKhZ5UP/517UoZ6Rl6SzyJUbEKpUY D6TpI1C4co1yKlF9MO3MM4oOjGPzadXS2QzznnRQ3pvtZRtUdxGuTSywRXQ0M7mL qQ690MfxWvlGZwQOOrD6mUOks9mBCEz0KOMjXQyxTB7sudh+TNL1PGfg3PUel++v UVbm8EPDMTI= =3vid -----END PGP SIGNATURE----- From majordom Thu Mar 13 08:20:16 1997 Return-Path: Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA07754; Thu, 13 Mar 97 08:20:16 EST Received: from banana-jr.itd.nrl.navy.mil by itd.nrl.navy.mil (4.1/SMI-4.1) id AA07742; Thu, 13 Mar 97 08:20:06 EST Date: Thu, 13 Mar 1997 08:20:15 -0500 (EST) From: "Michael G. Reed" To: Onion Routing List Subject: Re: discussion points In-Reply-To: <3.0.32.19970312142049.00710208@netcom9.netcom.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-onions@itd.nrl.navy.mil Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- On Wed, 12 Mar 1997, Lucky Green wrote: |>>No, constant bandwidth makes absolutely NO difference in this |>>situation. This is an attack which looks at coincidences of NEW |>>connections going IN TO and OUT OF the network...not data flow within |>>the network, but timing on new connections. Bandwidth means nothing |>>here. |> |>Upon re-reading your original post, I agree that constant bandwidth amongst |>the routers will not help against a passive attacker in this case. What |>will help, however, is constant bandwidth between the user's proxy and the |>first core router. If the user makes a connection to an onion router in the |>morning and leaves it up until the evening, the passive attacker learns |>nothing. Other than your work hours, that is :-) True. This would be a slightly different implementation than we currently have since every connection to a proxy generates a new connection into a core onion router (ie, unless the protocol allows for sequencing request over one socket, you have N sockets for N requests...HTTP 1.1 allows for this). This design is different than our original design (oh, about 9 months ago) where proxy and core were one process, and some of our testing to date has pointed out that it was (probably) a mistake to make this division (the division was made since the fundamental core architecture is not application specific, so people could write new proxies and have them talk to the network without having to replace core onion routers...only add the proxy -- while nice from a theoretical perspective, every time we go up and down the IP stack (even on the same machine) and have more system calls, our efficiency goes down. We may ultimately roll the well established proxies into the core onion routers and still allow for new (experimental) proxies to connect as they do now. Comments? |>[about noise] |>>This can be done a number of ways including: 1) letting the higher |>>level protocol do it, 2) Inserting it into DATA cells somehow |>>(possibly by having cells with illegal lengths...only the last router |>>would be able to determine this, which might, in turn, give you some |>>more information to attack the connection), or 3) Adding a new cell |>>type (BAD idea since it introduces markers that can be tracked |>>independent of the other cell types). To somewhat quote Monte Python, |>>"#3 is right-out". Furthermore, I really have to think some more |>>about #2 before I would consider adding it. #1 is by far the best, |>>but we are trying to coexist with UNMODIFIED internet applications, so |>>this is difficult. |> |>Of course you want to interoperate with unmodified Internet applications. |>That's why you should use a client side proxy. What happens at the other |>side of the proxy is yours to choose. It could be as simple as a steam |>cipher into which the proxy xor's the data. [Client side proxies are the |>future. My thanks go to Jim McCoy for convincing me of that. In fact, the |>average user's machine will probably run multiple chained proxies for the |>same protocol: |> |>An onion routing proxy to access the network, followed by SafePassage to |>increase SSL strength from 40 to 128 bit, followed by a decrypting proxy |>for webpages that are stored encrypted, followed by CookieCutter, to get |>rid of unwanted cookies, etc. That's four chained proxies for HTTP alone. |>[As a side bar, proxies@communities.com is the list where we are currently |>discussing specs for a "universal" client side proxy that allows for |>dynamic loading of proxy modules.] Great idea, but isn't that going to be a little heavy on the overhead? Also, how are you handling the parsing/tokenizing of HTML? Right now it looks like our anonymizing proxies does some of these all wrapped up in one (cleans up the data stream, routes through onion routing, and certainly we could add end to end crypto like stronger SSL). |>>It will |>>help confound external observers, but a bad node will always know what |>>is padding on node to node padding. End to end padding could be |>>hidden from all but the last node, |> |>It might help to think of the "last node" as something that resides on the |>user's machine. I was thinking more in terms of the other end of the pipe (ie, the end away from the user would know it had got padding). |>>and protocol padding could be |>>hidden from all nodes. |> |>Wouldn't that require a proxy on the accessed website? Not necessarily. It could just make bogus requests to that website. The last node will not be able to determine a valid request from a bogus request since they are both legitimate....we're just ignoring the response of the later when it get's back to the original requestor. |>The mere fact that you are working on Onion Routers proves that you have a |>clue and are none of the things that you seem I am assuming. I assure you, |>I am not assuming any of the traits you mention. Great! :-) Really though, I was just venting at no one in particular... most of the email that had stroked me the wrong way was from people that are not on the list and really don't want to bother being on the list because they don't want to help/contribute but are VERY quick to jump to conclusions and criticize something they don't understand. We *REALLY* do appreciate all the comments we've gotten from the list in the past week or so here (for one thing, it has fundamentally shaken a few of us with regard to some of our base assumptions about the threat model...), keep them coming :-) - -Michael -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMyf/FE8Qx019l0ClAQHP0QP6A6fc8Kx5X/SZ2nYOU0Gbs97aMgxEHuuw 0mF3dXVvWi0VeelW6CrUwdnCnam2Y8qWXfRCUh2JgqWj9QBdIXxhehO3ZG/cc3IG GXNgHfd3Himb0YLwvqv4TaONrEggHJJzSQDqoGNkN9mQZ5W4VXV8o9bfHYvvymUp soBTNiHMAg8= =ZygT -----END PGP SIGNATURE----- From majordom Thu Mar 13 08:33:12 1997 Return-Path: Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA08325; Thu, 13 Mar 97 08:33:12 EST Received: from banana-jr.itd.nrl.navy.mil by itd.nrl.navy.mil (4.1/SMI-4.1) id AA08302; Thu, 13 Mar 97 08:32:59 EST Date: Thu, 13 Mar 1997 08:33:08 -0500 (EST) From: "Michael G. Reed" To: Onion Routing List Subject: Re: Bandwidth/Padding/etc... In-Reply-To: <3.0.32.19970312132106.006e1adc@netcom9.netcom.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-onions@itd.nrl.navy.mil Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- On Wed, 12 Mar 1997, Lucky Green wrote: |>The idea of "smoothing" has merit. When it was first mentioned, I thought |>you were talking about a high frequency smoothing. But if you mean by |>smoothing a low frequency smoothing, say adding and removing available |>bandwidth along well established daily usage patterns, then smoothing may |>not provide the attacker with more information than a constant bandwidth |>pipe would. Yes, lower frequency is what I had envisioned...it could even done at different levels (ie, general bandwidth could follow one pattern per 24x7 usage and then we could allow for some deviations in time if really high usage...essentially allow us to push the threshold up a little more if we really need it and then gradually fall back down to the 24x7 rolling threshold). |>Agreed. It all comes down to the treat model. I assume a very resourceful |>adversary that can monitor the entire network, or at least large parts of |>it. The adversary in my threat model also can conduct active attacks. What |>is your threat model? I believe David is currently writing up our threat model (Aren't you Dave :-), so it should be out there soon. |>As to the link capacity, I believe the core routers should be on high |>capacity links that can be assumed to be mostly stable. The link between a |>core router and the user's proxy must of course be assumed to be unstable. I like the sound of that, but I'm wondering if we really can get the high-bandwidth/stable/geographically and locally diverse requirements met for core routers. Also, what do we do if joe-down-the-street is hanging off a 128k ISDN link but wants to run a core router...do we say no? - -Michael -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMygCGE8Qx019l0ClAQHuRgP/RwPRkfSFgExhhfs5NZkukHfc5Wi8VRZN buIAtHO1aSh1+NhxbcZPdD3jGFMdRFoC2ENw0AAav9sXXVeTW7XDc57GnHJFPFM/ xauwKxaJWOk9+rtW2fyNS8prvwG0BmTezMbpFyA3yISj/XuPTA91WZJNvDmrsfya 3Sa6yiygkc8= =GzhC -----END PGP SIGNATURE----- From majordom Wed Mar 26 02:53:11 1997 Return-Path: Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA10967; Wed, 26 Mar 97 02:53:11 EST Received: from netcom13.netcom.com by itd.nrl.navy.mil (4.1/SMI-4.1) id AA10961; Wed, 26 Mar 97 02:53:03 EST Received: from sfbayarea.ccnet.com (h108-14-160.ccnet.com [199.108.14.160]) by netcom13.netcom.com (8.6.13/Netcom) id XAA10506; Tue, 25 Mar 1997 23:52:59 -0800 Message-Id: <3.0.32.19970325235326.0073e2c0@netcom9.netcom.com> X-Sender: shamrock@netcom9.netcom.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 25 Mar 1997 23:53:37 -0800 To: From: Lucky Green Subject: Threat model? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-onions@itd.nrl.navy.mil Precedence: bulk Folks, It has been rather silent on this list. Did NRL finish the threat model? Dave? I'd love to see it and I am sure so would others on the list. And we are all still waiting for the source code... Thanks, -- Lucky Green PGP encrypted mail preferred "I do believe that where there is a choice only between cowardice and violence, I would advise violence." Mahatma Gandhi From majordom Wed Mar 26 09:06:40 1997 Return-Path: Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA19944; Wed, 26 Mar 97 09:06:40 EST Received: from banana-jr.itd.nrl.navy.mil by itd.nrl.navy.mil (4.1/SMI-4.1) id AA19938; Wed, 26 Mar 97 09:06:32 EST Date: Wed, 26 Mar 1997 09:06:40 -0500 (EST) From: "Michael G. Reed" To: Onion Routing List Subject: Re: Threat model? In-Reply-To: <3.0.32.19970325235326.0073e2c0@netcom9.netcom.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-onions@itd.nrl.navy.mil Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- On Tue, 25 Mar 1997, Lucky Green wrote: |>It has been rather silent on this list. Did NRL finish the threat model? |>Dave? I'd love to see it and I am sure so would others on the list. That's Dave's ballpark... |>And we are all still waiting for the source code... I've been working fast and furious to get the code ready for distribution...there were a few things that really needed to be cleaned up and fixed up before people start trying to run one of these things themselves (like the configuration files where you had to specify the onion routers in network order hexadecimal since I hadn't bothered with DNS resolution on them :-) I'm doing the last round of integration testing with our STS crypto code and generating some DH keys (unlike the RSA keys which I can generate in a few seconds on my machines, the DH keys take anywhere from 3 to 12 hours to generate with BSAFE). I hope to have it ready by tomorrow, but Friday or early next week is looking more likely. More info to follow... - -Michael -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMzktdE8Qx019l0ClAQEE7wP/Wse05Y3IT+T1YBeRPMmA1in+G8hs+0LO keiaRacLW+t3PBWNIAhWnfM6KfB2Xqk1fu75v+yc7Q4bhJlVH8T6FgMUJcBJXv+5 zDMFvyCae3L9EnKqTmevRswMY/5G2d33WqmqlAxFZEZqYkmYox9mmB2h6oXwK03J 3RZoe/51n2I= =uBLy -----END PGP SIGNATURE----- From majordom Thu Mar 27 00:47:19 1997 Return-Path: Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA22812; Thu, 27 Mar 97 00:47:19 EST Received: from freya.cs.umass.edu by itd.nrl.navy.mil (4.1/SMI-4.1) id AA22804; Thu, 27 Mar 97 00:47:07 EST Received: from opine.cs.umass.edu (opine.cs.umass.edu [128.119.41.246]) by freya.cs.umass.edu (8.7.6/8.6.9) with SMTP id AAA18274 for ; Thu, 27 Mar 1997 00:46:52 -0500 Message-Id: <333A09CC.446B@cs.umass.edu> Date: Thu, 27 Mar 1997 00:46:52 -0500 From: Lewis McCarthy Organization: Theoretical Computer Science Group, UMass-Amherst, X-Mailer: Mozilla 3.01Gold (X11; U; OSF1 V3.2 alpha) Mime-Version: 1.0 To: Onion Routing Mailing List Subject: Dolev talk at MIT on "Efficient Anonymous Multicast and Reception" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-onions@itd.nrl.navy.mil Precedence: bulk I gather this talk is scheduled for Mon. Apr. 14. I don't know any room/time details; they may be still TBA. Be Blackburn writes: [...] > Date: Sun, 23 Mar 1997 10:41:17 +0300 (IDT) > From: Shlomi Dolev > To: Ron Rivest > Subject: Re: talk [...] > The title: > > Efficient Anonymous Multicast and Reception > > The speaker (me): > Shlomi Dolev > Department of Math. and Computer Science > Ben-Gurion University > > The abstract: > > We examine the problem of efficient anonymous broadcast > and reception in general communication networks. We show how > anonymous broadcast/reception can be achieved with $O(1)$ amortized > communication complexity per bit sent and low computational > complexity. In contrast, all previous solutions required polynomial > (in the size of the network and security parameter) communication > complexity. Joint work with Rafail Ostrovsky. [...] -- Lewis http://www.cs.umass.edu/~lmccarth/lmkey.asc "And all the science, I don't understand; it's just my job, eight days a week..." From majordom Fri Mar 28 12:24:16 1997 Return-Path: Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA02166; Fri, 28 Mar 97 12:24:16 EST Received: from netcom13.netcom.com by itd.nrl.navy.mil (4.1/SMI-4.1) id AA02152; Fri, 28 Mar 97 12:24:08 EST Received: from sfbayarea.ccnet.com (h96-132.ccnet.com [192.215.96.132]) by netcom13.netcom.com (8.6.13/Netcom) id JAA09160; Fri, 28 Mar 1997 09:24:04 -0800 Message-Id: <3.0.32.19970328092341.006fffbc@netcom9.netcom.com> X-Sender: shamrock@netcom9.netcom.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 28 Mar 1997 09:24:19 -0800 To: "Michael G. Reed" , Onion Routing List From: Lucky Green Subject: Re: Threat model? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-onions@itd.nrl.navy.mil Precedence: bulk At 09:06 AM 3/26/97 -0500, Michael G. Reed wrote: >-----BEGIN PGP SIGNED MESSAGE----- > >On Tue, 25 Mar 1997, Lucky Green wrote: >|>It has been rather silent on this list. Did NRL finish the threat model? >|>Dave? I'd love to see it and I am sure so would others on the list. > >That's Dave's ballpark... Is Dave reading this list? [Hi, Dave :-] If so, when do you expect the thread model to be done? I don't want to rush you. I just would like to know the ETA. Thanks! >|>And we are all still waiting for the source code... > >I've been working fast and furious to get the code ready for >distribution...there were a few things that really needed to be >cleaned up and fixed up before people start trying to run one of these >things themselves (like the configuration files where you had to >specify the onion routers in network order hexadecimal since I hadn't >bothered with DNS resolution on them :-) I hear you. > I'm doing the last round of >integration testing with our STS crypto code and generating some DH >keys (unlike the RSA keys which I can generate in a few seconds on my >machines, the DH keys take anywhere from 3 to 12 hours to generate >with BSAFE). I hope to have it ready by tomorrow, but Friday or early >next week is looking more likely. More info to follow... Why are you using BSAFE? You are a research institution. You aren't required to use RSA's software implementation. You can use more efficient software. Not to mention hardware. Lately, I have been working with the Rainbow PCI boards. According to some very preliminary testing, they are worthy of our attention. Let me know if you'd like a contact there for some samples. Thanks, -- Lucky Green PGP encrypted mail preferred "I do believe that where there is a choice only between cowardice and violence, I would advise violence." Mahatma Gandhi From majordom Fri Mar 28 12:34:17 1997 Return-Path: Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA02590; Fri, 28 Mar 97 12:34:17 EST Received: from golem.itd.nrl.navy.mil by itd.nrl.navy.mil (4.1/SMI-4.1) id AA02584; Fri, 28 Mar 97 12:34:12 EST Received: (from goldschl@localhost) by golem.itd.nrl.navy.mil (8.8.5/8.7.3) id MAA08889; Fri, 28 Mar 1997 12:34:09 -0500 (EST) Date: Fri, 28 Mar 1997 12:34:09 -0500 (EST) Message-Id: <199703281734.MAA08889@golem.itd.nrl.navy.mil> From: David Goldschlag To: shamrock@netcom.com Cc: onions@itd.nrl.navy.mil In-Reply-To: <3.0.32.19970328092341.006fffbc@netcom9.netcom.com> (message from Lucky Green on Fri, 28 Mar 1997 09:24:19 -0800) Subject: BSAFE Sender: owner-onions@itd.nrl.navy.mil Precedence: bulk We don't have any particular affinity for BSAFE. We are using it because it was available, well documented, and comprehensive, and thread safe. We have written our code so other crypto packages can be substituted in for BSAFE. We would be very interested in learning about hardware implementations of RSA and symmetric crypto for Suns and other platforms that do not require much overhead to re-key. Since each onion router runs many connections at a time it has to switch between crypto engines constantly. BSAFE functions are stateless, so this is easy. David. From majordom Fri Mar 28 12:36:48 1997 Return-Path: Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA02722; Fri, 28 Mar 97 12:36:48 EST Received: from banana-jr.itd.nrl.navy.mil by itd.nrl.navy.mil (4.1/SMI-4.1) id AA02716; Fri, 28 Mar 97 12:36:42 EST Date: Fri, 28 Mar 1997 12:36:52 -0500 (EST) From: "Michael G. Reed" To: Onion Routing List Subject: Re: Threat model? In-Reply-To: <3.0.32.19970328092341.006fffbc@netcom9.netcom.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-onions@itd.nrl.navy.mil Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- On Fri, 28 Mar 1997, Lucky Green wrote: |>> I'm doing the last round of |>>integration testing with our STS crypto code and generating some DH |>>keys (unlike the RSA keys which I can generate in a few seconds on my |>>machines, the DH keys take anywhere from 3 to 12 hours to generate |>>with BSAFE). I hope to have it ready by tomorrow, but Friday or early |>>next week is looking more likely. More info to follow... |> |>Why are you using BSAFE? You are a research institution. You aren't |>required to use RSA's software implementation. You can use more efficient |>software. Not to mention hardware. Lately, I have been working with the |>Rainbow PCI boards. According to some very preliminary testing, they are |>worthy of our attention. Let me know if you'd like a contact there for some |>samples. We're using BSAFE for a couple of reasons: 1) it was essentially free to us, 2) we know it works, 3) we get great support, 4) I was too lazy to code up the crypto myself, and 5) up until recently, this was just a proof-of-concept project, so performance wasn't an issue. As for other crypto, we have a fast version of RSA for the Ultrasparc 2 (sparc v9 architecture) that was coded in assembly for us by a contractor. It's a LOT faster than BSAFE, so we use it for the onion encryption/decryption, but not for STS (this is a side technical issue that really doesn't matter at this point) -- downside is that it requires an Ultra2 (not a problem for us, but could be a kink for others :-). Hardware support would be nice, but we really don't envision many people having access to SBUS crypto boards (the prices are astronomical when we looked into it). We haven't really looked at PCI cards since you can't just slap one into a sparc (this will become a more viable option once we've ported to other platforms that have a native PCI bus) without other additional hardware. I'd be interested in any timing figures you have on hardware RSA and hardware DES (of course, we can move away from DES...the system allows for any symmetric stream cryptosystem with up to 128-bits of key) -- we know that a big bottleneck in the system now is the crypto (about 1MB/sec on DES on an Ultra2, and a HELL of a lot lower for RSA). Thanks. - -Michael -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMzwBuE8Qx019l0ClAQHPkwP/XrOeZWDdicYzRg9rREkNB2zczj2aDA+P 5v6OY/NMNPYw8Y2kBsdP68KxReGbyz5vdtTe1yM+QI+/YCqFh5OQp86B0mmSKeQ+ CxkV2vagnkEp0taPrmHTfA1Hx7Rknkhp4GTuuRmlah0ZLzmBtAKRbYlgrQNLdgSy wmDPGjAU27g= =/nNC -----END PGP SIGNATURE----- From majordom Mon Mar 31 15:24:10 1997 Return-Path: Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA00943; Mon, 31 Mar 97 15:24:10 EST Received: from golem.itd.nrl.navy.mil by itd.nrl.navy.mil (4.1/SMI-4.1) id AA00910; Mon, 31 Mar 97 15:24:00 EST Received: (from goldschl@localhost) by golem.itd.nrl.navy.mil (8.8.5/8.7.3) id PAA10892; Mon, 31 Mar 1997 15:23:57 -0500 (EST) Date: Mon, 31 Mar 1997 15:23:57 -0500 (EST) Message-Id: <199703312023.PAA10892@golem.itd.nrl.navy.mil> From: David Goldschlag To: onions@itd.nrl.navy.mil Subject: beta test sites Sender: owner-onions@itd.nrl.navy.mil Precedence: bulk Hi, We're about ready to release onion routing binaries for limited test. Testers will also get source. The code runs under Solaris 2.x on Sun Sparcs. The system runs as root if you want to run the rlogin proxy. To release any code, we need a signed license/non-disclosure agreement. I'm including an adequate one at the end. This needs your real name, address, and original signature. Sorry. The license/non-disclosure agreement does not limit who you may allow to access the onion routing system. It just limits redistribution of both the binary and source code. Also, since we will make the code (and future patches) available by FTP, please attach to your letter the username/password that you want to use, and the IP address of the machine that you will be ftp'ing from. Since configuration needs to be coordinated among the network, please send me the following information also (by e-mail is fine): What hardware you will be running onion routing on. Name and IP address of the machine that will run onion routing. Several port numbers on that machine: We suggest the following standard ports: 9500 for connections from proxies. 9501 for connections from other onion routers. 9505 for debugging. 9000 for the HTTP proxy. 9200 for the anonymizing HTTP proxy. Thanks, David. Here's an adequate license/non-disclosure letter, that Paul might write, if he needed to and wanted to test the system. From: Paul Syverson Naval Research Laboratory Washington, DC 20375-5337 (202) 767-2389 syverson@itd.nrl.navy.mil To: David Goldschlag Naval Research Laboratory Center for High Assurance Computer Systems Washington, DC 20375-5337 (202) 404-7310 Dear David: I would like to run your onion routing system. I am a US citizen, and I agree not to redistribute the source or binary code, and to provide reasonable protection against its unintended redistribution. I understand that this license is valid only through the end of 1997, and may be revoked earlier by the US government, and agree to destroy my copies of the code at that time. Yours truly, (Paul's real signature here) Paul Syverson From majordom Tue Apr 1 16:17:46 1997 Return-Path: Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA20789; Tue, 1 Apr 97 16:17:46 EST Received: from freya.cs.umass.edu by itd.nrl.navy.mil (4.1/SMI-4.1) id AA20781; Tue, 1 Apr 97 16:17:36 EST Received: from opine.cs.umass.edu (opine.cs.umass.edu [128.119.41.246]) by freya.cs.umass.edu (8.7.6/8.6.9) with SMTP id QAA04226 for ; Tue, 1 Apr 1997 16:06:15 -0500 Message-Id: <33417B5D.ABD@cs.umass.edu> Date: Tue, 01 Apr 1997 16:17:17 -0500 From: Lewis McCarthy Organization: Theoretical Computer Science Group, UMass-Amherst, X-Mailer: Mozilla 3.01Gold (X11; U; OSF1 V3.2 alpha) Mime-Version: 1.0 To: Onion Routing Mailing List Subject: [Fwd: Monday, Apr. 14th - TALK by Shlomi Dolev] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-onions@itd.nrl.navy.mil Precedence: bulk Here's the time & place of the upcoming talk at MIT I mentioned: Be Blackburn wrote: > > CRYPTOGRAPHY AND INFORMATION SECURITY GROUP SEMINAR > > Date: Monday, April 14 > Time: 4:00 p.m. > Place: NE43-628, 6th floor conference room > > EFFICIENT ANONYMOUS MULTICAST AND RECEPTION > > Shlomi Dolev > Department of Math. and Computer Science > Ben-Gurion University Unfortunately I have to hold office hours on Monday evenings, so I can't make it out to this. If someone else goes I'd be interested in hearing about it. -- Lewis http://www.cs.umass.edu/~lmccarth/lmkey.asc "And all the science, I don't understand; it's just my job, eight days a week..." From majordom Tue Apr 8 14:36:52 1997 Return-Path: Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA08136; Tue, 8 Apr 97 14:36:52 EDT Received: from golem.itd.nrl.navy.mil by itd.nrl.navy.mil (4.1/SMI-4.1) id AA08128; Tue, 8 Apr 97 14:36:44 EDT Received: (from goldschl@localhost) by golem.itd.nrl.navy.mil (8.8.5/8.7.3) id OAA22821; Tue, 8 Apr 1997 14:36:42 -0400 (EDT) Date: Tue, 8 Apr 1997 14:36:42 -0400 (EDT) Message-Id: <199704081836.OAA22821@golem.itd.nrl.navy.mil> From: David Goldschlag To: onions@itd.nrl.navy.mil Subject: dinner during Oakland Sender: owner-onions@itd.nrl.navy.mil Precedence: bulk Hi, Raph Levien suggested that people interested in onions get together during Oakland. I think that this is a great idea. For the NRL crowd, Tuesday May 6th at about 7:30pm would be a good time. How does this sound for others? Thanks, David. From majordom Tue Apr 8 15:37:36 1997 Return-Path: Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA11062; Tue, 8 Apr 97 15:37:36 EDT Received: from blacklodge.c2.net by itd.nrl.navy.mil (4.1/SMI-4.1) id AA11056; Tue, 8 Apr 97 15:37:28 EDT Received: (from raph@localhost) by blacklodge.c2.net (8.8.5/8.7.3) id MAA26550; Tue, 8 Apr 1997 12:37:14 -0700 (PDT) Date: Tue, 8 Apr 1997 12:37:14 -0700 (PDT) From: Raph Levien X-Sender: raph@blacklodge.c2.net To: David Goldschlag Cc: onions@itd.nrl.navy.mil Subject: Re: dinner during Oakland In-Reply-To: <199704081836.OAA22821@golem.itd.nrl.navy.mil> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-onions@itd.nrl.navy.mil Precedence: bulk On Tue, 8 Apr 1997, David Goldschlag wrote: > > Hi, > > Raph Levien suggested that people interested in onions get together > during Oakland. I think that this is a great idea. I hope so too - I think it would be a great chance to meet and discuss the ideas further. > For the NRL crowd, Tuesday May 6th at about 7:30pm would be a good > time. How does this sound for others? It's not ideal for me. I've tentatively scheduled a dinner with someone else for that evening. Also, since I was hoping to present one of the 5-minute talks, and also prepare the dinner, I wouldn't be able to do both on that day. If that's the only day available, I can switch my other dinner, and we can have our dinner at a restaurant on Tuesday. Otherwise, any of the other days (from Saturday to Wednesday) would probably work out. I make a pretty mean veggie lasagna and was planning to serve roasted onions as s side dish, in keeping with the theme. My apartment is only six blocks from the Claremont and would be a better place to spread out and talk than most restaurants. So if you'd all let me know what days and times are available, I'll try to coordinate. Raph From majordom Tue Apr 8 15:59:31 1997 Return-Path: Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA12471; Tue, 8 Apr 97 15:59:31 EDT Received: from golem.itd.nrl.navy.mil by itd.nrl.navy.mil (4.1/SMI-4.1) id AA12463; Tue, 8 Apr 97 15:59:23 EDT Received: (from goldschl@localhost) by golem.itd.nrl.navy.mil (8.8.5/8.7.3) id PAA22914; Tue, 8 Apr 1997 15:59:21 -0400 (EDT) Date: Tue, 8 Apr 1997 15:59:21 -0400 (EDT) Message-Id: <199704081959.PAA22914@golem.itd.nrl.navy.mil> From: David Goldschlag To: onions@itd.nrl.navy.mil In-Reply-To: (message from Raph Levien on Tue, 8 Apr 1997 12:37:14 -0700 (PDT)) Subject: Re: dinner during Oakland Sender: owner-onions@itd.nrl.navy.mil Precedence: bulk It's always hard to coordinate a group. Sunday night there is probably a program committee meeting. Monday night is the conference reception, and people might leave by Wednesday. Does anyone else have a preference? David. From majordom Tue Apr 8 16:56:48 1997 Return-Path: Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA15087; Tue, 8 Apr 97 16:56:48 EDT Received: from einstein.veriweb.com by itd.nrl.navy.mil (4.1/SMI-4.1) id AA15081; Tue, 8 Apr 97 16:56:40 EDT Received: (from jeremey@localhost) by einstein.veriweb.com (8.8.5/8.6.9) id NAA30922; Tue, 8 Apr 1997 13:59:15 -0700 Message-Id: <334AB197.3C59D86D@veriweb.com> Date: Tue, 08 Apr 1997 13:59:03 -0700 From: Jeremey Barrett Organization: VeriWeb Internet Corp. X-Mailer: Mozilla 3.01 (X11; U; Linux 2.0.11 i586) To: David Goldschlag Cc: onions@itd.nrl.navy.mil Subject: Re: dinner during Oakland References: <199704081836.OAA22821@golem.itd.nrl.navy.mil> Sender: owner-onions@itd.nrl.navy.mil Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- David Goldschlag wrote: > > Hi, > > Raph Levien suggested that people interested in onions get together > during Oakland. I think that this is a great idea. Agreed. > > For the NRL crowd, Tuesday May 6th at about 7:30pm would be a good > time. How does this sound for others? > Sounds fine, anytime is good for me. Jeremey. - -- Jeremey Barrett VeriWeb Internet Corp. Crypto, Ecash, Commerce Systems http://www.veriweb.com/ PGP key fingerprint = 3B 42 1E D4 4B 17 0D 80 DC 59 6F 59 04 C3 83 64 -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBM0qxoy/fy+vkqMxNAQG2kgP8Cy6Cmdg+vxw3zS3EG4Uu5wUFcJOQkhBz y1gHQzLubNhHhR72gnhvoUqwaawPFIuBCGv3/5Jv82EbThylLbb1RcPmD02YzABc Sskb0edwnT0hXOQwlndRZARVDRWMDZRuM3MwPQn/IUtjdqd0cn0XYDnlIcqM49Ks QUEflHdcH1Q= =BMVt -----END PGP SIGNATURE----- From majordom Tue Apr 8 17:33:34 1997 Return-Path: Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA16424; Tue, 8 Apr 97 17:33:34 EDT Received: from netcom19.netcom.com by itd.nrl.navy.mil (4.1/SMI-4.1) id AA16418; Tue, 8 Apr 97 17:33:27 EDT Received: from sfbayarea.ccnet.com (shamrock@netcom19.netcom.com [192.100.81.132]) by netcom19.netcom.com (8.6.13/Netcom) id OAA08821; Tue, 8 Apr 1997 14:33:22 -0700 Message-Id: <3.0.32.19970408142922.00741df8@netcom13.netcom.com> X-Sender: shamrock@netcom13.netcom.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 08 Apr 1997 14:33:45 -0700 To: David Goldschlag , onions@itd.nrl.navy.mil From: Lucky Green Subject: Re: dinner during Oakland Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-onions@itd.nrl.navy.mil Precedence: bulk At 03:59 PM 4/8/97 -0400, David Goldschlag wrote: > >It's always hard to coordinate a group. Sunday night there is >probably a program committee meeting. Monday night is the conference >reception, and people might leave by Wednesday. > >Does anyone else have a preference? Any day will work for me. Looking forward to an opportunity to discuss some ideas in more detail, -- Lucky Green PGP encrypted mail preferred "I do believe that where there is a choice only between cowardice and violence, I would advise violence." Mahatma Gandhi From majordom Tue Apr 8 18:23:33 1997 Return-Path: Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA17519; Tue, 8 Apr 97 18:23:33 EDT Received: from homer.communities.com by itd.nrl.navy.mil (4.1/SMI-4.1) id AA17511; Tue, 8 Apr 97 18:23:27 EDT Received: from [205.162.51.35] (pericles.communities.com [205.162.51.35]) by homer.communities.com (8.7.5/8.7.3) with ESMTP id RAA25231 for ; Tue, 8 Apr 1997 17:05:41 -0700 X-Sender: mccoy@mail.communities.com Message-Id: In-Reply-To: <3.0.32.19970408142922.00741df8@netcom13.netcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 8 Apr 1997 14:20:46 -0800 To: onions@itd.nrl.navy.mil From: Jim McCoy Subject: Re: dinner during Oakland Sender: owner-onions@itd.nrl.navy.mil Precedence: bulk Lucky writes: >At 03:59 PM 4/8/97 -0400, David Goldschlag wrote: >> >>It's always hard to coordinate a group. Sunday night there is >>probably a program committee meeting. Monday night is the conference >>reception, and people might leave by Wednesday. >> >>Does anyone else have a preference? > >Any day will work for me. Ditto. jim From majordom Wed Apr 9 16:27:07 1997 Return-Path: Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA23668; Wed, 9 Apr 97 16:27:07 EDT Received: from golem.itd.nrl.navy.mil by itd.nrl.navy.mil (4.1/SMI-4.1) id AA23644; Wed, 9 Apr 97 16:27:00 EDT Received: (from goldschl@localhost) by golem.itd.nrl.navy.mil (8.8.5/8.7.3) id QAA23564; Wed, 9 Apr 1997 16:26:57 -0400 (EDT) Date: Wed, 9 Apr 1997 16:26:57 -0400 (EDT) Message-Id: <199704092026.QAA23564@golem.itd.nrl.navy.mil> From: David Goldschlag To: onions@itd.nrl.navy.mil Subject: onions dinner Sender: owner-onions@itd.nrl.navy.mil Precedence: bulk So Monday after the reception is probably OK also. Raph, what do you prefer? (We could meet at a restaurant for dinner in either case, if that is easier.) David. From majordom Wed Apr 9 20:19:45 1997 Return-Path: Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA29502; Wed, 9 Apr 97 20:19:45 EDT Received: from blacklodge.c2.net by itd.nrl.navy.mil (4.1/SMI-4.1) id AA29494; Wed, 9 Apr 97 20:19:37 EDT Received: (from raph@localhost) by blacklodge.c2.net (8.8.5/8.7.3) id RAA24287; Wed, 9 Apr 1997 17:19:35 -0700 (PDT) Date: Wed, 9 Apr 1997 17:19:35 -0700 (PDT) From: Raph Levien X-Sender: raph@blacklodge.c2.net To: David Goldschlag Cc: onions@itd.nrl.navy.mil Subject: Re: onions dinner In-Reply-To: <199704092026.QAA23564@golem.itd.nrl.navy.mil> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-onions@itd.nrl.navy.mil Precedence: bulk On Wed, 9 Apr 1997, David Goldschlag wrote: > > So Monday after the reception is probably OK also. > > Raph, what do you prefer? (We could meet at a restaurant for dinner > in either case, if that is easier.) Monday after the reception is definitely better for me. I'd still like to cook, unless I hear an overwhelming preference for a restaurant. Raph From majordom Thu Apr 10 11:04:49 1997 Return-Path: Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA20435; Thu, 10 Apr 97 11:04:49 EDT Received: from banana-jr.itd.nrl.navy.mil by itd.nrl.navy.mil (4.1/SMI-4.1) id AA20421; Thu, 10 Apr 97 11:04:39 EDT Date: Thu, 10 Apr 1997 11:04:48 -0400 (EDT) From: "Michael G. Reed" Reply-To: "Michael G. Reed" To: Onion Routing List Subject: New Onion Router on-line... Message-Id: X-Personal: False X-Anonymous: False Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-onions@itd.nrl.navy.mil Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- All- The newest code release (Beta1 -- what's going out to the testers) of the onion-routing software is now on-line on onion-router.nrl.navy.mil. You will see some *BIG* performance changes with this (for the worse mostly) since we are now doing: 1) Full RSA and DES (this was turned off during earlier testing phases so we could track packets for debugging). 2) Full Mixing at 10microsecond intervals across all VCI's in the system. This hits hard on both latency and throughput of the system, but the system appears to be robust under some of the most abusive conditions we could generate. Now that Beta1 is ready to go out, we are starting to talk about Beta2...we've learned a *LOT* of important lessons from Beta1 in terms of system throughput, latency, design, etc. and we plan to completely re-engineer the design for Beta2. I'll be sending out a complete technical specification of what we did in Beta1 by early next week, and more importantly, what we plan on doing for Beta2 (and why we are changing the implementation so radically). I would *REALLY* like to see feedback on both the Beta1 design and the proposed Beta2 design since (as of right now) the idea is to use Beta1 to conduct some tests, but build Beta2 "the right way" so it can actually be deployed for full use on the Internet. Comments? - -Michael -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBM00BlE8Qx019l0ClAQH6+wP/Wyi9ytJsY0Ke1JhJ8QPc2zzn2gugForb WMlN+3ZPF9UbKRodlhhLtLCC4tva5cBcb8z/KCB3sZC4O/x62fksvuF/8nBFRw7K KCDQLE7eo19+V3UWAnxBFWF7D6ual2y7izJKwDA2XvinFUh8o0ZgQwnMc/vVqqZJ hQp+7lauqKE= =eRrq -----END PGP SIGNATURE----- From majordom Tue Apr 15 10:35:47 1997 Return-Path: Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA17088; Tue, 15 Apr 97 10:35:47 EDT Received: from golem.itd.nrl.navy.mil by itd.nrl.navy.mil (4.1/SMI-4.1) id AA17080; Tue, 15 Apr 97 10:35:34 EDT Received: (from goldschl@localhost) by golem.itd.nrl.navy.mil (8.8.5/8.7.3) id KAA26964; Tue, 15 Apr 1997 10:35:33 -0400 (EDT) Date: Tue, 15 Apr 1997 10:35:33 -0400 (EDT) Message-Id: <199704151435.KAA26964@golem.itd.nrl.navy.mil> From: David Goldschlag To: onions@itd.nrl.navy.mil Subject: Oakland Dinner Sender: owner-onions@itd.nrl.navy.mil Precedence: bulk Hi, So I propose that we meet at Raph's apartment after the reception on Monday May 5th. How does this sound? Raph, can you please provide details? Thanks, David. From majordom Tue Apr 15 13:47:07 1997 Return-Path: Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA26749; Tue, 15 Apr 97 13:47:07 EDT Received: from blacklodge.c2.net by itd.nrl.navy.mil (4.1/SMI-4.1) id AA26727; Tue, 15 Apr 97 13:46:56 EDT Received: (from raph@localhost) by blacklodge.c2.net (8.8.5/8.7.3) id KAA01885; Tue, 15 Apr 1997 10:46:34 -0700 (PDT) Date: Tue, 15 Apr 1997 10:46:34 -0700 (PDT) From: Raph Levien X-Sender: raph@blacklodge.c2.net To: David Goldschlag Cc: onions@itd.nrl.navy.mil Subject: Re: Oakland Dinner In-Reply-To: <199704151435.KAA26964@golem.itd.nrl.navy.mil> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-onions@itd.nrl.navy.mil Precedence: bulk On Tue, 15 Apr 1997, David Goldschlag wrote: > > Hi, > > So I propose that we meet at Raph's apartment after the reception on > Monday May 5th. > > How does this sound? Raph, can you please provide details? This sounds great to me. Here are the details: My apartment is 345 62nd St. in Oakland. You just go down Claremont Ave from the hotel, then take a gentle left onto 62nd at College (it's a six-way intersection). We're in the big yellow house at the end of the block (just before you get to Hillegass), on the left. It's about a 15 minute walk, or you could drive. I'm planning to prepare vegetarian lasagna, salad, and roasted onions. Plan on being there around 7:30. Dinner will be ready shortly thereafter. Please RSVP so I have some idea how much to cook. Look forward to seeing you there! Raph From majordom Thu Apr 17 17:42:10 1997 Return-Path: Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA21828; Thu, 17 Apr 97 17:42:10 EDT Received: from freya.cs.umass.edu by itd.nrl.navy.mil (4.1/SMI-4.1) id AA21811; Thu, 17 Apr 97 17:42:02 EDT Received: from opine.cs.umass.edu (opine.cs.umass.edu [128.119.41.246]) by freya.cs.umass.edu (8.7.6/8.6.9) with SMTP id RAA15799 for ; Thu, 17 Apr 1997 17:42:01 -0400 Message-Id: <33569928.41C6@cs.umass.edu> Date: Thu, 17 Apr 1997 17:42:00 -0400 From: Lewis McCarthy Organization: Theoretical Computer Science Group, UMass-Amherst, X-Mailer: Mozilla 3.01Gold (X11; U; OSF1 V3.2 alpha) Mime-Version: 1.0 To: Onion Routing List Subject: [Fwd: A new system for anonymity on the web] Content-Type: message/news Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-onions@itd.nrl.navy.mil Precedence: bulk Path: kernighan.cs.umass.edu!umass.edu!cam-news-feed5.bbnplanet.com!cam-news-hub1.bbnplanet.com!cpk-news-hub1.bbnplanet.com!news.bbnplanet.com!newsxfer3.itd.umich.edu!news.eecs.umich.edu!quip.eecs.umich.edu!rubin From: rubin@quip.eecs.umich.edu (Aviel Rubin) Newsgroups: sci.crypt,alt.security Subject: A new system for anonymity on the web Date: 17 Apr 1997 13:46:57 GMT Organization: University of Michigan, Ann Arbor, Michigan, USA Message-ID: <5j59kh$pu6$1@news.eecs.umich.edu> NNTP-Posting-Host: quip.eecs.umich.edu Xref: kernighan.cs.umass.edu sci.crypt:59170 alt.security:27248 We are developing a new system called "Crowds" for achieving anonymity on the web. A preliminary description of the system can be found on our web pages. Any comments/criticisms are welcomed and appreciated. Mike Reiter (http://www.research.att.com/~reiter/) Avi Rubin (http://www.research.att.com/~rubin/) From majordom Tue May 6 05:28:14 1997 Return-Path: Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA10040; Tue, 6 May 97 05:28:14 EDT Received: from netcom21.netcom.com by itd.nrl.navy.mil (4.1/SMI-4.1) id AA10034; Tue, 6 May 97 05:28:06 EDT Received: from sfbayarea.ccnet.com (shamrock@netcom21.netcom.com [192.100.81.135]) by netcom21.netcom.com (8.6.13/Netcom) id CAA24618; Tue, 6 May 1997 02:28:01 -0700 Message-Id: <3.0.32.19970506022902.00721d3c@netcom13.netcom.com> X-Sender: shamrock@netcom13.netcom.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 06 May 1997 02:29:23 -0700 To: onions@itd.nrl.navy.mil From: Lucky Green Subject: Thanks for the dinner and some pointers Cc: reiter@research.att.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-onions@itd.nrl.navy.mil Precedence: bulk I would like to thank everybody that showed up for the Onion Dinner and of course would like to thank our host Raph for organizing it. Some issues came up during the our conversation that I would like to address. o I think it is clear that we all have the same goal: to provide a privacy protecting infrastructure for near real-time net connections. Sure, some people out there will flame you because they are convinced that it all is giant plot by NSA/NRL/AT&T, undoubtedly organized by the Illuminati, the Elders of Zion, and of course the Trilateral Commission. The people on this list do not fall into this category. You'll just have to ignore the nay sayers, though some of them may have some valid technical advise to contribute. o The various systems proposed all have their advantages and drawbacks. There is good reason to continue parallel development. o None of us really has any hard numbers to back up their assumptions. I believe further development would benefit greatly from subjecting the systems to information theoretic/signal analysis. For example, it seems to me that we are all just guessing if additional cover traffic has to be added or not. My experience with remailers suggest it does, others disagree. But nobody has actually done the math to prove or disprove either claim. o For any of these systems to see widespread deployment, they have to work on other operating systems, especially the free UNIX versions such as FreeBSD and Linux. Furthermore, the software has to compile with a crypto library other than the difficult to obtain BSAFE. The first such library that jumps to mind is the tremendously popular SSLeay, written by Eric "DES" Young himself. SSLeay tends to produce the fastest code out there. To quote Ian Goldberg "it is the library RSA wished they were selling." The SSLeay FAQ is available from http://www.psy.uq.oz.au/~ftp/Crypto It lists the numerous world wide distribution sites. That's all for now. Time to go to bed :-) -- Lucky Green PGP encrypted mail preferred "I do believe that where there is a choice only between cowardice and violence, I would advise violence." Mahatma Gandhi From majordom Tue May 6 05:36:52 1997 Return-Path: Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA10122; Tue, 6 May 97 05:36:52 EDT Received: from netcom21.netcom.com by itd.nrl.navy.mil (4.1/SMI-4.1) id AA10116; Tue, 6 May 97 05:36:45 EDT Received: from sfbayarea.ccnet.com (shamrock@netcom21.netcom.com [192.100.81.135]) by netcom21.netcom.com (8.6.13/Netcom) id CAA25226; Tue, 6 May 1997 02:36:41 -0700 Message-Id: <3.0.32.19970506023752.00721d3c@netcom13.netcom.com> X-Sender: shamrock@netcom13.netcom.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 06 May 1997 02:38:03 -0700 To: onions@itd.nrl.navy.mil From: Lucky Green Subject: FWD: more RSA numbers Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-onions@itd.nrl.navy.mil Precedence: bulk Here are some numbers the NRL folks might find interesting. >Return-Path: >Date: Fri, 2 May 1997 11:05:03 +1000 (EST) >From: Eric Young >To: coderpunks@toad.com >Subject: more RSA numbers >Sender: owner-coderpunks@toad.com >X-Status: > > >I was able to build my current SSLeay release on a 400mhz DEC Alpha (21164A) >last night and some of the RSA numbers are quite interesting. >Definitly the crypto CPU of choice if you can get a large enough heat sink >into the room :-). > >Surfice it to say, I can see the SET processing yards either with lots of >hardware or lots of alphas :-). > > alpha-400 ppro-200 R10k-195 usparc-167 PCC604-100 pent-100 >rsa 512 bits 0.003s 0.010s 0.008s 0.021s 0.019s 0.024s >rsa 1024 bits 0.013s 0.045s 0.043s 0.127s 0.096s 0.119s >rsa 2048 bits 0.081s 0.260s 0.280s 0.891s 0.614s 0.744s >rsa 4096 bits 0.583s 1.690s 2.064s 6.805s 4.433s 5.430s > >or in RSA/sec > >rsa 512 bits 333.3 100.0 125.0 47.6 52.6 41.6 >rsa 1024 bits 76.9 22.2 23.2 7.8 10.4 8.4 >rsa 2048 bits 12.3 3.8 3.5 1.1 1.6 1.3 > >assuming every-one ramps upto 400mhz and things scale linearly > >rsa 512 bits 333.3 200.0 256.4 114.0 210.4 166.4 >rsa 1024 bits 76.9 44.4 47.5 27.3 41.6 33.6 >rsa 2048 bits 12.3 7.6 7.1 2.5 6.4 5.2 > >So on a clock for clock, the alpha is good but the pentium pro is not bad. >The alpha takes a hit at the low end because the C code becomes a bit of >a bottle neck (the RSA multiplies are only 256^256%256 so only 4*4 arrays >are being multipied. > >The caveats are that the alpha uses asm to get 64*64->128 and the pentium >pro/pentium uses asm but then the architeture is retarded :-). The R10000 was >only compiling in 32bit mode (the 64bit compiler was not installed :-(. >Potentially its numbers could be 2 times better. Otherwise all systems were >running under unix and either using system compilers or gcc. > >Oh, for the block ciphers/digests... > Alpha 400 ppro 200 > MD5 -> 26700k/s 16800k/s > SHA1 -> 15900k/s 9340k/s > RC4 -> 19300k/s 15260k/s > des-cbc -> 4920k/s 3980k/s > 3des-cbc -> 1850k/s 1563k/s > blowfish-cbc -> 9672k/s 6220k/s > These are all for 32k blocks and no special tweaking to the code, > (except for the DES asm for the pentium pro). > >eric (with more numbers....) > > > -- Lucky Green PGP encrypted mail preferred "I do believe that where there is a choice only between cowardice and violence, I would advise violence." Mahatma Gandhi From majordom Tue May 6 12:38:46 1997 Return-Path: Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA26212; Tue, 6 May 97 12:38:46 EDT Received: from einstein.veriweb.com by itd.nrl.navy.mil (4.1/SMI-4.1) id AA26204; Tue, 6 May 97 12:38:39 EDT Received: (from jeremey@localhost) by einstein.veriweb.com (8.8.5/8.6.9) id JAA04546; Tue, 6 May 1997 09:42:11 -0700 Message-Id: <336F5F60.574F34C0@veriweb.com> Date: Tue, 06 May 1997 09:42:08 -0700 From: Jeremey Barrett Organization: VeriWeb Internet Corp. X-Mailer: Mozilla 4.0b3C (X11; I; Linux 2.0.11 i586) To: Raph Levien , onions@itd.nrl.navy.mil Subject: Dinner X-Priority: 3 (Normal) References: <336E3B29.16D0B9B0@acm.org> Sender: owner-onions@itd.nrl.navy.mil Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- My apologies for not making the dinner. I was on a "non-stop" flight on Reno Air, which stopped in Las Vegas for two hours and changed planes. Jeremey. - -- Jeremey Barrett VeriWeb Internet Corp. Crypto, Ecash, Commerce Systems http://www.veriweb.com/ PGP key fingerprint = 3B 42 1E D4 4B 17 0D 80 DC 59 6F 59 04 C3 83 64 -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBM29fYi/fy+vkqMxNAQFawQQAsxF5X28EIzZ/YZiY1e+nFMFiLZhR0onp KnG8fgPnrjC2RgtsT98WGUmjjJDSUGD9+acObDfC5UFbvZBnoGRHjQyjjsIlTL6L ae+HFwryzCWWN5YTNH13GU7Gxu/ebqUqJiUaqZLHNr1sW+zlDcajDl3ypocqxPMS dZpyoqB22rk= =tSR+ -----END PGP SIGNATURE----- From majordom Wed May 7 20:19:28 1997 Return-Path: Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA12063; Wed, 7 May 97 20:19:28 EDT Received: from golem.itd.nrl.navy.mil by itd.nrl.navy.mil (4.1/SMI-4.1) id AA12056; Wed, 7 May 97 20:19:23 EDT Received: (from goldschl@localhost) by golem.itd.nrl.navy.mil (8.8.5/8.7.3) id UAA06482; Wed, 7 May 1997 20:19:20 -0400 (EDT) Date: Wed, 7 May 1997 20:19:20 -0400 (EDT) Message-Id: <199705080019.UAA06482@golem.itd.nrl.navy.mil> From: David Goldschlag To: onions@itd.nrl.navy.mil Subject: dinner, etc. Sender: owner-onions@itd.nrl.navy.mil Precedence: bulk Hi, I'd like to thank Raph for a wonderful dinner and a very interesting evening. I am very hopeful that we can work together to develop an infrastructure for private communication. Over the next few days, we will get our system running on both Solaris 2.5 and 2.4. We'll also integrate SSLeay, so the crypto will not introduce licensing issues. At that point, we'll be ready to release (in North America) source and binary codes to anyone who has mailed me a signed license/non-disclosure agreement. Several of you have volunteered to run beta onion routers. If you are running 2.5, we can integrate your machine into the onion network now. If you are running 2.4, we'll have to wait a bit. Our near term plans after that are to develop a careful attack model of onion routing and write it up. We are also re-architecting the system and will try to make the new implementation as portable as we can. Thanks, David. Here's an adequate license/non-disclosure letter, that Paul might write, if he needed to and wanted to test the system. From: Paul Syverson Naval Research Laboratory Washington, DC 20375-5337 (202) 767-2389 syverson@itd.nrl.navy.mil To: David Goldschlag Naval Research Laboratory Center for High Assurance Computer Systems Washington, DC 20375-5337 (202) 404-7310 Dear David: I would like to experiment with Onion Routing. I am a US citizen, and I agree not to redistribute the source or binary code, and to provide reasonable protection against its unintended redistribution. I understand that this license is valid only through the end of 1997, and may be revoked earlier by the US government, and agree to destroy my copies of the code at that time. Yours truly, (Paul's real signature here) Paul Syverson From majordom Thu May 8 00:45:17 1997 Return-Path: Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA16423; Thu, 8 May 97 00:45:17 EDT Received: from netcom18.netcom.com by itd.nrl.navy.mil (4.1/SMI-4.1) id AA16417; Thu, 8 May 97 00:45:12 EDT Received: from sfbayarea.ccnet.com (shamrock@netcom18.netcom.com [192.100.81.131]) by netcom18.netcom.com (8.6.13/Netcom) id VAA16983; Wed, 7 May 1997 21:45:08 -0700 Message-Id: <3.0.32.19970507214556.0070de00@netcom13.netcom.com> X-Sender: shamrock@netcom13.netcom.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 07 May 1997 21:46:10 -0700 To: onions@itd.nrl.navy.mil From: Lucky Green Subject: Re: dinner, etc. Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-onions@itd.nrl.navy.mil Precedence: bulk At 08:19 PM 5/7/97 -0400, David Goldschlag wrote: [...] >Over the next few days, we will get our system running on both Solaris >2.5 and 2.4. We'll also integrate SSLeay, so the crypto will not >introduce licensing issues. Patent licensing is an odd area and I certainly won't claim to understand completely. IANAL and all that. But I have a decent working knowledge of the topic. Using SSLeay has many advantages. Amongst them is the fact that SSLeay is widely available, solidly coded, fast, and talking care of all the ugly X.509 stuff for you (the latter not being applicable for Onion Routers). Oh, and SSLeay is widely portable. But SSLeay does not fully solve all patent issues. Using SSLeay in the US is generally considered fine as long as the project falls under the research exemption of the patent law. At this stage, Onion Routers should have no problem meeting this requirement. However, at some stage and for some users, the research exemption may no longer be met. For such a situation, it may be beneficial to be able to use BSAFE. I would suggest that the Onion Routers use SSLeay as the interface. But you also may want to consider writing some glue between the SSLeay interface and BSAFE for those that wish to use BSAFE. Funny tidbit: BSAFE uses Eric Young's code for DES. But it uses an older version of his code. I am told that he meanwhile has achieved a 30% speed increase which is reflected in the latest versions of SSLeay. Pointer: the company selling the SCSI RSA accelerator is nCipher http://www.ncipher.com/ -- Lucky Green PGP encrypted mail preferred "I do believe that where there is a choice only between cowardice and violence, I would advise violence." Mahatma Gandhi From majordom Thu Jun 12 02:58:43 1997 Return-Path: Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA27814; Thu, 12 Jun 97 02:58:43 EDT Received: from netcom4.netcom.com by itd.nrl.navy.mil (4.1/SMI-4.1) id AA27808; Thu, 12 Jun 97 02:58:35 EDT Received: from slirp.netcom.com (ppp-206-170-4-53.wnck11.pacbell.net [206.170.4.53]) by netcom4.netcom.com (8.6.13/Netcom) id XAA21609; Wed, 11 Jun 1997 23:58:33 -0700 Message-Id: <3.0.2.32.19970612000004.03be128c@netcom13.netcom.com> X-Sender: shamrock@netcom13.netcom.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 b4 (32) Date: Thu, 12 Jun 1997 00:00:04 -0700 To: onions@itd.nrl.navy.mil From: Lucky Green Subject: Status? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-onions@itd.nrl.navy.mil Precedence: bulk How are the Onion Routers coming along? Waiting to be a beta tester, --Lucky Green PGP encrypted mail preferred. Put a stake through the heart of DES! Join the quest at http://www.frii.com/~rcv/deschall.htm From majordom Thu Jun 12 08:32:19 1997 Return-Path: Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA05095; Thu, 12 Jun 97 08:32:19 EDT Received: from banana-jr.itd.nrl.navy.mil by itd.nrl.navy.mil (4.1/SMI-4.1) id AA05089; Thu, 12 Jun 97 08:32:11 EDT Date: Thu, 12 Jun 1997 08:32:30 -0400 (EDT) From: "Michael G. Reed" Reply-To: "Michael G. Reed" To: Lucky Green Cc: onions@itd.nrl.navy.mil Subject: Re: Status? In-Reply-To: <3.0.2.32.19970612000004.03be128c@netcom13.netcom.com> Message-Id: X-Personal: False X-Anonymous: False Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-onions@itd.nrl.navy.mil Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- On Thu, 12 Jun 1997, Lucky Green wrote: |>How are the Onion Routers coming along? Things were put on hold for a few weeks as our entire branch moved offices. I'm sure you can imagine the disarray :-) Anyway, I recently got back into the swing of things and I've managed to pound out a series of bugs. There has also been some pretty heated discussion here about how to evolve the system (forthcoming -- we're trying to move this discussion to the onions mailing list). If all goes well today and tomorrow, David will be overseeing another distribution next week while I'm out of town (this probably will still not have SSLEAY support, but that will be soon...sooner if someone can give me a hand with the API :-). We're currently doing some heavy testing of the system with an automatic tester (we've already flushed out a half dozen bugs we had no idea existed, and tracked down the last two we did know about) with a "abuse-rate" of about 40,000 hits per hour with RSA shut off (it's a lot easier to beat on the system when we don't run the RSA operations...we test with it on as well, but don't get nearly as many hits through the system). More info soon... - -Michael -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBM5/sYk8Qx019l0ClAQE/RwP/ZZU4cqQEKiF196wWRkNDbt4x1gPpMmp6 GrJvMXNsGHmNGZB8XnbBAhR4G5dPi/7DeoJZDXcHszld5SpbKpkXuiwcPwk1WcEb Arym/EZiX6RSk+c7B6mPSXss+5Acd6qQO9IAzBfkghCisa1YAmu5CYTulzLotvov UOPic7OCfp8= =GOF2 -----END PGP SIGNATURE----- From majordom Sat Jul 26 01:01:32 1997 Return-Path: Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA21121; Sat, 26 Jul 97 01:01:32 EDT Received: from netcom8.netcom.com by itd.nrl.navy.mil (4.1/SMI-4.1) id AA21108; Sat, 26 Jul 97 01:01:25 EDT Received: from slirp.netcom.com (shamrock@netcom6.netcom.com [192.100.81.114]) by netcom8.netcom.com (8.6.13/Netcom) id WAA22293; Fri, 25 Jul 1997 22:01:22 -0700 Message-Id: <3.0.2.32.19970725220105.006c68f4@netcom10.netcom.com> X-Sender: shamrock@netcom10.netcom.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 b4 (32) Date: Fri, 25 Jul 1997 22:01:05 -0700 To: onions@itd.nrl.navy.mil From: Lucky Green Subject: Status update, please Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-onions@itd.nrl.navy.mil Precedence: bulk Folks, What is going on with the Onion Routers? I has been quite a while... I am waiting to run some sites on FreeBSD/Linux. How is the port to SSLeay coming? Thanks, --Lucky Green PGP encrypted mail preferred. DES is dead! Please join in breaking RC5-56. http://rc5.distributed.net/ From majordom Mon Jul 28 13:23:09 1997 Return-Path: Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA16328; Mon, 28 Jul 97 13:23:09 EDT Received: from carnap.itd.nrl.navy.mil by itd.nrl.navy.mil (4.1/SMI-4.1) id AA16315; Mon, 28 Jul 97 13:23:02 EDT From: syverson@itd.nrl.navy.mil (Paul Syverson) Received: (from syverson@localhost) by carnap.itd.nrl.navy.mil (8.8.5/8.7.3) id NAA06790; Mon, 28 Jul 1997 13:22:59 -0400 (EDT) Date: Mon, 28 Jul 1997 13:22:59 -0400 (EDT) Message-Id: <199707281722.NAA06790@carnap.itd.nrl.navy.mil> To: shamrock@netcom.com Subject: Re: Status update, please Cc: onions@itd.nrl.navy.mil X-Sun-Charset: US-ASCII Sender: owner-onions@itd.nrl.navy.mil Precedence: bulk Hi, We are going to put out another code release this Friday (Aug. 1). More information will be given soon. aloha, Paul > > Folks, > What is going on with the Onion Routers? I has been quite a while... > > I am waiting to run some sites on FreeBSD/Linux. > > How is the port to SSLeay coming? > > Thanks, > > --Lucky Green > PGP encrypted mail preferred. > DES is dead! Please join in breaking RC5-56. > http://rc5.distributed.net/ > From majordom Tue Jul 29 15:49:25 1997 Return-Path: Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA02936; Tue, 29 Jul 97 15:49:25 EDT Received: from carnap.itd.nrl.navy.mil by itd.nrl.navy.mil (4.1/SMI-4.1) id AA02772; Tue, 29 Jul 97 15:45:42 EDT From: syverson@itd.nrl.navy.mil (Paul Syverson) Received: (from syverson@localhost) by carnap.itd.nrl.navy.mil (8.8.5/8.7.3) id PAA00527; Tue, 29 Jul 1997 15:45:32 -0400 (EDT) Date: Tue, 29 Jul 1997 15:45:32 -0400 (EDT) Message-Id: <199707291945.PAA00527@carnap.itd.nrl.navy.mil> To: syverson@itd.nrl.navy.mil, onions@itd.nrl.navy.mil Subject: latest onion routing code X-Sun-Charset: US-ASCII Sender: owner-onions@itd.nrl.navy.mil Precedence: bulk Greetings Beta Testers and others, We will release the next version of the onion routing code this Friday (Aug. 1). It will run on Solaris 2.5 (and Solaris 2.4?). Since the last release we have spent a good deal of time testing this version and making it robust. The new release has been running here on Solaris 2.5 since early summer, and it appears to be stable. This release will *not* do mixing. We attempted to build the previous version by adding mixing to other components, knowing that we would eventually have to redesign the whole implementation, but the result generated an apparently inexhaustible supply of hard-to-find bugs. Reluctantly, we have decided to cut our losses and release this version with the mixing code commented out. We are proceeding with a redesign that will both include mixing and improve performance. Onion routers running the redesigned system, when available, should interoperate with those running the current release. We are looking forward to the participation of the beta testers in a network of onion routers. So far, we are still running a single machine that simulates a five hop network. Please let us know if you would like to be part of such a network. Participation would probably entail some reasonable commitment on your part to operate your node for predictable time periods. Anyone who has already sent a nondisclosure agreement will receive the code. Anyone who would like to become a beta tester, or just receive code, should contact us at onion-info@itd.nrl.navy.mil for information on what is necessary. Finally, we regret to announce that David Goldschlag has decided to leave NRL for greener pastures. The project continues, (and we expect to remain in touch with him), but I will replace him as the primary point of contact for the project. Sincerely, Paul Syverson From majordom Wed Jul 30 03:30:08 1997 Return-Path: Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA03834; Wed, 30 Jul 97 03:30:08 EDT Received: from smtp1.xs4all.nl by itd.nrl.navy.mil (4.1/SMI-4.1) id AA03824; Wed, 30 Jul 97 03:29:49 EDT Received: from lucky.xs4all.nl (asd03-10.dial.xs4all.nl [194.109.44.75]) by smtp1.xs4all.nl (8.8.6/XS4ALL) with SMTP id JAA28824; Wed, 30 Jul 1997 09:29:46 +0200 (MET DST) Message-Id: <3.0.2.32.19970730090424.0072e9d0@netcom10.netcom.com> X-Sender: shamrock@netcom10.netcom.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 b4 (32) Date: Wed, 30 Jul 1997 09:04:24 -0700 To: syverson@itd.nrl.navy.mil, onions@itd.nrl.navy.mil From: Lucky Green Subject: Re: latest onion routing code In-Reply-To: <199707291945.PAA00527@carnap.itd.nrl.navy.mil> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-onions@itd.nrl.navy.mil Precedence: bulk At 03:45 PM 7/29/97 -0400, Paul Syverson wrote: > >Greetings Beta Testers and others, > >We will release the next version of the onion routing code this Friday >(Aug. 1). It will run on Solaris 2.5 (and Solaris 2.4?). Since the >last release we have spent a good deal of time testing this version and >making it robust. The new release has been running here on Solaris 2.5 >since early summer, and it appears to be stable. When will we see the Linux and FreeBSD ports? Did you move to SSLeay? --Lucky Green PGP encrypted mail preferred. DES is dead! Please join in breaking RC5-56. http://rc5.distributed.net/ From majordom Wed Jul 30 07:47:50 1997 Return-Path: Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA08604; Wed, 30 Jul 97 07:47:50 EDT Received: from banana-jr.itd.nrl.navy.mil by itd.nrl.navy.mil (4.1/SMI-4.1) id AA08555; Wed, 30 Jul 97 07:46:24 EDT Date: Wed, 30 Jul 1997 07:46:46 -0400 (EDT) From: "Michael G. Reed" Reply-To: "Michael G. Reed" To: Lucky Green Cc: Onion Routing List Subject: Re: latest onion routing code In-Reply-To: <3.0.2.32.19970730090424.0072e9d0@netcom10.netcom.com> Message-Id: X-Personal: False X-Anonymous: False Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-onions@itd.nrl.navy.mil Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- On Wed, 30 Jul 1997, Lucky Green wrote: |>>We will release the next version of the onion routing code this Friday |>>(Aug. 1). It will run on Solaris 2.5 (and Solaris 2.4?). Since the |>>last release we have spent a good deal of time testing this version and |>>making it robust. The new release has been running here on Solaris 2.5 |>>since early summer, and it appears to be stable. |> |>When will we see the Linux and FreeBSD ports? Did you move to SSLeay? There will be no ports or SSLeay support in this release. The new version that we will be working on will be built on top of SSLeay and be portable from the start. We just had to much legacy code in there that would have required rewriting to make it worth while at this time, instead we'll just do it right the second time around. - -Michael -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBM98prU8Qx019l0ClAQG9PgQAmhweGaf8BX7ueV0v2mIwAhz6gS1X0qat uP/xFD6pZrQ790pCfz1w7T1GJSDt0neDSD4F0YJus6/7LdaJ2GDsqB99SpwiQlaD Pd7NPdKX5RDOcFlaOQ4Ow3HAQ/Ea7WbHrz0Xeeg9i/vmMG6+9AdxU0EyGiqTHvUa Weq+wFYDrvY= =NYDq -----END PGP SIGNATURE----- From majordom Fri Aug 1 16:22:46 1997 Return-Path: Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA28453; Fri, 1 Aug 97 16:22:46 EDT Received: from carnap.itd.nrl.navy.mil by itd.nrl.navy.mil (4.1/SMI-4.1) id AA28309; Fri, 1 Aug 97 16:19:03 EDT From: syverson@itd.nrl.navy.mil (Paul Syverson) Received: (from syverson@localhost) by carnap.itd.nrl.navy.mil (8.8.5/8.7.3) id QAA03639; Fri, 1 Aug 1997 16:18:59 -0400 (EDT) Date: Fri, 1 Aug 1997 16:18:59 -0400 (EDT) Message-Id: <199708012018.QAA03639@carnap.itd.nrl.navy.mil> To: onion-info@itd.nrl.navy.mil Subject: Onion Routing Version 1.0 code now available X-Sun-Charset: US-ASCII Sender: owner-onions@itd.nrl.navy.mil Precedence: bulk Source and binaries for Onion Routing Version 1.0 are now available. (A brief desription of onion routing is given below.) Anyone interested in receiving the code is encouraged to contact us at onion-info@nrl.navy.mil The only restriction on receiving the code is that you be a US citizen and sign a nondisclosure agreement. Anyone who feels s/he should have already received code and has not should contact us. We are also looking for parties interested in serving as sites in our first distributed beta network. Anyone interested in running an onion router in the beta network should contact us (even if you already did during our first attempt at a beta network this spring). Minimal requirements are a Sun Sparc running Solaris 2.5 or later; contact us at onion-info@itd.nrl.navy.mil for detailed questions. We will gather interested sites until next Friday (August 8, 1997). At that point we will assemble a first beta network out of the sites that have contacted us. Beta sites will be given config files and private keys at that time. Our first network will be a static, persistent, fully connected clique. We will be able to add or remove interested sites later, but this will involve a redistribution of config files to the entire network. -------------------------------------------------------------------- Onion Routing Naval Research Laboratory Center for High Assurance Computer Systems http://www.itd.nrl.navy.mil/ITD/5540/projects/onion-routing Onion Routing is an infrastructure for private communication over a public network. It provides anonymous connections that are strongly resistant to both eavesdropping and traffic analysis. Onion routing's anonymous connections are bidirectional and near real-time, and can be used anywhere a socket connection can be used. A prototype of onion routing is running in our lab. An onion is a data structure that is treated as the destination address by onion routers; thus, it is used to establish an anonymous connection. Onions themselves appear differently to each onion router as well as to network observers. The same goes for data carried over the connections they establish. Proxy aware applications, such as web browsing and email, require no modification to use onion routing, and do so through a series of proxies. This work sponsored by DARPA, NRL, and ONR. From majordom Mon Aug 4 12:47:08 1997 Return-Path: Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA29495; Mon, 4 Aug 97 12:47:08 EDT Received: from descartes.bluemoney.com by itd.nrl.navy.mil (4.1/SMI-4.1) id AA29458; Mon, 4 Aug 97 12:46:57 EDT Received: from galileo.bluemoney.com (galileo.bluemoney.com [204.162.247.73]) by descartes.bluemoney.com (8.7/8.6.9) with SMTP id JAA06591; Mon, 4 Aug 1997 09:49:26 -0700 (PDT) Message-Id: <3.0.2.32.19970804094622.008426d0@descartes.bluemoney.com> X-Sender: jeremey@descartes.bluemoney.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32) Date: Mon, 04 Aug 1997 09:46:22 -0700 To: syverson@itd.nrl.navy.mil From: Jeremey Barrett Subject: Code comments Cc: onions@itd.nrl.navy.mil Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-onions@itd.nrl.navy.mil Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Some initial suggestions regarding the code: o Use pthreads instead of Solaris threads. You can quickly replace the code, the two libs match up pretty well. (pthread_create instead of thr_create, pthread_mutex_init instead of mutex_init, etc). I would assume a pthreads implementation exists for Solaris, probably as wrappers for Solaris threads. pthreads exist in some form or another on many platforms. (It might also be worth looking into whether threads are necessary at all). o poll(). Icky. Is there a reason you chose poll() over select()? select() will be much more portable. AFAIK, poll() doesn't exist outside of system V. o The dead horse: BSAFE. :-) But it looks as though you've already wrapped BSAFE up in your own calls, so writing an SSLeay interface should be pretty easy. I haven't perused or compiled everything yet. Thanks for the release, I'll keep you posted. Jeremey. -----BEGIN PGP SIGNATURE----- Version: PGP for Personal Privacy 5.0 Charset: noconv iQCVAwUBM+YHXS/fy+vkqMxNAQGWHwP/Xp6R/huwsRGLIX75BewgDyq5u7SGxBfc Pi5s/8zmTZWZrGewUxaQn0kMjeJXBUKbCGZ419JGNuGePfLTvv3p5FP3PcvOXqJZ qZSDKHwgqJlsWWoxfJYbbO4c5lVUsdYBnRRkFu7wd/2hpGyhOrdPSUBbo6VGzfRZ K7sQZzi0DxY= =yTll -----END PGP SIGNATURE----- -- Jeremey Barrett BlueMoney Software Corp. Crypto, Ecash, Commerce Systems http://www.bluemoney.com/ PGP key fingerprint = 3B 42 1E D4 4B 17 0D 80 DC 59 6F 59 04 C3 83 64 From majordom Mon Aug 4 13:06:24 1997 Return-Path: Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA00797; Mon, 4 Aug 97 13:06:24 EDT Received: from banana-jr.itd.nrl.navy.mil by itd.nrl.navy.mil (4.1/SMI-4.1) id AA00788; Mon, 4 Aug 97 13:06:17 EDT Date: Mon, 4 Aug 1997 13:06:44 -0400 (EDT) From: "Michael G. Reed" Reply-To: "Michael G. Reed" To: Jeremey Barrett Cc: Onion Routing List Subject: Re: Code comments In-Reply-To: <3.0.2.32.19970804094622.008426d0@descartes.bluemoney.com> Message-Id: X-Personal: False X-Anonymous: False Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-onions@itd.nrl.navy.mil Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- On Mon, 4 Aug 1997, Jeremey Barrett wrote: |> o Use pthreads instead of Solaris threads. You can quickly replace |> the code, the two libs match up pretty well. (pthread_create |> instead of thr_create, pthread_mutex_init instead of mutex_init, |> etc). I would assume a pthreads implementation exists for |> Solaris, probably as wrappers for Solaris threads. pthreads |> exist in some form or another on many platforms. (It might also |> be worth looking into whether threads are necessary at all). Actually, I've been meaning to do that for some time. In the next version, I am thinking of avoiding threading all together and just using several heavy weight processes loosely interconnected via shared memory or IPC calls. I've found the Solaris threads to be buggy (we have two known bugs that we worked around in this release alone), and I'm not sure how confident I am in pthreads considering they were only recently adopted as a POSIX standard, correct? Comments? |> o poll(). Icky. Is there a reason you chose poll() over select()? |> select() will be much more portable. AFAIK, poll() doesn't |> exist outside of system V. Yes, I know. You go with what you know though...Since the initial version was a proof of concept, I just used poll. That will change. |> o The dead horse: BSAFE. :-) But it looks as though you've already |> wrapped BSAFE up in your own calls, so writing an SSLeay |> interface should be pretty easy. Already been suggested and is currently being worked on. Prior to BSAFE we used Bell Lab's CryptoLib, but since it isn't completely thread safe, we dropped it. We also interface into fast RSA routines for the SPARC v9+ architecture with the same call structure as BSAFE. Since we are looking to go to a Intel platform with cheap crypto hardware or fast crypto software (SSLeay), this will change too... |>I haven't perused or compiled everything yet. Thanks for the release, |>I'll keep you posted. Keep in mind that we are throwing out all of this code for the next release. This version was a proof of concept only, and is *NOT* intended to be used widely or heavily. We made every attempt possible to make it pretty robust, but next time we "plan on doing it right" :-) Therefore, all comments and criticisms are appreciated. Look for more details on the design of the new system here next week (we're banging out the details as we speak). - -Michael -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBM+YMKE8Qx019l0ClAQGxJgP/WZzk3a7NuPf5XKuxNEQMUenwjR/LIwnz PBsJkHaoz+UIwRA+n70oYEW27DYpCme3J/f429JtLcMlYDj+WN5u20hA/YxwQcGT w97Ptr74ai4PgMJENUDnsFHsm99VoQ5PGZXsKohMN5WLPLdD30CZbK8A97f07NpE W97ZWS+w2Jg= =QqUJ -----END PGP SIGNATURE----- From majordom Mon Aug 4 13:15:59 1997 Return-Path: Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA01291; Mon, 4 Aug 97 13:15:59 EDT Received: from descartes.bluemoney.com by itd.nrl.navy.mil (4.1/SMI-4.1) id AA01282; Mon, 4 Aug 97 13:15:48 EDT Received: from galileo.bluemoney.com (galileo.bluemoney.com [204.162.247.73]) by descartes.bluemoney.com (8.7/8.6.9) with SMTP id KAA06642; Mon, 4 Aug 1997 10:18:17 -0700 (PDT) Message-Id: <3.0.2.32.19970804101513.00807690@descartes.bluemoney.com> X-Sender: jeremey@descartes.bluemoney.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32) Date: Mon, 04 Aug 1997 10:15:13 -0700 To: "Michael G. Reed" From: Jeremey Barrett Subject: Re: Code comments Cc: Onion Routing List In-Reply-To: References: <3.0.2.32.19970804094622.008426d0@descartes.bluemoney.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-onions@itd.nrl.navy.mil Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- At 01:06 PM 8/4/97 -0400, Michael G. Reed wrote: >On Mon, 4 Aug 1997, Jeremey Barrett wrote: >|> o Use pthreads instead of Solaris threads. You can quickly replace >|> the code, the two libs match up pretty well. (pthread_create >|> instead of thr_create, pthread_mutex_init instead of mutex_init, >|> etc). I would assume a pthreads implementation exists for >|> Solaris, probably as wrappers for Solaris threads. pthreads >|> exist in some form or another on many platforms. (It might also >|> be worth looking into whether threads are necessary at all). > >Actually, I've been meaning to do that for some time. In the next >version, I am thinking of avoiding threading all together and just >using several heavy weight processes loosely interconnected via shared >memory or IPC calls. I've found the Solaris threads to be buggy (we >have two known bugs that we worked around in this release alone), and >I'm not sure how confident I am in pthreads considering they were only >recently adopted as a POSIX standard, correct? Comments? In my experience, pthreads are pretty buggy too. :-) I think the best solution is no threads at all. The only platform on which pthreads seem to work well is linux (LinuxThreads implementation) because they are based on clone(), and actually create a different light process for each thread. So you don't have to replace all of libc, because normal blocking system calls are fine. Most pthreads implementations I've used are user-level, and choke horribly on things like select(). > >Keep in mind that we are throwing out all of this code for the next >release. This version was a proof of concept only, and is *NOT* >intended to be used widely or heavily. We made every attempt possible >to make it pretty robust, but next time we "plan on doing it right" >:-) Therefore, all comments and criticisms are appreciated. Look for >more details on the design of the new system here next week (we're >banging out the details as we speak). Great, looking forward to it. Jeremey. -----BEGIN PGP SIGNATURE----- Version: PGP for Personal Privacy 5.0 Charset: noconv iQCVAwUBM+YOIC/fy+vkqMxNAQE2fwP+Oh6IoUC3qgUlNwYpARooAXBjvFAmClfS JDFAXgIzVyM5l9HepefO0AJK0gDNHy+kAB5AmATc5+iT2quaUCvgM/VxYkRjcigP o78h1tjUNSic4xUw/HJ6lGyP6nQYIoTxpmrMlxWDoK7ExdmY86EuKXCuZnTEpLwS iWGenO1kg3w= =ne5v -----END PGP SIGNATURE----- -- Jeremey Barrett BlueMoney Software Corp. Crypto, Ecash, Commerce Systems http://www.bluemoney.com/ PGP key fingerprint = 3B 42 1E D4 4B 17 0D 80 DC 59 6F 59 04 C3 83 64 From majordom Tue Aug 5 07:45:45 1997 Return-Path: Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA29514; Tue, 5 Aug 97 07:45:45 EDT Received: from banana-jr.itd.nrl.navy.mil by itd.nrl.navy.mil (4.1/SMI-4.1) id AA29507; Tue, 5 Aug 97 07:45:39 EDT Date: Tue, 5 Aug 1997 07:46:06 -0400 (EDT) From: "Michael G. Reed" Reply-To: "Michael G. Reed" To: Onion Routing List Subject: Some questions... Message-Id: X-Personal: False X-Anonymous: False Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-onions@itd.nrl.navy.mil Precedence: bulk Calling all Onioneers! Now that we are redesigning the system from ground up, we are considering a few fundamental changes that may render new versions of the Onion Routing software incompatible with the current prototype. Before we take those drastic steps though, we want to get some feedback/comments on them. Constructive criticism would really be appreciated! Question #1: Keep or ditch ATM sized cells? The original assumption was that there would be a good mix (no pun intended) of data traffic between interactive services (RLOGIN) and bulk transport services (HTTP/FTP/SMTP). This has not proven to be the case (we have 70k HTTP hits in the last two weeks and only 3 RLOGIN hits). We also adopted cell sizes that would fit within ATM cells so we could run directly over ATM/AAL5 instead of TCP/IP. With some people lamenting that ATM to the desktop is dead and it will only ever be used as a WAN transport mechanism (and even then, most of the time people tend to use PVCs with IP running over them), should we continue to constrain ourselves to this small size (48 byte cells -- in the case of data cells that's 44 byte payload and 4 byte header), or is a larger size in order? The 8.3% overhead we currently have is pretty high, and will only get larger if we add MACs (see the next question). If we increase cell size we will increase system throughput and reduce cell overhead. Comments? Question #2: Add a mandatory end-to-end data MAC, an optional end-to-end data MAC, and/or OR-to-OR link MACs? Proxy classically offer services that may be weaker than the TCP/IP connections they run over. This is due to the fact that the proxy may alter the data (intentionally or not) while relaying it from one side to the other. We run into a potentially larger problem with OR. There is nothing to prevent a malicious OR from tampering with the data stream. By using the stream ciphers, we guard against replay/data injection/data removal in the sense the data stream will become corrupted, but the application may not KNOW the data stream is corrupted. Currently there is no MAC in place and we've been discussing this for a little while. Does a vanilla CRC-16 inside the data messages (and secured by the multiple stream ciphers) add the level of security we should probably be providing? If we put it into the data cells, are OR-to-OR link MACs necessary? We have some ideas and answers on this, but I want to hear other peoples opinions. Question #3: Keep or increase the ACI length? The ACI (Anonymous Connection Identifier) field in each cell is currently 16 bits long. This allows for 64K connections through any one OR-to-OR link. Because we need an asymmetry during connection setup, this really amounts to a 32K address space in both directions (we carve it in half). Does this seem sufficient? Can anyone forsee a situation where there are more than 40K or 50K connections up simultaneously between two particular OR's? This would require a redesign of the header, so I am reluctant to endorse the idea, but some have raised the question about this limitation and I'd really like to hear some good arguments on it. Question #4: Run multi-threaded or single-threaded servers that communicate via IPC/shared memory? Multi-threaded applications are nice in that the entire server is self contained. However, there are a number of drawbacks as well: 1) they tend to be more difficult to debug, 2) POSIX threads have one recently been adopted so are not available on all platforms, 3) many thread implementations are buggy. The first prototype was a multi-threaded application, and given that experience, I am thinking of going the later route this time around. Question #5: Crypto of choice? Software: SSLeay -- it's fast and portable. Hardware: ? -- we're looking at PCI based, publicly available crypto boards now. If anyone has a suggestion, we're all ears. Support for DES-56/RSA-1024/DH is critical. Any other protocols (MD5/IDEA/etc) would be gravy. That's all for now. Look for more details on the changes in the new system to come in a few days...Thanks for the help! -Michael From majordom Tue Aug 5 13:35:16 1997 Return-Path: Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA17572; Tue, 5 Aug 97 13:35:16 EDT Received: from einstein.bluemoney.com ([204.162.247.69]) by itd.nrl.navy.mil (4.1/SMI-4.1) id AA17455; Tue, 5 Aug 97 13:35:09 EDT Received: (from jeremey@localhost) by einstein.bluemoney.com (8.8.5/8.6.9) id KAA02326; Tue, 5 Aug 1997 10:37:17 -0700 Date: Tue, 5 Aug 1997 10:37:17 -0700 Message-Id: <199708051737.KAA02326@einstein.bluemoney.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Michael G. Reed" Cc: Onion Routing List Subject: Some questions... In-Reply-To: References: X-Mailer: VM 6.22 under 19.15 XEmacs Lucid From: Jeremey Barrett Organization: BlueMoney Software Corp. Sender: owner-onions@itd.nrl.navy.mil Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- > > Question #1: Keep or ditch ATM sized cells? Ditch. I imagine running over TCP/IP is nearly a given, and you can achieve better/more efficient messages formats. > Question #2: Add a mandatory end-to-end data MAC, an optional > end-to-end data MAC, and/or OR-to-OR link MACs? > > Proxy classically offer services that may be weaker than the TCP/IP > connections they run over. This is due to the fact that the proxy may > alter the data (intentionally or not) while relaying it from one side > to the other. We run into a potentially larger problem with OR. > There is nothing to prevent a malicious OR from tampering with the > data stream. By using the stream ciphers, we guard against > replay/data injection/data removal in the sense the data stream will > become corrupted, but the application may not KNOW the data stream is > corrupted. Currently there is no MAC in place and we've been > discussing this for a little while. Does a vanilla CRC-16 inside the > data messages (and secured by the multiple stream ciphers) add the > level of security we should probably be providing? If we put it into > the data cells, are OR-to-OR link MACs necessary? We have some ideas > and answers on this, but I want to hear other peoples opinions. It will be pretty hard to protect against a malicious router. Regardless of MAC, the router can rewrite an onion at connection setup time (am I off base here?). A MAC might be useful for the OR-to-OR link, to protect against outside attackers modifying the data stream. > > > Question #3: Keep or increase the ACI length? > > The ACI (Anonymous Connection Identifier) field in each cell is > currently 16 bits long. This allows for 64K connections through any > one OR-to-OR link. Because we need an asymmetry during connection > setup, this really amounts to a 32K address space in both directions > (we carve it in half). Does this seem sufficient? Can anyone forsee > a situation where there are more than 40K or 50K connections up > simultaneously between two particular OR's? This would require a > redesign of the header, so I am reluctant to endorse the idea, but > some have raised the question about this limitation and I'd really > like to hear some good arguments on it. They said 32 bits was way more than enough for IP addresses :-) Maybe have a 1 byte version indicator, so you can later upgrade the protocol without breaking everything. Seems like a max of 32K connections is low, given the number of people out there, but I really don't know how much use the system will get. > > > Question #4: Run multi-threaded or single-threaded servers that > communicate via IPC/shared memory? Out of curiosity, why are multiple servers necessary? In any case, a non-threaded implementation will be more portable and much easier to debug, as you say. Go without threads. > Question #5: Crypto of choice? > > Software: SSLeay -- it's fast and portable. Hardware: ? -- we're > looking at PCI based, publicly available crypto boards now. If anyone > has a suggestion, we're all ears. Support for DES-56/RSA-1024/DH is > critical. Any other protocols (MD5/IDEA/etc) would be gravy. I'd recommend nCipher's hardware. It runs on the SCSI bus, so the driver is entirely user-space, no kernel modifications required. It's also quite fast. Jeremey. - -- Jeremey Barrett BlueMoney Software Corp. Crypto, Ecash, Commerce Systems http://www.bluemoney.com/ PGP key fingerprint = 3B 42 1E D4 4B 17 0D 80 DC 59 6F 59 04 C3 83 64 -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQCVAwUBM+dkri/fy+vkqMxNAQGUUwP+MkJvriTrbSR4hYndrtLx9OxTyCWRoADx XEU5AiDXWLgCJ2syR2uFhZrh+DD9T3trjV26FtdC79ftu4ly5fD1f6dVwoTLrLtJ CCVGq+y2OIFs7jm5lGv2itme/l/4b9DRp2Xbm9woG9ybJv0zNq0SkjTC61ralgX1 BQSMebWILMs= =S72L -----END PGP SIGNATURE----- From majordom Tue Aug 5 16:37:41 1997 Return-Path: Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA27448; Tue, 5 Aug 97 16:37:41 EDT Received: from freya.cs.umass.edu by itd.nrl.navy.mil (4.1/SMI-4.1) id AA27440; Tue, 5 Aug 97 16:37:35 EDT Received: from opine.cs.umass.edu (opine.cs.umass.edu [128.119.41.246]) by freya.cs.umass.edu (8.8.5/8.8.5) with SMTP id QAA25501 for ; Tue, 5 Aug 1997 16:37:34 -0400 Message-Id: <33E78F0E.167E@cs.umass.edu> Date: Tue, 05 Aug 1997 16:37:34 -0400 From: Lewis McCarthy Organization: UMass-Amherst Theoretical Computer Science Group, X-Mailer: Mozilla 3.01Gold (X11; U; OSF1 V3.2 alpha) Mime-Version: 1.0 To: Onion Routing List Subject: Re: Some questions... References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-onions@itd.nrl.navy.mil Precedence: bulk Michael Reed writes: > Question #2: Add a mandatory end-to-end data MAC, an optional > end-to-end data MAC, and/or OR-to-OR link MACs? > > Proxy classically offer services that may be weaker than the TCP/IP > connections they run over. This is due to the fact that the proxy may > alter the data (intentionally or not) while relaying it from one side > to the other. We run into a potentially larger problem with OR. > There is nothing to prevent a malicious OR from tampering with the > data stream. By using the stream ciphers, we guard against > replay/data injection/data removal in the sense the data stream will > become corrupted, but the application may not KNOW the data stream is > corrupted. Currently there is no MAC in place and we've been > discussing this for a little while. Does a vanilla CRC-16 inside the > data messages (and secured by the multiple stream ciphers) add the > level of security we should probably be providing? I don't believe this would add much real strength. If I read you correctly, you're suggesting a construction with a single CRC inside the innermost encryption layer, such as: Encrypt_m( ... Encrypt_2( Encrypt_1( DATA, CRC16( DATA ) ) ) ... ). Since each encryption layer Encrypt_i() is an application of a stream cipher, we have (DATA, CRC16(DATA)) xor KeyStream_1 xor KeyStream_2 ... xor KeyStream_m == (DATA, CRC16(DATA)) xor Composite-KeyStream. If I'm not mistaken, an attacker can flip some bits in the DATA xor LeftBits(Composite-Keystream) portion, and quickly figure out which bits should be flipped in the CRC16(DATA) xor RightBits(Composite- Keystream) portion. For a while last year there was a proposal in the IPSEC WG to use a stream cipher in ESP with an embedded CRC as a form of MAC. This scheme and some suggested fixes were torn open; see the thread on "A hole in esp-stream-01" in the IPSEC mailing list archives for Oct. `96 at . > If we put it into > the data cells, are OR-to-OR link MACs necessary? We have some ideas > and answers on this, but I want to hear other peoples opinions. Hmm, I haven't thought much about the workfactor for breaking a construction with multiple nested non-cryptographic checksums. Intuitively I suspect it may be possible to hurdle them one at a time, rather than needing to tackle them all simultaneously. I'm inclined to vote for an optional end-to-end data MAC, using a construction with cryptographic teeth like an HMAC with MD5 (or preferably SHA-1 or RIPEMD160). If people use SSL or TLS on top of their onion connections then a lower-level MAC is probably unnecessary anyway. Some folks might be satisfied with IP layer data integrity protection from IPSEC-AH or -ESP for this purpose, if they don't need per-connection data origin authentication. I don't see an exception to the usual end-to-end security arguments here that would call for deploying link security measures instead. -- Lewis http://www.cs.umass.edu/~lmccarth/ "In our opinion provable security is nothing more than a phantom, similar to the perpetuum mobile in thermodynamics." -- Joan Daemen, 1995 From majordom Wed Aug 6 13:05:50 1997 Return-Path: Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA28926; Wed, 6 Aug 97 13:05:50 EDT Received: from banana-jr.itd.nrl.navy.mil by itd.nrl.navy.mil (4.1/SMI-4.1) id AA28912; Wed, 6 Aug 97 13:05:40 EDT Date: Wed, 6 Aug 1997 13:06:08 -0400 (EDT) From: "Michael G. Reed" Reply-To: "Michael G. Reed" To: Jeremey Barrett Cc: Onion Routing List Subject: Re: Some questions... In-Reply-To: <199708051737.KAA02326@einstein.bluemoney.com> Message-Id: X-Personal: False X-Anonymous: False Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-onions@itd.nrl.navy.mil Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- On Tue, 5 Aug 1997, Jeremey Barrett wrote: |> > Question #1: Keep or ditch ATM sized cells? |> |>Ditch. I imagine running over TCP/IP is nearly a given, and |>you can achieve better/more efficient messages formats. Ah, but what size do we select instead? All packets must be the same size to avoid traceability in the network... |> > Question #2: Add a mandatory end-to-end data MAC, an optional |> > end-to-end data MAC, and/or OR-to-OR link MACs? |> |>It will be pretty hard to protect against a malicious router. |>Regardless of MAC, the router can rewrite an onion at connection |>setup time (am I off base here?). A MAC might be useful for the |>OR-to-OR link, to protect against outside attackers modifying the |>data stream. A malicious router CANNOT rewrite the onion. He can add layers, but he cannot remove or replace existing layers of the connection will not succeed. |> > Question #3: Keep or increase the ACI length? |> > |> > The ACI (Anonymous Connection Identifier) field in each cell is |> > currently 16 bits long. This allows for 64K connections through any |> > one OR-to-OR link. Because we need an asymmetry during connection |> > setup, this really amounts to a 32K address space in both directions |> > (we carve it in half). Does this seem sufficient? Can anyone forsee |> > a situation where there are more than 40K or 50K connections up |> > simultaneously between two particular OR's? This would require a |> > redesign of the header, so I am reluctant to endorse the idea, but |> > some have raised the question about this limitation and I'd really |> > like to hear some good arguments on it. |> |>They said 32 bits was way more than enough for IP addresses :-) |>Maybe have a 1 byte version indicator, so you can later upgrade |>the protocol without breaking everything. Seems like a max of |>32K connections is low, given the number of people out there, |>but I really don't know how much use the system will get. Since the ACI is a locally defined parameter on each OR-to-OR link, there is no reason that in the future it couldn't be expanded by simply upgrading both OR's on either side of the link. This would need to be done as well under your proposal since if you don't upgrade both, one won't understand the new format (version). For that reason, I'm inclined to leave it at 16 bits and see what happens. |> > Question #4: Run multi-threaded or single-threaded servers that |> > communicate via IPC/shared memory? |> |>Out of curiosity, why are multiple servers necessary? In any case, |>a non-threaded implementation will be more portable and much easier |>to debug, as you say. Go without threads. I tend to agree with you in the "no threads" this time around. However, I am thinking of simulating threads though with heavy-weight processes. IE, I'll have a READ process that takes data from the various thick pipes and dumps it to the PROCESS process which will do all the crypto and cross lookups and then forward the data to a WRITE process. If I don't do it this way, problems could arise (ie, what if I can't write all the data...do I block indefinitely stalling everything, etc). |> > Question #5: Crypto of choice? |> > |> > Software: SSLeay -- it's fast and portable. Hardware: ? -- we're |> > looking at PCI based, publicly available crypto boards now. If anyone |> > has a suggestion, we're all ears. Support for DES-56/RSA-1024/DH is |> > critical. Any other protocols (MD5/IDEA/etc) would be gravy. |> |>I'd recommend nCipher's hardware. It runs on the SCSI bus, so the |>driver is entirely user-space, no kernel modifications required. |>It's also quite fast. Their web page is less than stellar (lots of promises, little on details). Are they shipping (and if so, WHAT are they shipping)? Thanks for the input! - -Michael -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBM+ivA08Qx019l0ClAQHp5wP/deTaJQDPlK2BVjbNPNCjrIQomGQc9Iu3 WNTdol0j//YzPKtPuTTHftBiOWn4hJuOzetwDkByCyir53T56gG+8yeymj4rOUE3 ZICVrozA4FGd035f4P1lgQJ+3WzY1N5AML+cBAVbS92kKTKD8Sqw1xE+OZgJfA63 Wd6O3l1UBmw= =k9bC -----END PGP SIGNATURE----- From majordom Wed Aug 6 14:51:47 1997 Return-Path: Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA05010; Wed, 6 Aug 97 14:51:47 EDT Received: from mail.eskimo.com by itd.nrl.navy.mil (4.1/SMI-4.1) id AA05004; Wed, 6 Aug 97 14:51:34 EDT Received: from eskimo.com (weidai@eskimo.com [204.122.16.13]) by mail.eskimo.com (8.8.5/8.6.12) with SMTP id LAA13727; Wed, 6 Aug 1997 11:51:30 -0700 (PDT) Date: Wed, 6 Aug 1997 11:51:28 -0700 (PDT) From: Wei Dai To: "Michael G. Reed" Cc: Jeremey Barrett , Onion Routing List Subject: Re: Some questions... In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-onions@itd.nrl.navy.mil Precedence: bulk On Wed, 6 Aug 1997, Michael G. Reed wrote: > Ah, but what size do we select instead? All packets must be the same > size to avoid traceability in the network... How about having different classes of service? For example you can offer two different packet sizes for rlogin and http services. This will allow an adversary to tell the difference between rlogin users and http users, but I think a one-size-fits-all approach is too inefficient to be practical. From majordom Thu Aug 7 04:07:50 1997 Return-Path: Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA24680; Thu, 7 Aug 97 04:07:50 EDT Received: from uni-sb.de by itd.nrl.navy.mil (4.1/SMI-4.1) id AA24670; Thu, 7 Aug 97 04:07:41 EDT Received: from cs.uni-sb.de (cs.uni-sb.de [134.96.252.31]) by uni-sb.de (8.8.6/97052600) with ESMTP id KAA28564 for ; Thu, 7 Aug 1997 10:07:37 +0200 (CEST) Received: from fsinfo.cs.uni-sb.de (root@fsinfo.cs.uni-sb.de [134.96.239.10]) by cs.uni-sb.de (8.8.6/97052600) with ESMTP id KAA28318 for ; Thu, 7 Aug 1997 10:07:37 +0200 (CEST) Received: from [134.96.113.124] (acc1-124.telip.uni-sb.de [134.96.113.124]) by fsinfo.cs.uni-sb.de (8.8.6/97070902) with ESMTP id KAA10402 for ; Thu, 7 Aug 1997 10:07:20 +0200 (CEST) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 7 Aug 1997 10:08:20 +0200 To: onions@itd.nrl.navy.mil From: Lothar Fritsch Subject: Q: rlogin onion router Sender: owner-onions@itd.nrl.navy.mil Precedence: bulk Hello! My name is Lothar Fritsch, a new subscriber to the onions list. I'm a german computer science student at the Universit=E4t des Saarlandes at Saarbr=FCcken, Germany, working on my thesis on the topic of anonymous communications in an electronic marketplace. This is why I'm interested in onion routing. One particular problem I found in connection-oriented MIXes or onion routers is the problem of the "data size" sent over the onion router network. Especially for rlogin, where users hit single keys on their keyboards, the size of the transmitted data might very well be a single byte. I wonder how this is implemented in the rlogin onion router: is the single keystroke packaged into a cell with 44 bytes of payload, like Syverson, Goldschlag and Reed wrote in "Anonymous Connections and Onion Routing" in section 5.6? Yours, Lothar Fritsch -- Lothar Fritsch Informatik, Fotografie, fritsch@fsinfo.cs.uni-sb.de Internet-Journalist, http://fsinfo.cs.uni-sb.de/~fritsch/ Neue Medien, Schulungen From majordom Thu Aug 7 04:53:37 1997 Return-Path: Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA25394; Thu, 7 Aug 97 04:53:37 EDT Received: from einstein.bluemoney.com by itd.nrl.navy.mil (4.1/SMI-4.1) id AA25388; Thu, 7 Aug 97 04:53:30 EDT Received: (from jeremey@localhost) by einstein.bluemoney.com (8.8.5/8.6.9) id BAA01974; Thu, 7 Aug 1997 01:57:14 -0700 Date: Thu, 7 Aug 1997 01:57:14 -0700 Message-Id: <199708070857.BAA01974@einstein.bluemoney.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Michael G. Reed" Cc: Onion Routing List Subject: Re: Some questions... In-Reply-To: References: <199708051737.KAA02326@einstein.bluemoney.com> X-Mailer: VM 6.22 under 19.15 XEmacs Lucid From: Jeremey Barrett Organization: BlueMoney Software Corp. Sender: owner-onions@itd.nrl.navy.mil Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Michael G. Reed writes: > > Ah, but what size do we select instead? All packets must be the same > size to avoid traceability in the network... What size I don't know exactly. How much overhead is there? (including a MAC perhaps). I agree with Wei Dai that it should vary according to traffic type. rlogin with 256 byte packets would be less than optimal, similarly HTTP with 53 byte packets. > > A malicious router CANNOT rewrite the onion. He can add layers, but > he cannot remove or replace existing layers of the connection will not > succeed. Hrm... then an end-to-end MAC on the data stream seems most useful. It should be some form of keyed cryptographic hash IMO, probably HMAC. The key can be derived from the shared symmetric key. The MAC on the data stream, if valid, will also validate that the setup onion was not tampered with in any meaningful way. > |>I'd recommend nCipher's hardware. It runs on the SCSI bus, so the > |>driver is entirely user-space, no kernel modifications required. > |>It's also quite fast. > > Their web page is less than stellar (lots of promises, little on > details). Are they shipping (and if so, WHAT are they shipping)? They have a low-end card that does 75 1024 bit RSA sigs a second, and a high-end around 300. I don't think they are shipping final products yet, but they do have a beta program. Jeremey. - -- Jeremey Barrett BlueMoney Software Corp. Crypto, Ecash, Commerce Systems http://www.bluemoney.com/ PGP key fingerprint = 3B 42 1E D4 4B 17 0D 80 DC 59 6F 59 04 C3 83 64 -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQCVAwUBM+mNuC/fy+vkqMxNAQGN0gP/fcY+/blYDAcDKX0WklSoKXdwP57fKQAW 1291PEhAj6T3P0MIbjtf0K4eL0s897ukfx1iiZJzUeFb5qEKS7YGltGsXuTTHrWb gGUgCaMe6YcQthrmJmMy4QYM2uDZBUXkqUwkaiZGYz4FGHVp6xhklhvkcVPQcuPS +QoTkNltIPk= =isCU -----END PGP SIGNATURE----- From majordom Thu Aug 7 07:15:43 1997 Return-Path: Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA27503; Thu, 7 Aug 97 07:15:43 EDT Received: from banana-jr.itd.nrl.navy.mil by itd.nrl.navy.mil (4.1/SMI-4.1) id AA27495; Thu, 7 Aug 97 07:15:25 EDT Date: Thu, 7 Aug 1997 07:15:52 -0400 (EDT) From: "Michael G. Reed" Reply-To: "Michael G. Reed" To: Lothar Fritsch Cc: onions@itd.nrl.navy.mil Subject: Re: Q: rlogin onion router In-Reply-To: Message-Id: X-Personal: False X-Anonymous: False Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-onions@itd.nrl.navy.mil Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- On Thu, 7 Aug 1997, Lothar Fritsch wrote: |>My name is Lothar Fritsch, a new subscriber to the onions list. I'm a |>german computer science student at the Universit=E4t des Saarlandes at |>Saarbr=FCcken, Germany, working on my thesis on the topic of anonymous |>communications in an electronic marketplace. |>This is why I'm interested in onion routing. One particular problem I fou= nd |>in connection-oriented MIXes or onion routers is the problem of the "data |>size" sent over the onion router network. Especially for rlogin, where |>users hit single keys on their keyboards, the size of the transmitted dat= a |>might very well be a single byte. I wonder how this is implemented in the |>rlogin onion router: is the single keystroke packaged into a cell with 44 |>bytes of payload, like Syverson, Goldschlag and Reed wrote in "Anonymous |>Connections and Onion Routing" in section 5.6? Yes, if only a byte of data is available at a time, it is packaged with 43 bytes of random padding and then sent through the network. Not the most efficient way of doing it, but not really any worse than what normally happens on the Internet (one of the more common TCP/IP packets is the single byte payload at a time interactive telnet connection). - -Michael -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBM+mubE8Qx019l0ClAQEcQQP9G83TxJFRtvLmOdmS0Pj9yqAsiHIz16VM pAWEAVGfVdARkGlhSQwId45QgD46Dmok33nMvYLcacqPyYIiUQ0eR8qBbpiZj169 zbuhS8sI2k2xdFq7bNQkH8Wa+qMnvDbxiw6Gs0LTyRpWa9kQMOmgMMRYMNlgIuOP ikV+leA6zXg=3D =3DWV56 -----END PGP SIGNATURE----- From majordom Thu Aug 7 07:39:07 1997 Return-Path: Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA28363; Thu, 7 Aug 97 07:39:07 EDT Received: from banana-jr.itd.nrl.navy.mil by itd.nrl.navy.mil (4.1/SMI-4.1) id AA28340; Thu, 7 Aug 97 07:38:53 EDT Date: Thu, 7 Aug 1997 07:39:20 -0400 (EDT) From: "Michael G. Reed" Reply-To: "Michael G. Reed" To: Wei Dai Cc: Jeremey Barrett , Onion Routing List Subject: Re: Some questions... In-Reply-To: Message-Id: X-Personal: False X-Anonymous: False Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-onions@itd.nrl.navy.mil Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- On Wed, 6 Aug 1997, Wei Dai wrote: |>> Ah, but what size do we select instead? All packets must be the same |>> size to avoid traceability in the network... |> |>How about having different classes of service? For example you can offer |>two different packet sizes for rlogin and http services. This will allow |>an adversary to tell the difference between rlogin users and http users, |>but I think a one-size-fits-all approach is too inefficient to be |>practical. We had discussed the idea of different classes of service, but not in a data payload size context -- instead in a mixing context. For example, you may have high priority data (ie, data that must maintain a better QoS level like interactive telnet connections) and lower priority data (ie, smtp transactions). One could imagine a mixing strategy that tries to do minimal mixing on the high priority data to reduce the latency for the data flowing through the network but is willing to hold low priority data at each node for some time to better hide everything (after all, the larger the mix pool, the harder it becomes to track coincidences). In the end, we didn't implement this because of the traceability it introduces (and I think this would also be true if we use different packet sizes). If you take our current mix (no pun intended) of traffic, we have about 99.99% HTTP and .01% RLOGIN. I think we'll find that even when we add more services (FTP/SMTP/etc), we'll still see HTTP as a staggering percentage. This then makes it MUCH easier to track RLOGIN/FTP/SMTP/etc since the connections will be effectively tagged as they move through the network. In terms of the QoS idea, we ultimately came up with the idea of per-node jitter. We're looking at adding two character-size values to each layer of the onion: Jitter_Min and Jitter_Max. These will be inputs to an always increasing function that will map into some range (like 0-5000) and will be used to tell a particular onion-router along a route for how long he may hold up data (jitter it) as it passes him. Since this is a per layer value and not a global constant, it will not be trackable (ie, cooperating onion routers will not be able to compare the values they receive in their layers since any smart onion creator will vary the values (ie, an onion creator might put the following tuples in the individual layers: (0,3), (1,6), (0,0), (1,2), (0,0) -- this would ultimately lead to a data latency of at least 1 and at most 11). Different services (and different paranoid levels) might choose different base values and work from there. It becomes harder to correlate data then (ie, is a (50,100) a really paranoid individual or just some low priority data that isn't time sensitive?) I'm still not really confident that it doesn't leak too much information, but I think it will leak a lot less than a change in packet size would (ie, making something like telnet packets really small in comparison to HTTP). Not to mention I'm not really happy about having to potentially store more data at each node (we've already seen our prototype get deadlocked when someone overwhelmed an intermediate onion router and refused to extract the data out the other side and also refused to close the connection) and do a LOT of buffering. Ideas/comments would be appreciated :-) - -Michael -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBM+mz7E8Qx019l0ClAQF2IgQAi1ftpTEkOoJUcs7C+Y2Inc4pfLpqam/S Tf60yKfygFtJJtL3tVPr4taRA3QpDW7GMKHFi+5fQNfGKG48soAx0E/eXV3gf++G /ohXb148SZgJA4W0YiG2Jiwf8yGvQexcE5//FxjyohvZaIvD5vQvsOIRcCTGYxsh NwJFp5TmKtE= =kt3u -----END PGP SIGNATURE----- From majordom Tue Aug 12 14:20:31 1997 Return-Path: Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA13749; Tue, 12 Aug 97 14:20:31 EDT Received: from banana-jr.itd.nrl.navy.mil by itd.nrl.navy.mil (4.1/SMI-4.1) id AA13739; Tue, 12 Aug 97 14:20:25 EDT Date: Tue, 12 Aug 1997 14:20:58 -0400 (EDT) From: "Michael G. Reed" Reply-To: "Michael G. Reed" To: Onion Routing List Subject: Size of cells... Message-Id: X-Personal: False X-Anonymous: False Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-onions@itd.nrl.navy.mil Precedence: bulk All- I just wanted to revive the discussion about changing the CELL size in OR. Just to recap for those of you out of this discussion, cells are the fundamental data unit used to ship stuff around within the OR network. OR requires guaranteed, in-order delivery of cells within the network (or notification that the cell carrying pipe has gone down to proceed with a cleanup operation). Because of this, we currently run over TCP/IP sockets (although we could build this on top of an unreliable protocol such as UDP/IP, but I would rather take advantage of the power of TCP than reinvent the wheel), but we considered the possibility of running OR over an ATM/AAL5 network. To this end, we standardized on our cells being 48 bytes so we could fit within an ATM payload. Of which, 4 bytes are header and 44 bytes are payload. Now we assumed that there would be a good mix (pardon the pun) of traffic -- both interactive and bulk transfer. This has not proven to be the case to date on the OR running here at NRL. We see over 99% of the traffic as web related which has a more bulk transfer like signature. With the future services to be added including FTP and SMTP traffic, this does not appear it will change. In the future, I would be VERY surprised if we say more than 5 or 10% of all traffic being interactive sessions. To this end, it appears that a larger cell payload size would be more efficient and thus more attractive. Add to all of this the fact that most ATM networks that exist today either are running raw ATM protocols for data/voice, or are running TCP/IP over the underlying ATM network. Very few people are running ATM/AAL5 in place of TCP/IP and this trend does not appear to be changing. Some network people conjecture that ATM/AAL5 will never replace TCP/IP, instead ATM will continue to be utilized for backbone network with TCP/IP running over it as used today. On a different note, we are extremely concerned that introducing different levels of service, or variable payload lengths will introduce easy traceability of data through the network (to insiders, not necessarily outsiders although information may leak out to them as well). This will be especially true if only a small class of services use a particular payload length. IE, if we had small but fixed payload length for interactive services and larger but fixed payload lengths for bulk services, it would easily identify interactive services. We are not addressing volume or timing attacks here (ie, cooperating onion routers could correlate timing signatures or data quantities on a particular ACI), but instead size markers. We have ideas to help the volume/timing attacks, but those ideas will be discussed later. What we are trying to come to grips with now are the following: 1) Should we ditch the ATM constraint of 48 byte cells? 2) Should we maintain fixed-length cells or move to variable length? 3) Should we allow different classes of service in terms of cell length? (interactive vs. bulk) 4) If we enlarge the fixed length payload, to what size should we go? (128, 256, 512 bytes? keeping in mind both interactive and bulk data usage) Comments would be greatly appreciated! -Michael From majordom Mon Aug 25 18:00:43 1997 Return-Path: Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA18519; Mon, 25 Aug 97 18:00:43 EDT Received: from sbusol.rz.uni-sb.de by itd.nrl.navy.mil (4.1/SMI-4.1) id AA18513; Mon, 25 Aug 97 18:00:37 EDT Received: from cs.uni-sb.de (ftp.cs.uni-sb.de [134.96.254.254]) by sbusol.rz.uni-sb.de (8.8.5/8.8.4/8.8.2) with ESMTP id AAA25233 for ; Tue, 26 Aug 1997 00:00:35 +0200 (METDST) Received: from fsinfo.cs.uni-sb.de (root@fsinfo.cs.uni-sb.de [134.96.239.10]) by cs.uni-sb.de (8.8.7/97052600) with ESMTP id AAA10549 for ; Tue, 26 Aug 1997 00:00:34 +0200 (CEST) Received: from [134.96.113.178] (acc1-178.telip.uni-sb.de [134.96.113.178]) by fsinfo.cs.uni-sb.de (8.8.7/97070902) with ESMTP id AAA22265 for ; Tue, 26 Aug 1997 00:00:05 +0200 (CEST) Message-Id: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 25 Aug 1997 12:06:45 +0200 To: Onion Routing List From: Lothar Fritsch Subject: Future OR design Re: Size of cells... Sender: owner-onions@itd.nrl.navy.mil Precedence: bulk At 20:20 Uhr +0200 12.08.1997, Michael G. Reed wrote: >All- > I just wanted to revive the discussion about changing the CELL >size in OR. Well, after some days passed I'll give my $0.02 to it. It very much looks like OR reached a point where the further design needs to fit networks or applications it will be used for. If you're mixing ATM, your cell size is fine. If you're mixing Internet, supposedly a larger cell size to fit bulk http and ftp transfer would be the right decision. Fitting telnet and rlogin doesn't deserve a heck lot of attention: first of all, you measured very little usage of the rlogin OR, and second, besides a handful of academic people I don't see a mass application of interactive sessions so you'd even have problems creating the anonymity set to hide the connections in. Maybe people don't even trust the OR (the router might as well copy their passwords). So the only working solution might be sending larger cells containing a single real data byte. Another solution could be imagined, but would add some complexity to the OR network: using the free rlogin cell space to transmit other data. This involved repackacking cells, and seems to be a complex problem to me. The way to go might be to specialize OR: a bulk OR for internet load, custom made ORs for ATM, general TCP/IP OR for internet providers to anonymize their customers, and real-time-large-throughput OR for protecting video-on-demand customers. All these services still might run through the same server to make traffic analysis more expensive. Lothar Fritsch -- Lothar Fritsch Informatik, Fotografie, fritsch@fsinfo.cs.uni-sb.de Internet-Journalist, http://fsinfo.cs.uni-sb.de/~fritsch/ Neue Medien, Schulungen From majordom Tue Aug 26 09:39:51 1997 Return-Path: Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA03634; Tue, 26 Aug 97 09:39:51 EDT Received: from banana-jr.itd.nrl.navy.mil by itd.nrl.navy.mil (4.1/SMI-4.1) id AA03628; Tue, 26 Aug 97 09:39:43 EDT Date: Tue, 26 Aug 1997 09:40:16 -0400 (EDT) From: "Michael G. Reed" Reply-To: "Michael G. Reed" To: Lothar Fritsch Cc: Onion Routing List Subject: Re: Future OR design Re: Size of cells... In-Reply-To: Message-Id: X-Personal: False X-Anonymous: False Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-onions@itd.nrl.navy.mil Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- On Mon, 25 Aug 1997, Lothar Fritsch wrote: |>Well, after some days passed I'll give my $0.02 to it. And there was much rejoicing!!! Finally some input :-) |>It very much looks like OR reached a point where the further design needs |>to fit networks or applications it will be used for. If you're mixing ATM, |>your cell size is fine. If you're mixing Internet, supposedly a larger cell |>size to fit bulk http and ftp transfer would be the right decision. Fitting |>telnet and rlogin doesn't deserve a heck lot of attention: first of all, |>you measured very little usage of the rlogin OR, and second, besides a |>handful of academic people I don't see a mass application of interactive |>sessions so you'd even have problems creating the anonymity set to hide the |>connections in. Maybe people don't even trust the OR (the router might as |>well copy their passwords). |>So the only working solution might be sending larger cells containing a |>single real data byte. I agree. |>Another solution could be imagined, but would add some complexity to the OR |>network: using the free rlogin cell space to transmit other data. This |>involved repackacking cells, and seems to be a complex problem to me. Ugh! Someone here suggested that (he'll remain nameless), and I soundly beat him over the head at the amount of work he was proposing for me to do :-) |>The way to go might be to specialize OR: a bulk OR for internet load, |>custom made ORs for ATM, general TCP/IP OR for internet providers to |>anonymize their customers, and real-time-large-throughput OR for protecting |>video-on-demand customers. All these services still might run through the |>same server to make traffic analysis more expensive. This is a *REALLY* good point. I can imagine several, parallel OR networks. One that would service normal bulk transfers (SMTP/HTTP/FTP/NNTP), one that would support interactive services (IRC/TELNET), and one that would support massive data (VIDEO/VOICE). Since they are distinct, they can have different cell sizes (although the size would be set in stone for each network) to best match the service type. The big drawback is that you loose some of the hiding that you would get if this all went over the same network, but we may make big wins in the following areas: 1) Dedicated high-capacity services (video/voice) wouldn't kill other lower-bandwidth services. 2) Redundancy in network design (ie if one network goes down, the others will keep on running). 3) Better network design/load use (ie, you may not need an Ultra2 with hardware crypto for the interactive sessions that tend to be long with few new connections per day). I like it! Comments? - -Michael -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBNALcxE8Qx019l0ClAQE8GgP7B6CwOR+gNjtym6SOgB0iUEMxLdiH7Hqe cOG6ivsYks9sGkCjwebEAtVNhNB/9WbpP8KwsDA5mSpT6wtCrezLP6v71r1Fwdek Tirr48ps8iNmFLqo9HO150mjFMPWNMTUBaCyl5KuXPsn4fZ0H38Q3P4NnNMidxYT KppzkgdXAWE= =ClI5 -----END PGP SIGNATURE----- From majordom Tue Aug 26 12:29:54 1997 Return-Path: Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA10281; Tue, 26 Aug 97 12:29:54 EDT Received: from netcom9.netcom.com by itd.nrl.navy.mil (4.1/SMI-4.1) id AA10271; Tue, 26 Aug 97 12:29:46 EDT Received: from lucky.netcom.com (shamrock@netcom9.netcom.com [192.100.81.119]) by netcom9.netcom.com (8.6.13/Netcom) id JAA13279; Tue, 26 Aug 1997 09:29:43 -0700 Message-Id: <3.0.2.32.19970826092816.00711e1c@netcom10.netcom.com> X-Sender: shamrock@netcom10.netcom.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 b4 (32) Date: Tue, 26 Aug 1997 09:28:16 -0700 To: "Michael G. Reed" From: Lucky Green Subject: Re: Future OR design Re: Size of cells... Cc: Onion Routing List In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-onions@itd.nrl.navy.mil Precedence: bulk At 09:40 AM 8/26/97 -0400, Michael G. Reed wrote: >This is a *REALLY* good point. I can imagine several, parallel OR >networks. One that would service normal bulk transfers >(SMTP/HTTP/FTP/NNTP), one that would support interactive services >(IRC/TELNET), and one that would support massive data (VIDEO/VOICE). >Since they are distinct, they can have different cell sizes (although >the size would be set in stone for each network) to best match the >service type. The big drawback is that you loose some of the hiding >that you would get if this all went over the same network, but we may >make big wins in the following areas: > > 1) Dedicated high-capacity services (video/voice) wouldn't kill > other lower-bandwidth services. Different routers could offer different published QOS. The user could chose a path that suits their QOS requirements. > 2) Redundancy in network design (ie if one network goes down, the > others will keep on running). Individual routers can go down. Entire networks never should. > 3) Better network design/load use (ie, you may not need an Ultra2 > with hardware crypto for the interactive sessions that tend to > be long with few new connections per day). I agree on 3), but I think breaking up the mix might greatly facilitate traffic analysis. BTW, I agree that you should change the packet size. And congratulations to deciding to go with SSLeay. It is the best crypto library out there. I hope the future-rewrite OR code will match SSLeay's portability. :-) Keep up the good work, --Lucky Green PGP encrypted mail preferred. DES is dead! Please join in breaking RC5-56. http://rc5.distributed.net/ From majordom Tue Aug 26 12:42:05 1997 Return-Path: Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA10762; Tue, 26 Aug 97 12:42:05 EDT Received: from banana-jr.itd.nrl.navy.mil by itd.nrl.navy.mil (4.1/SMI-4.1) id AA10699; Tue, 26 Aug 97 12:40:40 EDT Date: Tue, 26 Aug 1997 12:41:11 -0400 (EDT) From: "Michael G. Reed" Reply-To: "Michael G. Reed" To: Lucky Green Cc: Onion Routing List Subject: Re: Future OR design Re: Size of cells... In-Reply-To: <3.0.2.32.19970826092816.00711e1c@netcom10.netcom.com> Message-Id: X-Personal: False X-Anonymous: False Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-onions@itd.nrl.navy.mil Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- On Tue, 26 Aug 1997, Lucky Green wrote: |>> 1) Dedicated high-capacity services (video/voice) wouldn't kill |>> other lower-bandwidth services. |> |>Different routers could offer different published QOS. The user could chose |>a path that suits their QOS requirements. Exactly. |>> 2) Redundancy in network design (ie if one network goes down, the |>> others will keep on running). |> |>Individual routers can go down. Entire networks never should. Correct -- that is implied as well. |>> 3) Better network design/load use (ie, you may not need an Ultra2 |>> with hardware crypto for the interactive sessions that tend to |>> be long with few new connections per day). |> |>I agree on 3), but I think breaking up the mix might greatly facilitate |>traffic analysis. I'm not so sure that is the case. The real question is how well utilized the network will be. Even with the different padding approaches we've come up with, if users aren't using the network, then it will be more vulnerable. If we see adequate usage of each of the parallel networks, then I don't think we loose in the traffic analysis war, we just don't benefit from having all the traffic together. |>BTW, I agree that you should change the packet size. And congratulations to |>deciding to go with SSLeay. It is the best crypto library out there. I hope |>the future-rewrite OR code will match SSLeay's portability. :-) Um, yes and no. I've already pointed out to the SSLeay authors the fact that there is no direct access to the raw RSA operations without breaking the API (namely, I need raw, unpadded RSA...not that ugly PKCS/SSL padding that RSAREF seems so fond of and they duplicated in SSLeay). I've been given assurances that support for what I need will be in the next release (maybe the one after that), so then we're golden. On another note, there is a new codebase that hasn't been sent out yet that correctly implements the mixing function and also takes care of a REALLY nasty bug in the Solaris version of the system. This codebase also moves from Solaris threads/mutexs to POSIX threads/mutexs, so porting to things like Linux should be quite a bit easier. This new codebase has been sent to only one other individual and should be general available in the next day or two. |>Keep up the good work, Thanks....keep the input coming :-) - -Michael -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBNAMHK08Qx019l0ClAQEDawP+L6cy/aQJhHgFW34tTmYFcYVGA/2eNb/r erl0oN87nvAh7SQv19ZiC+6Wgazsu5YBtwcld/nmPFtq86EBUN2XthkOvGOJY2UQ ZUdDBXf7bFPTon729Fa+M0zbGDhOjF4cIlcrM2al3KAfezdRqy9eFwXD/lfUeKuK wFxkQBcEG8w= =KH6i -----END PGP SIGNATURE----- From majordom Tue Aug 26 19:36:11 1997 Return-Path: Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA23948; Tue, 26 Aug 97 19:36:11 EDT Received: from uni-sb.de by itd.nrl.navy.mil (4.1/SMI-4.1) id AA23942; Tue, 26 Aug 97 19:36:04 EDT Received: from cs.uni-sb.de (cs.uni-sb.de [134.96.252.31]) by uni-sb.de (8.8.7/97052600) with ESMTP id BAA14990 for ; Wed, 27 Aug 1997 01:35:52 +0200 (CEST) Received: from fsinfo.cs.uni-sb.de (root@fsinfo.cs.uni-sb.de [134.96.239.10]) by cs.uni-sb.de (8.8.7/97052600) with ESMTP id BAA23954 for ; Wed, 27 Aug 1997 01:35:53 +0200 (CEST) Received: from [134.96.113.123] (acc1-123.telip.uni-sb.de [134.96.113.123]) by fsinfo.cs.uni-sb.de (8.8.7/97070902) with ESMTP id BAA22674 for ; Wed, 27 Aug 1997 01:35:29 +0200 (CEST) Message-Id: In-Reply-To: <3.0.2.32.19970826092816.00711e1c@netcom10.netcom.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 27 Aug 1997 01:10:53 +0200 To: Onion Routing List From: Lothar Fritsch Subject: Re: Future OR design Re: Size of cells... Sender: owner-onions@itd.nrl.navy.mil Precedence: bulk At 18:28 Uhr +0200 26.08.1997, Lucky Green wrote: >At 09:40 AM 8/26/97 -0400, Michael G. Reed wrote: > >> 2) Redundancy in network design (ie if one network goes down, the >> others will keep on running). > >Individual routers can go down. Entire networks never should. Well, this is an interesting point. OR or MIX networks tend to use chains of servers. One of the servers going down would shut of a lot of connections. And here is where user psychology comes into play: unless you assume some software module (or even OR / MIX testing protocol) generates random paths for the OR chains, users might build preferences for certain ORs (e.g. by only knowing 5 of them and not caring to find more of them). Imagine a certain OR becoming very popular (remeber anon.penet.fi?) and being used by 60% of the users in their chains. Shutting off this OR would severely decrease the networks' uptime for the users. Not to mention security risks created by people always using the same chain of ORs. I think it was Ceki G=FClc=FC (I might be wrong here, just too many papers = do float around on my desk...) who suggested to include the addresses of the following two hops into a data packet, along with increasing the number of ORs used. I personally don't think this increases reliability at all. Lothar PS: Did you ever consider an attack where a OR is slowed down or manipulated so that the TCP/IP connections still exist, but substantially less data is accepted than sent by the senders? TCP buffers throughout the OR's should fill up and traffic slow down and stop along the connection's path ... up to the sender's link. The only way around this seems to be pseudo traffic from the sender's machine to the 1st OR in the chain as soon as the 'regular' link doesn't transmit data any more. Any other ideas? -- Lothar Fritsch Informatik, Fotografie, fritsch@fsinfo.cs.uni-sb.de Internet-Journalist, http://fsinfo.cs.uni-sb.de/~fritsch/ Neue Medien, Schulungen From majordom Tue Aug 26 21:26:14 1997 Return-Path: Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA25299; Tue, 26 Aug 97 21:26:14 EDT Received: from banana-jr.itd.nrl.navy.mil by itd.nrl.navy.mil (4.1/SMI-4.1) id AA25289; Tue, 26 Aug 97 21:26:06 EDT Date: Tue, 26 Aug 1997 21:26:37 -0400 (EDT) From: "Michael G. Reed" Reply-To: "Michael G. Reed" To: Lothar Fritsch Cc: Onion Routing List Subject: Re: Future OR design Re: Size of cells... In-Reply-To: Message-Id: X-Personal: False X-Anonymous: False Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-onions@itd.nrl.navy.mil Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- On Wed, 27 Aug 1997, Lothar Fritsch wrote: |>Well, this is an interesting point. OR or MIX networks tend to use chains |>of servers. One of the servers going down would shut of a lot of |>connections. Yes, a link failing does mean that all current connections through it are immediately lost. We've looked into ways to delay propagating this information (it is potentially a flood of information that may cause an information leak). Furthermore, if the network cannot quickly re-adept, then all new connections that are destined to span that link will fail too. We're currently having a bit of an argument about what kind of topology information needs to be distributed and how it should be distributed. Personally, I'm for the decentralized approach where the link state information (*NOT* routing information... that's a completely different ball) is sent in-band as a new cell type. However, for the short range (ie, time being), I've been beaten into accepting a less than desirable solution of a centralized server that will keep the info. This will have to change if the OR networks are going to scale to any kind of reasonable size. |>And here is where user psychology comes into play: unless you assume some |>software module (or even OR / MIX testing protocol) generates random path= s |>for the OR chains, users might build preferences for certain ORs (e.g. by |>only knowing 5 of them and not caring to find more of them). Imagine a |>certain OR becoming very popular (remeber anon.penet.fi?) and being used = by |>60% of the users in their chains. Shutting off this OR would severely |>decrease the networks' uptime for the users. Not to mention security risk= s |>created by people always using the same chain of ORs. This brings up the whole issue of how to distribute topology information, link-state information, public keys, administrative policies, etc. As I said above, we have a less than stellar solution in the draft stage now, and we plan on revisiting this again later to get a real solution -- these are REALLY BIG problems that need REALLY GOOD solutions if this project is ultimately going to succeed. As for the route generation, if users make that mistake, then there is nothing we can do...I think people will need to realize that you *REALLY* have to trust your local proxy and your internet connection to that proxy...if you don't, you shouldn't be using the system since it doesn't protect you. Given that, I'm not too worried about this. |> I think it was Ceki G=FClc=FC (I might be wrong here, just too many pape= rs do |>float around on my desk...) who suggested to include the addresses of the |>following two hops into a data packet, along with increasing the number o= f |>ORs used. I personally don't think this increases reliability at all. Care to comment (I think he's still on the list :-)? |>PS: Did you ever consider an attack where a OR is slowed down or |>manipulated so that the TCP/IP connections still exist, but substantially |>less data is accepted than sent by the senders? TCP buffers throughout th= e |>OR's should fill up and traffic slow down and stop along the connection's |>path ... up to the sender's link. The only way around this seems to be |>pseudo traffic from the sender's machine to the 1st OR in the chain as so= on |>as the 'regular' link doesn't transmit data any more. Any other ideas? We've considered a LOT of attacks...there is a paper just detailing them alone in the works. It's interesting to note that quite a few of the ones we've come up with are also vulnerabilities in Pipe-Net. We don't necessarily have good solutions to all of them, but then again, not all of them are realistic attacks either (more info soon). - -Michael -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBNAOCUU8Qx019l0ClAQHzrQP+OLhSORU8qMYlZJfFnGk/iJ3kIkAF5qLY 8xeslPcKl8mCXoo22kyp/iOapZ13xXh6Vx4ucNLGbvl3+886NDgMWAoz/8sVH/rM rJJrYw8t7yqGLV/28NMOcm6VrlVK82fsnW0yrnVtV+cas2B9Lc0nExyr+uZG7djy YqWkJitdc7I=3D =3DWK2Q -----END PGP SIGNATURE----- From majordom Tue Aug 26 22:54:41 1997 Return-Path: Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA26225; Tue, 26 Aug 97 22:54:41 EDT Received: from netcom9.netcom.com by itd.nrl.navy.mil (4.1/SMI-4.1) id AA26219; Tue, 26 Aug 97 22:54:33 EDT Received: from lucky.netcom.com (shamrock@netcom2.netcom.com [192.100.81.108]) by netcom9.netcom.com (8.6.13/Netcom) id TAA24366; Tue, 26 Aug 1997 19:54:29 -0700 Message-Id: <3.0.2.32.19970826192717.0069e13c@netcom10.netcom.com> X-Sender: shamrock@netcom10.netcom.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 b4 (32) Date: Tue, 26 Aug 1997 19:27:17 -0700 To: "Michael G. Reed" From: Lucky Green Subject: Re: Future OR design Re: Size of cells... Cc: Onion Routing List In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-onions@itd.nrl.navy.mil Precedence: bulk At 09:26 PM 8/26/97 -0400, Michael G. Reed wrote: >We're currently having a bit of an argument >about what kind of topology information needs to be distributed and >how it should be distributed. Personally, I'm for the decentralized >approach where the link state information (*NOT* routing >information... that's a completely different ball) is sent in-band as >a new cell type. However, for the short range (ie, time being), I've >been beaten into accepting a less than desirable solution of a >centralized server that will keep the info. This will have to change >if the OR networks are going to scale to any kind of reasonable size. A central server on which all users must rely for such crucial information as the network state is a Bad Thing. It lends itself to attack, both spoofing and DoS, provides a single point of failure, etc. This is bad design. Don't waste time on coding a design that you know to be unsuitable to the task. So who do we need to beat up to get them to stop beating you up? :-) [...] >This brings up the whole issue of how to distribute topology >information, link-state information, public keys, administrative >policies, etc. As I said above, we have a less than stellar solution >in the draft stage now, and we plan on revisiting this again later to >get a real solution -- these are REALLY BIG problems that need REALLY >GOOD solutions if this project is ultimately going to succeed. Distributing this information is difficult. Automating the routing process securely may well be impossible. IMHO, there has to be user involvement. > As for >the route generation, if users make that mistake, then there is >nothing we can do...I think people will need to realize that you >*REALLY* have to trust your local proxy and your internet connection >to that proxy...if you don't, you shouldn't be using the system since >it doesn't protect you. Given that, I'm not too worried about this. I tend to agree. [...] >We've considered a LOT of attacks...there is a paper just detailing >them alone in the works. It's interesting to note that quite a few of >the ones we've come up with are also vulnerabilities in Pipe-Net. We >don't necessarily have good solutions to all of them, but then again, >not all of them are realistic attacks either (more info soon). Indeed, Pipe-net is vulnerable to delay attacks. The solution to this type of attack is complex. Still, before discounting any attacks as unlikely, you may want to bounce them off this list. :-) --Lucky Green PGP encrypted mail preferred. DES is dead! Please join in breaking RC5-56. http://rc5.distributed.net/ From majordom Wed Aug 27 16:44:59 1997 Return-Path: Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA25247; Wed, 27 Aug 97 16:44:59 EDT Received: from banana-jr.itd.nrl.navy.mil by itd.nrl.navy.mil (4.1/SMI-4.1) id AA25160; Wed, 27 Aug 97 16:43:28 EDT Date: Wed, 27 Aug 1997 16:44:00 -0400 (EDT) From: "Michael G. Reed" Reply-To: "Michael G. Reed" To: Lucky Green Cc: Onion Routing List Subject: Re: Future OR design Re: Size of cells... In-Reply-To: <3.0.2.32.19970826192717.0069e13c@netcom10.netcom.com> Message-Id: X-Personal: False X-Anonymous: False Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-onions@itd.nrl.navy.mil Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- On Tue, 26 Aug 1997, Lucky Green wrote: |>A central server on which all users must rely for such crucial information |>as the network state is a Bad Thing. It lends itself to attack, both |>spoofing and DoS, provides a single point of failure, etc. This is bad |>design. Don't waste time on coding a design that you know to be unsuitable |>to the task. |> |>So who do we need to beat up to get them to stop beating you up? :-) Some of the preceding messages may have led to misunderstanding of our approach to redesign. We weren't deciding primarily about centralized vs. decentralized solutions to topology information maintenance. We wanted to be open to many approaches for distributing dynamic and static topology information changes, key information changes, etc. The design decision we have currently agreed on is to simplify the functional modules comprising the OR systems. Just as we have separated the proxy and onion creation functions from the routing-mixing modules, we will separate topology maintenance modules from the routing-mixing modules too. Since the r-m module (``r-m'' for routing-mixing) knows the status of its connections to its neighbors, its obligation is to inform the topology maintenance module about changes in that status. It is then up to the topology maintenance modules to distribute this information in some sensible way. Note that while the r-m modules are the source of much topology info, they need nothing more than local neighbor information themselves. Where this information is needed is at the onion building proxies on the edges of OR network, because they are the ones that build the routes. Specifically, onion building proxies must have at least enough of a complete picture of the network link state to build a route. We chose this solution since it takes responsibility for topology maintenance information away from the r-m module to let it focus on its main task. On the other hand, we have been considering the possibility that this modularity should be essentially conceptual. That the r-m module pass topology info as a different cell type, just as we pass data cells for individual connections. This has the possible advantage of reduced IPC costs between the r-m module and the topology maintenance module, and also of adding more traffic to the network to enable better hiding. But, this solution means that the routing-mixing module has to understand the topology maintenance algorithm to decide when and to whom it is appropriate to forward topology cells. This adds complexity to a security critical part of our system. Comments/criticisms on these choices and the advantages of the options are welcome as always. - -Michael -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBNASRlE8Qx019l0ClAQG4TQP6AqhOB0dv5sTF27mHIJtB0WMmxm+qZQP/ PeBUTs8iQK7bkaY8cqjK7y+5CmVr+RyxqikLGHX07doWabUG9QXDdQNanrJoWVpS 7+YusgTZExwwCVvuuLB6Tr9uK5ks36xliYCIT3lpT1EbzI3nDsNA5J4dvhATO+ZY Twa3bY94+jY= =w/us -----END PGP SIGNATURE----- From majordom Thu Aug 28 04:26:29 1997 Return-Path: Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA05426; Thu, 28 Aug 97 04:26:29 EDT Received: from einstein.bluemoney.com by itd.nrl.navy.mil (4.1/SMI-4.1) id AA05420; Thu, 28 Aug 97 04:26:23 EDT Received: (from jeremey@localhost) by einstein.bluemoney.com (8.8.5/8.6.9) id BAA23691; Thu, 28 Aug 1997 01:29:53 -0700 Date: Thu, 28 Aug 1997 01:29:53 -0700 Message-Id: <199708280829.BAA23691@einstein.bluemoney.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: onions@itd.nrl.navy.mil Subject: BSAFE3 for Linux? :-) X-Mailer: VM 6.22 under 19.15 XEmacs Lucid From: Jeremey Barrett Organization: BlueMoney Software Corp. Sender: owner-onions@itd.nrl.navy.mil Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- The core onion router is compiled on Linux, save the linking to the crypto. Before I finish an SSLeay wrapper, does anyone have BSAFE3 for Linux? It would make testing easier, less variables and all that. Thanks, Jeremey. - -- Jeremey Barrett BlueMoney Software Corp. Crypto, Ecash, Commerce Systems http://www.bluemoney.com/ PGP key fingerprint = 3B 42 1E D4 4B 17 0D 80 DC 59 6F 59 04 C3 83 64 -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQCVAwUBNAU24C/fy+vkqMxNAQEUBAQAiZLfDI3fzANVtEJUZZREK1yDM6Rd+MgR AZLqBfbcViS+hwiD4PBjHc0eW9ib+EngEQ3jWka1+cav4Y9bzkeIx2c2UB+t1xnG s9DbxvNzWBadwgMjWrIYqWg7+1UUa85TnpNxWY7+yP8h4JT0UzBRRVhUWScjWCI8 S76DdOVbNwc= =4HLQ -----END PGP SIGNATURE----- From majordom Thu Aug 28 18:52:01 1997 Return-Path: Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA05354; Thu, 28 Aug 97 18:52:01 EDT Received: from einstein.bluemoney.com by itd.nrl.navy.mil (4.1/SMI-4.1) id AA05348; Thu, 28 Aug 97 18:51:56 EDT Received: (from jeremey@localhost) by einstein.bluemoney.com (8.8.5/8.6.9) id PAA01352; Thu, 28 Aug 1997 15:55:37 -0700 Date: Thu, 28 Aug 1997 15:55:37 -0700 Message-Id: <199708282255.PAA01352@einstein.bluemoney.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: onions@itd.nrl.navy.mil Subject: BER RSA keys X-Mailer: VM 6.22 under 19.15 XEmacs Lucid From: Jeremey Barrett Organization: BlueMoney Software Corp. Sender: owner-onions@itd.nrl.navy.mil Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- I've written a wrapper emulating BSAFE calls using SSLeay (so far for DES-CBC, RSA, DH, SHA1, and MD5, everything used in the onion routers). The last step is to figure out BER-encoded RSA keys, so I can turn them into bignums for SSLeay. If anyone knows what the encoding looks like off the top of their heads, please let me know. I have BSAFE on another platform, so at worst I'll write some code to generate both BER and non-BER keys, and compare. BTW, the core router now links cleanly on Linux, so all I need is to decode the RSA keys and I can start dumping core. Thanks, Jeremey. - -- Jeremey Barrett BlueMoney Software Corp. Crypto, Ecash, Commerce Systems http://www.bluemoney.com/ PGP key fingerprint = 3B 42 1E D4 4B 17 0D 80 DC 59 6F 59 04 C3 83 64 -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQCVAwUBNAYB3y/fy+vkqMxNAQEAJQP9FvOhO0Q1nseYqe31QlA1fzq+r/6z/Oa9 ID6y5v7u1vipHjQkh7s+YWitV8dA3X1LnK3O3s8mSychIrOhWRjpbj7H3k5Gqc41 liqHKgSgYDsyKOnaCTg0/fXM2VyXb+R6I9DnWBJD183lra161cg0GJfLWXgXgGA+ RY+4XciMhyU= =Bf0X -----END PGP SIGNATURE----- From majordom Fri Aug 29 07:44:23 1997 Return-Path: Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA15080; Fri, 29 Aug 97 07:44:23 EDT Received: from banana-jr.itd.nrl.navy.mil by itd.nrl.navy.mil (4.1/SMI-4.1) id AA15074; Fri, 29 Aug 97 07:44:16 EDT Date: Fri, 29 Aug 1997 07:44:48 -0400 (EDT) From: "Michael G. Reed" Reply-To: "Michael G. Reed" To: Jeremey Barrett Cc: onions@itd.nrl.navy.mil Subject: Re: BER RSA keys In-Reply-To: <199708282255.PAA01352@einstein.bluemoney.com> Message-Id: X-Personal: False X-Anonymous: False Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-onions@itd.nrl.navy.mil Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- On Thu, 28 Aug 1997, Jeremey Barrett wrote: |>I've written a wrapper emulating BSAFE calls using SSLeay (so far |>for DES-CBC, RSA, DH, SHA1, and MD5, everything used in the onion |>routers). The last step is to figure out BER-encoded RSA keys, |>so I can turn them into bignums for SSLeay. If anyone knows |>what the encoding looks like off the top of their heads, please |>let me know. |> |>I have BSAFE on another platform, so at worst I'll write some code |>to generate both BER and non-BER keys, and compare. According to my BSAFE manuals..."The standard description of information is known as Basic Encoding Rules, or BER, which is a product of Open Systems Interconnection of the ANSI X.200 series. BER is defined in X.209." It looks like X.209 is based on X.208 which is ASN.1, which (correct me if I'm wrong) is what SSLeay uses (or is capable of using). Probing around RSA-land will get you to http://www.rsa.com/rsalabs/pubs/PKCS/ which includes links to "A Layman's Guide to a Subset of ASN.1, BER, and DER" written by Burton S. Kaliski. A more useful publication, "Some Examples of the PKCS Standards" gives quick examples of the format of both public and private keys which have been BER encoded...THIS IS WHAT YOU WANT :-) It may be that you can use SSLeay's ASN.1 routines without any real work, or you may need to pick apart the keyfiles directly...not sure. Remember, my key-files include multiple keys that are stacked one after another in the form ULONG length, unsigned char data[length], unsigned char pad. Where pad is 0-4 bytes to make the next field in the file long aligned. This length fields are 32-bit longs stored in network order. |>BTW, the core router now links cleanly on Linux, so all I need is to |>decode the RSA keys and I can start dumping core. Ugh! That was not very punny...good luck - -Michael -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBNAa2NE8Qx019l0ClAQFSJwP/YlMt+OPPwSCs1eeTy9IDVZTzooHig9yk irlDGjJ/WNnxEUDect653W7pTRNfBlNF1Cdexs6ZrHgUS/hDtBlGxh/MMCsaToem CpLtEgQosmGgxoi0j2t7MU48ul97xqeFVRtluhPjRtehWUv8Plen7kYw1MgL/FNS 2QoFcheJSJg= =eI19 -----END PGP SIGNATURE----- From owner-onions Tue Dec 16 12:36:21 1997 Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id MAA03625 for onions-outgoing; Tue, 16 Dec 1997 12:35:28 -0500 (EST) Received: from banana-jr.itd.nrl.navy.mil (banana-jr.itd.nrl.navy.mil [132.250.80.211]) by itd.nrl.navy.mil (8.8.8/8.8.8) with SMTP id MAA03614 for ; Tue, 16 Dec 1997 12:34:54 -0500 (EST) Date: Tue, 16 Dec 1997 12:34:53 -0500 (EST) From: "Michael G. Reed" Reply-To: "Michael G. Reed" To: Onion Routing List Subject: New code tomorrow! Message-ID: X-Personal: False X-Anonymous: False MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-onions@itd.nrl.navy.mil Precedence: bulk All- There will be a new code release (the proof-of-concept system) that corrects a few bugs that we've had reported from our testers. This will probably be the last update on this code since development has now begun on the next generation system. Full specs on the new system will be forthcoming after the holidays. Those who have received source and binaries in the past will receive personal email with the name of the new tar file to FTP. If you are one of the active nodes in the network, please upgrade your node as soon as possible. Thanks! -Michael From owner-onions Tue Dec 16 16:39:15 1997 Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id QAA08962 for onions-outgoing; Tue, 16 Dec 1997 16:37:31 -0500 (EST) Received: from banana-jr.itd.nrl.navy.mil (banana-jr.itd.nrl.navy.mil [132.250.80.211]) by itd.nrl.navy.mil (8.8.8/8.8.8) with SMTP id QAA08953 for ; Tue, 16 Dec 1997 16:36:58 -0500 (EST) Date: Tue, 16 Dec 1997 16:36:59 -0500 (EST) From: "Michael G. Reed" Reply-To: "Michael G. Reed" To: Onion Routing List Subject: Looking for 'porters' Message-ID: X-Personal: False X-Anonymous: False MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-onions@itd.nrl.navy.mil Precedence: bulk All- Now that we are starting the next generation code, we will be trying to support as many platforms as possible. In house, we are developing against: sparc Solaris 2.4, 2.5.1, 2.6 sparc SunOS 4.1.3u1 hppa HPUX 10.00 rs68k AIX 4.1.3 i386 BSDI 3.0 i386 Red Hat Linux 2.4 Our primary development platforms are Solaris 2.5.1 & Linux 2.4. We hope to add a i386 NetBSD/OpenBSD/FreeBSD set of machines as well, but that is on temporary hold. WHAT WE ARE LOOKING FOR: People who are interested enough in the project to dedicate some time porting the code to other platforms (either other OS's, versions of OS, or hardware platform). Please respond to onion-info@itd.nrl.navy.mil if you are interested in giving us a hand. -Michael