From pde at eff.org Mon May 21 15:30:34 2012 From: pde at eff.org (Peter Eckersley) Date: Mon, 21 May 2012 15:30:34 -0700 Subject: [Sovereign Keys] Parameters for a hash tree In-Reply-To: <1334588360.6818.9.camel@lap19.cdc.informatik.tu-darmstadt.de> References: <1334588360.6818.9.camel@lap19.cdc.informatik.tu-darmstadt.de> Message-ID: <20120521223034.GB4903@xylophonic> I am persuaded that hash trees are a good addition to the protocol. I only have one niggling concern about them, which is the IO/memory requirements for mirrors, which are required to compute the alternative hash paths necessary to answer each client's query. Keeping the entire hash tree in memory for this purpose might become an unreasonable requirement for mirror operators one day (for 2x10^8 timeline entries and 256 bit hashes, that's 100GB of RAM), but computing everything on the fly sounds problematic too. However, I think there are plausible caching strategies where you keep the topmost and frequently-queried portions of the hash tree in RAM, but go to disk 1-3 times for unusual queries. On Mon, Apr 16, 2012 at 04:59:20PM +0200, Erik Tews wrote: > Hi > > I did some calculations how one could build a hash tree to verify that a > response from a mirror is really correct and based on a current database > from a timeline server. I pushed some notes to github: > > https://github.com/eriktews/Sovereign-Keys/commit/f1983f6ad810c7c28fa27041d6bf710d2f1e0cca > > And you can find a google docs spreadsheet online where you can play a > bit with the parameters: > > https://docs.google.com/spreadsheet/ccc?key=0Ak_UqCvQqMRAdGVMTU9KRVZLQUFKUENyZzdfYUkzUEE > -- Peter Eckersley pde at eff.org Technology Projects Director Tel +1 415 436 9333 x131 Electronic Frontier Foundation Fax +1 415 436 9993 From pde at eff.org Mon May 21 15:44:15 2012 From: pde at eff.org (Peter Eckersley) Date: Mon, 21 May 2012 15:44:15 -0700 Subject: [Sovereign Keys] issues/bridge-exposure.txt : Sovereign Keys as an oracle for censorship circumvention methods Message-ID: <20120521224415.GC4903@xylophonic> I was initially quite pessimistic when I realised this issue existed: https://git.eff.org/?p=sovereign-keys.git;a=blob;f=issues/bridge-exposure.txt;h=f5a259056f59d23487cdd008cef5a1fa8a937c4d;hb=HEAD In a sense, it undercuts one of the main design objectives of SKs ("fall back to censorship-resistant secure routing, but only when required"). The fall back to secure routing part is still ok, but it turns out that it's hard to only be censorship resitant when you're actually being censored. -- Peter Eckersley pde at eff.org Technology Projects Director Tel +1 415 436 9333 x131 Electronic Frontier Foundation Fax +1 415 436 9993 From pde at eff.org Mon May 21 15:58:45 2012 From: pde at eff.org (Peter Eckersley) Date: Mon, 21 May 2012 15:58:45 -0700 Subject: [Sovereign Keys] Sovereign Keys and Tor Message-ID: <20120521225845.GD4903@xylophonic> A lot of people ask about the degree to which Tor and hidden services /need/ to be the fallback routing mechanism for SKs. One answer is: they don't. SKs could be used with no fallback, or with proxies, VPNs, or some other complicated fallback routing mechanism. It would be up to the client to decide what fallbacks, if any, to use in case of MITMs or connection blocking. Of course, there is benefit to standardisation: servers and clients using the same secure routing method creates an incentive for everyone to get on that same bandwagon. At the moment, Tor looks like the most robust option we have. The design is currently a little big vague on these questions. I'm thinking about updating it to make fallback to a Tor hidden service an /option/ for the server operator, and to allow other (arbitrary) fallback specifications. So eff.org can say, "1234567890abcdefgh.onion is our fallback", google.com can say "use an UDP OpenVPN to 8.8.8.8 port 88", and someone else could say "we have an I2P service, here's the address!" Control over these fallbacks would be added to the existing "Alteration of protocols" message. I imagine that if we do end up building and deploying SKs, we'll encourage servers and clients to support .onion fallbacks by default, but that won't be required. -- Peter Eckersley pde at eff.org Technology Projects Director Tel +1 415 436 9333 x131 Electronic Frontier Foundation Fax +1 415 436 9993 From erik at datenzone.de Tue May 22 00:11:49 2012 From: erik at datenzone.de (Erik Tews) Date: Tue, 22 May 2012 09:11:49 +0200 Subject: [Sovereign Keys] Parameters for a hash tree In-Reply-To: <20120521223034.GB4903@xylophonic> References: <1334588360.6818.9.camel@lap19.cdc.informatik.tu-darmstadt.de> <20120521223034.GB4903@xylophonic> Message-ID: <1337670709.17902.19.camel@lap19.cdc.informatik.tu-darmstadt.de> Am Montag, den 21.05.2012, 15:30 -0700 schrieb Peter Eckersley: > I am persuaded that hash trees are a good addition to the protocol. Thanks > I only have one niggling concern about them, which is the IO/memory requirements > for mirrors, which are required to compute the alternative hash paths > necessary to answer each client's query. OK, I commented on this: > Keeping the entire hash tree in memory for this purpose might become an > unreasonable requirement for mirror operators one day (for 2x10^8 timeline > entries and 256 bit hashes, that's 100GB of RAM), but computing everything on > the fly sounds problematic too. However, I think there are plausible caching > strategies where you keep the topmost and frequently-queried portions of the > hash tree in RAM, but go to disk 1-3 times for unusual queries. In a nutshell, you can use the intermediate signatures I suggested. If you do so, you just cache these 65536 intermediate signatures in RAM (a few MB) and store the hash tree up to this intermediate signature on disk with the SK database entry. This adds about 416 bytes to each database entry (keep in mind that this adds redundancy to the data, but this will help to increase the performance). Now, there is no noticeable performance decrease, because you get the hash tree with the same read you use to get the SK database entry. Only the number of entries that can be cached in memory is slightly decreased, because a entry is slightly larger and less entries fit in the memory cache. > On Mon, Apr 16, 2012 at 04:59:20PM +0200, Erik Tews wrote: > > Hi > > > > I did some calculations how one could build a hash tree to verify that a > > response from a mirror is really correct and based on a current database > > from a timeline server. I pushed some notes to github: > > > > https://github.com/eriktews/Sovereign-Keys/commit/f1983f6ad810c7c28fa27041d6bf710d2f1e0cca > > > > And you can find a google docs spreadsheet online where you can play a > > bit with the parameters: > > > > https://docs.google.com/spreadsheet/ccc?key=0Ak_UqCvQqMRAdGVMTU9KRVZLQUFKUENyZzdfYUkzUEE > > > > > From erik at datenzone.de Tue May 22 00:22:26 2012 From: erik at datenzone.de (Erik Tews) Date: Tue, 22 May 2012 09:22:26 +0200 Subject: [Sovereign Keys] Parameters for a hash tree In-Reply-To: <1337670709.17902.19.camel@lap19.cdc.informatik.tu-darmstadt.de> References: <1334588360.6818.9.camel@lap19.cdc.informatik.tu-darmstadt.de> <20120521223034.GB4903@xylophonic> <1337670709.17902.19.camel@lap19.cdc.informatik.tu-darmstadt.de> Message-ID: <1337671346.17902.20.camel@lap19.cdc.informatik.tu-darmstadt.de> Am Dienstag, den 22.05.2012, 09:11 +0200 schrieb Erik Tews: > Am Montag, den 21.05.2012, 15:30 -0700 schrieb Peter Eckersley: > > I am persuaded that hash trees are a good addition to the protocol. > > Thanks > > > I only have one niggling concern about them, which is the IO/memory requirements > > for mirrors, which are required to compute the alternative hash paths > > necessary to answer each client's query. > > OK, I commented on this: Sorry, I forgot to add the URL: https://github.com/eriktews/Sovereign-Keys/compare/ideas-from-erik-tews