From ian at cypherpunks.ca  Tue Oct  4 08:43:14 2005
From: ian at cypherpunks.ca (Ian Goldberg)
Date: Tue, 4 Oct 2005 08:43:14 -0400
Subject: [OTR-dev] New OTR Protocol draft: please look over
Message-ID: <20051004124314.GZ32161@smtp.paip.net>

It's been a long time coming, but we've finally got a draft of the new
OTR Protocol Spec.

It's here:

http://www.cypherpunks.ca/otr/Protocol-v2-draft-2005100401.html

Please look it over, and if you've got comments, make them pretty soon
(like in the next few days), since we'd like to get the next version
coded and released in about a month.  ;-)

Thanks,

   - Ian


From gdt at ir.bbn.com  Thu Oct  6 20:45:19 2005
From: gdt at ir.bbn.com (Greg Troxel)
Date: 06 Oct 2005 20:45:19 -0400
Subject: [OTR-dev] New OTR Protocol draft: please look over
In-Reply-To: <20051004124314.GZ32161@smtp.paip.net>
References: <20051004124314.GZ32161@smtp.paip.net>
Message-ID: <rmihdbu40kg.fsf@fnord.ir.bbn.com>

I suggest considering adding an id field to fragments.  Right now
fragments can be misassembled if the transport doesn't actualy do
in-order delivery.  The reassembly rules protect against this if n is
different, or k isn't K+1, but don't do so strongly.  Just having a
fragment id and incrementing it and requiring that it match would
help.  But, this may not be worthwhile because lack of ordering would
perhaps cause so many other problems, and it does take up space.
-- 
        Greg Troxel <gdt at ir.bbn.com>


From ian at cypherpunks.ca  Thu Oct  6 21:32:37 2005
From: ian at cypherpunks.ca (Ian Goldberg)
Date: Thu, 6 Oct 2005 21:32:37 -0400
Subject: [OTR-dev] New OTR Protocol draft: please look over
In-Reply-To: <rmihdbu40kg.fsf@fnord.ir.bbn.com>
References: <20051004124314.GZ32161@smtp.paip.net> <rmihdbu40kg.fsf@fnord.ir.bbn.com>
Message-ID: <20051007013237.GB847@smtp.paip.net>

On Thu, Oct 06, 2005 at 08:45:19PM -0400, Greg Troxel wrote:
> I suggest considering adding an id field to fragments.  Right now
> fragments can be misassembled if the transport doesn't actualy do
> in-order delivery.  The reassembly rules protect against this if n is
> different, or k isn't K+1, but don't do so strongly.  Just having a
> fragment id and incrementing it and requiring that it match would
> help.  But, this may not be worthwhile because lack of ordering would
> perhaps cause so many other problems, and it does take up space.

Indeed, if the network reorders messages, all kinds of things go wrong
(not security-wise, of course, but sessions won't get set up properly,
or messages won't be readable).

   - Ian


From paul at cypherpunks.ca  Sat Oct  8 14:22:18 2005
From: paul at cypherpunks.ca (Paul Wouters)
Date: Sat, 8 Oct 2005 20:22:18 +0200 (CEST)
Subject: [OTR-dev] New OTR Protocol draft: please look over
In-Reply-To: <20051007013237.GB847@smtp.paip.net>
References: <20051004124314.GZ32161@smtp.paip.net> <rmihdbu40kg.fsf@fnord.ir.bbn.com>
 <20051007013237.GB847@smtp.paip.net>
Message-ID: <Pine.LNX.4.63.0510082015310.1051@tla.xelerance.com>

On Thu, 6 Oct 2005, Ian Goldberg wrote:

> On Thu, Oct 06, 2005 at 08:45:19PM -0400, Greg Troxel wrote:
>> I suggest considering adding an id field to fragments.  Right now
>> fragments can be misassembled if the transport doesn't actualy do
>> in-order delivery.  The reassembly rules protect against this if n is
>> different, or k isn't K+1, but don't do so strongly.  Just having a
>> fragment id and incrementing it and requiring that it match would
>> help.  But, this may not be worthwhile because lack of ordering would
>> perhaps cause so many other problems, and it does take up space.
>
> Indeed, if the network reorders messages, all kinds of things go wrong
> (not security-wise, of course, but sessions won't get set up properly,
> or messages won't be readable).

But the fragments have an "id", right? The spec said:

?OTR,<fragmentnumber>,<totalfragments>,data

So in this case you could just save the fragments (within reason) and
reassemble them when you have all the fragments.

Though I guess it hardly makes sense to do so, because for any non
fragmented OTR message, you wouldn't be able to properly read it,

I think the assumption here is that messages can never be delivered
out of order, and if you receive a fragment while missing the 
previous fragments, you disgard all of them and return an error.

Paul


From ian at cypherpunks.ca  Sat Oct  8 14:32:43 2005
From: ian at cypherpunks.ca (Ian Goldberg)
Date: Sat, 8 Oct 2005 14:32:43 -0400
Subject: [OTR-dev] New OTR Protocol draft: please look over
In-Reply-To: <Pine.LNX.4.63.0510082015310.1051@tla.xelerance.com>
References: <20051004124314.GZ32161@smtp.paip.net> <rmihdbu40kg.fsf@fnord.ir.bbn.com> <20051007013237.GB847@smtp.paip.net> <Pine.LNX.4.63.0510082015310.1051@tla.xelerance.com>
Message-ID: <20051008183243.GG847@smtp.paip.net>

On Sat, Oct 08, 2005 at 08:22:18PM +0200, Paul Wouters wrote:
> But the fragments have an "id", right? The spec said:

The *fragments* have an id (as in "1/3", "2/3", "3/3"), but *reassembled
packets* don't (unlike, say, in IP).

> ?OTR,<fragmentnumber>,<totalfragments>,data
> 
> So in this case you could just save the fragments (within reason) and
> reassemble them when you have all the fragments.

The protocol doc specifies just accumulating fragments as they come in,
but it amounts to the same thing.

> Though I guess it hardly makes sense to do so, because for any non
> fragmented OTR message, you wouldn't be able to properly read it,

I don't understand this sentence.  Most OTR messages will be
unfragmented; surely you'll be able to read them.

> I think the assumption here is that messages can never be delivered
> out of order, and if you receive a fragment while missing the 
> previous fragments, you disgard all of them and return an error.

That's right.

   - Ian


From mail at marioland.it  Mon Oct 17 13:50:39 2005
From: mail at marioland.it (Mario)
Date: Mon, 17 Oct 2005 19:50:39 +0200
Subject: [OTR-dev] About the draft
Message-ID: <4353E46F.2090107@marioland.it>

Hi to all,
I've some questions about the AKE from the draft of the new protocol:
I've (hardly) recognized the SIGMA protocol in it, but:
- why do you encrypt the component g^x with AES under a fresh key $r$
when you reveal $r$ under the third message? In this way you are
temporarily hiding the component $g^x$. Why?
- Why do you generate a further MAC_B=MAC_{m1}(g^x,g^y,pub_B,keyid_B)
and then you sign it as sig_B(MAC_B) instead to sign directly
sig_B(g^x,g^y,pub_B,keyid_B)?
- What's the aim of the keyid_B and keyid_A fields in the AKE? For
example, keyid_B is included into MAC_B (with g^x from which it is
derivated).
- In the SIGMA protocol, the part signs only the DH-components and not
the his identity (that is contained into the separated MAC_{Km}(0,A)).
You are signing (indirectly signing the MAC) the identity of the part.

I hope that my comments don't arrive too late. I suggest to keep the
protocol as simple as possible (without unnecessary layer of
complexity). Nevertheless, actually I don't see security problems.

bye,
Mario Di Raimondo

-- 
 Home Page: http://www.marioland.it
 GnuPG/PGP key (ID BAC3EBB1) available on key-servers


From ian at cypherpunks.ca  Mon Oct 17 14:37:37 2005
From: ian at cypherpunks.ca (Ian Goldberg)
Date: Mon, 17 Oct 2005 14:37:37 -0400
Subject: [OTR-dev] About the draft
In-Reply-To: <4353E46F.2090107@marioland.it>
References: <4353E46F.2090107@marioland.it>
Message-ID: <20051017183737.GU847@smtp.paip.net>

On Mon, Oct 17, 2005 at 07:50:39PM +0200, Mario wrote:
> Hi to all,
> I've some questions about the AKE from the draft of the new protocol:
> I've (hardly) recognized the SIGMA protocol in it, but:
> - why do you encrypt the component g^x with AES under a fresh key $r$
> when you reveal $r$ under the third message? In this way you are
> temporarily hiding the component $g^x$. Why?

It's actually the hash(g^x) in that message that's important; Bob is
committing to a choice of x, so that we can use a truncated hash
of g^{xy} later in the protocol (as the secure session id) without
a MITM being able to match the truncated hashes.  What we've got:

-> enc_r(g^x), hash(g^x)
<- g^y
-> r, authenticator
<- authenticator

is just the same as

-> hash(g^x)
<- g^y
-> g^x, authenticator
<- authenticator

except that r is much smaller than g^x, and so we save space in the
(crowded) third message by putting enc_r(g^x) in the first message.
Many IM networks have very limited message sizes, so we have to be
careful about how much we send.

> - What's the aim of the keyid_B and keyid_A fields in the AKE? For
> example, keyid_B is included into MAC_B (with g^x from which it is
> derivated).

The keyids are used to identify the keys for the subsequent Data
Messages.  They're used to keep track of the key rotations.

> - Why do you generate a further MAC_B=MAC_{m1}(g^x,g^y,pub_B,keyid_B)
> and then you sign it as sig_B(MAC_B) instead to sign directly
> sig_B(g^x,g^y,pub_B,keyid_B)?
> - In the SIGMA protocol, the part signs only the DH-components and not
> the his identity (that is contained into the separated MAC_{Km}(0,A)).
> You are signing (indirectly signing the MAC) the identity of the part.

We use the space-saving variant of SIGMA that IKE also uses: instead of
sending

    sig_B(g^x, g^y), MAC_k(pub_B)

you send

    sig_B(MAC_k(g^x, g^y, pub_B))

The rules of SIGMA are that you have to MAC your identity, and
you have to sign fresh values (such as the DH params), but you can
always do more.  And this way saves message space, since you only send
one signature, instead of one signature and one MAC.  [The message is
then itself encrypted and MAC'd for identity protection, but that's a
separate MAC.]

See section 5.4 of Krawczyk, "SIGMA: the 'SIGn-and-MAc' Approach to
Authenticated Diffie-Hellman and its Use in the IKE Protocols", for
example.

> I hope that my comments don't arrive too late. I suggest to keep the
> protocol as simple as possible (without unnecessary layer of
> complexity). Nevertheless, actually I don't see security problems.

Thanks for your comments [as well as, of course, the paper that
instigated them ;-) ]!

   - Ian


From mr.s0rr0w at gmail.com  Thu Oct 20 19:11:35 2005
From: mr.s0rr0w at gmail.com (s0rr0w)
Date: Fri, 21 Oct 2005 01:11:35 +0200
Subject: [OTR-dev] otr projects visual studio workspaces
Message-ID: <43582427.9030803@gmail.com>

hi all,
since I want to work on otrproxy and actually I can do this mainly
on win32 platforms, I made dsw/dsp workspaces of libotr and
otrproxy for visual studio 6 (vs.net are easily derived).

I created the project using sourcesafe
http://sourceforge.net/projects/gpgvs/

actually you can build, without changing original code:
libgpg-error-1.1
libgcrypt-1.2.2
(but you can use also libgcrypt binaries you have)
libotr-2.0.2
otrproxy-0.3.0
libotr-head (at 21-10-2005)

I have not yet made test on otrproxy, I will do.
If useful, feel free to use and ask.
Thank you for otr effort, keep on :)

Francesco "s0rr0w" Picasso

------------------------------------------------------------------
Note: the only change I had to make to original source code was in
libotr\context.h

typedef struct fingerprint {
     struct fingerprint *next;
     struct fingerprint **tous;
     unsigned char *fingerprint;
     struct context *context;
     char *trust;
} Fingerprint;

this structure cannot compile (with vs) in a C++ file even if using
extern "C". So I did this little "alteration"

typedef struct _fingerprint_ {
     struct _fingerprint_ *next;
     struct _fingerprint_ **tous;
     unsigned char *fingerprint;
     struct context *context;
     char *trust;
} Fingerprint;

that's all.


From t6172839405l at ftml.net  Thu Oct 27 04:43:43 2005
From: t6172839405l at ftml.net (Thomas Lau)
Date: Thu, 27 Oct 2005 18:43:43 +1000
Subject: [OTR-dev] OTR in Adium / version 2 OTR feature request
Message-ID: <1130402623.22002.246132894@webmail.messagingengine.com>

To whom it may concern,

I've been instructed to forward a message to you folks because the
developers of Adium were a bit unsure. I would like to make a feature
request, for OTR to be recognised and cancelled more intelligently: too
often, messages are lost forever because users A and B talked with
encrypted messages, then say user A disconnects and reconnects, while
User B is still connected; when User B sends a message it is still
encrypted, and User A has not 'enabled' it in time to receive it. I
request a way to have OTR intelligently initially before translating the
message, which is much more practical.

The following two links may aid to resolve confusion:

http://trac.adiumx.com/ticket/1860
http://trac.adiumx.com/ticket/14

Regards,
Thomas

-- 
http://www.fastmail.fm - I mean, what is it about a decent email service?



From ian at cypherpunks.ca  Thu Oct 27 10:05:21 2005
From: ian at cypherpunks.ca (Ian Goldberg)
Date: Thu, 27 Oct 2005 10:05:21 -0400
Subject: [OTR-dev] OTR in Adium / version 2 OTR feature request
In-Reply-To: <1130402623.22002.246132894@webmail.messagingengine.com>
References: <1130402623.22002.246132894@webmail.messagingengine.com>
Message-ID: <20051027140521.GF847@smtp.paip.net>

Your concern is that if Alice is having an OTR conversation with Bob
over Jabber, and Bob disconnects, future messages from Alice (queued by
the Jabber server) will be unreadable?

Note that they *really are* unreadable; the messages are encrypted with
keys that Bob has long since forgotten.  The "right" thing to do is for
Bob's client to let Alice's client know that he's about to disconnect,
but that's not always possible (say, if Bob's machine just crashes, or
the net is flaky, or something).

Note that this is only a problem on networks like Jabber that queue
messages.

   - Ian