Re: [Mailman-Developers] [GSoC14] Full Anonymization Project Idea
Hi I am a prospective Gsoc'15 applicant. I found the Anonymous mailing list idea for project interesting. While researching about the same I found this thread. I have a queries regarding this : Can't we keep our encryption application away from the site admins by creating an interface between sender and the switchboard ,what I'm trying to imply here is, can't we process the encryption before the mail goes to switchboard or server for further processing.
Let say,the email sent by the sender gets into the interface first where it strips out the message header and encrypts the email address, so when the email goes to the switchboard it is already modified, does not contain original sender's address but has the details about where it is to be sent.
Now when the receiver sends the reply then the email gets to the list moderator and after that it passes through the same interface which now decrypts it to the original address and forwards it after encrypting the sender's address. Stephen J. Turnbull writes:
In general, what is missing from these "anonymization" proposals are use cases, user stories which display the reasons for anonymity and the definition of anonymity (for example, should repeated posts from a given subscriber have the same "From" field or not?) For example, the following organizations want a "fully anonymized" list:
- An Alcoholics Anonymous meeting.
- A therapy group for battered wives led by a professional therapist (whose identity is known to all, and who knows all realspace identities -- but maybe can't match them to list identities).
- A corporate whistleblower/suggestion box.
- A terrorist cell. (I'm not suggesting we should *care* about serving these people well, and maybe we should try *not* to serve them -- it's an intellectual exercise.)
- A tax evaders users' group. (ditto)
How do their needs differ? How are they similar? How well does your proposal serve their needs? I'm not too serious about that specific list, individual students may or may not have experience and knowledge of those use cases. But I would strongly prefer to work with a student who thinks about these issues *explicitly* and *concretely* in terms of use cases. In particular, it may seem obvious that we can't protect the subscriber database against the site admin/root, but then we have to give up on use case 3 above. Or do we?
These are hard, *hard*, HARD questions. Even Bruce Schneier (if you don't know who he is, find out!) might not get the answers at first try. I don't ask you to get the hard ones at all! But sometimes the answer is obvious from just asking the question (use case 3 vs root access), so you'd best ask some of those easy ones. :-)
About this specific proposal:
Kshitij Gupta writes:
As I understand, we can do this in the following ways:
- For each subscriber on the mailing list generate a random encryption
and
decryption key, which will be store in the database.
If the keys never leave the database, why not use symmetric encryption? Why do different subscribers need different keys?
If they do leave the database, how are they distributed? How is the distribution protected from the standard attacks (eg, man in the middle)?
- Everytime user sends the mail we can encrypt the email to a hash
which
will then be used as the pseudo id for the user. To do this we can
either
use salt (as in time) to ensure a new email id is generated everytime
I don't understand why you would ever want this, let alone why there is a use case common enough to be worth implementing in Mailman.
That doesn't mean there isn't any, but please explain.
or without salt which equivalently fixes a single id for the user. 3. From the email we can cleanup headers, converting the users timezone
to
a standard UTC timezone.
You also probably need to handle Message-ID specially.
- We can also hash the users original email id and append it as a
signature to sign the mail, ensuring the authenticity of mail in a conversation.
That's not how digital signatures are done, and only those with access to a descryption key can check authenticity.
- For replies, the person replying can respond to the message, the
address will then be decrypted by matching against the list of all decryption keys and matching the digest of the mail id for additional security and forwarding it to the intended user.
I'm not sure I understand the "additional security part." In any case, if you have a "digest", why not use that as a unique key into the user database, so that the actual decryption becomes an authentication, and only needs to be done once?
The above steps (in my understanding):
- Will allow users to anonymously post to mailing lists.
Except that the site admin knows where to find each user. The site admin had better be the only entity with such access.
- Ensure nobody can pretend to be someone else in a thread via the
personal salt.
But how about spoofing subscriptions? Do we care about that? What if a user happens to know the address of another user, and spoofs that?
- Allow users to communicate in threads and reply to each other.
- Use a constant space for users in the database, at the cost of
matching
against multiple decryption keys and then checking against the hashed
email.
Is constant space really an issue?
Look forward to some feedback and hope to contribute to the mailman community.
[1]- https://code.launchpad.net/apparmor-profile-tools , however the
code
was recently merged into the branch upstream at: https://code.launchpad.net/apparmor where development continues.
Regards, Kshitij Gupta _______________________________________________ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/stephen%40xemacs....
Security Policy: http://wiki.list.org/x/QIA9
Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org
Security Policy: http://wiki.list.org/x/QIA9
Rashi Karanpuria writes:
Can't we keep our encryption application away from the site admins by creating an interface between sender and the switchboard ,what I'm trying to imply here is, can't we process the encryption before the mail goes to switchboard or server for further processing.
Site admins (the people who install the software) have to have root privileges. Nothing can be hidden from them. The only way to protect your data from them is to send it encrypted with a key they don't have.
But it's hard to imagine why you would use an anonymous list, or any mailing list, hosted by people you don't trust enough to give them the keys, to send mail to people you know and trust well enough to give them those keys. The basic motivation for encrypted lists is avoiding the key distribution problem, either because it's annoying or because the point of the list is that the subscribers are not to know each other at all.
I think I might be missing a point here. What i understand is, we don't need to protect the data in the message from the admin, but the information about sender of the data from the list admin as well as other subscribers of that list (i.e. the email address and other details in header which includes traces of sender's identity). In an anonymous list we don't aim to build trust relationships or import the hierarchy maintained in an establishment where we put the decisive power and right to know everything in the hands of the admin/root. We aim at discussing things sharing the bitterest of views unbiased from personal identities and positions in an establishment.
A possible use case might be:
- A suggestion and discussion list of an organisation where subscribers
could post all problems and issues and slackenings in the organisation's structure and authorities without worrying about their names being involved. They could even use the list in decision making process, internal polling or maybe even reviewing the system.
- Similarly a psychiatrist's list where patients can discuss there issues
and arrive at mutual solutions with help from the doctor, while bonding with people of their kind. Some syndromes are not cured beacuse of social stigmas that could find a possible solution in such lists.
Rashi Karanpuria writes:
Can't we keep our encryption application away from the site admins by creating an interface between sender and the switchboard ,what I'm
trying
to imply here is, can't we process the encryption before the mail goes
to
switchboard or server for further processing.
Site admins (the people who install the software) have to have root privileges. Nothing can be hidden from them. The only way to protect your data from them is to send it encrypted with a key they don't have.
But it's hard to imagine why you would use an anonymous list, or any mailing list, hosted by people you don't trust enough to give them the keys, to send mail to people you know and trust well enough to give them those keys. The basic motivation for encrypted lists is avoiding the key distribution problem, either because it's annoying or because the point of the list is that the subscribers are not to know each other at all.
Rashi Karanpuria writes:
A possible use case might be:
- A suggestion and discussion list of an organisation where
subscribers could post all problems and issues and slackenings in the organisation's structure and authorities without worrying about their names being involved. They could even use the list in decision making process, internal polling or maybe even reviewing the system.
If the president of the company doesn't have root, he can fire whoever does and replace them with somebody who will do what he says. Not going to work unless you trust the site admin *and* her boss. Note that they also have access to MTA and firewall logs, and so probably know who made connections when.
- Similarly a psychiatrist's list where patients can discuss there
issues and arrive at mutual solutions with help from the doctor, while bonding with people of their kind. Some syndromes are not cured beacuse of social stigmas that could find a possible solution in such lists.
If you don't trust your psychiatrist and her office staff, you are in very big trouble. No need to protect the list from the list admin, but you might want to protect it from the site admin if the list is hosted by a third party.
Security (including privacy) of electronic communication is brain- breaking hard stuff. Note: I am *not* saying "don't do this project" -- past experience shows that the level of coding needed for proof of concept is about right for GSoC -- but you need to be very careful not to make overly optimistic claims that you're actually protecting anyone's privacy.
When I was mentoring Abhilash's project in 2013, I thought quite carefully about possible applications and came to the conclusion that the crypto was useless. One use-case you might find interesting was student evaluations of classes they took. Either the students trust the faculty not to peek, or they don't, and in the latter case there just isn't any sure way to protect the students' privacy *and* at the same time prevent ballot-box stuffing (ie, the students need to authenticate). The traditional method (check ids at the door and give one marksheet to each student to fill in, then have a student collect the marksheets and deliver them to the Faculty Development Office) is much closer to airtight.
OTOH, if you *do* have that level of trust in the list and site admins, encrypting traffic does make sense (otherwise mail is an open book to relaying hosts), and encrypting with your key is as good a signature as encrypting a hash of the message (the usual "digital signature").
participants (2)
-
Rashi Karanpuria -
Stephen J. Turnbull