On Fri 2015-04-17 10:53:01 -0400, Greg Reagle wrote:
> Then why don't the docs explain this? I assume that the docs are also
> for people who want security but don't understand the details of
> cryptography? How can the docs claim that "They are also confident that
> no one watching the network can read their messages" [1]. That seems
> like an obviously false statement to me.
This statement clarifies the threat model that OTR tries to address.
the attacker is someone "watching the network", up to and including
sitting on the chat server itself and able to see its transit.
The threat model necessarily excludes (doesn't address) some forms of
attackers, including attackers who have control over the end user's
device to the point where they can grab the user's secret key.
I'm unaware of any cryptosystem that can defend message confidentiality
against any attacker that has full control over the endpoint device on
which the message is ultimately read.
> This seems like a major and serious vulnerability to me, and it seems
> like the weakest link in the chain. I am not criticizing OTR for having
> this vulnerability because, as Daniel wrote, all cryptosystems have it.
> But not emphasizing it in the docs seems really deceptive to me.
I don't think it's deceptive to state your expected adversaries
explicitly, or to leave out details about the adversaries you
can't/don't address. complete endpoint security is a long and deep
topic, and probably out of scope for the OTR web site.
> It is really not that hard for Mallory to get Bob's private key. If he
> leaves his computer unattended for 5 minutes Mallory could stick in a
> USB flash drive and copy his private key.
OTR does not defend against this attack. Locking your computer when you
are away from it defends against this attack.
> Or Mallory could use spyware or some sort of other hacking.
Again, if your endpoint is compromised, all the software running on it
is suspect.
> Or Bob might include his private key file in an online backup or
> Dropbox not realizing it.
This is an excellent point, and it is something that i think the OTR web
site (and OTR plugins) could make more prominent in the documentation.
Users need to know which pieces of data they should *not* back up in the
clear to somewhere outside of their control. At the moment, i think
most OTR implementations probably stash their secret key material
someplace like ~/.irssi/otr/otr.key (this is for the IRSSI OTR plugin),
unprotected by a passphrase. Users probably don't want this backed up,
but they might not know where it is stored at all, or how to exclude it
from their normal backups.
In parallel, this is a good argument for using backup services that
encrypt the data before upload to protect it against the operator of the
backup service itself. In that case, there would be no need to exclude
the key from backup.
--dkg
_______________________________________________
OTR-users mailing list
OTR-users@lists.cypherpunks.ca
http://lists.cypherpunks.ca/mailman/listinfo/otr-users
