[Cryptography] Implementations, attacks on DHTs, Mix Nets?
For some research on communications privacy I'm doing at the moment, I'm interested in learning about the state of the art of DHT systems and mix network systems. I'd like to know both which systems are currently considered state of the art and what the state of the art is on attacks against such systems. Anyone care to shed some light? Pointers to literature are especially welcome, but anything that is just in the folklore is also clearly of use... Perry -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] Traffic Analysis (was Re: PRISM PROOF Email)
On Fri, 23 Aug 2013 09:38:21 -0700 Carl Ellison c...@acm.org wrote: Meanwhile PRISM was more about metadata than content, right? How are we going to prevent traffic analysis worldwide? The best technology for that is mix networks. At one point, early in the cypherpunks era, mix networks were something of an expensive idea. Now, however, everyone in sight is connected 24x7 to the internet. Similarly, at one point, bandwidthwas scarce, but now, most traffic is video, and even if instant messages and email equivalents took many hops through the network, the bandwidth used (except for mobiles, which need not be interior mix nodes per se) is negligible. Perry -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] Thoughts about keys
[Disclaimer: very little in this seems deeply new, I'm just mixing it up in a slightly different way. The fairly simple idea I'm about to discuss has germs in things like SPKI, Certificate Transparency, the Perspectives project, SSH, and indeed dozens of other things. I think I even suggested a version of this exact idea several times in the past, and others may have as well. I'm not going to pretend to make claims of real originality here, I'm more interested in thinking about how to get such things quite widely deployed, though it would be cool to hear about prior art just in case I decide to publish a tech report.] One element required to get essentially all messaging on the Internet end to end encrypted is a good way to find out what people's keys are. If I meet someone at a reception at a security conference, they might scrawl their email address (al...@example.org) for me on a cocktail napkin. I'd like to be able to then write to them, say to discuss their exciting new work on evading censorship of mass releases of stolen government documents using genetically engineered fungal spores to disseminate the information in the atmosphere worldwide. However, in our new everything is always encrypted world, I'll be needing their encryption key, and no one can remember something as long as that. So, how do I translate al...@example.org into a key? Now, the PGP web-of-trust model, which I think is broken, would have said check a key server, see if there's a reasonable trust path between you and Alice. I have an alternative suggestion. Say that we have a bunch of (only vaguely) trustworthy organizations out in the world. (They can use crypto based log protocols of various kinds to make sure you don't _really_ need to trust them, but for the moment that part doesn't matter.) Say that Alice, at some point in the past, sent an email message, signed in her own key, to such an organization's key server, saying in effect this is al...@example.org's key. At intervals, the trustworthy organization (and others like it) can send out email messages to Alice, encrypted in said key, saying Hi there! Please reply with a message containing this magic cookie, encrypted in our key, signed in yours. If a third party needing the key for al...@example.org queries the vaguely trusted server, it will then give them information like For the past six years, we've been sending al...@example.org emails every couple of weeks asking her to reply to demonstrate she controls a particular public key, and she always has -- new keys have always been signed in the old one, too. Here's a log, including various sorts of widely witnessed events and hash chains so that if we were lying about this we had to be planning to lie about it for a very long time. Now of course, in the real world, who wants to go through the effort of hand replying to query messages to establish a key over time? Instead, Alice has some actually trusted software running on her computer at home. She can either leave it to automatically do IMAP queries against her mailbox (which could even be GMail or what have you) and reply on her behalf, or it could ask her to unlock her key while she's at home in the morning having her coffee. However, I think the former is actually preferable. We'd rather have an imperfect system that is effortless to use but can be bypassed by physically breaking in to someone's home. (After all if you did that you probably can bug Alice's hardware anyway.) Alice probably also needs to make sure someone isn't spoofing her replies by accessing her IMAP box and replying for her (using a key known to the attacker but presumably not to Alice) and then deleting the query, but the mere absence of periodic pings from the trusted party may be enough to create suspicion, as might doing one's own queries against the trusted parties and noticing that the key isn't your own. Presumably, of course, there should be a bunch of such servers out there -- not so many that the traffic becomes overwhelming, but not so few that it is particularly feasible to take the system off the air. (One can speculate about distributed versions of such systems as well -- that's not today's topic.) So, this system has a bunch of advantages: 1) It doesn't require that someone associated with administrators of the domain name you're using for email has to cooperate with deploying your key distribution solution. Alice doesn't need her managers to agree to let her use the system -- her organization doesn't even need to know she's turned it on. Yet, it also doesn't allow just anyone to claim to be al...@example.org -- to put in a key, you have to show you can receive and reply to emails sent to the mailbox. 2) You know that, if anyone is impersonating Alice, they had to have been planning it for a while. In general, this is probably good enough for a very large number of purposes, and much better than a perfect system that no one ever uses. You can always trade a key hash
Re: [Cryptography] PRISM PROOF Email
On 08/22/2013 02:36 AM, Phillip Hallam-Baker wrote: Thanks to Snowden we now have a new term of art 'Prism-Proof', i.e. a security scheme that is proof against state interception. Having had an attack by the Iranians, I am not just worried about US interception. Chinese and Russian intercepts should also be a concern. We have two end to end security solutions yet Snowden used neither. If PGP and S/MIME are too hard to use for the likes of Snowden, they are too hard to use. The problem Snowden faced was that even if he could grok PGP, the people sending him emails probably couldn't. Observation: Silent Circle and Lavabit both ran encrypted email services. Lavabit shut down a few days ago rather than become complicit in crimes against the American People. I would say that's about as close as you can skate to We're facing a court order that we're not allowed to tell you about. Maybe even closer; we'll be forbidden to know whether anyone prosecutes them for violating the presumed gag order. Silent Circle shut down soon after, saying, We always knew the USG would come after us. Which perhaps a little less clearly indicates a court oder they can't talk about, but that's certainly one interpretation. Egypt, Oman, and India refused to allow Blackberry to operate with their end-to-end encrypted devices. In cases where Blackberry is now allowed to operate in those jurisdictions it is not at all clear that they are not doing so using compromised devices whose keys shared with those governments. Chinese military teams spent so much effort hacking at gmail and facebook accounts, in order to ferret out dissidents, that Google was eventually forced to cease doing business in China, and now gmail and facebook both have some end-to-end encrypted clients. My point I guess is that we have some evidence that Governments across the world are directly hostile to email privacy. Therefore any centralized server, CA, or company providing same may expect persecution, prosecution or subversion depending on the jurisdiction. And it can never, ever, not in a billion years, be clear to users which if any of those centralized servers or companies are trustworthy. Google now implements some end-to-end encryption for gmail but we also know that google is among those specifically mentioned as providing metadata access to the US government. The exact details of Blackberry's keys in Oman, UAE, India are now subject to largely unknown deals and settlements. Therefore, IMO, any possible solution to email privacy, if it is to be trusted at all, must be pure P2P with no centralized points of failure/control and no specialized routers etc. And it can have no built-in gateways to SMTP. Sure, someone will set one up, but there simply cannot be any dependence on SMTP or the whole thing is borked before it begins. It is time to simply walk away from that flaming wreckage and consider how to do email properly. S/Mime and PGP email-body encryption both fail to protect from traffic analysis because of underlying dependence on SMTP. Onion routing fails to protect due to timing attacks. So I say you must design your easy-to-use client completely replacing the protocol layer. No additional effort to install because this is the only protocol it handles. The traditional approach to making a system intercept proof is to eliminate the intermediaries. PGP attempts to eliminate the CA but it has the unfortunate effect on scalability. Due to the Moore bound on a minimum diameter graph, it is only possible to have large graphs with a small diameter if you have nodes of high degree. If every PGP key signer signs ten other people then we have to trust key chains of 6 steps to support even a million users and nine to support a global solution of a billion users. My solution is to combine my 'Omnibroker' proposal currently an internet draft and Ben Laurie's Certificate Transparency concept. I would start from a design in which mail is a global distributed database, with globs that can be decrypted by use of one or more of each user's set of keys, and all globs have expiry dates after which they cease to exist. Routing becomes a nonissue because routing, like old USENET, is global. Except instead of timestamp/ message ID's, we just use dates (because timestamps are too precise) and message hashes (because message IDs contain too much originating information). No certificate, no broker, no routing information unless the node that first hears about the new glob has been compromised. Each message (decrypted glob) optionally contains one or more replyable addresses (public keys). If we need more 'scalability' we could set up channels discriminated by some nine bit or so substring of the message hash, and require senders to solve hashes until they get a hash with the right nine bits to put it in the desired channel. Still no routing information as such. Now Eve can tell what channel/s a user is listening to, but the user has
[Cryptography] Hey! You! Get off of the cloud!
[Second in a series of several posts about what is needed to make all Internet messaging go encrypted. Again, if the contents of this post sound unoriginal, that's because it isn't original thinking. It does strike me as part of a larger puzzle, however, and some people may not be familiar with all the arguments.] I have a lot of friends who work in offices where the sysadmins are, somewhat reasonably, hostile to the idea of their users installing or configuring applications on their company machines. Users in such offices have gotten quite used to using their browsers to access web mail and chat systems -- de facto GMail and GTalk -- as well as things like facebook messaging etc. This, and one's smart phone, is many people's interface to the world outside work. Companies still let you do https: to Google even if they won't let you install a chat client locally, so that's what everyone does. (Well, lots of people do http: but never mind that). In any new world where everyone's messages are end to end secure and probably transiting mix networks to prevent traffic analysis, such users are going to have to be accommodated. That means that their end-to-end encryption endpoint is going to have to be on the web server they're talking to. Keys are going to have to be on that machine, because you're not going to be able to install software to use them on your work machine, and even if you could do everything in javascript, you probably have relatively limited trust for the local box and certainly not enough to leave long lived high entropy keys on it. Now, it is relatively easy for such a user to check that the cert for their web mail provider doesn't come from a Bluecoat box -- no one does, but it is kind of feasible. It is relatively difficult for someone to bug your local machine -- hardly impossible, but not something that is supposed to happen without the local system administrator doing something to your machine or a remote bad guy using malware. On the other hand, a company that's hosting your email and chats almost certainly will hand over encryption keys you store with them if the government forces them to, and it is absolutely impossible to know if this has happened. You just have to assume it has in your threat model. It strikes me that the only real solution to handle this for people to replace their router (really NAT) boxes on their cable modems with tiny cheap servers that host their email and chats and such. Luckily, the cost of such things has gotten very low -- a Raspberry Pi class machine with a USB thumb drive larger than a GMail quota costs less than a carton of cigarettes or the cheapest monthly Cable TV bill, and such devices will only get cheaper and cheaper in the near term. It is also feasible to make such machines insanely reliable, especially if there's no mechanical disk involved. (I'm of course not the first person by far to make this observation -- the FreedomBox people, among others, have been saying it for several years. The idea is far from original.) Sure, a bad guy can of course break into your apartment, but that's a lot more expensive than simply getting Google or Facebook to hand over all your communications, and hard to do on a vacuum it all basis. With appropriate software and a friendly UI, one's Email, IM, remote file storage and similar needs could be easily managed on such a device with no greater difficulty than one faces in using GMail, GTalk, Dropbox etc. That's just a question of keeping the user interface easy. Note that, however, this is not merely a requirement and stumbling block -- it is also an opportunity. If everyone has such a box at home, they've got a server, and the kinds of protocols they can participate in to enhance their own security can be a lot more sophisticated. Some additional notes: a) Certainly, the security of a home server device is no greater than that of the underlying software -- mass surveillance through malware is possible. However, I presume that even there, doing so _en masse_ is dangerous to an attacker, since it leaves lots of traces. Also, just as attackers have been improving their game, there are methods that defenders can employ to improve security on such devices with time -- malware is not a foregone conclusion forever, and is in some sense a higher quality problem. b) I'm aware that many ISPs prohibit the use of servers on their home customer's networks, but loads of people ignore this. They also used to prohibit (de facto) sharing connections with lots of machines, and the arrival of commercial NAT boxes named routers made that policy fade away as though by magic. I think they mostly don't want to have to re-engineer their networks overnight, but in practice I doubt a device hosting your email and some baby pictures is going to alter traffic patterns enough to cause that anyway. c) Even if people are happy using their smart phone to read their home mail instead of their desktop at work, and could be persuaded
Re: [Cryptography] PRISM PROOF Email
On Sun, 25 Aug 2013 10:37:52 -0700 Ray Dillinger b...@sonic.net wrote: Therefore, IMO, any possible solution to email privacy, if it is to be trusted at all, must be pure P2P with no centralized points of failure/control and no specialized routers etc. Quite agreed. I have a long message in draft that I'll hopefully be sending out later today on this topic. And it can have no built-in gateways to SMTP. Sure, someone will set one up, but there simply cannot be any dependence on SMTP or the whole thing is borked before it begins. It is time to simply walk away from that flaming wreckage and consider how to do email properly. S/Mime and PGP email-body encryption both fail to protect from traffic analysis because of underlying dependence on SMTP. That said, as I shall propose, it is not necessary to get rid of all our email infrastructure. In particular, RFC-2822 remains an entirely viable thing, and I think IMAP based clients can continue to be used, with at most small changes. Onion routing fails to protect due to timing attacks. Mix networks are not onion routing, though. If you're pure peer to peer, traffic analysis is possible. Real mix networks are now quite feasible, however, and unlike the Tor model where one is trying to make real time TCP connections secure, there is no need to be real time for IM and Email -- a delay of a couple of seconds is just fine. So I say you must design your easy-to-use client completely replacing the protocol layer. No additional effort to install because this is the only protocol it handles. I see this as a reasonable observation. As I said, I'll be explaining the rest of my proposal (of which I've put up the first two parts, which are reasonably independent) later. Perry -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] Email and IM are ideal candidates for mix networks
[Third in an ongoing series. Disclaimer yet again: I make few claims of the contents here being specifically original to me. Mix networks and the like have been discussed forever, and I'm sure others have been having similar thoughts to this of late.] The aim of the Tor network (which, it should be noted, is an onion network and not a mix network in the original sense) is to provide people with reasonably responsive end to end untraceable TCP connections. This is a big strength when dealing with going to arbitrary existing web sites and accessing existing services. It is also a bit of a weakness, in that it imposes fairly strict latency limits on what people will (de facto) put up with, and it means that the effective limit on the system is exit node availability. Exit node operators need a strong stomach. However, we can note that the requirements for instant messaging and electronic mail are somewhat distinct. Latency can't be infinite, but several seconds is totally acceptable even for IM, and longer (sometimes much longer) is often just fine for email. End to end virtual streams are not necessary, either, and there is no reason that real mix networks, complete with slicing of traffic to uniform lengths, variable delays, cover traffic, far more hops than Tor can afford, etc., are all quite feasible. Compared to video traffic, IM and Email are quite trivial loads for the network -- this also makes longer mixing paths and cover traffic quite feasible even where they might not have been in the days when the Cypherpunks list was young. There is also no need per se for exit nodes. All participants in a system can be internal nodes, since the system isn't being used for surfing arbitrary web sites etc. Thus, the rare exit node problem is not an issue. So, imagine that we have the situation described by part 1 (some universal system for mapping name@domain type identifiers into keys with reasonable trust) and part 2 (most users having some sort of long lived $40 device attached to their home network to act as a home server.) All the server nodes we postulated in part 2 could easily participate in a mix network for exchanging instant messages and RFC-2822 style bodies. We will presume some end to end encapsulating encryption for these messages, and the use of standard mix network techniques for moving the (often sliced up) bodies of these objects around the network. The endpoints for communications are typically people's home servers themselves (see part 2), accessed through some sort of clients (see below). Spam might be a terrible, terrible problem in such a network since it could not easily be traced to a sender and thus not easily blocked, but there's an obvious solution to that. I've been using Jabber, Facebook and other services where all or essentially all communications require a bi-directional decision to enable messages for years now, and there is virtually no spam in such systems because of it. So, require such bi-directional friending within our postulated new messaging network -- authentication is handled by the public keys of course. (If you want to contact someone you haven't talked to before, you'll need an introduction or to use SMTP email, which you probably need to keep around to handle your keys as described in part 1 anyway.) We probably don't want any sort of central service running this network that could be easily disrupted, so identifier to IP address information should probably be stored in some big honking DHT, signed in the ID's key. Access to the DHT probably should happen in some privacy preserving way, possibly through the mix network itself or a PIR protocol. It would be unpleasant, and probably the kiss of death to deployment, if everyone had to abandon Mail.app and iMessage and Pidgin and Outlook and all the other user interfaces of the world in order to use this system. Do we need to re-write all the world's user interfaces to handle this? No. There's no real reason that your home server can't present you with a SSL'ed web and SSL'ed IMAP interface to your RFC-2822 messages. You run the box, and it has your keys anyway, so you can likely trust it. Similarly, you can do a Web interface for instant messages, or, if you have an existing Jabber client, you can run the Jabber client protocol over SSL to your home server. Additional notes: There are probably lots of interesting denial of service modalities available in such a network. Figuring out very clever ways to stop them is probably a priority. Note that distinguishing cover traffic from denial of service may get quite interesting indeed. Similar techniques may be useful for voice traffic, but that has interesting latency requirements, and they're hard to fulfill with a mix network that might take arbitrary time. There's been some interesting work by a number of people (including one of my doctoral brothers) on this topic. It probably would require a bunch of experimentation to get it right. On the other hand,
Re: [Cryptography] Email and IM are ideal candidates for mix networks
I think we can agree that the first step is to deploy home servers, and that the first application there would to host communication applications. Just doing that without much other change would already provide protection against the silent spying that goes on in big cloud servers. Initial deployment of anything must provide an immediate reward to the early adopters. You cannot rely on a network effect, and that means you can certainly not request third parties to adopt a new protocol. So better pinch our noses and say that, of course, we will accept SMTP mail. Probably SIP as well, and XMPP. We just need at first to make sure that the home server is easy to deploy and maintain. Then the adopters get the immediate reward, nobody can go through my mail archives without asking me. The various P2P enhancements come next, once there already is a network of home servers. The obvious one is a communication application that beats traffic analysis by embedding its own shuffling or onion routing. I don't think we can run anything like that directly on a phone, it would drain the battery way too quickly. -- Christian Huitema ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Implementations, attacks on DHTs, Mix Nets?
On 08/25/2013 09:12 PM, Perry E. Metzger wrote: For some research on communications privacy I'm doing at the moment, I'm interested in learning about the state of the art of DHT systems and mix network systems. I'd like to know both which systems are Can you rephrase whether you want info about DHT systems that are related to some kind of mix system (e.g. GNUnet), or whether you simply want to know about common DHT systems. If the latter, what kind of attacks are you after? Eclipse? Ralph -- Ralph Holz I8 - Network Architectures and Services Technische Universität München http://www.net.in.tum.de/de/mitarbeiter/holz/ Phone +49.89.289.18043 PGP: A805 D19C E23E 6BBB E0C4 86DC 520E 0C83 69B0 03EF ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Email and IM are ideal candidates for mix networks
On Sun, 25 Aug 2013 16:04:59 -0700 Christian Huitema huit...@huitema.net wrote: I think we can agree that the first step is to deploy home servers, and that the first application there would to host communication applications. Just doing that without much other change would already provide protection against the silent spying that goes on in big cloud servers. Initial deployment of anything must provide an immediate reward to the early adopters. You cannot rely on a network effect, and that means you can certainly not request third parties to adopt a new protocol. So better pinch our noses and say that, of course, we will accept SMTP mail. Probably SIP as well, and XMPP. We just need at first to make sure that the home server is easy to deploy and maintain. Then the adopters get the immediate reward, nobody can go through my mail archives without asking me. I do not disagree, and given a home server, supporting whatever protocols are popular is merely a matter of software. One reason I split that proposal (more to come!) into multiple messages was because I think the issues are somewhat distinct, and home servers would be of use regardless. That said, I personally don't need much of a network effect to make things like secure IM useful to me. I exchange instant messages all day long, but only with about a dozen people for the most part. I don't need the whole world to switch to a new IM system for me to be much happier, just that dozen people. My email network is somewhat wider, but even there, I'd get incremental benefit from a new protocol. The trick is to make it easy to do the old and the new at the same time. Most IMAP and Jabber clients will happily handle multiple accounts, however, so I don't even have to choose if the client access protocol remains the same. The various P2P enhancements come next, once there already is a network of home servers. The obvious one is a communication application that beats traffic analysis by embedding its own shuffling or onion routing. I don't think we can run anything like that directly on a phone, it would drain the battery way too quickly. It might not if the total traffic was quite low (even if my IM traffic in bytes or packets was 10x larger because of a mix network participation, it would still be tiny compared to even a couple of phone calls a day). Still, I tend to agree that home nodes make better mix participants. -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Implementations, attacks on DHTs, Mix Nets?
On Sun, 25 Aug 2013 21:33:42 +0200 Ralph Holz ralph-cryptometz...@ralphholz.de wrote: On 08/25/2013 09:12 PM, Perry E. Metzger wrote: For some research on communications privacy I'm doing at the moment, I'm interested in learning about the state of the art of DHT systems and mix network systems. I'd like to know both which systems are Can you rephrase whether you want info about DHT systems that are related to some kind of mix system (e.g. GNUnet), or whether you simply want to know about common DHT systems. If the latter, what kind of attacks are you after? Eclipse? My knowledge of the field is pretty spotty in general as I've never paid much attention up until now -- mostly I know about how people have built DHTs in non-hostile environments. I'm close enough to starting from scratch that I don't know yet what I don't know. Perry -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Implementations, attacks on DHTs, Mix Nets?
My knowledge of the field is pretty spotty in general as I've never paid much attention up until now -- mostly I know about how people have built DHTs in non-hostile environments. I'm close enough to starting from scratch that I don't know yet what I don't know. I studied such systems intensely, and designed some (http://en.wikipedia.org/wiki/Peer_Name_Resolution_Protocol). Using a distributed hash table securely is really hard. The basic idea of DHT is that information is spread on the network based on matches between the hash of a resource identifier and the hash of a node identifier. All nodes are effectively relying on every other node. In an open network, that is pretty much equivalent to relying on the goodness of strangers. You can be sure that if our buddies at the NSA set up to watch the content of a DHT, they will succeed. -- Christian Huitema ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Implementations, attacks on DHTs, Mix Nets?
On Sun, 25 Aug 2013 16:42:57 -0700 Christian Huitema huit...@huitema.net wrote: I studied such systems intensely, and designed some (http://en.wikipedia.org/wiki/Peer_Name_Resolution_Protocol). Using a distributed hash table securely is really hard. The basic idea of DHT is that information is spread on the network based on matches between the hash of a resource identifier and the hash of a node identifier. All nodes are effectively relying on every other node. In an open network, that is pretty much equivalent to relying on the goodness of strangers. You can be sure that if our buddies at the NSA set up to watch the content of a DHT, they will succeed. That is not my worry. Signing the data posted to the DHT can prevent spoofing, querying it over a mix network or using a PIR protocol can prevent eavesdropping. I'm more worried about various sorts of denial of service attacks, or service being shut down by inadvertent behavior. Perry -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Implementations, attacks on DHTs, Mix Nets?
That is not my worry. Signing the data posted to the DHT can prevent spoofing, querying it over a mix network or using a PIR protocol can prevent eavesdropping. I'm more worried about various sorts of denial of service attacks, or service being shut down by inadvertent behavior. Of course the data can be signed, encrypted, etc. But the rule of the game is that the adversary can manufacture as many peers as they want -- something known as the Sybil attack. They can then perform various forms of denial. For example, the connectivity of the DHT generally relies on connectivity between nodes of similar indices. The attackers can research hashes that fall very near the hash of the target node, add the corresponding nodes in the DHT, and effectively place themselves in the path of DHT traffic meant for the target node. This enables passive traffic analysis, and active denial of service. Another potential attack is to get node indices close to that of a popular resource, effectively becoming the repository of record for that resource. Again, that enables passive traffic analysis, e.g. finding who accesses a specific resource, and also active denial of service attacks. If the attackers can manufacture enough virtual nodes, they obtain control of the network. They can use that passively for global traffic analysis. They can also engineer selective disruption, inject traffic to DOS specific nodes, and other fun games. Bottom line, anonymous DHT are fragile. If we want something robust, we have to forgo the mathematical elegance of the DHT, and adopt a network structure in which nodes only connect to peers that they trust. You could call that networks of friends. That removes the nice O(log N) properties of the DHT, and it becomes hard to guarantee that all queries will converge. But the network becomes much harder to penetrate. The old Freenet had a structure like that. -- Christian Huitema ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Implementations, attacks on DHTs, Mix Nets?
On 2013-08-26 11:04 AM, Christian Huitema wrote: Of course the data can be signed, encrypted, etc. But the rule of the game is that the adversary can manufacture as many peers as they want -- something known as the Sybil attack. They can then perform various forms of denial. We need, and have not designed, a good distributed reputation system, resting on Zooko's triangle and a large global hash tree that provides an unfalsifiable past history of the past conduct of key holders. Such a global hash tree requires, like bitcoin, a solution to the Byzantine Generals Problem - a known hard problem that is nonetheless soluble. A distributed reputation system can also provide things like debt based money that provides an incentive for seeding - for providing storage of interesting content as well as an incentive for upload bandwidth of interesting content. Bittorrent provides an upload bandwidth incentive, but no storage incentive. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Email and IM are ideal candidates for mix networks
On Aug 25, 2013, at 6:28 PM, Perry E. Metzger wrote: [Commenting on just one minor piece] ...Similar techniques may be useful for voice traffic, but that has interesting latency requirements, and they're hard to fulfill with a mix network that might take arbitrary time. There's been some interesting work by a number of people (including one of my doctoral brothers) on this topic. It probably would require a bunch of experimentation to get it right. On the other hand, anything might be better than what we have now for voice traffic, which is essentially zero privacy from the operators of most of the services. There's another problem with voice: People have come to expect services beyond the old point-to-point conversations that the traditional phone network provided. Group conferences are now very much an expected part of on-line voice services. These actually require fairly sophisticated processing of the audio to balance levels, avoid or suppress echoes, and so on. The only implementation techniques available today require a central server with access to cleartext voice streams. Not only does the server need to be trusted to handle the cleartext voice streams, it has to be trusted to do all the authentication - what comes out of the system doesn't usually match what went in from any one endpoint. Multi-way chat has similar, if much simpler, problems. On the rare occasions these problems (or even multi-party video conferencing) get mentioned, someone usually suggests using homomorphic cryptography. Besides being way too expensive to be practical at the moment, it's not even clear to me that it provides a useful kind of security. What kind of authentication model could such a system implement? Without it, what's to prevent a rogue server from inserting its own voice into the conversation? There are probably a couple of nice PhD dissertations in here -- Jerry ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Email and IM are ideal candidates for mix networks
On Aug 25, 2013, at 7:04 PM, Christian Huitema wrote: I think we can agree that the first step is to deploy home servers, and that the first application there would to host communication applications. Just doing that without much other change would already provide protection against the silent spying that goes on in big cloud servers. Initial deployment of anything must provide an immediate reward to the early adopters. You cannot rely on a network effect, and that means you can certainly not request third parties to adopt a new protocol. So better pinch our noses and say that, of course, we will accept SMTP mail. Probably SIP as well, and XMPP. We just need at first to make sure that the home server is easy to deploy and maintain. Then the adopters get the immediate reward, nobody can go through my mail archives without asking me. I agree, and have suggested this as the right next step for a couple of years. (For services like mail, it's the right next step *even without the security considerations*. At one time, everyone who wanted to run use mail ran his own mail server. This was a pain to do, and didn't work well in a world of intermittent network connectivity and small disks. Letting someone else figure out how to keep sendmail working, provide a continuous on-line presence, back up the disks, and so on, was a clear win. Today, however, pretty much everyone (well, at least in the first world; but the problems elsewhere are of an entirely different nature anyway) has a continuous, immensely fast (relative to the demands of mail) internet connection, disk is too cheap to meter, machines run of years with no maintenance, and you can back everything up using readily-available tools to encrypted copies in the cloud, or on friend's system. What's been missing is the ability to configure your local mail server as easily as you set up an email address at Google or Yahoo or at any other provider. But that's a solvable problem. On the flip side, mail systems like gMail or Yahoo mail are complex and difficult to run *exactly because they are immense*. But what are they getting for that size? There are no economies of scale here - in fact, there are clear *dis*economies. Even without the recent uproar over email privacy, at some point, someone was going to come up with a product along the following lines: Buy a cheap, preconfigured box with an absurd amount of space (relative to the huge amounts of space, like 10GB, the current services give you); then sign up for a service that provides your MX record and on-line, encrypted backup space for a small monthly fee. (Presumably free services to do the same would also appear, perhaps from some of the dynamic DNS providers.) What's the value add of one of the giant providers? The various P2P enhancements come next, once there already is a network of home servers. The obvious one is a communication application that beats traffic analysis by embedding its own shuffling or onion routing. A single-purpose appliance - a box that has exactly two open ports on the Internet, one for SMTP and one for IMAP, with management over a physically separate interface, would have a tiny attack surface and could be very secure. The more interfaces you put on the box, the less secure it gets. Maybe you can play games with virtualization - not the kind of virtualization that's used today, with all kinds of hooks for efficient sharing, but virtualization specifically for security, with as little sharing as possible (e.g., completely separate virtual disks; so what if you duplicate stuff, programs and such are tiny relative to disk sizes today). *The* biggest headache is HTTP support. Even the simplest modern HTTP server is so complex you can never be reasonably sure it's secure (though, granted, it's simpler than a browser!) You'd want to stay simple and primitive. Probably the biggest threat to such a device is a rogue update that installs malware. You can try to mitigate that risk by requiring that all updates be signed by multiple independent parties who vet the patch, but there are difficult tradeoffs: Too few checkers, and a rogue patch can get through; too many, and if a severe problem develops, you can't get a patch out quickly. I think the goal to aim for is no patches! Keep the device and its interfaces simple enough that you can get a decent formal proof of correctness, along with a ton of careful review and testing (per Don Knuth's comment somewhere to Be careful of the following code, I've only proved it correct, not tested it) and then *leave it alone*. If you don't think you can do without patches for the whole thing, maybe you can have a non-patched security kernel, with patches only to portions that cannot break your security guarantees. (Yes, this is also a hard problem.) An important element of a secure design is some sort of obliviousness. A mail server doesn't, on its own, need to
Re: [Cryptography] Traffic Analysis (was Re: PRISM PROOF Email)
There has to be a layered approach. Traffic analysis is probably going to demand steganography and that is almost by definition outside standards work. The part of Prism that I consider to be blatantly unconstitutional is that they keep all the emails so that they can search them years later should the need arise. Strikes me that is the type of sophistry that John Yoo used when he wrote those memos claiming that torture isn't torture. There will be a reckoning in the end. Takes about twenty to thirty years before the point is reached that nobody in the establishment has a reason to protect the war criminals of years past. I have a little theory about the reason the CIA engineered coups were so successful from 53 to 73 and then suddenly stopped working. Seems to me that the CIA would have been nuts to try operation Ajax without some very powerful intel like being able to break the Persian codes. CIa stopped being able to mount those exercises after electronic ciphers were introduced. Given how the NSA used their powers last time round to topple democracies and install dictators I don't think they deserve a second chance. On Sun, Aug 25, 2013 at 3:34 PM, Perry E. Metzger pe...@piermont.comwrote: On Fri, 23 Aug 2013 09:38:21 -0700 Carl Ellison c...@acm.org wrote: Meanwhile PRISM was more about metadata than content, right? How are we going to prevent traffic analysis worldwide? The best technology for that is mix networks. At one point, early in the cypherpunks era, mix networks were something of an expensive idea. Now, however, everyone in sight is connected 24x7 to the internet. Similarly, at one point, bandwidthwas scarce, but now, most traffic is video, and even if instant messages and email equivalents took many hops through the network, the bandwidth used (except for mobiles, which need not be interior mix nodes per se) is negligible. Perry -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography -- Website: http://hallambaker.com/ ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
