Re: [Cryptography] Email and IM are ideal candidates for mix networks
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 In message fdd34a58-6ce6-497a-a177-b940d36d0...@lrw.com, Jerry Leichter leich...@lrw.com writes On the flip side, mail systems like gMail or Yahoo mail are complex and difficult to run *exactly because they are immense*. The mail systems part is really rather simple... and pretty much looks after itself. That's not where all the employees work. But what are they getting for that size? There are no economies of scale here - in fact, there are clear *dis*economies. ... the economy of scale is in identifying and routing spam of various kinds. Some can be detected a priori -- the majority of the detection relies on feedback from users (the chances are that someone else got the bad mail before you did, so it can be arranged that you are not bothered) 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.) Just what the world needs, more free email sending provision! sigh What's the value add of one of the giant providers? If you run your own emails system then you'll rapidly find out what 2013's spam / malware problem looks like. Just as success in crypto deployment isn't about algorithms or file formats, success in mail handling isn't about MX records and MTAs. - -- richard Richard Clayton They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. Benjamin Franklin -BEGIN PGP SIGNATURE- Version: PGPsdk version 1.7.1 iQA/AwUBUhrsBeINNVchEYfiEQKkQQCcDXtNGi30Zp8yhazPbQOvqEmu6icAnjqe y5QvKffZakNHejWz1tu4PJ4d =oGIg -END PGP SIGNATURE- ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Traffic Analysis (was Re: PRISM PROOF Email)
On Sun, 25 Aug 2013 23:40:35 -0400 Phillip Hallam-Baker hal...@gmail.com wrote: There has to be a layered approach. Traffic analysis is probably going to demand steganography and that is almost by definition outside standards work. I'm unaware of anyone who has seriously proposed steganography for that purpose -- I'm not even sure it would have the desired effect. Recall that the problem in blocking traffic analysis is to conceal that two endpoints are communicating. Mix networks are, however, a well technique. Onion networks, which are related, are widely deployed right now in the form of Tor, and work well. I see little reason to believe mix networks would not also work well for instant messages and email (see my other thread, begun yesterday.) I'm not particularly interested in standards work per se. If something becomes successful, that is probably the time to consider standardization if warranted. Perry -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] Formal Verification (was Re: Email and IM are ideal candidates for mix networks)
On Sun, 25 Aug 2013 23:32:32 -0400 Jerry Leichter leich...@lrw.com wrote: 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*. I'd like to point out that this is no longer a pipe dream. The formal verification of seL4, CompCert and other substantial pieces of code in recent years shows the technology has improved a lot. Quark (the web browser verified by the use of a shim) has shown one can get enormous leverage by formally verifying only tiny fractions of an overall system comprising millions of lines of code, which is an especially interesting technique in the context of existing large code bases. Formal verification is not a panacea. One has to know what to verify, for example, and if you verify the wrong properties, you've gained little. However, unlike current methods, if you discover you have failed to verify a needed property, adding a theorem to your development fixes that hole _completely_ and _forever_. (Yes, you also need a verified toolchain, but given things like CompCert, that is now doable.) I'm something of a recent arrival to the world that developed the most widely used tools for formal verification (like Coq), and so I'm in a better position than most to explain how to learn about them. I would be happy to produce an extended post on how to learn about what is out there for people who are interested. Warning: although in the long term there is no reason the tools cannot be made very user friendly and easy to use, right now that is not the case. This is not inherently so, it is just a feature of the development history of the tools. Error messages tend to be pretty poor, as is documentation, and the learning curve is steep. However, in the long run, I'll state very directly I think the recent advances in the state of the art in proof assistants are the most significant new development in software quality in decades. The user unfriendliness could be fixed by a new generation of users and developers who started further away from the problem. Perry -- Perry E. Metzgerpe...@piermont.com ___ 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 Mon, 26 Aug 2013 06:47:49 +0100 Richard Clayton rich...@highwayman.com wrote: If you run your own emails system then you'll rapidly find out what 2013's spam / malware problem looks like. This is slightly off topic, but... As it happens, I run my own email system (and run email for a few other people at the same time.) My email address is also very very widely published, so I'm on virtually every spam list in existence. Thus, I'm reasonably qualified to speak on this. Things work pretty well, and I spend essentially no time on required maintenance. Malware is not a problem. Viruses by email haven't been prevalent for a while anyway, but because I block all windows executable formats in attachments at the SMTP server, back when they were common, none of that traffic got through. 100% coverage. For spam, I use a couple of reliable RBLs, a few simple block rules, and spamassassin for postprocessing. I get almost everything. About ten spams a day get through to me, but on the other hand, I get hundreds of legitimate messages on an average day and my address is _very_ widely published. I think that a zero maintenance box that handles this is probably doable. One could also set up a peer to peer blacklisting/spam reporting and detection system that would reduce the problem further without individual work. All that said, there is a good reason that I proposed that in the long run, whitelist only systems like Jabber and Facebook messaging are a better model. -- 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 18:04:13 -0700 Christian Huitema huit...@huitema.net wrote: Bottom line, anonymous DHT are fragile. Though it appears that Tor uses them for its hidden service directory. How does it do that robustly (or does it do it robustly)? How do other users of DHTs handle attacks in practice (or is it just that no one has tried attacking them enough?) My back of the envelope says that there's little enough data needed in the distributed data store I want that 1000x replication would not be a serious problem. I presume that is not sufficient to make Sybil attacks moot, given the size of modern botnets? Perry -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] Good private email
I don't think you need all that much to get good secure private email. You need a client that can make PEM pretty seamless; reduce it to a button that says encrypt when possible. You need the client to be able to generate a keypair, upload the public half, and pull down (seamlessly) recipient public keys. You need a server to store and return those keys. You need an installed base to kickstart the network effect. Who has that? Apple certainly; Microsoft could; Google perhaps (although not reading email is against their business model). Maybe even the FB API. It's not perfect -- seems to me the biggest weakness is (a) the client could double-encrypt for TLA's to read, or (b) it could give you the wrong key so your mail only goes to the bad guy -- but it's a hell of a lot better than we have now and I'd say it's more than good enough. Thoughts? ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Implementations, attacks on DHTs, Mix Nets?
Hi, 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. OK, so I'll just add to what's been written so far. * Most DHTs are indeed intended for a non-hostile environment and allow users to freely place information in the DHT. This means that data items can be easily eclipsed from the network by abusing the DHT's principle of storing an item on the node with the ID that is closest to the item's own ID. Most concepts support replica. * The only DHT type that really has seen wide deployment seems to be Kademlia, most notably in aMule/eMule and some bot networks. Steiner et al. showed by example that Eclipse attacks against data items are easy (Conducting and optimizing Eclipse attacks in the Kad P2P network). * The aMule developers reacted to that attack by restricting routing tables. Kohen/Leske et al. showed that this can be easily circumvented by introducing chains of attackers that cooperate in a particular fashion to redirect queries and let Kad run into a timeout. * We have been active in Kad research for a little while, too. We found that while Eclipse attacks against data items are easy, they are much much harder against active nodes. I.e. Kad is designed to keep long-running nodes as long in the routing tables as possible, and to spread this knowledge widely in the network. This makes it very hard for an attacker to reroute traffic intended for a victim. However, given a very strong attacker (1000s of nodes), this should become possible again. It is one of the disruptive DoS methods. * The most interesting work that I know of is GNUnet: www.gnunet.org. They employ a DHT called R5N that combines recursive Kad-style routing with an initial random walk to evade the above attacker. GNUnet's problem is that there are not enough developers to get the network to a reasonable size, but the underlying technology is interesting. GNUnet also has a SDSI/SPKI-style DNS replacement called GADS. Christian Grothoff is the main developer and also at TUM (that's how I know him) - he recently gave a talk on PRISM and GNUnet: https://www.gnunet.org/internetistschuld There is a host of older literature, too - P2P research, however, has become a cold topic. Although I expect that it will see a revival in the face of surveillance. 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
Hi, On 26.08.2013 00:28, Perry E. Metzger wrote: 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. Hashing it out in public: Common failure modes of DHT-based anonymity schemes by Andrew Tran, Nicholas Hopper, and Yongdae Kim. In the Proceedings of the Workshop on Privacy in the Electronic Society (WPES 2009), Chicago, IL, USA, November 2009. http://freehaven.net/anonbib/#wpes09-dht-attack We examine peer-to-peer anonymous communication systems that use Distributed Hash Table algorithms for relay selection. We show that common design flaws in these schemes lead to highly effective attacks against the anonymity provided by the schemes. These at- tacks stem from attacks on DHT routing, and are not mitigated by the well-known DHT security mechanisms due to a fundamental mismatch between the security requirements of DHT routing’s put- get functionality and anonymous routing’s relay selection function- ality. [...] CONCLUSION The anonymity literature, including all of the schemes investi- gated here, is replete with claims that a peer-to-peer architecture is necessary in order to construct a scheme that will work at Internet scale. Distributed Hash Tables offer a scalable architecture for or- ganizing and finding peers, and thus appear to be an obvious choice of peer-to-peer architecture. However, as we have shown there is not a clear bijection between the security and robustness require- ments of a DHT’s put-get interface and an anonymity scheme’s re- lay selection mechanism. This leads to severe vulnerabilities in the existing schemes based on DHTs, limiting the deployability of such schemes. The critical question for future work in this line of research is whether a “DHT-like” algorithm can be designed to meet the specific requirements – in terms of privacy, availability, and correctness – of an anonymity scheme. ___ 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 26, 2013, at 10:14 AM, Perry E. Metzger pe...@piermont.com wrote: On Mon, 26 Aug 2013 06:47:49 +0100 Richard Clayton rich...@highwayman.com wrote: If you run your own emails system then you'll rapidly find out what 2013's spam / malware problem looks like. This is slightly off topic, but... As it happens, I run my own email system (and run email for a few other people at the same time.) My email address is also very very widely published, so I'm on virtually every spam list in existence. Thus, I'm reasonably qualified to speak on this. Things work pretty well, and I spend essentially no time on required maintenance This is my experience as well. My primary email address is actually served by a small ISP whose spam filter I don't trust - too many false positives. Actually, I have yet to see a spam filter I *do* trust. So I've configured my account at the ISP to mark what it thinks is spam in the subject line but then pass it through. My primary spam filtering is from Mail.app - but I manually check everything in my Junk mailbox before tossing it. I see every message it thinks is spam, everything my ISP thinks is spam, and everything they think is ham as well. (Mail.app has no idea what the ISP's Spam marking means, but presumably adds it as an element in its own decisions.) Like Perry's, my email address has been the same for a while (25 years or so, in my case - it was initially delivered via UUCP) and has been widely distributed. My experience is that Mail.app's junk filtering is rather good, producing a small number of false positives and negatives. My ISP's filtering is considerably worse. Reviewing my junk mail is no big deal. Way back when, I used to get an overwhelming amount of spam. Looking at it, the cause became clear: I own lrw.com, and have the only mailbox there. I had set it up to forward mail sent to any user at lrw.com to me. I never got anything useful that way - but I got *tons* of spam. Simply black-holing anything not sent specifically to leich...@lrw.com cut the load *way* down. Keep in mind that one of the starting points of this discussion was how to implement mail that was proof against PRISM-like bulk monitoring. That rules out solutions in which a central server has access to the cleartext of your mail to do spam scanning anyway. If people were willing to send definite spam to a central server, and accept consensus updates to their spam filter in response, there's no reason why the same algorithms that the big guys currently run couldn't be combined with local scanning. (At least you could safely send examples of spam. Sending ham is more problematic. And one could speculate about the kinds of attacks that targeted spam, together with monitoring of when it gets noticed and sent back to the service, could enable.) -- Jerry ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Implementations, attacks on DHTs, Mix Nets?
On Sun, Aug 25, 2013 at 7:42 PM, Christian Huitema huit...@huitema.netwrote: 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. I am doing a history of the Web. I came to the conclusion that the clever part is the problems it decides not to solve. Ted Nelson was absolutely right on what was desirable, but what he considered 'essential' turned out to be easily added as layers (search for example). A confidentiality solution that tells the user 'you can't send mail right now because you may be subject to an intercept' is more than acceptable. -- Website: http://hallambaker.com/ ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Good private email
This is everything *but* PRISM-proof : it doesn t solve the metadata issue and your directory server containing public keys could very well be forced by a law enforcement agency ( in the best case scenario because it could also be the mafia) to answer the fbi/mafia public key on any request made to it. On Monday, August 26, 2013, Richard Salz wrote: I don't think you need all that much to get good secure private email. You need a client that can make PEM pretty seamless; reduce it to a button that says encrypt when possible. You need the client to be able to generate a keypair, upload the public half, and pull down (seamlessly) recipient public keys. You need a server to store and return those keys. You need an installed base to kickstart the network effect. Who has that? Apple certainly; Microsoft could; Google perhaps (although not reading email is against their business model). Maybe even the FB API. It's not perfect -- seems to me the biggest weakness is (a) the client could double-encrypt for TLA's to read, or (b) it could give you the wrong key so your mail only goes to the bad guy -- but it's a hell of a lot better than we have now and I'd say it's more than good enough. Thoughts? ___ The cryptography mailing list cryptography@metzdowd.com javascript:; http://www.metzdowd.com/mailman/listinfo/cryptography -- Alexandre Anzala-Yamajako ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] ADMIN: What is top posting, and why should you avoid it?
A3: Please. Q3: Should I avoid top posting on this mailing list? A2: Because, by reversing the order of a conversation, it leaves the reader without much context, and makes them read a message in an unnatural order. Q2: Why is top posting irritating? A1: It is the practice of putting your reply to a message before the quoted message, instead of after the (trimmed) message. Q1: What is top posting? [Yes, this is a re-run, but it needed saying. Also, please trim as much as possible from messages you are quoting in replies, keeping only the sections needed to maintain context for the reader.] -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Good private email
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Aug 26, 2013, at 4:12 AM, Richard Salz rich.s...@gmail.com wrote: I don't think you need all that much to get good secure private email. You need a client that can make PEM pretty seamless; reduce it to a button that says encrypt when possible. You need the client to be able to generate a keypair, upload the public half, and pull down (seamlessly) recipient public keys. You need a server to store and return those keys. You need an installed base to kickstart the network effect. Repeat after men. Encryption is not the problem. What you described is pretty much PGP Universal. Traffic analysis is the problem. Individual computers can be tracked thru the internets with mere timing signatures on the packets given off by their clocks. Watch this. And that was academic research 7 years ago. You think things haven't progressed since then? http://www.youtube.com/watch?v=eYwYC4x4gtU Tamzen -BEGIN PGP SIGNATURE- Version: PGP Universal 3.2.0 (Build 1672) Charset: us-ascii wj8DBQFSG4uS5/HCKu9Iqw4RAo4WAJ9+TqsB6a8LUxzGWzItKvqDALCdCwCgxaaF 0sts0HaO3fSw7ZdR+Vp7B8A= =yv/q -END PGP SIGNATURE- ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Good private email
On 08/26/2013 04:12 AM, Richard Salz wrote: You need the client to be able to generate a keypair, upload the public half, and pull down (seamlessly) recipient public keys. You need a server to store and return those keys. You need an installed base to kickstart the network effect. Who has that? I know who has that - in spades! The bitcoin network is a public transaction record of bitcoin transfers. The individual accounts are not quite fully anonymous to a determined observer, but nothing we've discussed here would be more anonymous. Anyway, a bitcoin client already generates key pairs, and every transaction stores them in the database. The database is distributed to all full node clients, and kept (reasonably) secure using Nakamoto's proof-of-work protocol for the byzantine-generals problem. The maintainers of the database have a vested (monetary) interest in keeping the database secure. Anyway, each address is a relatively short high-entropy string (ECC crypto) -- and each client already has an address book of public addresses (public keys where people can be sent bitcoin payments -- or private messages) and accounts (private keys which represent bitcoin that can be sent). In addition, you can ask the client to generate a new address (keypair) for you at any moment. The private key goes into your accounts as an account with zero balance (and no message history) and a new public key for you goes into your addresses as a place where you can receive payments (and messages). There are smartphone clients that don't maintain the full database, but which do maintain the address book, accounts, and address-generation bits for you. There are already solutions for transferring public keys directly between smartphones via bluetooth, which is a convenient channel outside the sphere of Internet eavesdropping. And there is already software that can preprint N business cards (with or without your name/etc on them) that all have different addresses on them, so you can hand them out to anyone whom you think may have a reason to send you money (or messages), one address per person. In practice, people need to key in an address for someone once if they are handed a card. Keying it is about the same difficulty as a VIN number on an auto insurance form. Subsequent new addresses for the same person can be sent in a message encrypted, along with any bitcoin transaction, and automatically replace the address you already have associated with that account for your next payment (or message). If Alice doesn't have preprinted cards, she has her smartphone and it can generate an address for her on demand -- She will have to read it off her smartphone screen if she wants to scribble it on a napkin. If we build further email infrastructure on top of this, A side effect of this is that every user has a choice about whether or not s/he will accept messages without payments. You can require someone to make a bitcoin payment to send you an email. Even a tiny one-percent-of-a-penny payment that is negligible between established correspondents or even on most email lists would break a spammer. Also, you can set your client to automatically return the payment (when you read a message and don't mark it as spam) or just leave it as a balance that you'll return when you reply. In short, a private email client can be built directly on top of the bitcoin network. In practice, I think it would be useful mainly for maintaining the distribution and updating of keys, rather than for messages per se, because the amount of extra data you can send along with a bitcoin transaction is quite small (3k? I think?). Anyway, it couldn't handle file attachments etc. Bear ___ 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 08/25/2013 03:28 PM, Perry E. Metzger wrote: 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.) My main issue with this proposal is that somebody identifiable is going to manufacture these boxes. Maybe several somebodies, but IMO, that's an identifiable central point of control/failure. If this is deployed, what could an attacker gain by compromising the manufacturers, via sabotage, component modification/substitution at a supplier's chip fab, or via secret court order from a secret court operating according to a secret interpretation of the law? Bear ___ 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 08/25/2013 08:32 PM, Jerry Leichter wrote: Where mail servers have gotten into trouble is when they've tried to provide additional services - e.g., virus scanners, which then try to look inside of complex formats like zip files. This is exactly the kind of thing you want to avoid - another part of the mission creep that we tend to see in anything that runs on a general-purpose computer. Absolutely agreed; the most reliable things are the least complex. That's 20th century thinking: The computer is expensive, keep it busy. Twenty first century thinking should be: The computer is cheap - leave it alone to do its job securely. My thinking is more like: The computer has a multitasking OS. Whatever else it needs to be doing will be in another process. So you lose nothing if you keep each process simple. Or if it's a single-purpose box intended to provide security; don't dilute its purpose. Keep it simple enough that even installations of it in the wild, after unknown handling and in all possible configurations, can be unambiguously, easily, and exhaustively tested so you know they're doing exactly what they should be and no more. Realistically, it will be impossible to get little appliances like this patched on a regular basis - how many people patch their WiFi routers today? - so better to design on the assumption there won't be any patches. Also agreed; online patches are the number one distribution vector of malware that such a device would need to be worried about. Firstly because whoever can issue such a patch is a central point of control/ failure and can be coerced. So send it out with an absolutely sealed kernel. Bear ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Good private email
On Aug 26, 2013, at 1:16 PM, Ray Dillinger b...@sonic.net wrote: Minor point in an otherwise interesting message: Even a tiny one-percent-of-a-penny payment that is negligible between established correspondents or even on most email lists would break a spammer. Also, you can set your client to automatically return the payment (when you read a message and don't mark it as spam) or just leave it as a balance that you'll return when you reply. This (and variants, like a direct proof-of-work requirement) has been proposed time and again in the past. It's never worked, and it can't work, because the spammers don't use their own identities or infrastructure - they use botnets. They don't care what it costs (in work or dollars or Bitcoins) to send their message, because they aren't going to pay it - the machine they've taken over is going to pay. Granted, today most machines don't provide access to Bitcoins. But assuming your idea catches on, they will. Once a box has a legitimate capability to send some form of mail, it can be subverted to send mail of that form that the owner of that box didn't intend. As long as endpoints can be pwned, nothing about those endpoints can be trusted -- Jerry ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Implementations, attacks on DHTs, Mix Nets?
On Sun, Aug 25, 2013 at 12:12 PM, Perry E. Metzger pe...@piermont.comwrote: Anyone care to shed some light? Pointers to literature are especially welcome Check out this paper: Security Considerations for Peer-to-Peer Distributed Hash Tables http://and.they.can.be.quite.long.3.4.0.f.0.6.a.0.1.0.0.2.ip6.arpa/~bauerm/names/DHTsec.pdf -- Tony Arcieri ___ 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 Mon, 26 Aug 2013 10:40:17 -0700 Ray Dillinger b...@sonic.net wrote: On 08/25/2013 03:28 PM, Perry E. Metzger wrote: 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.) My main issue with this proposal is that somebody identifiable is going to manufacture these boxes. Maybe several somebodies, but IMO, that's an identifiable central point of control/failure. One can use a commercial PC if one wants to install on one's own, or any one of many manufacturers of small boxes. It is certainly the case that the hardware layer can be attacked, all is lost. On the other hand, if we presume supply chain attacks, all is lost anyway -- once you control the computer, the protocols it is running don't matter. Even keyboards can be suborned -- see Gaurav Shah's work on that, for example. I would prefer not to try to solve that problem right now -- it is too broad and too general. If others can solve it, that's of course a great thing. :) Perry -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Good private email
This is everything *but* PRISM-proof I wasn't trying to be PRISM proof, hence my subject line. The client and keyserver could help thwart traffic analysis by returning a few extra keys on each request. The client then sends a structure message to some of those keys that the receiving client recognizes and ignores. and your directory server containing public keys could very well be forced by a law enforcement agency ( in the best case scenario because it could also be the mafia) to answer the fbi/mafia public key on any request made to So what? Your content might get sent to the wrong person, but that can be avoided with that old PKI favorite, out of band verification. If it's necessary. [bitcoin] has the user base No it doesn't. Not by orders of magnitude compared to the few I mentioned. Nor does it have a mail client last I checked. (I guess Chrome doesn't either, but that could be fixed with a couple of quick, and silent, updates.) you just described PGP universal I never said it was new. The combination of size of the populace using an out of the box mail client that has this happen seamlessly, however, would be new. Traffic analysis is the problem Do you really think that for most people on the planet, that it is? Hey folks, go off and design your perfect secure system. Build a prototype or alpha-test even. And then watch while the millions of people who could benefit from private email, and the few who could use it as an infrastructure to build more services, ignore you. Sigh. /r$ ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Good private email
On 08/26/2013 10:39 AM, Jerry Leichter wrote: On Aug 26, 2013, at 1:16 PM, Ray Dillinger b...@sonic.net wrote: Even a tiny one-percent-of-a-penny payment that is negligible between established correspondents or even on most email lists would break a spammer. This (and variants, like a direct proof-of-work requirement) has been proposed time and again in the past. It's never worked, and it can't work, because the spammers don't use their own identities or infrastructure - they use botnets. They don't care what it costs (in work or dollars or Bitcoins) to send their message, because they aren't going to pay it - the machine they've taken over is going to pay. Possible, but Doubtful. The bitcoin wallet is extraordinarily secure as software goes. Once you've chosen a keyphrase, It NEVER gets saved in decrypted form to the disk, and even in the client software, cannot be decrypted except by explicit command and will not remain in memory for more than a few seconds in decrypted form. Furthermore, the client software does not invoke other programs (like Word or other scriptable attack vectors) under any circumstances. Furthermore any extensions like clickable URLs in messages or javascript execution etc or other methods by which external possibly non-secure applications could start up with information from inside the client would be soundly rejected as untrustworthy extensions. People design for and demand an altogether different level of security when you're talking about their own money, and handle the complexities of key management with no difficulty. In short, no possibly naive user could convince the developers to do the stupid things that email clients do for coolness or convenience in the context of a financial client. If there were a vulnerability or exploit discovered that allowed a spammer to take control of a bitcoin account, it would be regarded as a MAJOR DISASTER by the community and prompt a fix within minutes, not hours days or months as is the case with mere email clients. Consider that *every* *last* *developer* stands to lose at least thousands or tens of thousands of dollars of real, personally owned money if confidence in the network falters. In some cases literally millions. This is not some hypothetical loss to the company that they can be ordered to do by some boss even though they think it's a bad idea, nor some hobby that they can allow to fall by the wayside; these people are deeply and very literally invested in the security of the code, and flatly will refuse to do anything that might compromise it. If some company did issue a client with security holes, the usual shrink-wrap not liable crap would be completely unacceptable, the lawsuit exposure would be somewhere in the trillions of dollars, and the legal costs to even try to defend a mealymouthed claim of not liable because of our shrink wrap license from the resulting firestorm would probably break the company. There are *dozens* of serious, litigous, investors who hold millions of dollars in bitcoin these days, including, among others, the Winkelvoss brothers who spent ten years or more pursuing their infamous Facebook lawsuit. Even if you win that legal fight you're going to lose. The fact that the client is also highly usable is an excellent example of interface design. Bear ___ 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 Mon, Aug 26, 2013 at 02:44:32PM -0400, Perry E. Metzger wrote: My main issue with this proposal is that somebody identifiable is going to manufacture these boxes. Maybe several somebodies, but IMO, that's an identifiable central point of control/failure. Recently there's a trend for at least somewhat open hardware (Raspberry Pi, other ARM systems, Parallella Epiphany) some of which contain enough FPGA real estate (sure, we know there are FPGA backdoors, but) so that you could boot up an open core soft CPU, and even bootstrap your own toolchain from scratch. One can use a commercial PC if one wants to install on one's own, or any one of many manufacturers of small boxes. It is certainly the case In principle an FPGA die is regular, and hence more easily inspectable, but even SoCs can be sampled by reverse-engineering them from the metal layers. that the hardware layer can be attacked, all is lost. On the other hand, if we presume supply chain attacks, all is lost anyway -- once you control the computer, the protocols it is running don't matter. Even keyboards can be suborned -- see Gaurav Shah's work on that, for example. We need open, fully inspectable systems. If proving code, or at least, auto-generating code from state machines catches on in open source the number of exploitable vulnerabilities can be greatly diminished. I would prefer not to try to solve that problem right now -- it is too broad and too general. If others can solve it, that's of course a great thing. :) ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] Using Raspberry Pis
I really like RPis as a cryptographic tool. The only thing that would make them better is a second Ethernet interface so they could be used as a firewall type device. However that said, the pros are: * Small, cheap, reasonably fast, has ethernet and even a monitor output * Boot from an SD card which can be preloaded with the OS and application build. So it is really easy to use RPi as an embedded device controller. The main con is that they are not so fast that you want to be routing packets through them unnecessarily. So they are a great device to make use of for connection brokering, not such a great idea to tunnel video packets through them. It is entirely reasonable to tell someone to get an RPi, download a config onto an SD card, plug it into their network and apply power and ethernet. And they take so little power that we could even tell them to install a pair so that they had a fault tolerant setup (although they are low enough power, low enough complexity that this may not be necessary or helpful). In the home of the future there will be hundreds of devices on the network rather than just the dozens I have today. So trying to configure security at every point is a non starter. Peer to peer network configurations tend to end up being unnecessarily chatty and are hard to debug because you can't tell who is meant to be in command. The approach that makes most sense to me is to have one or two network controller devices built on something like RPis and vest all the trust decisions in those. So rather than trying to configure PKI at hundreds of devices, concentrate those decisions in just one logical point. So I would like at minimum such a device to be my DNS + DHCP + PKI + NTP configuration service and talk a consistent API to the rest of the network. Which is the work I am doing on Omnibroker. Putting a mail server on the system as well would be logical, though it would increase complexity and more moving parts on a trusted system makes me a little nervous. -- Website: http://hallambaker.com/ ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] Is Traffic Analysis the problem (was Re: Good private email)
On Mon, 26 Aug 2013 14:53:54 -0400 Richard Salz rich.s...@gmail.com wrote: Traffic analysis is the problem Do you really think that for most people on the planet, that it is? Probably. If one's threat model is mass dragnet surveillance, traffic analysis is far too useful a way for the enemy to figure out who to subject to detailed analysis. The fact that quite so much traffic analysis data is being collected and saved right now should be a warning -- people who have huge budgets seem to think that it is an interesting way to snoop. Imagine you're the dictator of a country, and you want to figure out who all your political enemies are so you can throw them in camps. Simply producing the social network graph connecting up a few known activists to their tightest cluster of common contacts is going to give you loads of juicy information on who to spy on in detail and likely who to detain. Indeed, the traffic analysis information is probably the best way to figure out where to look for the needles in the haystack. Hey folks, go off and design your perfect secure system. Build a prototype or alpha-test even. And then watch while the millions of people who could benefit from private email, and the few who could use it as an infrastructure to build more services, ignore you. It doesn't have to be either-or. :) There are a lot of people in the community. Working on many different approaches is probably for the best. It is hard to tell, a priori, what will happen to take off. 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?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/25/2013 09:04 PM, Christian Huitema wrote: 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 It sounds like you're describing the F2F structure underlying the Retroshare network (though it does piggyback atop the BitTorrent DHT as a shortcut for peer finding). However, Retroshare has evidenced some significant problems on Windows as a platform, and UPnP for automatic port forwarding is dodgy at the best because not every home router out there supports it correctly (or at all). - -- The Doctor [412/724/301/703] [ZS] Developer, Project Byzantium: http://project-byzantium.org/ PGP: 0x807B17C1 / 7960 1CDC 85C9 0B63 8D9F DD89 3BD8 FF2B 807B 17C1 WWW: https://drwho.virtadpt.net/ Who are you? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlIbxskACgkQO9j/K4B7F8Hn3wCgwbBRSYaLmWCv38fDMlsso8+g 6HAAn3fEucUf43FhZxVhUx/X6oOcfrJU =V4Zm -END PGP SIGNATURE- ___ 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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/26/2013 08:46 AM, Phillip Hallam-Baker wrote: Which is why I think Ted Lemon's idea about using Facebook type friending may be necessary. Or Gchat-style contacts. I don't think we can rely on that for Key distribution. But I think it needs to be a part of the mix. What if the public key were baked into the user's public-facing profile in such a fashion that the client could pick it up automagickally but viewers just saw another link that they'd never click on anyway? I have a protocol compiler. Just give it an abstract schema and out pops a server and client API library. Just need to add the code to implement the semantics. It is up on Sourceforge, will update later this week. Neat! Link, please? - -- The Doctor [412/724/301/703] [ZS] Developer, Project Byzantium: http://project-byzantium.org/ PGP: 0x807B17C1 / 7960 1CDC 85C9 0B63 8D9F DD89 3BD8 FF2B 807B 17C1 WWW: https://drwho.virtadpt.net/ Who are you? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlIbyDoACgkQO9j/K4B7F8EjDACgrDH06jqgRCew6iVWbB5w9qm8 +e4AnjeMnOvmmNQoHuuxFMdHEv3Nff9i =8hzx -END PGP SIGNATURE- ___ 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 8/26/13 8:14 AM, Perry E. Metzger wrote: there is a good reason that I proposed that in the long run, whitelist only systems like Jabber and Facebook messaging are a better model. As one of those Jabber guys, I agree. :-) Perry, thanks for starting some very interesting threads here -- I'll post more soon. Peter -- Peter Saint-Andre https://stpeter.im/ ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Using Raspberry Pis
On Mon, Aug 26, 2013 at 4:12 PM, Phillip Hallam-Baker hal...@gmail.com wrote: I really like RPis as a cryptographic tool. The only thing that would make them better is a second Ethernet interface so they could be used as a firewall type device. Two things to look at. Onion Pi turns one into a WiFi hotspot Tor input node: http://learn.adafruit.com/onion-pi/overview Freedom Box is working on low-power home servers with goals overlapping yours. They use a different machine as their reference server, but it should work on Pi. There is some discussion in their mailing list archive: http://freedomboxfoundation.org/ ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Using Raspberry Pis
On Mon, Aug 26, 2013 at 5:43 PM, Perry E. Metzger pe...@piermont.comwrote: On Mon, 26 Aug 2013 16:12:22 -0400 Phillip Hallam-Baker hal...@gmail.com wrote: I really like RPis as a cryptographic tool. The only thing that would make them better is a second Ethernet interface so they could be used as a firewall type device. You can of course use a USB ethernet with them, but to me, they're more a proof of what you can do with a very small bill of materials. If you're designing your own, adding another ethernet (and getting rid of unneeded things like the video adapter) is easy. Custom built hardware will probably be the smartest way to go for an entrepreneur trying to sell these in bulk to people as home gateways anyway -- you want the nice injection molded case, blinkylights and package as well. :) I don't think the video adds much to the cost. I do have a USB ethernet adapter... but that cost me as much as the Pi. Problem with all these things is that the Pi is cheap because they have the volume. Change the spec and the price shoots up :( -- Website: http://hallambaker.com/ ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Using Raspberry Pis
I was pointed to this list by a friend of mine who thought I'd be interested in this discussion, and indeed I am. I intended to lurk for a while before posting, but this discussion so perfectly fits with a SkyTalk I gave at DefCon last year (DC20, not just a few weeks ago) where I proposed this very thing: A small home-router type device that contains everything that I do on-line, such as Email, IM, DNS, my node in that mythical federated social network that doesn't really exist, etc. (I'm kind of embarrassed now that I was promoting Diaspora at the time. *sigh*) Unfortunately, the realities of my life are that I haven't done anything about this, but I did get a few emails after my talk from people saying they were. 'course, I haven't heard anything SINCE then so who knows. Anyway. In case any of you are interested, my talk is available here: https://archive.org/details/skytalks_defcon_20_taking_back_our_data_smitty_2012_07_27 I'd be interested in hearing your comments or thoughts. If anything strikes you as a good idea, by all means use it. While I'm interested in seeing this happen, the realities of my life are that I'm unlikely to be the one to do it. Specifically, I'd love to be told why something like NameCoin distributing both DNS server and domain-limited CA certs would NOT work. There is the issue of scale with block-chain technologies like that, but is that the ONLY thing? Or is there a fundamental problem with the technology? -Mark On 08/26/13 14:43, Perry E. Metzger wrote: On Mon, 26 Aug 2013 16:12:22 -0400 Phillip Hallam-Baker hal...@gmail.com wrote: I really like RPis as a cryptographic tool. The only thing that would make them better is a second Ethernet interface so they could be used as a firewall type device. You can of course use a USB ethernet with them, but to me, they're more a proof of what you can do with a very small bill of materials. If you're designing your own, adding another ethernet (and getting rid of unneeded things like the video adapter) is easy. Custom built hardware will probably be the smartest way to go for an entrepreneur trying to sell these in bulk to people as home gateways anyway -- you want the nice injection molded case, blinkylights and package as well. :) The main con is that they are not so fast that you want to be routing packets through them unnecessarily. So they are a great device to make use of for connection brokering, not such a great idea to tunnel video packets through them. Not sure that's really true for normal home networks. The current average home NAT box is, in fact, a CPU in this class running Linux, so we have proof of concept of them pushing packets fast enough running in millions of homes. The processors in question are also quite cheap, and only getting cheaper and more powerful -- multicore will be universal before long. So I would like at minimum such a device to be my DNS + DHCP + PKI + NTP configuration service and talk a consistent API to the rest of the network. Not an unreasonable goal -- particular details of what software is running depend on what one's final application mix is. Putting a mail server on the system as well would be logical, though it would increase complexity and more moving parts on a trusted system makes me a little nervous. Modern Linux systems have pretty good MAC and similar security hardening available. They're a pain in the neck to configure, but if you're handing people firmware, that only has to be done once. It isn't perfect but it is better than what almost anyone has at home now or what they rely on elsewhere. (I would prefer to see hybrid capability systems in such applications, like Capsicum, though I don't think any such have been ported to Linux and that's a popular platform for such work.) In the long term, of course, I'd like to see the work in seL4 extended to open source systems, but that's a very long term goal. 0xD4217DB1.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Using Raspberry Pis
On Tue, 27 Aug 2013 12:06:47 +1200 Peter Gutmann pgut...@cs.auckland.ac.nz wrote: Perry E. Metzger pe...@piermont.com writes: Custom built hardware will probably be the smartest way to go for an entrepreneur trying to sell these in bulk to people as home gateways anyway -- you want the nice injection molded case, blinkylights and package as well. :) In that case why not just get an Alix embedded system, http://www.pcengines.ch/alix.htm, and drop pfSense, http://www.pfsense.org/, on it? Someone else has already done all the work, all you need to do is configure it however you want it. I'm not going to disagree as such (I have no idea what the wholesale cost of these machines is but I assume it is fine, or if it isn't that someone else sells one that is cheap enough.) I think that we can stipulate that quite inexpensive machines are possible, and concentrate on discussing what they might run (which is a much wider discussion -- see the last couple of days of discussion...) 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?
Ralph Holz ralph-cryptometz...@ralphholz.de writes: There is a host of older literature, too - P2P research, however, has become a cold topic. Although I expect that it will see a revival in the face of surveillance. For people who are interested, the list I have (for a year or two back) is: Security Considerations for Peer-to-Peer Distributed Hash Tables, Emil Sit and Robert Morris, Proceedings of the 1st International Workshop on Peer-to- Peer Systems (IPTPS'01), Springer-Verlag LNCS No.2429, March 2002, p.261. A Survey of Peer-to-Peer Security Issues, Dan Wallach, Proceedings of the 2002 International Symposium on Software Security (ISSS'02), Springer-Verlag LNCS No.2609, November 2002, p.42. Eclipse Attacks on Overlay Networks: Threats and Defenses, Atul Singh, Tsuen-Wan Ngan, Peter Druschel and Dan Wallach, Proceedings of the 25th International Conference on Computer Communications (INFOCOM'06), April 2006, The Index Poisoning Attack in P2P File Sharing Systems, Jian Liang, Naoum Naoumov and Keith Ross, Proceedings of the 25th Conference on Computer Communications (INFOCOM'06), April 2006, Conducting and Optimizing Eclipse Attacks in the Kad Peer-to-Peer Network, Michael Kohnen, Mike Leske and Erwin Rathgeb, Proceedings of the 8th IFIP-TC 6 Networking Conference (Networking'09), Springer-Verlag LNCS No.5550, May 2009, p.104. Combating Index Poisoning in P2P File Sharing, Lingli Deng, Yeping He and Ziyao Xu, Proceedings of the 3rd Conference and Workshops on Advances in Information Security and Assurance (ISA'09), Springer-Verlag LNCS No.5576, June 2009, p.358. Hashing it out in public: Common failure modes of DHT-based anonymity schemes, Andrew Tran, Nicholas Hopper and Yongdae Kim, Proceedings of the 8th Workshop on Privacy in the Electronic Society (WPES'09), November 2009, p.71. Poisoning the Kad Network, Thomas Locher, David Mysicka, Stefan Schmid and Roger Wattenhofer, Proceedings of the 11th International Conference on Distributed Computing and Networking (ICDCN'10), Springer-Verlag LNCS No.5935, January 2010, p.195. If there's anything significant I've missed, feel free to fill in the gaps. Peter. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
