[OTR-users] Re: OTR-users digest (regarding logging)

[Jake Appelbaum]

> Message: 1
> Subject: Re: [OTR-users] Gaim plugin and archiving
> From: Didier Frick <didier at dfr.ch>
> To: Paul Wouters <paul at cypherpunks.ca>
> Cc: Ian Goldberg <ian at cypherpunks.ca>, otr-users at lists.cypherpunks.ca
> Date: Sun, 07 May 2006 17:07:50 +0200
> 
> Le samedi 06 mai 2006  19:28 +0200, Paul Wouters a crit :
> > 
> > People want want to keep logging, especially if they are using disk encryption
> > for their homedir (eg FileVault or something else). So please don't change
> > logging without telling the user. eg Make it an explicit option in the OTR
> > menu or something?
> 
> I don't think disk encryption preserves forward secrecy, and the issue
> becomes the one I outlined in my last message: even if _you_ do it
> correctly, how can you be sure that your correspondents "get it" and do
> it correctly as well....
> 
> So I still contend that the only way to preserve forward secrecy without
> too many gaping holes that you can't control is to never log any OTR
> conversation in any way.
> 

Obviously disk encryption doesn't preserve forward secrecy. In theory it
can keep thing secret under certain threats. (I'm not talking about the
pile of junk that is filefault, that's a lost cause.)

I agree that you probably shouldn't log conversations but I don't think
this is easy to accomplish.

In defense of loggers, Gaim logs aren't cryptographically sound. My gaim
logs are just lines in a text file and anyone can add anything they like
to them. If I'm away from the computer and they do it quickly enough, it
would be possible to inject an entire conversation into my log files. 

I can inject data into log files that looks like it was sent by a given
party when it was not. Here's an example:

cat /home/error/.gaim/logs/aim/error23five/ioerrortype23/2006-05-07.150151.txt
Conversation with ioerrortype23 at 2006-05-07 15:01:51 on error23five
(aim)
(15:01:53) error23five: hi
(15:02:02) io error type23: hey
(15:02:16) error23five: This is a GAIM log message being forged
(15:02:21) io error type23: how so?
(15:03:29) error23five: I will now copy your sent message to me, change
the time stamp and paste two responses with different words to see how
the text is formatted in the logs.
(15:03:40) io error type23: You've put words in my mouth.
(15:04:10) io error type23: You're so smart and sexy, will you be mine?

The last three messages were actually a single message. All that's
required to make the log look realistic is knowing the remote logging
format with regard to dates and their system time. Pretty easy.

Given the fact that OTR cannot control logging all of the time it seems
difficult and perhaps a really good place for a mistake.

Perhaps the plugin could contain a data leek flag that says: "Would you
like to let people know you're logging this automatically?" And perhaps
the client would say: "It appears that the remote party is logging
automatically." And perhaps there could be a way to request logging was
disabled. And likely, no one would enable that flag because it's a
privacy nightmare.

Practically speaking this would be unenforceable. Some clients already
ship with logging enabled by default. I believe the user friendly adium
for Mac OS X does this. I believe that people using the OTR proxy would
also be out of the reach of such possible plugin features.

Personally, I would ask the remote party to disable logging manually. It
seems best because they learn how to do such a thing in their client of
choice. Regardless of OTR, disk encryption or what have you, anyone can
log messages in a way that could possibly be used against you. And
either way, logging or not, you have to trust the person you're talking
with to some degree.

-- 
Jake Appelbaum <jacob at appelbaum.net>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 155 bytes
Desc: This is a digitally signed message part
URL: <http://lists.cypherpunks.ca/pipermail/otr-users/attachments/20060507/b860c15b/attachment.pgp>