From rabbi at abditum.com Mon Aug 4 00:44:56 2008 From: rabbi at abditum.com (Len Sassaman) Date: Sun, 3 Aug 2008 21:44:56 -0700 (PDT) Subject: [OTR-dev] Requirements for libotr4 In-Reply-To: <20080619191430.GX26418@thunk.cs.uwaterloo.ca> References: <1213874573.7202.22.camel@hegg> <20080619191430.GX26418@thunk.cs.uwaterloo.ca> Message-ID: On Thu, 19 Jun 2008, Ian Goldberg wrote: > > The reason libotr treats a typed "?OTR?" as an signal to start/refresh > the private conversation is that for some clients (iChat?) that may be > the only way to do it. There may be no UI in the client itself to > control OTR. > > But I suppose we could make it an option. If you've got OTR support in > your UI, let libotr know that, and it will treat a typed "?OTR?" just as > any other 5 chars. [And maybe an option to treat "?OTR?" as the > start-OTR command if you're not currently encrypted, but as regular text > if you are, hmm.] I'm not sure I like this -- I prefer to keep the responses to given user input commands consistent across implementations unless there's compelling reason to offer optional variation. (Having OTR-enabled clients choose to display something other than "?OTR?" when they receive it doesn't concern me, but I think that "?OTR?" should always work.) (I'd argue that OTR-enabled clients probably *should* suppress the ?OTR? string, to address the "reposting of transcripts" issue.) I guess I'm okay with quoted "?OTR?" not triggering it (I.e., adding a nit where ?OTR? does what it currently does, but "?OTR?" doesn't -- essentially adding a comment bracketing to the initiation protocol.) It's my hope that this will become a non-issue, and that users won't have to use the characters "?OTR?" in conversation anyway. (It's not that this one new option proposal is a problem by itself, but these things accumulate, and each one makes implementing the OTR protocol that much more difficult.) --Len. From rabbi at abditum.com Mon Aug 4 01:01:31 2008 From: rabbi at abditum.com (Len Sassaman) Date: Sun, 3 Aug 2008 22:01:31 -0700 (PDT) Subject: [OTR-dev] Requirements for libotr4 In-Reply-To: <20080621134210.GR6417@yoink.cs.uwaterloo.ca> References: <20080619183738.GW26418@thunk.cs.uwaterloo.ca> <20080621134210.GR6417@yoink.cs.uwaterloo.ca> Message-ID: [Apologies if these issues have already been settled -- I'm behind on my list mail.] On Sat, 21 Jun 2008, Ian Goldberg wrote: > Note: this message is long, and will only be of interest to Uli and > others who care about asynchronous privkey generation. [snip] > > What do you think of that? I'm showing my Unix systems programming background here, but is there any objection to having a separate key generation process entirely, rather than doing this with threads? > otrl_privkey_generate_start checks to see if a generation for this > account is already in progress. If so, it returns a particular error > code, and the application should free any data state it allocated before > calling this routine. > > If not, otrl_privkey_generate_start will create an opaque data structure > newkey, and pass it to call_when_ready, along with the data the > application handed it. This all seems reasonable to me. > But I've got a question for you, Uli: key generation usually happens > when you get an incoming OTR Query or OTR Commit message. Is there a reason not to generate keys at the time an account is added to the client or registered/created? Obviously this is not a libotr issue, but it could be encouraged in a developers notes guide. Generating keys preemptively in the background so that the user does not need to wait for them while a conversation is in progress seems like a good usability move. (Obviously you still need to address the case you're talking about for clients that choose to do things "on-demand" though.) > So: even assuming we do the above, your create_privkey callback *must > not* return until the key generation is complete. You can still perform > the key generation in a subthread, though, and your main thread can > handle UI events to avoid appearing frozen, but it *must not* call > any libotr functions (even in the UI handlers, hmm). I assume we're doing a tuple check to make sure that the key generation we're blocking on is for the account that OTR operations are being requested for? If I have one account that is having its key generated, and another account that already has a key, I should of course be able to merrily perform OTR operations for the second account while the first account is waiting on the key generation. You'll also want a way to gracefully stop a key generation in progress, for instance if the app exits. I didn't see a call for that. --Len. From gmaxwell at gmail.com Tue Aug 26 22:39:57 2008 From: gmaxwell at gmail.com (Gregory Maxwell) Date: Tue, 26 Aug 2008 22:39:57 -0400 Subject: [OTR-dev] Achieving non-non-repudiation in another protocol. Message-ID: Hopefully the this brief non-libotr discussion is not too far off-topic. I'm getting close to releasing a real-time low latency audio conferencing tool (suitable for real-time music collaboration and the like). The system provides automatic, transparent, and always on encryption since I believe that I'm ethically obligated to include that as an author of a protocol that will be used across the internet. Due to the application requirements existing crypto layers like OTR do not suit my needs. It would be desirable if the anti-MITM functionality of my application did not also introduce non-repudiation, which is undesirable for this application. So I'd like the essential non-non-repudiation behavior of OTR. I think I've achieved that, but I'd like a quick sanity check. Some of the features of OTR, such as the ability to make validly decoding blind forgeries are not realistic in my application because of the use of compression (Nor are blind bitflips all that useful against audio in any case), so I'm performing my non-non-repudiation in a manner fairly different from libotr. I won't be providing a complete and accurate description of the cryptographic protocol here, since I'm only trying to verify that what I'm doing will achieve non-non-repudiation. Definitions: DHp1 = Client 1's ephemeral EC Diffie-Hellman public key DHp2 = Client 2's ephemeral EC Diffie-Hellman public key M1 = Random value generated by client 1 for message auth M2 = Random value generated by client 2 for message auth N1 = Random value generated by client 1 as a nonce N2 = Random value generated by client 2 as a nonce S1() = Signing with Client1's private key. S2() = Signing with Client2's private key. H() = some cryptographic hash function Client 1 sends DHp1 || N1 || MAC(M1,DHp1) -> Client 2 then Client 2 sends DHp2 || N2 || MAC(M2,DHp2) -> Client 1 then Client 1 sends M1 || S1(H(M1||N2)) -> Client 2 then Client 2 sends M2 || S2(H(M2||N1)) -> Client 1 With reasonable assumptions that M1, M2, N1, N2 are large and randomly selected: Client 1 and 2 can now verify that the DH public values are authenticated by M1 and M2. And that M1 and M2 were authenticated by the public keys so no MITM is possible. Replay isn't possible against client 1 or client 2 because the signatures depend on a nonce controlled by the other client. After the final exchange either client (or any eavesdropper) could create a new stream are re-use the Mn and Nn values from this exchange to make a forged stream that appears to be signed by Client1, Client2, or both. Does this appear correct? From ian at cypherpunks.ca Wed Aug 27 10:17:04 2008 From: ian at cypherpunks.ca (Ian Goldberg) Date: Wed, 27 Aug 2008 10:17:04 -0400 Subject: [OTR-dev] Achieving non-non-repudiation in another protocol. In-Reply-To: References: Message-ID: <20080827141704.GD13406@thunk.cs.uwaterloo.ca> On Tue, Aug 26, 2008 at 10:39:57PM -0400, Gregory Maxwell wrote: > Hopefully the this brief non-libotr discussion is not too far off-topic. > > I'm getting close to releasing a real-time low latency audio > conferencing tool (suitable for real-time music collaboration and the > like). > > The system provides automatic, transparent, and always on encryption > since I believe that I'm ethically obligated to include that as an > author of a protocol that will be used across the internet. Well said. :-) > It would be desirable if the anti-MITM functionality of my application > did not also introduce non-repudiation, which is undesirable for this > application. So I'd like the essential non-non-repudiation behavior > of OTR. I think I've achieved that, but I'd like a quick sanity > check. > > Some of the features of OTR, such as the ability to make validly > decoding blind forgeries are not realistic in my application because > of the use of compression (Nor are blind bitflips all that useful > against audio in any case), so I'm performing my non-non-repudiation > in a manner fairly different from libotr. > > I won't be providing a complete and accurate description of the > cryptographic protocol here, since I'm only trying to verify that what > I'm doing will achieve non-non-repudiation. > > Definitions: > DHp1 = Client 1's ephemeral EC Diffie-Hellman public key > DHp2 = Client 2's ephemeral EC Diffie-Hellman public key > M1 = Random value generated by client 1 for message auth > M2 = Random value generated by client 2 for message auth > N1 = Random value generated by client 1 as a nonce > N2 = Random value generated by client 2 as a nonce > S1() = Signing with Client1's private key. > S2() = Signing with Client2's private key. > H() = some cryptographic hash function > > Client 1 sends DHp1 || N1 || MAC(M1,DHp1) -> Client 2 > then > Client 2 sends DHp2 || N2 || MAC(M2,DHp2) -> Client 1 > then > Client 1 sends M1 || S1(H(M1||N2)) -> Client 2 > then > Client 2 sends M2 || S2(H(M2||N1)) -> Client 1 > > With reasonable assumptions that M1, M2, N1, N2 are large and randomly > selected: > > Client 1 and 2 can now verify that the DH public values are > authenticated by M1 and M2. And that M1 and M2 were authenticated by > the public keys so no MITM is possible. Replay isn't possible against > client 1 or client 2 because the signatures depend on a nonce > controlled by the other client. > > After the final exchange either client (or any eavesdropper) could > create a new stream are re-use the Mn and Nn values from this exchange > to make a forged stream that appears to be signed by Client1, Client2, > or both. > > Does this appear correct? I think you indeed achieve repudiability, but I'm pretty sure the above protocol suffers from the same identity-misbinding attack that OTRv1 had. The MITM can change the signature on the last message to be her own signature instead of C2's. Then C1 will think she's talking to MITM, but she's really talking to C2. OTR switched to the SIGMA protocol (used in IPSec) to overcome this problem. I think to fix the above, you could: - Change the H inside the signatures to a MAC, with key based on the DH shared secret. This proves that the parties have computed the same session key. - Put the sender's name/id/pubkey inside this MAC, along with the M and N values. Then if you remove the MAC(M1,DHp1) (and 2) and indeed the Ms entirely, I think you get SIGMA. Not positive; I'd have to write it out and look more closely. Maybe you have to put both N1 and N2 inside the MACs inside the signature. - Ian From gmaxwell at gmail.com Wed Aug 27 11:20:20 2008 From: gmaxwell at gmail.com (Gregory Maxwell) Date: Wed, 27 Aug 2008 11:20:20 -0400 Subject: [OTR-dev] Achieving non-non-repudiation in another protocol. In-Reply-To: <20080827141704.GD13406@thunk.cs.uwaterloo.ca> References: <20080827141704.GD13406@thunk.cs.uwaterloo.ca> Message-ID: On Wed, Aug 27, 2008 at 10:17 AM, Ian Goldberg wrote: >> Does this appear correct? > > I think you indeed achieve repudiability, but I'm pretty sure the above > protocol suffers from the same identity-misbinding attack that OTRv1 > had. > > The MITM can change the signature on the last message to be her own > signature instead of C2's. Then C1 will think she's talking to MITM, > but she's really talking to C2. Eeek. I agree. Thank you for pointing this out. > OTR switched to the SIGMA protocol (used in IPSec) to overcome this > problem. I think to fix the above, you could: > > - Change the H inside the signatures to a MAC, with key based on the DH > shared secret. This proves that the parties have computed the same > session key. > - Put the sender's name/id/pubkey inside this MAC, along with the M and > N values. I had consciously avoided *signing* the DH value or any result of the DH value because I wanted a third party to be able to produce a whole encrypted transmission bearing client1 and client2's signatures based only on passive observation without ever taking to those clients himself. Since the third party wouldn't know the private portions of the DH exchange (nor could we reasonable expect him to find new a new DH exchange which resulted in the same shared secret, I think) signing the DH exchange or shared secret would prevent such an forgery. I think I can probably solve this by including the pubkey inside the initial MAC over the public DH values but I'll have to give it a bit more thought. Thank you very much for your insight. From ian at cypherpunks.ca Wed Aug 27 13:01:21 2008 From: ian at cypherpunks.ca (Ian Goldberg) Date: Wed, 27 Aug 2008 13:01:21 -0400 Subject: [OTR-dev] Achieving non-non-repudiation in another protocol. In-Reply-To: References: <20080827141704.GD13406@thunk.cs.uwaterloo.ca> Message-ID: <20080827170121.GH13406@thunk.cs.uwaterloo.ca> On Wed, Aug 27, 2008 at 11:20:20AM -0400, Gregory Maxwell wrote: > On Wed, Aug 27, 2008 at 10:17 AM, Ian Goldberg wrote: > >> Does this appear correct? > > > > I think you indeed achieve repudiability, but I'm pretty sure the above > > protocol suffers from the same identity-misbinding attack that OTRv1 > > had. > > > > The MITM can change the signature on the last message to be her own > > signature instead of C2's. Then C1 will think she's talking to MITM, > > but she's really talking to C2. > > Eeek. I agree. Thank you for pointing this out. > > > OTR switched to the SIGMA protocol (used in IPSec) to overcome this > > problem. I think to fix the above, you could: > > > > - Change the H inside the signatures to a MAC, with key based on the DH > > shared secret. This proves that the parties have computed the same > > session key. > > - Put the sender's name/id/pubkey inside this MAC, along with the M and > > N values. > > I had consciously avoided *signing* the DH value or any result of the > DH value because I wanted a third party to be able to produce a whole > encrypted transmission bearing client1 and client2's signatures based > only on passive observation without ever taking to those clients > himself. Since the third party wouldn't know the private portions of > the DH exchange (nor could we reasonable expect him to find new a new > DH exchange which resulted in the same shared secret, I think) signing > the DH exchange or shared secret would prevent such an forgery. > > I think I can probably solve this by including the pubkey inside the > initial MAC over the public DH values but I'll have to give it a bit > more thought. > > Thank you very much for your insight. Fair enough; you just have to MAC your name with the DH session key, and also sign something fresh. So S(N1 || N2), MAC_s(my name) where s is derived from the DH shared secret may be OK. (That is, I think the MAC doesn't have to be *inside* the signature.) I think that's one of the variants explicitly given in the SIGMA paper, but I'm not positive. - Ian From paul at cypherpunks.ca Thu Aug 28 11:45:40 2008 From: paul at cypherpunks.ca (Paul Wouters) Date: Thu, 28 Aug 2008 11:45:40 -0400 (EDT) Subject: [OTR-dev] Achieving non-non-repudiation in another protocol. In-Reply-To: References: Message-ID: On Tue, 26 Aug 2008, Gregory Maxwell wrote: > Hopefully the this brief non-libotr discussion is not too far off-topic. > > I'm getting close to releasing a real-time low latency audio > conferencing tool (suitable for real-time music collaboration and the > like). > > The system provides automatic, transparent, and always on encryption > since I believe that I'm ethically obligated to include that as an > author of a protocol that will be used across the internet. Due to the > application requirements existing crypto layers like OTR do not suit > my needs. Doesn't the new libotr 4 specification for arranging symmetric keys via OTR solve your problem? Paul From gmaxwell at gmail.com Thu Aug 28 13:55:37 2008 From: gmaxwell at gmail.com (Gregory Maxwell) Date: Thu, 28 Aug 2008 13:55:37 -0400 Subject: [OTR-dev] Achieving non-non-repudiation in another protocol. In-Reply-To: References: Message-ID: On Thu, Aug 28, 2008 at 11:45 AM, Paul Wouters wrote: > Doesn't the new libotr 4 specification for arranging symmetric keys via > OTR solve your problem? It may, but I did not think the functionality was implemented yet. I haven't seen the implementation yet so I can't say. It would need to preserve the repudiation property for the symmetric keys. Schemes which sign symmetric keying material (as in Ian's quick reply to me) wouldn't get the repudiation property I'm looking for. I'm trying to figure out how I could use OTR: Common libraries are good for many reasons, including security, but I'm looking for properties that OTR doesn't provide naively which go beyond needing simple symmetric keys. I have a hard realtime audio data channel which simply needs symmetric keys that change every once in a while. Sounds like libotr4 could do that for me. I also have a control channel which provides reliable and known-order delivery of control messages. I need all of it to be robust against eavesdropping, MTIM, and 'traffic interference'. Traffic interference in this context is any activity other than simple packet dropping which damages or degrades the flow of traffic (think: sending forged RST packets to kill TCP sessions). Right now I'm accomplishing this via a yet un-released fork of airhook (http://airhook.ofb.net/) which I've extended to provide some OTR like properties as well as being able to provide symmetric keys for the hard-realtime audio channel (which I multiplex on the same UDP port by reserving one of the audio channel sequence numbers to indicate control). Think of it is as reliable-packet-OTR for IPv4/UDP and IPv6/UDP , perhaps. :) In order to use libotr I'd need to implement a basic reliable transport for OTR, then implement another reliable transport inside of OTR (or otherwise keyed by OTR)... and I'd need to make sure the outer transport for OTR is itself not vulnerable to traffic interference. I'd also have tolerate or work around some of OTR's existing chat channels (like the wasteful plain text encoding) which don't apply to this application. I *think* that since OTR can run inside the 500 byte limit of IRC I should be fine with the 532 byte MTU I'm imposing for keying operations. An interesting idea.