[OTR-dev] Fragmentation

Ian Goldberg ian at cypherpunks.ca
Wed Dec 17 12:22:00 EST 2014

On Wed, Dec 17, 2014 at 02:55:56PM +0100, Hannes Mehnert wrote:
> Hash: SHA384
> Dear OTR hackers,
> I just implemented reassembly of OTR fragments...
> While doing this I stumbled upon (in Protocol-v3):
> OTR version 2 messages get fragmented in a similar format, but without
> the instance tags fields:
> "?OTR,%hu,%hu,%s," , sender_instance, receiver_instance, k , n , piece[k]
>                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> I think those arguments should be removed (OTRv2 only uses k, n,
> piece[k]).

Thanks, I've fixed this in git.

> Furthermore, the protocol description does allow for fragmented
> fragments... I'm curious whether there is any use of it? (With my
> formal methods background, whenever I write a recursive function
> without a (straightforward) termination argument it hurts (tbh, the
> termination argument is rather straightforward since fragmentation
> prepends and appends some bytes, thus it should all be safe).
> I'd explicitly only allow certain messages to be fragmented -- such as
> data (query is shorter without fragmentation anyways, ...).
> I'm roughly talking about (where arrows indicate fragmentation, using
> v2 here for simplicity (and I didn't try to execute this..)):
> ?OTRv2
>  -->
> ?OTR,1,2,?O,
> ?OTR,2,2,TRv2,
>  -->
> ?OTR,1,2,?OTR,1,2,?,
> ?OTR,2,2,O,,
> ?OTR,2,2,TRv2,
>  -->
> ...

Hmm.  That certainly isn't the *intent*.  I don't see in the spec where
it allows fragments to be fragmented.  Messages can be fragmented, but
fragments aren't messages--they're fragments of messages.

And I fully agree with the "formal argument for termination of
recursive functions", of course.  I teach that myself.  ;-)  But this
function is not intended to be recursive at all.

Can you point to where the spec misled you or was unclear?  I'd
certainly like to fix that.


   - Ian

More information about the OTR-dev mailing list