15:00:41 #startmeeting SponsorR 15:00:42 Meeting started Fri Apr 10 15:00:41 2015 UTC. The chair is asn. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:42 Useful Commands: #action #agreed #help #info #idea #link #topic. 15:00:50 hello there 15:01:03 ohmygodel: you think syverson will make an appearance? 15:01:10 no i dont 15:01:24 ok np 15:01:35 so let's start with the status reports 15:01:52 over the past week I looked a bit at #15513 15:01:56 hi meeting 15:02:03 athena: hello 15:02:18 i wrote a tor-dev thread about popularity and hidden services: https://lists.torproject.org/pipermail/tor-dev/2015-April/008597.html 15:02:31 as part of our discussion with syverson 15:02:36 thanks for writing long, detailed emails, btw. 15:02:45 and I also wrote a proposal for encrypted services: https://lists.torproject.org/pipermail/tor-dev/2015-April/008625.html 15:03:05 i was supposed to do work on #13239, but that didn't seem that exciting at that time. 15:03:23 mainly because it required tracing and other stuff that I dn't really know how to do 15:03:28 so I decided to focus attention elsewhere. 15:03:31 anyway, that was from me. 15:03:36 who wants to go next? 15:03:41 I can go next. 15:03:44 karsten: please 15:03:57 I worked on #15513, then you looked and commented, then I worked more on it. 15:04:01 there's a new set of graphs on the ticket now. 15:04:03 that's all. 15:04:04 yep just saw 15:04:05 willl take a look 15:04:16 next? 15:04:18 * ohmygodel can go 15:04:20 ohmygodel: please 15:04:27 all i did for memex this week 15:04:30 was to read some smc papers 15:04:37 and think about how the protocols might go 15:04:45 thats it 15:04:48 ack 15:05:07 i took a look at SMC code, and nickm also did so. he can tell us about it if he wants later. 15:05:08 next? 15:05:12 I read a whole bunch of ccl codes, manuals, and websites 15:05:16 nickm: aha 15:05:22 ccl? 15:05:25 smc 15:05:26 sorry 15:05:29 ack 15:05:40 ( ccl is the school where my kid goes; they just sent me an email :) ) 15:05:48 :) 15:06:10 cool nick which ones did you look at ? 15:06:11 I've also been looking at parallelizing things a bit, and implementing some of the ideas from clemson folks. 15:06:35 ohmygodel: I looked at both of the ones you sent me. The code is very immature and the documentation is more or less useless 15:06:47 yeah that doesnt surprise me 15:06:47 and there's insecure coding practices all over, too 15:06:52 thanks for looking at it 15:07:17 nickm: parallelizing what things? 15:07:21 nickm: SMC things? or HS things? 15:07:40 I looked at a bunch of other systms, and found a couple where the maturity was nicer, but I hear (from ohmygodel) that they don't have the security model we want, even though they are more mature 15:08:16 asn: hidden service and circuit extension stuff 15:08:21 ah great 15:08:48 like pushing the circuit extension crypto to cpuworkers? (if that's not already done) 15:09:02 at the client side, yes. 15:09:04 also introduce handling 15:09:07 ack 15:09:09 sounds good! 15:09:15 nickm: anything else? :) 15:09:20 both will be a bit tricky, but i think we can get there 15:09:38 I thouht more about SMC but didn't get any excellent conclusions. let's talk more 15:09:46 ack 15:09:49 who next? dgoulet ? 15:09:57 yup 15:10:00 good morning world 15:10:29 worked on writing the hs health measurer specification, TorSoP review, had to investiguate a bit weird warnings I'm getting on my relay after 15515 fallout. Not much R but next week will be full of it :) 15:10:46 great 15:10:55 what graphs will you be making? 15:10:57 do you know? 15:11:22 asn: not yet but I have a couple in minds to visualize relay churn towards HS rechability 15:11:56 ok 15:11:58 still have to figure out that part, visualization 15:12:02 let's be in contact. 15:12:07 sure 15:12:24 ok sounds good. 15:12:25 anyone else? 15:12:35 so let's move to discuss phase, I guess. 15:12:45 i think with the upcoming quarterly meeting coming, we should talk a bit about it. 15:13:22 did I read well, that they gave Tor 10 mins of presentation? 15:13:29 5 :P 15:13:56 i think the point is mostly to tell other teams how you can work on the challenge problems 15:14:05 Especially since they want us to focus on "what we want to do this week 15:14:06 and what we need help with / what we offer to others". 15:14:20 Especially since they want us to focus on "what we want to do this week 15:14:20 and what we need help with / what we offer to others". 15:14:21 oops 15:14:26 ok 15:14:30 so it's not even about presenting progress? 15:14:35 i think that the PM (chris) uses the monthly progress reports to find out what we have been doing, and doesnt see the need to spend time having each team share that with all other teams 15:14:47 ah ok 15:14:55 that makes sense i guess 15:15:08 yeah and it,s not as "official" as in January, mostly collaboration between teams instead of full day of progress report 15:15:13 the challenge problems are mostly supposed to be “what we want to do this week” 15:15:18 but ok it could be broader than that 15:15:40 fair enough 15:15:57 do we want to talk more about the upcoming meeting? 15:15:59 dgoulet: ? 15:16:17 would you benefit from something like that? 15:16:32 I have no idea what to expect again so I doubt that would benefit anything :S 15:16:39 fair enough 15:16:42 so next topic? 15:16:53 dgoulet: I'm available next week, in case you need me for something. 15:17:06 i'm quite happy by #15513 15:17:11 right I'll try to make sure to update you guys on what's going on there :) 15:17:22 dgoulet: yes, please do. 15:17:25 asn: it's fun. 15:17:36 asn: the crazy rotation period of IPs from agora is still unsolved? 15:17:37 #15513 seems useful to us. and i think this is the kind of stat the sponsor will like. 15:17:43 dgoulet: no. 15:17:58 dgoulet: i think it's some kind of crazy OPSEC hax, so I've been ignoring it. 15:18:08 i've mainly looked at the hidden wiki and the other 3. 15:18:19 hidden wiki being the most interesting of them all. 15:18:26 some things id like to discuss 15:18:29 ohmygodel: yes 15:18:30 1. the top-down plan ? 15:18:35 2. SMC plans 15:18:49 ok 15:18:50 … ok thats it 15:18:50 great 15:18:59 let's start with the top-down plan 15:19:08 https://docs.google.com/spreadsheets/d/1mY8wax7FBUIAPAmDLpGcEtYCYCcsxW21KtLCntRbSk0/edit?pli=1#gid=0 15:19:23 i think currently we are looking at the first 3 questions 15:19:31 that is #15513 and the HSDir stuff that dgoulet is working on. 15:20:01 and there are people who have been doing the honeypot stuff (like naif), but we haven't been involved much with them. 15:20:25 maybe we should try to get some figures from them to show to the sponsor at some point. 15:20:48 where do we collect results? 15:20:50 my plan is to focus 100% on hs health next week with folks their and hopefully a bit of Roger 15:20:51 in tickets? 15:21:03 and some ohmygodel :) 15:21:13 * karsten isn't saying the word tech and report. 15:21:25 the network testing part (stress test) would be a very useful one I think in the short-mid term 15:21:26 dgoulet: ack. 15:21:27 ha 15:21:30 and overlaps with S/U 15:21:33 karsten: ok good point 15:21:41 karsten: i think before the july meeting, we should write anothe tech report 15:21:48 you said it, ok. 15:21:50 karsten: with the statistics/figures we have been collecting these months. 15:22:03 or mayeb we could write a blog post directly. 15:22:09 sounds good. 15:22:16 but we can look at this in a month or so? 15:22:23 absolutely. 15:22:28 since we have decided that we don't need to present anything like this during april meeting. 15:22:30 so, tickets for now. 15:22:35 karsten: yes tickets.\ 15:22:42 15:21 < dgoulet> the network testing part (stress test) would be a very useful one I think in the short-mid term 15:23:05 dgoulet: yes, i will be able to look at this more after i finish exams 15:23:14 and you guys can help too, if you find yourself with free time in the mid-term future. 15:23:21 ohmygodel: what else would you like to discusso n this? 15:23:30 asn: cool! had a talk with nickm last little-t tor meeting, chutney2 apparently could be used, thus things are in motion 15:23:40 chutney2???? 15:23:43 oh yes! 15:23:49 new and improved Jam 15:23:56 oh 15:24:00 didn't know. interesting. 15:24:04 it exists, or will it exist? 15:24:07 asn: how/when are the second and third questions being addressed ? 15:24:16 asn: exists in some nickm's internal documents for now :) 15:24:32 well, it's not there _yet_. 15:24:36 it's very designish 15:24:45 in fact, I threw away the first 2 designs 15:24:54 best to undersell, I think. :/ 15:24:58 ohmygodel: not sure. 15:25:01 still, I hope for goodness 15:25:19 asn: so were just looking into the first one in the near future 15:25:22 is that correct 15:25:23 ? 15:25:24 ohmygodel: i'm not sure how we prioritize between the remaining questions. we never got to that part. 15:25:41 yes, and then move to next questions after we finish with the first one. 15:25:54 ok makes sense 15:25:55 i'm fine with the person who does the job, picking the question he likes from the spreadsheet. 15:26:34 ok 15:26:51 so smc ? 15:26:52 yes 15:27:23 i see a couple of uses for SMC 15:27:47 the first is that it could allow Tor to collect its current statistics more accurately and securely, and it could enable Tor to collect more statistics 15:28:00 the second is that it could allow researchers to measure Tor more safely 15:28:27 +1 to both ideas 15:28:45 The state of the art in SMC implementations seems to let us down a bit. 15:28:52 for example, they could collect long-term trends in the ASes of clients without risk of disclosing interim results by sharing intermediate data among distributed aggregators 15:29:23 General purpose SMC to resist hostile (byzantine?) adversaries seems not to exist in a form that we can actually use. 15:29:40 nickm: it seems to me that using SMC for these purposes would probably involve implementation of the protocols customized for Tor’s efficiency and security requirements 15:29:46 yeah 15:29:55 we're not going to get away with somebody else's implementation here 15:30:04 I wonder whether we can reuse some code, though. 15:30:19 they do serve as a useful proof of concept 15:30:24 and I also wonder whether we can save time by doing something less hurculean than arbitrary circuit evaluation. 15:30:57 that by using the optimizations they adopt, SMC can be as secure and efficient as we would like 15:31:23 nickm: that has been a hope of mine, and i know that nick hopper has some customized protocols in mind 15:31:34 the problem i have with his protocols is that they leak some information 15:31:38 how much? 15:32:07 for example, in Sec. 8 of our Peerflow submission 15:32:10 that protcol is his 15:32:18 and it leaks a full histogram of observed traffic amounts 15:32:35 its better than all the individual measurements from relays 15:33:25 but still way more than just the total traffic amount 15:33:39 yeah 15:34:09 :/ 15:34:16 so im hoping to work with nick hopper on bringing SMC to Tor 15:34:46 interesting. nick could be a good person for that. 15:34:47 and if it works out 15:35:13 then maybe Tor itself would find it worthwhile to create/adopt an implementation for its own use 15:36:05 nick hopper sent me this paper 15:36:09 https://eprint.iacr.org/2014/482.pdf 15:36:28 that describes how to use SMC to automatically produce differentially-private results 15:36:45 so the aggregate automatically has the noise you want 15:37:04 it apparently has code as well 15:37:07 interesting 15:37:23 the stuff in tables 2-4 seems concice-ish. 15:37:29 *concise 15:37:35 https://sites.google.com/site/arithmeticsmpc/ 15:38:24 nickm: not sure if you are joking or not 15:38:36 the authors themselves suggest applying these techniques to “Traffic Statistics for Anonymous Communication Networks” 15:38:45 maybe i'm not used at looking at SMC protocols 15:38:50 nice 15:38:53 looks definitely relevant 15:39:28 asn: I've seen worse! 15:39:37 the code is more uncommented stuff 15:39:44 tables 2 and 4 rely on SMC protocols for each of those FL* and FP* functions (which exist elsewhere in the literature) 15:39:50 what is it with smc people and hating to document their code? 15:40:14 ha not sure 15:40:50 i need document my code just for myself later. not sure how other people dont need to do that. 15:41:11 .oO(maybe they don't read it later.) 15:41:22 ^ :) 15:41:36 ok, ohmygodel and nickh definitely seem like a good team for such a task,. 15:41:59 ok glad we talked about this 15:42:25 great 15:42:28 anything else to talk about? 15:42:39 that would be quite novel work/reasearch if we can pull it off in the network :) 15:42:40 ohmygodel: Please loop me or somebody on on it so that there's somebody asking "how do we actually implement that" all the time? 15:42:52 nickm: +1 15:43:15 iiuc we will be the first people on the internet using SMC for something serious 15:43:28 nickm: ack 15:43:47 thx 15:43:52 asn: not sure about that. this company apparently sells it: . 15:43:55 anything else to talk about or are we going for an early finish? 15:43:58 http://cyber.ee/en/security-technologies/sharemind/ 15:44:11 wow 15:44:18 cyber cyber 15:44:34 ohmygodel: thought you said we couldn't use their stuff? 15:44:47 we can’t because they use the honest-but-curious model 15:44:58 they do that for efficiency 15:45:11 oh 15:45:11 i guess that works for other people though 15:45:32 IIUC, hbc usually means "Willing to do bad stuff, but not willing to get caught". is that right in this case? 15:46:03 the solutions for the malicious model tend to just add to the honest-but-curious protocols some checks for malicious behavior at certain steps, so its not like a completely different technology 15:46:12 nickm: not quite 15:46:21 oh dear 15:46:26 what you describe is called the “covert model” 15:46:41 the honest-but-curious model is that you assume that everybody follows the protocol correctly 15:46:53 ah. That's... silly. 15:46:58 the adversary may then try to use what he observes to determine the secret values though 15:47:17 so in terms of adversary strength it goes hbc < covert < malicious 15:47:53 nickm: yeah, and malicious attacks definitely exist on hbc protocols 15:48:10 so its not just that they cant prove malicious security 15:49:15 btw i do have a question about threat model 15:50:07 what does everybody think about two-party protocols is privacy is guaranteed as long as both parties arent compromised 15:50:12 *if privacy is 15:50:46 two party what protocols? 15:50:49 2-party seems... suboptimal 15:50:57 but I hear that 2-party makes things much much easier 15:51:02 2 party SMC? 15:51:03 ah 15:51:04 how much I don't knwo 15:51:12 yeah 2 party smc 15:51:19 i think social milionaire protocol by OTR is a 2 party SMC 15:51:24 yeah 15:51:25 or not mayeb 15:51:28 it is 15:51:37 there is a generalization to multiparty 15:51:44 where a majority must be honest for privacy 15:52:03 so then you need >= 5 parties to achieve the better resiliance to a single compromise than the 2-party situation 15:52:18 but how would you use a 2party protocol to do SMC on all Tor relays? 15:52:29 does pairwise even make sense in thsis context? 15:52:33 the idea is to have a separate set of Statistics Authorities 15:52:38 they are the only ones running the SMC 15:52:53 tor relay would only ever divide their data into shares via some simple secret sharing 15:53:06 and send each share to a StatAuth 15:53:08 (*socialist milionaie protocol) 15:54:06 for reference, FairPlay implements this idea by dividing the protocol into “input parties”, “computation parties” and “results parties” 15:54:15 * karsten needs to leave and attend the next meeting in 6. 15:54:20 karsten: ack. thx. 15:54:45 ok then that will be all from me on smc :-) 15:54:53 thanks ohmygodel 15:54:56 very nice 15:55:04 i think i need to read a bit more theory here to better undersrtand how these things work in our context... 15:55:29 ohmygodel: I'll probably ask you to teach me a bit about all this next week :) 15:55:37 great idea 15:55:40 dgoulet: sounds fun 15:55:43 ok. thanks for the discussion folks. 15:55:46 #endmeeting