You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
If receiver(R) is online, just send the data.
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.
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)
The text was updated successfully, but these errors were encountered:
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:
R
) is online, just send the data.E
, give:{R adress, encrypt(S→R,data)}
, and send toE
, who then knows who you talk to, but not what you said.E
,F
, but willing to assume they are not co-operating, then giveE
:{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 isS→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
andF
. The adress list could help, for any somewhat vigilent user. (dont know enough about tor itself, they have to worry about the same problem)The text was updated successfully, but these errors were encountered: