Re: [liberationtech] My design to implement PGP in commercial email system
In the light of Lavabit, Silent Circle both shut down, someone needs to invent a end to end encrypted email soon -- Liberationtech is a public list whose archives are searchable on Google. Persistent violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] My design to implement PGP in commercial email system
We have it already. People for some reason don't want to use it. Part of its usability, part of it is laziness. But it can be done. On Aug 10, 2013, at 9:32 AM, Percy Alpha percyal...@gmail.com wrote: In the light of Lavabit, Silent Circle both shut down, someone needs to invent a end to end encrypted email soon -- Liberationtech is a public list whose archives are searchable on Google. Persistent violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech -- Liberationtech is a public list whose archives are searchable on Google. Persistent violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] My design to implement PGP in commercial email system
OK, so let's say someone needs to invent a USABLE end to end encrypted email soon. On Fri, Aug 9, 2013 at 4:40 PM, Andrew Lewis m...@andrewlew.is wrote: We have it already. People for some reason don't want to use it. Part of its usability, part of it is laziness. But it can be done. On Aug 10, 2013, at 9:32 AM, Percy Alpha percyal...@gmail.com wrote: In the light of Lavabit, Silent Circle both shut down, someone needs to invent a end to end encrypted email soon -- @kylemaxwell -- Liberationtech is a public list whose archives are searchable on Google. Persistent violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] My design to implement PGP in commercial email system
*I don't see how this scheme would work with contextual based advertisements? Or maybe you are talking about a premium subscription service that does not rely on advertisements for revenue. (?)* From OP, The only downside of this approach is that email providers are not able to filter spam or provide related Ads based on email content. Even this might be solved in the future because of private outsourced computation Private outsourced computation will let you search Google without revealing to Google what you searched for(thus getting the Ads). However, this cryptography function is still in experiment, for now, Google might provide Geo-location ads or just show ads from users' search history,etc -- Liberationtech list is public and archives are available via Google. Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] My design to implement PGP in commercial email system
On Mon, Jul 29, 2013 at 05:19:27PM -0700, Percy Alpha wrote: On Mon, Jul 29, 2013 at 10:58 AM, Randolph D. rdohm...@gmail.com wrote: uh? why commercial? http://bitmail.sf.net is open source. Regards Again, I want common people to use PGP. I want every communication to be Then, put GPG gateways into mail servers. encrypted. You recommendation is great but a client app(especially an app designed by cryptographer, no offense) just will not attract common users. A simple, familiar web mail that can provide PGP in default without any extra configuration is the only way to push it to the mass.(And even after everyone adopts it, the mass will still no nothing about PGP) -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] My design to implement PGP in commercial email system
Percy Alpha(PGP https://en.greatfire.org/contact#alt) GreatFire.org Team how does a browser know if this is the first time or the second one? What I mean is: 1) Alice wants to send an mail to Bob. It's the first time, so she retrieves B's key and signs it 2) in a different session (ie: in a different browser) Alice sends an email to Bob. It retrieves B's key, but Mallory does mitm and gives a different key; let's call M(B) that key; there is no signature on it, so A thinks it's the first time, and accepts the key and signs it. at that point, the mitm even received a signature from A! The signed contact list should be protected and authenticated the same way as user's secret key is protected and authenticated. So in a different session, A will download the contact list first and match the existing ones. You said earlier using password to encrypt the secret key and verify it is not a good security practice. But I assume there's some function in cryptography that can verify the authenticity of the encrypted secret key since you know the encrypted password but Google doesn't. Also, the application code (that is, javascript) is provided by Google itself, so the second time it could just be changed to behave in a completely different way without Alice ever noticing it; this can be done both by google and by a mitm. I guess a browser plug-in(open-source) is necessary. Anyone can download without logging in; this prevents targeted attack. (say plug-in is distributed through Mozilla and signed by Google). The distribution page should not be able to distinguish individual users. Users is subject to compromised code the first time he installs the plug-in. (Advanced users can simply put the installer file on flash disk, if he wants to use a new computer.) We still put some minimal trust on Google. But Google should not have any existing criteria to decide which users to spy on while the scheme will quickly unveil if Google tries to spy on all new users. But even Google talk sometimes requires pulg-in, I think the additional click is relatively easy and pain-free even for common users. I think I missed the point; could you clear out an example of attack that is possible now, but won't be possible anymore using the scheme you proposed? I want to find a way such that email provider cannot read your emails. Or at least make such action both technically and legally unfeasible(only possible to spy on an existing users, if Google is forced to spy on all new users and the existing user is downloading the plug-in again ). -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] My design to implement PGP in commercial email system
On Tue, 30 Jul 2013 21:06:43 -0700, Percy Alpha percyal...@gmail.com wrote: --===7521353976464463127== Content-Type: multipart/alternative; boundary=089e0158b34caca15804e2c6db70 --089e0158b34caca15804e2c6db70 Content-Type: text/plain; charset=UTF-8 Percy Alpha(PGP https://en.greatfire.org/contact#alt) GreatFire.org Team how does a browser know if this is the first time or the second one? Hi, I don't see how this scheme would work with contextual based advertisements? Or maybe you are talking about a premium subscription service that does not rely on advertisements for revenue. (?) -- Waitman Gobble San Jose California USA +1.5108307875 -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] My design to implement PGP in commercial email system
On 29/07/2013 01:45, Percy Alpha wrote: key and plain public key to Google. Because Google doesn't know your password, Google cannot server you a fake secret key, even though you download your encrypted secret key from Google every time you login. this is using encryption (your password) to provide verification. I don't believe this is safe (even if I can't came up with a way to break it). When the users tries to send an email to another Gmail user B for the first time, B's public key will be downloaded from Google and signed by A. Any subsequent times when A tries to send email to B, A will not only download B's key from Google but also verifies the authenticity of B's key. This prevents MITM attack if Google is hacked or forced by law enforcement. (For advanced users, Google can present the option to manually verify the public key for the first email. ) but what if Gmail provides a fake key for B? Why should you automatically trust that key? Also, I miss the point of signatures: A signs B's key, but noone cares about that signature in that scheme. Am I missing something? I think that this scheme relies on trust on your email provider and on https not being MITM-ed, which I think is not common between people that want to use PGP. -- boyska -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] My design to implement PGP in commercial email system
uh? why commercial? http://bitmail.sf.net is open source. Regards 2013/7/29 Percy Alpha percyal...@gmail.com PGP is great for privacy but rather hard to use for common users. I came up with a simple design that can be implement in main-string email system while preserving the usability. Take Gmail for example. First Google should adopt zero-knowledge password proof for its account while asking users to choose recovery questions. To recover password, users will answer 3 secret questions and the password is encrypted with the answers. This ensures that users can recover password and get old emails back without letting Google know the password. Then when users first log into Gmail, the browser will generate the keypair using JavaScript locally and encrypt the secret key with login password(with PBKDF2, etc). Then the user will upload the encrypted secret key and plain public key to Google. Because Google doesn't know your password, Google cannot server you a fake secret key, even though you download your encrypted secret key from Google every time you login. When the users tries to send an email to another Gmail user B for the first time, B's public key will be downloaded from Google and signed by A. Any subsequent times when A tries to send email to B, A will not only download B's key from Google but also verifies the authenticity of B's key. This prevents MITM attack if Google is hacked or forced by law enforcement. (For advanced users, Google can present the option to manually verify the public key for the first email. ) To send email between Gmail and Hotmail, Google should be able to request a Hotmail user's public key from Microsoft server. To prevent spam, Microsoft should return some random public key for non-exist account and perhaps always return this fake public key for this non-exist account to prevent cross reference. The only downside of this approach is that email providers are not able to filter spam or provide related Ads based on email content. Even this might be solved in the future because of private outsourced computation. Percy Alpha(PGP https://en.greatfire.org/contact#alt) GreatFire.org Team -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] My design to implement PGP in commercial email system
To boyska, but what if Gmail provides a fake key for B? Why should you automatically trust that key? Also, I miss the point of signatures: A signs B's key, but noone cares about that signature in that scheme. Am I missing something? At first time, B's public key will be downloaded from Google and signed by A.. Any subsequent times, A also verifies the authenticity of B's key. So Google can provide a fake key only at the first time. I said For advanced users, Google can present the option to manually verify the public key for the first email. Google cannot MITM any subsequent communications because fake key of B is not signed by A and will be detected. I think that this scheme relies on trust on your email provider and on https not being MITM-ed, which I think is not common between people that want to use PGP. I'm targeting the common people(email provider to the common people),not the existing PGP users. Now, only people who are technical savvy can make the conscious decision to use PGP. My design is totally transparent to the users and can greatly boost the privacy of common communications without users even knowing what PGP is. Those high profile users can keep using the desktop version. -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] My design to implement PGP in commercial email system
On Mon, Jul 29, 2013 at 10:58 AM, Randolph D. rdohm...@gmail.com wrote: uh? why commercial? http://bitmail.sf.net is open source. Regards Again, I want common people to use PGP. I want every communication to be encrypted. You recommendation is great but a client app(especially an app designed by cryptographer, no offense) just will not attract common users. A simple, familiar web mail that can provide PGP in default without any extra configuration is the only way to push it to the mass.(And even after everyone adopts it, the mass will still no nothing about PGP) -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
[liberationtech] My design to implement PGP in commercial email system
PGP is great for privacy but rather hard to use for common users. I came up with a simple design that can be implement in main-string email system while preserving the usability. Take Gmail for example. First Google should adopt zero-knowledge password proof for its account while asking users to choose recovery questions. To recover password, users will answer 3 secret questions and the password is encrypted with the answers. This ensures that users can recover password and get old emails back without letting Google know the password. Then when users first log into Gmail, the browser will generate the keypair using JavaScript locally and encrypt the secret key with login password(with PBKDF2, etc). Then the user will upload the encrypted secret key and plain public key to Google. Because Google doesn't know your password, Google cannot server you a fake secret key, even though you download your encrypted secret key from Google every time you login. When the users tries to send an email to another Gmail user B for the first time, B's public key will be downloaded from Google and signed by A. Any subsequent times when A tries to send email to B, A will not only download B's key from Google but also verifies the authenticity of B's key. This prevents MITM attack if Google is hacked or forced by law enforcement. (For advanced users, Google can present the option to manually verify the public key for the first email. ) To send email between Gmail and Hotmail, Google should be able to request a Hotmail user's public key from Microsoft server. To prevent spam, Microsoft should return some random public key for non-exist account and perhaps always return this fake public key for this non-exist account to prevent cross reference. The only downside of this approach is that email providers are not able to filter spam or provide related Ads based on email content. Even this might be solved in the future because of private outsourced computation. Percy Alpha(PGP https://en.greatfire.org/contact#alt) GreatFire.org Team -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
