16:15:27 <asn_> #startmeeting SoP-kernelcorn
16:15:27 <MeetBot> Meeting started Tue Jun 23 16:15:27 2015 UTC.  The chair is asn_. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:15:27 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
16:15:33 <asn_> ok
16:15:35 <asn_> here we go
16:15:48 <asn_> so repo is https://github.com/Jesse-V/OnioNS
16:16:01 <asn_> i guess we should wait a bit for kernelcorn to do a status update
16:16:12 <asn_> on things he has done, and things he will be doing short-=term
16:16:25 <Yawning> and what he needs from us if anything
16:16:32 <asn_> i admit i still haven't reviewed his code at all
16:16:47 <asn_> i was trying to wrap my head around how to test this whole system
16:16:52 <asn_> so that i can test it while reviewing
16:16:57 <asn_> but i have no idea how to test it.
16:18:21 <Yawning> hmm no recent commits, have you just not pushed recently?
16:18:25 <Yawning> (feature branches?)
16:18:34 <asn_> https://github.com/Jesse-V/OnioNS/issues
16:19:16 <kernelcorn> ok, yes
16:20:04 <kernelcorn> that is the repo, https://github.com/Jesse-V/OnioNS/issues?q=is%3Aopen+is%3Aissue+milestone%3A0.3.x are the issues I'm working on atm in line for the next release
16:20:59 <kernelcorn> Yawning: I'm working locally, haven't pushed.
16:21:44 <kernelcorn> I've been tackling replacing std::cout with logging to a file, which involves changing std::cout in almost every file
16:21:55 <Yawning> ah I see
16:22:24 <kernelcorn> so it does not compile yet, and I have a policy to allow my commits to compile
16:22:50 <asn_> ok
16:22:51 <kernelcorn> You are welcome to review the code, but I think it best if you wait until I finish a release, then you can check everything in conjunction with testing it
16:23:04 <asn_> how do you test stuff?
16:24:16 <kernelcorn> I fire up my own network, which isn't too hard. In the last release, I used a single server, so it's a simple matter of firing up the server on a public-facing machine, then passing its IP to the client and HS functionality
16:24:38 <Yawning> do you have unit tests?
16:25:19 <kernelcorn> I have integration tests, but not unit tests, no. As you can see, there are tickets on them.
16:25:50 <kernelcorn> It's challenging to do unit tests for networking code, so I might have to resort to integration tests
16:26:27 <kernelcorn> as for progress, the essential functionality of the client, hidden service operator, and server are there
16:26:56 <asn_> by 'server' you mean relay?
16:27:37 <asn_> unit tests for netwokring code don't need to be so challenging. unit tests for functions that parse network data should exist, I think.
16:27:37 <kernelcorn> yes. Right now the server code does not run on Tor relays (it runs independently) so I felt "server" was the better term
16:27:42 <asn_> ok
16:27:45 <asn_> that's fine
16:28:14 <asn_> when do you think the next release will be?
16:28:46 <kernelcorn> I'm trying to get it before PETS, but we'll see. I've been busy with a few other projects.
16:29:08 <kernelcorn> If you want to test the last release, I can fire up the server code and you could do that
16:29:33 <asn_> i think testing is the first thing i'm going to do
16:29:36 <asn_> this seems like too many LoCs to review.
16:29:41 <Yawning> in the short (and medium term) do you need anything from us?
16:29:46 <kernelcorn> Yawning, asn_, do you have an understanding of how the project works?
16:29:53 <kernelcorn> no, I think I've got it
16:29:59 <asn_> 65% understanding here.
16:30:02 <Yawning> beyond testing/reviw and that spec I need to write
16:30:13 <kernelcorn> at the HS meetings after PETS, I will discuss what changes I need from Tor.
16:30:42 <Yawning> I'm neither going to that or pets
16:30:52 <Yawning> but I will send my faithful minion asn
16:30:57 <Yawning> to act on my behalf
16:31:14 <kernelcorn> Mainly I need ed25519 keys or RSA keys for each Tor relay (nick is removing the rsa-1024 keys)
16:31:17 <kernelcorn> ok
16:31:18 <Yawning> :P
16:31:35 <Yawning> from every relay?
16:31:45 <Yawning> you can extract that out of the control port I think, if not, it'd be easy to add
16:32:41 <kernelcorn> the Tor consensus is a great PKI, everyone already has each other's keys. I need a key in order to sign the data structures in a way that everyone can verify
16:32:58 <Yawning> oh
16:33:06 <Yawning> signing with the id key, maybe not a good idea
16:33:09 <Yawning> hmm
16:33:26 <kernelcorn> I don't see a problem with that, that was my plan. We are moving to ed25519 anyway.
16:33:39 <Yawning> prolly cross certify a separate key with the id key
16:34:03 <kernelcorn> I can convert Curve25519 keys to Ed25519 and sign with those, but I have not seen any research that suggests that such a move is cryptographically secure
16:34:11 <Yawning> it's not
16:34:14 <Yawning> don't do that
16:34:21 <kernelcorn> yes
16:34:38 <nickm> why not just assume everybody's got an ed25519 key?
16:34:39 <kernelcorn> Yawning: ideally yes, but I'm aiming for easy integration with Tor
16:34:43 <Yawning> so what I would suggest is, an ed25519 key, that's signed by the relay's long term id key
16:35:16 <Yawning> maybe I'm wearing too many tinfoil hats
16:35:40 <kernelcorn> Yawning: that requires a non-trivial amount of changes to relays, clients, and authorities. nickm, I was making that assumption because soon everyone will have ed25519
16:36:06 <kernelcorn> Yawning: there's nothing wrong with a medium-term signing key, that's a good idea, but it does require more work
16:36:19 <nickm> there's already a medium term signing key in the architecture
16:36:22 <nickm> you don't need to add one
16:36:26 <kernelcorn> for the authorities
16:36:53 <Yawning> (Is this where, look over prop 220 comes into play? :P)
16:37:22 <kernelcorn> yes
16:37:39 <kernelcorn> 224 is related of course
16:38:02 <kernelcorn> asn_: would you like me to go over how the system works again?
16:38:19 <asn_> we can do this in PETS
16:38:32 <asn_> i think that's better
16:39:12 <kernelcorn> I agree
16:39:15 <Yawning> https://cheezburger.com/6591767040
16:39:24 <Yawning> ok, lemmie know if you need stuff
16:39:42 <asn_> kernelcorn: that will be in less than week, so that's quite soon!
16:40:07 <kernelcorn> actually, right now I do need advice on how to integrate with the Tor Browser
16:40:11 <Yawning> hm
16:40:40 <kernelcorn> my goal for the next release is to launch the client-side software + a python script with the Tor Browser
16:41:04 <Yawning> I dunno how tor launcher works
16:41:17 <Yawning> and you will hate life integrating it into the build system
16:41:34 <Yawning> because testing gitian descriptor changes takes forever
16:41:48 <kernelcorn> https://github.com/Jesse-V/OnioNS/issues/27
16:42:23 <kernelcorn> hmm. Currently I'm requiring users to launch two terminal windows and run the software, that's not ideal
16:42:48 <Yawning> eventually tor will launch your thing, once an interface for doing so has been nailed down yes?
16:43:38 <kernelcorn> I'm envisioning telling the users to download the Tor Browser, then run a script that installs my software into their Tor Browser, enabling OnioNS
16:44:06 <Yawning> ah I see
16:44:18 <kernelcorn> Yawning: the two client-side applications ("onions --client" and "python client.py") need no interface
16:44:26 <kernelcorn> so I just need them to run in the background
16:45:03 <kernelcorn> currently I launch them from two terminals while the Tor Browser is running, but I would like to move away from that.
16:46:13 <asn_> kernelcorn: might be worth dropping by a TBB meeting
16:46:19 <Yawning> mondays
16:46:24 <asn_> and asking the TBB folks how you shoudl do this
16:46:26 <Yawning> at some stupid time for me
16:46:33 <kernelcorn> I'm confident that I can get the programs to autolaunch with the Tor Browser. There's the nice way and the hacky way of doing that.
16:46:34 <Yawning> (they're gonna say gitian)
16:46:53 <kernelcorn> https://github.com/Jesse-V/OnioNS/issues/27#issuecomment-114022073
16:48:04 <asn_> shit delivery is here
16:48:14 <asn_> got to go. will be back in 10 mins or so.
16:48:24 <Yawning> (do we have more specific stuff to cover?)
16:48:29 <kernelcorn> also, in your opinion, how many CPU hours would you consider a good cost to claim a domain name?
16:48:29 <asn_> don't think  so
16:48:30 <asn_> not me at least
16:48:51 <Yawning> unless there's questions for me, I'm good
16:49:00 <asn_> kernelcorn: hmmm
16:49:06 <kernelcorn> HS operators must perform computational work, which involves making signatures with their HS key
16:49:09 <asn_> kernelcorn: 0 hours would be ideal i guess
16:49:14 <asn_> but there is a security tradeoff here i guess
16:49:17 <kernelcorn> no, because then you have flooding
16:49:44 <kernelcorn> currently I was thinking that HS operators should get a domain after about four hours of CPU work on an i7
16:49:54 <asn_> seems OK
16:49:59 <asn_> i guess...
16:50:02 <Yawning> all the people that want to be evil will just throw a botnet or something at this anyway
16:50:19 <Yawning> pick something reasonalbe, and discuss later?
16:50:32 <kernelcorn> yes, or use the cloud, but they will then need to export their private key
16:50:46 <kernelcorn> ok, well I don't have anything else unless you have questions for me
16:50:54 <kernelcorn> so I think we may be done here
16:50:57 <Yawning> ok
16:51:02 <asn_> #endmeeting