<Mutiny>	[00:05] Has anybody here checked out 6/4?
<arma>	[00:07] 6/4 ?
<Mutiny>	[00:08] yeah
	[00:08] The Six/Four System is a new protocol standard for decentralized peer-to-peer networks. Data between Trusted Peers and clients is tunneled using a trusted public key for data encryption and authentication. Together with the decentralized, Gnutella-like, but anonymous mode of routing in the Six/Four Network, this makes state-sponsored censorship based on either host-based access controls or content filtering ultimately impossible.
	[00:08] http://www.hacktivismo.com
<arma>	[00:30] "ha"
<Mutiny>	[00:33] ha?
	[00:33] heh. the first part of the build process is generating a key pair. before it even compiles anything.
<arma>	[00:34] is there a design doc for 6/4 yet? or a spec?
	[00:34] last i checked it was a bunch of yammering.
<Mutiny>	[00:35] looks like it's got lots of docs.
	[00:37] arma: http://doomtown.mutinyeng.com/sixfour-do cs/
<arma>	[00:41] skimming
<Mutiny>	[00:42] if you don't see a bunch of 'readme' files refresh
<arma>	[00:44] no, i got the tgz
<Mutiny>	[00:44] even better
<arma>	[00:47] ah. their anonymity is based on deniability.
	[00:51] like gnunet, etc.
	[00:51] i can't say whether it's better than the stuff i work on.
	[00:51] in five years i hope to be able to say that it isn't.
	[00:52] i can say that they appear to not be aware of any of the systems designed in the past 10 years.
	[00:52] except gnutella. they know about gnutella.
	[00:55] PKCS padding options suitable for avoiding
	[00:55] traffic analysis MUST be used.
	[00:55] ha. ha ha.
	[00:55] as if pkcs can stop traffic analysis.
	[00:55] it might stop a two year old. but only if you don't explain to him what he's trying to do.
<Mutiny>	[00:56] heh
<arma>	[00:57] damn. now i'm having doubts again. low-latency anonymity is hard.
	[00:57] there are all these systems that have popped up lately that don't mind allowing correlation between parts of the path --
	[00:58] that is, a packet towards the beginning of the path can be linked to the end of the path
	[00:58] in my world, you're dead at that point. people will just look at both ends and be sure it's you.
	[00:58] except there are these other attacks, like packet counting and timing analysis,
	[00:59] that make it not so relevant if the actual bytes are correlated too. because you're already dead if they can see both sides.
	[00:59] and if they can't see both sides, then you win, right? because they don't know where you're going to.
	[00:59] it's only in the grey area in between, where you assume an adaptive adversary who can compromise new nodes.
	[00:59] (and intelligently choose which to compromise)
	[01:00] and i think in that situation, 6/4 dies quite quickly.
	[01:00] but then, most things die quite quickly.
<Mutiny>	[01:00] what doesn't die quite quickly?
<arma>	[01:00] cascade-based systems seem more robust. eg, web mixes / jap.
	[01:00] but it's not the fact that it's a cascade topology that provides the protection -
	[01:01] it's the fact that it's synchronous.
	[01:01] that is, packets from many connections arrive, get batched and mixed, and passed on.
	[01:01] since it's a cascade, it's possible to get speed and synchronicity together.
	[01:01] with more related topologies, like onion routing or 6/4, it's quite hard. probably not worth it.
	[01:02] what i can say for sure about onion routing is that the best avenue for attack is to guess the two endpoints (guess me, and guess the website i'm going to), and go snoop the two links and verify.
	[01:03] whereas with 6/4 the best avenue for attack is to watch me, and when a request comes out of me that didn't go into me, you read the request, and know the server i'm going to. (this assumes many nodes around me are bad. but hey, it's hard for me to know either way, when random nodes show up and ask to be my neighbors.)
	[01:04] actually, i take that back. who knows if that's the best avenue for attack. but it seems like a fine one.
	[01:07] actually.. this thing is different from gnunet, because the transactions are streams of packets.
<blanu>	[01:07] I have no use for deniability. As far as I'm concerned the useful thing in anonymity is making it to figure out the IP of the server. Hence monitoring of endpoints means you've already lost. Unless you have some hypothetical attacker which can monitor lots of random endpoints easily and just wait until it finds a match. I don't know of such an attacker yet, but it's something to consider.
<arma>	[01:07] their cover traffic scheme cannot possibly work. i would have to pass back all the packets that i get, to all the people i'm connected to, all the time. otherwise people know who it's going to or that it is going to me.
	[01:08] blanu: that attacker you describe totally beats onion routing. we've accepted that. but against a weaker adversary we're quite strong.
	[01:09] mutiny: ok. i can say with increasing certainty that 6/4 is bullshit.
<blanu>	[01:09] Yeah onion routing is the only useful anonymity scheme I know of.
<arma>	[01:09] blanu: mixminion is of no use to you?
	[01:10] blanu: you should learn about web mixes then too.
<blanu>	[01:10] I forget what mixminion is all about. It's basically mixmaster, yes?
<arma>	[01:10] basically yes.
	[01:11] except done right, and also supporting recipient anonymity
<blanu>	[01:11] Is it multi-hop?
<arma>	[01:11] yes
<blanu>	[01:11] So what is the basic difference between mixmion and onion routing?
<arma>	[01:11] it's really very much like onion routing, but since the messages are email, they can go slowly, and mix better.
	[01:12] also, we're in better shape with mixminion, since messages aren't streams. so you don't necessarily get to say "well gosh, 467 packets went that way, and 467 packets arrived over here"
	[01:13] mutiny: ok. i think i have a handle on 6/4 now. here's how you should compare the anonymity offered.
	[01:13] imagine the adversary owns c of the n nodes in the network.
<blanu>	[01:13] Oh right, that's what I was thinking. Mixminion is as far as I recall slower, more secure onion routing. So that's great. I'm more interested in the low latency stuff, but there is definitely a place for the slower service.
<arma>	[01:14] in onion routing, he must own both the first node and the last node. so the chance of that is (c/n)^2
	[01:14] in 6/4, he must own the first node. the chance of that is (c/n). nuff said.
	[01:15] mutiny: put another way, 6/4 users would get equivalent anonymity if they all picked a random open proxy on the internet and used it. maybe even better anonymity.
	[01:16] blanu: right. everybody keeps saying that. nobody wants mixminion, everybody wants tor. we're working on that. :)
<blanu>	[01:19] Well I think people put too much emphasis on low latency. Like with Freenet when we did fproxy then the web browser interface became the trendy way to access files. That's a *terrible* way to access file on Freenet. A Napster-like select-and-forget interface makes much more sense.
	[01:22] Hm... I should think more about this point I just brought up. I'm not sure why I'm stuck on using tor instead of mixminion in my projects. I bet I could put something quite functional together with a message based system and there's even source code!
	[01:22] I will consider that.
<arma>	[01:25] ok. not to discourage you, but:
	[01:25] it's a shame that we can't actually provide the anonymity we'd like, even in a high-latency system like mixminion. the problem is that various activities have different usage patterns, and it's probably easy to distinguish them.
	[01:25] so while you *think* you're getting lots of protection by using mixminion when zooko's project is also using mixminion,
	[01:25] you're probably only mixing with your own users.
	[01:26] (assuming a strong adversary, that is.)
<blanu>	[01:26] Yeah mixminion doesn't actually add anything for me, except source code. ;-)
<arma>	[01:27] which admittedly is a lot.
	[01:29] that's why when len and bram were trying to decide between mixminion and tor for codecon, i withdrew tor
	[01:29] not having source code is lame.
	[01:31] well, maybe more precisely that is 'brandon not having your source code is lame'
<blanu>	[01:31] Even if traffic analysis was foiled as much as is reasonable, if the attacker can do taps then he can build up a list of all IPs in the network. As churn will inevitably occur, he can pick out the stable nodes and then he can go get a search warrant for each stable node. So even if the mixer is the awesomest ever, it's not as if you're really all that safe.
	[01:31] Yes, give me the source!!
	[01:31] Of course it doesn't help much if I can't distribute it.
	[01:31] In fact that would just be cruel.
<arma>	[01:32] actually, in theory not enough of the mixes will be in the same jurisdiction for warrants to be of any use.
	[01:32] you really mean scientology there, i think.
	[01:32] and the hope is that we can have a diverse enough set of nodes that we can resist even threats of kneecapping, etc.
	[01:33] i mean, mixminion will clearly be a more robust anonymity system against strong adversaries
	[01:33] i'm too much at the mercy of kind people with lots of bandwidth, for tor.
	[01:33] octal offered to run a lot of the backbone nodes, when the code comes out.
	[01:33] which is great, but i imagine octal doesn't stand up to kneecapping threats on my behalf. i don't blame him.
<blanu>	[01:35] Yeah that whole bandwidth thing is a pain. They should just build onion routing into TCP routers.
<arma>	[01:35] still doesn't solve the bandwidth problem.
<blanu>	[01:36] Well someone always has to provide the bandwidth. The problematic part is that YOU have to acquire it.
<arma>	[01:37] huh?
<blanu>	[01:38] I'm just saying that if onion routing was widespread then getting people to set up onion routers would no longer be on your shoulders. Which I guess is tautological.

<arma>	[01:38] ah. yep.
<blanu>	[01:40] So how stable is mixminion?
<arma>	[01:42] meaning does it crash much? it does not crash much.
	[01:42] meaning will 0.0.5 break backward compatibility with 0.0.4? quite possibly.
	[01:43] the basic api should stay about the same, though.
<blanu>	[01:43] Ugh, API. Can't I talk to it over a socket or something?
<arma>	[01:44] you could. but then you'd get stuff in mixminion format.
	[01:45] you might prefer talking to it with system() or the like.
<blanu>	[01:45] Argh! Oh well. Maybe IIP or JAP will work out.
<arma>	[01:45] what do you want to say to it?
	[01:45] iip? eek.
<blanu>	[01:45] Oh you know send this message to this guy. Or give me some messages.
	[01:45] What's wrong with IIP?
<arma>	[01:46] what are you written in?
<blanu>	[01:46] Java
<arma>	[01:46] like 6/4, last i checked the iip protocol was inferior to tor.
	[01:46] a lot of it (like 6/4) was that it was quite unspecified.
<blanu>	[01:47] Yes tor would clearly be the best choice if I could use it, but currently the only thing I've found which I can use is Jap. The IIP folks said they'd have SOCKS in 3 months so I'll check back with them then.
<arma>	[01:48] so one possibly api for mixminion is that you can queue a message, eg by system or something like that, and then it can deliver messages to an mbox like thing, eg a pipe.
<blanu>	[01:48] mbox would be great. I have very nice mbox code.
<arma>	[01:48] mixminion already supports mbox
	[01:49] next time you and nick are both online, i should hook you two together. it's quite possible there's an easier interface for sending.
<blanu>	[01:49] Oh awesome. But how can I get it to send stuff as well?
	[01:49] Ah, okay.
<arma>	[01:49] well, you can just invoke it, and it'll send it.
<blanu>	[01:49] "invoke"?
<arma>	[01:49] run it. it's a process.
<blanu>	[01:50] Ah, no that's not acceptable.
<arma>	[01:50] mixminion --send arma@mit.edu < message
<blanu>	[01:50] It's pretty much got to be a socket.
<arma>	[01:50] but mbox is ok?
	[01:51] anyway, should hook you up with nick
	[01:51] i pay more attention to tor than to minion these days
<blanu>	[01:51] Yeah mbox is great. That's better than a socket even. Heck if I could *put* messages in an mbox and then mixminion would deliver and delete them, that would be the best.
<arma>	[01:51] (3 months?! it's just fucking socks. like 10 lines of code.)
<blanu>	[01:52] Yeah I think they're busy with more exciting stuff.
<arma>	[01:52] yes, i think there's a directory you can just dump your messages.
<blanu>	[01:52] But is this like some crazy message format or normal mboxish format?
<arma>	[01:53] might be we could add another pool, to handle that.
	[01:53] obviously the main pool is a crazy message format, because it's nested-encrypted.
	[01:53] but we could have another pool of stuff that wants to get converted into crazy message format
	[01:54] i mean, maybe. you'll have to talk to nick. :)
<blanu>	[01:54] Yeah I guess you can't use normal mbox because the To line would have to be some crazy thing where I can specify a chain. Unless there's some preselected mix I use, then I could just specify the final destination.
<arma>	[01:54] i wish the iip folk would put a bit of effort into documenting their protocol. that way i could know how it's broken and feel more justified writing them off.
<blanu>	[01:55] Is Nick ever online? I never see him on here.
<arma>	[01:55] he's rarely online. not ever here. only on #remops
<blanu>	[01:55] Ah, I see.
<arma>	[01:55] as far as chain goes, most people should just be able to use the randomly selected one.
	[01:56] particularly as chains should be selected based on uptime data. it should all be automated.
<blanu>	[01:56] So in that case a normal mbox should be just fine. That would be a really sweet interface.
	[01:57] Well this is exciting but I'm off to bed.
<arma>	[01:58] <manager>i'm confident that we can include that feature.</>
	[01:58] sleep well. me too.