Encrypted web mail
31 views
Skip to first unread message
Uri Even-Chen
Aug 15, 2015, 5:48:43 AM8/15/15
to pytho...@python.org, django...@googlegroups.com, speedy-mai...@googlegroups.com
To Python, Django and Speedy Mail Software developers,
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.
Thanks,
Uri.
| Uri Even-Chen |
 | Phone: +972-54-3995700 Email: u...@speedy.net Website: http://www.speedysoftware.com/uri/en/     |
Pedro
Aug 15, 2015, 8:33:30 AM8/15/15
to django...@googlegroups.com
Hello Uri,
what you want is completely possible, but demands you to understand some concepts of cryptography. To make your server completely safe against court orders or anyone that have access to it, including yourself, you need to encrypt and decrypt the emails at client side. For this you may use some public-key cryptosystem and store all user's public keys at your server (they are not secret). Probably the best option for you is to use PGP. If the clients run in Javascript you can use OpenPGP.js for this. It is very easy to use and you won't need to know anything about how to implement a secure cipher.----------
Pedro AlvesMestrando em Ciência da Computação
Universidade Estadual de Campinas
--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users...@googlegroups.com.
To post to this group, send email to django...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAMQ2MsHDNLRuth59FRAtXwMXY14LyMUibxHCFxZswdD7Jw4oyg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Uri Even-Chen
Aug 15, 2015, 8:49:45 AM8/15/15
to django...@googlegroups.com, pytho...@python.org, speedy-mai...@googlegroups.com
Thanks Pedro, actually I understand cryptography and I agree with you. Sonebody replied to me off-list and wrote me about ProtonMail, actually they are doing exactly what I wanted (I think), so maybe I will try to cooperate with them and/or use their open source source code. Anyway thanks for the feedback!
Uri.
| Uri Even-Chen |
| | Phone: +972-54-3995700 Email: u...@speedy.net Website: http://www.speedysoftware.com/uri/en/ |
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CACW_pa3PGDg0b6zNQertR0NXHZPDd75oh1ZcVU12SXy9aN%3DmiQ%40mail.gmail.com.
Sergiy Khohlov
Aug 15, 2015, 10:38:59 AM8/15/15
to django-users
Looks like it is not hard to change postfix maildrop agent to crypt mail passing to user dir. But some work should be done at mua side.
Anyway it is not a question of django
15 серп. 2015 15:49 "Uri Even-Chen" <u...@speedy.net> пише:
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAMQ2MsFooQD32PiVxQOFy8jOT8J0bL_16Y8E3_MY%3DA_LhV0-GQ%40mail.gmail.com.
Dennis Lee Bieber
Aug 15, 2015, 12:36:52 PM8/15/15
to django...@googlegroups.com, pytho...@python.org
On Sat, 15 Aug 2015 12:47:17 +0300, Uri Even-Chen <u...@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.
>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 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).
--
Wulfraed Dennis Lee Bieber AF6VN
wlf...@ix.netcom.com HTTP://wlfraed.home.netcom.com/
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
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.
>read the user's mail except the user himself. Is it possible? When I had
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 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.
>
(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).
--
Wulfraed Dennis Lee Bieber AF6VN
wlf...@ix.netcom.com HTTP://wlfraed.home.netcom.com/
Uri Even-Chen
Aug 16, 2015, 2:10:41 AM8/16/15
to django...@googlegroups.com, pytho...@python.org, speedy-mai...@googlegroups.com
Hi Dennis,
On Sat, Aug 15, 2015 at 7:35 PM, Dennis Lee Bieber <wlf...@ix.netcom.com> wrote:
On Sat, 15 Aug 2015 12:47:17 +0300, Uri Even-Chen <u...@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.
I think ProtonMail 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.
Avraham Serour
Aug 16, 2015, 4:19:22 AM8/16/15
to django-users
no, passwords shouldn't be encrypted, you should store hashes, just use the django default auth app
--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users...@googlegroups.com.
To post to this group, send email to django...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAMQ2MsF73cgTQ-dyZ2thF%2BGsLqSjjAQDTDjo4OLbNY%2Bdid%3DLgg%40mail.gmail.com.
Uri Even-Chen
Aug 16, 2015, 9:17:22 AM8/16/15
to django...@googlegroups.com
On Sun, Aug 16, 2015 at 11:18 AM, Avraham Serour <tov...@gmail.com> wrote:
no, passwords shouldn't be encrypted, you should store hashes, just use the django default auth app
Yes, I meant storing the hash in the database and not the password.
Uri.
Sergiy Khohlov
Aug 16, 2015, 10:28:50 AM8/16/15
to django-users
Anyway this not solve Uri problem. Man in black ask about access to the user private data. Problem with auth by hash? It is not a problem. Reset password generates new hash.
Let's imagine:
Bad guy hack into system and has all data. passwords hash other tricks hosting at the server side is not a problem. This guy has time to sort out all parts. One good way is use public and private keys private is stored at user PC only. Retrieving crypted data to user PC and uncrypt at client side is a way to solve this problem.
If some market is for this task it is possible to start, but not for free.
Software part requires 6-8k$. But you should check some rules with lawyer.
16 серп. 2015 16:16 "Uri Even-Chen" <u...@speedy.net> пише:
--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users...@googlegroups.com.
To post to this group, send email to django...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAMQ2MsEn4ZeUjNVoXOX0AEe67_q_SLH-bz57_nrPS%3DwgFhz2Pg%40mail.gmail.com.
Reply all
Reply to author
Forward
0 new messages