Search Mailing List Archives


Limit search to: Subject & Body Subject Author
Sort by: Reverse Sort
Limit to: All This Week Last Week This Month Last Month
Select Date Range     through    

[liberationtech] My design to implement PGP in commercial email system

Randolph D. rdohm321 at gmail.com
Mon Jul 29 10:58:35 PDT 2013


uh? why commercial? http://bitmail.sf.net is open source. Regards

2013/7/29 Percy Alpha <percyalpha at 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 companys at stanford.edu or changing your settings at
> https://mailman.stanford.edu/mailman/listinfo/liberationtech
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.stanford.edu/pipermail/liberationtech/attachments/20130729/8e2b42f5/attachment.html>


More information about the liberationtech mailing list