From ian at cypherpunks.ca  Wed Aug  3 14:30:27 2005
From: ian at cypherpunks.ca (Ian Goldberg)
Date: Wed, 3 Aug 2005 14:30:27 -0400
Subject: [OTR-users] Re: [OTR-announce] Flaw in OTR Protocol (with workaround!)
In-Reply-To: <e692861c050725140421e5488b@mail.gmail.com>
References: <E1Dwhse-0003Go-Mv@smtp.paip.net> <e692861c050725140421e5488b@mail.gmail.com>
Message-ID: <20050803183027.GE1007@smtp.paip.net>

On Mon, Jul 25, 2005 at 05:04:27PM -0400, Gregory Maxwell wrote:
> AIM is annoying enough without the overhead of OTR, especially if you
> paste in HTML things, but with OTR it is quite painful.
> 
> Support for compression would help this quite a bit, but I understand
> the desire to avoid compression to make it more trivial to demonstrate
> a modification attack.  ... Since it would still take a lot of work to
> find an AES key that produced the 'right' keystream output given the
> logged traffic. (i.e. in the very likely case that some 'trustable'
> logging device has been installed in the network).
> 
> In any case, message splitting really should be implemented and it
> would be nice if the protocol had support so that there needed to be
> only 1x OTR overhead for a N way split message.
> 
> It would be nice if the splitting mechanism supported joining messages
> of varying length, so that message breaks could be placed randomly to
> frustrate traffic analysis and it would be nice if the maximum message
> length could be controlled based on some feedback from GAIM about what
> it guesses the IM services' rate limit might be.

We talked about this back in December:
http://www.cypherpunks.ca/pipermail/otr-dev/2004-December/000005.html

I'd like to revisit it, though.  The problem the sample implementation
discovered was that the AIM network's bot-flooding-prevention triggered
when the fragments of the message were sent in quick succession.

It turns out gaim makes a half-assed attempt to queue messages that are
being sent too fast, but it contains sections like this:

    /*
     * And now for the meager attempt to force transmit
     * latency and avoid missed messages.
     */
    if ((cur->conn->lastactivity + cur->conn->forcedlatency) >= time(NULL)) {
	/*
	 * XXX should be a break! we don't want to block the
	 * upper layers
	 *
	 * XXX or better, just do this right.
	 *
	 */
	sleep((cur->conn->lastactivity + cur->conn->forcedlatency) - time(NULL));
    } 
    /* XXX this should call the custom "queuing" function!! */
    aim_tx_sendframe(sess, cur);

But in any event, libotr could simply do something like this:

- Callback the app to ask it what the appropriate maximum packet size
  should be for the given buddy.  The app may return a size in bytes, or
  0 for "no fragmentation".
- The app's inject_message callback must deal with any network-specific
  bandwidth limits.


Having fragmentation work would simplify a number of things, so I think
we might try again.  There's still the big issue of how to determine
what the correct maximum packet size should be, and I don't know of a
good way to do that (see the above thread).  Hardcoding some values
is a kludgy workaround.  Making those values user-configurable at least
allows user fixes if the networks change.  Any other suggestions?

   - Ian


From gmaxwell at gmail.com  Wed Aug  3 14:51:31 2005
From: gmaxwell at gmail.com (Gregory Maxwell)
Date: Wed, 3 Aug 2005 14:51:31 -0400
Subject: [OTR-users] Re: [OTR-announce] Flaw in OTR Protocol (with workaround!)
In-Reply-To: <20050803183027.GE1007@smtp.paip.net>
References: <E1Dwhse-0003Go-Mv@smtp.paip.net>
	 <e692861c050725140421e5488b@mail.gmail.com>
	 <20050803183027.GE1007@smtp.paip.net>
Message-ID: <e692861c050803115161ac86fe@mail.gmail.com>

On 8/3/05, Ian Goldberg <ian at cypherpunks.ca> wrote:
> Having fragmentation work would simplify a number of things, so I think
> we might try again.  There's still the big issue of how to determine
> what the correct maximum packet size should be, and I don't know of a
> good way to do that (see the above thread).  Hardcoding some values
> is a kludgy workaround.  Making those values user-configurable at least
> allows user fixes if the networks change.  Any other suggestions?

*IF* we figure out how to survive the ratelimiting and if we are able
to catch rejected messages:
Path MTU discovery. 

We startout with a hard set maximum... as high as the network protocol
allows or ... just some very long limit presumed limit. When as small
message makes its way through, we increase our minimum guess MTU to
match that message size. Whenever a message is rejected due to being
too large, we reduce our presumed MTU to one under the rejected size,
then we fragment into midway between the know good size and the known
not good. If it passes we up our known good, if it fails we reduce our
presumed MTU and continue the process.

To make the process non painful for the user we'd need to be able to
intercept those errors on both sides.. and to make it work we need to
differentiate between 'too large' errors and other errors.

Thats about all I can guess, just beyond making it manual.. which
would also work (esp if we provided some sane defaults) and would not
require heroic coding.



From ian at cypherpunks.ca  Wed Aug  3 14:59:04 2005
From: ian at cypherpunks.ca (Ian Goldberg)
Date: Wed, 3 Aug 2005 14:59:04 -0400
Subject: [OTR-users] Re: [OTR-announce] Flaw in OTR Protocol (with workaround!)
In-Reply-To: <e692861c050803115161ac86fe@mail.gmail.com>
References: <E1Dwhse-0003Go-Mv@smtp.paip.net> <e692861c050725140421e5488b@mail.gmail.com> <20050803183027.GE1007@smtp.paip.net> <e692861c050803115161ac86fe@mail.gmail.com>
Message-ID: <20050803185904.GG1007@smtp.paip.net>

On Wed, Aug 03, 2005 at 02:51:31PM -0400, Gregory Maxwell wrote:
> On 8/3/05, Ian Goldberg <ian at cypherpunks.ca> wrote:
> > Having fragmentation work would simplify a number of things, so I think
> > we might try again.  There's still the big issue of how to determine
> > what the correct maximum packet size should be, and I don't know of a
> > good way to do that (see the above thread).  Hardcoding some values
> > is a kludgy workaround.  Making those values user-configurable at least
> > allows user fixes if the networks change.  Any other suggestions?
> 
> *IF* we figure out how to survive the ratelimiting and if we are able
> to catch rejected messages:
> Path MTU discovery. 

Yes, of course.  The problem is exactly that we're *not* able to catch
rejected messages, as far as I know.  If you send a message that's too
large into the AIM network, it will happily accept it.  At some unknown
time in the future, you *may* receive an error message that says "you
recently sent a message that was too big".  Your buddy will simply
receive nothing.

And then there's the problem that gaim plugins don't even get to *see*
that error message at all, as useless as it may be.

   - Ian


From CLAY at BROKENLADDER.COM  Thu Aug 11 17:06:12 2005
From: CLAY at BROKENLADDER.COM (CLAY SHENTRUP)
Date: Thu, 11 Aug 2005 14:06:12 -0700
Subject: [OTR-users] single pass deniable authentication
Message-ID: <1123794372.9459.240499859@webmail.messagingengine.com>


While we're on the subject of potential ways to improve OTR in
its next stage, I came across a remarkably simple single pass
deniable authentication scheme here:
http://www.google.com/url?sa=t&ct=res&cd=1&url=http%3A//eprint.i
acr.org/2005/056.pdf&ei=LLH7Qoi-Mcv0YLzNkPMM
The basis for the system is incredibly simple.  We'll call
Alice's public and private keys A and a respectively, and
likewise for Bob; B and b.
Alice wants to send a message to Bob, so she creates a random
value, x, and sends the pair the pair ( Z, x ) to Bob, where Z =
a(B(x)).
Bob can then calculate x from Z as x = b(A(Z)), verifying
Alice's RSA digital signature on x, essentially.  However, Bob
cannot prove to someone else that Alice created this pair,
because he could create a value Z, and calculate x as x =
b(A(Z)).  The rest is just protocol to make the system feasible
and robust.  This system sounds so simple, though I've never
heard of it before.  The fact that it can operate in a single
pass might be helpful for offline messages that you still want
to be secure and authenticated, but repudiable.
Thoughts?  Opinions?
-END-
"Extending the war into Iraq would have incurred incalculable human and political
costs. We would have been forced to occupy Baghdad and, in effect, rule Iraq. The
coalition would instantly have collapsed, the Arabs deserting in anger and other
allies pulling out as well. Exceeding the U.N.'s mandate would have destroyed the
precedent of international response to aggression we hoped to establish. Had we
gone the invasion route, the U.S. could still be an occupying power in a bitterly
hostile land."

-- From "Why We Didn't Remove Saddam"
by George Bush [Sr.] and Brent Scowcroft, Time Magazine, 1998

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cypherpunks.ca/pipermail/otr-users/attachments/20050811/0c1eb17c/attachment.html>

From ian at cypherpunks.ca  Fri Aug 12 08:18:58 2005
From: ian at cypherpunks.ca (Ian Goldberg)
Date: Fri, 12 Aug 2005 08:18:58 -0400
Subject: [OTR-users] single pass deniable authentication
In-Reply-To: <1123794372.9459.240499859@webmail.messagingengine.com>
References: <1123794372.9459.240499859@webmail.messagingengine.com>
Message-ID: <20050812121858.GE1007@smtp.paip.net>

On Thu, Aug 11, 2005 at 02:06:12PM -0700, CLAY SHENTRUP wrote:
> The fact that it can operate in a single
> pass might be helpful for offline messages that you still want
> to be secure and authenticated, but repudiable.
> Thoughts?  Opinions?

But it doesn't have perfect forward secrecy: if Bob's long-term
(for use while he's offline) keys are compromised, all past messages
to Bob get revealed.

There are lots of ways to do one-pass repudiable authentication; we
talked about one (ring signatures) in the original OTR paper.

   - Ian


From tor at algae-world.com  Wed Aug 17 15:02:56 2005
From: tor at algae-world.com (tor)
Date: Wed, 17 Aug 2005 12:02:56 -0700
Subject: [OTR-users] Jabberd, AdiumX and TOR(reason for the crossposting..)
Message-ID: <430389E0.5060906@algae-world.com>

Hi all,
         This was actually applicable to both groups. I have 
successfully been able to do the following

1. log in to a jabber server via adiumX using TOR as a transport and OTR 
encryption after logging.

2. run the c2s script of jabberd as a hidden service with a .onion address 

I am running the above under OpenBSD-current.

Steps needing to be done

torify(no that script doesnt work here) the jabberd2/resolver and the 
jabberd2/s2s components
I am thinking libnylon and LD_LIBRARY_PATH or something similar here.
this should allow jabberd2 to operate as a totally location hidden service.



I will update the tor wiki upon success.. question is has anyone else 
done this??
the OTR crowd was CCed on this due to the OTR/Adium sucess..


    a tor operator




From peter at palfrader.org  Wed Aug 17 16:57:19 2005
From: peter at palfrader.org (Peter Palfrader)
Date: Wed, 17 Aug 2005 22:57:19 +0200
Subject: [OTR-users] Re: Jabberd, AdiumX and TOR(reason for the crossposting..)
In-Reply-To: <430389E0.5060906@algae-world.com>
References: <430389E0.5060906@algae-world.com>
Message-ID: <20050817205719.GD1275@opium.palfrader.org>

On Wed, 17 Aug 2005, tor wrote:

> Hi all,
>         This was actually applicable to both groups. I have 
> successfully been able to do the following
> 
> 1. log in to a jabber server via adiumX using TOR as a transport and OTR 
> encryption after logging.
> 
> 2. run the c2s script of jabberd as a hidden service with a .onion address 

> I will update the tor wiki upon success.. question is has anyone else 
> done this??

Yes, I've successfully run 2 hidden jabber servers (1.4.x), and had
clients connect to them and chat to each other.

For the name resolution problem I chose to work around it by assigning
some special IPs from the link local ranges to my servers in etc/hosts
and mapping them back to the .onion names using tor's MapAddress.  For a
really decentralized system one would of course have to solve that issue
correctly.

Peter
-- 
 PGP signed and encrypted  |  .''`.  ** Debian GNU/Linux **
    messages preferred.    | : :' :      The  universal
                           | `. `'      Operating System
 http://www.palfrader.org/ |   `-    http://www.debian.org/


From shatadal at vfemail.net  Tue Aug 30 01:57:31 2005
From: shatadal at vfemail.net (Shatadal)
Date: Tue, 30 Aug 2005 00:57:31 -0500
Subject: [OTR-users] OTR on USB
Message-ID: <4313F54B.5010608@vfemail.net>

Can anybody instruct me (or point to instructions) on how to install OTR
for gaim on a USB flash drive?

Thanks.


From shatadal at vfemail.net  Tue Aug 30 03:46:38 2005
From: shatadal at vfemail.net (Shatadal)
Date: Tue, 30 Aug 2005 02:46:38 -0500
Subject: [OTR-users] OTR on USB flash drive
In-Reply-To: <1125386793.4514.241762973@webmail.messagingengine.com>
References: <4313F54B.5010608@vfemail.net> <1125386793.4514.241762973@webmail.messagingengine.com>
Message-ID: <43140EDE.9020700@vfemail.net>

CLAY SHENTRUP wrote:
> Gaim is automatically going to put it's settings in some path relative
> to its location.  To have it use the key on the flash drive, I'd think
> you'd actually have to store it on the drive, or at least run it from
> there (possibly as a sym link to a real exe).  You could probably even
> put the bins for different platfroms (linux, windows, etc.) on the flash
> drive and run it from the drive on whatever system you plug it into.
> 
> Maybe someone else can come up with something better, but this is all I
> can think of.

Does that mean I can install OTR for windows directly onto the flash
drive and then configure gaim (also on the flash drive) to use this
particular OTR plugin (as explained by Adam Zimmermann on the website)?

> 
> Clay
> 
> 
> "Extending the war into Iraq would have incurred incalculable human and political
> costs. We would have been forced to occupy Baghdad and, in effect, rule Iraq. The
> coalition would instantly have collapsed, the Arabs deserting in anger and other
> allies pulling out as well. Exceeding the U.N.'s mandate would have destroyed the
> precedent of international response to aggression we hoped to establish. Had we
> gone the invasion route, the U.S. could still be an occupying power in a bitterly
> hostile land."
> 
> -- From "Why We Didn't Remove Saddam"
> by George Bush [Sr.] and Brent Scowcroft, Time Magazine, 1998
> 
> ----- Original message -----
> From: "Shatadal" <shatadal at vfemail.net>
> To: otr-users at lists.cypherpunks.ca
> Date: Tue, 30 Aug 2005 00:57:31 -0500
> Subject: [OTR-users] OTR on USB
> 
> Can anybody instruct me (or point to instructions) on how to install OTR
> for gaim on a USB flash drive?
> 
> Thanks.
> _______________________________________________
> OTR-users mailing list
> OTR-users at lists.cypherpunks.ca
> http://lists.cypherpunks.ca/mailman/listinfo/otr-users
> 
> 


From shatadal at vfemail.net  Wed Aug 31 00:14:01 2005
From: shatadal at vfemail.net (Shatadal)
Date: Tue, 30 Aug 2005 23:14:01 -0500
Subject: [OTR-users] OTR on USB flash drive
In-Reply-To: <1125418977.19000.241799152@webmail.messagingengine.com>
References: <4313F54B.5010608@vfemail.net>   <1125386793.4514.241762973@webmail.messagingengine.com>   <43140EDE.9020700@vfemail.net> <1125418977.19000.241799152@webmail.messagingengine.com>
Message-ID: <43152E89.8030303@vfemail.net>

CLAY SHENTRUP wrote:
> If you install it to the flash drive, it should work exactly as if you
> had installed it to a regular drive.  My only fear is that I seem to
> recollect that Gaim puts some settings files in a directory outside of
> where it was installed, in "Documents and Settings/user".  If Gaim runs
> from the flash drive, but expects to find needed files in this area on
> your "primary" drive (the one windoze is running from) then of course
> that could cause a problem.  I would just try it.  It seems like it
> would just take minutes.
> 

It seems that in the end it was a pretty simple solution. On the gaim
sourceforge site there are instructions to run from
https://sourceforge.net/docman/display_doc.php?docid=28372&group_id=137399

While copying c:\program files\gaim to <flash drive>:\Gaim I also copied
gaim-otr.dll onto the USB drive. I also copied the profile directory at
C:\Documents and Settings\<User Name>\Application Data\.gaim to <flash
drive>:\Gaim which also copied the private keys stored in otr.private_key

On starting gaim, I noticed that the OTR plugin was functional in gaim
and it could recognise the private keys in otr.private_key

On starting an IM session I clicked on the OTR button on the IM window
and it attempted to start a private conversation like when it does when
I start gaim and otr from the hard drive.

However does anybody think that using the OTR plugin for gaim in such a
fashion could break the implementation in some way?

Thanks.


From ian at cypherpunks.ca  Wed Aug 31 13:38:28 2005
From: ian at cypherpunks.ca (Ian Goldberg)
Date: Wed, 31 Aug 2005 13:38:28 -0400
Subject: [OTR-users] OTR on USB flash drive
In-Reply-To: <43152E89.8030303@vfemail.net>
References: <4313F54B.5010608@vfemail.net> <1125386793.4514.241762973@webmail.messagingengine.com> <43140EDE.9020700@vfemail.net> <1125418977.19000.241799152@webmail.messagingengine.com> <43152E89.8030303@vfemail.net>
Message-ID: <20050831173828.GV13525@smtp.paip.net>

On Tue, Aug 30, 2005 at 11:14:01PM -0500, Shatadal wrote:
> However does anybody think that using the OTR plugin for gaim in such
> a fashion could break the implementation in some way?

With the caveat that I don't really know how the Windows gaim stuff
works very well, I'd suggest you double-check that when you receive a
new fingerprint from someone, it gets stored in the otr.fingerprints
file *on the USB drive*.  Other that that, I don't know that there'd be
any problems.

   - Ian


From wine at henkis.net  Fri Aug  5 04:12:43 2005
From: wine at henkis.net (wine at henkis.net)
Date: Fri, 5 Aug 2005 10:12:43 +0200
Subject: [OTR-users] GAIM OTR plugin problems
Message-ID: <20050805081243.GA25009@henkis.net>

Fellow OTR-users!

I have compiled version 2.0.2 of the GAIM OTR plugin on my Solaris x86 machine.
It compiles and installs ok, but i dont see it in the plugin list in GAIM.

The library was found by GAIM:
access("/opt/sfw/lib/gaim/gaim-otr.la", F_OK)   = 0
access("/opt/sfw/lib/gaim/gaim-otr.so", F_OK)   = 0
access("/opt/sfw/lib/gaim/gaim-otr.so", F_OK)   = 0
xstat(2, "/opt/sfw/lib/gaim/gaim-otr.so", 0x08046628) = 0
resolvepath("/opt/sfw/lib/gaim/gaim-otr.so", "/opt/sfw/lib/gaim/gaim-otr.so", 1023) = 29
open("/opt/sfw/lib/gaim/gaim-otr.so", O_RDONLY) = 6
mmap(0x00010000, 4096, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_ALIGN, 6, 0) = 0xCECF0000
mmap(0x00010000, 122880, PROT_NONE, MAP_PRIVATE|MAP_NORESERVE|MAP_ANON|MAP_ALIGN, -1, 0) = 0xCD500000
mmap(0xCD500000, 50787, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_TEXT, 6,
0) = 0xCD500000
mmap(0xCD51C000, 4309, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_INITDATA, 6, 49152) = 0xCD51C000
munmap(0xCD50D000, 61440)                       = 0
memcntl(0xCD500000, 12308, MC_ADVISE, MADV_WILLNEED, 0, 0) = 0
close(6)

I do not however find it in the process map, other librarys are found:
...
CD590000       4K rwx--    [ anon ]
CD5A0000       4K r-x--  /opt/sfw/lib/gaim/ssl.so
CD5B0000       4K rwx--  /opt/sfw/lib/gaim/ssl.so
CD5C0000       4K r-x--  /opt/sfw/lib/gaim/ssl-nss.so
CD5D0000       4K rwx--  /opt/sfw/lib/gaim/ssl-nss.so
CD5E0000     216K r-x--  /usr/lib/libgcrypt.so.1.5.1
CD625000      12K rwx--  /usr/lib/libgcrypt.so.1.5.1
CD628000       4K rwx--  /usr/lib/libgcrypt.so.1.5.1
CD630000       4K rwx--    [ anon ]
CD640000     340K r-x--  /usr/lib/libgnutls.so.6.0.5
CD6A4000      20K rwx--  /usr/lib/libgnutls.so.6.0.5
CD6B0000       8K r-x--  /opt/sfw/lib/gaim/ssl-gnutls.so
CD6C1000       4K rwx--  /opt/sfw/lib/gaim/ssl-gnutls.so
...


Any suggestions? Debuging tips?

Regards
Henrik