Re: STEED - Usable end-to-end encryption
On Mon, 17 Oct 2011 20:11:29 +0200, Werner Koch wrote: of the whole system. We prepared a short paper; if you are interested Some suggestions and questions, some are applicable to the paper while others might be more suited for a FAQ section on the website: * More pictures. * You're suggesting to 'to allow easy integration with the MUA it may be better to move the contact database into GnuPG proper.' I first read that as duplicating functionality of, for example, existing Directory Servers. Is that correct? If it isn't, maybe that paragraph could be clarified. * Address the concerns some have about DNSSEC (see Micah Andersons' mail from Fri 28 Oct 2011). Those concerns are mostly valid for TUFC if you don't rely on more traditional mechanisms like the WOT. * Address the size-concerns some (many?) have about publishing key material in DNS. I know about EDNS0 and TCP, but there's a myriad of firewalls and DNS-servers not being able to properly deal with that. IPv6 deployment is luckily (bit by bit) making more DNS-servers accessible to answers that are 512 bytes, but it's still a challenge. * in the conventions section you're listing GPGME as 'GnuPG Made Easy An application library used to access the feature of GnuPG.' I'd write features, in plural, don't be too modest ;-) * When suggesting DNS, IPGP records seem to make most sense to me, given the problems a lot of DNS-servers have with size. PKA and IPGP both require some other place to actually store the key. How do you picture solving that? Anyone has other suggestions or feedback on this? Maybe this list has more ideas on incentives for e-mail providers for this? kwadronaut ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: STEED - Usable end-to-end encryption
On Oct 25, 2011, gn...@lists.grepular.com wrote: . . . (*) there's a nasty privacy issue when you're able to trigger a receiving email client to do arbitrary http lookups. It means the sender is able to determine when the recipient downloaded the email, and what IP address they were using at the time. Perhaps MTAs could look up the public key on delivery and add it to the email headers. . . . A comment about social psychology, FWIW: Just from talking to ordinary users, it seems to me that a hesitation they have is not to get involved with something they do not much understand, particularly when the people trying to sell it to them are telling stories about bad things happening to people because of stuff the people do not understand. People live their lives aware they are dependent on a lot of stuff they can not control or really understand, and cope by separating what is their own self and what is other. Isolating the user's involvement in the system as much as possible (eg to just locally running en/decrypt actions including using whatever keys) might both (i) technically protect users from bad stuff (including the bad effect mentioned in the quote above) and (ii) make it more comfortable for them to internalize into their own psychology that there is this security stuff happening, because it is OK since the experts are taking care of it for them and if things go wrong, they (users) themselves are not to blame. If users do not internalize the situation, they are unlikely to want to go along with it, that is how psychology works. Cf consider a strategy of aiming for something like technical modularity which mimics users' psychological modularity about the product. The system designers' problem is that they have to look at the overall system objectively technically as well as to take the position of the individual user and look at the system from that point of view, too. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: STEED - Usable end-to-end encryption
It should probably be likened to sending a letter in an security-obscured and tamper evident envelope. How often is that done? That being said, I've appreciated the discussion on this topic. Being a neophyte to mail encryption (I haven't even set up any of my own yet) gives a good perspective of the challenge. Providing the tools, putting the security envelopes next to the regular ones, is a crucial first step and no matter how much user or carrier adoption hand-wringing occurs nothing will change until the tools are accessible. Note the distinction between accessible and available. -Devin -Original Message- From: Robert J. Hansen r...@sixdemonbag.org Sender: gnupg-users-boun...@gnupg.org Date: Tue, 25 Oct 2011 22:02:29 To: gnupg-users@gnupg.org Subject: Re: STEED - Usable end-to-end encryption -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 10/25/11 6:46 PM, MFPA wrote: If people don't care about privavy, why did envelopes rather than postcards develop as the default for sending messages through the post? This one should be obvious: because a postcard doesn't allow you to write much more than a Twitter post, and many times people need to send more than a handful of characters. In the mid-to-late '90s, prior to the adoption of email, I was routinely sending my girlfriend ten-page letters. The envelope was pretty handy for keeping all those pages together. We keep on trotting out the envelope analogy, but perhaps we should do some more thinking before we do that. It doesn't appear to me to be as advantageous to our position as we think. The envelope gives the letter author immediate benefits beyond just enhanced privacy. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: STEED - Usable end-to-end encryption
On 24/10/11 19:25, Robert J. Hansen wrote: With respect to your question: what we offer is privacy, but most people do not understand privacy, do not care about privacy, and would not care about privacy even if they understood it. So if we can't motivate users by showing the bad stuff that can happen if you have no privacy, then how to do it? I don't see any other way. Which for a pessimist might imply that it is simply doomed, and we'll never have e-mail crypto by default. Though pessimists are unfortunately more often right than optimists[1], I do think the number of TLS connections between MUAs and MTAs has increased because the clients have it on by default. And I base this on absolutely nothing. Peter. PS: Nice anecdote :) [1] Curse the researchers who actually did scientific research on this! Some things are better left unknown and only speculated about :). -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at http://wwwhome.cs.utwente.nl/~lebbing/pubkey.txt ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: STEED - Usable end-to-end encryption
On 10/25/11 5:26 AM, Peter Lebbing wrote: So if we can't motivate users by showing the bad stuff that can happen if you have no privacy, then how to do it? I don't see any other way. Years ago W.D. Richter wrote a fictitious interview between the two fictitious characters Reno Nevada and Buckaroo Banzai. It sums up my position quite well. = Q: You lament the decline of the great causes -- civil rights, the antiwar movement, the war on poverty, the exploration of space -- and the all-consuming preoccupation with the self in today's culture. But what gave birth to these great causes to begin with? A: Twin utopias, unfortunately: the myth of revolution and the myth of progress. Q: These are myths? A: To the extent that people believe in them as utopias, yes, which is how they were oversold in many cases. By embracing any utopia, we sow the seeds of cynicism when things don't work out as advertised. Q: Not that they've ever been tried... A: Which is the fallacy -- that big change has to happen on an institutional or national level. When it doesn't, you have the epidemic of cynicism we have today, with bean counters running the whole shooting match under the rubric of being realists. Q: So what do we failed idealists do? A: First, stop being failures. It's absurd to judge ourselves against a scale larger than our own efforts. = I reject your premise, which seems to be that we *should* motivate users, or that it is *possible* for us to do it. I don't think either one is true. I don't think that I -- or any group of us -- has the capability to do this, so my response to this is to let myself off the hook for it. Every now and again I'll meet someone who's interested in learning about privacy and how to protect it. I do my best to help these people along. That's what I can do, that's what's within my power, that's the standard I judge myself by -- how well I do what good I can do. It's made a world of difference in my mental health. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: STEED - Usable end-to-end encryption
d...@geer.org wrote: With respect to your question: what we offer is privacy, but most people do not understand privacy, do not care about privacy, and would not care about privacy even if they understood it. [snip] You got that right, Brother. To be more pointed, how many folks on this list carry a cell phone? --dan I carry one about half the time, but it is usually powered off unless I am expecting a call, or when I need to make one. Also about once every other month to use the GPS navigation feature. -- .~. Jean-David Beyer Registered Linux User 85642. /V\ PGP-Key: 9A2FC99A Registered Machine 241939. /( )\ Shrewsbury, New Jerseyhttp://counter.li.org ^^-^^ 09:10:01 up 4 days, 18:16, 3 users, load average: 4.84, 5.14, 5.11 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: STEED - Usable end-to-end encryption
On 25/10/11 14:54, Robert J. Hansen wrote: Every now and again I'll meet someone who's interested in learning about privacy and how to protect it. I do my best to help these people along. That's what I can do, that's what's within my power, that's the standard I judge myself by -- how well I do what good I can do. The problem with the current proposal in that respect is that it requires co-operation of e-mail providers. If there is no significant user base, the providers don't want to cater for that very small minority that asks them to implement the extra DNS functionality. And without the functionality being offered by the e-mail providers, there is no chance to build a significant user base. If there was no dependency on third parties implementing stuff for their customers, this catch-22 would not be there. It needs to be such that an individual can say I will install this and then communicate with people who did the same thing. If this individual then comes to the conclusion My provider does not support this, he would need to be very motivated indeed to do something about it. So currently there is no way to only have a few people do this, and let that group grow slowly. Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at http://wwwhome.cs.utwente.nl/~lebbing/pubkey.txt ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: STEED - Usable end-to-end encryption
On 10/25/11 10:57 AM, Peter Lebbing wrote: The problem with the current proposal in that respect is that it requires co-operation of e-mail providers. I disagree. The problem with the current proposal is it offers email providers no payoff for their work. If it could credibly be said, implement STEED and you'll get 25% less spam across your network, email providers would be lining up around the block to participate. As I mentioned before, most people do not understand privacy, do not see the benefit from privacy, and even if they understood it would not see a benefit from it. That's the dealbreaker. Hundreds of good ideas have foundered on those shoals: I suspect STEED will turn out to be another. But I hope I'm wrong. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: STEED - Usable end-to-end encryption
On Mon, 24 Oct 2011 23:02:32 -0400 d...@geer.org articulated: To be more pointed, how many folks on this list carry a cell phone? I carry one virtually all the time. It is sort of in my job description. I have to be available 24/7. -- Jerry ✌ gnupg.u...@seibercom.net _ Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: STEED - Usable end-to-end encryption
On 25/10/11 17:09, Robert J. Hansen wrote: I disagree. The problem with the current proposal is it offers email providers no payoff for their work. If it could credibly be said, implement STEED and you'll get 25% less spam across your network, email providers would be lining up around the block to participate. Yes, and if it could credibly be said implement STEED and you'll get 10% more clients, you'd need crowd control. Unfortunately, both ifs are not met. When you try to create the perfect standard that solves all e-mail problems, it quickly becomes a terrible mess. You need focus and compartmentalisation, draw some boundaries. Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at http://wwwhome.cs.utwente.nl/~lebbing/pubkey.txt ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: STEED - Usable end-to-end encryption
So, to summarize what I think I've been hearing: the problem which remains to be solved (if it is a problem) is a nontechnical one, and no amount of technical wizardry will solve it. The most that can be done now is to be ready to help someone who fears for his privacy and asks, what can I do? Maybe someday there will be a panic and everybody will be asking. It's good to have an answer. -- Mark H. Wood, Lead System Programmer mw...@iupui.edu Asking whether markets are efficient is like asking whether people are smart. pgposLjY6QnZN.pgp Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: STEED - Usable end-to-end encryption
On 10/25/11 5:17 PM, Robert J. Hansen wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 [rest of message, which *lacked* a signature, elided] Wow, that's a wacky error. Time to file a bug report in Enigmail! ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: STEED - Usable end-to-end encryption
On 25/10/11 21:11, Mark H. Wood wrote: So, to summarize what I think I've been hearing: the problem which remains to be solved (if it is a problem) is a nontechnical one, and no amount of technical wizardry will solve it. The most that can be done now is to be ready to help someone who fears for his privacy and asks, what can I do? Maybe someday there will be a panic and everybody will be asking. It's good to have an answer. I think there are two major technical problems which would make things a lot easier if they were solved. 1.) A system of mapping email addresses to public keys 2.) A system of distributing private keys between all of a users email clients automatically. These can be tackled independently. For #2 I'd like to see an IMAP extension where the client can upload and download password protected private keys. The security of the keys would rely on a strong passphrase (different from the IMAP passphrase obviously) but it would solve the problem of copying the keys between clients/backing them up. It would also mean that the clients can handle the key generation/management without the user even knowing it is happening. For #1 I'd like to see two options. First of all, the DNS solution described in the STEED proposal. Secondly, as a backup, if the DNS record doesn't exist, and somebody emails me with a header containing a link (*) to their key and its fingerprint, or even just the key it's self, I'd like to automatically use that. Initially major email providers like GMail/Hotmail wouldn't implement the DNS solution, but that wouldn't stop people using GMail/Hotmail with supporting IMAP clients from automatically looking up keys and encrypting. I can imagine these two solutions being implemented natively in Dovecot, Courier IMAP, Evolution and Thunderbird if the right people can be convinced. Maybe a few other widely used open source IMAP servers and MUAs. At that point, getting noticed by Microsoft/Google/Yahoo should be easier. Web browsers would need to be upgraded to make functions available for webmail providers. I'd imagine this coming later once average users are using encrypted email without even realising. Each new implementation would simply lead to more and more encrypted email. We don't need an all or nothing approach. We might even end up with MSAs that accept mail from clients without encryption support, then look up the recipients public key, and encrypt it before passing it on. (*) there's a nasty privacy issue when you're able to trigger a receiving email client to do arbitrary http lookups. It means the sender is able to determine when the recipient downloaded the email, and what IP address they were using at the time. Perhaps MTAs could look up the public key on delivery and add it to the email headers. If somebody pulls this off, the spam fighting industry is going to have a lot of fun. It becomes a lot more difficult to identify spammy content if you can't read it. I guess all of that filtering tech (bayes/uribl lookups etc) would end up having to be pushed to the client. Those are problems to be solved by other people though. -- Mike Cardwell https://grepular.com/ https://twitter.com/mickeyc Professional http://cardwellit.com/ http://linkedin.com/in/mikecardwell PGP.mit.edu 0018461F/35BC AF1D 3AA2 1F84 3DC3 B0CF 70A5 F512 0018 461F signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: STEED - Usable end-to-end encryption
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi On Tuesday 25 October 2011 at 10:26:57 AM, in mid:4ea680e1.6070...@digitalbrains.com, Peter Lebbing wrote: On 24/10/11 19:25, Robert J. Hansen wrote: With respect to your question: what we offer is privacy, but most people do not understand privacy, do not care about privacy, and would not care about privacy even if they understood it. So if we can't motivate users by showing the bad stuff that can happen if you have no privacy, then how to do it? I don't see any other way. Which for a pessimist might imply that it is simply doomed, and we'll never have e-mail crypto by default. An oft-used analogy when promoting encrypted communication is to compare it to sending a letter in an envelope rather than sending a postcard. If people don't care about privavy, why did envelopes rather than postcards develop as the default for sending messages through the post? - -- Best regards MFPAmailto:expires2...@ymail.com During an eruption - move away from the volcano - not towards it -BEGIN PGP SIGNATURE- iQCVAwUBTqc8UaipC46tDG5pAQps0gQAuGIMmK7uuyV1kxZYhk9Q3cV+BwZYIzt/ fOBOGWkFIsbAOnv815fV/adh43UOxioG0VDMxDHost2Wp+aOjVdGdNCYVYcBVUV8 +s9Or2yMIxEvjhXEbkfrEiAmB+miNjDOgpFJqdq2s6KNcYbyUQ8M/UCOcUAUaej0 LN7dErynosk= =kSKU -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: STEED - Usable end-to-end encryption
On 10/25/2011 15:46, MFPA wrote: An oft-used analogy when promoting encrypted communication is to compare it to sending a letter in an envelope rather than sending a postcard. If people don't care about privavy, why did envelopes rather than postcards develop as the default for sending messages through the post? Privacy is certainly one reason. Others are the greater capacity of envelopes, ability to send more than one piece of paper at a time, ability to carry things other than paper I could go on. My point being that it's just as important to observe the lenses through which we do our observations as it is to make the observations themselves. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: STEED - Usable end-to-end encryption
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 10/25/11 6:46 PM, MFPA wrote: If people don't care about privavy, why did envelopes rather than postcards develop as the default for sending messages through the post? This one should be obvious: because a postcard doesn't allow you to write much more than a Twitter post, and many times people need to send more than a handful of characters. In the mid-to-late '90s, prior to the adoption of email, I was routinely sending my girlfriend ten-page letters. The envelope was pretty handy for keeping all those pages together. We keep on trotting out the envelope analogy, but perhaps we should do some more thinking before we do that. It doesn't appear to me to be as advantageous to our position as we think. The envelope gives the letter author immediate benefits beyond just enhanced privacy. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: STEED - Usable end-to-end encryption
On Fri, Oct 21, 2011 at 01:46:02AM +0200, Marcus Brinkmann wrote: On 10/20/2011 10:25 PM, Matthias-Christian Ott wrote: But who are the providers? Except for people who work in computer science, physics or similar fields I don't know people who run their own mail servers or are part of a cooperative. Most other people use a handful of providers who often offer free service in exchange for the loss of privacy or at least some form of semi-targeted advertisement. Do you expect those providers to ruin their business models by implementing this proposal? I wouldn't count on them. Maybe. But the only way to fail for certain is by not trying. There are other business models and market pressures beside those that you are highlighting. It's not easy to predict. I agree, there are other business models and perhaps there will be demand for this, but I just summarised the service providers almost all “non-technical” people I communicate with use. Perhaps the providers could also be forced by law not to implement this, because (if I remember correctly) come countries require that they store at least the header information (including subject, which should also be encryted by the system) for traffic analysis. So in the worst case the providers couldn't implement this without breaking the law (I doubt that citizens could use the system without breaking the law in this situation either, but individuals are often more venturous than organisations). STEED is fully compatible with existing mail encryption, so we do not include the headers in the plaintext. I am not an expert, but as far as I know the regulation usually demands to store connection data that is available, it does not ask for data that is not available for whatever reason. I think your interpretation of the regulations in that area is overly pessimistic, but I could be wrong. Maybe you can verify this? I'm not aware of any overview of e-mail data rentention, so I don't have complete picture, but a quick search on EU data retention laws showed that only SMTP envelope data is officially stored, so at least in these countries it's not a problem (though I think the subject should be encrypted as well). Moreover, I agree that as long as the body and thus the actual contents are not stored there is reason why a provider could break the law by providing STEED services to their costumers. Fortunately many countries have laws to garantuee (at leas in theory) privacy of correspondance and these laws of a long tradition, so it seems hard to abolish them. However, I see the possibility that providers could be forced to cooperate with government agencies, but this would have little impact and would require bigger efforts to “break” STEED this way (e.g. MITM attacks by publishing false keys for new contacts). What about making everyone their own provider? The efforts in this direction intiated by Eben Moglen that lead to the FreedomBox and other projects seem to go in the right direction. It doesn't seem to me less realistic than requiring cooperation from providers. I think everybody deserves private email communication, not only those who are willing to be their own provider. We don't expect people to carry out their own snail mail letters either, and the business model of the post office does not require spying on the letters. I agree, but I also talked to people who don't care about privacy (nothing to hide) and don't understand it. Therefore, it is important not to rely on the market to provide the means for private e-mail communication (do it yourself instead of relying on other people to do it). But, we have to go where the users are, and we have to try our best to get the providers cooperation. There is no benefit in ignoring them and their users just for our convenience. Let's say you had the opportunity to convince a smaller independent hosting provider that e.g. sells web hosting, e-mail and resells internet connectivity, how would you do this? There had to be real demand and easily installable and maintainable software to convince them to implement STEED. Recently I did some search and inquiries on DNSSEC, for which there is argueably real demands from private and enterprise customers and there is working software, but only relatively few companies worldwide offer it and I don't expect it to be widely deployed within the next years. However, people running their own server have it running or at leas prepared (waiting for the registras to close the trust chain by submitting their public key to the registry) for some time now. Maybe you are still not convinced. Then let me give you an illustrative analogy. (Disclaimer: I am not associated with SawStop or anybody involved, nor have I met anybody involved or used their product). An inventor created a table saw that can prevent injury by stopping the blade as soon as it is touched by human flesh (SawStop). According to the
Re: STEED - Usable end-to-end encryption
On Fri, Oct 21, 2011 at 06:55:47PM +0100, MFPA wrote: If you are trying to get people to think about privacy, maybe suggesting Diaspora as an alternative to Facebook is a direction to consider... I would suggest that, if you are trying to get people to think about privacy, about the only thing worth saying to them (initially) is to point out real-life examples of bad things happening to average people who didn't think about privacy. No one can desire salvation until he believes that he is in jeopardy. -- Mark H. Wood, Lead System Programmer mw...@iupui.edu Asking whether markets are efficient is like asking whether people are smart. pgpSNcORr6GO6.pgp Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: STEED - Usable end-to-end encryption
On 10/24/11 11:15 AM, Mark H. Wood wrote: No one can desire salvation until he believes that he is in jeopardy. Although hellfire-and-damnation preachers are a popular cultural idea, they're really quite rare: most preachers go more for the John 10:10 angle [*]. They've found through centuries of proselytization experience that things work better if you pitch the benefit of the faith, rather than the hypothesized penalties if you live without it. The relevance here should be plain: we need to pitch the benefits of confidential and assured communications, not the hypothetical penalties if they fail to take our advice. [*] I am come that they might have life, and that they might have it more abundantly. John 10:10, KJV signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: STEED - Usable end-to-end encryption
On Mon, Oct 24, 2011 at 11:24:40AM -0400, Robert J. Hansen wrote: On 10/24/11 11:15 AM, Mark H. Wood wrote: No one can desire salvation until he believes that he is in jeopardy. Although hellfire-and-damnation preachers are a popular cultural idea, they're really quite rare: most preachers go more for the John 10:10 angle [*]. They've found through centuries of proselytization experience that things work better if you pitch the benefit of the faith, rather than the hypothesized penalties if you live without it. And I agree with this. The problem with applying the turn-or-burn sermon to proselytization is that it requires that the audience already believes in sin and hell, and that the problem is one of raising awareness. Unbelievers...don't believe. It is fortunate to such efforts that an argument couched in terms of benefit is available. The relevance here should be plain: we need to pitch the benefits of confidential and assured communications, not the hypothetical penalties if they fail to take our advice. So, in the absence of any threat, what exactly *are* those benefits? The cited passage asserts that the hearer is missing out -- he could have more than he has now. How much more can I get out of email by using crypto? What do I get, if I don't believe that my privacy is threatened or I do not value privacy? -- Mark H. Wood, Lead System Programmer mw...@iupui.edu Asking whether markets are efficient is like asking whether people are smart. pgpEr6jJyBnF3.pgp Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: STEED - Usable end-to-end encryption
With respect to your question: what we offer is privacy, but most people do not understand privacy, do not care about privacy, and would not care about privacy even if they understood it. During graduate school the politically-active members of the Computer Science department were up in arms over government surveillance. Flyers, bulletin board notices, EFF fundraising campaigns, and the like. Yet, when the Department required all TAs sign up for Facebook, in the interests of being accessible to the undergraduates, there wasn't any outcry. I was serving as the Area Steward for the graduate student labor union and tried to drum up some outrage that we were being *required* to sign up for a privacy-annihilating 'service.' Nobody was interested -- not even the people who had flyers on their doors condemning Total Information Awareness and EFF stickers on their laptops. You got that right, Brother. To be more pointed, how many folks on this list carry a cell phone? --dan ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: STEED - Usable end-to-end encryption
Hi Matthias-Christian, thanks for your comments, I think they are entirely correct. With respect to convincing ISPs, STEED is not a complete proposal yet. The STEED paper covers the technical aspects of making email encryption usable for the user. It does not cover the policies of the parties involved and strategies to break down walls of tradition. I think there are good reasons for this. It is easier to present the technical aspects in the form of a paper, while the policy stuff is probably more a learning process that involves entering a dialogue of multiple parties. Also, success of STEED may depend on external policy changes to some extent. When those happen, we should already be in place, though. So, you summed it up best: there is a lot to be done Thanks, Marcus ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: STEED - Usable end-to-end encryption
On Fri, 21 Oct 2011 01:46, marcus.brinkm...@ruhr-uni-bochum.de said: not ask for data that is not available for whatever reason. I think your interpretation of the regulations in that area is overly pessimistic, but I could be wrong. Maybe you can verify this? Actually the German Federal commissioner for data protection demands the use of strong encryption. According to him the message-escrow-able de-mail.de law and services are not suitable for private messages. [1] Salam-Shalom, Werner [1] In German: http://www.bfdi.bund.de/DE/Oeffentlichkeitsarbeit/Pressemitteilungen/2011/12_InkrafttretenDEMailGesetz.html?nn=408908 -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: STEED - Usable end-to-end encryption
On Thu, Oct 20, 2011 at 04:16:01AM +0200, Marcus Brinkmann wrote: On 10/19/2011 09:30 PM, Peter Lebbing wrote: However, I think you're not ambitious enough when you opt for using DNS for key distribution. Yes, the infrastructure and RR types[1] are already there. But it brings this nasty dependency on the provider. Because the part of the client updates to the DNS is a key missing part in the DNS infrastructure as today, and I don't see providers adding that soon. You are right that it is a challenge to get the support in the providers, but note that changes in the mail client are required anyway. Sure, changing the client and changing the DNS infrastructure are two different kind of beasts, but we probably can not do without the providers completely if we want ubiquitous support. But who are the providers? Except for people who work in computer science, physics or similar fields I don't know people who run their own mail servers or are part of a cooperative. Most other people use a handful of providers who often offer free service in exchange for the loss of privacy or at least some form of semi-targeted advertisement. Do you expect those providers to ruin their business models by implementing this proposal? I wouldn't count on them. Perhaps the providers could also be forced by law not to implement this, because (if I remember correctly) come countries require that they store at least the header information (including subject, which should also be encryted by the system) for traffic analysis. So in the worst case the providers couldn't implement this without breaking the law (I doubt that citizens could use the system without breaking the law in this situation either, but individuals are often more venturous than organisations). What about making everyone their own provider? The efforts in this direction intiated by Eben Moglen that lead to the FreedomBox and other projects seem to go in the right direction. It doesn't seem to me less realistic than requiring cooperation from providers. Regards, Matthias-Christian ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: STEED - Usable end-to-end encryption
On 20-10-2011 22:25, Matthias-Christian Ott wrote: What about making everyone their own provider? Is that technically equivalent to running your own mailserver? Because that also gives some problems: I run my own server at vulcan.xs4all.nl (bsmtp at a subdomain of my provider) but get some mails bounced because of ecessive anti-spam filters that complain about no reverse DNS. -- Met vriendelijke groet / With kind regards, Johan Wevers PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: STEED - Usable end-to-end encryption
Matthias-Christian Ott wrote: What about making everyone their own provider? The efforts in this direction intiated by Eben Moglen that lead to the FreedomBox and other projects seem to go in the right direction. It doesn't seem to me less realistic than requiring cooperation from providers. I was my own provider for many years, and that was easy enough. I got a static IP address from my ISP for $10/month and ran sendmail as my MTA. I used mutt am MUA. But when I switched to Verizon as ISP in order to get FiOS, they wanted $150/month for a static IP address and an additional fee (I forget what it was) to be allowed to run sendmail as a server. Verizon is a great ISP 8-( They discontinued Usenet, so I have to pay a fee to another provider to use Usenet. They did not reduce their fees when the reduced the level of service. Greed and Profit before Service: it is the American way. 8-( -- .~. Jean-David Beyer Registered Linux User 85642. /V\ PGP-Key: 9A2FC99A Registered Machine 241939. /( )\ Shrewsbury, New Jerseyhttp://counter.li.org ^^-^^ 10:05:01 up 19:11, 4 users, load average: 4.93, 4.98, 5.11 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: STEED - Usable end-to-end encryption
Le 21/10/2011 16:12, Jean-David Beyer a écrit : Matthias-Christian Ott wrote: What about making everyone their own provider? The efforts in this direction intiated by Eben Moglen that lead to the FreedomBox and other projects seem to go in the right direction. It doesn't seem to me less realistic than requiring cooperation from providers. I was my own provider for many years, and that was easy enough. I got a static IP address from my ISP for $10/month and ran sendmail as my MTA. I used mutt am MUA. But when I switched to Verizon as ISP in order to get FiOS, they wanted $150/month for a static IP address and an additional fee (I forget what it was) to be allowed to run sendmail as a server. Verizon is a great ISP 8-( They discontinued Usenet, so I have to pay a fee to another provider to use Usenet. They did not reduce their fees when the reduced the level of service. Greed and Profit before Service: it is the American way. 8-( Whaou ... In France, the second ISP (http://www.free.fr/ ) gives a static IP by default with port filtering and no bandwith usage limit. BR Christophe * Le contenu de ce courriel et ses éventuelles pièces jointes sont confidentiels. Ils s'adressent exclusivement à la personne destinataire. Si cet envoi ne vous est pas destiné, ou si vous l'avez reçu par erreur, et afin de ne pas violer le secret des correspondances, vous ne devez pas le transmettre à d'autres personnes ni le reproduire. Merci de le renvoyer à l'émetteur et de le détruire. Attention : L'organisme de l'émetteur du message ne pourra être tenu responsable de l'altération du présent courriel. Il appartient au destinataire de vérifier que les messages et pièces jointes reçus ne contiennent pas de virus. Les opinions contenues dans ce courriel et ses éventuelles pièces jointes sont celles de l'émetteur. Elles ne reflètent pas la position de l'organisme sauf s'il en est disposé autrement dans le présent courriel. ** ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: STEED - Usable end-to-end encryption
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi On Thursday 20 October 2011 at 10:04:15 AM, in mid:87hb34xcds@vigenere.g10code.de, Werner Koch wrote: Most users don't have personal web pages. So what now? Well many users have a facebook page - but this would make facebook mandatory and we woold need support from them (at least to guarantee that they don't break any assumptions). Not much different to work with ISPs. If you are trying to get people to think about privacy, maybe suggesting Diaspora as an alternative to Facebook is a direction to consider... - -- Best regards MFPAmailto:expires2...@ymail.com War is a matter of vital importance to the State. -BEGIN PGP SIGNATURE- iQCVAwUBTqGyM6ipC46tDG5pAQr6+AP/dG6q9Z58HD7RVZI5h1EYEA6yDZ2Rfx/p 9zLGMKGh2QY1gYpBqG70g78IZnk01aG62MIALmRReHs6plqR7fjnASZZikItZDQY IdG8J6B7yCVdA39phiABYoVbIDYeInyxJzMIWDVUDp1gyEYN55CVRmYUO1QslsuV 2VVad3uNL2c= =wf9G -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: STEED - Usable end-to-end encryption
On Thu, 20 Oct 2011 05:30, lists-gnupg...@lina.inka.de said: the lowest efford are discovery via personal web pages like doing XDR or maybe webfinger. Most users wont be able to have special RRs - not even Most users don't have personal web pages. So what now? Well many users have a facebook page - but this would make facebook mandatory and we woold need support from them (at least to guarantee that they don't break any assumptions). Not much different to work with ISPs. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: STEED - Usable end-to-end encryption
On Wed, 19 Oct 2011 22:10, kloec...@kde.org said: What NEW standard are you talking about? Werner wants to use OpenPGP. and S/MIME! We actually don't care. For certain MUAs it is much simpler to implement something on top of S/MIME than to trying to get OpenPGP support. The actual protocol in use does not matter to the user (only to use experts). Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: STEED - Usable end-to-end encryption
Am 20.10.2011 04:16, schrieb Marcus Brinkmann: You are right that it is a challenge to get the support in the providers the lowest efford are discovery via personal web pages like doing XDR or maybe webfinger. Most users wont be able to have special RRs - not even for their own domains (which is also rather seldom). I would use link rel= like openID does. Gruss Bernd ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: STEED - Usable end-to-end encryption
Hi, I read this briefly, and I'd actually like to read it over later and maybe contribute some ideas. The lack of people caring about cryptography is quite apparent, and may be solved with some good ideas of making things less annoying / hard to use. I'd be happy to help. On Mon, Oct 17, 2011 at 11:11 AM, Werner Koch w...@gnupg.org wrote: Hi! Over the last year Marcus and me discussed ideas on how to make encryption easier for non-crypto geeks. We explained our plans to several people and finally decided to start a project to develop such a system. Obviously it is based on GnuPG but this is only one component of the whole system. We prepared a short paper; if you are interested you may download it from http://g10code.com/docs/steed-usable-e2ee.pdf ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: STEED - Usable end-to-end encryption
What proportion of consumer-grade ISPs have bothered to implement DNSSEC for serving their customers? I don't think mine does, and they're a big outfit. If I asked, I expect they'd think I was speaking Aldebaranese or something. -- Mark H. Wood, Lead System Programmer mw...@iupui.edu Asking whether markets are efficient is like asking whether people are smart. pgptlqzy4h9zc.pgp Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: STEED - Usable end-to-end encryption
On 10/20/2011 10:25 PM, Matthias-Christian Ott wrote: But who are the providers? Except for people who work in computer science, physics or similar fields I don't know people who run their own mail servers or are part of a cooperative. Most other people use a handful of providers who often offer free service in exchange for the loss of privacy or at least some form of semi-targeted advertisement. Do you expect those providers to ruin their business models by implementing this proposal? I wouldn't count on them. Maybe. But the only way to fail for certain is by not trying. There are other business models and market pressures beside those that you are highlighting. It's not easy to predict. Perhaps the providers could also be forced by law not to implement this, because (if I remember correctly) come countries require that they store at least the header information (including subject, which should also be encryted by the system) for traffic analysis. So in the worst case the providers couldn't implement this without breaking the law (I doubt that citizens could use the system without breaking the law in this situation either, but individuals are often more venturous than organisations). STEED is fully compatible with existing mail encryption, so we do not include the headers in the plaintext. I am not an expert, but as far as I know the regulation usually demands to store connection data that is available, it does not ask for data that is not available for whatever reason. I think your interpretation of the regulations in that area is overly pessimistic, but I could be wrong. Maybe you can verify this? What about making everyone their own provider? The efforts in this direction intiated by Eben Moglen that lead to the FreedomBox and other projects seem to go in the right direction. It doesn't seem to me less realistic than requiring cooperation from providers. I think everybody deserves private email communication, not only those who are willing to be their own provider. We don't expect people to carry out their own snail mail letters either, and the business model of the post office does not require spying on the letters. Now, it may be the case that the freedom box is (or will be) a more attractive way for people to do email, and everybody will use it and nobody will use proprietary email service providers. That would be excellent! The FreedomBox project is a very important project, and it deserves our strongest support possible. If it is a better alternative, we still need to convince the FreedomBox project to adopt the STEED proposal (not a single word in the paper would have to change). And I agree that this is an overall more appealing task than trying to convince the proprietary providers. But, we have to go where the users are, and we have to try our best to get the providers cooperation. There is no benefit in ignoring them and their users just for our convenience. If this is too daunting for you, please remember that we do not have to get their active cooperation. If they accept it grudgingly because not following along would be bad business (or illegal), then that's good enough. That requires that we raise the state of the art in the field. Maybe you are still not convinced. Then let me give you an illustrative analogy. (Disclaimer: I am not associated with SawStop or anybody involved, nor have I met anybody involved or used their product). An inventor created a table saw that can prevent injury by stopping the blade as soon as it is touched by human flesh (SawStop). According to the inventory, he could not get the technology to be marketed by the big table saw companies. His claim is that the companies think that by raising the safety measures in the table saw, they would be more liable for table saw accidents, which would make them subject to litigation. Eventually he created his own SawStop product line. Now, after several years, lawmakers and regulators have taken notice and might make sawstop like technology mandatory in table saws. Now, maybe SawStop is bad technology, maybe it's good. But at least something is true: As long as no candidate technology like it exists, the question doesn't even come up. That's the state we are at with email encryption. Everybody who tried has learned that email encryption is not worth the hassle. Everybody who hasn't tried just expects email to be secure and might not even be aware that it is not. It's time to change that equation, don't you think? The good news is that STEED will integrate extremely well in P2P systems. The dependency on a provider in STEED is not integral to the proposal, but just a consequence of people already relying on their providers infrastructure for everything else. If users use different infrastructure, STEED will also work over that infrastructure just as well. Thanks, Marcus ___ Gnupg-users mailing list Gnupg-users@gnupg.org
Re: STEED - Usable end-to-end encryption
- Original Message - From: Werner Koch w...@gnupg.org To: Jerome Baum jer...@jeromebaum.com Cc: gnupg-users@gnupg.org Sent: Tuesday, October 18, 2011 7:00 PM Subject: Re: STEED - Usable end-to-end encryption On Tue, 18 Oct 2011 16:35, jer...@jeromebaum.com said: operations will be the most important part to making that work, and the ISPs don't have to help out there (modulo webmail which isn't even end-point). Even webmail. It is easy to write a browser extension to do the crypto stuff. Installing browser extensions is even easier than installing most other software. There is firegpg plugin for firefox, and it does not works well with latest versions (installing it in firefox5 was not straightforward). I am not aware of any other public key encryption plugin for firefox or for any other browser. Some webmails have POP3/IMAP/SMTP, but some does not. (for example inbox.lv for qute long time had only POP3, but not SMTP) ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: STEED - Usable end-to-end encryption
On 18 October 2011 12:00, Werner Koch w...@gnupg.org wrote: On Tue, 18 Oct 2011 16:35, jer...@jeromebaum.com said: operations will be the most important part to making that work, and the ISPs don't have to help out there (modulo webmail which isn't even end-point). Even webmail. It is easy to write a browser extension to do the crypto stuff. Installing browser extensions is even easier than installing most other software. It's not easy. I'm aware of FireGPG, CR-GPG, and Penango and they range from non-functional to barely-functional, some of the time. Email encryption is a super-hard problem because even within a 'target audience', you have to deal with hard problems, and cross-target-audience they get even harder. The Young Crowd: Most people I know use gmail web interface and their phone. The Old Crowd: Most of these folks I know use yahoo, hotmail, or their ISP with Outlook Express. The Super-Old-Crowd: Anything, but it needs to be easy enough to set up that a member of the Old Crowd can do it *for* a member of this crowd. Corporate: It has to enterprise manageable, key escrow, compliant, etc Devs/Security Folks: Key Management! My private key can never leave my possession. Other Security Folks: Absolutely NO javascript cryptography. Zero, none. And there's the very practical problem of _sometimes_ I do need to read my mail from a machine that is not my own. As a security person I almost never do it. But 'the young crowd' do it all the time. You have to satisfy that requirement also. From what I've seen - S/MIME within an organization satisfies most of Corporate, until you send an email outside the organization. Enigmail satisfies some developers/security folk (but you lose email on your phone and webmail - which is pretty nice.) Any solution you come up with for one group _should_ interoperate with the solution(s) for the others. And any solution that relies on an ISP or webmail provider making changes is just unlikely. The most innovation we've seen recently has come from the Chrome and Mozilla teams who are driving browser security with HSTS, Pinning, and Content Security Policy. Internet Explorer is driving browser security in another direction with reputational-based downloads and anti-phishing. So trying to drive a secure, browser-based cryptoapi seems to be a reasonable possibility. (See DOMCrypt). For browsers without the API, you could use a plugin to provide it, and eventually hopefully the browser makes it part of the browser proper and the extension is obsolete. That almost solves webmail. Except that the provider needs to support it - and you could opt to leave your key on the server vs not, that partially solves key management (because it's a choice). It could use OpenPGP and interoperate with Enigmail/Mutt. But you're still left trying to interoperate with corporate, phone-mail, convincing yahoo/hotmail/other obscure webmails to support it, intergrating it into the next Outlook Express (Windows Mail I think?), and having an understandable UI. I've been working with and on remailers recently, and this is a similar problem. It's bloody hard. I don't know if there will ever be a better solution than what we have now, and what we have now sucks. -tom ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: STEED - Usable end-to-end encryption
Hi, On 19.10.2011, at 15:11, Tom Ritter wrote: Other Security Folks: Absolutely NO javascript cryptography. Zero, none. well, JavaScript itself is just another programming language and combined with modern technologies like HTML5 Web Storage there is nowadays technically no need to implement browser plugins for different versions and platforms. See [1]. Best regards, Alex [1] http://www.gpgtools.org/mobile/index.html -- http://gpgtools.org ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: STEED - Usable end-to-end encryption
--- On Mon, 10/17/11, Werner Koch w...@gnupg.org wrote: From: Werner Koch w...@gnupg.org Subject: STEED - Usable end-to-end encryption To: gnupg-de...@gnupg.org Cc: Marcus Brinkmann mar...@gnu.org, gnupg-users@gnupg.org Date: Monday, October 17, 2011, 2:11 PM Hi! http://g10code.com/docs/steed-usable-e2ee.pdf There is also a brief (for now) web page dedicated to this project: http://g10code.com/steed.html Here is some input, you might not like it - but still: I dont see any ground breaking new approaches to the topic - key search via DNS has been in commercial products for over 10 years already - nothing new - heck isnt there even an RFC that describes this? Letting the keys automatically be generated by the client is not a new approach either commercial solutions do this too - however - did you think of the keys the user already has? His ID for example - you are sponsored by the german government - the first thing which should have come into your mind is that everybody can use his Personalausweis as a Smartcard because it already has a private/public keypair. Other european countries could follow... Also - inventing just ANOTHER protocol for email encryption that mail clients should implement? Heck, the only protocol available in all major mail clients right now for out of the box encryption is only smime - for PGP you need plugins - even after so many years there is no out of the box solution for the other major standard - lets not talk about all the compatibility issues with smime in all existing clients. And you just want add another NEW standard which will solve issues? I dont think so. Use existing tools most user have installed on his machine by default - work with these and get a suiteable end-to-end encryption going! ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: STEED - Usable end-to-end encryption
Werner, Marcus, Thank you for thinking about taking end-to-end e-mail encryption to the next level. I really like your ideas. However, I think you're not ambitious enough when you opt for using DNS for key distribution. Yes, the infrastructure and RR types[1] are already there. But it brings this nasty dependency on the provider. Because the part of the client updates to the DNS is a key missing part in the DNS infrastructure as today, and I don't see providers adding that soon. I'm thinking more of things like DHT, Distributed Hash Tables, in BitTorrent, or similar concepts in other peer-to-peer networks. I have no idea how it works :), but it does. You fire up your BitTorrent, all the data it needs is the hash of a torrent file, and suddenly it learns IP-addresses of other people who share that torrent file. If you could do something similar for mapping e-mail addresses to certificates, you don't need ISP's to implement extra stuff. Because I think that is a really major hurdle; probably a too steep one, IMHO. And if you design that infrastructure general enough to do X-to-certificate, we could use the same infra for opportunistic end-to-end encryption of TCP/IP, which would be great to have too, but a different paper altogether :). Peter. [1] Entries in the DNS, for people not up to DNSpeed ;) -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at http://wwwhome.cs.utwente.nl/~lebbing/pubkey.txt ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: STEED - Usable end-to-end encryption
On 19/10/11 21:30, Peter Lebbing wrote: that is a really major hurdle; probably a too steep one, IMHO. Given that all normal, literal hurdles are at right angles to the ground, they are all equally steep. Obviously I meant high :D. Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at http://wwwhome.cs.utwente.nl/~lebbing/pubkey.txt ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: STEED - Usable end-to-end encryption
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi On Wednesday 19 October 2011 at 7:07:45 PM, in mid:1319047665.75751.yahoomailclas...@web130223.mail.mud.yahoo.com, Harakiri wrote: Also - inventing just ANOTHER protocol for email encryption that mail clients should implement? Heck, the only protocol available in all major mail clients right now for out of the box encryption is only smime - for PGP you need plugins - even after so many years there is no out of the box solution for the other major standard - lets not talk about all the compatibility issues with smime in all existing clients. And you just want add another NEW standard which will solve issues? I dont think so. On the other hand, perhaps the message to take from the current low adoption levels of encrypted email is that the current protocols need replacing (or major tweaking). (-; Use existing tools most user have installed on his machine by default - work with these and get a suiteable end-to-end encryption going! If tools are installed by default but not enabled by default, maybe the group that needs bringing on board is not ISPs/email providers but OEMs and those who produce operating systems, email clients and browsers? - -- Best regards MFPAmailto:expires2...@ymail.com What's another word for synonym? -BEGIN PGP SIGNATURE- iQCVAwUBTp8tQ6ipC46tDG5pAQojwQQAyVC7lwcAqp82tR9lwxLQ2Y5bfdmw0Fym yYD/xnFlEB2Pxyzsvizdb0SyCgrGlpqIePhCw8YqGMW6ZWVl+l1Q3mU3SI67G+db s74vMtMLVr2zMW7FiGfKpHrDad6Gj1RQHoBSjN4kmalcTEGMediABmXgwFrfk9le /Ze5URFyJj4= =V8zt -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: STEED - Usable end-to-end encryption
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi On Wednesday 19 October 2011 at 8:30:48 PM, in mid:4e9f2568.6080...@digitalbrains.com, Peter Lebbing wrote: If you could do something similar for mapping e-mail addresses to certificates It would be awesome if this could be achieved without revealing other email addresses or UIDs that might happen to map to the same key/certificate. - -- Best regards MFPAmailto:expires2...@ymail.com Did you hear? They took the word gullible out of the dictionary -BEGIN PGP SIGNATURE- iQCVAwUBTp8whKipC46tDG5pAQosxQP9GrQFRgLGah55Xn3wtD1yOs1LfSiodMxu t4pEi3ecFQPrVvhExXhaqqm2MnDk14CG6xonZorMbrOc++oPqaismQ1ZCOagHiU0 Klqy3k/S0sWR2XIK7ec9G4BRNUirKtsIA4Etj0BXyfbuuDZ0weWxFPelZ5VBD6Ow ZLQ+joDgtdk= =iWzE -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: STEED - Usable end-to-end encryption
If you could do something similar for mapping e-mail addresses to certificates It would be awesome if this could be achieved without revealing other email addresses or UIDs that might happen to map to the same key/certificate. Hash the UID many times. (Didn't someone propose that a while ago?) -- PGP: A0E4 B2D4 94E6 20EE 85BA E45B 63E4 2BD8 C58C 753A PGP: 2C23 EBFF DF1A 840D 2351 F5F5 F25B A03F 2152 36DA ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: STEED - Usable end-to-end encryption
On Wednesday 19 October 2011, Harakiri wrote: --- On Mon, 10/17/11, Werner Koch w...@gnupg.org wrote: From: Werner Koch w...@gnupg.org Subject: STEED - Usable end-to-end encryption To: gnupg-de...@gnupg.org Cc: Marcus Brinkmann mar...@gnu.org, gnupg-users@gnupg.org Date: Monday, October 17, 2011, 2:11 PM Hi! http://g10code.com/docs/steed-usable-e2ee.pdf There is also a brief (for now) web page dedicated to this project: http://g10code.com/steed.html Here is some input, you might not like it - but still: I dont see any ground breaking new approaches to the topic - key search via DNS has been in commercial products for over 10 years already - nothing new - heck isnt there even an RFC that describes this? Letting the keys automatically be generated by the client is not a new approach either commercial solutions do this too - however - did you think of the keys the user already has? His ID for example - you are sponsored by the german government - the first thing which should have come into your mind is that everybody can use his Personalausweis as a Smartcard because it already has a private/public keypair. No, it does not. At least, not by default. If you buy a qualified certificate then you can put this certificate on your Personalausweis, but, given how expensive such a certificate is, I doubt that a lot of people will use this feature of the Personalausweis. There are probably more people with an OpenPGP-capable smartcard than there are people with a German Personalausweis with an expensive certificate. Other european countries could follow... Also - inventing just ANOTHER protocol for email encryption that mail clients should implement? Heck, the only protocol available in all major mail clients right now for out of the box encryption is only smime - for PGP you need plugins - even after so many years there is no out of the box solution for the other major standard - lets not talk about all the compatibility issues with smime in all existing clients. And you just want add another NEW standard which will solve issues? I dont think so. What NEW standard are you talking about? Werner wants to use OpenPGP. The only thing he wants to simplify is key exchange. Use existing tools most user have installed on his machine by default - work with these and get a suiteable end-to-end encryption going! I'm not sure what existing tools you mean. Are you talking about S/MIME? You said yourself that S/MIME is no viable solution because of compatibility issues. Regards, Ingo signature.asc Description: This is a digitally signed message part. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: STEED - Usable end-to-end encryption
On 2011-10-19 22:49, Peter Lebbing wrote: On 19/10/11 22:22, Jerome Baum wrote: It would be awesome if this could be achieved without revealing other email addresses or UIDs that might happen to map to the same key/certificate. Hash the UID many times. (Didn't someone propose that a while ago?) By default the STEED system as proposed creates a new certificate for every e-mail address. So unless manually overridden, there is a one-to-one relation between e-mail addresses and certificates and no way to enumerate all e-mail addresses. Peter. Re-reading the original quote (map to the same key/certificate) that's right. I had assumed he was talking about the DHT correlating keys (so just like you can tell in the BitTorrent DHT which other torrents some IP is involved in by doing enough work, you might be able to tell which other certificates that IP uploaded -- but all this is nonsense in the original context, which I misread). -- PGP: A0E4 B2D4 94E6 20EE 85BA E45B 63E4 2BD8 C58C 753A PGP: 2C23 EBFF DF1A 840D 2351 F5F5 F25B A03F 2152 36DA ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: STEED - Usable end-to-end encryption
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi On Wednesday 19 October 2011 at 9:49:20 PM, in mid:4e9f37d0.50...@digitalbrains.com, Peter Lebbing wrote: By default the STEED system as proposed creates a new certificate for every e-mail address. So unless manually overridden, there is a one-to-one relation between e-mail addresses and certificates and no way to enumerate all e-mail addresses. Fair enough if you are using the default. The paper also mentions One Key for all Accounts and says The system should allow for this use case, which needs to be supported by all clients by allowing previously created keys to be configured and deployed with an account. - -- Best regards MFPAmailto:expires2...@ymail.com Wait. You think I'm right? -BEGIN PGP SIGNATURE- iQCVAwUBTp9C5qipC46tDG5pAQot2wP9Hon1hAbbLzbYo02qBgaW1UZHA/GBBFgH +t77FNBc3OaolffxGzAZol9FhT+wrzsKkn6yos6E+Ub+rvZHHFgyNGoPPt5WSsBI U0gfK/is3xBVcmsM8YdWBYcd3l2dQeMyP3tw3CxHCU3DaDUjsjC9+kC3mJ3+E/g5 qjasVBWBFuU= =m9sn -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: STEED - Usable end-to-end encryption
On Wednesday 19 of October 2011 22:10:30 Ingo Klöcker wrote: On Wednesday 19 October 2011, Harakiri wrote: Also - inventing just ANOTHER protocol for email encryption that mail clients should implement? Heck, the only protocol available in all major mail clients right now for out of the box encryption is only smime - for PGP you need plugins - even after so many years there is no out of the box solution for the other major standard - lets not talk about all the compatibility issues with smime in all existing clients. And you just want add another NEW standard which will solve issues? I dont think so. What NEW standard are you talking about? Werner wants to use OpenPGP. The only thing he wants to simplify is key exchange. since when key servers are hard to use? the short PGP fingerprints can easily be told on the phone (so you have a voice verification of the key if you know the person) and the full can be verified just as easily. The problem is that people don't feel the need for authentication and privacy in e-mail. They feel that e-mail is secure (after all I use encryption to my e-mail server). Regards, -- Hubert Kario ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: STEED - Usable end-to-end encryption
Hi Peter, thanks for your feedback. On 10/19/2011 09:30 PM, Peter Lebbing wrote: However, I think you're not ambitious enough when you opt for using DNS for key distribution. Yes, the infrastructure and RR types[1] are already there. But it brings this nasty dependency on the provider. Because the part of the client updates to the DNS is a key missing part in the DNS infrastructure as today, and I don't see providers adding that soon. You are right that it is a challenge to get the support in the providers, but note that changes in the mail client are required anyway. Sure, changing the client and changing the DNS infrastructure are two different kind of beasts, but we probably can not do without the providers completely if we want ubiquitous support. I'm thinking more of things like DHT, Distributed Hash Tables, in BitTorrent, or similar concepts in other peer-to-peer networks. I have no idea how it works :), but it does. You fire up your BitTorrent, all the data it needs is the hash of a torrent file, and suddenly it learns IP-addresses of other people who share that torrent file. If you could do something similar for mapping e-mail addresses to certificates, you don't need ISP's to implement extra stuff. Because I think that is a really major hurdle; probably a too steep one, IMHO. Yes, P2P networks are great, let's do more of those. But why stop at certificates? Just use a P2P network for all of DNS. See what happened? I just turned it around. :) The paper notes how we can utilize DNSSEC to strengthen our trust model. Similarly, we can utilize a P2P based DNS system. Now instead of one problem, we got two :) P2P systems are tricky to get right, and have their own tradeoffs. Also, while acceptance for our proposal among service providers will be tough to get, I'd expect that getting acceptance for a P2P based system would be even harder. A lot of things have to fall into place to make a P2P network a viable alternative, and not all of them are technical. Thanks, Marcus ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: STEED - Usable end-to-end encryption
On 17 October 2011 20:11, Werner Koch w...@gnupg.org wrote: Hi! Over the last year Marcus and me discussed ideas on how to make encryption easier for non-crypto geeks. We explained our plans to several people and finally decided to start a project to develop such a system. Obviously it is based on GnuPG but this is only one component of the whole system. We prepared a short paper; if you are interested you may download it from http://g10code.com/docs/steed-usable-e2ee.pdf There is also a brief (for now) web page dedicated to this project: http://g10code.com/steed.html Have you had a look at? http://retroshare.sourceforge.net/ It has a very good integration with GPG Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: STEED - Usable end-to-end encryption
Skimmed over this. You say that you need ISP support to get the system adopted (for the DNS-based distribution). Wouldn't that hinder adoption? Please look at how most people use mail: They get a mail address from their ISP, a preinstalled MUA and so on. Mail works for them instantly; if it does not work, they change the provider or don't use mail. Thus to allows allow for instant use of encryption it is important to have encryption on by default and so you can't do that without getting ISPs interested in it. I know a number of power users that aren't savvy enough to configure gpg4win but are savvy enough for their share of MUAs. The MUA in this case isn't supplied by the ISP. In fact to my knowledge outside of webmail and inside private email (so drop companies, universities, schools) it's usual to configure your own MUA, with the help of instructions from your ISP. So yes the ISP is useful in helping with adoption (never said this isn't true, I fully agree) but this absolute ISP or not at all approach bugs me. How about an opportunistic approach? This email should include the following header: See above. Further the problem with such headers is that it is a local configuration highly dependent on the used MUA. More and more users are reading mail with at least two devices. Thus a certain degree of MUA independence is required. Access to the DNS is required anyway thus it is an obvious solution to use it for key distribution. I was saying if we have to extend the MUA anyway, we might as well add this header. We have to extend the MUA or otherwise it doesn't support end-point encryption. I don't see how DNS changes need to be made anyway. So take an average email provider and assume I don't have any zones delegated to me. I can upload my key to the keyservers just fine. I can add this header just fine. I can attach the key to my emails just fine. I don't need the ISP to do anything in his DNS zone.* (Now before someone comes up with yeah but the end-user doesn't know how to, *a computer can do all of this just fine*.) I'm not saying the ISP wouldn't be helpful when it comes to deploying this. Using Hushmail is obviously easier than installing and configuring gpg4win. I just don't like this absolute approach of we need the ISP, there's no way to do this without them, so let's not even try. What speaks against a hybrid approach (use the ISP if they support it, do it on our own if they don't)? I'd think what speaks against should be takes more work to develop or adds software complexity, not theoretical arguments about how this can't be user-friendly. The header vs. DNS question doesn't even relate to user-friendliness as it should happen behind the scenes. The only effect cooperation with ISPs would have is that some users get a message saying we don't support their ISP. I'm trying to suggest a solution that drop this message for those users. * To show that I think DNS is useful: ;; ANSWER SECTION: jerome._pka.jeromebaum.com. 3596 IN TXT v=pka1\;fpr=A0E4B2D494E620EE85BAE45B63E42BD8C58C753A\;uri=http://jeromebaum.com/pgp; (Hmm I should update that to the https version. I'll do this tomorrow.) -- PGP: A0E4 B2D4 94E6 20EE 85BA E45B 63E4 2BD8 C58C 753A PGP: 2C23 EBFF DF1A 840D 2351 F5F5 F25B A03F 2152 36DA ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: STEED - Usable end-to-end encryption
I don't see why the ISP has to be the entity providing DNS lookup. The one I use won't even allocate me a static address, let alone accept RRs from me to serve out to others. I'm not sure I'd trust them to get it right and *keep* it right anyway. If the ISPs won't cooperate, maybe the antivirus vendors would. They're already in the data security business, already have an extensive network presence, and already get money from me to help me secure my information assets. Build enrollment into the AV product or provide a separate setup tool. It should be simple. Likewise there are freestanding DNS providers out there who already have the infrastructure and the experience, are already serving some of us, already get money from some of us. This could be a welcome source of a little more income for very little more cost, or a freebie to get you in the door like free DDNS does. (I should read the paper; maybe this has been addressed.) -- Mark H. Wood, Lead System Programmer mw...@iupui.edu Asking whether markets are efficient is like asking whether people are smart. pgpJcR3QKfU0G.pgp Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: STEED - Usable end-to-end encryption
On Mon, Oct 17, 2011 at 05:50:42PM -0600, Aaron Toponce wrote: [snip] At any rate, I would love to see more client-to-client encryption in email. I've always wondered if there could be an OTR approach to mail, somehow, so people don't need to generate and manage their own sets of keys, as that seems to be the largest hinderence to widespread adoption. The only thing the user should do, is compose the mail, hit send, and everything is handled with very minimal user interaction. Three can keep a secret, if two of them are dead. If your computer holds the ultimate secret, anyone who can control the computer can use that secret. The user *must* be actively involved. We can remove *needless* complexity, but security could be said to be the art of *introducing* specific complexity that's a lot worse for the attacker than it is for you. It can't be automagical. Anyway, key generation is already automated. All you have to do is (1) choose to employ crypto, and (2) supply a passphrase that you can remember. There are even methods and tools to help you do (2)! To be secure without being involved in the process is an unreasonable expectation which can never be met. We need to teach our kids to expect to protect themselves online the same way we teach them to look both ways before crossing the street. Probably at the same age. Otherwise they'll grow up to believe the hype that you can buy security the same as buying bread. -- Mark H. Wood, Lead System Programmer mw...@iupui.edu Asking whether markets are efficient is like asking whether people are smart. pgprweGHynQeD.pgp Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: STEED - Usable end-to-end encryption
On 18/10/11 16:00, Mark H. Wood wrote: I don't see why the ISP has to be the entity providing DNS lookup. Because it is the e-mail address of the recipient you look up; that's all the data you have in this scenario. Thus, for me you would look up a key corresponding to user peter at the domain digitalbrains.com. The only logical place to look for that without further information is in the domain digitalbrains.com, which is under control of the e-mail provider. ISP here means e-mail provider, by the way, perhaps that is the confusion. Unless I'm the one confused ;). Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at http://wwwhome.cs.utwente.nl/~lebbing/pubkey.txt ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: STEED - Usable end-to-end encryption
In fact to my knowledge outside of webmail and inside private email (so drop companies, universities, schools) it's usual to configure your own MUA, with the help of instructions from your ISP. Well, so we need to convince them to change those instructions. Yes and this is what I said: It's useful to get the ISP involved. But it's not necessary -- Google doesn't provide instructions on how to enable send receipts in Outlook. I would guess that there are users out there using gmail that use read receipts. So yes, definitely get the ISPs involved. But let's not rely on them. A good, easy-to-use (easy-to-install) plugin for Outlook '03/'07/'10 should go a long way to getting people to use end-point encryption. The main value I would see in the STEED proposal is to make this whole process easier for the user. The UI for keyring management and crypto operations will be the most important part to making that work, and the ISPs don't have to help out there (modulo webmail which isn't even end-point). -- PGP: A0E4 B2D4 94E6 20EE 85BA E45B 63E4 2BD8 C58C 753A PGP: 2C23 EBFF DF1A 840D 2351 F5F5 F25B A03F 2152 36DA ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: STEED - Usable end-to-end encryption
On Tue, 18 Oct 2011 15:30, jer...@jeromebaum.com said: In fact to my knowledge outside of webmail and inside private email (so drop companies, universities, schools) it's usual to configure your own MUA, with the help of instructions from your ISP. Well, so we need to convince them to change those instructions. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: STEED - Usable end-to-end encryption
... We can remove *needless* complexity, but security could be said to be the art of *introducing* specific complexity that's a lot worse for the attacker than it is for you. It can't be automagical. Anyway, key generation is already automated. All you have to do is (1) choose to employ crypto, and (2) supply a passphrase that you can remember. There are even methods and tools to help you do (2)! To be secure without being involved in the process is an unreasonable expectation which can never be met. We need to teach our kids to expect to protect themselves online the same way we teach them to look both ways before crossing the street. Probably at the same age. Otherwise they'll grow up to believe the hype that you can buy security the same as buying bread. So let's put up traffic lights to help them and employ some crossing guards to teach them the first steps until they are old enough to make their own decisions. Or put another way, we could make the process automagical until the user has enough experience with the tool to do this themselves. The question is whether we should -- false sense of security, reasonable threat model, etc. Either way, it's better to encrypt to key that you _think_ is the recipient's key than to none at all*, because now your passive attacker is helpless. * Under a specific set of threat models. -- PGP: A0E4 B2D4 94E6 20EE 85BA E45B 63E4 2BD8 C58C 753A PGP: 2C23 EBFF DF1A 840D 2351 F5F5 F25B A03F 2152 36DA ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: STEED - Usable end-to-end encryption
I don't see why the ISP has to be the entity providing DNS lookup. The one I use won't even allocate me a static address, let alone accept RRs from me to serve out to others. I'm not sure I'd trust them to get it right and *keep* it right anyway. I should clarify. An email provider is also an ISP, and I was referring to the email-provider type of ISP. But yes I agree that we shouldn't trust the ISPs too much and that's why I keep saying we shouldn't rely solely on them. If the ISPs won't cooperate, maybe the antivirus vendors would. They're already in the data security business, already have an extensive network presence, and already get money from me to help me secure my information assets. Build enrollment into the AV product or provide a separate setup tool. It should be simple. This I'm not too sure if we can trust an AV vendor more or less than an ISP. That's the problem with making these decisions for the user: We're pushing the trust onto them, just like the CA root certificates in most browsers. The trust decision should be with the user. In a user-friendly way. Also, I want world peace. -- PGP: A0E4 B2D4 94E6 20EE 85BA E45B 63E4 2BD8 C58C 753A PGP: 2C23 EBFF DF1A 840D 2351 F5F5 F25B A03F 2152 36DA ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: STEED - Usable end-to-end encryption
On Tue, 18 Oct 2011 16:30, pe...@digitalbrains.com said: Because it is the e-mail address of the recipient you look up; that's all the data you have in this scenario. Thus, for me you would look up a key corresponding to user peter at the domain digitalbrains.com. The only logical Right. That is the whole point. We want to make keys invisible. You can't explain easily why you need a separate public key if you already have an email address. Thus from the user's point of view the email address is the public key. digitalbrains.com, which is under control of the e-mail provider. ISP here means e-mail provider, by the way, perhaps that is the confusion. Unless I'm the one Sure, email provider. However for most users this is identical to the ISP: First of all they need a connection to the Internet. Unless you spend a lot of money for the connections you will get an email address along with your user identification for DSL access. The email provider sets up something like /etc/aliases for the mail address and some of them also enter records into their zone file with the mailbox name for anti-spam protocols. They need to enter yet another record into a zone file to allow a key lookup by the assigned mail address. Salam-Shalom, Werner ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: STEED - Usable end-to-end encryption
On Tue, 18 Oct 2011 15:42, mw...@iupui.edu said: To be secure without being involved in the process is an unreasonable expectation which can never be met. We need to teach our kids to expect to protect themselves online the same way we teach them to look We did this for about 15 years - without any success. If you look at some of the studies you will see that you can't teach that stuff to non-techies - sometimes not even to engineers. Let's compare it using an example from the not too far past: It has been claimed that most VCRs used to blink 12:00 but nevertheless they were sold and did what they should do: tape movies. This is similar to mail: Everyone is able to send and receive mail but most are not able to (set the VCR timer|encrypt the mails). Newer features in VCRs set the clock automatically and make the timer setting task much easier in the user interface (e.g. by selecting the title of the movie you want to tape from a electronic program magazine). This user experience is what we need to aim for. both ways before crossing the street. Probably at the same age. That is easy because we have learned over thousands of years to use our senses to be safe. Our senses for those small electrons are not as matured as the the others. Why should they - we know about them only for maybe 300 years. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: STEED - Usable end-to-end encryption
Even webmail. It is easy to write a browser extension to do the crypto stuff. Installing browser extensions is even easier than installing most other software. I'd make it a point of discussion whether it's still webmail proper then. But you could also use Javascript, Java or Flash, so yes this is doable for webmail. I wouldn't trust my ISP to deliver the encryption module though. It kind of defeats the end-point part in end-point encryption. As your average user I have no way to verify the module and nobody can vouch for it as it's dynamically updated by my ISP. So a fixed, open-source browser extension is really the only way to do this properly. How is this different from installing an MUA (given that a browser extension is often a full-blown piece of software with full rights to the system)? With the webmail argument and since webmail is probably majority access for private email, it's looking more important to work with the ISPs, but I stand by my point of not building this on a single pillar. -- PGP: A0E4 B2D4 94E6 20EE 85BA E45B 63E4 2BD8 C58C 753A PGP: 2C23 EBFF DF1A 840D 2351 F5F5 F25B A03F 2152 36DA ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: STEED - Usable end-to-end encryption
On 10/18/2011 11:58 AM, Werner Koch wrote: We did this for about 15 years - without any success. If you look at some of the studies you will see that you can't teach that stuff to non-techies - sometimes not even to engineers. As a data point from 2005: I was teaching computer literacy at the University of Iowa. The first day of class I asked the 35 students which of them brought a computer of any kind to class. Three people raised their hands: they all said they brought laptops. When I asked how many brought cell phones, all 35 raised their hands. The only people who thought cell phones were computers were the three who brought laptops. I then asked if a game console (XBox, Playstation, take your pick) was a computer. The class was almost evenly split: half said yes, on account of how you could surf the web with it. Half said no, because you can't write a Word document with it. Admittedly, this is not a representative sample of college students. That said, I think it's an informative anecdote. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: STEED - Usable end-to-end encryption
On Tue, 18 Oct 2011 16:35, jer...@jeromebaum.com said: operations will be the most important part to making that work, and the ISPs don't have to help out there (modulo webmail which isn't even end-point). Even webmail. It is easy to write a browser extension to do the crypto stuff. Installing browser extensions is even easier than installing most other software. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: STEED - Usable end-to-end encryption
On Mon, Oct 17, 2011 at 05:50:42PM -0600, Aaron Toponce wrote: .snip.. At any rate, I would love to see more client-to-client encryption in email. I've always wondered if there could be an OTR approach to mail, somehow, so people don't need to generate and manage their own sets of keys, as that seems to be the largest hinderence to widespread adoption. the user should do, is compose the mail, hit send, and everything is Not true. The greatest hindrance to widespread adoption is the phrase I often hear...I've got nothing to hide It drives me up a wall. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users -- Bob Holtzman If you think you're getting free lunch, check the price of the beer. Key ID: 8D549279 signature.asc Description: Digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: STEED - Usable end-to-end encryption
* Robert Holtzman hol...@cox.net [111018 21:43, mID 20111018185035.gb4...@cox.net]: The greatest hindrance to widespread adoption is the phrase I often hear...I've got nothing to hide It drives me up a wall. +1 Martin smime.p7s Description: S/MIME cryptographic signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: STEED - Usable end-to-end encryption
http://g10code.com/docs/steed-usable-e2ee.pdf Skimmed over this. You say that you need ISP support to get the system adopted (for the DNS-based distribution). Wouldn't that hinder adoption? hotmail and the like still don't support POP3 or IMAP in a standard account, and they are still popular options. So obviously email providers aren't the right place to look to get a technology deployed, especially one that hinders their access to email. How about an opportunistic approach? This email should include the following header: OpenPGP: id=C58C753A; url=https://jeromebaum.com/pgp The MUA could recognize a header like this one and remember that there's a certificate -- so the next email we send will be encrypted. The first email couldn't be, but is that worse than no encryption at all? Basically something like Strict-Transport-Security. What do you think? Like I said this is based on a quick skimming of the paper. Sorry about the long message. -- PGP: A0E4 B2D4 94E6 20EE 85BA E45B 63E4 2BD8 C58C 753A PGP: 2C23 EBFF DF1A 840D 2351 F5F5 F25B A03F 2152 36DA ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: STEED - Usable end-to-end encryption
On 2011-10-17 23:00, Ben McGinnes wrote: On 18/10/11 7:32 AM, Aaron Toponce wrote: I like the idea, but how are you setting the header? I see you're using Thunderbird, and I don't believe that setting that header is part of Enigmail. Further, it appears your mail isn't signed. Just curious. I don't sign every email I send. I tend to plug in my reader whenever I sign something important, and then sign other mails while the reader is plugged in. The reader wasn't plugged in in this case. No, but it is part of Thunderbird: http://kb.mozillazine.org/Custom_headers The process is even less straight forward than using Enigmail would be for end users. So enabling _Enigmail_'s Send 'OpenPGP' header option is difficult now? Anyway, my point wasn't that we should use Enigmail. It wasn't that we should use the OpenPGP header. It was that we should have an optional header that unobtrusively says by the way, I support encryption. However the OpenPGP header is a pretty good start as Enigmail supports it. Whatever solution we use, it should be default-on. Plus we should use key-servers as not everyone has a place to upload the key, and it'd be pretty involved for a dumb end-user. -- PGP: A0E4 B2D4 94E6 20EE 85BA E45B 63E4 2BD8 C58C 753A PGP: 2C23 EBFF DF1A 840D 2351 F5F5 F25B A03F 2152 36DA ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: STEED - Usable end-to-end encryption
On Mon, 17 Oct 2011 20:25:04 +0200 Jerome Baum articulated: Skimmed over this. You say that you need ISP support to get the system adopted (for the DNS-based distribution). Wouldn't that hinder adoption? hotmail and the like still don't support POP3 or IMAP in a standard account, and they are still popular options. Are you sure about that? http://windowslivehelp.com/solution.aspx?solutionid=a485233f-206d-491e-941b-118e45a7cf1b -- Jerry ✌ gnupg.u...@seibercom.net _ Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: STEED - Usable end-to-end encryption
http://windowslivehelp.com/solution.aspx?solutionid=a485233f-206d-491e-941b-118e45a7cf1b Wow, since 2009 (I haven't checked back in a while -- stay clear of strange hosts like hotmail). I think the point still stands though. I don't think email providers are the right place to look for end-to-end encryption technology: Aren't we trying to _not_ involve the provider in the encryption (end-point)? Is it in the interest of the provider that you encrypt your emails? etc. -- PGP: A0E4 B2D4 94E6 20EE 85BA E45B 63E4 2BD8 C58C 753A PGP: 2C23 EBFF DF1A 840D 2351 F5F5 F25B A03F 2152 36DA ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: STEED - Usable end-to-end encryption
On 10/17/11 5:21 PM, Jerome Baum wrote: So enabling _Enigmail_'s Send 'OpenPGP' header option is difficult now? Unquestionably, indubitably, beyond doubt, *yes*. You are assuming a level of computer literacy that is beyond 95% of the computing public. Remember, under 10% of the computing public knows how to use Ctrl-F to search through a document. [*] Speaking personally about Enigmail, I routinely get complaints about Enigmail being broken from people who don't have GnuPG installed, complaints about Enigmail being too hard to uninstall from people who have never installed Enigmail (they thought that just by downloading the .XPI the file was installed automatically), and so forth. All of us on the Enigmail user-help team have these stories. I'll eat my own hat if the GnuPG devs don't have their own. Users aren't stupid, not by any stretch of the imagination. Some of the worst offenders have been obviously intelligent people who have been extremely irate about Enigmail, on the grounds that I'm a freaking *physician* and I can't understand this, how do you expect regular users to?! To them, all I can say is -- it's not about innate intelligence: it's about whether you possess the skill of computer literacy. We live in an immensely technological society, and very few people are computer literate. [*] http://www.theatlantic.com/technology/archive/2011/08/crazy-90-percent-of-people-dont-know-how-to-use-ctrl-f/243840/ ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: STEED - Usable end-to-end encryption
On 2011-10-17 23:59, Robert J. Hansen wrote: On 10/17/11 5:21 PM, Jerome Baum wrote: So enabling _Enigmail_'s Send 'OpenPGP' header option is difficult now? [long rant about Enigmail] The emphasis was clearly on Enigmail, not on whether it's difficult or not. If you hadn't misquoted me you might have included the bit where I said this should be default-on (obviously so the user doesn't have to configure it). -- PGP: A0E4 B2D4 94E6 20EE 85BA E45B 63E4 2BD8 C58C 753A PGP: 2C23 EBFF DF1A 840D 2351 F5F5 F25B A03F 2152 36DA ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: STEED - Usable end-to-end encryption
On Mon, Oct 17, 2011 at 08:25:04PM +0200, Jerome Baum wrote:
How about an opportunistic approach? This email should include the
following header:
OpenPGP: id=C58C753A;
url=https://jeromebaum.com/pgp
The MUA could recognize a header like this one and remember that there's
a certificate -- so the next email we send will be encrypted. The first
email couldn't be, but is that worse than no encryption at all?
Basically something like Strict-Transport-Security.
What do you think?
Like I said this is based on a quick skimming of the paper. Sorry about
the long message.
For the uninitiated, http://josefsson.org/openpgp-header/ explains the
'OpenPGP' header, and it's syntax. This was something new to me. A bit of
additional research on whether or not this was something Mutt was planning
on adding led me to http://marc.info/?l=mutt-devm=110227240028896w=2.
I've added it with my_hdr OpenPGP id=${pgp_sign_as}\;url= The only
question remaining, for me, is whether or not it should be X-OpenPGP or
OpenPGP as the header field name. I've heard various positions on this,
but nothing definitive.
At any rate, I would love to see more client-to-client encryption in email.
I've always wondered if there could be an OTR approach to mail, somehow,
so people don't need to generate and manage their own sets of keys, as that
seems to be the largest hinderence to widespread adoption. The only thing
the user should do, is compose the mail, hit send, and everything is
handled with very minimal user interaction.
--
. o . o . o . . o o . . . o .
. . o . o o o . o . o o . . o
o o o . o . . o o o o . o o o
signature.asc
Description: Digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
