Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Messages as-in mail #55

Open
o-jasper opened this issue Apr 3, 2014 · 0 comments
Open

Messages as-in mail #55

o-jasper opened this issue Apr 3, 2014 · 0 comments

Comments

@o-jasper
Copy link

o-jasper commented Apr 3, 2014

This would be nice.

I think it is also nice if email clients can display it aswel, by having a local POP/SMTP server. That way the user doesnt at all need to change his workflow to use it, just install, make it run, and point the email client at it.

It could be transferred the following ways:

  1. If receiver(R) is online, just send the data.
  2. In trusting E, give: {R adress, encrypt(S→R,data)}, and send to E, who then knows who you talk to, but not what you said.
  3. In not trusting E,F, but willing to assume they are not co-operating, then give E: {F adress, encrypt(S→F,{R adress,encrypt(S→R,data)})}
    AFAICT it is 'tor on tor'. (wait, can F infer from encrypted data that it is S→R encrypted?)

Programs could have different policies. 1. always makes sense. If have a trusted guy run a server for you somewhere, or just trusted friends, you can use 2. (of course even trusted friends might not have secure setups! Otherwise use 3. You might start circuits as soon as the message is made or just before closing the program. E doesnt need to know if the case is 2 or 3, or in which step he is.

However, it isnt sigil proof? Many accounts → better shot at being both E and F. The adress list could help, for any somewhat vigilent user. (dont know enough about tor itself, they have to worry about the same problem)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant