Antoine Beaupré <anar...@debian.org> writes: > On 2016-03-16 11:37:51, micah wrote: >>> Yes. In fact, I think it compromises the "encryption", "PFS" and >>> "deniability" aspects of the protocol, to be more specific. >> >> It doesn't cryptographically. >> >> You cannot take an OTR conversation that has been logged through an >> external means and prove cryptographically that this conversation >> actually happened. > > I stand corrected on the "deniability" aspect, but the PFS and > encryption aspects still stand, and they are, in my opinion, critical.
I hate to be annoying about this... but I dont think you are correct. The OTR encryption property only ensures that nobody can read your messages if they are listening on the wire... nothing else... it never promises that someone isn't reading over your shoulder, copying and pasting things from the screen, taking a photo, etc. PFS/FS is the same, it has to do with the on-the-wire replayability of captured traffic, it doesn't ensure anything beyond that. OTR is really from the time the plaintext is in the libotr library and up to the libotr library on the other hand. if you log an OTR encrypted message you'll still have those properties because it's the same as on the wire. if you log cleartext, you might loose deniability (yet to be proven). Obviously logging is bad, and I dont want to argue that this shouldn't be done, I know someone who was screwed because of cleartext logs that happened on the other side of the conversation (not his side). The deniability you get is just being able to say that "anyone" could have made those messages, because OTR rekeys and broadcasts the old key... but this is a blurry line, its obviously safer not to log for real deniability. personally, I think that having a switch for logging, having it default, and even having something that indicates to the other party are all good things, but make no mistake, these are not things that OTR is trying to solve with those properties.
