From ryan.bourque at gmail.com  Mon Jul  4 11:44:03 2005
From: ryan.bourque at gmail.com (Ryan Bourque)
Date: Mon, 4 Jul 2005 10:44:03 -0500
Subject: [OTR-users] gaim-otr hangs on generating key
In-Reply-To: <20050630223251.GA8008@smtp.paip.net>
References: <ea61314e05063007044a94ef14@mail.gmail.com>
	 <20050630191824.GX8008@smtp.paip.net>
	 <ea61314e05063013397966b8d6@mail.gmail.com>
	 <20050630223251.GA8008@smtp.paip.net>
Message-ID: <ea61314e050704084476a24f25@mail.gmail.com>

This is a terminal server, so there are a lot of clients being used on
the server.  Once we re-imaged the machine, everything started working
just fine as usual.

On 6/30/05, Ian Goldberg <ian at cypherpunks.ca> wrote:
> The strace (particularly this part:
> > open("/dev/random", O_RDONLY)           = 9
> > select(10, [9], NULL, NULL, {3, 0})     = 1 (in [9], left {3, 0})
> > read(9, "8U>\311\320\25\337\347\375U\356\340\276\35\376\311\355"...,
> > 300) = 85> select(10, [9], NULL, NULL, {3, 0})     = 1 (in [9], left
> > {3, 0})
> > read(9, "\332\10\202Zi\274\344b\6\305\230/T\31\252d\354\317\326"...,
> > 215) = 85> select(10, [9], NULL, NULL, {3, 0})     = 1 (in [9], left
> > {3, 0})
> > read(9, "8\6*\213\253\311/\357U\370?\266L\307b\274\r^\30\rU?\256"...,
> > 130) = 85
> > select(10, [9], NULL, NULL, {3, 0})     = 1 (in [9], left {3, 0})
> > read(9, "5\316.\346\1\336G\16\334\37\315J\200\206\352\273\342\3"...,
> > 45) = 38
> > select(10, [9], NULL, NULL, {3, 0})     = 0 (Timeout)
> > select(10, [9], NULL, NULL, {3, 0})     = 0 (Timeout)
> > select(10, [9], NULL, NULL, {3, 0})     = 0 (Timeout)
> > select(10, [9], NULL, NULL, {3, 0})     = 0 (Timeout)
> > select(10, [9], NULL, NULL, {3, 0})     = 0 (Timeout)
> > select(10, [9], NULL, NULL, {3, 0})     = 0 (Timeout)
> ) leads me to believe that for some reason, your kernel is accumulating
> very little randomness in /dev/random [in fact, none at all for 18
> seconds, here].  That seems odd, as things like disk accesses and mouse
> movements AFAIK add randomness.
> 
> Is this an strace of gaim running on the virtual server, or on a client?
> If it's on the server, I can imagine that the (real) server machine
> isn't giving enough randomness to the virtual server's /dev/urandom.
> But I'm unclear on why one would run gaim on the server, and not on a
> client.
> 
>    - Ian
>



From bwiese at cotse.com  Sat Jul  9 14:31:36 2005
From: bwiese at cotse.com (Brian Wiese)
Date: Sat, 09 Jul 2005 14:31:36 -0400
Subject: [OTR-users] compiled plugin, how do I add it to gaim?
Message-ID: <42D01808.8020005@cotse.com>

--- background --- I'm running ubuntu hoary, and unfortunately I did not 
find any .deb packages on the download page for OTR (just source and 
fedora), though there is documentation about howto install the deb 
packages.  Another issue, is I added debian unstable to my sources.list, 
but on 'apt-get update' it complained there was no GPG key for that 
source.  (off topic, but does anyone know how to disable that check -- I 
thought there was an additional gpg-apt package installed somewhere)

My problem now... is I got libotr[1] and otr[2] and did..
./configure && make && make install  -- for both successfully as root 
(no config options)

Where is my plugin at?  How do I add it to gaim?  It did not just 'show 
up' on the plugins list in gaim (after restart even).  Do I need to move 
the file to a certain directory? (I didn't see plugins/ in ~/.gaim or 
/etc/gaim)

Thanks in advance!

Brian (aim: unolinuxguru, jabber: bwiese at jabber.org)

[1] http://www.cypherpunks.ca/otr/libotr-2.0.2.tar.gz
[2] http://www.cypherpunks.ca/otr/gaim-otr-2.0.2.tar.gz
-- 

bwiese[at]cotse.com | brianwiese.net | 402.297.9392
"What we do in life echoes in eternity" - Gladiator



From jcohen07 at brandeis.edu  Sat Jul  9 16:13:48 2005
From: jcohen07 at brandeis.edu (Jason Cohen)
Date: Sat, 09 Jul 2005 16:13:48 -0400
Subject: [OTR-users] compiled plugin, how do I add it to gaim?
Message-ID: <1120940028.22809.4.camel@localhost.localdomain>

On Sat, 2005-07-09 at 14:31 -0400, Brian Wiese wrote:

> problem now... is I got libotr[1] and otr[2] and did..
> ./configure && make && make install  -- for both successfully as root 
> (no config options)
> 


Did you do sudo make install? make install must be run as the
administrative/root user. Since Ubuntu has no root user you must either
run the command with sudo or type sudo -s to get a root shell. 

./configure && make && sudo make install

Also, if you're interested in building debs, you can easily backport
gaim-otr from breezy. I wrote instructions how to do this on the forum.
See http://ubuntuforums.org/showthread.php?t=40544&highlight=gaim-otr .
Read the last post.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cypherpunks.ca/pipermail/otr-users/attachments/20050709/824b37be/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 481 bytes
Desc: This is a digitally signed message part
URL: <http://lists.cypherpunks.ca/pipermail/otr-users/attachments/20050709/824b37be/attachment.pgp>

From otr at cypherpunks.ca  Sun Jul 24 10:55:04 2005
From: otr at cypherpunks.ca (The OTR Dev Team)
Date: Sun, 24 Jul 2005 10:55:04 -0400
Subject: [OTR-users] Flaw in OTR Protocol (with workaround!)
Message-ID: <E1Dwhse-0003Gq-O3@smtp.paip.net>

Well, this is the benefit of open protocols and open source.  :-)

Researchers from the Universita di Cantania (Italy) and IBM have looked
at the OTR protocol, and pointed out a flaw, which is this:

If Alice tries to communicate with Bob, Mallory (an active attacker) can
make Bob _think_ he's talking to Mallory, when he's actually talking to
Alice.  Alice correctly knows she's talking to Bob.  Note that Mallory
can't actually _read_ the messages between Alice and Bob.

For example, if Bob thinks he's talking to Mallory, he may tell her
something in confidence he would not want Alice to hear.  Note that
although Mallory could relate this confidential information to Alice
herself, but in the attack scenario Alice has assurance that the
message came from Bob rather than having to take Mallory's word for it.

There's a simple temporary workaround: Alice should say "Hi, this is
Alice." at the beginning of the conversation, alerting Bob to any
possible attack.  Likewise, Bob should identify himself to prevent
the attack in the opposite direction.

But in the longer term, we're going to fix the protocol to prevent the
attack in the first place.  Unfortunately, this will mean changing the
wire protocol, which will cause incompatibility.  The current plan is
for the next version of libotr to support both the current and new
protocols (with an option to disallow the current protocol); if you
communicate with someone speaking the current protocol, it will let you
know that you should confirm your identity with the other person.  [Note
that in the attack scenario, the people communicating are not "in on"
the attack, so simply mentioning your own name inside the OTR
conversation is sufficient.]

As a side effect, if anyone's got other enhancements to OTR in the wings
that would require wire protocol changes, now's the time to speak up.  :-)

- The OTR Dev Team

[Note that Ian and Kat will shortly be off the net until Monday evening,
but Nikita may be around.]


From ava089 at gmx.de  Mon Jul 25 16:46:29 2005
From: ava089 at gmx.de (Andreas von Arb)
Date: Mon, 25 Jul 2005 22:46:29 +0200
Subject: [OTR-users] otr proxy problems with german umlaute
Message-ID: <42E54FA5.70001@gmx.de>

Hallo,

Can anyone help me with following problem:

Sending German Umlaute like '??????' over the OTR Proxy does not work
correctly.

A friend sent e.g. 'Bl??' (which does not make any sense) and I receive
'Bl????' wich is quite ugly to look at.
Tested with OTR Proxy 0.3.0 und Trillian 0.74 and 3.1 Basic using SOCKS5
Proxy. The rest works fine for me.

Is this bug already known?
Any workaround?

Greetings
Andreas



From gmaxwell at gmail.com  Mon Jul 25 17:04:27 2005
From: gmaxwell at gmail.com (Gregory Maxwell)
Date: Mon, 25 Jul 2005 17:04:27 -0400
Subject: [OTR-users] Re: [OTR-announce] Flaw in OTR Protocol (with workaround!)
In-Reply-To: <E1Dwhse-0003Go-Mv@smtp.paip.net>
References: <E1Dwhse-0003Go-Mv@smtp.paip.net>
Message-ID: <e692861c050725140421e5488b@mail.gmail.com>

On 7/24/05, The OTR Dev Team <otr at cypherpunks.ca> wrote:
> As a side effect, if anyone's got other enhancements to OTR in the wings
> that would require wire protocol changes, now's the time to speak up.  :-)

Oh!

1. Automatic message splitting
2. Compression

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.

I also have an idea about compression that I've been stewing on for a
while, which I will discuss in a separate post.



From gmaxwell at gmail.com  Mon Jul 25 17:29:53 2005
From: gmaxwell at gmail.com (Gregory Maxwell)
Date: Mon, 25 Jul 2005 17:29:53 -0400
Subject: [OTR-users] Compression
Message-ID: <e692861c0507251429f151bd7@mail.gmail.com>

This is a post I made a few months ago to sci.crypt, it was inspired
by my musings on OTR, but lacking a more solid mathematical analysis
or an implementation I thought such dreaming was less suited for OTR
discussion and more suited for sci.crypt.

However, I guess they were all too busy dealing with factoring trolls
... or perhaps my musings were just too much conjecture and not enough
'show me the code'. :) Or perhaps I hit everyone's spam filters, in
any case there were no follow ups.

With talk of an OTR protocol change, I thought I'd bring it up here...
I don't think it's actionable today, but I think it is a neat idea
that would justify adding some bits into the protocol to allow later
versions of OTR to negotiate capabilities like compression.

-----------

Cryptography often finds use in textual messaging systems, for
example, email encryption and instant messenger communications.  In
this context, given most practical encryption systems, an attacker
will not
know exactly what a given message contains, but he can likely identify
the vast majority of possible decryptions as incorrect because the
vast majority of the messages will be not be remotely plausible (not
valid text in a language shared by the communicators).

Depending on the cipher used, its mode, its keysize, and the amount of
input encrypted with a key, it is quite possible that there is only a
single correct key which produces human readable text. The only
ciphers which I am aware of which provide an assurance of a large
quantity of plausible human text as potential decryptions are ones
where every key defines a unique bijective mapping from the input
space to the output space, and where the keysize is equal to the size
of the input message. We refer to such systems as one time pads, and
they are usually
achieved by simply xoring the input with the key. Although other
schemes are possible, they will all share the requirement of needing
too much key material for most uses.

This presents an annoying problem:  It is can often difficult for to a
sender to deny he sent a specific blob of encrypted output, unless he
has a secure channel (in which case, why does he need encryption?). 
In
some application the encrypted transmission is very public: there is
no doubt who created the message.

An attacker may somehow be able to find a key which decodes the
message by using 'rubberhose' cryptography against the recipient, by
brute-forcing the probable space of user-provided passwords, by bugs
in the software causing poor key choice, or via other means.

With the practical encryption schemes in use today, once an attacker
has obtained a key which decodes the message he is easily able to use
that key to extend whatever confidence there is in that the sender
sent the encrypted message into confidence that the sender sent that
particular plain-text.

Additionally, if a sender is forced to give up his key or face death,
he will be forced to disclose the real key because no other key will
produce a remotely plausible message. Thus, there is a substantial
incentive for an attacker to use that approach.

Below I will propose a system which addresses these issues within a
limited domain.

Let us consider a communication system which exchanges complete
messages of human readable text as encrypted fixed sized messages of N
bits.  Fixed sized messages are used in some private communication
because they are the only proven method of avoiding statistical
analysis on the message size. I am not sure if my idea can be easily
extended to non-fixed sized systems, so I will exclude them for here.
An example system using fixed sized messages is Mixminion
(http://www.mixminion.net/).

If we consider the set of all possible messages of N bits or less
(here after called set M), it follows that we can count each message
with a number representable in N bits or less in size.

We define function T to be a bijective mapping from the set M onto set
M such that messages are now ordered by their probability in the
context of the communication system (for example, if the system is
exchanging english text, "I went to the park." will be strictly before
"wr9ir4Pi;49 9irw9i3i$jRwe").  Because of the size of M it is not
possible to produce an optimal function T, but we can approximate it.
More below.

We define function S to be a surjective mapping on the size in bits of
the message, such that sizes of around perhaps 40 bits have much
shorter, and thus more probable output values and that longer messages
have outputs of substantially lower probability. (Think of a huffman
code where sizes around 40 bits are very likely).

Function E(m,k) encrypts message m with key k. The only requirement is
that the  encryption function does not make it easy to build a
dictionary of S_output,key -> first few bytes of ciphertext. Since S's
output should be fairly small, most block ciphers even in ECB mode
will suffice.

Function R(x) produces N - sizeof(x) random bits where N is the fixed
message size.

We now compute the encryption of message m by computing E_m =
E(S(m)+T(m)+R(T(m)+S(m))). Where + is concatenation.

We see that this encryption process is somewhat expansive (depending
on the size of the S output.) We ensure that no input message can be
longer than N minus the maximum size of S, and shrink T's output
accordingly, to account for  this.

If we decrypt E_m with an incorrect key, the resulting S will likely
indicate a fairly short message. Because of the nature of the T
mapping, the short messages will all be 'high probability' and thus
tend to be plausible english text.

Because of this property, it will be much more difficult to construct
an automated bruteforcing system since the goal will be to look for
the key giving the least probable decoding, and the attacker will be
out of
luck if the actual transmission happened to be a high probability one.

The sender has an increased ability to deny a specific key because
there are so many other keys which also produce english text. It could
be argued that a key is correct because it produced a fairly low
probability message, but the issue is certainly more clouded.

Furthermore, after encrypting a message, a sender could test various
keys for decryption and find some decryption which provides a basic
level of plausibility. This key could be provided to an attacker under
duress.

Obviously any authentication must be on the encrypted output, not on
the plaintext.

The suggestion of 40bits as the tuning size for S was only a guess, S
should be tuned so that it's output is long enough to produces
messages of a believable length, but not so long that random decodings
yield
implausible content. Tending towards shorter bad-decodings also helps
the sender find reasonable cover messages.

Now let us consider the construction of the T function. The T function
is actually an idealized version of what compression software tries to
achieve. So finding T would also find us the perfect compression
algorithm, which is obviously not a trivial task.

However, T does not need to be optimal in order to be usable. Our goal
in T is that every possible input gives a valid decoding, and that
that smaller outputs will tend to map to reasonable english text and
that it
is not too unlikely for short human readable inputs to map to also map
to short outputs. A dictionary based PPM compressor with the right
backend (one which ensures all inputs decode, and that the most
significant bits come first) will be sufficient.

So, is this idea useful or am I missing something obvious?



From nikitab at gmail.com  Mon Jul 25 17:33:19 2005
From: nikitab at gmail.com (Nikita Borisov)
Date: Mon, 25 Jul 2005 14:33:19 -0700
Subject: [OTR-users] otr proxy problems with german umlaute
In-Reply-To: <42E54FA5.70001@gmx.de>
References: <42E54FA5.70001@gmx.de>
Message-ID: <16f0378d05072514335b15a3ee@mail.gmail.com>

On 7/25/05, Andreas von Arb <ava089 at gmx.de> wrote:
> 
> Hallo,
> 
> Can anyone help me with following problem:
> 
> Sending German Umlaute like '??????' over the OTR Proxy does not work
> correctly.
> 
> A friend sent e.g. 'Bl??' (which does not make any sense) and I receive
> 'Bl????' wich is quite ugly to look at.
> Tested with OTR Proxy 0.3.0 und Trillian 0.74 and 3.1 Basic using SOCKS5
> Proxy. The rest works fine for me.


Can your friend send you characters with umlauts when you are not using the 
OTR proxy? I'm surprised that OTR would affect anything regarding character 
encoding. (I just did a quick test with my setup, using Adium X on one end 
and Gaim on the other and umlauts show up fine.)

- Nikita
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cypherpunks.ca/pipermail/otr-users/attachments/20050725/c635bc2e/attachment.html>

From ian at cypherpunks.ca  Mon Jul 25 18:10:21 2005
From: ian at cypherpunks.ca (Ian Goldberg)
Date: Mon, 25 Jul 2005 18:10:21 -0400
Subject: [OTR-users] otr proxy problems with german umlaute
In-Reply-To: <42E54FA5.70001@gmx.de>
References: <42E54FA5.70001@gmx.de>
Message-ID: <20050725221021.GQ1155@smtp.paip.net>

On Mon, Jul 25, 2005 at 10:46:29PM +0200, Andreas von Arb wrote:
> Hallo,
> 
> Can anyone help me with following problem:
> 
> Sending German Umlaute like '??????' over the OTR Proxy does not work
> correctly.
> 
> A friend sent e.g. 'Bl??' (which does not make any sense) and I receive
> 'Bl????' wich is quite ugly to look at.
> Tested with OTR Proxy 0.3.0 und Trillian 0.74 and 3.1 Basic using SOCKS5
> Proxy. The rest works fine for me.
> 
> Is this bug already known?
> Any workaround?

Huh.  Are you and your buddy both using otrproxy 0.3.0?  Which OS?

If you could file this in the bug database at
http://sourceforge.net/projects/otr/ that'd be great.

Thanks,

   - Ian


From ken at restivo.org  Mon Jul 25 19:45:20 2005
From: ken at restivo.org (Ken Restivo)
Date: Mon, 25 Jul 2005 16:45:20 -0700
Subject: [OTR-users] OTR loop DOS attack
Message-ID: <20050725234520.GA4376@vaio.restivo.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I inadvertently discovered a DOS attack in OTR.

I wrote a Jabber bot which notifies me of certain events. It also accepts a few text commands. If an unknown command is entered, the bot echoes it back.

This created a DOS attack in Adium. The OTR code apparently saw the "?OTR?" echoed back, and thought that my bot was attempting to mate with it. Not so. A huge, CPU-soaking, network-spewing, machine-locking disaster resulted (on the client, anyway).

Turning off encryption for that particular contact solved the problem.

It might be good if the opportunistic encryption somehow could recognise an echo of its own request, and just disregard it and go into unencrypted mode.

I don't know whether this vulnerability is in Adium, with the OTR protocol. It's obviously more annoying than dangerous, but I suppose it could be put to nefarious endsas well.

I'm not subscribed to this list. If you want to duplicate the error, write a simple Jabber bot that just echoes messages back (may be in sample code of a few Jabber libraries), then try to use opportunistic encryption to connect to it. Much hilarity will follow.

Cheers!

- -ken
- -- 
- ---------------
The world's most affordable web hosting.
http://www.nearlyfreespeech.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFC5XmQe8HF+6xeOIcRAvKCAJ9sxZpokOG9CTlPalH8NF91g4UD2gCfXN5O
cWiznvkcdI0pFJ4gqbqpJbw=
=HSm+
-----END PGP SIGNATURE-----


From ian at cypherpunks.ca  Mon Jul 25 21:44:31 2005
From: ian at cypherpunks.ca (Ian Goldberg)
Date: Mon, 25 Jul 2005 21:44:31 -0400
Subject: [OTR-users] OTR loop DOS attack
In-Reply-To: <20050725234520.GA4376@vaio.restivo.org>
References: <20050725234520.GA4376@vaio.restivo.org>
Message-ID: <20050726014431.GS1155@smtp.paip.net>

On Mon, Jul 25, 2005 at 04:45:20PM -0700, Ken Restivo wrote:
> It might be good if the opportunistic encryption somehow could
> recognise an echo of its own request, and just disregard it and go
> into unencrypted mode.

libotr in fact *does* recognize echoes of its own Key Exchange Messages.
You should see a message somewhere saying "We are receiving our own OTR
messages.  You are either trying to talk to yourself, or someone is
reflecting your messages back at you."  When it recognizes this, it
doesn't reply with another Key Exchange Message, so things should stop
there.

What messages keep getting sent back and forth?

> I don't know whether this vulnerability is in Adium, with the OTR
> protocol. It's obviously more annoying than dangerous, but I suppose
> it could be put to nefarious ends as well.

Note that we don't in general try to protect against DoS attacks, since
we can't.  But I'm still not clear on what exactly is going on here.
Can you send me a log?

Thanks,

   - Ian


From ava089 at gmx.de  Tue Jul 26 06:14:25 2005
From: ava089 at gmx.de (Andreas von Arb)
Date: Tue, 26 Jul 2005 12:14:25 +0200
Subject: [OTR-users] otr proxy problems with german umlaute
In-Reply-To: <20050725221021.GQ1155@smtp.paip.net>
References: <42E54FA5.70001@gmx.de> <20050725221021.GQ1155@smtp.paip.net>
Message-ID: <42E60D01.5030607@gmx.de>

Hallo,

Ian Goldberg wrote:
> 
> Huh.  Are you and your buddy both using otrproxy 0.3.0?  Which OS?

My buddy was using Gaim (ver ??) with OTR plugin 2.0.2 on Windows XP.

> 
> If you could file this in the bug database at
> http://sourceforge.net/projects/otr/ that'd be great.
> 

I'm going to post it there.

Nikita Borisov wrote:
> Can your friend send you characters with umlauts when you are not
> using the OTR proxy?

When OTR proxy is disabled everything works fine.


Ciao,
Andreas


From ken at restivo.org  Mon Jul 25 22:07:13 2005
From: ken at restivo.org (Ken Restivo)
Date: Mon, 25 Jul 2005 19:07:13 -0700
Subject: [OTR-users] OTR loop DOS attack
In-Reply-To: <20050726014431.GS1155@smtp.paip.net>
References: <20050725234520.GA4376@vaio.restivo.org> <20050726014431.GS1155@smtp.paip.net>
Message-ID: <20050726020713.GA4610@vaio.restivo.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mon, Jul 25, 2005 at 09:44:31PM -0400, Ian Goldberg wrote:
> On Mon, Jul 25, 2005 at 04:45:20PM -0700, Ken Restivo wrote:
> > It might be good if the opportunistic encryption somehow could
> > recognise an echo of its own request, and just disregard it and go
> > into unencrypted mode.
> 
> libotr in fact *does* recognize echoes of its own Key Exchange Messages.
> You should see a message somewhere saying "We are receiving our own OTR
> messages.  You are either trying to talk to yourself, or someone is
> reflecting your messages back at you."  When it recognizes this, it
> doesn't reply with another Key Exchange Message, so things should stop
> there.
> 

That is in fact what it said. But, yet, it keeps on attempting to re-send an OTR message to the bot; I don't know what exactly.

This was during a presence subscription exchange too; the bot automatically subscribes anyone who asks it. I don't know if that's significant.

> What messages keep getting sent back and forth?
> 

It's an SSL channel, and I wasn't logging it.

> > I don't know whether this vulnerability is in Adium, with the OTR
> > protocol. It's obviously more annoying than dangerous, but I suppose
> > it could be put to nefarious ends as well.
> 
> Note that we don't in general try to protect against DoS attacks, since
> we can't.  But I'm still not clear on what exactly is going on here.
> Can you send me a log?
> 

If I can get one from the user who experienced this lock-up, I will forward it.

What I might do is send along a simplified bit of code for the bot, and let you-all have a look. I suspect you could get a lot farther troubleshooting this than I ever would.

- -ken
- -- 
- ---------------
The world's most affordable web hosting.
http://www.nearlyfreespeech.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFC5ZrRe8HF+6xeOIcRAis+AJ9mxgXKBZDHVRXtryAjxlg9BSVOHQCfRki0
vsDZ38HdBdK3fLoHBuc+5kE=
=gNek
-----END PGP SIGNATURE-----


From ken at restivo.org  Tue Jul 26 00:55:25 2005
From: ken at restivo.org (Ken Restivo)
Date: Mon, 25 Jul 2005 21:55:25 -0700
Subject: [OTR-users] OTR loop DOS attack
In-Reply-To: <20050726014431.GS1155@smtp.paip.net>
References: <20050725234520.GA4376@vaio.restivo.org> <20050726014431.GS1155@smtp.paip.net>
Message-ID: <20050726045525.GA4909@vaio.restivo.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mon, Jul 25, 2005 at 09:44:31PM -0400, Ian Goldberg wrote:
> Note that we don't in general try to protect against DoS attacks, since
> we can't.  But I'm still not clear on what exactly is going on here.
> Can you send me a log?
> 

It appears to be a bug in Adium not in libotr. I tried with gaim-otr and could not duplicate the problem. Gaim did the right thing: it printed a message stating that it received its own OTR request, and cheerfully reverted back to cleartext mode. Adium, however, kept attempting to send.

This should provide some amusement:
http://www.restivo.org/projects/bots/echobot

To duplicate the problem: 
	1) create a valid user account for the bot, 
	2) run the above bot connected to that account, 
	3) then go to a client Mac running Adium and,
	4) turn on global opportunistic encryption (or is it the default?),
	5) attempt to add the bot's account to your buddy list, and then
	6) attempt to type something to it.

If the problem manifests, you'll get into an endless loop of OTR messages, which will fill up your logs, peg 100% CPU on your machine, and essentially lock it up.

If the problem does *not* manifest, then perhaps my user had some misconfiguration (i.e. maybe she had OTR defauting to *required* not requested), and I apologise for wasting your time. 

- -ken
- -- 
- ---------------
The world's most affordable web hosting.
http://www.nearlyfreespeech.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFC5cI9e8HF+6xeOIcRAkfFAKCbAj/gFQaq3+u9KGWVBowDGtfEEACfa6Ky
ondWhOdOnYXM2H7AZPPsFho=
=0IMV
-----END PGP SIGNATURE-----


From bean62 at hotmail.com  Fri Jul 29 08:49:28 2005
From: bean62 at hotmail.com (ben k)
Date: Fri, 29 Jul 2005 08:49:28 -0400
Subject: [OTR-users] OTR malformed message errors
Message-ID: <BAY106-F33D2B1CD015BBBFCC7FE61C3CE0@phx.gbl>

Greetings,

I use the OTR plugin for Gaim.  I am on windows XP pro, running gaim 1.4.  
I've noticed in the past week since I've upgraded from gaim 1.3.? to 1.4 
that I'm getting the "malformed message" when either sending or receiving 
messages over Yahoo about 1 in 10 times.  This may be some other issue, but 
seems to be happening often enough that I thought I'd mention it on the 
mailing list and see if anyone recognizes the issue...
For that matter, I'm not really sure what the malformed message error means. 
  Any suggestions welcomed.  As well, thanks for a great piece of software!

-ben

_________________________________________________________________
Don?t just search. Find. Check out the new MSN Search! 
http://search.msn.click-url.com/go/onm00200636ave/direct/01/



From ian at cypherpunks.ca  Fri Jul 29 09:47:27 2005
From: ian at cypherpunks.ca (Ian Goldberg)
Date: Fri, 29 Jul 2005 09:47:27 -0400
Subject: [OTR-users] OTR malformed message errors
In-Reply-To: <BAY106-F33D2B1CD015BBBFCC7FE61C3CE0@phx.gbl>
References: <BAY106-F33D2B1CD015BBBFCC7FE61C3CE0@phx.gbl>
Message-ID: <20050729134727.GE1019@smtp.paip.net>

On Fri, Jul 29, 2005 at 08:49:28AM -0400, ben k wrote:
> I use the OTR plugin for Gaim.  I am on windows XP pro, running gaim 1.4.  
> I've noticed in the past week since I've upgraded from gaim 1.3.? to 1.4 
> that I'm getting the "malformed message" when either sending or receiving 
> messages over Yahoo about 1 in 10 times.  This may be some other issue, but 
> seems to be happening often enough that I thought I'd mention it on the 
> mailing list and see if anyone recognizes the issue...
> For that matter, I'm not really sure what the malformed message error 
> means. Any suggestions welcomed.  As well, thanks for a great piece of 
>  software!

Does the error show up more often when you type a long message?  Does it
happen on networks other than Yahoo?

   - Ian


From ian at cypherpunks.ca  Sat Jul 30 10:34:03 2005
From: ian at cypherpunks.ca (Ian Goldberg)
Date: Sat, 30 Jul 2005 10:34:03 -0400
Subject: [OTR-users] otr proxy problems with german umlaute
In-Reply-To: <42E54FA5.70001@gmx.de>
References: <42E54FA5.70001@gmx.de>
Message-ID: <20050730143403.GJ1019@smtp.paip.net>

On Mon, Jul 25, 2005 at 10:46:29PM +0200, Andreas von Arb wrote:
> Hallo,
> 
> Can anyone help me with following problem:
> 
> Sending German Umlaute like '??????' over the OTR Proxy does not work
> correctly.
> 
> A friend sent e.g. 'Bl??' (which does not make any sense) and I receive
> 'Bl????' wich is quite ugly to look at.
> Tested with OTR Proxy 0.3.0 und Trillian 0.74 and 3.1 Basic using SOCKS5
> Proxy. The rest works fine for me.
> 
> Is this bug already known?
> Any workaround?

This is now fixed in CVS.  We correctly handle all Unicode points
< 0x10000.  There seems to be no way to handle points larger than that,
though, since none of the OSCAR encodings (ASCII, ISO-8859-1, UCS-2BE)
can represent them.

   - Ian