Re: [Cryptography] Good private email
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/27/2013 02:32 AM, Sebastian Krahmer wrote: > Now, thats an interesting point! Once all email is encrypted, how > many mail providers would be interested in offering free service at > all, Another question might be, how many e-mail services would pull a Hushmail (i.e., tout transparent encryption after it leaves the browser (but is actually backdoored))? How many people /who are not us/ cared when that happened? > and whats their business model then? How brisk a business do the freemium mail providers do? One gig for free, fifty for $xus/month? > Is it still valuable enough to sell the graph of connects? Intel agencies have an interest in social graphs, which implies that the data is valuable to some people who are not intel agencies, so why not sell that data? I read an article yesterday about a company that mines Facebook and sells the data to insurance companies and suchlike for making service and rate determinations, so it is possible that this is already happening under a different context. http://www.celent.com/reports/using-social-data-claims-and-underwriting http://www.claimsjournal.com/news/national/2011/10/14/192987.htm http://www.web-strategist.com/blog/2010/06/14/how-insurance-companies-will-influence-rates-based-on-your-tweets/ - -- 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/ "Only shallow people know themselves." --Oscar Wilde -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlIcxu4ACgkQO9j/K4B7F8Hy2wCfchzF9uUS2oFLyr98ESzdabyZ uAQAoNWszAIPcrTNnOyUQXILJpoyzMRg =VAHQ -END PGP SIGNATURE- ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Good private email
On Mon, Aug 26, 2013 at 07:12:21AM -0400, 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. Now, thats an interesting point! Once all email is encrypted, how many mail providers would be interested in offering free service at all, and whats their business model then? Is it still valuable enough to sell the graph of connects? Sebastian -- ~ perl self.pl ~ $_='print"\$_=\47$_\47;eval"';eval ~ krah...@suse.de - SuSE Security Team ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Good private email
On Aug 26, 2013, at 2:54 PM, Ray Dillinger wrote: > On 08/26/2013 10:39 AM, Jerry Leichter wrote: >> On Aug 26, 2013, at 1:16 PM, Ray Dillinger 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 You're arguing about the security of the wrong component. The user runs some program that can send mail. *You* have required that it have the ability to access the user's Bitcoin wallet. At best, if everything about the wallet is implemented correctly, that just means the spammer has to slip-stream in a bunch of messages along with messages the user is already sending - while the sending is being done, there's a window during with the wallet has to be open, and you can't restrict it *too* much or the interface becomes annoying (how many times do you want to type your passphrase while sending a bunch of replies to different recipients in different domains?). Keep in mind that individual spammer bot's don't have to send a very high volume of mail; in fact, they don't *want* to as that trips too many alarms in too many places. They want to look like the person whose machine they have control of - and they want that machine to look the same as it always has to the user. The line between me sending n messages a day, and me sending (say) 3n messages a day, over many "me" instances, is enough to keep the spam masters going - but without a really intrusive interface it's hard to see how you're going to stop that. If you manage such an interface, the spammers will adjust (as they have many time before) and maybe go after high-volume mailers - who will have to have a high-threshold interface from their mail agent to their Bitcoin wallets, and cannot rely on a user regularly typing a passphrase. Somewhere or another on the net, there's a document that's intended to be sent in response to someone with a brilliant idea for finally ending spam - showing how what they thought of has not only be thought of before, but was actually tried and didn't work. I can't seem to find it again, but the last time I read it, I found it quite convincing. There's no one golden solution to the spam problem; there's just the ongoing, boring, back and forth of attack and defense. (Actually, relative to a number of years back, spam doesn't seem to be all that bad - see Perry's and my messages on a parallel thread about our own experiences.) (And if you find a contradiction between my claim that we should be able to build a provably secure system, and this claim that there's no final solution to spam: The difference between the problems is that "spam or ham" is ultimately a *human* decision which we're trying to model. Some spam these days is sophisticated enough that even humans aren' t sure! That's by its nature a problem that will never have a completely automated solution - well, maybe not until we can through close-to-human-level AI at it.) -- Jerry ___ 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 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] 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 Aug 26, 2013, at 1:16 PM, Ray Dillinger 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] 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] Good private email
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Aug 26, 2013, at 4:12 AM, 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. > 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
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 > http://www.metzdowd.com/mailman/listinfo/cryptography > -- Alexandre Anzala-Yamajako ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
