13:28:43 <nickm> #startmeeting 13:28:43 <MeetBot> Meeting started Thu Feb 4 13:28:43 2016 UTC. The chair is nickm. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:28:43 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic. 13:28:50 <nickm> Hi all, it's about time 13:28:55 <Yawning> herro 13:29:11 <wwhyte> Hello hello 13:29:18 <zhenfeizhang> Hello 13:29:19 <jschanck> Hi 13:29:20 <wwhyte> I have a school run to do but should be back in 15 13:29:25 <wwhyte> Don't wait for me 13:29:45 <nickm> isis: ping 13:30:12 <nickm> so, everybody knows where to find the proposals we're talking about, right? 13:30:15 <Yawning> I have comments for the handshake stuff, the large create cell proposal looked ok. 13:30:17 <Yawning> yah 13:30:18 <isis> nickm: pong 13:30:27 <nickm> yaay 13:30:34 <isis> peter schwabe is also here, shouldersurfing 13:30:40 <zhenfeizhang> https://gitweb.torproject.org/torspec.git/tree/proposals/263-ntru-for-pq-handshake.txt 13:30:48 <zhenfeizhang> https://gitweb.torproject.org/torspec.git/tree/proposals/249-large-create-cells.txt 13:30:53 <isis> i'll just prefix things with [peter] when peter is saying something 13:31:08 <armadev> (hi peter!) 13:31:33 <isis> [peter] hi to everyone! 13:31:34 <Yawning> So the 5 zillion btc question is, is what nickm told me about newerhope true, and if so should I hold off on ammending the spec? 13:31:51 <nickm> (let's start with 263, since that's the one we're all here to talk aobut I think) 13:32:18 <Yawning> should I just give feedback from my notes? 13:32:33 <isis> [peter] we'll change k from 12 to 16, and the message format will change slightly 13:32:46 <isis> [peter] agl has a blog post 13:32:50 <nickm> Hm. How about I try to summarize what the proposal is, and everybody can correct me if I get it wrong? 13:33:06 <jschanck> Sounds good 13:33:38 <isis> https://www.imperialviolet.org/2015/12/24/rlwe.html 13:33:47 <Yawning> peter: agl uses a more condensed encoding for initiator->responder, but there's no savings the other way without using a simpler reconciliation method right? 13:33:47 <isis> nickm: sounds good 13:34:01 <nickm> The idea is to come up with a circuit extension handshake that is no less secure than ntor, and which additionally resists an offline attacker with a quantum computer. (This is equivalent to resisting an attacker who has no quantum computer today, but who may have one later.) 13:34:24 <Yawning> when I asked him about it the impression I got was he was like "fuck it, I'll just use Peikert's since it's simpler to write up" 13:35:11 <Yawning> (sorry, this can wait) 13:35:28 <nickm> So in addition to sending the ntor CREATE and CREATED parts, we also send additional material in the create and created cells. The client sends a single-use public key key in some lattice-based PK encryption scheme. The server replies by encrypting a nonce to that public key in the CREATED cell. 13:35:42 <nickm> The KDF now includes that nonce as one of its inputs. 13:35:49 <isis> [peter] Yawning: you do a polynomial encoding; what agl does one way saves space, and then just use the same encoding in th eother direction as well 13:36:08 <Yawning> (peter: ahhh k) 13:36:17 <nickm> did I get the description right? 13:36:42 <nickm> oh. also, include the lattice public key as one of the KDF inputs too 13:36:44 <Yawning> yeah, though RLWE is better visualized as "an extra DH-like keypair" rather than encryption 13:36:45 <jschanck> nickm: yeah, to be clear any (?) KEM can be used, doesn't need to be lattice-based PKE 13:36:55 <Yawning> (though under the hood the KEM scheme is a one time pad) 13:37:09 <zhenfeizhang> Yes. Thats right. Just one minor thing, the lattice-based pk also goes to KDF, so both client and server contribute to the randomness 13:37:22 <isis> [peter] Yawning: agl didn't understand the encoding, so he just described another, but there will be a write up on ours in a few weeks (since there is a deadline) 13:37:37 <Yawning> peter: looking forward to it <3 13:37:47 <nickm> so, it seems like there are two main questions to ask: 13:37:51 <Yawning> (see, I'm not scary) 13:37:56 <nickm> 1) Is this the right construction? 13:38:01 <nickm> 2) Which KEM? 13:38:14 <nickm> Let's talk about 1 first? 13:38:17 <Yawning> My opinions are 1) Yes 13:38:42 <Yawning> with a minor tweak or two I think 13:38:58 <nickm> What alternatives should we consider? 13:39:03 <jschanck> ok, I think there's room for debate on 1. You might want to go straight for post-quantum authentication 13:39:10 <Yawning> the proposal specifies HMAC_SHA3 but naked SHA3 is sufficient 13:39:31 <Yawning> jschanck: I don't think there's a suitable scheme that has keys that are easily distributable 13:39:40 <nickm> Yawning: for KDF I think we want SHAKE? 13:39:47 <Yawning> indeed 13:39:48 <jschanck> Yawning: agreed 13:39:54 <nickm> Yawning: say more? 13:40:03 <Yawning> for PQ auth? 13:40:08 <nickm> armadev and I know the least about PQ schemes here. 13:40:09 <Yawning> our microdescriptors will get huge 13:40:20 <nickm> Yawning: you don't need a signing key for auth. 13:40:25 <isis> 1) yes 13:40:30 <nickm> like, I agree that auth isn't the priority. 13:40:38 <armadev> i'm mostly listening here. i have not read the proposal nor read the paper. 13:40:43 <Yawning> you can't do 3DH with RLWE 13:40:54 <nickm> but if we include a public encryption key in the MD, we can do something like TAP with it: 13:40:57 <Yawning> key reuse destroyes the security properties 13:41:00 <nickm> ah. 13:41:03 <nickm> then never mind. 13:41:25 <Yawning> NTRU fares better here, but PFS is desierable 13:41:48 <Yawning> whcih pushes us towards a signing algorithm 13:42:14 <nickm> To be clear, is it just PFS that you lose by reusing keys in these schemes, or is it worse? 13:42:29 <zhenfeizhang> we don't reuse keys. NTRU key gen is fast. we can get PFS with one-time ntru keys. 13:42:45 <isis> [peter] my intuition is that i would wait with PQ authentication 13:42:52 <Yawning> zhenfeizhang: right, but nickm wants to do authenticated handshake 13:42:55 <Yawning> without signatures 13:43:02 <nickm> Well, I want to know how hard that would be. 13:43:02 <Yawning> eg a tripple dh handshake 13:43:05 <nickm> well no 13:43:09 <nickm> can't do triple dh 13:43:37 <isis> [peter] the intuition being that you only need it once there is a quantum computer, and by then there's much better algorithms (hopefully) 13:44:06 <Yawning> peter: ack, or bandwidth improves to where the hit for adding sphincs keys to every relay is affordable 13:44:06 <isis> [peter] 3DH on the ECC side is just fine 13:44:52 <Yawning> I think the scope of the current proposal is correct in that it encompases what is practical 13:44:59 <zhenfeizhang> We can't get both PFS and Auth at the same time without signature, I think. PFS is more important, it matters for now. Auth matters after quantum computer arrives. 13:44:59 <Yawning> given currently available primitives 13:45:02 <nickm> like, here's a simple approach http://paste.debian.net/378505/ 13:45:11 <nickm> Not saying we should do it, but I'd like to know if it would work 13:45:16 <armadev> so, doing PQ auth would prevent even a mitm attack on the handshake right then, but the downside is that the keys are huge and unwieldy? and the design we're looking at here falls to an adversary who can mitm the handshake right then, but protects against one who thinks really hard about the recorded traffic flow later? 13:45:32 <Yawning> armadev: correct 13:45:37 <armadev> great 13:45:40 <nickm> specifically, existing PQ signature designs people believe in have huge keys. 13:45:45 <Yawning> signatures are also uh 13:45:48 <Yawning> quite large 13:45:54 <nickm> that too 13:46:06 <Yawning> some of the lattice onces are a few kib, sphincs is ~40 13:46:36 <Yawning> nickm: QPK_Server if we're talking NTRU, isn't sufficiently smaller than a sphincs key 13:46:51 <Yawning> so at that point we might as well just sign 13:46:57 <isis> armadev: correct 13:46:58 <karsten> (metrics team meeting in 12 minutes moves to #tor-project) 13:47:21 <Yawning> though what you have will wirth with NTRUEncrypt 13:47:25 <nickm> Yawning: well, we'd save the 40k for the signature, right? 13:47:44 <Yawning> yeah 13:47:53 <Yawning> there's a bunch of lattice based signature schemes that have smaller signatures 13:47:58 <armadev> i'm in no hurry to move to huge keys that we don't need right now and might not need for a long while. doing something about providing *actual* PFS seems very useful though. 13:48:19 <Yawning> but BLISS-B is really hard to implement fast without timing side channels 13:48:30 <zhenfeizhang> BLISS and pqNTRUsign both have key/pk size less than 1k. 13:48:39 <nickm> one reason I'm pushing on this is a half-formed idea I have that TAP saved us from precomputation-based discrete log attacks on our DH group. 13:49:18 <armadev> yes. "don't show people the public key unless you have to" seemed wise then and turned out to be wise. 13:49:21 <nickm> Looking at the TAP design, it seems that an adversary who has done the necessary expensive precomputation to do discrete logs on our NIST DH group couldn't do it against TAP, since the g^x value is encrypted. 13:49:22 <Yawning> nickm: depending on the KEM, we can get that with what we have now 13:49:35 <nickm> interesting 13:49:54 <Yawning> eg: newhope, the common parameter is regenerated on a per-handshake basis (`a` in the paper) 13:50:48 <nickm> so maybe something like this: http://paste.debian.net/378511/ ? 13:50:49 <isis> [peter] there will be an improved version of SPHICS this year, but i don't think you need it now 13:51:26 <nickm> making at least half of the ntor handshake get encrypted with a single-use key sounds potentially beneficial and pretty cheap. 13:51:31 <Yawning> (there was also some ring-lwe based signature scheme paper, but it's really new) 13:51:35 <nickm> but I Am Not A Real Cryptographer 13:51:47 <isis> i mentioned to peter the idea of sending a hash of the SPHINCS public key in the microdescriptor, since we're relying on the hash's pre-image resistance anyway 13:52:02 <isis> [peter] definitely don't use BLISS 13:52:32 <Yawning> having to generate newr-perfect gausian entropy basically killed me interest in BLISS 13:52:41 <Yawning> because that's Not Fun and Really SLow 13:52:46 <isis> [peter] BLISS needs a bunch of assumptions, is also hell to implement efficiently without leaking a ton of timing info 13:52:52 <nickm> we're moving on to 2 right now. Let's stick with 1 for a minute longer? 13:53:19 <Yawning> nickm: what you pasted seems sensible for the NTRU based handshake 13:53:45 <nickm> Yawning: would it fail for the Ring-LWE handshakes for some reason? 13:53:47 <isis> [peter] there are people working on better things for this, specifically léo ducas, andy hülsing, and kit 13:53:56 <Yawning> ring-lwe looks like dh 13:54:05 <nickm> ok. So you can still do that. 13:54:16 <Yawning> ah I see 13:54:32 <Yawning> QPK_server, E(sharedsecret, nonce || ntor_blablahblah) as the response 13:54:45 <nickm> yes. Authenticated encryption, obviously. 13:55:00 <zhenfeizhang> nickm, i think your paste will work. TLS starts to encrypt all extensions too. 13:55:13 <isis> peter says we'd better talk to andy about whether it's possible to do something with a collision against sending just the hash of the SPHINCS pubkey in the microdescriptor 13:55:17 <Yawning> yeah, the 2nd revision fo the paste works 13:55:30 <zhenfeizhang> and with ntru, the cost of E(nonce) is almost the samse as E(nonce||ntor) 13:55:39 <Yawning> nickm: your 2nd paste is how I did the basket handshake 13:55:44 <Yawning> welcome to 2014 :P 13:55:46 <nickm> :) 13:55:52 <nickm> good ideas keep coming up 13:55:55 <nickm> (yay prior art) 13:56:24 <Yawning> So to summerise so far 13:56:31 <Yawning> "auth can wait" 13:56:36 <nickm> yes. 13:56:43 <Yawning> "we should encryupt more stuff" 13:56:54 <nickm> agreed. TAP did some smart things by accident. 13:57:00 <nickm> (And some dumb things too) 13:57:15 <Yawning> "SHAKE for the KDF, no more HMAC, use SHA3 on it's own when we need a fixed length dighest" 13:57:26 <Yawning> (since SHA3(key || msg) is safe) 13:57:40 <nickm> [anybody object to that part? I'd say SHA3(const || key ||msg).] 13:57:50 <nickm> but basically yeah. 13:57:59 <nickm> anybody want to push for blake2b? 13:58:00 <Yawning> a tweak is good yeah 13:58:16 <isis> nickm: no blake2b 13:58:24 <Yawning> I don't think our fips202 stuff is that slow 13:58:25 <isis> nickm: also yes on const 13:58:45 <Yawning> and it has a rediculous secuirty envelope 13:58:46 <Yawning> so 13:58:56 <isis> [peter] agreed 13:59:08 <Yawning> (also this stuff will be parallelized once I finish my branch) 13:59:45 <Yawning> Do we have more to add here, or should we move on to 2? 14:00:00 <Yawning> where we argue about parameter sets etc 14:00:10 <nickm> (let's move on to 2! On 2 I am very far out of my depth) 14:00:17 <nickm> so I will mostly be listening. 14:00:45 <isis> [6~[6~[6~[6~[6~[6~[6~on to #2 then 14:00:55 <Yawning> IIRC the proposal currently specifies product form parameter sets for NTRU right? 14:01:09 <wwhyte> Yes 14:01:28 <zhenfeizhang> I remember we want non-product form, correct? 14:01:37 <Yawning> I would prefer non-product form parameter sets because I do not know how Redhat/debian legal will react even witht he grant 14:01:39 <Yawning> yes 14:02:28 <wwhyte> Redhat should be fine, right? Given that everything is also available under GPL 14:02:35 <wwhyte> Debian is the question 14:02:42 <Yawning> There was that paper by the person at about running grover's vs the hash used for the padding function 14:02:54 <Yawning> wwhyte: they did some odd things with openssl till fairly recently 14:03:04 <Yawning> (stripping out the ECC code entirely due to patent paranoia) 14:03:17 <jschanck> Yawning: we deprecated the parameter sets that still used SHA1, no longer affected by grover 14:03:24 <Yawning> jschanck: excellent 14:04:04 <zhenfeizhang> I assume Tor wants a SHA3 version of parameter sets, right? 14:04:14 <isis> yes 14:04:17 <zhenfeizhang> SHA3, non-product form. 14:04:20 <karsten> (metrics team meeting now happening in #tor-project) 14:04:23 <isis> [peter] yes 14:04:24 <Yawning> sha256 would be ok, sha3 woudl be extra nice 14:04:25 <Yawning> yes 14:05:21 <Yawning> I think that covers the stuff I had on the back of my mind re NTRU 14:05:38 <Yawning> RingLWE can wait till newerhope I think 14:05:55 <Yawning> since this will miss the 0.2.8 merge window, so we have 6 months+ 14:05:57 <nickm> Do we want ntru, newesthope, something else...? Is it worth keeping our options open on that count? 14:06:09 <Yawning> I think we want at least 2 14:06:14 <nickm> well, we have 6 months till the next merge window. 14:06:21 <Yawning> it's flexibile so we can add more later 14:06:37 <nickm> which one do clients use? :) 14:06:38 <Yawning> there was brief discussion on tor-dev about having ntru + newesthope as an option 14:07:13 <Yawning> (which is the "overkill, por que no los dos?" approach to this) 14:07:55 <Yawning> hmm, I haven't benchmarked optimzed ntru vs avx2ed newhope 14:08:18 <nickm> By asking "which do clients use", I mean, we can have servers support both, but we need clients to pick one. 14:08:47 <zhenfeizhang> Having ntor + ntru + newesthope (strikes back?) may affects the performance quite noticeably. 14:09:15 <Yawning> I was thinking both > ntru > newesthope (no offense to peter, but ntru has had more analysis) 14:09:20 <Yawning> would be ok initially 14:09:23 <zhenfeizhang> nickm: i think yawning's idea is to miss all three, so client will need to send both ntru and r-lwe pks. 14:09:24 <isis> [peter] i don't think you want clients to pick one, the right thing to do is just choose proper crypto and have everyone use it 14:09:51 <Yawning> zhenfeizhang: yes 14:10:12 <jschanck> agree w/ peter. the modular approach shouldn't be taken as liberty to introduce a ton of new ciphersuites 14:10:19 <isis> also i don't think we should pile NTRU and newesthope on top of each other, it seems like it would be hella overhead 14:10:31 <Yawning> (imo: we really need PQ-FS now, but all the primitives coud use another few years of analysis) 14:10:38 <nickm> isis/peter: Sorry; when I say "clients must pick one" I mean "We must pick one that that clients will actually use". 14:10:57 <nickm> I'm not seriously considering the idea of pushing the decision onto the enduser 14:10:58 <isis> [peter] if you prefer NTRU in the end, i can put you in contact with léo ducas, who can do a proper parameter analysis 14:11:13 <Yawning> I think, part of this comes down to, "what will debian legal do wrt ntru" 14:11:24 <armadev> nickm: (they're saying the "one" that clients pick should be a composition of two) 14:11:26 <isis> [peter] nickm: ah, okay, i misunderstood. good. 14:11:58 <Yawning> we should have an unencumbered option that everyone supports that we think is sensible 14:12:01 <wwhyte> How can we find out what Debian legal will do? Is there a person we can ask? 14:12:06 <Yawning> in addition to ntru 14:12:13 <Yawning> that's a good question 14:12:36 <Yawning> (our relays have a bit of a debian monoculture problem) 14:13:00 <nickm> let's ask weasel whom to ask maybe? He doesn't like to talk when meetbot is listening though. 14:13:32 <Yawning> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=802259 14:13:44 <Yawning> that was what amde me nervous about the whole thing 14:14:07 <Yawning> but INAL nor a Debian developer 14:14:25 <nickm> ug. 14:14:40 <Yawning> I just think it would be silly to provide pqfs with something that the bulk of the relays won't package 14:14:44 <isis> i strongly suspect that debian's reaction will be ~1000 anarchistic developers who are strongly opposed to patents, having roughly 3000 slightly differing opinions on this case, which all generally coalesce to "NO." 14:14:51 <wwhyte> https://www.debian.org/legal/patent 14:14:52 <nickm> well, I guess we get all the documents and licenses and ask what debian-legal thinks 14:15:08 <wwhyte> Right 14:15:28 <Yawning> (I feel really bad about bringing this up, because I think the patent grant is reasonable) 14:15:50 <wwhyte> No that's fair 14:16:30 <isis> but if this gets tor kicked from the debian repositories, it makes it much harder for less-weird people to install, and that becomes true for millions of people using debian-based systems 14:16:32 <nickm> The combination of the two grants I've seen (commercial-tor-only, GPL-only) seems DFSG-complaint to me. (IANAL,TINLA) 14:17:02 <Yawning> isis: well we could --enable-ntru feature gate it or something 14:17:10 <Yawning> so I don't think it'll go that far 14:17:15 <Yawning> but we should have a plan b 14:17:40 <Yawning> I think we have a decent amount of time to work this all out 14:17:49 <Yawning> and we're waiting on newesthope anyway 14:17:50 <nickm> let's go with "collect all the information, ask debian-legal, and make sure that the conversation includes somebody on the ntru side who can figure out if anything needs to be amended"? 14:17:58 <Yawning> so I see no reason not to move forward with ntru for now 14:17:59 <armadev> i think we need ~all relays to support this, or it won't work; and we need tor to remain dfsg-free. so we need versions of all these things that are sufficiently free and unencumbered. 14:18:23 <Yawning> armadev: I *will* add a Ring-LWE based option 14:18:46 <Yawning> the basic scheme is modular by design 14:18:51 <armadev> is that going to make it non-free? we can take this fight outside. :) 14:18:53 <nickm> to be clear: if patents were no issue, what would we use? 14:19:22 <Yawning> just by virtue of the amount of analysis, probably NTRU? 14:19:33 <Yawning> (though I really like newhope)( 14:20:00 <Yawning> I wish I had nother 5 years to sit around and wait for more analysis on all this stuff :( 14:20:12 <Yawning> but that evil building in Utah is a thing Now 14:21:03 <nickm> So, I'm kind of feeling a consensus on this -- work to get ntru through debian-legal (permission, not forgiveness) , and make sure we implement two options in case of Badness? 14:21:14 <nickm> and have the client default be ntru? 14:21:19 <jschanck> What's the timeline on deployment for something like this? Is deployment before aug 22, 2017 (when the non-product form patent expires) a possibility? 14:21:26 <nickm> IMO yes 14:21:34 <Yawning> IMO yes 14:22:04 <Yawning> 0.2.9 timeframe ideally, so sometime this year 14:22:07 <isis> it would be included in the 0.2.9 release in september 2016, correct? 14:22:08 <nickm> October/November 2015 would be the first stable release that could include it; March/April 2017 would be the second. 14:22:27 <armadev> s/2015/2016/g 14:22:34 <jschanck> ok, was just hoping you could skip the patent debate entirely. nvm 14:22:43 <zhenfeizhang> would link to ntru lib like --enable-ntru get around the patent issue for now? 14:23:07 <nickm> isis: I'd give that about 50% odds. We don't have a schedule for sep2016 yet where we can say "we know what we will have time to do" 14:23:08 <Yawning> zhenfeizhang: I belive so, it would be up to the packager to support it or not then 14:23:10 <wwhyte> If we need Debian sign-off on patents anyway, maybe it's worth going straight to product form -- there's no downside to using it v non-product-form and it makes things faster 14:23:34 <Yawning> wwhyte: good point 14:23:45 <Yawning> kind of depends what they say too 14:23:48 <wwhyte> Right yes 14:23:50 <Yawning> if they're like "Hell no" 14:24:02 <Yawning> but, changing the parameter set is easy 14:24:03 <nickm> zhenfeizhang: For debian's purposes, yes. But if we did that, we'd have no ntru on debian clients, which means that debian clients would be distinguishable from regular clients unless LWE was the default. 14:24:19 <Yawning> the bigger problem is 14:24:28 <isis> [peter] i have to take off to teach a lecture, so i'm taking off. it was good to talk with all of you! 14:24:34 <Yawning> I suspect the majority of our relays are debian based 14:24:39 <nickm> thanks for all the crypto peter! 14:24:45 <zhenfeizhang> I see, thanks. 14:24:45 <Yawning> tkae care peter! 14:24:59 <Yawning> so if debian is like "no", the adoption would take a huge hit 14:25:53 <Yawning> but I think at this point, we've done most of the speculation 14:25:54 <nickm> well, maybe it will be easy. The notorious case people point to was the ECC case. But the ECC case was a minefield, where many of the patent holders were deliberately obfuscating what their patents covered. 14:25:58 <Yawning> and we need to start writing e-mails 14:26:06 <Yawning> nickm: indeed 14:26:31 <wwhyte> Yeah we aren't aware of any NTRU-relevant patents other than the ones we hold 14:26:40 <wwhyte> And hopefully the grant is unambiguous 14:26:45 <nickm> Yeah. For the ntru case, we have patent holders who seem to want the patent situation to be clear, and want DFSG-compliant implementations to be obviously permissible. 14:26:50 <wwhyte> Exactly 14:26:54 <Peng> Red Hat had more of an issue with ECC than Debian 14:27:03 <wwhyte> "Seem to want" :-) 14:27:27 <Yawning> Optimistically, hopefully this is just a matter of the patent holders and debian talking to eachother 14:29:47 <nickm> Also in the ECC situation, there were tons&tons of patents for obvious optimizations, patents which should not have been granted because of prior art, etc. This doesn't seem to be going on here too. 14:29:56 <Yawning> *nods* 14:29:59 <nickm> wwhyte: no offense intended. ;) 14:30:31 <Yawning> So apart from deciding who gets to write all the e-mails 14:30:32 <wwhyte> I have to head to the airport unfortunately but do let me know if it'd be useful for me to get on an email thread with patents@debian. 14:30:41 <isis> not to add more fuel to the patent war fire, but… another thing which we should consider is the PR perspective that The Tor Project would essentially be advocating for crypto created by people who patent things. (apologies if this seems rude, but i feel concerns.) 14:30:44 <Yawning> do we have other stuff to argue about? ;) 14:31:01 <nickm> isis: well, we did that for ECC too. :) 14:31:09 <nickm> but yeah, we should have some philosophy time. 14:31:15 <nickm> We didn't talk about prop#249 yet. 14:31:17 <nickm> thanks wwhyte ! 14:31:26 <Yawning> thanks wwhyte! 14:31:38 <isis> nickm: alright true… slightly different, but true. 14:31:39 <nickm> Does anybody want to draft the initial email for us to send to debian-legal? If not I will. 14:31:48 <nickm> isis: also RSA 14:31:55 <armadev> i have finished reading proposal 263. i'm going to commit my grammar/etc fixes in a bit, and maybe somebody can skim them to make sure i didn't break the protocol? :) 14:31:56 <isis> thanks for joining us, wwhyte! 14:31:58 <Yawning> I belive this is a nickm/wendy thing? 14:32:02 <nickm> Yawning: sadly! 14:32:11 <nickm> Yawning: I'll circulate it to this whole group for comment before sending 14:32:17 <Yawning> Real life is exploding for me 14:32:18 <isis> armadev: sure 14:32:20 <nickm> #action nickm drafts that email 14:32:26 <Yawning> for the next 1.5 weeks :( 14:32:34 <nickm> Yawning: good luck with the move! 14:32:49 <Yawning> should be ok, dealing with the last of my paperwork tomorrow 14:33:25 <isis> Yawning: i hope your moving goes well :) 14:33:32 <armadev> nickm: i have two design questions around prop#249 14:33:37 <nickm> great 14:34:22 <armadev> first is, why not set the hlen accurately in subsequent cells? the proposal sets it to 0, so somebody has to count. somebody has to count anyway. actually saying how many bytes you're planning to use could be helpful in some future. 14:34:58 <nickm> armadev: because I want the information to only be set in one place. 14:35:10 <zhenfeizhang> thank armadev. I will modify #263 after your modification. I will change sha3, shake, etc. 14:35:15 <nickm> The idea being that if there are two things that need to be consistent, there's a risk of letting them become inconsistent 14:35:33 <nickm> zhenfeizhang: should I do the tweak from the second paste, or will you? 14:35:45 <nickm> (this one http://paste.debian.net/378511/ ) 14:35:52 <armadev> zhenfeizhang: there, i just pushed my little fixes. all yours. (or nickm's) 14:36:05 <zhenfeizhang> nickm: I can do it. 14:36:12 <nickm> thanks! 14:36:28 <armadev> https://lists.torproject.org/pipermail/tor-commits/2016-February/101829.html 14:37:54 <armadev> nickm: ok. so the current approach in 249 precludes sending any less than the full number of bytes in subsequent cells. does this limit us in any meaningful way? 14:38:22 <nickm> it means we need to generate the full message before we start sending it. I think that's probably a good thing. 14:38:23 <isis> armadev: i don't see your torspec changes on arma/torspec.git 14:38:30 <nickm> isis: he pushed them to master 14:38:42 <isabela> oi 14:38:56 <isis> nickm: ah doh 14:39:48 <nickm> (does anybody not buy my reasoning about one-length-only?) 14:40:03 <Yawning> nickm: seems fine 14:40:12 <nickm> basically, I'm thinking about IP fragmentation and getting twitchy. :) 14:40:39 <armadev> and that leads to my second question: 14:40:41 <armadev> "These cells must be sent on the circuit with no intervening cells." 14:40:50 <armadev> "Clients MAY send RELAY_DROP cells during circuit construction in order to hide the true size of their handshakes." 14:40:59 <armadev> by "during", do you mean "after"? 14:41:49 <nickm> after the handshake, before being done with making the whole ciruit. 14:41:52 <nickm> "during" in that sense 14:43:45 <nickm> anything else on prop#249 ? 14:44:05 <armadev> - Clients MAY send RELAY_DROP cells during circuit construction in order to 14:44:06 <armadev> - hide the true size of their handshakes. 14:44:06 <armadev> + Clients MAY send RELAY_DROP cells during circuit construction (but 14:44:06 <armadev> + not in the middle of a train of EXTENDV2 cells) in order to hide the 14:44:06 <armadev> + true size of their handshakes. 14:44:21 <armadev> s/EXTENDV2/EXTEND2/ i guess 14:44:58 <nickm> maybe clarify that you can do it between the extend2 cells for one create cell, and the extend2 cells for the next 14:45:21 <armadev> ok. also, relays can send relay-drop cells back, right? but not inside a train? 14:45:29 <nickm> yes 14:45:37 <Yawning> chooo choo 14:47:06 <nickm> ok. anything else for today? I think this went well! 14:47:15 <Yawning> indeed 14:47:28 <armadev> nothing more from me. except i'm looking forward to seeing the table of patents, unhappiness, and expiration dates :) 14:47:49 <nickm> Thanks everybody! I'll #endmeeting in 1 minute unless there's something else. 14:48:56 <nickm> #endmeeting