Encrypted web mail

[Uri Even-Chen]

Hi Dennis,



On Sat, Aug 15, 2015 at 7:35 PM, Dennis Lee Bieber <wlfraed at ix.netcom.com>
wrote:

> On Sat, 15 Aug 2015 12:47:17 +0300, Uri Even-Chen <uri at speedy.net>
> declaimed the following:
>
> >To Python, Django and Speedy Mail Software developers,
> >
> >Is it possible to make Speedy Mail encrypted? I want mail to be encrypted
> >on the server, and only the user will be able to read his/her mail. The
> >user's password will be encrypted on the server and nobody will be able to
>
>         Most systems I know of don't store the password on the server in
> the
> first place. They store a one-way hash generated from the password
> (possibly using a randomly generated salt that is also saved with the hash
> -- that is, rather than just hash "password" into "hashstring", they hash
> "saltpassword" into "otherhash" and prepend the "salt" -> "saltotherhash".
> When user comes to connect later, they match the user name in the password
> database, extract the "salt" from "saltotherhash", attach it to the
> password given by the user, generate the hash, and see if it matches the
> rest of the saved hash). The hash value is only used for matching purposes,
> not for any subsequent processing -- it is not a cryptography key, nor is
> any cryptography key used to produce it.
>
>
Thanks for the feedback. Actually the passwords on my webmail in 2000 to
2005 were not encrypted, but I agree with you that passwords should be
always encrypted.



> >read the user's mail except the user himself. Is it possible? When  I had
>
>         How do you intend to handle new inbound email? After all, the
> sender of
> the email sure won't know about any user encryption key -- that means you
> have to have the encryption key stored on your server associated with the
> recipient username, so that you can encrypt inbound email before putting it
> into the user's mailbox... Do you also intend to encrypt the header
> information or just the body of the message?
>
>         A public key system MIGHT support that, in that the public key --
> used
> to "send to" the recipient is only used to encrypt the data, and can be
> stored on your server (in the same username/password account file). The
> private (decryption) key would have to be stored on the user's computer and
> never provided to your server machine -- and you'd need some way to send
> individual encrypted messages to the user where they are decrypted on their
> computer, NOT ON the server. You'd also need to be able to identify which
> messages are new, read, deleted -- if the mailbox is encrypted, this likely
> means each message is a file within the mailbox, since you can't do things
> like mark and compress an MBOX (all mail is in one file with a special
> header marking the start of a message) file without corrupting the
> encryption stream.
>
>         If, at anytime, the decryption key is on the server, you have lost
> the
> security you claim to be striving for -- as any court ordered system could
> just patch in a packet sniffer and wait for your user to connect, capture
> the password, and capture the decryption key if it is sent to the server to
> retrieve mail (though they don't even need it at that point -- they could
> just capture the decrypted contents being sent to the user... TLS/SSL
> sessions may alleviate that problem, but it does mean having certificates
> to initiate the TLS session keys). If the packets are TLS encrypted, they
> can require one to patch into the server at the point where the contents
> are converted back to plain text and capture the traffic.
>
>         Of course, this now means the user has to carry around a "keyring"
> that
> can be accessed by any computer used to read the email (since the
> decryption key can not be on the server, if they read email from an android
> tablet they need to have the key installed on the tablet; they also need it
> on their desktop if they use it to access the server; on their phone if it
> has a browser, etc.).
>
>         A Javascript client is probably going to be rather slow at
> decrypting
> the emails -- but you may not be able to install a compiled Java encryption
> package on all the clients out there (you'd have to have something for iOS,
> something for Android, for Linux, Macintosh, and Windows -- though the
> latter three might be able to use the same core Java code).
>
>         We've taken care of inbound email. What were your plans for
> outgoing
> email? You can't encrypt that as it is going to other systems and other
> users who are not part of your server and don't expect to see encrypted
> stuff. You could perhaps store the already sent messages using the same
> public key, but you can't do that with in-work drafts stored on the server
> prior to being sent (at least, not without requiring them to pass from the
> server to the client for decryption and then back to the server in
> plain-text for delivery -- deleting the draft copy and saving an encrypted
> sent copy)
>
> I think ProtonMail <https://protonmail.ch/> is doing something similar to
what I want, so maybe I'll check what they are doing. I also want the
user's mail to be searchable, like Gmail.


> >I believe a user's mail is something personal, like his thoughts. I don't
> >want the police to read my mail and it's similar to reading my thoughts.
> >
>         And the solution, in my mind, is to not use a central mail
> repository
> (no webmail client, nor even an IMAP client) and always do a
> delete-from-server when the POP3 client fetches the mail (and the server
> should do some sort of secure scrub of the deleted file area on disk). That
> way the only mail that will ever be found on the server is the mail the
> user hasn't logged in to retrieve yet, or outgoing messages that the SMTP
> daemon hasn't gotten around to forwarding to the destination (and deleting
> once the receiving server ACKs the message). (This also reduces the storage
> needed by the server, and likely speeds access to mail if using MBOX format
> as it doesn't have to scan humongous files).
>

Yes, but then the mail is on your computer, and the police can enter your
house and take it (but you can encrypt it on your computer). There is no
way to have 100% security against the police.

Uri.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20150816/4c67de8c/attachment.html>