[jitsi-dev] OTR support for fragmenting messages to be sent


#1

Hi George and others,

I've been looking at OTR message fragmentation for the last few days. I
believe I've got a pretty decent implementation for fragmenting outgoing
messages. I'm still working on the implementation on the Jitsi side, but
I have been able to successfully establish a connection and authenticate
over IRC (which is originally limited to around 500 chars which was not
enough to even establish a connection in the first place) against a
pidgin client. That's not done yet, though, because the current
InstantMessageTransform implementation assumes only 1 message/event, so
I'm still fiddling around with the options there. (I've been cheating a
bit up to now.)

I would like it if you can take a look at the implementation in OTR4J
and give some feedback on the modifications I've made.

You can find it here: https://github.com/cobratbq/otr4j/tree/fragmenter

There are a few questions I still have:

1. It currently breaks the original public interface because it now
returns multiple encrypted message contents. How do you feel about that?
Any preferred alternatives?

2. I've added a method to the OtrEngineHost interface for querying about
fragmentation instructions. (I'm thinking of making this call
Just-In-Time such that we can adjust best as possible to the current
state and requirements of the transport channel.)

3. Do you have a good overview of the places where potentially a plain
text message is sent?
The current implementation always fragments and I've seen one or two
cases a plain text message announcing OTR was sent segmented. I'm not
sure if that's according to the specification.

4. I currently distinguish between 2 fragmentation instructions: 1.
Number of messages allowed to send, 2. Array with maximum message
fragment sizes (1 size per fragment, last size will be used for all
remaining message fragments)

5. It's implemented with a bunch of tests which includes some tests that
use the example messages from the OTR v2 and v3 specs.

Also, if you have any thoughts on how to implement this in Jitsi, then
I'm quite interested to know. The current IMT implementation seems to
depend on the MessageDeliveredEvent being returned and I'm quite
hesistant to "just convert everything to arrays". But, similarly I'm not
convinced that just injecting every fragment is the way to go ...

Let me know what you think!

Kind regards,
Danny


#2

Hey Danny!

Hi George and others,

I've been looking at OTR message fragmentation for the last few days. I
believe I've got a pretty decent implementation for fragmenting outgoing
messages. I'm still working on the implementation on the Jitsi side, but
I have been able to successfully establish a connection and authenticate
over IRC (which is originally limited to around 500 chars which was not
enough to even establish a connection in the first place) against a
pidgin client. That's not done yet, though, because the current
InstantMessageTransform implementation assumes only 1 message/event, so
I'm still fiddling around with the options there. (I've been cheating a
bit up to now.)

I would like it if you can take a look at the implementation in OTR4J
and give some feedback on the modifications I've made.

You can find it here: https://github.com/cobratbq/otr4j/tree/fragmenter

Very nicely done, awesome!

There are a few questions I still have:

1. It currently breaks the original public interface because it now
returns multiple encrypted message contents. How do you feel about that?
Any preferred alternatives?

I don't have a better idea ATM, so no problem whatsoever :slight_smile:

Also, keep in mind that OtrEngine is now called OtrSessionManager in
otr4j/master. It's nothing fancy, but you'll need to take that into account
when you integrate otr4j/master into Jitsi.

2. I've added a method to the OtrEngineHost interface for querying about
fragmentation instructions. (I'm thinking of making this call
Just-In-Time such that we can adjust best as possible to the current
state and requirements of the transport channel.)

Cool!

3. Do you have a good overview of the places where potentially a plain
text message is sent?
The current implementation always fragments and I've seen one or two
cases a plain text message announcing OTR was sent segmented. I'm not
sure if that's according to the specification.

I think OTR fragmentation is only meant for encoded OTR messages.

4. I currently distinguish between 2 fragmentation instructions: 1.
Number of messages allowed to send, 2. Array with maximum message
fragment sizes (1 size per fragment, last size will be used for all
remaining message fragments)

Out of curiosity, why did you choose to have an array of maximum message
fragment sizes? I mean, it sure gives you finer control over the fragmentation
process, but wouldn't a single maximum message fragment size suffice? Did you
actually need the array for the IRC implementation?

5. It's implemented with a bunch of tests which includes some tests that
use the example messages from the OTR v2 and v3 specs.

That's highly valuable!

Also, if you have any thoughts on how to implement this in Jitsi, then
I'm quite interested to know. The current IMT implementation seems to
depend on the MessageDeliveredEvent being returned and I'm quite
hesistant to "just convert everything to arrays". But, similarly I'm not
convinced that just injecting every fragment is the way to go ...

Hm, hmm.. The transform layer API has been introduced for and, AFAIK, is only
being used by OTR. So, if it makes sense to change it, I think we should.

I'm really not sure which option to go with, but I don't see why message
transformations need to be a "1 to 0 or 1" operation and not "1 to any". Taking
this into account, converting everything to arrays doesn't seem that crazy.

Thanks!

Kind regards,
George

···

On Wed, Sep 03, 2014 at 11:46:32PM +0200, Danny van Heumen wrote:

Let me know what you think!

Kind regards,
Danny


#3

Hi George,

Hey Danny!

Hi George and others,

I've been looking at OTR message fragmentation for the last few days. I
believe I've got a pretty decent implementation for fragmenting outgoing
messages. I'm still working on the implementation on the Jitsi side, but
I have been able to successfully establish a connection and authenticate
over IRC (which is originally limited to around 500 chars which was not
enough to even establish a connection in the first place) against a
pidgin client. That's not done yet, though, because the current
InstantMessageTransform implementation assumes only 1 message/event, so
I'm still fiddling around with the options there. (I've been cheating a
bit up to now.)

I would like it if you can take a look at the implementation in OTR4J
and give some feedback on the modifications I've made.

You can find it here: https://github.com/cobratbq/otr4j/tree/fragmenter

Very nicely done, awesome!

Thanks :slight_smile:

There are a few questions I still have:

1. It currently breaks the original public interface because it now
returns multiple encrypted message contents. How do you feel about that?
Any preferred alternatives?

I don't have a better idea ATM, so no problem whatsoever :slight_smile:

Okay, great.

Also, keep in mind that OtrEngine is now called OtrSessionManager in
otr4j/master. It's nothing fancy, but you'll need to take that into account
when you integrate otr4j/master into Jitsi.

Yup, I noticed that, but it was an easy fix. Are you planning to upgrade
the code in Jitsi for the current version of OTR4J? Or otherwise, I
could include that in my OTR4J extension. It's mostly, if not
completely, syntactic change, so it's quite easy to notice a mistake.

2. I've added a method to the OtrEngineHost interface for querying about
fragmentation instructions. (I'm thinking of making this call
Just-In-Time such that we can adjust best as possible to the current
state and requirements of the transport channel.)

Cool!

At least for IRC this is useful because I can determine the message size
while keeping the size of the contact's nick name in mind. A person with
a long nick name, will have little room for message content.

3. Do you have a good overview of the places where potentially a plain
text message is sent?
The current implementation always fragments and I've seen one or two
cases a plain text message announcing OTR was sent segmented. I'm not
sure if that's according to the specification.

I think OTR fragmentation is only meant for encoded OTR messages.

Okay, I suspect that as well. In that case I'll still need to check in
which cases a plain text message is sent. (I also need to check how
error messages are sent.)

4. I currently distinguish between 2 fragmentation instructions: 1.
Number of messages allowed to send, 2. Array with maximum message
fragment sizes (1 size per fragment, last size will be used for all
remaining message fragments)

Out of curiosity, why did you choose to have an array of maximum message
fragment sizes? I mean, it sure gives you finer control over the fragmentation
process, but wouldn't a single maximum message fragment size suffice? Did you
actually need the array for the IRC implementation?

I started with this approach, but up to now I haven't thought of a good
reason why we need this. I thought I would need it, but now I'm thinking
of getting it out.

5. It's implemented with a bunch of tests which includes some tests that
use the example messages from the OTR v2 and v3 specs.

That's highly valuable!

Also, if you have any thoughts on how to implement this in Jitsi, then
I'm quite interested to know. The current IMT implementation seems to
depend on the MessageDeliveredEvent being returned and I'm quite
hesistant to "just convert everything to arrays". But, similarly I'm not
convinced that just injecting every fragment is the way to go ...

Hm, hmm.. The transform layer API has been introduced for and, AFAIK, is only
being used by OTR. So, if it makes sense to change it, I think we should.

I'm really not sure which option to go with, but I don't see why message
transformations need to be a "1 to 0 or 1" operation and not "1 to any". Taking
this into account, converting everything to arrays doesn't seem that crazy.

I agree with you on the 1:1 vs. 1:many. If it turns out that there are
very few dependencies on the Instant Message Transform interface, then
I'll just modify it accordingly.

I was wondering ... is it a good approach to return the encrypted
message to the transform pipeline? Wouldn't that leave open the
possibility to accidentally corrupt the encrypted message by an ignorant
transform plugin?
Because of this, I wondered whether it would be better to inject the
message fragments directly and return null.

Regards,
Danny

···

On 09/07/2014 11:56 PM, George Politis wrote:

On Wed, Sep 03, 2014 at 11:46:32PM +0200, Danny van Heumen wrote:

Thanks!

Kind regards,
George

Let me know what you think!

Kind regards,
Danny