From ian at cypherpunks.ca Wed Jan 12 18:17:45 2005 From: ian at cypherpunks.ca (Ian Goldberg) Date: Wed, 12 Jan 2005 18:17:45 -0500 Subject: [OTR-dev] handling jabber resources In-Reply-To: <20041223181216.F25E822D3@fnord.ir.bbn.com> References: <20041223181216.F25E822D3@fnord.ir.bbn.com> Message-ID: <20050112231745.GR1211@smtp.paip.net> Happy New Year! ;-) On Thu, Dec 23, 2004 at 01:12:16PM -0500, Greg Troxel wrote: > resource is a jabber protocol concept, used to identify the particular > endpoint with a JID, where JID == screen name > (e.g. username at jabber.server.org) for gaim purposes. > So you would have user at jabber.net/home and user at jabber.net/work. Both > are the same 'account' (same pw to log into jabber server), but the > resource is carried along to the other party, and can be used to > direct messages to particular endpoints. Message routing w/o a > resource goes to the most recently active resource. > > Ian just said there was no way to stop doing OTR, so you wouldn't send > cleartext by accident. I looked into this a bit. It looks to me like gaim always merges conversations to user at jabber.net/home and user at jabber.net/work into one conversation window. If you've got a secure connection to one, and an insecure connection to one, you can certainly receive messages you think are secure, but aren't. I think this is a bug in gaim, personally. If /home and /work are in fact both logged in and sending me messages, why should their conversations be merged into one window? I'm not even able to reply to whomever sends it to me second, it seems. Did I miss a configuration option of gaim? If we could solve this security-related UI issue, it's easy enough to separate the internal state for the different resources. - Ian From gdt at ir.bbn.com Thu Jan 13 11:35:40 2005 From: gdt at ir.bbn.com (Greg Troxel) Date: Thu, 13 Jan 2005 11:35:40 -0500 Subject: [OTR-dev] handling jabber resources In-Reply-To: Message from Ian Goldberg of "Wed, 12 Jan 2005 18:17:45 EST." <20050112231745.GR1211@smtp.paip.net> Message-ID: <20050113163540.5F14D2356@fnord.ir.bbn.com> I think you are right that this is a bug in gaim. It's hard to get it right, though, because jabber is conflicted about resources. If you bring up a chat window, it doesn't yet know a resource, so it's probably fair to go from 'no resource' to a specific one on the first receipt of a message. For this reason, it's problematic for OTR to assume things are still encrypted when starting a new chat session. I frequently get encrypted messages I can't decrypt from someone that has a key with some other resource. They don't know where I am - they just see presence from me. So I wonder about a protocol extension to send an encrypted ping before sending the message, used whenever the key data is more than a few minutes old, or whenever we don't know the resource to talk to. But I realize that gaim may need fixing first. From evan.s at dreskin.net Wed Jan 12 18:57:12 2005 From: evan.s at dreskin.net (Evan Schoenberg) Date: Wed, 12 Jan 2005 17:57:12 -0600 Subject: [OTR-dev] handling jabber resources In-Reply-To: <20050112231745.GR1211@smtp.paip.net> References: <20041223181216.F25E822D3@fnord.ir.bbn.com> <20050112231745.GR1211@smtp.paip.net> Message-ID: You're correct that Gaim ignores incoming resources. Somewhere in there is support for handling them, though, as you can definitely start private chats using a screen name of the form chatname at conference.jabberserver.org/handle, where handle is the name someone is using in a group chat... and is equivalent to a resource of the group chat itself (chatname at conference.jabberserver.org). -Evan On Jan 12, 2005, at 5:17 PM, Ian Goldberg wrote: > Happy New Year! ;-) > > On Thu, Dec 23, 2004 at 01:12:16PM -0500, Greg Troxel wrote: >> resource is a jabber protocol concept, used to identify the particular >> endpoint with a JID, where JID == screen name >> (e.g. username at jabber.server.org) for gaim purposes. >> So you would have user at jabber.net/home and user at jabber.net/work. Both >> are the same 'account' (same pw to log into jabber server), but the >> resource is carried along to the other party, and can be used to >> direct messages to particular endpoints. Message routing w/o a >> resource goes to the most recently active resource. >> >> Ian just said there was no way to stop doing OTR, so you wouldn't send >> cleartext by accident. > > I looked into this a bit. It looks to me like gaim always merges > conversations to user at jabber.net/home and user at jabber.net/work into one > conversation window. If you've got a secure connection to one, and an > insecure connection to one, you can certainly receive messages you > think > are secure, but aren't. I think this is a bug in gaim, personally. If > /home and /work are in fact both logged in and sending me messages, why > should their conversations be merged into one window? I'm not even > able > to reply to whomever sends it to me second, it seems. > > Did I miss a configuration option of gaim? If we could solve this > security-related UI issue, it's easy enough to separate the internal > state for the different resources. > > - Ian > _______________________________________________ > OTR-dev mailing list > OTR-dev at lists.cypherpunks.ca > http://lists.cypherpunks.ca/mailman/listinfo/otr-dev > From alex323 at gmail.com Fri Jan 14 17:36:19 2005 From: alex323 at gmail.com (Alex Wied) Date: Fri, 14 Jan 2005 17:36:19 -0500 Subject: [OTR-dev] DH? Message-ID: <41E84963.8050702@gmail.com> Sorry.. I sent the last one from the wrong email. I've been looking to code an OTR lib in C#, the only problem is i do not know what DH is. I have a guess though.. is it 'ElGamal'? From verbal at gmail.com Fri Jan 14 18:30:40 2005 From: verbal at gmail.com (verbal) Date: Fri, 14 Jan 2005 15:30:40 -0800 Subject: [OTR-dev] DH? In-Reply-To: <41E84963.8050702@gmail.com> References: <41E84963.8050702@gmail.com> Message-ID: i think its Diffie-Hellman. On Fri, 14 Jan 2005 17:36:19 -0500, Alex Wied wrote: > Sorry.. I sent the last one from the wrong email. > I've been looking to code an OTR lib in C#, the only problem is i do not > know what DH is. I have a guess though.. is it 'ElGamal'? > > _______________________________________________ > OTR-dev mailing list > OTR-dev at lists.cypherpunks.ca > http://lists.cypherpunks.ca/mailman/listinfo/otr-dev > From ian at cypherpunks.ca Fri Jan 14 19:36:28 2005 From: ian at cypherpunks.ca (Ian Goldberg) Date: Fri, 14 Jan 2005 19:36:28 -0500 Subject: [OTR-dev] DH? In-Reply-To: References: <41E84963.8050702@gmail.com> Message-ID: <20050115003628.GC1060@smtp.paip.net> > On Fri, 14 Jan 2005 17:36:19 -0500, Alex Wied wrote: > > Sorry.. I sent the last one from the wrong email. > > I've been looking to code an OTR lib in C#, the only problem is i do not > > know what DH is. I have a guess though.. is it 'ElGamal'? Wow. C#. What's your application? Making a .NET version? ;-) On Fri, Jan 14, 2005 at 03:30:40PM -0800, verbal wrote: > i think its Diffie-Hellman. Indeed it is. - Ian From verbal at gmail.com Fri Jan 14 19:40:11 2005 From: verbal at gmail.com (verbal) Date: Fri, 14 Jan 2005 16:40:11 -0800 Subject: [OTR-dev] DH? In-Reply-To: <20050115003628.GC1060@smtp.paip.net> References: <41E84963.8050702@gmail.com> <20050115003628.GC1060@smtp.paip.net> Message-ID: do you plan to test with mono or dotgnu? it may be advantageous to do so. if you are not familiar with such projects, please let me know and i can either show you or i can test it for you once you are ready. On Fri, 14 Jan 2005 19:36:28 -0500, Ian Goldberg wrote: > > On Fri, 14 Jan 2005 17:36:19 -0500, Alex Wied wrote: > > > Sorry.. I sent the last one from the wrong email. > > > I've been looking to code an OTR lib in C#, the only problem is i do not > > > know what DH is. I have a guess though.. is it 'ElGamal'? > > Wow. C#. What's your application? Making a .NET version? ;-) > > On Fri, Jan 14, 2005 at 03:30:40PM -0800, verbal wrote: > > i think its Diffie-Hellman. > > Indeed it is. > > - Ian > _______________________________________________ > OTR-dev mailing list > OTR-dev at lists.cypherpunks.ca > http://lists.cypherpunks.ca/mailman/listinfo/otr-dev > From alex323 at gmail.com Sat Jan 15 00:55:18 2005 From: alex323 at gmail.com (alex323) Date: Sat, 15 Jan 2005 00:55:18 -0500 Subject: [OTR-dev] A C# lib Message-ID: <41E8B046.4000700@gmail.com> As you might have heard, I'm making a libary in C# for OTR. I have a few questions however regarding the protocol: * What is the size of the DH key I need to generate? (I don't think it's 1536.. I tried it) What about the DSA key length? * Why doesn't the protocol say that you need to include a NULL (byte 0) as the first character of the key exchange message? * I have two editable parameters with my DH class: P and G. Should G be set to 0x02 and P should be set to the key you generated? * Why is there an 'e' in the DSA key? My only options are P, Q, G, Y, and X. Wikipedia told me that X was the private key. Thanks in advance for your answer(s). From ian at cypherpunks.ca Sat Jan 15 09:10:28 2005 From: ian at cypherpunks.ca (Ian Goldberg) Date: Sat, 15 Jan 2005 09:10:28 -0500 Subject: [OTR-dev] A C# lib In-Reply-To: <41E8B046.4000700@gmail.com> References: <41E8B046.4000700@gmail.com> Message-ID: <20050115141028.GD1060@smtp.paip.net> On Sat, Jan 15, 2005 at 12:55:18AM -0500, alex323 wrote: > As you might have heard, I'm making a libary in C# for OTR. Wow. That's awesome. [Not to mention that it's super-useful to have interoperable implementations of a protocol.] > I have a few questions however regarding the protocol: > > * What is the size of the DH key I need to generate? (I don't think it's > 1536.. I tried it) > * I have two editable parameters with my DH class: P and G. Should G be > set to 0x02 and P should be set to the key you generated? - DH y (MPI) - The initial DH public encryption key. The DH group is the one defined in RFC 3526 with 1536-bit modulus (hex, big-endian): FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D 670C354E 4ABC9804 F1746C08 CA237327 FFFFFFFF FFFFFFFF and generator 2. So yes, it's 1536 bits. G = 0x02, and P is the above 1536-bit modulus. (We didn't generate it; it's the standard one from RFC 3526.) > What about the DSA key length? 1024 bits (the largest the standard allows). > * Why doesn't the protocol say that you need to include a NULL (byte 0) > as the first character of the key exchange message? Well, the first field of the Key Exchange Message (after base64-decoding) is: - Protocol version (SHORT) - The version number of this protocol is 0x0001. So that'd be encoded as \x00\x01. Is that the NUL you're talking about? > * Why is there an 'e' in the DSA key? My only options are P, Q, G, Y, > and X. Wikipedia told me that X was the private key. 'e' == 'Y'. There was this problem that 'Y' was already used by the DH key in the Key Exchange Message. X is indeed the private key [which of course never gets sent in the protocol ;-) ] > Thanks in advance for your answer(s). No problem. - Ian From ian at cypherpunks.ca Sat Jan 15 10:47:32 2005 From: ian at cypherpunks.ca (Ian Goldberg) Date: Sat, 15 Jan 2005 10:47:32 -0500 Subject: [OTR-dev] otrproxy and packaging Message-ID: <20050115154732.GE1060@smtp.paip.net> Some exciting news. We've got an AIM proxy that speaks OTR. It works on Linux (and probably other *nixes), OSX, and we even got it to work under wine with mingw (though it has not yet been tested on a "real" Win32 box). There's no UI at all on it yet, though. [Well, it prints things to stdout.] Which means you start OTR conversations by typing "?OTR?" in your conversation window, and there's no way right now to leave private mode. It also always accepts new fingerprints, since there's no way to ask you. (It does *tell* you on stdout, though.) In order to implement this, a lot of the "logic" code from gaim-otr was refactored into libotr, with UI callbacks, as Evan wanted done for Adium X anyway. So there will soon be a 1.0.3 of gaim-otr, which uses the new refactored library. It's got this Changelog: > - Generate private keys automatically, if needed. Show a Please Wait > dialog while this is happening. > - We may as well try to use the "tag" method of checking for OTR, even > when we don't already know a fingerprint for the correspondent. > - Add version checking to the otrl_init() call. > - Refactored the logic parts of gaim-otr into libotr, so they can be > shared by other libotr-enabled apps. But now it seems to be the time that we need to split libotr from gaim-otr. Here's what I propose; please comment. - libotr and gaim-otr each get the new version 1.0.3, but from now on, their changes are independent, and will have separate version numbers. - The version numbers for libotr from now on will follow the usual convention: major number changes denote non-backwards-compatible API changes, minor number changes denote backwards-compatible API changes, sub number changes denote implementation changes, but no API changes. - They'll need to be packaged separately now. Maybe something like this: libotr Contains the toolkit binaries, and possibly eventually libotr.so Depends on libgcrypt libotr-dev Contains libotr.a and the .h files (in /usr/include/libotr/) Depends on libotr, libgcrypt-dev gaim-otr Contains /usr/lib/gaim/gaim-otr.so Depends on libotr, glib, gtk+, gaim otrproxy Contains otrproxy Depends on libotr - While this seems like the "right" way to do it, it means that people downloading gaim-otr will now have to download the libotr package separately. On some systems, package management will eventually do this automatically (once everything makes its way to the official distributions), but I don't know how this works on, say, OSX. What do people think? - Ian From gdt at ir.bbn.com Sat Jan 15 11:17:48 2005 From: gdt at ir.bbn.com (Greg Troxel) Date: Sat, 15 Jan 2005 11:17:48 -0500 Subject: [OTR-dev] otrproxy and packaging In-Reply-To: Message from Ian Goldberg of "Sat, 15 Jan 2005 10:47:32 EST." <20050115154732.GE1060@smtp.paip.net> Message-ID: <20050115161748.A2B9E1F74@fnord.ir.bbn.com> - The version numbers for libotr from now on will follow the usual convention: major number changes denote non-backwards-compatible API changes, minor number changes denote backwards-compatible API changes, sub number changes denote implementation changes, but no API changes. And presumably the shlib number for libotr.so will bump similarly to the first two version numbers. - They'll need to be packaged separately now. Maybe something like this: Your proposal is very linux-centric. But, the real question is: For the proposed tarball release strategy, will each of the packaging systems be able to do something rational, without having to do something they consider icky. What you listed seems to fit the linux world. For pkgsrc (NetBSD, but also many other OSes), I would see things being similar, except no libotr/libotr-dev split - compiling from source is the dominant paradigm, so that is rare. So I think it's fine. From alex323 at gmail.com Sat Jan 15 12:35:36 2005 From: alex323 at gmail.com (alex323) Date: Sat, 15 Jan 2005 12:35:36 -0500 Subject: [OTR-dev] A C# lib In-Reply-To: <20050115141028.GD1060@smtp.paip.net> References: <41E8B046.4000700@gmail.com> <20050115141028.GD1060@smtp.paip.net> Message-ID: <41E95468.5040303@gmail.com> (Sorry if I did this wrong, i'm still getting my feet wet with this mailing list thing) Should we start a sourceforge project on the entire OTR project? This could include lib-otr, gaim-otr, my C# lib.. and anything else you want to include. What do you think? I can do all the registration if you'd like (the hard stuff). Ian Goldberg wrote: >On Sat, Jan 15, 2005 at 12:55:18AM -0500, alex323 wrote: > > >>As you might have heard, I'm making a libary in C# for OTR. >> >> > >Wow. That's awesome. [Not to mention that it's super-useful to have >interoperable implementations of a protocol.] > > > >>I have a few questions however regarding the protocol: >> >>* What is the size of the DH key I need to generate? (I don't think it's >>1536.. I tried it) >>* I have two editable parameters with my DH class: P and G. Should G be >>set to 0x02 and P should be set to the key you generated? >> >> > > - DH y (MPI) > - The initial DH public encryption key. The DH group is the one > defined in RFC 3526 with 1536-bit modulus (hex, big-endian): > FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 > 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD > EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 > E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED > EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D > C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F > 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D > 670C354E 4ABC9804 F1746C08 CA237327 FFFFFFFF FFFFFFFF > and generator 2. > >So yes, it's 1536 bits. G = 0x02, and P is the above 1536-bit modulus. >(We didn't generate it; it's the standard one from RFC 3526.) > > > >>What about the DSA key length? >> >> > >1024 bits (the largest the standard allows). > > > >>* Why doesn't the protocol say that you need to include a NULL (byte 0) >>as the first character of the key exchange message? >> >> > >Well, the first field of the Key Exchange Message (after base64-decoding) is: > > - Protocol version (SHORT) > - The version number of this protocol is 0x0001. > >So that'd be encoded as \x00\x01. Is that the NUL you're talking about? > > > >>* Why is there an 'e' in the DSA key? My only options are P, Q, G, Y, >>and X. Wikipedia told me that X was the private key. >> >> > >'e' == 'Y'. There was this problem that 'Y' was already used by the DH >key in the Key Exchange Message. X is indeed the private key [which of >course never gets sent in the protocol ;-) ] > > > >>Thanks in advance for your answer(s). >> >> > >No problem. > > - Ian >_______________________________________________ >OTR-dev mailing list >OTR-dev at lists.cypherpunks.ca >http://lists.cypherpunks.ca/mailman/listinfo/otr-dev > > > From alex323 at gmail.com Sat Jan 15 13:01:49 2005 From: alex323 at gmail.com (alex323) Date: Sat, 15 Jan 2005 13:01:49 -0500 Subject: [OTR-dev] DH? Message-ID: <41E95A8D.2060503@gmail.com> .NET mostly. I hope to get it working on mono though On Sat, 15 Jan 2005 00:40:11 -0500, verbal wrote: > do you plan to test with mono or dotgnu? it may be advantageous to do > so. if you are not familiar with such projects, please let me know and > i can either show you or i can test it for you once you are ready. On Fri, 14 Jan 2005 19:36:28 -0500, Ian Goldberg > wrote: >/ > On Fri, 14 Jan 2005 17:36:19 -0500, Alex Wied > wrote: />/ > > Sorry.. I sent the last one from the wrong email. />/ > > I've been looking to code an OTR lib in C#, the only problem is i do not />/ > > know what DH is. I have a guess though.. is it 'ElGamal'? />/ />/ Wow. C#. What's your application? Making a .NET version? ;-) />/ />/ On Fri, Jan 14, 2005 at 03:30:40PM -0800, verbal wrote: />/ > i think its Diffie-Hellman. />/ />/ Indeed it is. />/ />/ - Ian />/ _______________________________________________ />/ OTR-dev mailing list />/ OTR-dev at lists.cypherpunks.ca />/ http://lists.cypherpunks.ca/mailman/listinfo/otr-dev /> From alex323 at gmail.com Sat Jan 15 13:06:46 2005 From: alex323 at gmail.com (alex323) Date: Sat, 15 Jan 2005 13:06:46 -0500 Subject: [OTR-dev] DH? In-Reply-To: <41E95A8D.2060503@gmail.com> References: <41E95A8D.2060503@gmail.com> Message-ID: <41E95BB6.9090103@gmail.com> I don't get what's wrong with my mail client.. it isn't sending these emails right. alex323 wrote: > .NET mostly. I hope to get it working on mono though > > On Sat, 15 Jan 2005 00:40:11 -0500, verbal wrote: > >> do you plan to test with mono or dotgnu? it may be advantageous to do >> so. if you are not familiar with such projects, please let me know and >> i can either show you or i can test it for you once you are ready. > > > On Fri, 14 Jan 2005 19:36:28 -0500, Ian Goldberg > wrote: > >> / > On Fri, 14 Jan 2005 17:36:19 -0500, Alex Wied > > wrote: > > />/ > > Sorry.. I sent the last one from the wrong email. > />/ > > I've been looking to code an OTR lib in C#, the only problem > is i do not > />/ > > know what DH is. I have a guess though.. is it 'ElGamal'? > />/ />/ Wow. C#. What's your application? Making a .NET version? ;-) > />/ />/ On Fri, Jan 14, 2005 at 03:30:40PM -0800, verbal wrote: > />/ > i think its Diffie-Hellman. > />/ />/ Indeed it is. > />/ />/ - Ian > />/ _______________________________________________ > />/ OTR-dev mailing list > />/ OTR-dev at lists.cypherpunks.ca > />/ http://lists.cypherpunks.ca/mailman/listinfo/otr-dev > /> > > From alex323 at gmail.com Sat Jan 15 13:19:20 2005 From: alex323 at gmail.com (alex323) Date: Sat, 15 Jan 2005 13:19:20 -0500 Subject: [OTR-dev] A C# lib In-Reply-To: <20050115141028.GD1060@smtp.paip.net> References: <41E8B046.4000700@gmail.com> <20050115141028.GD1060@smtp.paip.net> Message-ID: <41E95EA8.5070803@gmail.com> Hmmm.. i'm having some problems. My friend keeps telling me that there was a malformed key exchange. Maybe one of you can look at what my program is generating? Thanks To reply to a key exchange (reply=1): ?OTR:AAEKAG8IXHYaE01IBR0bB31gHgFwM1QlXUgUCgh3InJIKj5PKQkSLHgiDFwTeBkhbTUWUk0sZ2FJWlAyfnwySjdWIHYjRmxgEAxxU1NbJ1JIX0w2I2guZxFmGCF5R2AQQUgCSi88E2NeWRtcfRMtfVgJVWkbdzJ+GjR5DkkbeGFpfidvBgYPAGl/NARaACNyXz5AOhQxOSM4MwNOGncXCGE9LUM+djx3IR0IdxMaLHFvdCABDT9zJk1IfAMkZT1QYQkhGjMPJEEcegUcG2RKKDpicnMFHlsKVmdAIXk+aFcvTHZrPVV4b28lexFiKUMsJxwgSzdvfWM3IztVbXEiZRM9YA5aCA0PMy1QLFN7aB8TRR5xQGpmJzwRLEE3AggMOn1qcFNuXnkeUxdjQ1FVTWAQNHsPAz8xKkQjRCQYWEhCAzlNU01DJDVXGWMPNhpYFwp0JwlWQDITLwl/BiYCfjc6Fl04Th96eDEkWW1pICYeRUs+JV0ANip3FXJZBQ9DPzsLZBN+YzhUHxplHXlcFi0TTyllPGg0UxYGE0c3bwFrVVUheFNDE2VDOSxKF2gnAgpvCWU5E3BZTAIQWEwEMSp6ey4VBjcpOQ8+QhgFUFNCe0FHFHFkFWJsBVlEPVA1BksdLBc5Kj9pJXltNQ9VeDURPSAvSGY/PE50EE94ZlkPMjxdX1hjFyZaZko/cyUoIWJ6PRFqEjYRQndoNwcwYklGJg12TXlcG11ieBBAEFZQfwlGLGUANgBIG0sZQSs1ZHRhaiJsRFpnSFo/BlIsThl4SQp/FQhvAhAnSng1b3wcfQ40VyQDF1Q3UCkufnUZInVEeVtrWQwgWBQCL3ViaQ==. To send a key (reply=0): ?OTR:AAEKAR5AVE8xfUsjSCk+bVcZU146PA1MGzYuSDwaJz16TiB0J0prS2tdPDcJPlM8FhRHGGlqVmJWWFxaWwYNOgsyfzZvLU1aWEV2N0xHQVEnCiZ3QA9BehtKTBVkQScZG21ucyBmXUEfSjcyOisEU0IYJx5gckltGW98AzxZfRBULRcTIDAzT2MQKTBmcg8MRTt/QG10TWlQdBoUdx8oZgoeXRkifhZEL0sZUzAiT3U6DnUDR3ErUjpzUXUueWdgLixmLSsYIh0WSiR0FhR2VClxMVQlBztRelk2Mk1XSwcbI2o2fEYYXn9/VntZZCF2XAQbFjskbnlRKTt2Zzs7alxxCn9vSTUGBTYWDTYTEHlQS0ZUJxE8JScpK0QyYGhEdCVfRAg2EBNNaR8KEHduTkZSWg8edVpMRXopZRgzK3dnQRgQPG8oJxR0cXsBfSpyORhzen8xEQl7VnhvIWRGYj92bnBfcGY8PwwySAodEy8iRw4mcw9aIm84fT5ABHcoIxoTYiViBENCGjtAJ0FaMRI0Qn4IfH8IeiQPRns+fQx8LlJYUgsrOzhSei1XYRBmBAluaBJsJWkMZFgDBklKTl9+ND8cYzsqcFl7WURZF21ESGEdHgE0J0tfMGBVCGBEREIgPjBvJ2ZNexJ6dDkAfQpVbnkbJR5DGR00Ei8sUgwACxJNSEwRIF1gSgEuKUlRTGxrM09/PGt6XkwebTUsSngzDQA+Hx5yIjYBQ18YdklqVml9SDlSQwRRVQkYHBMFYCBoOzITXUoFJBt3DHN/RGYyNG92UgMtAh1ZP2pmNks+HWxSd0wGXXFGdiJ5ahY8BmxFKBIvKUZ3ND5lHDM9TQ==. All I should be able to do is generate a reply to a key exchange (I will make the keyid and all that work later when this works). Here is my code (a little sloppy.. i'll clean it up later): private static byte[] generateKeyExchangePacket(DSAParameters dsap, byte[] dhPubKey) { byte[] ret = new byte[601]; byte[] publicKey = dsa.GetPublicKey(dsap); ret[1]=(byte)protocol.OTR_PROTOCOL_VERSION; ret[2]=10; // Message type (0x0a == 10) ret[3]=0; // Reply publicKey.CopyTo(ret,4); dhPubKey.CopyTo(ret,publicKey.Length+4); ret[dhPubKey.Length+publicKey.Length+4]=2; //KeyId SHA1CryptoServiceProvider sha1 = new SHA1CryptoServiceProvider(); byte[] myEnd = new byte[640]; dsa.Sign(sha1.ComputeHash(ret),dsap).CopyTo(myEnd,600); ret.CopyTo(myEnd,0); return myEnd; } Ian Goldberg wrote: >On Sat, Jan 15, 2005 at 12:55:18AM -0500, alex323 wrote: > > >>As you might have heard, I'm making a libary in C# for OTR. >> >> > >Wow. That's awesome. [Not to mention that it's super-useful to have >interoperable implementations of a protocol.] > > > >>I have a few questions however regarding the protocol: >> >>* What is the size of the DH key I need to generate? (I don't think it's >>1536.. I tried it) >>* I have two editable parameters with my DH class: P and G. Should G be >>set to 0x02 and P should be set to the key you generated? >> >> > > - DH y (MPI) > - The initial DH public encryption key. The DH group is the one > defined in RFC 3526 with 1536-bit modulus (hex, big-endian): > FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 > 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD > EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 > E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED > EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D > C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F > 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D > 670C354E 4ABC9804 F1746C08 CA237327 FFFFFFFF FFFFFFFF > and generator 2. > >So yes, it's 1536 bits. G = 0x02, and P is the above 1536-bit modulus. >(We didn't generate it; it's the standard one from RFC 3526.) > > > >>What about the DSA key length? >> >> > >1024 bits (the largest the standard allows). > > > >>* Why doesn't the protocol say that you need to include a NULL (byte 0) >>as the first character of the key exchange message? >> >> > >Well, the first field of the Key Exchange Message (after base64-decoding) is: > > - Protocol version (SHORT) > - The version number of this protocol is 0x0001. > >So that'd be encoded as \x00\x01. Is that the NUL you're talking about? > > > >>* Why is there an 'e' in the DSA key? My only options are P, Q, G, Y, >>and X. Wikipedia told me that X was the private key. >> >> > >'e' == 'Y'. There was this problem that 'Y' was already used by the DH >key in the Key Exchange Message. X is indeed the private key [which of >course never gets sent in the protocol ;-) ] > > > >>Thanks in advance for your answer(s). >> >> > >No problem. > > - Ian >_______________________________________________ >OTR-dev mailing list >OTR-dev at lists.cypherpunks.ca >http://lists.cypherpunks.ca/mailman/listinfo/otr-dev > > > From evan.s at dreskin.net Sat Jan 15 14:35:59 2005 From: evan.s at dreskin.net (Evan Schoenberg) Date: Sat, 15 Jan 2005 13:35:59 -0600 Subject: [OTR-dev] otrproxy and packaging In-Reply-To: <20050115154732.GE1060@smtp.paip.net> References: <20050115154732.GE1060@smtp.paip.net> Message-ID: Awesome :D Look forward to seeing and playing with that. -Evan On Jan 15, 2005, at 9:47 AM, Ian Goldberg wrote: > In order to implement this, a lot of the "logic" code from gaim-otr was > refactored into libotr, with UI callbacks, as Evan wanted done for > Adium X anyway. From alex323 at gmail.com Sat Jan 15 15:08:28 2005 From: alex323 at gmail.com (alex323) Date: Sat, 15 Jan 2005 15:08:28 -0500 Subject: [OTR-dev] DH? In-Reply-To: <41E95BB6.9090103@gmail.com> References: <41E95A8D.2060503@gmail.com> <41E95BB6.9090103@gmail.com> Message-ID: <41E9783C.8060104@gmail.com> Ok, the problem is fixed :) alex323 wrote: > I don't get what's wrong with my mail client.. it isn't sending these > emails right. > > alex323 wrote: > >> .NET mostly. I hope to get it working on mono though >> >> On Sat, 15 Jan 2005 00:40:11 -0500, verbal wrote: >> >>> do you plan to test with mono or dotgnu? it may be advantageous to do >>> so. if you are not familiar with such projects, please let me know and >>> i can either show you or i can test it for you once you are ready. >> >> >> >> On Fri, 14 Jan 2005 19:36:28 -0500, Ian Goldberg > > wrote: >> >>> / > On Fri, 14 Jan 2005 17:36:19 -0500, Alex Wied >> > wrote: >> >> >> />/ > > Sorry.. I sent the last one from the wrong email. >> />/ > > I've been looking to code an OTR lib in C#, the only problem >> is i do not >> />/ > > know what DH is. I have a guess though.. is it 'ElGamal'? >> />/ />/ Wow. C#. What's your application? Making a .NET version? ;-) >> />/ />/ On Fri, Jan 14, 2005 at 03:30:40PM -0800, verbal wrote: >> />/ > i think its Diffie-Hellman. >> />/ />/ Indeed it is. >> />/ />/ - Ian >> />/ _______________________________________________ >> />/ OTR-dev mailing list >> />/ OTR-dev at lists.cypherpunks.ca >> />/ http://lists.cypherpunks.ca/mailman/listinfo/otr-dev >> /> >> >> > > From alex323 at gmail.com Sat Jan 15 15:52:55 2005 From: alex323 at gmail.com (alex323) Date: Sat, 15 Jan 2005 15:52:55 -0500 Subject: [OTR-dev] A C# lib In-Reply-To: <20050115141028.GD1060@smtp.paip.net> References: <41E8B046.4000700@gmail.com> <20050115141028.GD1060@smtp.paip.net> Message-ID: <41E982A7.1040005@gmail.com> I have another question as well: There is another parameter I can choose: "The length, in bits, of the private value. If 0 is specified, the default value will be used." The default value is 160. Is that what I need? It's used here: dhm = new DiffieHellmanManaged(1536, /* What goes here? */ ,DHKeyGeneration.Static); Ian Goldberg wrote: >On Sat, Jan 15, 2005 at 12:55:18AM -0500, alex323 wrote: > > >>As you might have heard, I'm making a libary in C# for OTR. >> >> > >Wow. That's awesome. [Not to mention that it's super-useful to have >interoperable implementations of a protocol.] > > > >>I have a few questions however regarding the protocol: >> >>* What is the size of the DH key I need to generate? (I don't think it's >>1536.. I tried it) >>* I have two editable parameters with my DH class: P and G. Should G be >>set to 0x02 and P should be set to the key you generated? >> >> > > - DH y (MPI) > - The initial DH public encryption key. The DH group is the one > defined in RFC 3526 with 1536-bit modulus (hex, big-endian): > FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 > 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD > EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 > E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED > EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D > C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F > 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D > 670C354E 4ABC9804 F1746C08 CA237327 FFFFFFFF FFFFFFFF > and generator 2. > >So yes, it's 1536 bits. G = 0x02, and P is the above 1536-bit modulus. >(We didn't generate it; it's the standard one from RFC 3526.) > > > >>What about the DSA key length? >> >> > >1024 bits (the largest the standard allows). > > > >>* Why doesn't the protocol say that you need to include a NULL (byte 0) >>as the first character of the key exchange message? >> >> > >Well, the first field of the Key Exchange Message (after base64-decoding) is: > > - Protocol version (SHORT) > - The version number of this protocol is 0x0001. > >So that'd be encoded as \x00\x01. Is that the NUL you're talking about? > > > >>* Why is there an 'e' in the DSA key? My only options are P, Q, G, Y, >>and X. Wikipedia told me that X was the private key. >> >> > >'e' == 'Y'. There was this problem that 'Y' was already used by the DH >key in the Key Exchange Message. X is indeed the private key [which of >course never gets sent in the protocol ;-) ] > > > >>Thanks in advance for your answer(s). >> >> > >No problem. > > - Ian >_______________________________________________ >OTR-dev mailing list >OTR-dev at lists.cypherpunks.ca >http://lists.cypherpunks.ca/mailman/listinfo/otr-dev > > > From cbdrews at verizon.net Sat Jan 15 16:26:50 2005 From: cbdrews at verizon.net (Carol Brosen Drews) Date: Sat, 15 Jan 2005 16:26:50 -0500 Subject: [OTR-dev] concerns with mail handling on this list In-Reply-To: <41E95BB6.9090103@gmail.com> Message-ID: There is apparently no way to hit reply and have it go to the list first to be filtered according to list member's settings. Instead, it apparently automatically replies to the sender. If you hit reply to all, that is apparently the only way it will also be sent to the list. Is that assumption correct? From verbal at gmail.com Sat Jan 15 16:27:07 2005 From: verbal at gmail.com (verbal) Date: Sat, 15 Jan 2005 13:27:07 -0800 Subject: [OTR-dev] otrproxy and packaging In-Reply-To: <20050115154732.GE1060@smtp.paip.net> References: <20050115154732.GE1060@smtp.paip.net> Message-ID: > - While this seems like the "right" way to do it, it means that people > downloading gaim-otr will now have to download the libotr package > separately. On some systems, package management will eventually do > this automatically (once everything makes its way to the official > distributions), but I don't know how this works on, say, OSX. as you said, packaging on systems that have managers should not be a problem. just setup the depencies. for other systems such as os x and netbsd, we could just package them together and make a new package release whenever we drop a new version of libotr or the frontend. i know that if you'll be making people download unnecessary code, but that shouldnt be a problem. From verbal at gmail.com Sat Jan 15 16:31:21 2005 From: verbal at gmail.com (verbal) Date: Sat, 15 Jan 2005 13:31:21 -0800 Subject: [OTR-dev] DH? In-Reply-To: <41E95A8D.2060503@gmail.com> References: <41E95A8D.2060503@gmail.com> Message-ID: On Sat, 15 Jan 2005 13:01:49 -0500, alex323 wrote: > .NET mostly. I hope to get it working on mono though it should just work in mono. i've had experience getting .net made programs to compile/run on mono/dotgnu so i should be able to help if you run into any troubles. if you dont mind my asking, what will the library used for? is there an IM client written in C# that you are interested in? verbal From alex323 at gmail.com Sat Jan 15 16:37:42 2005 From: alex323 at gmail.com (alex323) Date: Sat, 15 Jan 2005 16:37:42 -0500 Subject: [OTR-dev] DH? In-Reply-To: References: <41E95A8D.2060503@gmail.com> Message-ID: <41E98D26.1020705@gmail.com> Kind of.. there is an IRC bot called SharpBot that I founded (http://sf.net/projects/sharpbot) and I wanted to make a plugin for it. Why don't you come by our channel #sharpbot on dalnet? Regards, Alex verbal wrote: >On Sat, 15 Jan 2005 13:01:49 -0500, alex323 wrote: > > >>.NET mostly. I hope to get it working on mono though >> >> > >it should just work in mono. i've had experience getting .net made >programs to compile/run on mono/dotgnu so i should be able to help if >you run into any troubles. if you dont mind my asking, what will the >library used for? is there an IM client written in C# that you are >interested in? > >verbal > > > From ian at cypherpunks.ca Sat Jan 15 16:40:42 2005 From: ian at cypherpunks.ca (Ian Goldberg) Date: Sat, 15 Jan 2005 16:40:42 -0500 Subject: [OTR-dev] concerns with mail handling on this list In-Reply-To: References: <41E95BB6.9090103@gmail.com> Message-ID: <20050115214042.GH1060@smtp.paip.net> On Sat, Jan 15, 2005 at 04:26:50PM -0500, Carol Brosen Drews wrote: > There is apparently no way to hit reply and have it go to the list first to > be filtered according to list member's settings. Instead, it apparently > automatically replies to the sender. If you hit reply to all, that is > apparently the only way it will also be sent to the list. Is that > assumption correct? Hit "reply" to have it go only to the sender. Hit "reply to all" (or better, "reply to list", which most mailers have a way to do) to reply to everyone. If you do "reply to list", the sender doesn't get an extra copy, which is nice. - Ian From ian at cypherpunks.ca Sat Jan 15 16:44:23 2005 From: ian at cypherpunks.ca (Ian Goldberg) Date: Sat, 15 Jan 2005 16:44:23 -0500 Subject: [OTR-dev] A C# lib In-Reply-To: <41E982A7.1040005@gmail.com> References: <41E8B046.4000700@gmail.com> <20050115141028.GD1060@smtp.paip.net> <41E982A7.1040005@gmail.com> Message-ID: <20050115214423.GI1060@smtp.paip.net> On Sat, Jan 15, 2005 at 03:52:55PM -0500, alex323 wrote: > I have another question as well: There is another parameter I can > choose: "The length, in bits, of the private value. If 0 is specified, > the default value will be used." > The default value is 160. Is that what I need? It's used here: > > dhm = new DiffieHellmanManaged(1536, /* What goes here? */ > ,DHKeyGeneration.Static); libotr uses 320; see otrl_dh_gen_keypair in dh.c. - Ian From ian at cypherpunks.ca Sat Jan 15 16:57:37 2005 From: ian at cypherpunks.ca (Ian Goldberg) Date: Sat, 15 Jan 2005 16:57:37 -0500 Subject: [OTR-dev] A C# lib In-Reply-To: <41E95EA8.5070803@gmail.com> References: <41E8B046.4000700@gmail.com> <20050115141028.GD1060@smtp.paip.net> <41E95EA8.5070803@gmail.com> Message-ID: <20050115215737.GJ1060@smtp.paip.net> On Sat, Jan 15, 2005 at 01:19:20PM -0500, alex323 wrote: > Hmmm.. i'm having some problems. My friend keeps telling me that there > was a malformed key exchange. Maybe one of you can look at what my > program is generating? Thanks > > To reply to a key exchange (reply=1): > ?OTR:AAEKAG8IXHYaE01IBR0bB31gHgFwM1QlXUgUCgh3InJIKj5PKQkSLHgiDFwTeBkhbTUWUk0sZ2FJWlAyfnwySjdWIHYjRmxgEAxxU1NbJ1JIX0w2I2guZxFmGCF5R2AQQUgCSi88E2NeWRtcfRMtfVgJVWkbdzJ+GjR5DkkbeGFpfidvBgYPAGl/NARaACNyXz5AOhQxOSM4MwNOGncXCGE9LUM+djx3IR0IdxMaLHFvdCABDT9zJk1IfAMkZT1QYQkhGjMPJEEcegUcG2RKKDpicnMFHlsKVmdAIXk+aFcvTHZrPVV4b28lexFiKUMsJxwgSzdvfWM3IztVbXEiZRM9YA5aCA0PMy1QLFN7aB8TRR5xQGpmJzwRLEE3AggMOn1qcFNuXnkeUxdjQ1FVTWAQNHsPAz8xKkQjRCQYWEhCAzlNU01DJDVXGWMPNhpYFwp0JwlWQDITLwl/BiYCfjc6Fl04Th96eDEkWW1pICYeRUs+JV0ANip3FXJZBQ9DPzsLZBN+YzhUHxplHXlcFi0TTyllPGg0UxYGE0c3bwFrVVUheFNDE2VDOSxKF2gnAgpvCWU5E3BZTAIQWEwEMSp6ey4VBjcpOQ8+QhgFUFNCe0FHFHFkFWJsBVlEPVA1BksdLBc5Kj9pJXltNQ9VeDURPSAvSGY/PE50EE94ZlkPMjxdX1hjFyZaZko/cyUoIWJ6PRFqEjYRQndoNwcwYklGJg12TXlcG11ieBBAEFZQfwlGLGUANgBIG0sZQSs1ZHRhaiJsRFpnSFo/BlIsThl4SQp/FQhvAhAnSng1b3wcfQ40VyQDF1Q3UCkufnUZInVEeVtrWQwgWBQCL3ViaQ==. You know about otr_parse in the toolkit, right? Indeed, it says your message is malformed. So let's take it apart. iang at warren:~$ echo 'AAEKAG8IXHYaE01IBR0bB31gHgFwM1QlXUgUCgh3InJIKj5PKQkSLHgiDFwTeBkhbTUWUk0sZ2FJWlAyfnwySjdWIHYjRmxgEAxxU1NbJ1JIX0w2I2guZxFmGCF5R2AQQUgCSi88E2NeWRtcfRMtfVgJVWkbdzJ+GjR5DkkbeGFpfidvBgYPAGl/NARaACNyXz5AOhQxOSM4MwNOGncXCGE9LUM+djx3IR0IdxMaLHFvdCABDT9zJk1IfAMkZT1QYQkhGjMPJEEcegUcG2RKKDpicnMFHlsKVmdAIXk+aFcvTHZrPVV4b28lexFiKUMsJxwgSzdvfWM3IztVbXEiZRM9YA5aCA0PMy1QLFN7aB8TRR5xQGpmJzwRLEE3AggMOn1qcFNuXnkeUxdjQ1FVTWAQNHsPAz8xKkQjRCQYWEhCAzlNU01DJDVXGWMPNhpYFwp0JwlWQDITLwl/BiYCfjc6Fl04Th96eDEkWW1pICYeRUs+JV0ANip3FXJZBQ9DPzsLZBN+YzhUHxplHXlcFi0TTyllPGg0UxYGE0c3bwFrVVUheFNDE2VDOSxKF2gnAgpvCWU5E3BZTAIQWEwEMSp6ey4VBjcpOQ8+QhgFUFNCe0FHFHFkFWJsBVlEPVA1BksdLBc5Kj9pJXltNQ9VeDURPSAvSGY/PE50EE94ZlkPMjxdX1hjFyZaZko/cyUoIWJ6PRFqEjYRQndoNwcwYklGJg12TXlcG11ieBBAEFZQfwlGLGUANgBIG0sZQSs1ZHRhaiJsRFpnSFo/BlIsThl4SQp/FQhvAhAnSng1b3wcfQ40VyQDF1Q3UCkufnUZInVEeVtrWQwgWBQCL3ViaQ==' | perl -MMIME::Base64 -pe '$_=&decode_base64($_)' | od -tx1 0000000 00 01 0a 00 6f 08 5c 76 1a 13 4d 48 05 1d 1b 07 0000020 7d 60 1e 01 70 33 54 25 5d 48 14 0a 08 77 22 72 [snip] You start with: 00 01 (Protocol version 1) 0a (Key Exchange Message) 00 (reply == 0, unlike what you said) 6f 08 5c 76 <- nonsense An MPI is expected here. From the Protocol document: > Multi-precision integers (MPI): > 4 byte unsigned len, big-endian > len byte unsigned value, big-endian > (MPIs must use the minimum-length encoding; i.e. no leading 0x00 > bytes. This is important when calculating public key fingerprints.) You seem to be missing the MPI length field. - Ian From alex323 at gmail.com Sat Jan 15 16:58:35 2005 From: alex323 at gmail.com (alex323) Date: Sat, 15 Jan 2005 16:58:35 -0500 Subject: [OTR-dev] A C# lib In-Reply-To: <20050115214423.GI1060@smtp.paip.net> References: <41E8B046.4000700@gmail.com> <20050115141028.GD1060@smtp.paip.net> <41E982A7.1040005@gmail.com> <20050115214423.GI1060@smtp.paip.net> Message-ID: <41E9920B.9080808@gmail.com> Thanks... as I read throught the source code (again), I see the type "Fingerprint". What is the purpose of that? Also, do you have some kind of IM account we can talk on? You may email it to me directly if you wish. Ian Goldberg wrote: >On Sat, Jan 15, 2005 at 03:52:55PM -0500, alex323 wrote: > > >>I have another question as well: There is another parameter I can >>choose: "The length, in bits, of the private value. If 0 is specified, >>the default value will be used." >>The default value is 160. Is that what I need? It's used here: >> >>dhm = new DiffieHellmanManaged(1536, /* What goes here? */ >>,DHKeyGeneration.Static); >> >> > >libotr uses 320; see otrl_dh_gen_keypair in dh.c. > > - Ian >_______________________________________________ >OTR-dev mailing list >OTR-dev at lists.cypherpunks.ca >http://lists.cypherpunks.ca/mailman/listinfo/otr-dev > > > From alex323 at gmail.com Sat Jan 15 17:07:07 2005 From: alex323 at gmail.com (alex323) Date: Sat, 15 Jan 2005 17:07:07 -0500 Subject: [OTR-dev] A C# lib In-Reply-To: <20050115215737.GJ1060@smtp.paip.net> References: <41E8B046.4000700@gmail.com> <20050115141028.GD1060@smtp.paip.net> <41E95EA8.5070803@gmail.com> <20050115215737.GJ1060@smtp.paip.net> Message-ID: <41E9940B.8030009@gmail.com> I see. Let me admonish you that the .NET crypto libs are slightly different than gcrypt. Before I read the protocol, I never knew what an MPI was. "4 byte unsigned len, big-endian" I am assuming that that is supposed to be 4 bytes that indicate the length of hte public key? Thanks for your assistance and patience. Ian Goldberg wrote: >On Sat, Jan 15, 2005 at 01:19:20PM -0500, alex323 wrote: > > >>Hmmm.. i'm having some problems. My friend keeps telling me that there >>was a malformed key exchange. Maybe one of you can look at what my >>program is generating? Thanks >> >>To reply to a key exchange (reply=1): >>?OTR:AAEKAG8IXHYaE01IBR0bB31gHgFwM1QlXUgUCgh3InJIKj5PKQkSLHgiDFwTeBkhbTUWUk0sZ2FJWlAyfnwySjdWIHYjRmxgEAxxU1NbJ1JIX0w2I2guZxFmGCF5R2AQQUgCSi88E2NeWRtcfRMtfVgJVWkbdzJ+GjR5DkkbeGFpfidvBgYPAGl/NARaACNyXz5AOhQxOSM4MwNOGncXCGE9LUM+djx3IR0IdxMaLHFvdCABDT9zJk1IfAMkZT1QYQkhGjMPJEEcegUcG2RKKDpicnMFHlsKVmdAIXk+aFcvTHZrPVV4b28lexFiKUMsJxwgSzdvfWM3IztVbXEiZRM9YA5aCA0PMy1QLFN7aB8TRR5xQGpmJzwRLEE3AggMOn1qcFNuXnkeUxdjQ1FVTWAQNHsPAz8xKkQjRCQYWEhCAzlNU01DJDVXGWMPNhpYFwp0JwlWQDITLwl/BiYCfjc6Fl04Th96eDEkWW1pICYeRUs+JV0ANip3FXJZBQ9DPzsLZBN+YzhUHxplHXlcFi0TTyllPGg0UxYGE0c3bwFrVVUheFNDE2VDOSxKF2gnAgpvCWU5E3BZTAIQWEwEMSp6ey4VBjcpOQ8+QhgFUFNCe0FHFHFkFWJsBVlEPVA1BksdLBc5Kj9pJXltNQ9VeDURPSAvSGY/PE50EE94ZlkPMjxdX1hjFyZaZko/cyUoIWJ6PRFqEjYRQndoNwcwYklGJg12TXlcG11ieBBAEFZQfwlGLGUANgBIG0sZQSs1ZHRhaiJsRFpnSFo/BlIsThl4SQp/FQhvAhAnSng1b3wcfQ40VyQDF1Q3UCkufnUZInVEeVtrWQwgWBQCL3ViaQ==. >> >> > >You know about otr_parse in the toolkit, right? Indeed, it says your >message is malformed. So let's take it apart. > >iang at warren:~$ echo 'AAEKAG8IXHYaE01IBR0bB31gHgFwM1QlXUgUCgh3InJIKj5PKQkSLHgiDFwTeBkhbTUWUk0sZ2FJWlAyfnwySjdWIHYjRmxgEAxxU1NbJ1JIX0w2I2guZxFmGCF5R2AQQUgCSi88E2NeWRtcfRMtfVgJVWkbdzJ+GjR5DkkbeGFpfidvBgYPAGl/NARaACNyXz5AOhQxOSM4MwNOGncXCGE9LUM+djx3IR0IdxMaLHFvdCABDT9zJk1IfAMkZT1QYQkhGjMPJEEcegUcG2RKKDpicnMFHlsKVmdAIXk+aFcvTHZrPVV4b28lexFiKUMsJxwgSzdvfWM3IztVbXEiZRM9YA5aCA0PMy1QLFN7aB8TRR5xQGpmJzwRLEE3AggMOn1qcFNuXnkeUxdjQ1FVTWAQNHsPAz8xKkQjRCQYWEhCAzlNU01DJDVXGWMPNhpYFwp0JwlWQDITLwl/BiYCfjc6Fl04Th96eDEkWW1pICYeRUs+JV0ANip3FXJZBQ9DPzsLZBN+YzhUHxplHXlcFi0TTyllPGg0UxYGE0c3bwFrVVUheFNDE2VDOSxKF2gnAgpvCWU5E3BZTAIQWEwEMSp6ey4VBjcpOQ8+QhgFUFNCe0FHFHFkFWJsBVlEPVA1BksdLBc5Kj9pJXltNQ9VeDURPSAvSGY/PE50EE94ZlkPMjxdX1hjFyZaZko/cyUoIWJ6PRFqEjYRQndoNwcwYklGJg12TXlcG11ieBBAEFZQfwlGLGUANgBIG0sZQSs1ZHRhaiJsRFpnSFo/BlIsThl4SQp/FQhvAhAnSng1b3wcfQ40VyQDF1Q3UCkufnUZInVEeVtrWQwgWBQCL3ViaQ==' | perl -MMIME::Base64 -pe '$_=&decode_base64($_)' | od -tx1 >0000000 00 01 0a 00 6f 08 5c 76 1a 13 4d 48 05 1d 1b 07 >0000020 7d 60 1e 01 70 33 54 25 5d 48 14 0a 08 77 22 72 >[snip] > >You start with: > 00 01 (Protocol version 1) > 0a (Key Exchange Message) > 00 (reply == 0, unlike what you said) > 6f 08 5c 76 <- nonsense > >An MPI is expected here. From the Protocol document: > > > >>Multi-precision integers (MPI): >> 4 byte unsigned len, big-endian >> len byte unsigned value, big-endian >> (MPIs must use the minimum-length encoding; i.e. no leading 0x00 >> bytes. This is important when calculating public key fingerprints.) >> >> > >You seem to be missing the MPI length field. > > - Ian >_______________________________________________ >OTR-dev mailing list >OTR-dev at lists.cypherpunks.ca >http://lists.cypherpunks.ca/mailman/listinfo/otr-dev > > > From alex323 at gmail.com Sat Jan 15 17:17:21 2005 From: alex323 at gmail.com (alex323) Date: Sat, 15 Jan 2005 17:17:21 -0500 Subject: [OTR-dev] A C# lib In-Reply-To: <41E9940B.8030009@gmail.com> References: <41E8B046.4000700@gmail.com> <20050115141028.GD1060@smtp.paip.net> <41E95EA8.5070803@gmail.com> <20050115215737.GJ1060@smtp.paip.net> <41E9940B.8030009@gmail.com> Message-ID: <41E99671.5070402@gmail.com> "(len is the length of the DSA public parameter q)" <-- Sorry, I never noticed that before alex323 wrote: > I see. Let me admonish you that the .NET crypto libs are slightly > different than gcrypt. Before I read the protocol, I never knew what > an MPI was. > > "4 byte unsigned len, big-endian" > > I am assuming that that is supposed to be 4 bytes that indicate the > length of hte public key? > Thanks for your assistance and patience. > > Ian Goldberg wrote: > >> On Sat, Jan 15, 2005 at 01:19:20PM -0500, alex323 wrote: >> >> >>> Hmmm.. i'm having some problems. My friend keeps telling me that >>> there was a malformed key exchange. Maybe one of you can look at >>> what my program is generating? Thanks >>> >>> To reply to a key exchange (reply=1): >>> ?OTR:AAEKAG8IXHYaE01IBR0bB31gHgFwM1QlXUgUCgh3InJIKj5PKQkSLHgiDFwTeBkhbTUWUk0sZ2FJWlAyfnwySjdWIHYjRmxgEAxxU1NbJ1JIX0w2I2guZxFmGCF5R2AQQUgCSi88E2NeWRtcfRMtfVgJVWkbdzJ+GjR5DkkbeGFpfidvBgYPAGl/NARaACNyXz5AOhQxOSM4MwNOGncXCGE9LUM+djx3IR0IdxMaLHFvdCABDT9zJk1IfAMkZT1QYQkhGjMPJEEcegUcG2RKKDpicnMFHlsKVmdAIXk+aFcvTHZrPVV4b28lexFiKUMsJxwgSzdvfWM3IztVbXEiZRM9YA5aCA0PMy1QLFN7aB8TRR5xQGpmJzwRLEE3AggMOn1qcFNuXnkeUxdjQ1FVTWAQNHsPAz8xKkQjRCQYWEhCAzlNU01DJDVXGWMPNhpYFwp0JwlWQDITLwl/BiYCfjc6Fl04Th96eDEkWW1pICYeRUs+JV0ANip3FXJZBQ9DPzsLZBN+YzhUHxplHXlcFi0TTyllPGg0UxYGE0c3bwFrVVUheFNDE2VDOSxKF2gnAgpvCWU5E3BZTAIQWEwEMSp6ey4VBjcpOQ8+QhgFUFNCe0FHFHFkFWJsBVlEPVA1BksdLBc5Kj9pJXltNQ9VeDURPSAvSGY/PE50EE94ZlkPMjxdX1hjFyZaZko/cyUoIWJ6PRFqEjYRQndoNwcwYklGJg12TXlcG11ieBBAEFZQfwlGLGUANgBIG0sZQSs1ZHRhaiJsRFpnSFo/BlIsThl4SQp/FQhvAhAnSng1b3wcfQ40VyQDF1Q3UCkufnUZInVEeVtrWQwgWBQCL3ViaQ==. >>> >>> >> >> >> You know about otr_parse in the toolkit, right? Indeed, it says your >> message is malformed. So let's take it apart. >> >> iang at warren:~$ echo >> 'AAEKAG8IXHYaE01IBR0bB31gHgFwM1QlXUgUCgh3InJIKj5PKQkSLHgiDFwTeBkhbTUWUk0sZ2FJWlAyfnwySjdWIHYjRmxgEAxxU1NbJ1JIX0w2I2guZxFmGCF5R2AQQUgCSi88E2NeWRtcfRMtfVgJVWkbdzJ+GjR5DkkbeGFpfidvBgYPAGl/NARaACNyXz5AOhQxOSM4MwNOGncXCGE9LUM+djx3IR0IdxMaLHFvdCABDT9zJk1IfAMkZT1QYQkhGjMPJEEcegUcG2RKKDpicnMFHlsKVmdAIXk+aFcvTHZrPVV4b28lexFiKUMsJxwgSzdvfWM3IztVbXEiZRM9YA5aCA0PMy1QLFN7aB8TRR5xQGpmJzwRLEE3AggMOn1qcFNuXnkeUxdjQ1FVTWAQNHsPAz8xKkQjRCQYWEhCAzlNU01DJDVXGWMPNhpYFwp0JwlWQDITLwl/BiYCfjc6Fl04Th96eDEkWW1pICYeRUs+JV0ANip3FXJZBQ9DPzsLZBN+YzhUHxplHXlcFi0TTyllPGg0UxYGE0c3bwFrVVUheFNDE2VDOSxKF2gnAgpvCWU5E3BZTAIQWEwEMSp6ey4VBjcpOQ8+QhgFUFNCe0FHFHFkFWJsBVlEPVA1BksdLBc5Kj9pJXltNQ9VeDURPSAvSGY/PE50EE94ZlkPMjxdX1hjFyZaZko/cyUoIWJ6PRFqEjYRQndoNwcwYklGJg12TXlcG11ieBBAEFZQfwlGLGUANgBIG0sZQSs1ZHRhaiJsRFpnSFo/BlIsThl4SQp/FQhvAhAnSng1b3wcfQ40VyQDF1Q3UCkufnUZInVEeVtrWQwgWBQCL3ViaQ==' >> | perl -MMIME::Base64 -pe '$_=&decode_base64($_)' | od -tx1 >> 0000000 00 01 0a 00 6f 08 5c 76 1a 13 4d 48 05 1d 1b 07 >> 0000020 7d 60 1e 01 70 33 54 25 5d 48 14 0a 08 77 22 72 >> [snip] >> >> You start with: >> 00 01 (Protocol version 1) >> 0a (Key Exchange Message) >> 00 (reply == 0, unlike what you said) >> 6f 08 5c 76 <- nonsense >> >> An MPI is expected here. From the Protocol document: >> >> >> >>> Multi-precision integers (MPI): >>> 4 byte unsigned len, big-endian >>> len byte unsigned value, big-endian >>> (MPIs must use the minimum-length encoding; i.e. no leading 0x00 >>> bytes. This is important when calculating public key fingerprints.) >>> >> >> >> You seem to be missing the MPI length field. >> >> - Ian >> _______________________________________________ >> OTR-dev mailing list >> OTR-dev at lists.cypherpunks.ca >> http://lists.cypherpunks.ca/mailman/listinfo/otr-dev >> >> >> > > > > _______________________________________________ > OTR-dev mailing list > OTR-dev at lists.cypherpunks.ca > http://lists.cypherpunks.ca/mailman/listinfo/otr-dev > From ian at cypherpunks.ca Sat Jan 15 17:25:04 2005 From: ian at cypherpunks.ca (Ian Goldberg) Date: Sat, 15 Jan 2005 17:25:04 -0500 Subject: [OTR-dev] A C# lib In-Reply-To: <41E99671.5070402@gmail.com> References: <41E8B046.4000700@gmail.com> <20050115141028.GD1060@smtp.paip.net> <41E95EA8.5070803@gmail.com> <20050115215737.GJ1060@smtp.paip.net> <41E9940B.8030009@gmail.com> <41E99671.5070402@gmail.com> Message-ID: <20050115222504.GK1060@smtp.paip.net> On Sat, Jan 15, 2005 at 05:17:21PM -0500, alex323 wrote: > "(len is the length of the DSA public parameter q)" <-- Sorry, I never > noticed that before That's just for the DSA signature; the length is implied by the length of q. - Ian From ian at cypherpunks.ca Sat Jan 15 17:28:07 2005 From: ian at cypherpunks.ca (Ian Goldberg) Date: Sat, 15 Jan 2005 17:28:07 -0500 Subject: [OTR-dev] A C# lib In-Reply-To: <41E9940B.8030009@gmail.com> References: <41E8B046.4000700@gmail.com> <20050115141028.GD1060@smtp.paip.net> <41E95EA8.5070803@gmail.com> <20050115215737.GJ1060@smtp.paip.net> <41E9940B.8030009@gmail.com> Message-ID: <20050115222807.GL1060@smtp.paip.net> On Sat, Jan 15, 2005 at 05:07:07PM -0500, alex323 wrote: > I see. Let me admonish you that the .NET crypto libs are slightly > different than gcrypt. Before I read the protocol, I never knew what an > MPI was. The wire format in the protocol isn't the native one of libgcrypt, either. (In fact, the Protocol document was written before coding started, and I think even before libgcrypt was chosen.) It's just an easy-to-generate, easy-to-parse format. > "4 byte unsigned len, big-endian" > > I am assuming that that is supposed to be 4 bytes that indicate the > length of hte public key? That's right. - Ian From ian at cypherpunks.ca Sat Jan 15 17:43:34 2005 From: ian at cypherpunks.ca (Ian Goldberg) Date: Sat, 15 Jan 2005 17:43:34 -0500 Subject: [OTR-dev] A C# lib In-Reply-To: <41E9920B.9080808@gmail.com> References: <41E8B046.4000700@gmail.com> <20050115141028.GD1060@smtp.paip.net> <41E982A7.1040005@gmail.com> <20050115214423.GI1060@smtp.paip.net> <41E9920B.9080808@gmail.com> Message-ID: <20050115224334.GM1060@smtp.paip.net> On Sat, Jan 15, 2005 at 04:58:35PM -0500, alex323 wrote: > Thanks... as I read throught the source code (again), I see the type > "Fingerprint". What is the purpose of that? Wow, good point. There was no mention of that in the Protocol document. But I've added this paragraph to the Key Exchange Message section: > The DSA key given in this message has a "Fingerprint", which is the > SHA-1 hash of the portion of the message from the beginning of the "p" > field (including the MPI length) to the end of the "e" field. This > fingerprint should be displayed to the recipient so that he may verify > the sender's key. Sorry for the oversight. In gaim-otr, you can see the fingerprints (both yours and other people's) in the UI panel, as well as the popup that happens when a secure connection is established. > Also, do you have some kind of IM account we can talk on? > You may email it to me directly if you wish. I can often be found at otr4ian on AIM. [OTR welcomed, of course! ;-) ] -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The OTR fingerprint for otr4ian on AIM is C5D70FB3 135CB595 F2F31E01 88884CEF BDD73BD9 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBxFjp3tZOuyuofFwRAhn5AJkBC3141pudLtg4yYsiXn/u84O7/gCglIsY RP1vN6adlXi85fsk1Yi5W5Q= =AnZB -----END PGP SIGNATURE----- - Ian From alex323 at gmail.com Sat Jan 15 17:46:17 2005 From: alex323 at gmail.com (alex323) Date: Sat, 15 Jan 2005 17:46:17 -0500 Subject: [OTR-dev] A C# lib In-Reply-To: <20050115222807.GL1060@smtp.paip.net> References: <41E8B046.4000700@gmail.com> <20050115141028.GD1060@smtp.paip.net> <41E95EA8.5070803@gmail.com> <20050115215737.GJ1060@smtp.paip.net> <41E9940B.8030009@gmail.com> <20050115222807.GL1060@smtp.paip.net> Message-ID: <41E99D39.1040305@gmail.com> I think I know what I need to do now.. Do I need to insert the length of p, q, g, and e seperately? So if: p.Length = 12 q.Length = 34 g.Length = 56 e.Length = 7890 i'd have my array look like this: [4] = 0 /* It's 4 bytes per MPI */ [5] = 0 [6] = 0 [7] = 12 [8] = 0 [9] = 0 [10] = 0 [11] = 34 [12] = 0 [13] = 0 [14] = 0 [15] = 56 [16] = 0 [17] = 0 [18] = 90 /* Big-Endian right? */ [19] = 78 Please correct me if I am wrong :) Regards, Alex Ian Goldberg wrote: >On Sat, Jan 15, 2005 at 05:07:07PM -0500, alex323 wrote: > > >>I see. Let me admonish you that the .NET crypto libs are slightly >>different than gcrypt. Before I read the protocol, I never knew what an >>MPI was. >> >> > >The wire format in the protocol isn't the native one of libgcrypt, >either. (In fact, the Protocol document was written before coding >started, and I think even before libgcrypt was chosen.) It's just >an easy-to-generate, easy-to-parse format. > > > >>"4 byte unsigned len, big-endian" >> >>I am assuming that that is supposed to be 4 bytes that indicate the >>length of hte public key? >> >> > >That's right. > > - Ian >_______________________________________________ >OTR-dev mailing list >OTR-dev at lists.cypherpunks.ca >http://lists.cypherpunks.ca/mailman/listinfo/otr-dev > > > From ian at cypherpunks.ca Sat Jan 15 17:54:14 2005 From: ian at cypherpunks.ca (Ian Goldberg) Date: Sat, 15 Jan 2005 17:54:14 -0500 Subject: [OTR-dev] A C# lib In-Reply-To: <41E99D39.1040305@gmail.com> References: <41E8B046.4000700@gmail.com> <20050115141028.GD1060@smtp.paip.net> <41E95EA8.5070803@gmail.com> <20050115215737.GJ1060@smtp.paip.net> <41E9940B.8030009@gmail.com> <20050115222807.GL1060@smtp.paip.net> <41E99D39.1040305@gmail.com> Message-ID: <20050115225414.GN1060@smtp.paip.net> On Sat, Jan 15, 2005 at 05:46:17PM -0500, alex323 wrote: > I think I know what I need to do now.. Do I need to insert the length of > p, q, g, and e seperately? So if: > > p.Length = 12 > q.Length = 34 > g.Length = 56 > e.Length = 7890 > > i'd have my array look like this: > > [4] = 0 /* It's 4 bytes per MPI */ > [5] = 0 > [6] = 0 > [7] = 12 > [8] = 0 > [9] = 0 > [10] = 0 > [11] = 34 [snip] not quite right. Taking to to private comm. From mcr at sandelman.ottawa.on.ca Sat Jan 15 17:57:05 2005 From: mcr at sandelman.ottawa.on.ca (Michael Richardson) Date: Sat, 15 Jan 2005 17:57:05 -0500 Subject: [OTR-dev] otrproxy and packaging In-Reply-To: Message from Ian Goldberg of "Sat, 15 Jan 2005 10:47:32 EST." <20050115154732.GE1060@smtp.paip.net> References: <20050115154732.GE1060@smtp.paip.net> Message-ID: <7211.1105829825@marajade.sandelman.ottawa.on.ca> -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Ian" == Ian Goldberg writes: Ian> Some exciting news. We've got an AIM proxy that speaks OTR. Ian> It works on Linux (and probably other *nixes), OSX, and we even Ian> got it to work under wine with mingw (though it has not yet Ian> been tested on a "real" Win32 box). Maybe I don't understand what an AIM proxy is. I thought that gaim-otr could do communicate over AIM just like it uses other "transports". Or are you saying that you now have a stand-alone program? - -- ] Michael Richardson Xelerance Corporation, Ottawa, ON | firewalls [ ] mcr @ xelerance.com Now doing IPsec training, see |net architect[ ] http://www.sandelman.ca/mcr/ www.xelerance.com/training/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys iQCVAwUBQemfv4qHRg3pndX9AQGZvwQA6tr+arGcPyIVpcZ4wzoNdi3hr/H+v+r7 X19NxoJjCpYWbqIQV/HNF8OtcK/oeEMrG9NyeusPx5COZDvDj/sD7uOKGSMFqzft ZldCfuo6FidQRAxlTSSWnrjh1Q0XbUF3dlG4sftX/iCPDumIlC4MEvr8pmMGr8on IJ+4S1554p8= =hju2 -----END PGP SIGNATURE----- From ian at cypherpunks.ca Sat Jan 15 18:07:30 2005 From: ian at cypherpunks.ca (Ian Goldberg) Date: Sat, 15 Jan 2005 18:07:30 -0500 Subject: [OTR-dev] otrproxy and packaging In-Reply-To: <7211.1105829825@marajade.sandelman.ottawa.on.ca> References: <20050115154732.GE1060@smtp.paip.net> <7211.1105829825@marajade.sandelman.ottawa.on.ca> Message-ID: <20050115230730.GO1060@smtp.paip.net> On Sat, Jan 15, 2005 at 05:57:05PM -0500, Michael Richardson wrote: > Maybe I don't understand what an AIM proxy is. > > I thought that gaim-otr could do communicate over AIM just like it > uses other "transports". > > Or are you saying that you now have a stand-alone program? Yes, this is separate from gaim-otr, for people who don't (or can't) use gaim. It's a localhost proxy; you point your AIM client at it, and it does the OTR as messages pass through it. - Ian From alex323 at gmail.com Sat Jan 15 21:53:19 2005 From: alex323 at gmail.com (alex323) Date: Sat, 15 Jan 2005 21:53:19 -0500 Subject: [OTR-dev] Re: A C# lib In-Reply-To: <41E8B046.4000700@gmail.com> References: <41E8B046.4000700@gmail.com> Message-ID: <41E9D71F.1030206@gmail.com> All problems have been fixed. Ian and I had our first successful key exchange. alex323 wrote: > As you might have heard, I'm making a libary in C# for OTR. I have a > few questions however regarding the protocol: > > * What is the size of the DH key I need to generate? (I don't think > it's 1536.. I tried it) What about the DSA key length? > > * Why doesn't the protocol say that you need to include a NULL (byte > 0) as the first character of the key exchange message? > > * I have two editable parameters with my DH class: P and G. Should G > be set to 0x02 and P should be set to the key you generated? > > * Why is there an 'e' in the DSA key? My only options are P, Q, G, Y, > and X. Wikipedia told me that X was the private key. > > Thanks in advance for your answer(s). > From paul at cypehrpunks.ca Sat Jan 15 20:39:54 2005 From: paul at cypehrpunks.ca (paul at cypehrpunks.ca) Date: Sun, 16 Jan 2005 02:39:54 +0100 (CET) Subject: [OTR-dev] otrproxy and packaging In-Reply-To: <20050115154732.GE1060@smtp.paip.net> Message-ID: On Sat, 15 Jan 2005, Ian Goldberg wrote: > libotr > Contains the toolkit binaries, and possibly eventually libotr.so > Depends on libgcrypt > > libotr-dev > Contains libotr.a and the .h files (in /usr/include/libotr/) > Depends on libotr, libgcrypt-dev > > gaim-otr > Contains /usr/lib/gaim/gaim-otr.so > Depends on libotr, glib, gtk+, gaim > > otrproxy > Contains otrproxy > Depends on libotr > > - While this seems like the "right" way to do it, it means that people > downloading gaim-otr will now have to download the libotr package > separately. On some systems, package management will eventually do > this automatically (once everything makes its way to the official > distributions), but I don't know how this works on, say, OSX. I will turn the rpm repository in one that supports repodata, so that packet managers like yum, apt-get and up2date will just automaticly grab the dependancies. so people using redhat/FC/suse etc can just run 'yum install gaim-otr' Paul From ian at cypherpunks.ca Mon Jan 17 13:32:03 2005 From: ian at cypherpunks.ca (Ian Goldberg) Date: Mon, 17 Jan 2005 13:32:03 -0500 Subject: [OTR-dev] gaim-otr for Windows Message-ID: <20050117183203.GS1060@smtp.paip.net> I'm flailing around in the dark a bit. I managed to get a mingw toolchain to successfully compile gaim-otr.dll, and it indeed works with Windows gaim for me, under Wine. But I sent a copy to Alex, who said it crashed gaim when generating a key. Here's a copy: http://www.cypherpunks.ca/otr/gaim-otr-1.0.3.zip This is my link line: i586-mingw32msvc-gcc -g -shared -Wl,--enable-auto-image-base \ otr-plugin.o ui.o dialogs.o ../libotr/libotr.a -o ../gaim-otr.dll \ -lgcrypt -lgpg-error -lgtk-win32-2.0 -latk-1.0 -lpango-1.0 -lglib-2.0 \ -lgdk-win32-2.0 -lgobject-2.0 -lgaim As I said, it works correctly for me (under wine). Now, is it possible that crashes would happen if someone had different versions of the above libraries from the ones I scrounged around on the web for? -rw-r--r-- 1 root root 168818 Jan 17 12:37 libatk-1.0.dll -rw-r--r-- 1 root root 256174 Jan 17 12:38 libpango-1.0.dll -rw-r--r-- 1 root root 626036 Jan 17 12:39 libglib-2.0.dll -rw-r--r-- 1 root root 695862 Jan 17 12:40 libgdk-win32-2.0.dll -rw-r--r-- 1 root root 3979892 Jan 17 12:40 libgtk-win32-2.0.dll -rw-r--r-- 1 root root 279067 Jan 17 12:42 libgobject-2.0.dll -rw-r--r-- 1 root root 1045651 Jan 17 13:00 gaim.dll md5sums: 21eb6b1101193243dc36194f06f713cb libatk-1.0.dll 4ba12c8292c8f6a3edcb31df36c1b03e libpango-1.0.dll baaddd021a5cb740a5b9330a59d6053d libglib-2.0.dll b44b63f6f28d5cee8f91b5e1595720cc libgdk-win32-2.0.dll 6b07038a76175fe01c856bbdc9ae9886 libgtk-win32-2.0.dll 4899ed84060d4718f918860a55ba4860 libgobject-2.0.dll 56c356d6535c2a050471127a50668a46 gaim.dll If anyone could send me some Windows-dev-clue, I'd appreciate it. ;-) The gaim.dll above is from gaim 1.0.3. Thanks, - Ian From ian at cypherpunks.ca Mon Jan 17 14:29:24 2005 From: ian at cypherpunks.ca (Ian Goldberg) Date: Mon, 17 Jan 2005 14:29:24 -0500 Subject: [OTR-dev] gaim-otr for Windows In-Reply-To: <20050117183203.GS1060@smtp.paip.net> References: <20050117183203.GS1060@smtp.paip.net> Message-ID: <20050117192924.GT1060@smtp.paip.net> On Mon, Jan 17, 2005 at 01:32:03PM -0500, Ian Goldberg wrote: > I'm flailing around in the dark a bit. I managed to get a mingw > toolchain to successfully compile gaim-otr.dll, and it indeed works > with Windows gaim for me, under Wine. > > But I sent a copy to Alex, who said it crashed gaim when generating a > key. I've replaced the gtk libs I found on the web with the ones from the gaim-1.0.3.exe file, and rebuilt it. Can Windows gaim users tell me if it works for them? [It continues to work under wine for me.] http://www.cypherpunks.ca/otr/gaim-otr-1.0.3-rc1.zip Thanks, - Ian From alex323 at gmail.com Mon Jan 17 14:29:02 2005 From: alex323 at gmail.com (alex323) Date: Mon, 17 Jan 2005 14:29:02 -0500 Subject: [OTR-dev] gaim-otr for Windows In-Reply-To: <20050117183203.GS1060@smtp.paip.net> References: <20050117183203.GS1060@smtp.paip.net> Message-ID: <41EC11FE.5020807@gmail.com> Heh, I think the problem is that i'm running gaim v1.1.1 :) Ian Goldberg wrote: >I'm flailing around in the dark a bit. I managed to get a mingw >toolchain to successfully compile gaim-otr.dll, and it indeed works >with Windows gaim for me, under Wine. > >But I sent a copy to Alex, who said it crashed gaim when generating a >key. > >Here's a copy: http://www.cypherpunks.ca/otr/gaim-otr-1.0.3.zip > >This is my link line: > >i586-mingw32msvc-gcc -g -shared -Wl,--enable-auto-image-base \ > otr-plugin.o ui.o dialogs.o ../libotr/libotr.a -o ../gaim-otr.dll \ > -lgcrypt -lgpg-error -lgtk-win32-2.0 -latk-1.0 -lpango-1.0 -lglib-2.0 \ > -lgdk-win32-2.0 -lgobject-2.0 -lgaim > >As I said, it works correctly for me (under wine). Now, is it possible >that crashes would happen if someone had different versions of the above >libraries from the ones I scrounged around on the web for? > >-rw-r--r-- 1 root root 168818 Jan 17 12:37 libatk-1.0.dll >-rw-r--r-- 1 root root 256174 Jan 17 12:38 libpango-1.0.dll >-rw-r--r-- 1 root root 626036 Jan 17 12:39 libglib-2.0.dll >-rw-r--r-- 1 root root 695862 Jan 17 12:40 libgdk-win32-2.0.dll >-rw-r--r-- 1 root root 3979892 Jan 17 12:40 libgtk-win32-2.0.dll >-rw-r--r-- 1 root root 279067 Jan 17 12:42 libgobject-2.0.dll >-rw-r--r-- 1 root root 1045651 Jan 17 13:00 gaim.dll > >md5sums: > >21eb6b1101193243dc36194f06f713cb libatk-1.0.dll >4ba12c8292c8f6a3edcb31df36c1b03e libpango-1.0.dll >baaddd021a5cb740a5b9330a59d6053d libglib-2.0.dll >b44b63f6f28d5cee8f91b5e1595720cc libgdk-win32-2.0.dll >6b07038a76175fe01c856bbdc9ae9886 libgtk-win32-2.0.dll >4899ed84060d4718f918860a55ba4860 libgobject-2.0.dll >56c356d6535c2a050471127a50668a46 gaim.dll > >If anyone could send me some Windows-dev-clue, I'd appreciate it. ;-) > >The gaim.dll above is from gaim 1.0.3. > >Thanks, > > - Ian >_______________________________________________ >OTR-dev mailing list >OTR-dev at lists.cypherpunks.ca >http://lists.cypherpunks.ca/mailman/listinfo/otr-dev > > > From alex323 at gmail.com Mon Jan 17 16:42:04 2005 From: alex323 at gmail.com (alex323) Date: Mon, 17 Jan 2005 16:42:04 -0500 Subject: [OTR-dev] Fingerprints? Message-ID: <41EC312C.1070107@gmail.com> I'm still kind of lost on what a fingerprint is (in the OTR context) I've heard of D/RSA fingerprints.. is it the same? Is this a fingerprint?: "Calculate the session id as the SHA-1 hash of the (5+len)-byte value composed of the byte 0x00, followed by the (4+len) bytes of secbytes. When a new private connection is established, display these 8 bytes to the user as two 4-byte (big-endian) values, in C "%08x" format." From ian at cypherpunks.ca Mon Jan 17 19:24:17 2005 From: ian at cypherpunks.ca (Ian Goldberg) Date: Mon, 17 Jan 2005 19:24:17 -0500 Subject: [OTR-dev] Fingerprints? In-Reply-To: <41EC312C.1070107@gmail.com> References: <41EC312C.1070107@gmail.com> Message-ID: <20050118002417.GU1060@smtp.paip.net> On Mon, Jan 17, 2005 at 04:42:04PM -0500, alex323 wrote: > I'm still kind of lost on what a fingerprint is (in the OTR context) > I've heard of D/RSA fingerprints.. is it the same? > Is this a fingerprint?: > > "Calculate the session id as the SHA-1 hash of the (5+len)-byte value > composed of the byte 0x00, followed by the (4+len) bytes of > secbytes. When a new private connection is established, display > these 8 bytes to the user as two 4-byte (big-endian) values, in C > "%08x" format." No, that's a session id. This is a fingerprint: The DSA key given in [the Key Exchange Message] has a "Fingerprint", which is the SHA-1 hash of the portion of the message from the beginning of the "p" field (including the MPI length) to the end of the "e" field. This fingerprint should be displayed to the recipient so that he may verify the sender's key. - Ian From alex323 at gmail.com Tue Jan 18 09:01:53 2005 From: alex323 at gmail.com (alex323) Date: Tue, 18 Jan 2005 09:01:53 -0500 Subject: [OTR-dev] Fingerprints? In-Reply-To: <20050118002417.GU1060@smtp.paip.net> References: <41EC312C.1070107@gmail.com> <20050118002417.GU1060@smtp.paip.net> Message-ID: <41ED16D1.20903@gmail.com> Thanks. Ian Goldberg wrote: >On Mon, Jan 17, 2005 at 04:42:04PM -0500, alex323 wrote: > > >>I'm still kind of lost on what a fingerprint is (in the OTR context) >>I've heard of D/RSA fingerprints.. is it the same? >>Is this a fingerprint?: >> >>"Calculate the session id as the SHA-1 hash of the (5+len)-byte value >>composed of the byte 0x00, followed by the (4+len) bytes of >>secbytes. When a new private connection is established, display >>these 8 bytes to the user as two 4-byte (big-endian) values, in C >>"%08x" format." >> >> > >No, that's a session id. This is a fingerprint: > > The DSA key given in [the Key Exchange Message] has a "Fingerprint", > which is the SHA-1 hash of the portion of the message from the > beginning of the "p" field (including the MPI length) to the end of > the "e" field. This fingerprint should be displayed to the recipient > so that he may verify the sender's key. > > - Ian >_______________________________________________ >OTR-dev mailing list >OTR-dev at lists.cypherpunks.ca >http://lists.cypherpunks.ca/mailman/listinfo/otr-dev > > > From alex323 at gmail.com Tue Jan 18 09:07:06 2005 From: alex323 at gmail.com (alex323) Date: Tue, 18 Jan 2005 09:07:06 -0500 Subject: [OTR-dev] Fingerprints? In-Reply-To: <20050118002417.GU1060@smtp.paip.net> References: <41EC312C.1070107@gmail.com> <20050118002417.GU1060@smtp.paip.net> Message-ID: <41ED180A.6080208@gmail.com> Who should be responsible for storing fingerprints on the hard drive? Should the client do it? Or should the library do it? Ian Goldberg wrote: >On Mon, Jan 17, 2005 at 04:42:04PM -0500, alex323 wrote: > > >>I'm still kind of lost on what a fingerprint is (in the OTR context) >>I've heard of D/RSA fingerprints.. is it the same? >>Is this a fingerprint?: >> >>"Calculate the session id as the SHA-1 hash of the (5+len)-byte value >>composed of the byte 0x00, followed by the (4+len) bytes of >>secbytes. When a new private connection is established, display >>these 8 bytes to the user as two 4-byte (big-endian) values, in C >>"%08x" format." >> >> > >No, that's a session id. This is a fingerprint: > > The DSA key given in [the Key Exchange Message] has a "Fingerprint", > which is the SHA-1 hash of the portion of the message from the > beginning of the "p" field (including the MPI length) to the end of > the "e" field. This fingerprint should be displayed to the recipient > so that he may verify the sender's key. > > - Ian >_______________________________________________ >OTR-dev mailing list >OTR-dev at lists.cypherpunks.ca >http://lists.cypherpunks.ca/mailman/listinfo/otr-dev > > > From alex323 at gmail.com Tue Jan 18 09:20:01 2005 From: alex323 at gmail.com (alex323) Date: Tue, 18 Jan 2005 09:20:01 -0500 Subject: [OTR-dev] Fingerprints? In-Reply-To: <41ED180A.6080208@gmail.com> References: <41EC312C.1070107@gmail.com> <20050118002417.GU1060@smtp.paip.net> <41ED180A.6080208@gmail.com> Message-ID: <41ED1B11.9010501@gmail.com> In addition to that, how do you display the fingerprint to the user? alex323 wrote: > Who should be responsible for storing fingerprints on the hard drive? > Should the client do it? Or should the library do it? > > Ian Goldberg wrote: > >> On Mon, Jan 17, 2005 at 04:42:04PM -0500, alex323 wrote: >> >> >>> I'm still kind of lost on what a fingerprint is (in the OTR context) >>> I've heard of D/RSA fingerprints.. is it the same? >>> Is this a fingerprint?: >>> >>> "Calculate the session id as the SHA-1 hash of the (5+len)-byte value >>> composed of the byte 0x00, followed by the (4+len) bytes of >>> secbytes. When a new private connection is established, display >>> these 8 bytes to the user as two 4-byte (big-endian) values, in C >>> "%08x" format." >>> >> >> >> No, that's a session id. This is a fingerprint: >> >> The DSA key given in [the Key Exchange Message] has a "Fingerprint", >> which is the SHA-1 hash of the portion of the message from the >> beginning of the "p" field (including the MPI length) to the end of >> the "e" field. This fingerprint should be displayed to the recipient >> so that he may verify the sender's key. >> >> - Ian >> _______________________________________________ >> OTR-dev mailing list >> OTR-dev at lists.cypherpunks.ca >> http://lists.cypherpunks.ca/mailman/listinfo/otr-dev >> >> >> > > > _______________________________________________ > OTR-dev mailing list > OTR-dev at lists.cypherpunks.ca > http://lists.cypherpunks.ca/mailman/listinfo/otr-dev > From ian at cypherpunks.ca Tue Jan 18 10:05:55 2005 From: ian at cypherpunks.ca (Ian Goldberg) Date: Tue, 18 Jan 2005 10:05:55 -0500 Subject: [OTR-dev] Fingerprints? In-Reply-To: <41ED180A.6080208@gmail.com> References: <41EC312C.1070107@gmail.com> <20050118002417.GU1060@smtp.paip.net> <41ED180A.6080208@gmail.com> Message-ID: <20050118150555.GX1060@smtp.paip.net> On Tue, Jan 18, 2005 at 09:07:06AM -0500, alex323 wrote: > Who should be responsible for storing fingerprints on the hard drive? > Should the client do it? Or should the library do it? libotr has a call (otrl_privkey_write_fingerprints) for that. - Ian From ian at cypherpunks.ca Tue Jan 18 10:06:57 2005 From: ian at cypherpunks.ca (Ian Goldberg) Date: Tue, 18 Jan 2005 10:06:57 -0500 Subject: [OTR-dev] Fingerprints? In-Reply-To: <41ED1B11.9010501@gmail.com> References: <41EC312C.1070107@gmail.com> <20050118002417.GU1060@smtp.paip.net> <41ED180A.6080208@gmail.com> <41ED1B11.9010501@gmail.com> Message-ID: <20050118150657.GY1060@smtp.paip.net> On Tue, Jan 18, 2005 at 09:20:01AM -0500, alex323 wrote: > In addition to that, how do you display the fingerprint to the user? Like this: C5D70FB3 135CB595 F2F31E01 88884CEF BDD73BD9 - Ian From ian at cypherpunks.ca Tue Jan 18 10:11:27 2005 From: ian at cypherpunks.ca (Ian Goldberg) Date: Tue, 18 Jan 2005 10:11:27 -0500 Subject: [OTR-dev] gaim-otr for Windows In-Reply-To: <20050117183203.GS1060@smtp.paip.net> References: <20050117183203.GS1060@smtp.paip.net> Message-ID: <20050118151127.GZ1060@smtp.paip.net> On Mon, Jan 17, 2005 at 01:32:03PM -0500, Ian Goldberg wrote: > As I said, it works correctly for me (under wine). Now, is it possible > that crashes would happen if someone had different versions of the above > libraries from the ones I scrounged around on the web for? w00t! A whole lot of fprintfs later, I tracked down the bug. It was actually a bug in libgcrypt's randomness gatherer: the win32 version walks the memory heap table and adds everything in it to the randomness pool. But adding things to the pool can change the table. If the change is to add something after the place in the table you're currently scanning, you get an infinite loop. I've patched the win32 libgcrypt, and sent a fix to the maintainers. Since we statically link libgcrypt on win32, there's no problem, and we'll just link in the fixed version. Yay! gaim-otr now works on Windows. - Ian From alex323 at gmail.com Tue Jan 18 11:31:51 2005 From: alex323 at gmail.com (alex323) Date: Tue, 18 Jan 2005 11:31:51 -0500 Subject: [OTR-dev] AES128 CTR? Message-ID: <41ED39F7.1040700@gmail.com> You say that you need to use AES128 Counter mode, but I cannot find any libs anywhere for it. (.NET) Does it go by another alias? From alex323 at gmail.com Tue Jan 18 11:33:59 2005 From: alex323 at gmail.com (alex323) Date: Tue, 18 Jan 2005 11:33:59 -0500 Subject: [OTR-dev] gaim-otr for Windows In-Reply-To: <20050118151127.GZ1060@smtp.paip.net> References: <20050117183203.GS1060@smtp.paip.net> <20050118151127.GZ1060@smtp.paip.net> Message-ID: <41ED3A77.6010902@gmail.com> When do you plan on releasing? Ian Goldberg wrote: >On Mon, Jan 17, 2005 at 01:32:03PM -0500, Ian Goldberg wrote: > > >>As I said, it works correctly for me (under wine). Now, is it possible >>that crashes would happen if someone had different versions of the above >>libraries from the ones I scrounged around on the web for? >> >> > >w00t! > >A whole lot of fprintfs later, I tracked down the bug. > >It was actually a bug in libgcrypt's randomness gatherer: the win32 >version walks the memory heap table and adds everything in it to the >randomness pool. But adding things to the pool can change the table. >If the change is to add something after the place in the table you're >currently scanning, you get an infinite loop. > >I've patched the win32 libgcrypt, and sent a fix to the maintainers. >Since we statically link libgcrypt on win32, there's no problem, and >we'll just link in the fixed version. > >Yay! gaim-otr now works on Windows. > > - Ian >_______________________________________________ >OTR-dev mailing list >OTR-dev at lists.cypherpunks.ca >http://lists.cypherpunks.ca/mailman/listinfo/otr-dev > > > From paul at cypherpunks.ca Tue Jan 18 11:44:46 2005 From: paul at cypherpunks.ca (Paul Wouters) Date: Tue, 18 Jan 2005 17:44:46 +0100 (CET) Subject: [OTR-dev] gaim-otr for Windows In-Reply-To: <20050118151127.GZ1060@smtp.paip.net> Message-ID: On Tue, 18 Jan 2005, Ian Goldberg wrote: > Yay! gaim-otr now works on Windows. Excellent! It also explains why my laptop looked dead. You shut it down :) Paul From ian at cypherpunks.ca Tue Jan 18 11:57:13 2005 From: ian at cypherpunks.ca (Ian Goldberg) Date: Tue, 18 Jan 2005 11:57:13 -0500 Subject: [OTR-dev] gaim-otr for Windows In-Reply-To: <41ED3A77.6010902@gmail.com> References: <20050117183203.GS1060@smtp.paip.net> <20050118151127.GZ1060@smtp.paip.net> <41ED3A77.6010902@gmail.com> Message-ID: <20050118165713.GB1060@smtp.paip.net> On Tue, Jan 18, 2005 at 11:33:59AM -0500, alex323 wrote: > When do you plan on releasing? Probably later today or tomorrow, time permitting. - Ian From ian at cypherpunks.ca Tue Jan 18 12:07:33 2005 From: ian at cypherpunks.ca (Ian Goldberg) Date: Tue, 18 Jan 2005 12:07:33 -0500 Subject: [OTR-dev] AES128 CTR? In-Reply-To: <41ED39F7.1040700@gmail.com> References: <41ED39F7.1040700@gmail.com> Message-ID: <20050118170733.GC1060@smtp.paip.net> On Tue, Jan 18, 2005 at 11:31:51AM -0500, alex323 wrote: > You say that you need to use AES128 Counter mode, but I cannot find any > libs anywhere for it. (.NET) Does it go by another alias? You surely have AES. (The 128 denotes the version with a 128-bit key.) If you don't have counter mode, I'd be a little surprised, but it's really easy to do yourself. See ctrmode.c in the toolkit source. http://www.tcs.hut.fi/~helger/papers/lrw00/ is a good paper about it, including a section which describes it in detail. - Ian From alex323 at gmail.com Tue Jan 18 12:08:01 2005 From: alex323 at gmail.com (alex323) Date: Tue, 18 Jan 2005 12:08:01 -0500 Subject: [OTR-dev] AES128 CTR? In-Reply-To: <20050118170733.GC1060@smtp.paip.net> References: <41ED39F7.1040700@gmail.com> <20050118170733.GC1060@smtp.paip.net> Message-ID: <41ED4271.8010609@gmail.com> Thanks, Ill do my best. Ian Goldberg wrote: >On Tue, Jan 18, 2005 at 11:31:51AM -0500, alex323 wrote: > > >>You say that you need to use AES128 Counter mode, but I cannot find any >>libs anywhere for it. (.NET) Does it go by another alias? >> >> > >You surely have AES. (The 128 denotes the version with a 128-bit key.) >If you don't have counter mode, I'd be a little surprised, but it's >really easy to do yourself. See ctrmode.c in the toolkit source. > >http://www.tcs.hut.fi/~helger/papers/lrw00/ is a good paper about it, >including a section which describes it in detail. > > - Ian >_______________________________________________ >OTR-dev mailing list >OTR-dev at lists.cypherpunks.ca >http://lists.cypherpunks.ca/mailman/listinfo/otr-dev > > > From alex323 at gmail.com Tue Jan 18 12:22:53 2005 From: alex323 at gmail.com (alex323) Date: Tue, 18 Jan 2005 12:22:53 -0500 Subject: [OTR-dev] AES128 CTR? In-Reply-To: <20050118170733.GC1060@smtp.paip.net> References: <41ED39F7.1040700@gmail.com> <20050118170733.GC1060@smtp.paip.net> Message-ID: <41ED45ED.3030805@gmail.com> I do have Rijndael. Is it the same thing? Ian Goldberg wrote: >On Tue, Jan 18, 2005 at 11:31:51AM -0500, alex323 wrote: > > >>You say that you need to use AES128 Counter mode, but I cannot find any >>libs anywhere for it. (.NET) Does it go by another alias? >> >> > >You surely have AES. (The 128 denotes the version with a 128-bit key.) >If you don't have counter mode, I'd be a little surprised, but it's >really easy to do yourself. See ctrmode.c in the toolkit source. > >http://www.tcs.hut.fi/~helger/papers/lrw00/ is a good paper about it, >including a section which describes it in detail. > > - Ian >_______________________________________________ >OTR-dev mailing list >OTR-dev at lists.cypherpunks.ca >http://lists.cypherpunks.ca/mailman/listinfo/otr-dev > > > From ian at cypherpunks.ca Tue Jan 18 12:35:21 2005 From: ian at cypherpunks.ca (Ian Goldberg) Date: Tue, 18 Jan 2005 12:35:21 -0500 Subject: [OTR-dev] AES128 CTR? In-Reply-To: <41ED45ED.3030805@gmail.com> References: <41ED39F7.1040700@gmail.com> <20050118170733.GC1060@smtp.paip.net> <41ED45ED.3030805@gmail.com> Message-ID: <20050118173521.GE1060@smtp.paip.net> On Tue, Jan 18, 2005 at 12:22:53PM -0500, alex323 wrote: > I do have Rijndael. Is it the same thing? Yes. - Ian From alex323 at gmail.com Tue Jan 18 14:07:45 2005 From: alex323 at gmail.com (alex323) Date: Tue, 18 Jan 2005 14:07:45 -0500 Subject: [OTR-dev] AES128 CTR? In-Reply-To: <20050118173521.GE1060@smtp.paip.net> References: <41ED39F7.1040700@gmail.com> <20050118170733.GC1060@smtp.paip.net> <41ED45ED.3030805@gmail.com> <20050118173521.GE1060@smtp.paip.net> Message-ID: <41ED5E81.2020503@gmail.com> Nice. Rijndael requires a few parameters. It requires a plain text, passphrase, salt, hash algo, # of password iterations, an IV, and a keysize. I'm assuming that the passphrase is the "sending/receiving AES key", the salt can be anything, the hash algo is sha1, the # of password iterations is 2, the IV is anything, and they keysize is 256. is this right? Please correct me if I am wrong. See: http://www.obviex.com/samples/Encryption.aspx Ian Goldberg wrote: >On Tue, Jan 18, 2005 at 12:22:53PM -0500, alex323 wrote: > > >>I do have Rijndael. Is it the same thing? >> >> > >Yes. > > - Ian >_______________________________________________ >OTR-dev mailing list >OTR-dev at lists.cypherpunks.ca >http://lists.cypherpunks.ca/mailman/listinfo/otr-dev > > > From ian at cypherpunks.ca Tue Jan 18 15:53:58 2005 From: ian at cypherpunks.ca (Ian Goldberg) Date: Tue, 18 Jan 2005 15:53:58 -0500 Subject: [OTR-dev] AES128 CTR? In-Reply-To: <41ED5E81.2020503@gmail.com> References: <41ED39F7.1040700@gmail.com> <20050118170733.GC1060@smtp.paip.net> <41ED45ED.3030805@gmail.com> <20050118173521.GE1060@smtp.paip.net> <41ED5E81.2020503@gmail.com> Message-ID: <20050118205358.GF1060@smtp.paip.net> On Tue, Jan 18, 2005 at 02:07:45PM -0500, alex323 wrote: > Nice. Rijndael requires a few parameters. It requires a plain text, > passphrase, salt, hash algo, # of password iterations, an IV, and a > keysize. I'm assuming that the passphrase is the "sending/receiving AES > key", the salt can be anything, the hash algo is sha1, the # of password > iterations is 2, the IV is anything, and they keysize is 256. is this > right? Please correct me if I am wrong. See: > http://www.obviex.com/samples/Encryption.aspx No, that's not right. The parameters for that class seem to indicate it's using a stretched passphrase for the key, then doing AES256 in CBC mode. OTR gives you the key directly, and uses AES128 in CTR mode. - Ian From alex323 at gmail.com Tue Jan 18 19:39:44 2005 From: alex323 at gmail.com (alex323) Date: Tue, 18 Jan 2005 19:39:44 -0500 Subject: [OTR-dev] AES128 CTR? In-Reply-To: <20050118205358.GF1060@smtp.paip.net> References: <41ED39F7.1040700@gmail.com> <20050118170733.GC1060@smtp.paip.net> <41ED45ED.3030805@gmail.com> <20050118173521.GE1060@smtp.paip.net> <41ED5E81.2020503@gmail.com> <20050118205358.GF1060@smtp.paip.net> Message-ID: <41EDAC50.5010901@gmail.com> That class does have a CTS mode: RijndaelManaged rm = new RijndaelManaged(); rm.Mode = CipherMode.CTS; Do you think it's the same? Ian Goldberg wrote: >On Tue, Jan 18, 2005 at 02:07:45PM -0500, alex323 wrote: > > >>Nice. Rijndael requires a few parameters. It requires a plain text, >>passphrase, salt, hash algo, # of password iterations, an IV, and a >>keysize. I'm assuming that the passphrase is the "sending/receiving AES >>key", the salt can be anything, the hash algo is sha1, the # of password >>iterations is 2, the IV is anything, and they keysize is 256. is this >>right? Please correct me if I am wrong. See: >>http://www.obviex.com/samples/Encryption.aspx >> >> > >No, that's not right. The parameters for that class seem to indicate >it's using a stretched passphrase for the key, then doing AES256 in CBC >mode. > >OTR gives you the key directly, and uses AES128 in CTR mode. > > - Ian >_______________________________________________ >OTR-dev mailing list >OTR-dev at lists.cypherpunks.ca >http://lists.cypherpunks.ca/mailman/listinfo/otr-dev > > > From nikitab at cs.berkeley.edu Tue Jan 18 19:46:40 2005 From: nikitab at cs.berkeley.edu (Nikita Borisov) Date: Tue, 18 Jan 2005 16:46:40 -0800 Subject: [OTR-dev] AES128 CTR? In-Reply-To: <41EDAC50.5010901@gmail.com> References: <41ED39F7.1040700@gmail.com> <20050118170733.GC1060@smtp.paip.net> <41ED45ED.3030805@gmail.com> <20050118173521.GE1060@smtp.paip.net> <41ED5E81.2020503@gmail.com> <20050118205358.GF1060@smtp.paip.net> <41EDAC50.5010901@gmail.com> Message-ID: <94CEEEAC-69B3-11D9-A11B-000A95873CEC@cs.berkeley.edu> On Jan 18, 2005, at 4:39 PM, alex323 wrote: > That class does have a CTS mode: > > RijndaelManaged rm = new RijndaelManaged(); > rm.Mode = CipherMode.CTS; > > Do you think it's the same? No, CTS mode is ciphertext stealing mode, which is quite different from CTR. Looking at the description, you're going to have to implement your own CTR mode. Like Ian said, ctrmode.c in the toolkit source has a sample implementation. - Nikita From alex323 at gmail.com Tue Jan 18 19:52:59 2005 From: alex323 at gmail.com (alex323) Date: Tue, 18 Jan 2005 19:52:59 -0500 Subject: [OTR-dev] AES128 CTR? In-Reply-To: <94CEEEAC-69B3-11D9-A11B-000A95873CEC@cs.berkeley.edu> References: <41ED39F7.1040700@gmail.com> <20050118170733.GC1060@smtp.paip.net> <41ED45ED.3030805@gmail.com> <20050118173521.GE1060@smtp.paip.net> <41ED5E81.2020503@gmail.com> <20050118205358.GF1060@smtp.paip.net> <41EDAC50.5010901@gmail.com> <94CEEEAC-69B3-11D9-A11B-000A95873CEC@cs.berkeley.edu> Message-ID: <41EDAF6B.7020602@gmail.com> That also means I need to code my own AES implementation as well :( Nikita Borisov wrote: > > On Jan 18, 2005, at 4:39 PM, alex323 wrote: > >> That class does have a CTS mode: >> >> RijndaelManaged rm = new RijndaelManaged(); >> rm.Mode = CipherMode.CTS; >> >> Do you think it's the same? > > > No, CTS mode is ciphertext stealing mode, which is quite different > from CTR. Looking at the description, you're going to have to > implement your own CTR mode. Like Ian said, ctrmode.c in the toolkit > source has a sample implementation. > > - Nikita > > _______________________________________________ > OTR-dev mailing list > OTR-dev at lists.cypherpunks.ca > http://lists.cypherpunks.ca/mailman/listinfo/otr-dev > From nikitab at cs.berkeley.edu Tue Jan 18 20:00:43 2005 From: nikitab at cs.berkeley.edu (Nikita Borisov) Date: Tue, 18 Jan 2005 17:00:43 -0800 Subject: [OTR-dev] AES128 CTR? In-Reply-To: <41EDAF6B.7020602@gmail.com> References: <41ED39F7.1040700@gmail.com> <20050118170733.GC1060@smtp.paip.net> <41ED45ED.3030805@gmail.com> <20050118173521.GE1060@smtp.paip.net> <41ED5E81.2020503@gmail.com> <20050118205358.GF1060@smtp.paip.net> <41EDAC50.5010901@gmail.com> <94CEEEAC-69B3-11D9-A11B-000A95873CEC@cs.berkeley.edu> <41EDAF6B.7020602@gmail.com> Message-ID: <8BA2F5A5-69B5-11D9-A11B-000A95873CEC@cs.berkeley.edu> On Jan 18, 2005, at 4:52 PM, alex323 wrote: > That also means I need to code my own AES implementation as well :( Probably not; you should be able to use the AES implementation in ECB mode to encrypt the counter value. - Nikita From alex323 at gmail.com Tue Jan 18 20:51:29 2005 From: alex323 at gmail.com (alex323) Date: Tue, 18 Jan 2005 20:51:29 -0500 Subject: [OTR-dev] AES128 CTR? In-Reply-To: <8BA2F5A5-69B5-11D9-A11B-000A95873CEC@cs.berkeley.edu> References: <41ED39F7.1040700@gmail.com> <20050118170733.GC1060@smtp.paip.net> <41ED45ED.3030805@gmail.com> <20050118173521.GE1060@smtp.paip.net> <41ED5E81.2020503@gmail.com> <20050118205358.GF1060@smtp.paip.net> <41EDAC50.5010901@gmail.com> <94CEEEAC-69B3-11D9-A11B-000A95873CEC@cs.berkeley.edu> <41EDAF6B.7020602@gmail.com> <8BA2F5A5-69B5-11D9-A11B-000A95873CEC@cs.berkeley.edu> Message-ID: <41EDBD21.80903@gmail.com> "This should monotonically increase (as a big-endian value) for each message sent with the same (sender keyid, recipient keyid) pair , and must not be all 0x00." So I am assuming that whenever the sender keyid and recipient keyid are the same, i add one to the counter. For example: 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x02 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x03 ... "The initial counter is a 16-byte value whose first 8 bytes are the above "top half of counter init" value, and whose last 8 bytes are all 0x00." And this should be: 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x02, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x03, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 Correct? Nikita Borisov wrote: > > On Jan 18, 2005, at 4:52 PM, alex323 wrote: > >> That also means I need to code my own AES implementation as well :( > > > Probably not; you should be able to use the AES implementation in ECB > mode to encrypt the counter value. > > - Nikita > > _______________________________________________ > OTR-dev mailing list > OTR-dev at lists.cypherpunks.ca > http://lists.cypherpunks.ca/mailman/listinfo/otr-dev > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 825 bytes Desc: OpenPGP digital signature URL: From alex323 at gmail.com Tue Jan 18 21:03:53 2005 From: alex323 at gmail.com (alex323) Date: Tue, 18 Jan 2005 21:03:53 -0500 Subject: [OTR-dev] AES128 CTR? In-Reply-To: <41EDBD21.80903@gmail.com> References: <41ED39F7.1040700@gmail.com> <20050118170733.GC1060@smtp.paip.net> <41ED45ED.3030805@gmail.com> <20050118173521.GE1060@smtp.paip.net> <41ED5E81.2020503@gmail.com> <20050118205358.GF1060@smtp.paip.net> <41EDAC50.5010901@gmail.com> <94CEEEAC-69B3-11D9-A11B-000A95873CEC@cs.berkeley.edu> <41EDAF6B.7020602@gmail.com> <8BA2F5A5-69B5-11D9-A11B-000A95873CEC@cs.berkeley.edu> <41EDBD21.80903@gmail.com> Message-ID: <41EDC009.7030703@gmail.com> Just for reference, here is the code i am using: public static byte[] Cipher(byte[] data, byte[] key, bool encrypt) { RijndaelManaged rm = new RijndaelManaged(); rm.Mode = CipherMode.ECB; ICryptoTransform cipherer; if(encrypt) { cipherer = rm.CreateEncryptor(key,new byte[4] { 0x00,0x00,0x00,0x01 }); } else { cipherer = rm.CreateDecryptor(key,new byte[4] { 0x00,0x00,0x00,0x01 }); } MemoryStream ms = new MemoryStream(); CryptoStream cs = new CryptoStream(ms, cipherer, CryptoStreamMode.Write); cs.Write(data, 0, data.Length); cs.FlushFinalBlock(); byte[] cipherTextBytes = ms.ToArray(); ms.Close(); cs.Close(); return cipherTextBytes; } ... byte[] data = new byte[20] {0xC5,0xD7,0x0F,0xB3,0x13,0x5C,0xB5,0x95,0xF2,0xF3,0x1E,0x01,0x88,0x88,0x4C,0xEF,0xBD,0xD7,0x3B,0xD9}; byte[] key = new byte[16] {0xC5,0xD7,0x0F,0xB3,0x13,0x5C,0xB5,0x95,0xF2,0xF3,0x1E,0x01,0x88,0x88,0x4C,0xEF}; byte[] enc = ctrmode.Cipher(data,key,true); byte[] dec = ctrmode.Cipher(enc,key,false); enc.Length == 32 bytes dec.Length == 20 bytes As you say in the protocol, the ctr will never change the length of the message. I assume this is what is happening here. enc reads this: 6D 84 FA 45 8A B6 BB 6A 94 89 9D 53 2A 21 85 72 CA 08 E3 8B 83 B5 91 95 B1 CF 65 49 BE EA 82 30 and dec == data Did I do this right? Thanks Regards, Alex alex323 wrote: > "This should monotonically increase (as a big-endian value) for > each message sent with the same (sender keyid, recipient keyid) > pair , and must not be all 0x00." > > > So I am assuming that whenever the sender keyid and recipient keyid > are the same, i add one to the counter. For example: > > 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01 > 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x02 > 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x03 > ... > > "The initial counter is a 16-byte value whose first 8 > bytes are the above "top half of counter init" value, and whose > last 8 bytes are all 0x00." > > And this should be: > > 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0x00, 0x00, 0x00, > 0x00, 0x00, 0x00, 0x00, 0x00 > 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x02, 0x00, 0x00, 0x00, > 0x00, 0x00, 0x00, 0x00, 0x00 > 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x03, 0x00, 0x00, 0x00, > 0x00, 0x00, 0x00, 0x00, 0x00 > > Correct? > > > Nikita Borisov wrote: > >> >> On Jan 18, 2005, at 4:52 PM, alex323 wrote: >> >>> That also means I need to code my own AES implementation as well :( >> >> >> >> Probably not; you should be able to use the AES implementation in ECB >> mode to encrypt the counter value. >> >> - Nikita >> >> _______________________________________________ >> OTR-dev mailing list >> OTR-dev at lists.cypherpunks.ca >> http://lists.cypherpunks.ca/mailman/listinfo/otr-dev >> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 825 bytes Desc: OpenPGP digital signature URL: From ian at cypherpunks.ca Tue Jan 18 21:06:31 2005 From: ian at cypherpunks.ca (Ian Goldberg) Date: Tue, 18 Jan 2005 21:06:31 -0500 Subject: [OTR-dev] AES128 CTR? In-Reply-To: <41EDBD21.80903@gmail.com> References: <20050118170733.GC1060@smtp.paip.net> <41ED45ED.3030805@gmail.com> <20050118173521.GE1060@smtp.paip.net> <41ED5E81.2020503@gmail.com> <20050118205358.GF1060@smtp.paip.net> <41EDAC50.5010901@gmail.com> <94CEEEAC-69B3-11D9-A11B-000A95873CEC@cs.berkeley.edu> <41EDAF6B.7020602@gmail.com> <8BA2F5A5-69B5-11D9-A11B-000A95873CEC@cs.berkeley.edu> <41EDBD21.80903@gmail.com> Message-ID: <20050119020631.GJ1060@smtp.paip.net> On Tue, Jan 18, 2005 at 08:51:29PM -0500, alex323 wrote: > "This should monotonically increase (as a big-endian value) for > each message sent with the same (sender keyid, recipient keyid) > pair , and must not be all 0x00." > > > So I am assuming that whenever the sender keyid and recipient keyid are > the same, i add one to the counter. For example: That's correct, where "the sender keyid and recipient keyid are the same" means "they're both the same as last time", not "they're the same as each other". > 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01 > 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x02 > 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x03 > ... > > "The initial counter is a 16-byte value whose first 8 > bytes are the above "top half of counter init" value, and whose > last 8 bytes are all 0x00." > > And this should be: > > 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0x00, 0x00, 0x00, 0x00, > 0x00, 0x00, 0x00, 0x00 > 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x02, 0x00, 0x00, 0x00, 0x00, > 0x00, 0x00, 0x00, 0x00 > 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x03, 0x00, 0x00, 0x00, 0x00, > 0x00, 0x00, 0x00, 0x00 > > Correct? Yes. - Ian From alex323 at gmail.com Tue Jan 18 21:34:56 2005 From: alex323 at gmail.com (alex323) Date: Tue, 18 Jan 2005 21:34:56 -0500 Subject: [OTR-dev] Fingerprints? In-Reply-To: <41EC312C.1070107@gmail.com> References: <41EC312C.1070107@gmail.com> Message-ID: <41EDC750.1040309@gmail.com> Do you remove the NULs at the beginning of the MPI when you are generating your session key? (secbytes). Write the value of secret as a minimum-length MPI, as specific above (4-byte big-endian len, len-byte big-endian value). Let this (4+len)-byte value be "secbytes". That seems to indicate to me that you leave the NULs there. alex323 wrote: > I'm still kind of lost on what a fingerprint is (in the OTR context) > I've heard of D/RSA fingerprints.. is it the same? > Is this a fingerprint?: > > "Calculate the session id as the SHA-1 hash of the (5+len)-byte value > composed of the byte 0x00, followed by the (4+len) bytes of > secbytes. When a new private connection is established, display > these 8 bytes to the user as two 4-byte (big-endian) values, in C > "%08x" format." > > _______________________________________________ > OTR-dev mailing list > OTR-dev at lists.cypherpunks.ca > http://lists.cypherpunks.ca/mailman/listinfo/otr-dev > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 825 bytes Desc: OpenPGP digital signature URL: From ian at cypherpunks.ca Tue Jan 18 23:53:52 2005 From: ian at cypherpunks.ca (Ian Goldberg) Date: Tue, 18 Jan 2005 23:53:52 -0500 Subject: [OTR-dev] Fingerprints? In-Reply-To: <41EDC750.1040309@gmail.com> References: <41EC312C.1070107@gmail.com> <41EDC750.1040309@gmail.com> Message-ID: <20050119045352.GL1060@smtp.paip.net> On Tue, Jan 18, 2005 at 09:34:56PM -0500, alex323 wrote: > Do you remove the NULs at the beginning of the MPI when you are > generating your session key? (secbytes). > > Write the value of secret as a minimum-length MPI, as specific above > (4-byte big-endian len, len-byte big-endian value). Let this > (4+len)-byte value be "secbytes". > > > That seems to indicate to me that you leave the NULs there. "minimum length" indicates the removal of leading 0x00 bytes. Let's say you've got an MPI with the (implausibly small) value of 0x123456. Mathematically, that's the same number as 0x00123456 or 0x000000000000123456. What the above is saying is that you need to encode it as 00000003123456, not 0000000400123456 or any other such thing. - Ian From alex323 at gmail.com Wed Jan 19 08:08:11 2005 From: alex323 at gmail.com (alex323) Date: Wed, 19 Jan 2005 08:08:11 -0500 Subject: [OTR-dev] Fingerprints? In-Reply-To: <20050119045352.GL1060@smtp.paip.net> References: <41EC312C.1070107@gmail.com> <41EDC750.1040309@gmail.com> <20050119045352.GL1060@smtp.paip.net> Message-ID: <41EE5BBB.8080400@gmail.com> "What the above is saying is that you need to encode it as 00000003123456, not 0000000400123456 or any other such thing." Why wouldn't it be encoded as 6123456? 0x00123456 == 0x123456 == (len = 6) == 0x0006123456 == 0x6123456 ^^ Right? ^^ Regards, Alex Ian Goldberg wrote: >On Tue, Jan 18, 2005 at 09:34:56PM -0500, alex323 wrote: > > >>Do you remove the NULs at the beginning of the MPI when you are >>generating your session key? (secbytes). >> >>Write the value of secret as a minimum-length MPI, as specific above >> (4-byte big-endian len, len-byte big-endian value). Let this >> (4+len)-byte value be "secbytes". >> >> >>That seems to indicate to me that you leave the NULs there. >> >> > >"minimum length" indicates the removal of leading 0x00 bytes. > >Let's say you've got an MPI with the (implausibly small) value of >0x123456. MathemaWtically, that's the same number as 0x00123456 >or 0x000000000000123456. What the above is saying is that you need >to encode it as 00000003123456, not 0000000400123456 or any other >such thing. > > - Ian >_______________________________________________ >OTR-dev mailing list >OTR-dev at lists.cypherpunks.ca >http://lists.cypherpunks.ca/mailman/listinfo/otr-dev > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 825 bytes Desc: OpenPGP digital signature URL: From ian at cypherpunks.ca Wed Jan 19 09:39:11 2005 From: ian at cypherpunks.ca (Ian Goldberg) Date: Wed, 19 Jan 2005 09:39:11 -0500 Subject: [OTR-dev] Fingerprints? In-Reply-To: <41EE5BBB.8080400@gmail.com> References: <41EC312C.1070107@gmail.com> <41EDC750.1040309@gmail.com> <20050119045352.GL1060@smtp.paip.net> <41EE5BBB.8080400@gmail.com> Message-ID: <20050119143911.GP1060@smtp.paip.net> On Wed, Jan 19, 2005 at 08:08:11AM -0500, alex323 wrote: > "What the above is saying is that you need > to encode it as 00000003123456, not 0000000400123456 or any other > such thing." > > Why wouldn't it be encoded as 6123456? > > 0x00123456 == 0x123456 == (len = 6) == 0x0006123456 == 0x6123456 > > ^^ Right? ^^ No. The length of 0x123456 is 3 bytes: 0x12, 0x34, 0x56. *First* remove any leading 0x00 bytes from the MPI. *Next* find the resulting length of the (possibly shorter) MPI, in bytes. *Finally*, output the length (as a four-byte value), followed by that many bytes of MPI data. The result will almost certainly have leading 0x00 bytes, but only in the length field, which is probably smaller than 0x01000000. - Ian From alex323 at gmail.com Wed Jan 19 15:50:04 2005 From: alex323 at gmail.com (alex323) Date: Wed, 19 Jan 2005 15:50:04 -0500 Subject: [OTR-dev] Fingerprints? In-Reply-To: <20050119143911.GP1060@smtp.paip.net> References: <41EC312C.1070107@gmail.com> <41EDC750.1040309@gmail.com> <20050119045352.GL1060@smtp.paip.net> <41EE5BBB.8080400@gmail.com> <20050119143911.GP1060@smtp.paip.net> Message-ID: <41EEC7FC.1090803@gmail.com> Heh, I saw my mistake now. Fixed: 0x00123456 == 0x123456 == (len = 3) == 0x0003123456 == 0x3123456 Whoops! Thanks Alex Ian Goldberg wrote: >On Wed, Jan 19, 2005 at 08:08:11AM -0500, alex323 wrote: > > >>"What the above is saying is that you need >>to encode it as 00000003123456, not 0000000400123456 or any other >>such thing." >> >>Why wouldn't it be encoded as 6123456? >> >>0x00123456 == 0x123456 == (len = 6) == 0x0006123456 == 0x6123456 >> >>^^ Right? ^^ >> >> > >No. The length of 0x123456 is 3 bytes: 0x12, 0x34, 0x56. > >*First* remove any leading 0x00 bytes from the MPI. >*Next* find the resulting length of the (possibly shorter) MPI, in bytes. >*Finally*, output the length (as a four-byte value), followed by that > many bytes of MPI data. > >The result will almost certainly have leading 0x00 bytes, but only in >the length field, which is probably smaller than 0x01000000. > > - Ian >_______________________________________________ >OTR-dev mailing list >OTR-dev at lists.cypherpunks.ca >http://lists.cypherpunks.ca/mailman/listinfo/otr-dev > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 825 bytes Desc: OpenPGP digital signature URL: From ian at cypherpunks.ca Wed Jan 19 16:48:45 2005 From: ian at cypherpunks.ca (Ian Goldberg) Date: Wed, 19 Jan 2005 16:48:45 -0500 Subject: [OTR-dev] Fingerprints? In-Reply-To: <41EEC7FC.1090803@gmail.com> References: <41EC312C.1070107@gmail.com> <41EDC750.1040309@gmail.com> <20050119045352.GL1060@smtp.paip.net> <41EE5BBB.8080400@gmail.com> <20050119143911.GP1060@smtp.paip.net> <41EEC7FC.1090803@gmail.com> Message-ID: <20050119214845.GT1060@smtp.paip.net> On Wed, Jan 19, 2005 at 03:50:04PM -0500, alex323 wrote: > Heh, I saw my mistake now. Fixed: > > 0x00123456 == 0x123456 == (len = 3) == 0x0003123456 == 0x3123456 Still no. 0x00123456 and 0x123456 are numbers, and they are equal in value. They are both *represented* by the _string_ (or byte array, if you prefer): "\x00\x00\x00\x03\x12\x34\x56", which is *not* the same as the string "\x03\x12\34\56". - Ian From alex323 at gmail.com Wed Jan 19 16:58:03 2005 From: alex323 at gmail.com (alex323) Date: Wed, 19 Jan 2005 16:58:03 -0500 Subject: [OTR-dev] Fingerprints? In-Reply-To: <20050119214845.GT1060@smtp.paip.net> References: <41EC312C.1070107@gmail.com> <41EDC750.1040309@gmail.com> <20050119045352.GL1060@smtp.paip.net> <41EE5BBB.8080400@gmail.com> <20050119143911.GP1060@smtp.paip.net> <41EEC7FC.1090803@gmail.com> <20050119214845.GT1060@smtp.paip.net> Message-ID: <41EED7EB.3090906@gmail.com> Oh, I see now. (0x00123456 == 0x123456) != 0x00 0x00 0x12 0x34 0x56 So by byte[] would have: [0] = 0x03 [1] = 0x12 [2] = 0x34 [3] = 0x56 Instead of: [0] = 0x00 [1] = 0x00 [2] = 0x00 [3] = 0x03 [4] = 0x12 [5] = 0x34 [6] = 0x56 Ian Goldberg wrote: >On Wed, Jan 19, 2005 at 03:50:04PM -0500, alex323 wrote: > > >>Heh, I saw my mistake now. Fixed: >> >>0x00123456 == 0x123456 == (len = 3) == 0x0003123456 == 0x3123456 >> >> > >Still no. 0x00123456 and 0x123456 are numbers, and they are equal in >value. They are both *represented* by the _string_ (or byte array, if >you prefer): "\x00\x00\x00\x03\x12\x34\x56", which is *not* the same as >the string "\x03\x12\34\56". > > - Ian >_______________________________________________ >OTR-dev mailing list >OTR-dev at lists.cypherpunks.ca >http://lists.cypherpunks.ca/mailman/listinfo/otr-dev > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 825 bytes Desc: OpenPGP digital signature URL: From ian at cypherpunks.ca Wed Jan 19 17:55:05 2005 From: ian at cypherpunks.ca (Ian Goldberg) Date: Wed, 19 Jan 2005 17:55:05 -0500 Subject: [OTR-dev] Fingerprints? In-Reply-To: <41EED7EB.3090906@gmail.com> References: <41EC312C.1070107@gmail.com> <41EDC750.1040309@gmail.com> <20050119045352.GL1060@smtp.paip.net> <41EE5BBB.8080400@gmail.com> <20050119143911.GP1060@smtp.paip.net> <41EEC7FC.1090803@gmail.com> <20050119214845.GT1060@smtp.paip.net> <41EED7EB.3090906@gmail.com> Message-ID: <20050119225505.GW1060@smtp.paip.net> On Wed, Jan 19, 2005 at 04:58:03PM -0500, alex323 wrote: > Oh, I see now. (0x00123456 == 0x123456) != 0x00 0x00 0x12 0x34 0x56 > > So by byte[] would have: > > [0] = 0x03 > [1] = 0x12 > [2] = 0x34 > [3] = 0x56 > > Instead of: > > [0] = 0x00 > [1] = 0x00 > [2] = 0x00 > [3] = 0x03 > [4] = 0x12 > [5] = 0x34 > [6] = 0x56 But the latter is the correct representation of the MPI 0x123456. - Ian From alex323 at gmail.com Thu Jan 20 16:06:28 2005 From: alex323 at gmail.com (alex323) Date: Thu, 20 Jan 2005 16:06:28 -0500 Subject: [OTR-dev] MAC keys to be revealed Message-ID: <41F01D54.1080407@gmail.com> Do you HAVE to send out your old MAC keys? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 825 bytes Desc: OpenPGP digital signature URL: From ian at cypherpunks.ca Thu Jan 20 17:33:06 2005 From: ian at cypherpunks.ca (Ian Goldberg) Date: Thu, 20 Jan 2005 17:33:06 -0500 Subject: [OTR-dev] MAC keys to be revealed In-Reply-To: <41F01D54.1080407@gmail.com> References: <41F01D54.1080407@gmail.com> Message-ID: <20050120223306.GG1060@smtp.paip.net> On Thu, Jan 20, 2005 at 04:06:28PM -0500, alex323 wrote: > Do you HAVE to send out your old MAC keys? Even moreso than all those surveillance cameras everywhere, it's For Your Protection. You really really want people to be able to forge messages after the fact. HAVE to? There's no client out there (yet) that will complain if you don't, but it's a really good idea to do it. - Ian From verbal at gmail.com Thu Jan 20 19:04:13 2005 From: verbal at gmail.com (verbal) Date: Thu, 20 Jan 2005 16:04:13 -0800 Subject: [OTR-dev] MAC keys to be revealed In-Reply-To: <41F01D54.1080407@gmail.com> References: <41F01D54.1080407@gmail.com> Message-ID: its more of a "cover your own ass" type of thing. otherwise, its just a pki to shared key encryption protocol. On Thu, 20 Jan 2005 16:06:28 -0500, alex323 wrote: > Do you HAVE to send out your old MAC keys? > > > From paul at cypherpunks.ca Thu Jan 20 20:03:31 2005 From: paul at cypherpunks.ca (Paul Wouters) Date: Fri, 21 Jan 2005 02:03:31 +0100 (CET) Subject: [OTR-dev] MAC keys to be revealed In-Reply-To: <20050120223306.GG1060@smtp.paip.net> Message-ID: On Thu, 20 Jan 2005, Ian Goldberg wrote: > On Thu, Jan 20, 2005 at 04:06:28PM -0500, alex323 wrote: > > Do you HAVE to send out your old MAC keys? > > Even moreso than all those surveillance cameras everywhere, it's > For Your Protection. You really really want people to be able to forge > messages after the fact. > > HAVE to? There's no client out there (yet) that will complain if you > don't, but it's a really good idea to do it. OTR should check for the MAC leakage, and warn me or even disconnect the OTR session if it detects the remove client doesn't do this. I consider this to be essential to OTR. Paul From ian at cypherpunks.ca Thu Jan 20 20:13:54 2005 From: ian at cypherpunks.ca (Ian Goldberg) Date: Thu, 20 Jan 2005 20:13:54 -0500 Subject: [OTR-dev] MAC keys to be revealed In-Reply-To: References: <20050120223306.GG1060@smtp.paip.net> Message-ID: <20050121011354.GK1060@smtp.paip.net> On Fri, Jan 21, 2005 at 02:03:31AM +0100, Paul Wouters wrote: > On Thu, 20 Jan 2005, Ian Goldberg wrote: > > > On Thu, Jan 20, 2005 at 04:06:28PM -0500, alex323 wrote: > > > Do you HAVE to send out your old MAC keys? > > > > Even moreso than all those surveillance cameras everywhere, it's > > For Your Protection. You really really want people to be able to forge > > messages after the fact. > > > > HAVE to? There's no client out there (yet) that will complain if you > > don't, but it's a really good idea to do it. > > OTR should check for the MAC leakage, and warn me or even disconnect the OTR > session if it detects the remove client doesn't do this. I consider this to > be essential to OTR. As long as *one* of you is doing it right, you're at least assured that all the keys are being published. [Each side publishes both his sending and receiving MAC keys for exactly this reason.] But it's probably a good idea to do something if the other side isn't playing along. - Ian From alex323 at gmail.com Thu Jan 20 20:36:03 2005 From: alex323 at gmail.com (alex323) Date: Thu, 20 Jan 2005 20:36:03 -0500 Subject: [OTR-dev] MAC keys to be revealed In-Reply-To: <20050120223306.GG1060@smtp.paip.net> References: <41F01D54.1080407@gmail.com> <20050120223306.GG1060@smtp.paip.net> Message-ID: <41F05C83.7030909@gmail.com> Ian Goldberg wrote: >On Thu, Jan 20, 2005 at 04:06:28PM -0500, alex323 wrote: > > >>Do you HAVE to send out your old MAC keys? >> >> > >Even moreso than all those surveillance cameras everywhere, it's >For Your Protection. You really really want people to be able to forge >messages after the fact. > > Why? I cannot fathom why you'd want that. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 825 bytes Desc: OpenPGP digital signature URL: From verbal at gmail.com Thu Jan 20 21:54:20 2005 From: verbal at gmail.com (verbal) Date: Thu, 20 Jan 2005 18:54:20 -0800 Subject: [OTR-dev] MAC keys to be revealed In-Reply-To: <41F05C83.7030909@gmail.com> References: <41F01D54.1080407@gmail.com> <20050120223306.GG1060@smtp.paip.net> <41F05C83.7030909@gmail.com> Message-ID: do you mean you dont understand why you would want to send our your old mac keys? if that is the question, then the answer is because it allows for your conversation to be forged at a later point in time. this lets you say "hey, i didnt say that" after the conversation time period. during the conversation period, no one can read your conversation or pretend to be you. hope that helps, verbal On Thu, 20 Jan 2005 20:36:03 -0500, alex323 wrote: > Ian Goldberg wrote: > > >On Thu, Jan 20, 2005 at 04:06:28PM -0500, alex323 wrote: > > > > > >>Do you HAVE to send out your old MAC keys? > >> > >> > > > >Even moreso than all those surveillance cameras everywhere, it's > >For Your Protection. You really really want people to be able to forge > >messages after the fact. > > > > > Why? I cannot fathom why you'd want that. > > > From alex323 at gmail.com Thu Jan 20 22:29:44 2005 From: alex323 at gmail.com (alex323) Date: Thu, 20 Jan 2005 22:29:44 -0500 Subject: [OTR-dev] MAC keys to be revealed In-Reply-To: References: <41F01D54.1080407@gmail.com> <20050120223306.GG1060@smtp.paip.net> <41F05C83.7030909@gmail.com> Message-ID: <41F07728.8090007@gmail.com> Hmm.. that does seem more logical if you put it that way. I guess in court you can say, "Anyone could have forged it." verbal wrote: >do you mean you dont understand why you would want to send our your >old mac keys? if that is the question, then the answer is because it >allows for your conversation to be forged at a later point in time. >this lets you say "hey, i didnt say that" after the conversation time >period. during the conversation period, no one can read your >conversation or pretend to be you. > >hope that helps, > >verbal > > >On Thu, 20 Jan 2005 20:36:03 -0500, alex323 wrote: > > >>Ian Goldberg wrote: >> >> >> >>>On Thu, Jan 20, 2005 at 04:06:28PM -0500, alex323 wrote: >>> >>> >>> >>> >>>>Do you HAVE to send out your old MAC keys? >>>> >>>> >>>> >>>> >>>Even moreso than all those surveillance cameras everywhere, it's >>>For Your Protection. You really really want people to be able to forge >>>messages after the fact. >>> >>> >>> >>> >>Why? I cannot fathom why you'd want that. >> >> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 825 bytes Desc: OpenPGP digital signature URL: From verbal at gmail.com Thu Jan 20 22:55:02 2005 From: verbal at gmail.com (verbal) Date: Thu, 20 Jan 2005 19:55:02 -0800 Subject: [OTR-dev] MAC keys to be revealed In-Reply-To: <41F07728.8090007@gmail.com> References: <41F01D54.1080407@gmail.com> <20050120223306.GG1060@smtp.paip.net> <41F05C83.7030909@gmail.com> <41F07728.8090007@gmail.com> Message-ID: and i guess that's why there's all this extra complexity with the changing of public keys so that each key can have a "time" associated with it. combine this with some onion routing (tor.eff.org) and you can pretty much not be held responsible for most things you do about 99% of the time ;). On Thu, 20 Jan 2005 22:29:44 -0500, alex323 wrote: > Hmm.. that does seem more logical if you put it that way. I guess in > court you can say, "Anyone could have forged it." > > verbal wrote: > > >do you mean you dont understand why you would want to send our your > >old mac keys? if that is the question, then the answer is because it > >allows for your conversation to be forged at a later point in time. > >this lets you say "hey, i didnt say that" after the conversation time > >period. during the conversation period, no one can read your > >conversation or pretend to be you. > > > >hope that helps, > > > >verbal > > > > > >On Thu, 20 Jan 2005 20:36:03 -0500, alex323 wrote: > > > > > >>Ian Goldberg wrote: > >> > >> > >> > >>>On Thu, Jan 20, 2005 at 04:06:28PM -0500, alex323 wrote: > >>> > >>> > >>> > >>> > >>>>Do you HAVE to send out your old MAC keys? > >>>> > >>>> > >>>> > >>>> > >>>Even moreso than all those surveillance cameras everywhere, it's > >>>For Your Protection. You really really want people to be able to forge > >>>messages after the fact. > >>> > >>> > >>> > >>> > >>Why? I cannot fathom why you'd want that. > >> > >> > > > From evan.s at dreskin.net Thu Jan 20 23:44:58 2005 From: evan.s at dreskin.net (Evan Schoenberg) Date: Thu, 20 Jan 2005 22:44:58 -0600 Subject: [OTR-dev] Core/UI Split of gaim-otr-1.0.3 Message-ID: <3469D110-6B67-11D9-947F-000A95685E80@dreskin.net> Folks (and probably Ian specifically), Could you give me some details on how a UI for gaim-otr is intended/envisioned to be implemented. All three files .c files presently require GTK, and the plugin claims to be GAIM_GTK_PLUGIN_TYPE. Should I take this to mean that the idea is that this is gaim-otr-gtk and there should be, in addition, a gaim-otr-cocoa or whatever? Thanks, Evan -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 403 bytes Desc: not available URL: From evan.s at dreskin.net Fri Jan 21 01:10:57 2005 From: evan.s at dreskin.net (Evan Schoenberg) Date: Fri, 21 Jan 2005 00:10:57 -0600 Subject: [OTR-dev] libotr 1.0.3 OS X compile error Message-ID: <37113D7A-6B73-11D9-947F-000A95685E80@dreskin.net> On OS X 10.3.7, libotr failed to compile because time_t was not a defined type. Running make as: CFLAGS=-Dtime_t=int make made it compile successfully. -Evan -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 177 bytes Desc: not available URL: From nikitab at cs.berkeley.edu Fri Jan 21 01:18:52 2005 From: nikitab at cs.berkeley.edu (Nikita Borisov) Date: Thu, 20 Jan 2005 22:18:52 -0800 Subject: [OTR-dev] libotr 1.0.3 OS X compile error In-Reply-To: <37113D7A-6B73-11D9-947F-000A95685E80@dreskin.net> References: <37113D7A-6B73-11D9-947F-000A95685E80@dreskin.net> Message-ID: <528C963F-6B74-11D9-A11B-000A95873CEC@cs.berkeley.edu> On Jan 20, 2005, at 10:10 PM, Evan Schoenberg wrote: > On OS X 10.3.7, libotr failed to compile because time_t was not a > defined type. Running make as: > CFLAGS=-Dtime_t=int make That's odd - I can compile libotr successfully on my OS X box. Which file is causing the error? - Nikita From evan.s at dreskin.net Fri Jan 21 01:25:29 2005 From: evan.s at dreskin.net (Evan Schoenberg) Date: Fri, 21 Jan 2005 00:25:29 -0600 Subject: [OTR-dev] libotr 1.0.3 OS X compile error In-Reply-To: <528C963F-6B74-11D9-A11B-000A95873CEC@cs.berkeley.edu> References: <37113D7A-6B73-11D9-947F-000A95685E80@dreskin.net> <528C963F-6B74-11D9-A11B-000A95873CEC@cs.berkeley.edu> Message-ID: <3EBC712A-6B75-11D9-947F-000A95685E80@dreskin.net> It was throwing the error at context.h:70 Other stuff must be wrong with my setup, too... I'm having to make a bunch of makefile changes to get gaim-otr to compile. So far my makefile's LDFLAGS are up to: LDLIBS = -lgcrypt -lgtk-x11-2.0 -lglib-2.0.0 -lgobject-2.0.0 (from an original LDLIBS = -lgcrypt). Now my only remaining problem is that all the gaim symbols (_serv_send_im, _gaim_account_get_connection, etc.) are undefined. -Evan On Jan 21, 2005, at 12:18 AM, Nikita Borisov wrote: > > On Jan 20, 2005, at 10:10 PM, Evan Schoenberg wrote: > >> On OS X 10.3.7, libotr failed to compile because time_t was not a >> defined type. Running make as: >> CFLAGS=-Dtime_t=int make > > That's odd - I can compile libotr successfully on my OS X box. Which > file is causing the error? > > - Nikita > From paul at cypherpunks.ca Fri Jan 21 07:40:59 2005 From: paul at cypherpunks.ca (Paul Wouters) Date: Fri, 21 Jan 2005 13:40:59 +0100 (CET) Subject: [OTR-dev] MAC keys to be revealed In-Reply-To: Message-ID: On Thu, 20 Jan 2005, verbal wrote: > . combine this with some onion routing (tor.eff.org) Pfff .tor. I am still not convinced. So much local state to transfer over something stateless. There was a reason SOCKS wasn't popular. Paul, believes more in IPsec with onion routing. Paul From alex323 at gmail.com Fri Jan 21 07:59:39 2005 From: alex323 at gmail.com (alex323) Date: Fri, 21 Jan 2005 07:59:39 -0500 Subject: [OTR-dev] MAC keys to be revealed In-Reply-To: References: Message-ID: <41F0FCBB.1040400@gmail.com> What's IPSec? >Paul, believes more in IPsec with onion routing. > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 825 bytes Desc: OpenPGP digital signature URL: From ian at cypherpunks.ca Fri Jan 21 08:31:07 2005 From: ian at cypherpunks.ca (Ian Goldberg) Date: Fri, 21 Jan 2005 08:31:07 -0500 Subject: [OTR-dev] Core/UI Split of gaim-otr-1.0.3 In-Reply-To: <3469D110-6B67-11D9-947F-000A95685E80@dreskin.net> References: <3469D110-6B67-11D9-947F-000A95685E80@dreskin.net> Message-ID: <20050121133107.GP1060@smtp.paip.net> On Thu, Jan 20, 2005 at 10:44:58PM -0600, Evan Schoenberg wrote: > Folks (and probably Ian specifically), > > Could you give me some details on how a UI for gaim-otr is > intended/envisioned to be implemented. All three files .c files > presently require GTK, and the plugin claims to be > GAIM_GTK_PLUGIN_TYPE. Should I take this to mean that the idea is that > this is gaim-otr-gtk and there should be, in addition, a gaim-otr-cocoa > or whatever? There's pretty much no logic left in gaim-otr; it's all UI. ui.c is the UI for the preferences panel, dialog.c are the dialog boxes, and otr-plugin.c is the "glue" to gaim. For Adium X, you'd probably need to implement each of these pieces using Cocoa or whatever, but you could follow the structure closely if you liked. [otr-plugin.c probably has the most reuseable bits in it, since the glue to Adium should be similar to gaim.] I was under the impression that there wasn't gaim for OSX, just Adium X. So wouldn't your package be adium-otr or something? - Ian From ian at cypherpunks.ca Fri Jan 21 08:37:12 2005 From: ian at cypherpunks.ca (Ian Goldberg) Date: Fri, 21 Jan 2005 08:37:12 -0500 Subject: [OTR-dev] libotr 1.0.3 OS X compile error In-Reply-To: <3EBC712A-6B75-11D9-947F-000A95685E80@dreskin.net> References: <37113D7A-6B73-11D9-947F-000A95685E80@dreskin.net> <528C963F-6B74-11D9-A11B-000A95873CEC@cs.berkeley.edu> <3EBC712A-6B75-11D9-947F-000A95685E80@dreskin.net> Message-ID: <20050121133712.GQ1060@smtp.paip.net> On Fri, Jan 21, 2005 at 12:25:29AM -0600, Evan Schoenberg wrote: > It was throwing the error at context.h:70 That's bizarre; it works for Len and Nikita for sure. > Other stuff must be wrong with my setup, too... I'm having to make a > bunch of makefile changes to get gaim-otr to compile. So far my > makefile's LDFLAGS are up to: > LDLIBS = -lgcrypt -lgtk-x11-2.0 -lglib-2.0.0 -lgobject-2.0.0 > > (from an original LDLIBS = -lgcrypt). > > Now my only remaining problem is that all the gaim symbols > (_serv_send_im, _gaim_account_get_connection, etc.) are undefined. AFAIK, we never tried to compile gaim-otr on OSX, since there isn't gaim there (at least, we didn't know of one). But gaim-otr builds a shared library; why is it complaining about missing symbols? They'll be provided by the application that links them. [That's how it works on Linux, anyway; I know Windows is different: .dll's have to have all of their symbols resolved, so you have to link -lgaim to gaim-otr.dll.] [Clearly, since you've got some gtk libs in your message, gtk and gaim exist for OSX, so we were wrong. Nikita: can you look into this and maybe build a gaim-otr OSX package? (Or at least make the code compile?)] Thanks, - Ian From evan.s at dreskin.net Fri Jan 21 11:27:14 2005 From: evan.s at dreskin.net (Evan Schoenberg) Date: Fri, 21 Jan 2005 10:27:14 -0600 Subject: [OTR-dev] libotr 1.0.3 OS X compile error In-Reply-To: <20050121133712.GQ1060@smtp.paip.net> References: <37113D7A-6B73-11D9-947F-000A95685E80@dreskin.net> <528C963F-6B74-11D9-A11B-000A95873CEC@cs.berkeley.edu> <3EBC712A-6B75-11D9-947F-000A95685E80@dreskin.net> <20050121133712.GQ1060@smtp.paip.net> Message-ID: <4F490509-6BC9-11D9-947F-000A95685E80@dreskin.net> OS X has X11.app, which when launched runs an XWindows server which should theoretically do anything XWindows normally does. The default Window manager even makes XWindows apps have OS X-like title bars and close buttons and such. Need to install the various Gaim dependencies, of course, to get Gaim running... which works as perfectly in OS X X11 as it does on any other system. Here are the notes I made of things I ran into while installing dependencies, FYI. gnutils-1.0.3: Compiled with -undefined suppress -flat-namespace to get rid of SBOX problems # for OpenCDK sudo ln -s /usr/include/malloc/malloc.h /usr/local/include # for Glib sudo ln -s /usr/lib/libiconv.la /usr/local/lib/libiconv.la sudo ln -s /usr/lib/libiconv.dylib /usr/local/lib/libiconv.dylib # running Gaim's autogen.sh CFLAGS="-I/usr/local/include -Iusr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include/" LDFLAGS="-L/usr/local/lib -L/usr/local/lib/glib-2.0 -I/usr/local/include/glib-2.0/glib" ./autogen.sh --prefix="/usr/local" --with-gnutls-libs=/usr/local/lib --disable-nis --disable-rpath --disable-perl --disable-tcl --disable-tk --disable-gtkspell --disable-gtktest -Evan On Jan 21, 2005, at 7:37 AM, Ian Goldberg wrote: > AFAIK, we never tried to compile gaim-otr on OSX, since there isn't > gaim there (at least, we didn't know of one). But gaim-otr builds a > shared library; why is it complaining about missing symbols? They'll > be > provided by the application that links them. > > [That's how it works on Linux, anyway; I know Windows is different: > .dll's have to have all of their symbols resolved, so you have to link > -lgaim to gaim-otr.dll.] > > [Clearly, since you've got some gtk libs in your message, gtk and gaim > exist for OSX, so we were wrong. Nikita: can you look into this and > maybe build a gaim-otr OSX package? (Or at least make the code > compile?)] > > Thanks, > > - Ian > _______________________________________________ > OTR-dev mailing list > OTR-dev at lists.cypherpunks.ca > http://lists.cypherpunks.ca/mailman/listinfo/otr-dev > From evan.s at dreskin.net Fri Jan 21 11:50:58 2005 From: evan.s at dreskin.net (Evan Schoenberg) Date: Fri, 21 Jan 2005 10:50:58 -0600 Subject: [OTR-dev] Core/UI Split of gaim-otr-1.0.3 In-Reply-To: <20050121133107.GP1060@smtp.paip.net> References: <3469D110-6B67-11D9-947F-000A95685E80@dreskin.net> <20050121133107.GP1060@smtp.paip.net> Message-ID: <9FB8F450-6BCC-11D9-947F-000A95685E80@dreskin.net> On Jan 21, 2005, at 7:31 AM, Ian Goldberg wrote: > There's pretty much no logic left in gaim-otr; it's all UI. ui.c is > the > UI for the preferences panel, dialog.c are the dialog boxes, and > otr-plugin.c is the "glue" to gaim. > For Adium X, you'd probably need to implement each of these pieces > using > Cocoa or whatever, but you could follow the structure closely if you > liked. [otr-plugin.c probably has the most reuseable bits in it, since > the glue to Adium should be similar to gaim.] [Prepare yourself... long email.] If otr-plugin is a true extension of gaim, it shouldn't be necessary to maintain "adium-otr". Gaim is nearly UI neutral in its core (there are still 2 core files which need some attention to be completely UI neutral); to update to a new version of libgaim, I diff the old Gaim against the new Gaim and apply the diff. In the future, when the core/UI split is complete, that will be completely unnecessary; I'll drop the new version of libgaim in place. Similarly, if otr-plugin were core/ui split, an updated version of gaim-otr would be dropped in place. If significant functionality changed I might change the UI functions which Adium registers with otr-plugin (like the gtkgaim functions which would have been updated along with the plugin, since it would ship with the gtk UI for use with Gaim, no changes needed). I can't just implement these pieces using Cocoa, not in any manner that would be clean or maintainable anyways. This would be the first invasion of cocoa into libgaim and its dependencies, libraries, and plugins. Libgaim.framework (a framework in OS X is like an umbrella dynamic library or something) is C-only. From within Adium's Cocoa code, what I want to do is register the UI functions which the plugin will call. Those should inform the UI of what to do display and be passed callbacks to call when user interaction is necessary... ok_cb, cancel_cb, whatever. The UI shouldn't need to call within libotr; otr-plugin is the abstraction layer between UI and libotr, just like the gaim core is the abstraction layer between UI and the various protocol prpls. Right now, otr-plugin directly calls methods within ui.c and dialog.c. What I would suggest instead is that these two files be changed to be UI-neutral, using their own structures, and have registration functions. A structure of the needed UI methods would be created with references to functions in the split gtk-otr-ui.c and gtk-otr-dialog.c and then would be registered with otr-ui.c and otr-dialog.c, which would perform the logic and libotr calls as needed, passing off UI and only UI to the registered UI functions. otr-plugin.c itself only has one function which actually depends on the UI and expects: a) it is GTK and b) it behaves in a certain way. (Those are just random name suggestions.. but giving the files in gaim-otr a unique prefix would be a Good Thing since one possible way of compiling gaim is statically, with all the plugins compiled at the same time and into the same binary, and without a unique prefix we're asking for a conflict). The magic test in my mind is ultimately if otr-plugin.c, ui.c, and dialog.c can be compiled without GTK; alone, they would clearly do nothing, but throw gtk-otr-ui.c and gtk-otr-dialog.c into the mix and you end up with the current functionality (no change apparent to the user, of course). otr-plugin.c would have some means of automatically registering the gtk callbacks if a gtk #define is available... if not, the external UI (Adium X in our case, but Proteus will probably Keep Up With The Joneses as usual, and other libgaim UIs will almost certainly surface in the future) will need to register its own callbacks for gaim-otr. In GTK Gaim proper main.c inits the core and then calls functions in the gtk*.c files which perform all the gtk registrations. I don't want to bore you, or ramble... so: Does that make sense? Does that seem desirable? etc. Basically: Thoughts? :) > > I was under the impression that there wasn't gaim for OSX, just Adium > X. > So wouldn't your package be adium-otr or something? > See my other email... OS X is a BSD-based operating system and as such can do anything other *NIX systems can do. I always have the latest Gaim installed and working via X11 XWindows Server.... it's ugly by comparison, clunky to use in my opinion, a hassle to get installed in the first place and not nearly as convenient to load up, but it's there :D But while Adium would implement its own UI, we would optimally just have gaim-otr loading as a normal plugin into the gaim core. -Evan From ian at cypherpunks.ca Fri Jan 21 12:15:04 2005 From: ian at cypherpunks.ca (Ian Goldberg) Date: Fri, 21 Jan 2005 12:15:04 -0500 Subject: [OTR-dev] Core/UI Split of gaim-otr-1.0.3 In-Reply-To: <9FB8F450-6BCC-11D9-947F-000A95685E80@dreskin.net> References: <3469D110-6B67-11D9-947F-000A95685E80@dreskin.net> <20050121133107.GP1060@smtp.paip.net> <9FB8F450-6BCC-11D9-947F-000A95685E80@dreskin.net> Message-ID: <20050121171504.GU1060@smtp.paip.net> On Fri, Jan 21, 2005 at 10:50:58AM -0600, Evan Schoenberg wrote: > Right now, otr-plugin directly calls methods within ui.c and dialog.c. > What I would suggest instead is that these two files be changed to be > UI-neutral, using their own structures, and have registration > functions. A structure of the needed UI methods would be created with > references to functions in the split gtk-otr-ui.c and gtk-otr-dialog.c > and then would be registered with otr-ui.c and otr-dialog.c, which > would perform the logic and libotr calls as needed, passing off UI and > only UI to the registered UI functions. otr-plugin.c itself only has > one function which actually depends on the UI and expects: a) it is GTK > and b) it behaves in a certain way. I think I see what you're saying. What should be done about the GAIM_GTK_PLUGIN_TYPE in otr-plugin.c? What "portably" goes there? (The gtk-centric function in otr-plugin.c is an oversight; it wasn't meant to be there at all.) - Ian From evan.s at dreskin.net Fri Jan 21 13:01:32 2005 From: evan.s at dreskin.net (Evan Schoenberg) Date: Fri, 21 Jan 2005 12:01:32 -0600 Subject: [OTR-dev] Core/UI Split of gaim-otr-1.0.3 In-Reply-To: <20050121171504.GU1060@smtp.paip.net> References: <3469D110-6B67-11D9-947F-000A95685E80@dreskin.net> <20050121133107.GP1060@smtp.paip.net> <9FB8F450-6BCC-11D9-947F-000A95685E80@dreskin.net> <20050121171504.GU1060@smtp.paip.net> Message-ID: <7BC787CF-6BD6-11D9-947F-000A95685E80@dreskin.net> On Jan 21, 2005, at 11:15 AM, Ian Goldberg wrote: > > I think I see what you're saying. What should be done about the > GAIM_GTK_PLUGIN_TYPE in otr-plugin.c? What "portably" goes there? > Good question. gaim-otr will be the first significant (in terms of use and in terms of size) Gaim plugin which I'm aware of which has as good as core/UI split as Gaim itself soon will, if we can pull it off (that's ignoring the protocol plugins such as meanwhile). As such, I don't think there's an established way to handle it. My gut, and probably the easiest thing to do, is to use the same #ifdef GTK_SOMETHING we'll use to know if we should automatically register gtk UI functions... if GTK is available, it'll be GAIM_GTK_PLUGIN_TYPE; otherwise we can just use NULL as the UI requirement. Not perfect, but I can't really imagine an alternative UI depending on that value in any case. What purpose does identifying as GAIM_GTK_PLUGIN_TYPE serve within Gaim? > (The gtk-centric function in otr-plugin.c is an oversight; it wasn't > meant to be there at all.) > Cool, I guessed that might be the case. -Evan From ian at cypherpunks.ca Fri Jan 21 15:29:20 2005 From: ian at cypherpunks.ca (Ian Goldberg) Date: Fri, 21 Jan 2005 15:29:20 -0500 Subject: [OTR-dev] Core/UI Split of gaim-otr-1.0.3 In-Reply-To: <7BC787CF-6BD6-11D9-947F-000A95685E80@dreskin.net> References: <3469D110-6B67-11D9-947F-000A95685E80@dreskin.net> <20050121133107.GP1060@smtp.paip.net> <9FB8F450-6BCC-11D9-947F-000A95685E80@dreskin.net> <20050121171504.GU1060@smtp.paip.net> <7BC787CF-6BD6-11D9-947F-000A95685E80@dreskin.net> Message-ID: <20050121202920.GX1060@smtp.paip.net> On Fri, Jan 21, 2005 at 12:01:32PM -0600, Evan Schoenberg wrote: > > On Jan 21, 2005, at 11:15 AM, Ian Goldberg wrote: > > > >I think I see what you're saying. What should be done about the > >GAIM_GTK_PLUGIN_TYPE in otr-plugin.c? What "portably" goes there? > > > Good question. gaim-otr will be the first significant (in terms of use > and in terms of size) Gaim plugin which I'm aware of which has as good > as core/UI split as Gaim itself soon will, if we can pull it off > (that's ignoring the protocol plugins such as meanwhile). As such, I > don't think there's an established way to handle it. OK, then to boldly go... :-) Tell me what you think of this: http://www.cypherpunks.ca/otr/gaim-otr-cvs-latest.tar.gz - Ian From jbash at velvet.com Fri Jan 21 14:38:28 2005 From: jbash at velvet.com (jbash at velvet.com) Date: Fri, 21 Jan 2005 11:38:28 -0800 Subject: [OTR-dev] MAC keys to be revealed In-Reply-To: References: Message-ID: <20050121193828.2508B386FAC@chodaboy.velvet.com> > > . combine this with some onion routing (tor.eff.org) > > Pfff .tor. I am still not convinced. So much local state to transfer > over something stateless. There was a reason SOCKS wasn't popular. > > Paul, believes more in IPsec with onion routing. Um, three layers of IPsec SAs is about as much state as three layers of TCP connections plus crypto context. I would have been happier if Tor had carried raw IP datagrams, myself, but I don't think state is the issue. There's always going to be some state until public key is close to as fast as symmetric crypto, and maybe even then if you have a billing system and are worried about replay protection. I was more worried about isochrony and queue stalls and excessive retransmission and that sort of thing. Tor is the way it is because Roger wanted it to be able to run in user space as non-root. To pull it back onto the topic, I do all my IM over Tor. It works great. Every time I chat with Ian, it's OTR over AIM over Tor. The SOCKS support in Gaim makes it easy to do IM over Tor transparently. I've also run xchat over Tor, complete with DCCs, and HTTP over Tor with Mozilla and privoxy... all with unmodified software, which was enabled by the surprisingly great popularity of the SOCKS protocol... From evan.s at dreskin.net Fri Jan 21 16:33:24 2005 From: evan.s at dreskin.net (Evan Schoenberg) Date: Fri, 21 Jan 2005 15:33:24 -0600 Subject: [OTR-dev] Core/UI Split of gaim-otr-1.0.3 In-Reply-To: <20050121202920.GX1060@smtp.paip.net> References: <3469D110-6B67-11D9-947F-000A95685E80@dreskin.net> <20050121133107.GP1060@smtp.paip.net> <9FB8F450-6BCC-11D9-947F-000A95685E80@dreskin.net> <20050121171504.GU1060@smtp.paip.net> <7BC787CF-6BD6-11D9-947F-000A95685E80@dreskin.net> <20050121202920.GX1060@smtp.paip.net> Message-ID: <14895CF4-6BF4-11D9-947F-000A95685E80@dreskin.net> I think I love you? :D That looks awesome. verbal and I are going to work on hooking that up this weekend... I'll let you know if I run into any snags or questions. Two comments: 1) Would it be possible to automate the #define USING_GTK like so? #ifdef GTK_MAJOR_VERSION #define USING_GTK #endif 2) The #define GAIM_PLUGINS at the top of otr-plugin.c seems like it could instead be a -DGAIM_PLUGINS in the makefile... as having it in the .c file forces dynamic compilation even if building statically, whereas in the makefile it would only do its thing when building via make (when of course you want to create a .so file). Actual code comments (or just laudations, since this looks really nice and clean, thanks so much for all your hard work!) will follow once I've played with implementation. -Evan On Jan 21, 2005, at 2:29 PM, Ian Goldberg wrote: > On Fri, Jan 21, 2005 at 12:01:32PM -0600, Evan Schoenberg wrote: >> >> On Jan 21, 2005, at 11:15 AM, Ian Goldberg wrote: >>> >>> I think I see what you're saying. What should be done about the >>> GAIM_GTK_PLUGIN_TYPE in otr-plugin.c? What "portably" goes there? >>> >> Good question. gaim-otr will be the first significant (in terms of >> use >> and in terms of size) Gaim plugin which I'm aware of which has as good >> as core/UI split as Gaim itself soon will, if we can pull it off >> (that's ignoring the protocol plugins such as meanwhile). As such, I >> don't think there's an established way to handle it. > > OK, then to boldly go... :-) > > Tell me what you think of this: > > http://www.cypherpunks.ca/otr/gaim-otr-cvs-latest.tar.gz > > - Ian > _______________________________________________ > OTR-dev mailing list > OTR-dev at lists.cypherpunks.ca > http://lists.cypherpunks.ca/mailman/listinfo/otr-dev > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 2083 bytes Desc: not available URL: From gdt at ir.bbn.com Fri Jan 21 16:55:32 2005 From: gdt at ir.bbn.com (Greg Troxel) Date: 21 Jan 2005 16:55:32 -0500 Subject: [OTR-dev] autoconf/automake/libtool support for libotr In-Reply-To: <4F490509-6BC9-11D9-947F-000A95685E80@dreskin.net> Message-ID: The following patch against libotr-1.0.3 adds autoconf/automake/libtool support, and bumps the version to 1.0.4. With this, 'make dist' seems to work. See the file NETBSD (doesn't belong in releases) for how to bootstrap the auto* tools. It's probably just 'autoreconf -s -i;./configure' for most of you. The problem with this change is that it breaks mingw support. The original makefiles could be retained, or it should be possible to add an --enable-mingw configure option that sets some variables (such as CC to the mingw cross-compiler). If you have mingw installed so that there is /usr/pkg/mingw/bin which has cc, ld, etc., you could perhaps do PATH=/usr/pkg/mingw/bin:$PATH ./configure and it might just pick it up. autoconf is said to have cross support; I'm not wicked familiar with it. Note that this patch removes the original 'Makefile' files, and adds Makefile.am. autoconf support will make it easier to make BSD packages, because the Linux install paths won't be hard-coded. Plus, a shared library is built, and that should work on a.out and ELF on various OSes. Ian: please disregard previous patch in private mail; this iss a fresh diff against 1.0.3. Index: AUTHORS =================================================================== RCS file: AUTHORS diff -N AUTHORS Index: ChangeLog =================================================================== RCS file: ChangeLog diff -N ChangeLog Index: Makefile =================================================================== RCS file: Makefile diff -N Makefile --- Makefile 18 Jan 2005 18:44:32 -0000 1.1.1.1 +++ /dev/null 1 Jan 1970 00:00:00 -0000 @@ -1,3 +0,0 @@ -all install clean distclean: - $(MAKE) -C src $@ - $(MAKE) -C toolkit $@ Index: Makefile.am =================================================================== RCS file: Makefile.am diff -N Makefile.am --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ Makefile.am 21 Jan 2005 21:39:46 -0000 1.2 @@ -0,0 +1,14 @@ +# -*- Makefile -*- +# $Id: Makefile.am,v 1.2 2005/01/21 21:39:46 gdt Exp $ + +SUBDIRS = src toolkit + +EXTRA_DIST = Protocol \ + packaging/debian/changelog \ + packaging/debian/compat \ + packaging/debian/control \ + packaging/debian/copyright \ + packaging/debian/docs \ + packaging/debian/rules \ + packaging/debian/watch + Index: NETBSD =================================================================== RCS file: NETBSD diff -N NETBSD --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ NETBSD 21 Jan 2005 18:59:37 -0000 1.1 @@ -0,0 +1,3 @@ +autoreconf -i -s +CPPFLAGS="-I/usr/pkg/include" LDFLAGS="-R/usr/pkg/lib -L/usr/pkg/lib" ./configure --prefix=/usr/pkg +gmake Index: NEWS =================================================================== RCS file: NEWS diff -N NEWS Index: configure.ac =================================================================== RCS file: configure.ac diff -N configure.ac --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ configure.ac 21 Jan 2005 21:39:46 -0000 1.3 @@ -0,0 +1,16 @@ +dnl Process this file with autoconf to produce configure. + +AC_INIT(toolkit/parse.c) + +AM_CONFIG_HEADER(config.h) +AM_INIT_AUTOMAKE(libotr, 1.0.4) + +AC_PROG_CC + +AM_PROG_LIBTOOL + +AC_CHECK_LIB(gpg-error, gpg_strerror) +AM_PATH_LIBGCRYPT + +AC_OUTPUT([Makefile src/Makefile toolkit/Makefile]) + Index: src/Makefile =================================================================== RCS file: src/Makefile diff -N src/Makefile --- src/Makefile 18 Jan 2005 18:44:08 -0000 1.1.1.1 +++ /dev/null 1 Jan 1970 00:00:00 -0000 @@ -1,40 +0,0 @@ -ifdef WIN32 -CC = i586-mingw32msvc-gcc -INCINSTALLDIR = /usr/i586-mingw32msvc/include -LIBINSTALLDIR = /usr/i586-mingw32msvc/lib -else -FPIC = -fPIC -INCINSTALLDIR = /usr/include -LIBINSTALLDIR = /usr/lib -endif - -INCINSTDIR = $(DESTDIR)$(INCINSTALLDIR)/libotr -LIBINSTDIR = $(DESTDIR)$(LIBINSTALLDIR) - -override CFLAGS += -g -Wall $(FPIC) -TARGET = libotr.a - -HEADERS = b64.h context.h dh.h mem.h message.h privkey.h proto.h version.h - -all: $(TARGET) - -$(TARGET): privkey.o context.o proto.o b64.o dh.o mem.o message.o - rm -f $@ -ifdef WIN32 - i586-mingw32msvc-ar rcs $@ $^ - i586-mingw32msvc-ranlib $@ -else - ar rcs $@ $^ -endif - -install: all - install -d $(INCINSTDIR) - install -d $(LIBINSTDIR) - install -m 0644 $(TARGET) $(LIBINSTDIR) - install -m 0644 $(HEADERS) $(INCINSTDIR) - -clean: - rm -f *.o - rm -f $(TARGET) - -distclean: clean Index: src/Makefile.am =================================================================== RCS file: src/Makefile.am diff -N src/Makefile.am --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ src/Makefile.am 21 Jan 2005 19:19:30 -0000 1.2 @@ -0,0 +1,13 @@ +# -*- Makefile -*- + +INCLUDES = @LIBGCRYPT_CFLAGS@ + +lib_LTLIBRARIES = libotr.la +libotr_la_LDFLAGS = -version 0:0:0 + +libotr_la_SOURCES = privkey.c context.c proto.c b64.c dh.c mem.c message.c +libotr_la_LDFLAGS = @LIBS@ @LIBGCRYPT_LDFLAGS@ + +otrincdir = $(includedir)/libotr + +otrinc_HEADERS = b64.h context.h dh.h mem.h message.h privkey.h proto.h version.h Index: toolkit/Makefile =================================================================== RCS file: toolkit/Makefile diff -N toolkit/Makefile --- toolkit/Makefile 18 Jan 2005 22:47:18 -0000 1.1.1.1 +++ /dev/null 1 Jan 1970 00:00:00 -0000 @@ -1,72 +0,0 @@ -# The location of the libotr directory -LIBOTR_DIR = ../src - -# The target dir -TARGET_DIR = .. - -ifdef WIN32 -CC = i586-mingw32msvc-gcc -SUFFIX = .exe -LDLIBS = -lgcrypt -lgpg-error -else -# Install dirs -INSTALLBINDIR = $(DESTDIR)/usr/bin -INSTALLMANDIR = $(DESTDIR)/usr/share/man/man1 - -FPIC = -fPIC -LDLIBS = -lgcrypt -endif - -override CFLAGS += -g -Wall -I$(LIBOTR_DIR) $(FPIC) -override LDFLAGS += -g - -TARGETS = $(TARGET_DIR)/otr_parse$(SUFFIX) \ - $(TARGET_DIR)/otr_sesskeys$(SUFFIX) \ - $(TARGET_DIR)/otr_mackey$(SUFFIX) \ - $(TARGET_DIR)/otr_readforge$(SUFFIX) \ - $(TARGET_DIR)/otr_modify$(SUFFIX) \ - $(TARGET_DIR)/otr_remac$(SUFFIX) - -all: $(TARGETS) - -$(TARGET_DIR)/otr_parse$(SUFFIX): otr_parse.o readotr.o parse.o sha1hmac.o $(LIBOTR_DIR)/libotr.a - $(CC) $(LDFLAGS) $^ -o $@ $(LDLIBS) - -$(TARGET_DIR)/otr_sesskeys$(SUFFIX): otr_sesskeys.o sesskeys.o parse.o sha1hmac.o $(LIBOTR_DIR)/libotr.a - $(CC) $(LDFLAGS) $^ -o $@ $(LDLIBS) - -$(TARGET_DIR)/otr_mackey$(SUFFIX): otr_mackey.o sesskeys.o parse.o sha1hmac.o $(LIBOTR_DIR)/libotr.a - $(CC) $(LDFLAGS) $^ -o $@ $(LDLIBS) - -$(TARGET_DIR)/otr_readforge$(SUFFIX): otr_readforge.o readotr.o sesskeys.o parse.o sha1hmac.o aes.o ctrmode.o $(LIBOTR_DIR)/libotr.a - $(CC) $(LDFLAGS) $^ -o $@ $(LDLIBS) - -$(TARGET_DIR)/otr_modify$(SUFFIX): otr_modify.o readotr.o parse.o sha1hmac.o $(LIBOTR_DIR)/libotr.a - $(CC) $(LDFLAGS) $^ -o $@ $(LDLIBS) - -$(TARGET_DIR)/otr_remac$(SUFFIX): otr_remac.o parse.o sha1hmac.o $(LIBOTR_DIR)/libotr.a - $(CC) $(LDFLAGS) $^ -o $@ $(LDLIBS) - -$(LIBOTR_DIR)/libotr.a: FORCE - $(MAKE) -C $(LIBOTR_DIR) libotr.a - -install: all -ifndef WIN32 - install -d $(INSTALLBINDIR) - install -d $(INSTALLMANDIR) - install -m 0755 $(TARGETS) $(INSTALLBINDIR) - install -m 0644 otr_toolkit.1 $(INSTALLMANDIR)/otr_parse.1 - ln -nsf otr_parse.1 $(INSTALLMANDIR)/otr_sesskeys.1 - ln -nsf otr_parse.1 $(INSTALLMANDIR)/otr_mackey.1 - ln -nsf otr_parse.1 $(INSTALLMANDIR)/otr_readforge.1 - ln -nsf otr_parse.1 $(INSTALLMANDIR)/otr_modify.1 - ln -nsf otr_parse.1 $(INSTALLMANDIR)/otr_remac.1 -endif - -clean: - rm -f *.o - rm -f $(TARGETS) - -distclean: clean - -FORCE: Index: toolkit/Makefile.am =================================================================== RCS file: toolkit/Makefile.am diff -N toolkit/Makefile.am --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ toolkit/Makefile.am 21 Jan 2005 21:39:46 -0000 1.2 @@ -0,0 +1,43 @@ +# -*- Makefile -*- + +INCLUDES = -I$(includedir) -I../src + +noinst_HEADERS = aes.h ctrmode.h parse.h sesskeys.h readotr.h sha1hmac.h + +bin_PROGRAMS = otr_parse otr_sesskeys otr_mackey otr_readforge \ + otr_modify otr_remac + +COMMON_S = parse.c sha1hmac.c +COMMON_LD = ../src/libotr.la @LIBS@ @LIBGCRYPT_LIBS@ + +otr_parse_SOURCES = otr_parse.c readotr.c $(COMMON_S) +otr_parse_LDADD = $(COMMON_LD) + +otr_sesskeys_SOURCES = otr_sesskeys.c sesskeys.c $(COMMON_S) +otr_sesskeys_LDADD = $(COMMON_LD) + +otr_mackey_SOURCES = otr_mackey.c sesskeys.c $(COMMON_S) +otr_mackey_LDADD = $(COMMON_LD) + +otr_readforge_SOURCES = otr_readforge.c readotr.c sesskeys.c \ + aes.c ctrmode.c $(COMMON_S) +otr_readforge_LDADD = $(COMMON_LD) + +otr_modify_SOURCES = otr_modify.c readotr.c $(COMMON_S) +otr_modify_LDADD = $(COMMON_LD) + +otr_remac_SOURCES = otr_remac.c $(COMMON_S) +otr_remac_LDADD = $(COMMON_LD) + + +man_MANS = otr_toolkit.1 +EXTRA_DIST = otr_toolkit.1 + +# XXX This assumes what automake will do, but there does not +# seem to be an install-man -hook or -local. +install-man: install-man1 install-links + +install-links: + (cd $(DESTDIR)$(man1dir) && \ + for f in otr_parse.1 otr_sesskeys.1 otr_mackey.1 otr_readforge.1 otr_modify.1 otr_remac.1; do \ + ln -sf otr_toolkit.1 $$f; done) -- Greg Troxel From verbal at gmail.com Fri Jan 21 16:55:47 2005 From: verbal at gmail.com (verbal) Date: Fri, 21 Jan 2005 13:55:47 -0800 Subject: [OTR-dev] MAC keys to be revealed In-Reply-To: <41F0FCBB.1040400@gmail.com> References: <41F0FCBB.1040400@gmail.com> Message-ID: http://en.wikipedia.org/wiki/IPSec On Fri, 21 Jan 2005 07:59:39 -0500, alex323 wrote: > What's IPSec? > > >Paul, believes more in IPsec with onion routing. > > > > > From verbal at gmail.com Fri Jan 21 17:00:16 2005 From: verbal at gmail.com (verbal) Date: Fri, 21 Jan 2005 14:00:16 -0800 Subject: [OTR-dev] Core/UI Split of gaim-otr-1.0.3 In-Reply-To: <14895CF4-6BF4-11D9-947F-000A95685E80@dreskin.net> References: <3469D110-6B67-11D9-947F-000A95685E80@dreskin.net> <20050121133107.GP1060@smtp.paip.net> <9FB8F450-6BCC-11D9-947F-000A95685E80@dreskin.net> <20050121171504.GU1060@smtp.paip.net> <7BC787CF-6BD6-11D9-947F-000A95685E80@dreskin.net> <20050121202920.GX1060@smtp.paip.net> <14895CF4-6BF4-11D9-947F-000A95685E80@dreskin.net> Message-ID: score! that was much faster responce than i had anticipated. thanks ian. evan, i guess we cant slack off this weekend ;). On Fri, 21 Jan 2005 15:33:24 -0600, Evan Schoenberg wrote: > I think I love you? :D > > That looks awesome. verbal and I are going to work on hooking that up > this weekend... I'll let you know if I run into any snags or questions. > > Two comments: > > 1) Would it be possible to automate the #define USING_GTK like so? > > #ifdef GTK_MAJOR_VERSION > #define USING_GTK > #endif > > 2) The #define GAIM_PLUGINS at the top of otr-plugin.c seems like it > could instead be a -DGAIM_PLUGINS in the makefile... as having it in > the .c file forces dynamic compilation even if building statically, > whereas in the makefile it would only do its thing when building via > make (when of course you want to create a .so file). > > Actual code comments (or just laudations, since this looks really nice > and clean, thanks so much for all your hard work!) will follow once > I've played with implementation. > > -Evan > > On Jan 21, 2005, at 2:29 PM, Ian Goldberg wrote: > > > On Fri, Jan 21, 2005 at 12:01:32PM -0600, Evan Schoenberg wrote: > >> > >> On Jan 21, 2005, at 11:15 AM, Ian Goldberg wrote: > >>> > >>> I think I see what you're saying. What should be done about the > >>> GAIM_GTK_PLUGIN_TYPE in otr-plugin.c? What "portably" goes there? > >>> > >> Good question. gaim-otr will be the first significant (in terms of > >> use > >> and in terms of size) Gaim plugin which I'm aware of which has as good > >> as core/UI split as Gaim itself soon will, if we can pull it off > >> (that's ignoring the protocol plugins such as meanwhile). As such, I > >> don't think there's an established way to handle it. > > > > OK, then to boldly go... :-) > > > > Tell me what you think of this: > > > > http://www.cypherpunks.ca/otr/gaim-otr-cvs-latest.tar.gz > > > > - Ian > > _______________________________________________ > > OTR-dev mailing list > > OTR-dev at lists.cypherpunks.ca > > http://lists.cypherpunks.ca/mailman/listinfo/otr-dev > > > > From evan.s at dreskin.net Fri Jan 21 17:02:46 2005 From: evan.s at dreskin.net (Evan Schoenberg) Date: Fri, 21 Jan 2005 16:02:46 -0600 Subject: [OTR-dev] libotr 1.0.3 OS X compile error In-Reply-To: <20050121133712.GQ1060@smtp.paip.net> References: <37113D7A-6B73-11D9-947F-000A95685E80@dreskin.net> <528C963F-6B74-11D9-A11B-000A95873CEC@cs.berkeley.edu> <3EBC712A-6B75-11D9-947F-000A95685E80@dreskin.net> <20050121133712.GQ1060@smtp.paip.net> Message-ID: <2E95997C-6BF8-11D9-947F-000A95685E80@dreskin.net> On Jan 21, 2005, at 7:37 AM, Ian Goldberg wrote: >> It was throwing the error at context.h:70 > > That's bizarre; it works for Len and Nikita for sure. I believe I figured out what was going on. socklen_t is defined in system headers in OS X 10.3... I'm building with the 10.2 SDK so it's not available. Easy to fix though :) From ian at cypherpunks.ca Fri Jan 21 17:21:23 2005 From: ian at cypherpunks.ca (Ian Goldberg) Date: Fri, 21 Jan 2005 17:21:23 -0500 Subject: [OTR-dev] Core/UI Split of gaim-otr-1.0.3 In-Reply-To: <14895CF4-6BF4-11D9-947F-000A95685E80@dreskin.net> References: <3469D110-6B67-11D9-947F-000A95685E80@dreskin.net> <20050121133107.GP1060@smtp.paip.net> <9FB8F450-6BCC-11D9-947F-000A95685E80@dreskin.net> <20050121171504.GU1060@smtp.paip.net> <7BC787CF-6BD6-11D9-947F-000A95685E80@dreskin.net> <20050121202920.GX1060@smtp.paip.net> <14895CF4-6BF4-11D9-947F-000A95685E80@dreskin.net> Message-ID: <20050121222123.GA1060@smtp.paip.net> On Fri, Jan 21, 2005 at 03:33:24PM -0600, Evan Schoenberg wrote: > I think I love you? :D > > That looks awesome. verbal and I are going to work on hooking that up > this weekend... I'll let you know if I run into any snags or questions. > > Two comments: > > 1) Would it be possible to automate the #define USING_GTK like so? > > #ifdef GTK_MAJOR_VERSION > #define USING_GTK > #endif But GTK_MAJOR_VERSION isn't defined unless you #include which you won't want to do unless USING_GTK is defined. > 2) The #define GAIM_PLUGINS at the top of otr-plugin.c seems like it > could instead be a -DGAIM_PLUGINS in the makefile... as having it in > the .c file forces dynamic compilation even if building statically, > whereas in the makefile it would only do its thing when building via > make (when of course you want to create a .so file). That's reasonable. In fact, probably both GAIM_PLUGINS and USING_GTK should be in the Makefile. Feel free to do that along with whatever else you need to do to get it to work nicely for you, and post the patches when you're done. > Actual code comments (or just laudations, since this looks really nice > and clean, thanks so much for all your hard work!) will follow once > I've played with implementation. Great. Looking forward to seeing OTR natively supported in Adium X. :-) Thanks, - Ian From alex323 at gmail.com Fri Jan 21 18:30:44 2005 From: alex323 at gmail.com (alex323) Date: Fri, 21 Jan 2005 18:30:44 -0500 Subject: [OTR-dev] DSA Signing Message-ID: <41F190A4.90306@gmail.com> The create signature method seems to output a byte array (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfsystemsecuritycryptographydsacryptoserviceproviderclasscreatesignaturetopic.asp) The only problem is that the protocol calls for: " DSA signature (DSASIG): (len is the length of the DSA public parameter q) len byte unsigned r, big-endian len byte unsigned s, big-endian " The output length of the byte array is 40 bytes. I've always known Q to be 20 bytes. Is it possible that the first half of the byte array is r, while the other half is s? - Alex -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 825 bytes Desc: OpenPGP digital signature URL: From ian at cypherpunks.ca Fri Jan 21 21:41:31 2005 From: ian at cypherpunks.ca (Ian Goldberg) Date: Fri, 21 Jan 2005 21:41:31 -0500 Subject: [OTR-dev] DSA Signing In-Reply-To: <41F190A4.90306@gmail.com> References: <41F190A4.90306@gmail.com> Message-ID: <20050122024131.GC1060@smtp.paip.net> On Fri, Jan 21, 2005 at 06:30:44PM -0500, alex323 wrote: > The output length of the byte array is 40 bytes. I've always known Q to > be 20 bytes. Is it possible that the first half of the byte array is r, > while the other half is s? That's almost certainly true. - Ian From evan.s at dreskin.net Sat Jan 22 23:33:59 2005 From: evan.s at dreskin.net (Evan Schoenberg) Date: Sat, 22 Jan 2005 22:33:59 -0600 Subject: [OTR-dev] Sending messages to yourself with OTR installed Message-ID: <0040A4A4-6CF8-11D9-868D-000A95685E80@dreskin.net> "We are receiving our own OTR messages. You are either trying to talk to yourself, or someone is reflecting your messages back at you." This seems like a good security thing to know... but shouldn't it only be presented if you are in an OTR connected conversation and it happens? -Evan From evan.s at dreskin.net Sat Jan 22 23:46:41 2005 From: evan.s at dreskin.net (Evan Schoenberg) Date: Sat, 22 Jan 2005 22:46:41 -0600 Subject: [OTR-dev] Core/UI Split of gaim-otr-1.0.3 In-Reply-To: <20050121222123.GA1060@smtp.paip.net> References: <3469D110-6B67-11D9-947F-000A95685E80@dreskin.net> <20050121133107.GP1060@smtp.paip.net> <9FB8F450-6BCC-11D9-947F-000A95685E80@dreskin.net> <20050121171504.GU1060@smtp.paip.net> <7BC787CF-6BD6-11D9-947F-000A95685E80@dreskin.net> <20050121202920.GX1060@smtp.paip.net> <14895CF4-6BF4-11D9-947F-000A95685E80@dreskin.net> <20050121222123.GA1060@smtp.paip.net> Message-ID: Attached is the patch, against the CVS you attached previously, for the changes I have made thus far. I can't compile the GTK portion yet (still haven't figured out how to resolve those make errors I was getting), but by sight it should be fine.. let me know if you run into any compile errors and I'll take care of them. Most of what this patch does is move things around; it shifts code into ui.c and dialogs.c, simplifying corresponding functions in the gtk UI modules and therefore reducing redundant code when implementing a second UI. Some things shifted into the gtk UI modules.. for example, the start/stop "Please wait" dialog functions no longer tell the UI what to do display but instead just inform it that private key generation has started (and stopped), leaving it up to the UI to present that information as it pleases. The "Please Wait" and "Done" code therefore moved into the gtk modules. I changed some if (blah == nil) return; lines to g_return_if_fail(blah != nil); to increase readability. This patch also does some #include shifting, allowing less specificity in the order in which headers must be included by having them include the files upon which they depend. It adds #ifdef HAVE_CONFIG_H #include "config.h" #endif to allow config.h files to be used as needed... This shouldn't be necessary with the makefile from the command line but makes other build environments easier to deal with. Speaking of the makefile, the patch adds -DUSE_GTK and -DGAIM_PLUGINS to the CFLAGS and moves them out of otr-plugin.c I think that's it. I tried to maintain the same style, indenting, etc. as is used in the rest of the code; any violations are accidental. Let me know if there are any problem areas or whatnot. :) Adium can now print pretty log messages from OTR UI callbacks as conversations are opened and closed. Progress! -Evan -------------- next part -------------- A non-text attachment was scrubbed... Name: gaim-otr-1.0.3.20050121526-core-ui-split.patch Type: application/octet-stream Size: 22918 bytes Desc: not available URL: -------------- next part -------------- On Jan 21, 2005, at 4:21 PM, Ian Goldberg wrote: > > Feel free to do that along with whatever else you need to do to get it > to work nicely for you, and post the patches when you're done. From ian at cypherpunks.ca Sun Jan 23 09:22:20 2005 From: ian at cypherpunks.ca (Ian Goldberg) Date: Sun, 23 Jan 2005 09:22:20 -0500 Subject: [OTR-dev] Sending messages to yourself with OTR installed In-Reply-To: <0040A4A4-6CF8-11D9-868D-000A95685E80@dreskin.net> References: <0040A4A4-6CF8-11D9-868D-000A95685E80@dreskin.net> Message-ID: <20050123142220.GJ1060@smtp.paip.net> On Sat, Jan 22, 2005 at 10:33:59PM -0600, Evan Schoenberg wrote: > "We are receiving our own OTR messages. > You are either trying to talk to yourself, or someone is reflecting > your messages back at you." > > This seems like a good security thing to know... but shouldn't it only > be presented if you are in an OTR connected conversation and it > happens? It happens when you receive a Key Exchange Message that's the same as one you just sent out. - Ian From alex323 at gmail.com Sun Jan 23 09:54:42 2005 From: alex323 at gmail.com (alex323) Date: Sun, 23 Jan 2005 09:54:42 -0500 Subject: [OTR-dev] Sending messages to yourself with OTR installed In-Reply-To: <0040A4A4-6CF8-11D9-868D-000A95685E80@dreskin.net> References: <0040A4A4-6CF8-11D9-868D-000A95685E80@dreskin.net> Message-ID: <41F3BAB2.10207@gmail.com> What if they reflect your key exchange message back at you? Evan Schoenberg wrote: > "We are receiving our own OTR messages. > You are either trying to talk to yourself, or someone is reflecting > your messages back at you." > > This seems like a good security thing to know... but shouldn't it only > be presented if you are in an OTR connected conversation and it happens? > > -Evan > > _______________________________________________ > OTR-dev mailing list > OTR-dev at lists.cypherpunks.ca > http://lists.cypherpunks.ca/mailman/listinfo/otr-dev > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 825 bytes Desc: OpenPGP digital signature URL: From ian at cypherpunks.ca Sun Jan 23 10:50:58 2005 From: ian at cypherpunks.ca (Ian Goldberg) Date: Sun, 23 Jan 2005 10:50:58 -0500 Subject: [OTR-dev] Core/UI Split of gaim-otr-1.0.3 In-Reply-To: References: <3469D110-6B67-11D9-947F-000A95685E80@dreskin.net> <20050121133107.GP1060@smtp.paip.net> <9FB8F450-6BCC-11D9-947F-000A95685E80@dreskin.net> <20050121171504.GU1060@smtp.paip.net> <7BC787CF-6BD6-11D9-947F-000A95685E80@dreskin.net> <20050121202920.GX1060@smtp.paip.net> <14895CF4-6BF4-11D9-947F-000A95685E80@dreskin.net> <20050121222123.GA1060@smtp.paip.net> Message-ID: <20050123155058.GK1060@smtp.paip.net> On Sat, Jan 22, 2005 at 10:46:41PM -0600, Evan Schoenberg wrote: > Attached is the patch, against the CVS you attached previously, for the > changes I have made thus far. I can't compile the GTK portion yet > (still haven't figured out how to resolve those make errors I was > getting), but by sight it should be fine.. let me know if you run into > any compile errors and I'll take care of them. Coolio. :-) I applied it, fixed some errors, and cleaned it up a bit (you added a selected_fingerprint() callback which was never used as a callback, so I re-removed it). http://www.cypherpunks.ca/otr/gaim-otr-cvs-latest.tar.gz - Ian From evan.s at dreskin.net Sun Jan 23 14:50:10 2005 From: evan.s at dreskin.net (Evan Schoenberg) Date: Sun, 23 Jan 2005 13:50:10 -0600 Subject: [OTR-dev] Sending messages to yourself with OTR installed In-Reply-To: <20050123142220.GJ1060@smtp.paip.net> References: <0040A4A4-6CF8-11D9-868D-000A95685E80@dreskin.net> <20050123142220.GJ1060@smtp.paip.net> Message-ID: On Jan 23, 2005, at 8:22 AM, Ian Goldberg wrote: > > It happens when you receive a Key Exchange Message that's the same as > one you just sent out. > Does that happen automatically as soon as you send a message in a new conversation? If so, how do non-OTR clients know not to display the key exchange message? From evan.s at dreskin.net Sun Jan 23 15:19:16 2005 From: evan.s at dreskin.net (Evan Schoenberg) Date: Sun, 23 Jan 2005 14:19:16 -0600 Subject: [OTR-dev] Sending messages to yourself with OTR installed In-Reply-To: References: <0040A4A4-6CF8-11D9-868D-000A95685E80@dreskin.net> <20050123142220.GJ1060@smtp.paip.net> Message-ID: <0E2B9A7A-6D7C-11D9-868D-000A95685E80@dreskin.net> Nevermind.... figured out the source of my confusion When debugging I had added otrg_plugin_send_default_query_conv(conv) to the UI callback for when a new conversation is created, and then I forgot I'd added the line... so I was automatically connecting :) -Evan On Jan 23, 2005, at 1:50 PM, Evan Schoenberg wrote: > > On Jan 23, 2005, at 8:22 AM, Ian Goldberg wrote: >> >> It happens when you receive a Key Exchange Message that's the same as >> one you just sent out. >> > Does that happen automatically as soon as you send a message in a new > conversation? If so, how do non-OTR clients know not to display the > key exchange message? > > _______________________________________________ > OTR-dev mailing list > OTR-dev at lists.cypherpunks.ca > http://lists.cypherpunks.ca/mailman/listinfo/otr-dev > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 846 bytes Desc: not available URL: From evan.s at dreskin.net Mon Jan 24 12:17:20 2005 From: evan.s at dreskin.net (Evan Schoenberg) Date: Mon, 24 Jan 2005 11:17:20 -0600 Subject: [OTR-dev] OTR in Adium X Message-ID: I just had my first OTR-secured conversation in Adium, with another Adium user. =) The UI is ugly right now, and there's no key management preferences yet, but those are just details. -Evan www.adiumx.com From nikitab at cs.berkeley.edu Mon Jan 24 16:16:17 2005 From: nikitab at cs.berkeley.edu (Nikita Borisov) Date: Mon, 24 Jan 2005 13:16:17 -0800 Subject: [OTR-dev] OTR in Adium X In-Reply-To: References: Message-ID: <2FEFC8CC-6E4D-11D9-99A5-000A95873CEC@cs.berkeley.edu> On Jan 24, 2005, at 9:17 AM, Evan Schoenberg wrote: > I just had my first OTR-secured conversation in Adium, with another > Adium user. =) Wow, that's great news! I'm using Adium X right now under MacOS X, so if you want someone else to test with, I'd be happy to help. - Nikita From evan.s at dreskin.net Tue Jan 25 14:48:54 2005 From: evan.s at dreskin.net (Evan Schoenberg) Date: Tue, 25 Jan 2005 13:48:54 -0600 Subject: [OTR-dev] SESS_DIR_LOW vs SESS_DIR_HIGH? Message-ID: <256DAAA0-6F0A-11D9-868D-000A95685E80@dreskin.net> What do SESS_DIR_LOW and SESS_DIR_HIGH mean? I see that one is bolded and one is not... is one your Secure ID and the other the remote one? Also, do y'all think it is strictly necessary to always immediately display session IDs when connected, or would it be reasonable to have a "Show Details" which reveals this information if it is desired? -Evan -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 369 bytes Desc: not available URL: From ian at cypherpunks.ca Tue Jan 25 17:49:39 2005 From: ian at cypherpunks.ca (Ian Goldberg) Date: Tue, 25 Jan 2005 17:49:39 -0500 Subject: [OTR-dev] SESS_DIR_LOW vs SESS_DIR_HIGH? In-Reply-To: <256DAAA0-6F0A-11D9-868D-000A95685E80@dreskin.net> References: <256DAAA0-6F0A-11D9-868D-000A95685E80@dreskin.net> Message-ID: <20050125224939.GR1060@smtp.paip.net> On Tue, Jan 25, 2005 at 01:48:54PM -0600, Evan Schoenberg wrote: > What do SESS_DIR_LOW and SESS_DIR_HIGH mean? I see that one is > bolded and one is not... is one your Secure ID and the other the remote > one? The secure session id is shared between the two of you. One half is bold; the intent is that if you choose to verify the session id by some out-of-band means (phone, or whatever), you each read your bold part to the other guy. gaim-otr's README says: The "secure id" is another way to verify that you're actually chatting with your buddy, and not some eavesdropper ("man-in-the-middle" is the technical term). Phone him up, and ask him to read his bold part, and read yours back to him. If they're both correct, you're assured that there's no one intercepting your private conversation. This is secure, even if you know that one or both of your private keys have been compromised. > Also, do y'all think it is strictly necessary to always immediately > display session IDs when connected, or would it be reasonable to have a > "Show Details" which reveals this information if it is desired? That'd be fine, I think. - Ian From evan.s at dreskin.net Tue Jan 25 18:01:43 2005 From: evan.s at dreskin.net (Evan Schoenberg) Date: Tue, 25 Jan 2005 17:01:43 -0600 Subject: [OTR-dev] SESS_DIR_LOW vs SESS_DIR_HIGH? In-Reply-To: <20050125224939.GR1060@smtp.paip.net> References: <256DAAA0-6F0A-11D9-868D-000A95685E80@dreskin.net> <20050125224939.GR1060@smtp.paip.net> Message-ID: <149F92A0-6F25-11D9-868D-000A95685E80@dreskin.net> On Jan 25, 2005, at 4:49 PM, Ian Goldberg wrote: > On Tue, Jan 25, 2005 at 01:48:54PM -0600, Evan Schoenberg wrote: >> What do SESS_DIR_LOW and SESS_DIR_HIGH mean? I see that one is >> bolded and one is not... is one your Secure ID and the other the >> remote >> one? > > The secure session id is shared between the two of you. One half is > bold; the intent is that if you choose to verify the session id by some > out-of-band means (phone, or whatever), you each read your bold part to > the other guy. > Ah, I see. If I'm putting it somewhere in plain (unformatted) text, what do you think would be a good label for each part, then? Right now I have whichever one would be bold in gaim-otr being labeled the "incoming" secure ID, and the other the "outgoing." > gaim-otr's README says: > If they're > both correct, you're assured that there's no one intercepting your > private conversation. This is secure, even if you know that one or > both of your private keys have been compromised. > Damnit, read the README and forgot that part. I hate asking questions which are already answered :) How is it that this is secure even if one or both private keys are compromised? -Evan From ian at cypherpunks.ca Tue Jan 25 18:02:44 2005 From: ian at cypherpunks.ca (Ian Goldberg) Date: Tue, 25 Jan 2005 18:02:44 -0500 Subject: [OTR-dev] Hmmm. Message-ID: <20050125230244.GT1060@smtp.paip.net> So I came across a small bug in gaim-otr: when you're presented with an unknown fingerprint, the gaim-otr dialog says: l33thax0r (IRC) has presented us with an unknown fingerprint. But of course that's not enough information to identify who we're talking about, since there may be different l33thax0r's on different IRC networks. It really should say: l33thax0r (IRC) has presented k00lk1d at irc.freenode.net with an unknown fingerprint. This is easy to fix. Unfortunately, it requires a small change in the libotr API (the function that handles unknown fingerprints needs to take an additional argument (the account name)). I'd do this in a heartbeat, except now we've got versioning rules about changing the API, so this would mean the release of libotr 2.0.0. Is there any reason not to do that? Am I just having silly hangups about increasing the major number for a relatively small bugfix (but one that incompatibly changes the API)? I could also wait a little bit and see if Evan or the proxy work shows up any other changes that can be put into 2.0.0 at the same time. [Evan shouldn't release his Adium code until 2.0.0 is out, and then he should use that (and display the account name, which will then be delivered to him). So that's an argument for "sooner, rather than later". So is "release early, release often".] [In other news, I just got a AM_PATH_LIBOTR autoconf macro working, and the proxy is now autoconfiscated and using it. :-) ] So: release often, or hold off? - Ian From gdt at ir.bbn.com Tue Jan 25 19:35:52 2005 From: gdt at ir.bbn.com (Greg Troxel) Date: 25 Jan 2005 19:35:52 -0500 Subject: [OTR-dev] Hmmm. In-Reply-To: <20050125230244.GT1060@smtp.paip.net> References: <20050125230244.GT1060@smtp.paip.net> Message-ID: If you can leave the old function and add a new one, you don't have to bump major. But if it's a callback that's really annoying. While I'm fussy about shlib versions, I don't see that the libotr version has to follow the shlib version. But I also don't see the harm. Waiting to batch changes is quite sane, too. In src/libc in NetBSD source tree there is a big list (12 things?) of things to change on next major bump. This would be a good prod to review the whole API for any other issues. [In other news, I just got a AM_PATH_LIBOTR autoconf macro working, and the proxy is now autoconfiscated and using it. :-) ] Cool. I was going to make up a libotr.pc.in file so that we could use pkg-config to find libotr. Basically pkg-config abstracts what you want in something like AM_PATH_LIBOTR, providing generic code and a data file. -- Greg Troxel From ian at cypherpunks.ca Tue Jan 25 19:46:24 2005 From: ian at cypherpunks.ca (Ian Goldberg) Date: Tue, 25 Jan 2005 19:46:24 -0500 Subject: [OTR-dev] SESS_DIR_LOW vs SESS_DIR_HIGH? In-Reply-To: <149F92A0-6F25-11D9-868D-000A95685E80@dreskin.net> References: <256DAAA0-6F0A-11D9-868D-000A95685E80@dreskin.net> <20050125224939.GR1060@smtp.paip.net> <149F92A0-6F25-11D9-868D-000A95685E80@dreskin.net> Message-ID: <20050126004624.GU1060@smtp.paip.net> On Tue, Jan 25, 2005 at 05:01:43PM -0600, Evan Schoenberg wrote: > Ah, I see. If I'm putting it somewhere in plain (unformatted) text, > what do you think would be a good label for each part, then? Right now > I have whichever one would be bold in gaim-otr being labeled the > "incoming" secure ID, and the other the "outgoing." The "printf UI" version of otrproxy surrounds the part that should be bold with asterisks: *** Tue Jan 25 11:09:26 2005 *** INFO: Private connection established Private connection with mumblemumble (AIM/ICQ) established. Fingerprint: 36D65628 A56C5E5C 376F1E88 BA2EFC04 BF07DBA9 Secure ID for this session: *aa687ac829b0367854f6* 0333b95bf0e1726c49c7 > >gaim-otr's README says: > > If they're > > both correct, you're assured that there's no one intercepting your > > private conversation. This is secure, even if you know that one or > > both of your private keys have been compromised. > > > > Damnit, read the README and forgot that part. I hate asking questions > which are already answered :) > > How is it that this is secure even if one or both private keys are > compromised? The private keys are used to sign the DH key exchange; that's the primary way you know the person at the other end of the DH-secured tunnel is who you think it is. But if the DH keys have been compromised, hearing your friend read the secure session id (which is a hash of the DH shared secret) will do just as well to convince you. - Ian From evan.s at dreskin.net Tue Jan 25 21:10:59 2005 From: evan.s at dreskin.net (Evan Schoenberg) Date: Tue, 25 Jan 2005 20:10:59 -0600 Subject: [OTR-dev] Hmmm. In-Reply-To: <20050125230244.GT1060@smtp.paip.net> References: <20050125230244.GT1060@smtp.paip.net> Message-ID: <852EF34A-6F3F-11D9-868D-000A95685E80@dreskin.net> *nod* the unknown fingerprint callback is the only important place from which you can't reconstruct the GaimConversation associated with the transaction.. I was going to email you about that soon. Whereas Gaim loves to throw up additional windows when things happen, we try to integrate information into the chat window (or other window) where possible in Adium, so being able to associate to a GaimConversation (and from there to an Adium Chat) is nice. On Jan 25, 2005, at 5:02 PM, Ian Goldberg wrote: > [Evan shouldn't release his Adium code > until 2.0.0 is out, and then he should use that (and display the > account > name, which will then be delivered to him). So that's an argument for > "sooner, rather than later". So is "release early, release often".] > I'm really excited with how well the Adium work has proceeded... what other changes/improvements be in 2.0.0 for which it's necessary to wait? > So: release often, or hold off? > One argument could be that the longer a release is put off, the more people it will effect.. since OTR is relatively new in the mainstream perception, there aren't nearly as many adopters right now as there will later be. -Evan From mid at zigamorph.net Tue Jan 25 22:26:17 2005 From: mid at zigamorph.net (Adam Fritzler) Date: Tue, 25 Jan 2005 19:26:17 -0800 Subject: [OTR-dev] proposed API change Message-ID: <20050126032617.GC14936@zigamorph.net> I'm new here, but I just happened to see Ian's last post about making an API change and wanted to recommend another. libotr currently keeps at least two (at first glance at least, maybe there's more) globals. I think it's generally frowned upon to have libraries with internal globals, and for the thing I'm working on it, it is kind of annoying. I'm working on a proxy solution[1] that potentially has several entirely unrelated users coexisting. In an optimal environment, you of course wouldn't use a "public service" proxy to do your crypto, but the APIs are such that it'd be a lot less annoying if libotr didn't keep globals, even for the single-user case. As it stands now, the private key files and fingerprint store must be shared by anyone who uses the proxy! I suggest making a "libotr context" struct that gets passed to all functions, and moving the globals to there. It's a straightforward change, but I can make a patch if necessary. asf. [1] See http://www.zigamorph.net/timps/ From evan.s at dreskin.net Wed Jan 26 00:26:28 2005 From: evan.s at dreskin.net (Evan Schoenberg) Date: Tue, 25 Jan 2005 23:26:28 -0600 Subject: [OTR-dev] Secure connections through a connect/disconnect cycle, OTR error messages Message-ID: Two situations, and associated questions: 1) - My friend and I are chatting via OTR - I disconnect. I reconnect (same application session). We can continue chatting as before. - I disconnect and quit. - I relaunch the application and connect. I open a message window to my friend and send him a normal (unencrypted) message, not realizing he has remained connected and not hit stopped the OTR session. - I receive: ?OTR Error: You sent unencrypted data to , who was expecting encrypted messages from you. Question: Should a client disconnect all OTR sessions on an account when that account disconnects? And from my friend's perspective, should a client disconnect an OTR session when the target contact disconnects? 2) - My friend decides to cancel the OTR session without telling me. - I send a message - I receive: ?OTR Error: You sent encrypted data to , who wasn't expecting it. Question: Is there a way in which the protocol could be expended to send some sort of otr-specific message to the other side letting it know that one person has asked to end the session? -Evan www.adiumx.com -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 1191 bytes Desc: not available URL: From evan.s at dreskin.net Wed Jan 26 00:47:16 2005 From: evan.s at dreskin.net (Evan Schoenberg) Date: Tue, 25 Jan 2005 23:47:16 -0600 Subject: [OTR-dev] Displaying OTR errors (was Re: Hmmm.) In-Reply-To: <20050125230244.GT1060@smtp.paip.net> References: <20050125230244.GT1060@smtp.paip.net> Message-ID: On Jan 25, 2005, at 5:02 PM, Ian Goldberg wrote: > I could also wait a little bit and see if Evan or the proxy work > shows up any other changes that can be put > into 2.0.0 at the same time. At present, libotr sends errors back to the UI via the inject_message callback. This gets the job done, but it's somewhat dirty... the other side didn't actually send the message. a) This means that the client doesn't have any way of presenting the error condition in a manner different from a normal message (gaim-otr would use gaim_conv_present_error() for example) b) This also means that a malicious or confusing user could masquerade as OTR errors by simply sending the text of an OTR error, since it appears the same way. I propose a new callback, inject_error. Thoughts? -Evan -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 835 bytes Desc: not available URL: From mid at zigamorph.net Wed Jan 26 01:48:45 2005 From: mid at zigamorph.net (Adam Fritzler) Date: Tue, 25 Jan 2005 22:48:45 -0800 Subject: [OTR-dev] Displaying OTR errors (was Re: Hmmm.) In-Reply-To: References: <20050125230244.GT1060@smtp.paip.net> Message-ID: <20050126064845.GA27798@zigamorph.net> On Tue, Jan 25, 2005 at 11:47:16PM -0600, Evan Schoenberg wrote: > I propose a new callback, inject_error. Thoughts? There's already the notify callback, with error/warning/info distinctions. Could just add the user information to that one. Unrelatedly, collecting the gone_secure/gone_insecure/still_secure callbacks into one "conversation event" callback might be more logical. asf. From evan.s at dreskin.net Wed Jan 26 02:14:33 2005 From: evan.s at dreskin.net (Evan Schoenberg) Date: Wed, 26 Jan 2005 01:14:33 -0600 Subject: [OTR-dev] Displaying OTR errors (was Re: Hmmm.) In-Reply-To: <20050126064845.GA27798@zigamorph.net> References: <20050125230244.GT1060@smtp.paip.net> <20050126064845.GA27798@zigamorph.net> Message-ID: The notify callback displays a window at present... it could handle it the way Gaim does error messages, using gaim_conv_present_error() if possible (that is, if given a valid account and protocol and username which resolves to a valid GaimConversation) and falling back on displaying a window if necessary. Either way. On Jan 26, 2005, at 12:48 AM, Adam Fritzler wrote: > > On Tue, Jan 25, 2005 at 11:47:16PM -0600, Evan Schoenberg wrote: > >> I propose a new callback, inject_error. Thoughts? > > There's already the notify callback, with error/warning/info > distinctions. Could just add the user information to that one. > > > Unrelatedly, collecting the gone_secure/gone_insecure/still_secure > callbacks into one "conversation event" callback might be more logical. > > asf. > > > _______________________________________________ > OTR-dev mailing list > OTR-dev at lists.cypherpunks.ca > http://lists.cypherpunks.ca/mailman/listinfo/otr-dev > From paul at cypherpunks.ca Wed Jan 26 03:01:31 2005 From: paul at cypherpunks.ca (Paul Wouters) Date: Wed, 26 Jan 2005 09:01:31 +0100 (CET) Subject: [OTR-dev] proposed API change In-Reply-To: <20050126032617.GC14936@zigamorph.net> Message-ID: On Tue, 25 Jan 2005, Adam Fritzler wrote: > I'm working on a proxy solution[1] that You know about otrproxy? http://www.cypherpunks.ca/otr/README-otrproxy.txt Paul From verbal at gmail.com Wed Jan 26 03:04:04 2005 From: verbal at gmail.com (verbal) Date: Wed, 26 Jan 2005 00:04:04 -0800 Subject: [OTR-dev] OTR encryption state Message-ID: ok, that was a very undescriptive subject, but the issue at hand is about the behavior of a chat program when someone wants to stop encrypting messages. this is how it currently works in adium: -alice and bob are having an otr-encrypted chat. -alice decides she no longer wants to talk to bob in an encrypted manner. -alice turns off otr via UI. -bob keeps sending messages to alice. -the first message alice sees from bob, adium says its encrypted and that she cant read it. -*alice's adium client puts her back into otr mode* -if alice sends a message to bob while her encryption is off, then bob's adium client warns him that it is unencrypted, but alice's adium client will once again put her back in otr mode. now, obviously i like OTR and think encryption is a good thing ;), but evan and i feel that if a user decides to stop encrypting a conversation, s/he's decision should hold. our proposed solution is that if alice turns off otr, then messages sent to bob will be displayed as "unecrypted" to bob, and messages sent to alice from bob will be encrypted and alice would be notified of this. this will happen until either alice renables encryption or bob unenables encryption, ie they're both synced up. -verbal From ian at cypherpunks.ca Wed Jan 26 09:59:54 2005 From: ian at cypherpunks.ca (Ian Goldberg) Date: Wed, 26 Jan 2005 09:59:54 -0500 Subject: [OTR-dev] proposed API change In-Reply-To: <20050126032617.GC14936@zigamorph.net> References: <20050126032617.GC14936@zigamorph.net> Message-ID: <20050126145954.GV1060@smtp.paip.net> On Tue, Jan 25, 2005 at 07:26:17PM -0800, Adam Fritzler wrote: > > I'm new here, but I just happened to see Ian's last post about making an > API change and wanted to recommend another. > > libotr currently keeps at least two (at first glance at least, maybe > there's more) globals. I think it's generally frowned upon to have > libraries with internal globals, and for the thing I'm working on it, > it is kind of annoying. I'm working on a proxy solution[1] that > potentially has several entirely unrelated users coexisting. In an > optimal environment, you of course wouldn't use a "public service" proxy > to do your crypto, but the APIs are such that it'd be a lot less > annoying if libotr didn't keep globals, even for the single-user case. > As it stands now, the private key files and fingerprint store must be > shared by anyone who uses the proxy! > > I suggest making a "libotr context" struct that gets passed to all > functions, and moving the globals to there. It's a straightforward > change, but I can make a patch if necessary. In fact I noticed this idea on your blog entry yesterday, and thought it was a good one. It's just about done being implemented now. :-) - Ian From ian at cypherpunks.ca Wed Jan 26 10:07:32 2005 From: ian at cypherpunks.ca (Ian Goldberg) Date: Wed, 26 Jan 2005 10:07:32 -0500 Subject: [OTR-dev] Secure connections through a connect/disconnect cycle, OTR error messages In-Reply-To: References: Message-ID: <20050126150732.GW1060@smtp.paip.net> On Tue, Jan 25, 2005 at 11:26:28PM -0600, Evan Schoenberg wrote: > Two situations, and associated questions: > > 1) > - My friend and I are chatting via OTR > - I disconnect. I reconnect (same application session). We can > continue chatting as before. > - I disconnect and quit. > - I relaunch the application and connect. I open a message window to > my friend and send him a normal (unencrypted) message, not realizing he > has remained connected and not hit stopped the OTR session. > - I receive: ?OTR Error: You sent unencrypted data to , who was > expecting encrypted messages from you. > > Question: Should a client disconnect all OTR sessions on an account > when that account disconnects? And from my friend's perspective, should > a client disconnect an OTR session when the target contact disconnects? Not all IM networks tell you when someone you're talking to logs off, unfortunately. :-( Since the failure mode is minimal (your message gets through to him anyway), it's probably not a big deal. > 2) > - My friend decides to cancel the OTR session without telling me. > - I send a message > - I receive: ?OTR Error: You sent encrypted data to , who wasn't > expecting it. > > Question: Is there a way in which the protocol could be expended to > send some sort of otr-specific message to the other side letting it > know that one person has asked to end the session? No, and that's quite on purpose. There should be NO WAY a network message can cause a session to transition from private to not private. If there were, you'd have to be really, really careful about whether that message is authentic / replayed / etc. There's also the problem of: 1. user (in secure conversation) starts typing private message, 2. other side ends the session, sending "session ended" packet to user 3. User hits Enter to send his message in the (now unencrypted) session. It's really important that the user have to take non-trivial action to leave a private conversation. - Ian From paul at cypherpunks.ca Wed Jan 26 10:17:50 2005 From: paul at cypherpunks.ca (Paul Wouters) Date: Wed, 26 Jan 2005 16:17:50 +0100 (CET) Subject: [OTR-dev] Secure connections through a connect/disconnect cycle, OTR error messages In-Reply-To: <20050126150732.GW1060@smtp.paip.net> Message-ID: On Wed, 26 Jan 2005, Ian Goldberg wrote: > It's really important that the user have to take non-trivial action to > leave a private conversation. But it would be very nice if we don't get to deal with these re-login problems. Almost daily, I have to retype a message send to an OTR user that has gone to bed meanwhile and logged back on, while my machine stays on, and they receive a message they can't read, and one end has to refresh and then I can resend that message. Is there a way perhaps to automate this with a prepended [automatic resend]? Paul From gdt at ir.bbn.com Wed Jan 26 10:18:50 2005 From: gdt at ir.bbn.com (Greg Troxel) Date: 26 Jan 2005 10:18:50 -0500 Subject: [OTR-dev] SESS_DIR_LOW vs SESS_DIR_HIGH? In-Reply-To: <20050126004624.GU1060@smtp.paip.net> References: <256DAAA0-6F0A-11D9-868D-000A95685E80@dreskin.net> <20050125224939.GR1060@smtp.paip.net> <149F92A0-6F25-11D9-868D-000A95685E80@dreskin.net> <20050126004624.GU1060@smtp.paip.net> Message-ID: The private keys are used to sign the DH key exchange; that's the primary way you know the person at the other end of the DH-secured tunnel is who you think it is. But if the DH keys have been compromised, hearing your friend read the secure session id (which is a hash of the DH shared secret) will do just as well to convince you. Sure, but this is way down on the usability scale. I suspect almost no one does this, so perhaps showing the conection hashes should be a 'show details' option, rather than a 'in your face' behavior. Plus, a threat model that leads to DSA key compromise is likely to include trojaned software. -- Greg Troxel From gdt at ir.bbn.com Wed Jan 26 10:19:58 2005 From: gdt at ir.bbn.com (Greg Troxel) Date: 26 Jan 2005 10:19:58 -0500 Subject: [OTR-dev] proposed API change In-Reply-To: <20050126032617.GC14936@zigamorph.net> References: <20050126032617.GC14936@zigamorph.net> Message-ID: I'll second this. Not for any particular need, but cleanliness. -- Greg Troxel From gdt at ir.bbn.com Wed Jan 26 10:23:29 2005 From: gdt at ir.bbn.com (Greg Troxel) Date: 26 Jan 2005 10:23:29 -0500 Subject: [OTR-dev] OTR encryption state In-Reply-To: References: Message-ID: Right now OTR has a notion that it is always autonegotiated on. One can terminate a session, but there is still a hardwired default to enable OTR when possible. To solve your 'problem', one could add a new bit in the per-correspondent UI that says "OTR desired", and have the auto-negotiate behavior be conditional on that being on. -- Greg Troxel From ian at cypherpunks.ca Wed Jan 26 10:29:53 2005 From: ian at cypherpunks.ca (Ian Goldberg) Date: Wed, 26 Jan 2005 10:29:53 -0500 Subject: [OTR-dev] Displaying OTR errors (was Re: Hmmm.) In-Reply-To: References: <20050125230244.GT1060@smtp.paip.net> Message-ID: <20050126152953.GX1060@smtp.paip.net> On Tue, Jan 25, 2005 at 11:47:16PM -0600, Evan Schoenberg wrote: > > On Jan 25, 2005, at 5:02 PM, Ian Goldberg wrote: > > > I could also wait a little bit and see if Evan or the proxy work > > shows up any other changes that can be put > > into 2.0.0 at the same time. > > > > At present, libotr sends errors back to the UI via the inject_message > callback. This gets the job done, but it's somewhat dirty... the other > side didn't actually send the message. Actually, it doesn't. It sends error messages to *the other person* using inject_message. It sends error messages to you with the notify callback (if a window should be popped up) or just by setting *messagep (if it should be displayed inline). [It used to be that all messages were displayed ouot-of-band in a popup, but people got annoyed at that really fast.] - Ian From ian at cypherpunks.ca Wed Jan 26 10:49:59 2005 From: ian at cypherpunks.ca (Ian Goldberg) Date: Wed, 26 Jan 2005 10:49:59 -0500 Subject: [OTR-dev] Hmmm. In-Reply-To: <852EF34A-6F3F-11D9-868D-000A95685E80@dreskin.net> References: <20050125230244.GT1060@smtp.paip.net> <852EF34A-6F3F-11D9-868D-000A95685E80@dreskin.net> Message-ID: <20050126154959.GY1060@smtp.paip.net> On Tue, Jan 25, 2005 at 08:10:59PM -0600, Evan Schoenberg wrote: > I'm really excited with how well the Adium work has proceeded... what > other changes/improvements be in 2.0.0 for which it's necessary to > wait? Here's a CVS snapshot: http://www.cypherpunks.ca/otr/libotr-cvs-latest.tar.gz ChangeLog since 1.0.4: 2005-01-26 * packaging/debian/control: Changed debian package names to libotr1 and libotr1-dev. * libotr.m4: Added copyright notice, more comments * src/userstate.c: * src/userstate.h: New files * src/Makefile.am: Added -Wall to default CFLAGS * toolkit/Makefile.am: Added -Wall to default CFLAGS * src/context.c (otrl_context_find, otrl_context_forget_all): * src/context.h (otrl_context_find, otrl_context_forget_all): * src/message.c (otrl_message_sending, process_kem) (process_confresp, otrl_message_receiving): * src/message.h (otrl_message_sending, otrl_message_receiving) (OtrlMessageAppOps.confirm_fingerprint): * src/privkey.c (otrl_privkey_fingerprint, otrl_privkey_read) (otrl_privkey_generate, otrl_privkey_read_fingerprints) (otrl_privkey_write_fingerprints, otrl_privkey_find) (otrl_privkey_forget_all): * src/privkey.h (otrl_privkey_fingerprint, otrl_privkey_read) (otrl_privkey_generate, otrl_privkey_read_fingerprints) (otrl_privkey_write_fingerprints, otrl_privkey_find) (otrl_privkey_forget_all): * src/proto.c (otrl_proto_create_key_exchange) (otrl_proto_accept_key_exchange): * src/proto.h (otrl_proto_create_key_exchange) (otrl_proto_accept_key_exchange): Added OtrlUserState parameter to many calls, eliminating global state. * src/privkey.c (otrl_privkey_fingerprint): the buffer is now passed in, and not static 2005-01-25 * src/version.h: bumped version number to 2.0.0 because API changed incompatibly * configure.ac: bumped version number to 2.0.0 because API changed incompatibly * src/message.h: added accountname parameter to confirm_fingerprint callback * src/message.c: passed accountname to confirm_fingerprint callback * libotr.m4: new file * Makefile.am: install (and uninstall) new libotr.m4 file * tools/Makefile.am: clean up manpage symlinks and add an uninstall rule 2005-01-23 * src/proto.h: moved numeric version defines into version.h * src/version.h: moved numeric version defines into version.h * src/message.c (otrl_message_receiving): Update the context list if we create a new context From evan.s at dreskin.net Wed Jan 26 11:23:45 2005 From: evan.s at dreskin.net (Evan Schoenberg) Date: Wed, 26 Jan 2005 10:23:45 -0600 Subject: [OTR-dev] Displaying OTR errors (was Re: Hmmm.) In-Reply-To: <20050126152953.GX1060@smtp.paip.net> References: <20050125230244.GT1060@smtp.paip.net> <20050126152953.GX1060@smtp.paip.net> Message-ID: Sorry, I was not sufficiently specific. I didn't mean that all errors are sent via inject_message, just that there are some which are and should not be. 9:30:30 : ?OTR Error: You sent unencrypted data to , who was expecting encrypted messages from you. 10:23:21 : ?OTR Error: You sent encrypted data to , who wasn't expecting it. 10:45:21 : The encrypted message received from is unreadable, as you are not currently communicating privately. 10:46:10 : The following message received from was not encrypted: [ok, I canceled encryption Those are four error conditions which are displayed as incoming messages. The first and second are definitely errors, but they are presented as simple text received from the other person. The third I believe should be presented as an error, not a message, as it does not contain message text. The fourth does make sense presenting as a message, carrying its OTR descriptive prefix ("The following message received.... was not encrypted:") Is that clearer? Thanks, Evan On Jan 26, 2005, at 9:29 AM, Ian Goldberg wrote: > Actually, it doesn't. It sends error messages to *the other person* > using inject_message. It sends error messages to you with the notify > callback (if a window should be popped up) or just by setting *messagep > (if it should be displayed inline). [It used to be that all messages > were displayed ouot-of-band in a popup, but people got annoyed at that > really fast.] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 2010 bytes Desc: not available URL: From evan.s at dreskin.net Wed Jan 26 11:26:45 2005 From: evan.s at dreskin.net (Evan Schoenberg) Date: Wed, 26 Jan 2005 10:26:45 -0600 Subject: [OTR-dev] SESS_DIR_LOW vs SESS_DIR_HIGH? In-Reply-To: References: <256DAAA0-6F0A-11D9-868D-000A95685E80@dreskin.net> <20050125224939.GR1060@smtp.paip.net> <149F92A0-6F25-11D9-868D-000A95685E80@dreskin.net> <20050126004624.GU1060@smtp.paip.net> Message-ID: <1201D366-6FB7-11D9-868D-000A95685E80@dreskin.net> On Jan 26, 2005, at 9:18 AM, Greg Troxel wrote: > Sure, but this is way down on the usability scale. I suspect almost > no one does this, so perhaps showing the conection hashes should be a > 'show details' option, rather than a 'in your face' behavior. *nod* That's how Adium is going to handle it. The menu off the locked/unlocked emblem (currently in the message window toolbar, will probably make its way elsewhere as well) has: Initiate encrypted OTR chat Show details... About encryption... Where initiate toggles to cancel once you are connected, show details is desensitized/disabled until connected, and about encryption gives a brief description of OTR and a link to the web site for more information. From evan.s at dreskin.net Wed Jan 26 11:30:53 2005 From: evan.s at dreskin.net (Evan Schoenberg) Date: Wed, 26 Jan 2005 10:30:53 -0600 Subject: [OTR-dev] Secure connections through a connect/disconnect cycle, OTR error messages In-Reply-To: <20050126150732.GW1060@smtp.paip.net> References: <20050126150732.GW1060@smtp.paip.net> Message-ID: I agree 100%. It would be disastrous for a client to bring you from encrypted to unencrypted automatically. I was just wondering if a message... which protocol specs say no client should act on besides to present the information to the other side... could be sent, such that if my friend clicks "end encrypted chat" I immediately see an OTR message in my chat informing me that the remote side has requested to end the OTR chat. No action is taken, but I am informed so I can either stop chatting with the person (since they won't see my messages) or cancel encryption myself (at which point we will be able to chat in plaintext) or contact my friend in some other manner to ask him to turn encryption back on. -Evan On Jan 26, 2005, at 9:07 AM, Ian Goldberg wrote: > No, and that's quite on purpose. There should be NO WAY a network > message can cause a session to transition from private to not private. > If there were, you'd have to be really, really careful about whether > that message is authentic / replayed / etc. There's also the problem > of: 1. user (in secure conversation) starts typing private message, > 2. other side ends the session, sending "session ended" packet to user > 3. User hits Enter to send his message in the (now unencrypted) > session. > > It's really important that the user have to take non-trivial action to > leave a private conversation. From nikitab at cs.berkeley.edu Wed Jan 26 11:36:16 2005 From: nikitab at cs.berkeley.edu (Nikita Borisov) Date: Wed, 26 Jan 2005 08:36:16 -0800 Subject: [OTR-dev] Secure connections through a connect/disconnect cycle, OTR error messages In-Reply-To: References: Message-ID: <662FD7CC-6FB8-11D9-99A5-000A95873CEC@cs.berkeley.edu> On Jan 25, 2005, at 9:26 PM, Evan Schoenberg wrote: > > 1) > - My friend and I are chatting via OTR > - I disconnect. I reconnect (same application session). We can > continue chatting as before. > - I disconnect and quit. > - I relaunch the application and connect. I open a message window to > my friend and send him a normal (unencrypted) message, not realizing > he has remained connected and not hit stopped the OTR session. > - I receive: ?OTR Error: You sent unencrypted data to , who was > expecting encrypted messages from you. > > Question: Should a client disconnect all OTR sessions on an account > when that account disconnects? And from my friend's perspective, > should a client disconnect an OTR session when the target contact > disconnects? On reason you might not want to kill the session is if the reason you disconnected was that your network connection temporarily went down. You and your friend might want to keep the same OTR session around once the connection comes back up. - Nikita From gdt at ir.bbn.com Wed Jan 26 12:52:15 2005 From: gdt at ir.bbn.com (Greg Troxel) Date: 26 Jan 2005 12:52:15 -0500 Subject: [OTR-dev] Secure connections through a connect/disconnect cycle, OTR error messages In-Reply-To: <20050126150732.GW1060@smtp.paip.net> References: <20050126150732.GW1060@smtp.paip.net> Message-ID: Fine, but that confuses two things: not wanting to send data in cleartext, unless user is really clear that this is happening (agree 100%) Knowing that the current OTR context you have with the other party (probably) won't work any more. I find that the current behavior doesn't meet either goal. I'd like to see an OTR handshake start if the other party has a fingerprint on record as soon as I start typing, and perhaps require some explicit action to enable sending cleartext. Perhaps this is per-correspondent state of 'require encryption'. An OTR crypto context that is old (15 minutes?) should be pinged before use; this would solve some of the "other person has restarted gaim but I don't know that" problems. If you define a ping that will be answered as a data message, and inject an "OTR ping" into the chat window, that would figure out mismatches and rekey around them before we get to data. It's kind of like a soft rekey, except you won't cause a rekey popup if it isn't needed. -- Greg Troxel From mid at zigamorph.net Wed Jan 26 14:15:58 2005 From: mid at zigamorph.net (Adam Fritzler) Date: Wed, 26 Jan 2005 11:15:58 -0800 Subject: [OTR-dev] proposed API change In-Reply-To: References: <20050126032617.GC14936@zigamorph.net> Message-ID: <20050126191558.GC27798@zigamorph.net> On Wed, Jan 26, 2005 at 09:01:31AM +0100, Paul Wouters wrote: > You know about otrproxy? I'm aware. What I'm working on is a larger, generic system; I'm only doing OTR because I can. :) It also takes a different approach than otrproxy. Instead of looking to the client like an explicit proxy (HTTP, SOCKS, etc), it looks like a server of the respective IM system, and transparently interfaces with the real system on behalf of the client. You can then simply spoof DNS to redirect the client through the proxy -- though most clients have an option somewhere to just change where they look for their server (as a preference, registry entry, etc). asf. From mid at zigamorph.net Wed Jan 26 14:48:16 2005 From: mid at zigamorph.net (Adam Fritzler) Date: Wed, 26 Jan 2005 11:48:16 -0800 Subject: [OTR-dev] proposed API change In-Reply-To: <20050126145954.GV1060@smtp.paip.net> References: <20050126032617.GC14936@zigamorph.net> <20050126145954.GV1060@smtp.paip.net> Message-ID: <20050126194816.GD27798@zigamorph.net> Another thing I was wondering: I think it'd be cleaner if the detection-of-OTR-ability was outside the scope of the OTR protocol. Which is to say, the library shouldn't add the whitespace tag to messages. Some IM systems offer better ways of advertising capabilities. I realize it's helpful for standardization if the library attaches the tag, but at the same time, I think it'd be better done in the client code. asf. From evan.s at dreskin.net Wed Jan 26 15:33:25 2005 From: evan.s at dreskin.net (Evan Schoenberg) Date: Wed, 26 Jan 2005 14:33:25 -0600 Subject: [OTR-dev] proposed API change In-Reply-To: <20050126194816.GD27798@zigamorph.net> References: <20050126032617.GC14936@zigamorph.net> <20050126145954.GV1060@smtp.paip.net> <20050126194816.GD27798@zigamorph.net> Message-ID: <87698128-6FD9-11D9-868D-000A95685E80@dreskin.net> Similarly, error messages shouldn't have the OTR tag prepended... a client should be able to display OTR messages how it wants. This goes hand in hand with needing error messages submitted to the client in a unique way rather than as received messages (as discussed in the Displaying OTR Errors (was: Re: Hmmm...) thread) Possibilities, as an example: - Prepend an OTR message (without the ugly question mark) - Display it in a special window - Tag encryption-related messages within the chat window in a special way (color, emblem, etc.) - Make loud noises and make the computer blow up -Evan On Jan 26, 2005, at 1:48 PM, Adam Fritzler wrote: > > Another thing I was wondering: I think it'd be cleaner if the > detection-of-OTR-ability was outside the scope of the OTR protocol. > Which is to say, the library shouldn't add the whitespace tag to > messages. Some IM systems offer better ways of advertising > capabilities. I realize it's helpful for standardization if the > library > attaches the tag, but at the same time, I think it'd be better done in > the client code. > > asf. > > _______________________________________________ > OTR-dev mailing list > OTR-dev at lists.cypherpunks.ca > http://lists.cypherpunks.ca/mailman/listinfo/otr-dev > From verbal at gmail.com Wed Jan 26 15:45:57 2005 From: verbal at gmail.com (verbal) Date: Wed, 26 Jan 2005 12:45:57 -0800 Subject: [OTR-dev] OTR encryption state In-Reply-To: References: Message-ID: > To solve your 'problem', one could add a new bit in the > per-correspondent UI that says "OTR desired", and have the > auto-negotiate behavior be conditional on that being on. > i dont know if we should have an OTR desired mode on/off switch or to just pick one. my main concern about this UI issue is that if a user specifically turns OTR off via UI, i dont see why their chat client should force them back into it. i agree with the fact that it should try to auto-negotiate at the beginning conversation, but once that's established, if either party wanted to continue the conversation in plaintext, i think they should have a right to do so. verbal From verbal at gmail.com Wed Jan 26 15:52:48 2005 From: verbal at gmail.com (verbal) Date: Wed, 26 Jan 2005 12:52:48 -0800 Subject: [OTR-dev] Secure connections through a connect/disconnect cycle, OTR error messages In-Reply-To: <20050126150732.GW1060@smtp.paip.net> References: <20050126150732.GW1060@smtp.paip.net> Message-ID: > > 2) > > - My friend decides to cancel the OTR session without telling me. > > - I send a message > > - I receive: ?OTR Error: You sent encrypted data to , who wasn't > > expecting it. > > > > Question: Is there a way in which the protocol could be expended to > > send some sort of otr-specific message to the other side letting it > > know that one person has asked to end the session? > > No, and that's quite on purpose. There should be NO WAY a network > message can cause a session to transition from private to not private. > If there were, you'd have to be really, really careful about whether > that message is authentic / replayed / etc. There's also the problem > of: 1. user (in secure conversation) starts typing private message, > 2. other side ends the session, sending "session ended" packet to user > 3. User hits Enter to send his message in the (now unencrypted) session. i agree with the fact that there should be no way alice can force bob out of a secure session, but i think what evan is saying is just to.. give bob a heads up so bob's client can make some gui niceness? while i feel that it is possible to do force bob to exit encrypted mode securely (encryption/nonce, whatever), it is not something we need to do and therefore should not add that point of failure into the protocol. anywho, UI wise, maybe its good enough to simply infer that alice has stopped encrypting her messages from the lack of ?OTR messages bob receives? verbal From evan.s at dreskin.net Wed Jan 26 15:57:12 2005 From: evan.s at dreskin.net (Evan Schoenberg) Date: Wed, 26 Jan 2005 14:57:12 -0600 Subject: [OTR-dev] Secure connections through a connect/disconnect cycle, OTR error messages In-Reply-To: References: <20050126150732.GW1060@smtp.paip.net> Message-ID: I think the lack of ?OTR messages is insufficient... that doesn't do anything until bob sends a message and that message fails... Part of the purpose of such a 'heads up' is that bob can react without us having to wait for a message send to fail before any one is the wiser. -Evan On Jan 26, 2005, at 2:52 PM, verbal wrote: > anywho, UI wise, maybe its good enough to simply infer that alice has > stopped encrypting her messages from the lack of ?OTR messages bob > receives? From gdt at ir.bbn.com Wed Jan 26 16:07:40 2005 From: gdt at ir.bbn.com (Greg Troxel) Date: Wed, 26 Jan 2005 16:07:40 -0500 Subject: [OTR-dev] OTR encryption state In-Reply-To: Message from verbal of "Wed, 26 Jan 2005 12:45:57 PST." Message-ID: <20050126210740.DF8961F68@fnord.ir.bbn.com> I think we need three modes (global, and then per-correspondent, defaultig to 'try' for all): don't do otr try to do otr refuse to send messages unless otr is set up From verbal at gmail.com Wed Jan 26 16:21:15 2005 From: verbal at gmail.com (verbal) Date: Wed, 26 Jan 2005 13:21:15 -0800 Subject: [OTR-dev] OTR encryption state In-Reply-To: <20050126210740.DF8961F68@fnord.ir.bbn.com> References: <20050126210740.DF8961F68@fnord.ir.bbn.com> Message-ID: that sounds reasonable. we should identify the most common usage scenario and set that as the default. also, i would like to change the first one and reword the third one. 1) manual OTR messaging 2) OTR whenever possible messaging. 3) OTR only messaging. so while my first mode and yours is different, with the three combined, they will have the same functionality. i think the difference between our wording for mode 1 will just end up being UI semantics. maybe we should get some UI people to weigh in on this. verbal On Wed, 26 Jan 2005 16:07:40 -0500, Greg Troxel wrote: > I think we need three modes (global, and then per-correspondent, > defaultig to 'try' for all): > > don't do otr > try to do otr > refuse to send messages unless otr is set up > From gdt at ir.bbn.com Wed Jan 26 16:25:13 2005 From: gdt at ir.bbn.com (Greg Troxel) Date: Wed, 26 Jan 2005 16:25:13 -0500 Subject: [OTR-dev] OTR encryption state In-Reply-To: Message from verbal of "Wed, 26 Jan 2005 13:21:15 PST." Message-ID: <20050126212513.426CE1F58@fnord.ir.bbn.com> 1) manual OTR messaging What i meant here is: never try to do KEX never send otr-encrypted messages perhaps don't send the whitespace tag So it's not manual, it's "don't". But, arguably hitting 'do KEX' is a command to change modes. OTOH, arguably the otr strat button should be grayed out if "don't" is selected. I would expect people to select "don't" only if that's what they really mean. 2) OTR whenever possible messaging. 3) OTR only messaging. From verbal at gmail.com Wed Jan 26 16:25:17 2005 From: verbal at gmail.com (verbal) Date: Wed, 26 Jan 2005 13:25:17 -0800 Subject: [OTR-dev] Secure connections through a connect/disconnect cycle, OTR error messages In-Reply-To: References: <20050126150732.GW1060@smtp.paip.net> Message-ID: On Wed, 26 Jan 2005 14:57:12 -0600, Evan Schoenberg wrote: > I think the lack of ?OTR messages is insufficient... that doesn't do > anything until bob sends a message and that message fails... Part of > the purpose of such a 'heads up' is that bob can react without us > having to wait for a message send to fail before any one is the wiser. > what do you mean by letting bob "react", ie what would bob do? if alice and bob are in an OTR conversation and alice turns it off. alice sends in plaintext to bob, which is ok because alice knows she is sending plaintext cause she set it while bob is sending in encrypted text which is ok because he still thinks they're encrypted. so i think security (grr i hate using that word) wise, everything is ok. the problem will be that bob wont know until an error comes back or whatever. so from the UI standpoint, it kind of sucks. so i propose a "heads up" message that the bob can choose to ignore, but it will show bob via UI that alice has ended the encrypted session and if bob wanted to, he could/should end the encrypted session also so alice can see his messages. verbal From evan.s at dreskin.net Wed Jan 26 16:31:16 2005 From: evan.s at dreskin.net (Evan Schoenberg) Date: Wed, 26 Jan 2005 15:31:16 -0600 Subject: [OTR-dev] Secure connections through a connect/disconnect cycle, OTR error messages In-Reply-To: References: <20050126150732.GW1060@smtp.paip.net> Message-ID: <9C4C8A12-6FE1-11D9-868D-000A95685E80@dreskin.net> verbal, right. we're saying the same thing :) On Jan 26, 2005, at 3:25 PM, verbal wrote: > On Wed, 26 Jan 2005 14:57:12 -0600, Evan Schoenberg > wrote: >> I think the lack of ?OTR messages is insufficient... that doesn't do >> anything until bob sends a message and that message fails... Part of >> the purpose of such a 'heads up' is that bob can react without us >> having to wait for a message send to fail before any one is the wiser. >> > > what do you mean by letting bob "react", ie what would bob do? if > alice and bob are in an OTR conversation and alice turns it off. alice > sends in plaintext to bob, which is ok because alice knows she is > sending plaintext cause she set it while bob is sending in encrypted > text which is ok because he still thinks they're encrypted. > > so i think security (grr i hate using that word) wise, everything is > ok. the problem will be that bob wont know until an error comes back > or whatever. so from the UI standpoint, it kind of sucks. > > so i propose a "heads up" message that the bob can choose to ignore, > but it will show bob via UI that alice has ended the encrypted session > and if bob wanted to, he could/should end the encrypted session also > so alice can see his messages. > > verbal > _______________________________________________ > OTR-dev mailing list > OTR-dev at lists.cypherpunks.ca > http://lists.cypherpunks.ca/mailman/listinfo/otr-dev > From verbal at gmail.com Wed Jan 26 16:47:49 2005 From: verbal at gmail.com (verbal) Date: Wed, 26 Jan 2005 13:47:49 -0800 Subject: [OTR-dev] OTR encryption state In-Reply-To: <20050126212513.426CE1F58@fnord.ir.bbn.com> References: <20050126212513.426CE1F58@fnord.ir.bbn.com> Message-ID: aye, so with what you're saying, you would be in mode 1 for unencrypted, mode 2 for encrypted if possible, and mode 3 is encrypted only. with what i'm proposing, you would be in mode 1 for manual control of encrypted or not, mode 2 for encrypted if possible, and mode 3 for encrypted only. i dont know what's best. i could really go either way. verbal On Wed, 26 Jan 2005 16:25:13 -0500, Greg Troxel wrote: > 1) manual OTR messaging > > What i meant here is: > never try to do KEX > never send otr-encrypted messages > perhaps don't send the whitespace tag > > So it's not manual, it's "don't". But, arguably hitting 'do KEX' is a > command to change modes. OTOH, arguably the otr strat button should > be grayed out if "don't" is selected. I would expect people to > select "don't" only if that's what they really mean. > > 2) OTR whenever possible messaging. > 3) OTR only messaging. > From verbal at gmail.com Wed Jan 26 16:48:51 2005 From: verbal at gmail.com (verbal) Date: Wed, 26 Jan 2005 13:48:51 -0800 Subject: [OTR-dev] Secure connections through a connect/disconnect cycle, OTR error messages In-Reply-To: <9C4C8A12-6FE1-11D9-868D-000A95685E80@dreskin.net> References: <20050126150732.GW1060@smtp.paip.net> <9C4C8A12-6FE1-11D9-868D-000A95685E80@dreskin.net> Message-ID: hah ok, just making sure =P. On Wed, 26 Jan 2005 15:31:16 -0600, Evan Schoenberg wrote: > verbal, > > right. we're saying the same thing :) > > On Jan 26, 2005, at 3:25 PM, verbal wrote: > > > On Wed, 26 Jan 2005 14:57:12 -0600, Evan Schoenberg > > wrote: > >> I think the lack of ?OTR messages is insufficient... that doesn't do > >> anything until bob sends a message and that message fails... Part of > >> the purpose of such a 'heads up' is that bob can react without us > >> having to wait for a message send to fail before any one is the wiser. > >> > > > > what do you mean by letting bob "react", ie what would bob do? if > > alice and bob are in an OTR conversation and alice turns it off. alice > > sends in plaintext to bob, which is ok because alice knows she is > > sending plaintext cause she set it while bob is sending in encrypted > > text which is ok because he still thinks they're encrypted. > > > > so i think security (grr i hate using that word) wise, everything is > > ok. the problem will be that bob wont know until an error comes back > > or whatever. so from the UI standpoint, it kind of sucks. > > > > so i propose a "heads up" message that the bob can choose to ignore, > > but it will show bob via UI that alice has ended the encrypted session > > and if bob wanted to, he could/should end the encrypted session also > > so alice can see his messages. > > > > verbal > > _______________________________________________ > > OTR-dev mailing list > > OTR-dev at lists.cypherpunks.ca > > http://lists.cypherpunks.ca/mailman/listinfo/otr-dev > > > > From gdt at ir.bbn.com Wed Jan 26 17:42:08 2005 From: gdt at ir.bbn.com (Greg Troxel) Date: Wed, 26 Jan 2005 17:42:08 -0500 Subject: [OTR-dev] OTR encryption state In-Reply-To: Message from verbal of "Wed, 26 Jan 2005 13:47:49 PST." Message-ID: <20050126224208.233411F58@fnord.ir.bbn.com> with what i'm proposing, you would be in mode 1 for manual control of encrypted or not, mode 2 for encrypted if possible, and mode 3 for encrypted only. The real question is the user's needs. Forcing encrypted only is something I would find useful. I find sometimes that OTR causes problems, due to poor interaction with gaim and multiple jabber resources. I would imagine that the 'try otr' mode would be a good default, and that you'd want to set 'otr only' mode for people that you know are always otr capable, so you don't slip on the first message. I'd only set 'no otr' when I was having trouble with otr, so wouldn't mind if it was a trip to prefs/plugins/otr to change. From verbal at gmail.com Wed Jan 26 17:59:35 2005 From: verbal at gmail.com (verbal) Date: Wed, 26 Jan 2005 14:59:35 -0800 Subject: [OTR-dev] OTR encryption state In-Reply-To: <20050126224208.233411F58@fnord.ir.bbn.com> References: <20050126224208.233411F58@fnord.ir.bbn.com> Message-ID: so i guess this is how i would use it. mode 1: people who i know do not use OTR mode 2: people who IM from different machines/clients that sometimes have it mode 3: people who i know have OTR all the time whatever we decide, the important thing is to have the modes consistent across all clients. verbal On Wed, 26 Jan 2005 17:42:08 -0500, Greg Troxel wrote: > with what i'm proposing, you would be in mode 1 for manual control of > encrypted or not, mode 2 for encrypted if possible, and mode 3 for > encrypted only. > > The real question is the user's needs. Forcing encrypted only is > something I would find useful. I find sometimes that OTR causes > problems, due to poor interaction with gaim and multiple jabber > resources. I would imagine that the 'try otr' mode would be a good > default, and that you'd want to set 'otr only' mode for people that > you know are always otr capable, so you don't slip on the first > message. I'd only set 'no otr' when I was having trouble with otr, so > wouldn't mind if it was a trip to prefs/plugins/otr to change. > > From gdt at ir.bbn.com Wed Jan 26 18:09:46 2005 From: gdt at ir.bbn.com (Greg Troxel) Date: Wed, 26 Jan 2005 18:09:46 -0500 Subject: [OTR-dev] OTR encryption state In-Reply-To: Message from verbal of "Wed, 26 Jan 2005 14:59:35 PST." Message-ID: <20050126230946.6E2F01F58@fnord.ir.bbn.com> mode 1: people who i know do not use OTR I would only set this when I was having trouble. I suppose this setting would omit the whitespace auto-start tag. Thus, I'd only set it if trouble, becaues if someone upgraded their client, I'd want to start otring. mode 2: people who IM from different machines/clients that sometimes have it I would set this (current behavior) for almost everyone mode 3: people who i know have OTR all the time I would set this if I knew that, and wanted to have communications fail rather than risk cleartext. From evan.s at dreskin.net Wed Jan 26 18:42:51 2005 From: evan.s at dreskin.net (Evan Schoenberg) Date: Wed, 26 Jan 2005 17:42:51 -0600 Subject: [OTR-dev] OTR encryption state In-Reply-To: <20050126230946.6E2F01F58@fnord.ir.bbn.com> References: <20050126230946.6E2F01F58@fnord.ir.bbn.com> Message-ID: I may be misunderstanding, but these proposed 'modes' don't seem to address the original issue verbal posted. No matter who I am talking to, if I stop encryption while in an OTR chat, it should not turn itself back on. This isn't a per-contact thing... Meanwhile, the question of "people who don't use OTR" versus "people who may use OTR" versus "people with whom I always use OTR" is a simple per-contact preference, implemented at the level of the client, not the protocol or library... "Automatically attempt to connect via OTR." If yes, then opening a chat will attempt to connect. If no, it won't. For "mode 2" you don't check the box, then you manually connect as desired. -Evan On Jan 26, 2005, at 5:09 PM, Greg Troxel wrote: > mode 1: people who i know do not use OTR > > I would only set this when I was having trouble. I suppose this > setting would omit the whitespace auto-start tag. Thus, I'd only set > it if trouble, becaues if someone upgraded their client, I'd want to > start otring. > > mode 2: people who IM from different machines/clients that sometimes > have it > > I would set this (current behavior) for almost everyone > > mode 3: people who i know have OTR all the time > > I would set this if I knew that, and wanted to have communications > fail rather than risk cleartext. > > _______________________________________________ > OTR-dev mailing list > OTR-dev at lists.cypherpunks.ca > http://lists.cypherpunks.ca/mailman/listinfo/otr-dev > From gdt at ir.bbn.com Wed Jan 26 18:51:07 2005 From: gdt at ir.bbn.com (Greg Troxel) Date: Wed, 26 Jan 2005 18:51:07 -0500 Subject: [OTR-dev] OTR encryption state In-Reply-To: Message from Evan Schoenberg of "Wed, 26 Jan 2005 17:42:51 CST." Message-ID: <20050126235107.CED931F64@fnord.ir.bbn.com> No matter who I am talking to, if I stop encryption while in an OTR chat, it should not turn itself back on. This isn't a per-contact thing... We are addressing this, but I think see it differently. If I'm running IKE, and manually nuke an SA, I expect IKE to regenerate it. So I'm distinguishing between "discard this SA" and "stop doing OTR". Yes, these are UI things, so I'm thinking about gaim-otr. Doing this cleanly might impose some requirements on the library, but I don't have any reason to think that yet. From verbal at gmail.com Wed Jan 26 18:56:15 2005 From: verbal at gmail.com (verbal) Date: Wed, 26 Jan 2005 15:56:15 -0800 Subject: [OTR-dev] OTR encryption state In-Reply-To: References: <20050126230946.6E2F01F58@fnord.ir.bbn.com> Message-ID: > No matter who I am talking to, if I stop encryption while in an OTR > chat, it should not turn itself back on. This isn't a per-contact > thing... > yes, you're right. while we see it as a problem, i think greg is saying that this functionality should be "emulated" by having the user set the different modes of operation. so if i wanted to turn encryption off, i would just goto mode 1. that's the way i see it anyways. verbal From evan.s at dreskin.net Wed Jan 26 18:56:11 2005 From: evan.s at dreskin.net (Evan Schoenberg) Date: Wed, 26 Jan 2005 17:56:11 -0600 Subject: [OTR-dev] OTR encryption state In-Reply-To: <20050126235107.CED931F64@fnord.ir.bbn.com> References: <20050126235107.CED931F64@fnord.ir.bbn.com> Message-ID: Apologies, but I'm new to encryption. What are IKE and SA? On Jan 26, 2005, at 5:51 PM, Greg Troxel wrote: > No matter who I am talking to, if I stop encryption while in an OTR > chat, it should not turn itself back on. This isn't a per-contact > thing... > > We are addressing this, but I think see it differently. If I'm > running IKE, and manually nuke an SA, I expect IKE to regenerate it. > So I'm distinguishing between "discard this SA" and "stop doing OTR". > > Yes, these are UI things, so I'm thinking about gaim-otr. Doing > this cleanly might impose some requirements on the library, but I > don't have any reason to think that yet. > From evan.s at dreskin.net Wed Jan 26 19:07:33 2005 From: evan.s at dreskin.net (Evan Schoenberg) Date: Wed, 26 Jan 2005 18:07:33 -0600 Subject: [OTR-dev] OTR encryption state In-Reply-To: References: <20050126230946.6E2F01F58@fnord.ir.bbn.com> Message-ID: <71600CD6-6FF7-11D9-868D-000A95685E80@dreskin.net> Implementing these modes requires more changes, and it sounds like more library-level changes, than just making it not automatically re-negotiate (the automatic re-negotiation could even occur iff a callback to the libotr's UI returns YES, so the behavior could be customized [or not] as desired)... "emulating" a fix to a problem instead of just fixing it isn't a good idea in my opinion, and fixing it would provide a more intuitive user experience and less complex user interface. -Evan On Jan 26, 2005, at 5:56 PM, verbal wrote: >> No matter who I am talking to, if I stop encryption while in an OTR >> chat, it should not turn itself back on. This isn't a per-contact >> thing... >> > > yes, you're right. while we see it as a problem, i think greg is > saying that this functionality should be "emulated" by having the user > set the different modes of operation. so if i wanted to turn > encryption off, i would just goto mode 1. that's the way i see it > anyways. > > verbal > From verbal at gmail.com Wed Jan 26 19:23:46 2005 From: verbal at gmail.com (verbal) Date: Wed, 26 Jan 2005 16:23:46 -0800 Subject: [OTR-dev] OTR encryption state In-Reply-To: <71600CD6-6FF7-11D9-868D-000A95685E80@dreskin.net> References: <20050126230946.6E2F01F58@fnord.ir.bbn.com> <71600CD6-6FF7-11D9-868D-000A95685E80@dreskin.net> Message-ID: i totally agree with that, but it may be worth the work. i'm not sure. it depends on what people think will be best for the user. someone else weigh the cost/benefit ratio here between code complexity/portability vs UI enchancement. =) verbal On Wed, 26 Jan 2005 18:07:33 -0600, Evan Schoenberg wrote: > Implementing these modes requires more changes, and it sounds like more > library-level changes, than just making it not automatically > re-negotiate (the automatic re-negotiation could even occur iff a > callback to the libotr's UI returns YES, so the behavior could be > customized [or not] as desired)... "emulating" a fix to a problem > instead of just fixing it isn't a good idea in my opinion, and fixing > it would provide a more intuitive user experience and less complex user > interface. > > -Evan > > On Jan 26, 2005, at 5:56 PM, verbal wrote: > > >> No matter who I am talking to, if I stop encryption while in an OTR > >> chat, it should not turn itself back on. This isn't a per-contact > >> thing... > >> > > > > yes, you're right. while we see it as a problem, i think greg is > > saying that this functionality should be "emulated" by having the user > > set the different modes of operation. so if i wanted to turn > > encryption off, i would just goto mode 1. that's the way i see it > > anyways. > > > > verbal > > > > From gdt at ir.bbn.com Wed Jan 26 19:24:25 2005 From: gdt at ir.bbn.com (Greg Troxel) Date: Wed, 26 Jan 2005 19:24:25 -0500 Subject: [OTR-dev] OTR encryption state In-Reply-To: Message from verbal of "Wed, 26 Jan 2005 15:56:15 PST." Message-ID: <20050127002425.1DCD71F5C@fnord.ir.bbn.com> yes, you're right. while we see it as a problem, i think greg is saying that this functionality should be "emulated" by having the user set the different modes of operation. so if i wanted to turn encryption off, i would just goto mode 1. that's the way i see it anyways. I'm making a distinction between "delete current crypto context" and "delete current context and go into a mode where you won't try to negotiate a new one" To answer Evan, IKE : Internet Key Exchange, RFC2409, part of IPsec, RFC2401 At its core DH with authentiation and algorithm negotiation, but fairly complex. SA: security association - a combination of the remote parties ID, key, cipher type, sequence number, etc. With IPsec you have a 'security policy database' (SPD) that says what traffic needs what protection. On BSD, the kernel sends an ACQUIRE message to a key management daemon; the daemon then negotiates an SA and installs it in the kernel, where it can be used by subsequent packets. On BSD, IKE is implemented by racoon. Perhaps on Linux also; there have been several implementations. Sometimes racoon gets in a state where it won't try to get new SAs, typically after the network has been gone for a while. I don't want to stop doing IPsec in those cases - my policy says "this port needs IPsec, period". So I restart racoon, which deletes all the SAs and then tries to negotiate on the next packet because it gets an ACQUIRE. That's the sense of 'nuke this context' that I'm talking about. The other action would be "change the SPD so that crypt is no longer required". From gdt at ir.bbn.com Wed Jan 26 19:26:03 2005 From: gdt at ir.bbn.com (Greg Troxel) Date: Wed, 26 Jan 2005 19:26:03 -0500 Subject: [OTR-dev] OTR encryption state In-Reply-To: Message from verbal of "Wed, 26 Jan 2005 16:23:46 PST." Message-ID: <20050127002604.0081F1F5C@fnord.ir.bbn.com> i totally agree with that, but it may be worth the work. i'm not sure. it depends on what people think will be best for the user. someone else weigh the cost/benefit ratio here between code complexity/portability vs UI enchancement. =) I consider it a serious bug that I can't check a box in otr prefs to say "don't try to do otr with this person for now". Right now I have to delete the fingerprint to get that effect, and that opens me up to reverification issues. From evan.s at dreskin.net Wed Jan 26 19:48:57 2005 From: evan.s at dreskin.net (Evan Schoenberg) Date: Wed, 26 Jan 2005 18:48:57 -0600 Subject: [OTR-dev] OTR encryption state In-Reply-To: <20050127002604.0081F1F5C@fnord.ir.bbn.com> References: <20050127002604.0081F1F5C@fnord.ir.bbn.com> Message-ID: <39D22713-6FFD-11D9-868D-000A95685E80@dreskin.net> On Jan 26, 2005, at 6:26 PM, Greg Troxel wrote: > I consider it a serious bug that I can't check a box in otr prefs to > say "don't try to do otr with this person for now". Right now I have > to delete the fingerprint to get that effect, and that opens me up to > reverification issues. *nod* You're right, then, when you said previously that we were addressing the same issue in different ways. Removing autorenogiation solves this, as you stop the OTR session and OTR won't begin again with that contact until you ask it to. Unfortunately, now that it's put that way, it becomes clear that -this- opens up a problem with initial OTR sessions... there's no way to distinguish: a) a conversation I ended (i.e. we were talking, i told it to stop, and therefore we should not be automatically reconnected) from b) an initial conversation with someone with whom I have a confirmed fingerprint and therefore should automatically be connected to > To answer Evan, Thanks for the explanations. > So I restart racoon, > which deletes all the SAs and then tries to negotiate on the next > packet because it gets an ACQUIRE. > That's the sense of 'nuke this context' that I'm talking about. > > The other action would be "change the SPD so that crypt is no longer > required". > I see. Do the session IDs change in the state situation we've been discussing, that is if I hit 'cancel' and then you message me twice (once and receive the error message, at which point we autorenegotiate and have a secure sesion, and then a second time which is an encrypted message which goes through succesfully)? -Evan From ian at cypherpunks.ca Wed Jan 26 21:39:01 2005 From: ian at cypherpunks.ca (Ian Goldberg) Date: Wed, 26 Jan 2005 21:39:01 -0500 Subject: [OTR-dev] Displaying OTR errors (was Re: Hmmm.) In-Reply-To: References: <20050125230244.GT1060@smtp.paip.net> <20050126152953.GX1060@smtp.paip.net> Message-ID: <20050127023901.GZ1060@smtp.paip.net> On Wed, Jan 26, 2005 at 10:23:45AM -0600, Evan Schoenberg wrote: > Sorry, I was not sufficiently specific. I didn't mean that all > errors are sent via inject_message, just that there are some which are > and should not be. > > 9:30:30 : ?OTR Error: You sent unencrypted data to buddy's name>, who was expecting encrypted messages from you. > > 10:23:21 : ?OTR Error: You sent encrypted data to buddy's name>, who wasn't expecting it. > > 10:45:21 : The encrypted message received from buddy's name> is unreadable, as you are not currently communicating > privately. > > 10:46:10 : The following message received from buddy's name> was not encrypted: [ok, I canceled encryption > > Those are four error conditions which are displayed as incoming > messages. The first and second are definitely errors, but they are > presented as simple text received from the other person. The first two *are* simple text received from the other person. _His_ OTR-enabled client is the one that recognized that you sent him unencrypted data (when he was expecting encrypted data), and sent you back the plain old IM message "?OTR Error: You sent unencrypted data to , who was expecting encrypted messages from you." > The third I > believe should be presented as an error, not a message, as it does not > contain message text. That's the one we changed from a popup to an inlined message early on, as it was annoying people. But I agree that it more "correctly" should be out-of-band. - Ian From evan.s at dreskin.net Wed Jan 26 23:33:34 2005 From: evan.s at dreskin.net (Evan Schoenberg) Date: Wed, 26 Jan 2005 22:33:34 -0600 Subject: [OTR-dev] Displaying OTR errors (was Re: Hmmm.) In-Reply-To: <20050127023901.GZ1060@smtp.paip.net> References: <20050125230244.GT1060@smtp.paip.net> <20050126152953.GX1060@smtp.paip.net> <20050127023901.GZ1060@smtp.paip.net> Message-ID: <9ABC7C12-701C-11D9-868D-000A95685E80@dreskin.net> On Jan 26, 2005, at 8:39 PM, Ian Goldberg wrote: > The first two *are* simple text received from the other person. _His_ > OTR-enabled client is the one that recognized that you sent him > unencrypted data (when he was expecting encrypted data), and sent you > back the plain old IM message "?OTR Error: You sent unencrypted data to > , who was expecting encrypted messages from you." > Ah. It becomes clear. Thanks. >> The third I >> believe should be presented as an error, not a message, as it does not >> contain message text. > > That's the one we changed from a popup to an inlined message early on, > as it was annoying people. But I agree that it more "correctly" should > be out-of-band. > Hm, so there's still a case for being able to pass back a conversation-associated error message, then? > - Ian > _______________________________________________ > OTR-dev mailing list > OTR-dev at lists.cypherpunks.ca > http://lists.cypherpunks.ca/mailman/listinfo/otr-dev > From ian at cypherpunks.ca Thu Jan 27 07:03:02 2005 From: ian at cypherpunks.ca (Ian Goldberg) Date: Thu, 27 Jan 2005 07:03:02 -0500 Subject: [OTR-dev] Secure connections through a connect/disconnect cycle, OTR error messages In-Reply-To: References: <20050126150732.GW1060@smtp.paip.net> Message-ID: <20050127120302.GB1060@smtp.paip.net> On Wed, Jan 26, 2005 at 01:25:17PM -0800, verbal wrote: > On Wed, 26 Jan 2005 14:57:12 -0600, Evan Schoenberg wrote: > > I think the lack of ?OTR messages is insufficient... that doesn't do > > anything until bob sends a message and that message fails... Part of > > the purpose of such a 'heads up' is that bob can react without us > > having to wait for a message send to fail before any one is the wiser. > > > > what do you mean by letting bob "react", ie what would bob do? if > alice and bob are in an OTR conversation and alice turns it off. alice > sends in plaintext to bob, which is ok because alice knows she is > sending plaintext cause she set it while bob is sending in encrypted > text which is ok because he still thinks they're encrypted. Don't forget to take into account the case where Alice and Bob are in a secure conversation, but Eve sends a message to Bob (pretending to be Alice), trying to convince Bob to turn off OTR. That could either be the above plaintext, or the "heads-up" message, or whatever. It's *vital* that Bob _not_ turn off OTR in response to anything except Alice (_in_ an OTR conversation) saying "OK, I'm turning off OTR now.". [But this method does work OK.] - Ian From ian at cypherpunks.ca Thu Jan 27 09:36:20 2005 From: ian at cypherpunks.ca (Ian Goldberg) Date: Thu, 27 Jan 2005 09:36:20 -0500 Subject: [OTR-dev] OTR encryption state In-Reply-To: References: <20050126210740.DF8961F68@fnord.ir.bbn.com> Message-ID: <20050127143620.GC1060@smtp.paip.net> [Side note: libotr now can have separate UserStates (instead of the static context_root and privkey_root). It also will reencrypt and retransmit the last message it sent encrypted (if it's very recent) in the event that the other guy lost his OTR state. (Paul's been requesting that since the dawn of time.)] On Wed, Jan 26, 2005 at 01:21:15PM -0800, verbal wrote: > that sounds reasonable. we should identify the most common usage > scenario and set that as the default. also, i would like to change the > first one and reword the third one. > > 1) manual OTR messaging > 2) OTR whenever possible messaging. > 3) OTR only messaging. > > so while my first mode and yours is different, with the three > combined, they will have the same functionality. i think the > difference between our wording for mode 1 will just end up being UI > semantics. maybe we should get some UI people to weigh in on this. Implementation-wise, what do you think of adding a callback that looks something like: OtrlMessagePolicy determine_policy(userstate, accountname, protocol, username, context); which returns information about what OTR features should and should not be enabled for this context? NEVER: Pretend OTR isn't enabled at all for this user ALWAYS: It is an error to send unencrypted data to this user. If you try, you'll get a notify(ERROR) callback and the message to be sent will be turned into an OTR Error message that the other side will see. OPPORTUNISTIC: (the current mode) probe the other side with the whitespace tag, and reply to any indication that he speaks OTR with a Key Exchange Message (if we're not already private) MANUAL: Don't send the whitespace tag, and don't reply to one you receive. Respond to explicit OTR Query Messages and Key Exchange Messages, but not other indications of OTR. This mode is useful if you for some reason want to communicate in the clear, even though you know the other guy speaks OTR, and also allow either side to start a private conversation at any time. [If you don't want to allow that last condition, use NEVER instead.] - Ian From gdt at ir.bbn.com Thu Jan 27 10:27:47 2005 From: gdt at ir.bbn.com (Greg Troxel) Date: Thu, 27 Jan 2005 10:27:47 -0500 Subject: [OTR-dev] OTR encryption state In-Reply-To: Message from Evan Schoenberg of "Wed, 26 Jan 2005 18:48:57 CST." <39D22713-6FFD-11D9-868D-000A95685E80@dreskin.net> Message-ID: <20050127152747.D44E01F5C@fnord.ir.bbn.com> > Removing autorenogiation > solves this, as you stop the OTR session and OTR won't begin again with > that contact until you ask it to. Unfortunately, now that it's put > that way, it becomes clear that -this- opens up a problem with initial > OTR sessions... there's no way to distinguish: > a) a conversation I ended (i.e. we were talking, i told it to stop, and > therefore we should not be automatically reconnected) from > b) an initial conversation with someone with whom I have a confirmed > fingerprint and therefore should automatically be connected to Exactly - the ambiguity between 'discard context' and 'don't try again'. I don't see why 'discard context' shouldn't send an authenticated message to the other side saying that, similar to an IKE Delete notify message. > > So I restart racoon, > > which deletes all the SAs and then tries to negotiate on the next > > packet because it gets an ACQUIRE. > > That's the sense of 'nuke this context' that I'm talking about. > > > > The other action would be "change the SPD so that crypt is no longer > > required". > > > I see. Do the session IDs change in the state situation we've been > discussing, that is if I hit 'cancel' and then you message me twice > (once and receive the error message, at which point we autorenegotiate > and have a secure sesion, and then a second time which is an encrypted > message which goes through succesfully)? IPsec is at the level of IP packets, not messages. But if I remove an SA, then the new SA that gets created will have the same peer identifiers, but a different SPI (Security Parameters Index), and different keys. SPI is a random/arbitrary value chosen by the receiver, used to look up the SA on receiving a packet. It isn't a hash. Also, when you kill racoon, it sends authenticated delete messages to the peer, which removes the SAs it has with the killed racoon. This isn't the sort of security problem that Ian is (rightfully) so worried about, because removing the context doesn't allow cleartext messages - that's control by the policy database. And, the delete is authenticated. So really I'm arguing for an IPsec-like separation of policy and SA databases. In PFKEY_v2 (specifies kernel/IKE interaction for SA/SPD manipulation), SPD entries match traffic and can have multiple values: discard: bit-bucket the traffic. require: SA required. If none, send acquire and drop packet. use: SA preferred. if none, send acquire, but send packet anyway none: don't use SA. send packet in clear. don't send acquire These work on receive, too, so you can drop packets that aren't protected by IPsec if the incoming policy says require. Right now OTR always has an implicit policy setting of 'use'. I'm suggesting to add required and none, orthogonal to a 'delete context' operation. From alex323 at gmail.com Thu Jan 27 11:50:36 2005 From: alex323 at gmail.com (alex323) Date: Thu, 27 Jan 2005 11:50:36 -0500 Subject: [OTR-dev] Secure connections through a connect/disconnect cycle, OTR error messages In-Reply-To: <20050127120302.GB1060@smtp.paip.net> References: <20050126150732.GW1060@smtp.paip.net> <20050127120302.GB1060@smtp.paip.net> Message-ID: <7501094705012708501906b50b@mail.gmail.com> Why not just have a parser for when the message is decrypted? That way, Eve can't send the disconnect message. - Alex On Thu, 27 Jan 2005 07:03:02 -0500, Ian Goldberg wrote: > On Wed, Jan 26, 2005 at 01:25:17PM -0800, verbal wrote: > > On Wed, 26 Jan 2005 14:57:12 -0600, Evan Schoenberg wrote: > > > I think the lack of ?OTR messages is insufficient... that doesn't do > > > anything until bob sends a message and that message fails... Part of > > > the purpose of such a 'heads up' is that bob can react without us > > > having to wait for a message send to fail before any one is the wiser. > > > > > > > what do you mean by letting bob "react", ie what would bob do? if > > alice and bob are in an OTR conversation and alice turns it off. alice > > sends in plaintext to bob, which is ok because alice knows she is > > sending plaintext cause she set it while bob is sending in encrypted > > text which is ok because he still thinks they're encrypted. > > Don't forget to take into account the case where Alice and Bob are in a > secure conversation, but Eve sends a message to Bob (pretending to be > Alice), trying to convince Bob to turn off OTR. That could either be > the above plaintext, or the "heads-up" message, or whatever. > > It's *vital* that Bob _not_ turn off OTR in response to anything except > Alice (_in_ an OTR conversation) saying "OK, I'm turning off OTR now.". > [But this method does work OK.] > > - Ian > _______________________________________________ > OTR-dev mailing list > OTR-dev at lists.cypherpunks.ca > http://lists.cypherpunks.ca/mailman/listinfo/otr-dev > -- Thousands of people die every day. Yet you put 1 dead body in the middle of a busy street and it makes people crazy. From evan.s at dreskin.net Thu Jan 27 12:06:44 2005 From: evan.s at dreskin.net (Evan Schoenberg) Date: Thu, 27 Jan 2005 11:06:44 -0600 Subject: [OTR-dev] Secure connections through a connect/disconnect cycle, OTR error messages In-Reply-To: <7501094705012708501906b50b@mail.gmail.com> References: <20050126150732.GW1060@smtp.paip.net> <20050127120302.GB1060@smtp.paip.net> <7501094705012708501906b50b@mail.gmail.com> Message-ID: *nod* I meant that the notification would be sent in the OTR context before the client disconnects, not in plaintext after it disconnects, so it would not be possible for the "other side requested OTR disconnect" message to be emulated by a third party. -Evan On Jan 27, 2005, at 10:50 AM, alex323 wrote: > Why not just have a parser for when the message is decrypted? That > way, Eve can't send the disconnect message. > > - Alex > > > On Thu, 27 Jan 2005 07:03:02 -0500, Ian Goldberg > wrote: >> On Wed, Jan 26, 2005 at 01:25:17PM -0800, verbal wrote: >>> On Wed, 26 Jan 2005 14:57:12 -0600, Evan Schoenberg >>> wrote: >>>> I think the lack of ?OTR messages is insufficient... that doesn't >>>> do >>>> anything until bob sends a message and that message fails... Part of >>>> the purpose of such a 'heads up' is that bob can react without us >>>> having to wait for a message send to fail before any one is the >>>> wiser. >>>> >>> >>> what do you mean by letting bob "react", ie what would bob do? if >>> alice and bob are in an OTR conversation and alice turns it off. >>> alice >>> sends in plaintext to bob, which is ok because alice knows she is >>> sending plaintext cause she set it while bob is sending in encrypted >>> text which is ok because he still thinks they're encrypted. >> >> Don't forget to take into account the case where Alice and Bob are in >> a >> secure conversation, but Eve sends a message to Bob (pretending to be >> Alice), trying to convince Bob to turn off OTR. That could either be >> the above plaintext, or the "heads-up" message, or whatever. >> >> It's *vital* that Bob _not_ turn off OTR in response to anything >> except >> Alice (_in_ an OTR conversation) saying "OK, I'm turning off OTR >> now.". >> [But this method does work OK.] >> >> - Ian >> _______________________________________________ >> OTR-dev mailing list >> OTR-dev at lists.cypherpunks.ca >> http://lists.cypherpunks.ca/mailman/listinfo/otr-dev >> > > > -- > Thousands of people die every day. Yet you put 1 dead body in the > middle of a busy street and it makes people crazy. > _______________________________________________ > OTR-dev mailing list > OTR-dev at lists.cypherpunks.ca > http://lists.cypherpunks.ca/mailman/listinfo/otr-dev > From ian at cypherpunks.ca Thu Jan 27 12:35:03 2005 From: ian at cypherpunks.ca (Ian Goldberg) Date: Thu, 27 Jan 2005 12:35:03 -0500 Subject: [OTR-dev] Secure connections through a connect/disconnect cycle, OTR error messages In-Reply-To: References: <20050126150732.GW1060@smtp.paip.net> <20050127120302.GB1060@smtp.paip.net> <7501094705012708501906b50b@mail.gmail.com> Message-ID: <20050127173503.GE1060@smtp.paip.net> On Thu, Jan 27, 2005 at 11:06:44AM -0600, Evan Schoenberg wrote: > *nod* I meant that the notification would be sent in the OTR context > before the client disconnects, not in plaintext after it disconnects, > so it would not be possible for the "other side requested OTR > disconnect" message to be emulated by a third party. So when you click "end private connection", the client first sends an IM like "[ending private connection]" (as if you'd typed that string), and then forgets the context? That'd be fine, security-wise; it'd just be an automated form of what people can do now. - Ian From paul at cypherpunks.ca Thu Jan 27 12:43:26 2005 From: paul at cypherpunks.ca (Paul Wouters) Date: Thu, 27 Jan 2005 18:43:26 +0100 (CET) Subject: [OTR-dev] OTR encryption state In-Reply-To: <20050127143620.GC1060@smtp.paip.net> Message-ID: On Thu, 27 Jan 2005, Ian Goldberg wrote: > [Side note: libotr now can have separate UserStates (instead of the > static context_root and privkey_root). It also will reencrypt and > retransmit the last message it sent encrypted (if it's very recent) > in the event that the other guy lost his OTR state. (Paul's been > requesting that since the dawn of time.)] Yay! Release! release! :) Paul From evan.s at dreskin.net Thu Jan 27 12:48:30 2005 From: evan.s at dreskin.net (Evan Schoenberg) Date: Thu, 27 Jan 2005 11:48:30 -0600 Subject: [OTR-dev] Secure connections through a connect/disconnect cycle, OTR error messages In-Reply-To: <20050127173503.GE1060@smtp.paip.net> References: <20050126150732.GW1060@smtp.paip.net> <20050127120302.GB1060@smtp.paip.net> <7501094705012708501906b50b@mail.gmail.com> <20050127173503.GE1060@smtp.paip.net> Message-ID: Yup, I appear to winning awards for poor communication, despite my best efforts. :) You've described it precisely. Except instead of the client manually sending an IM (i.e. having an automated message sent out when the user clicks Adium's button to "end private conversation" which reads "Evan has clicked end private conversation!"), OTR itself sends out the message in a way the OTR plugin on the other side can interpret as a conversation event and pass as such, in the schnazzy conversation-associated way which the message > 10:45:21 : The encrypted message received from buddy's name> is unreadable, as you are not currently communicating > privately. should also be presented. -Evan On Jan 27, 2005, at 11:35 AM, Ian Goldberg wrote: > So when you click "end private connection", the client first sends an > IM > like "[ending private connection]" (as if you'd typed that string), and > then forgets the context? > > That'd be fine, security-wise; it'd just be an automated form of what > people can do now. From paul at cypherpunks.ca Thu Jan 27 13:00:04 2005 From: paul at cypherpunks.ca (Paul Wouters) Date: Thu, 27 Jan 2005 19:00:04 +0100 (CET) Subject: [OTR-dev] OTR encryption state In-Reply-To: <20050127152747.D44E01F5C@fnord.ir.bbn.com> Message-ID: On Thu, 27 Jan 2005, Greg Troxel wrote: > I don't see why 'discard context' shouldn't send an authenticated > message to the other side saying that, similar to an IKE Delete notify > message. Actually, there are problems involved with that approach. What if that happens to be the packet you miss due to packet loss (or an active attacker). IKE solves this by always allowing a renegotiation of IKE in plaintext from the IP it has an ISAKMP SA for. Unfortunately, we don't have that in OTR, since we are re-using the only channel we have between the two parties. > IPsec is at the level of IP packets, not messages. But if I remove an > SA, then the new SA that gets created will have the same peer > identifiers, but a different SPI (Security Parameters Index), and > different keys. SPI is a random/arbitrary value chosen by the > receiver, used to look up the SA on receiving a packet. It isn't a > hash. Yes, but again, you have the luxury of being able to communicate both encrypted and plaintext to the same machine (where for plaintext only IKE messages are accepted). In fact, Openswan gives you additional protection here with the uniqueids= option, which you can use to decide whether or not to ignore these new plaintext IKE packets or not. If you decide to ignore them (eg to twart spoofed IKE packets interfering with your established ISAKMP connection) you also condemning yourself when you or your remote partner crashes or receives a new IP address. You will have to wait the remainder of the SA keylife before you can negotiate a new SA. Needless to say, uniqueids= is on per default, meaning that if a known party appears on a new IP or suddenly starts sending new plaintext IKE packets, you allow these packets and when you have a new SA, you kill the old one. > Also, when you kill racoon, it sends authenticated delete messages to > the peer, which removes the SAs it has with the killed racoon. Assuming th epacket makes it. You'll be suprised how often Notify Delete's get lost, especially on roadwarrior type setups. (or worse, someone losing their access point or just closing the lid on their laptop, causing no Delete/Notify message to be sent at all). > This isn't the sort of security problem that Ian is (rightfully) so > worried about, because removing the context doesn't allow cleartext > messages The real potential information leak is at the restarted client. That user might accidently send a cleartext message, forgetting his client or connection got restarted. One way to resolve this would be to initiate OTR for all buddies you had an OTR connect with when shutting down that are currently listed as online, but I fear that would only add to the amount of fingerprint windows I need to click away in the morning that I already have. Paul From paul at cypherpunks.ca Thu Jan 27 13:03:34 2005 From: paul at cypherpunks.ca (Paul Wouters) Date: Thu, 27 Jan 2005 19:03:34 +0100 (CET) Subject: [OTR-dev] Secure connections through a connect/disconnect cycle, OTR error messages In-Reply-To: <20050127173503.GE1060@smtp.paip.net> Message-ID: On Thu, 27 Jan 2005, Ian Goldberg wrote: > So when you click "end private connection", the client first sends an IM > like "[ending private connection]" (as if you'd typed that string), and > then forgets the context? > > That'd be fine, security-wise; it'd just be an automated form of what > people can do now. You mean it wasn't like this what was happening when I clicked the OTR button to leave private mode?? Paul From gdt at ir.bbn.com Thu Jan 27 13:05:14 2005 From: gdt at ir.bbn.com (Greg Troxel) Date: 27 Jan 2005 13:05:14 -0500 Subject: [OTR-dev] OTR encryption state In-Reply-To: <20050127143620.GC1060@smtp.paip.net> References: <20050126210740.DF8961F68@fnord.ir.bbn.com> <20050127143620.GC1060@smtp.paip.net> Message-ID: ALWAYS: It is an error to send unencrypted data to this user. If you try, you'll get a notify(ERROR) callback and the message to be sent will be turned into an OTR Error message that the other side will see. I'd say: if one tries to send data, and we don't have a context, try to do a key exchange, and then send the data. Other than sending KEX request, do not convey any information to the peer. If KEX fails, notify locally of error. I realize that's missing the UI/libotr boundary, though. -- Greg Troxel From gdt at ir.bbn.com Thu Jan 27 13:08:36 2005 From: gdt at ir.bbn.com (Greg Troxel) Date: 27 Jan 2005 13:08:36 -0500 Subject: [OTR-dev] Secure connections through a connect/disconnect cycle, OTR error messages In-Reply-To: <20050127173503.GE1060@smtp.paip.net> References: <20050126150732.GW1060@smtp.paip.net> <20050127120302.GB1060@smtp.paip.net> <7501094705012708501906b50b@mail.gmail.com> <20050127173503.GE1060@smtp.paip.net> Message-ID: So when you click "end private connection", the client first sends an IM like "[ending private connection]" (as if you'd typed that string), and then forgets the context? This begs a larger issue, which is that there is a subchannel within the IM channel for key management, and another for encrypted/maced data. I would define a 'deleting context' message format within the key management subchannel, that carries the hash of the context being deleted. Pretty much what you are saying, but more of a focus on KM-KM communication, and making it machine-parsable as priority #1. -- Greg Troxel From gdt at ir.bbn.com Thu Jan 27 13:16:52 2005 From: gdt at ir.bbn.com (Greg Troxel) Date: Thu, 27 Jan 2005 13:16:52 -0500 Subject: [OTR-dev] OTR encryption state In-Reply-To: Message from Paul Wouters of "Thu, 27 Jan 2005 19:00:04 +0100." Message-ID: <20050127181652.42FB11F64@fnord.ir.bbn.com> > From: Paul Wouters > > On Thu, 27 Jan 2005, Greg Troxel wrote: > > > I don't see why 'discard context' shouldn't send an authenticated > > message to the other side saying that, similar to an IKE Delete notify > > message. > > Actually, there are problems involved with that approach. What if that > happens to be the packet you miss due to packet loss (or an active attacker). > IKE solves this by always allowing a renegotiation of IKE in plaintext from > the IP it has an ISAKMP SA for. Unfortunately, we don't have that in OTR, > since we are re-using the only channel we have between the two parties. Sure, a delete can be missed. It just aids cleanliness most of the time, and enables the remote side, when it works, to negotiate a new SA before the old one times out. Isn't the channel subchannelized by tags at the beginning? (or shouldn't it be?) > Yes, but again, you have the luxury of being able to communicate both > encrypted and plaintext to the same machine (where for plaintext only IKE > messages are accepted). I really don't see why one couldn't send a KEX message instead of an encrypted data message. Certainly a restart at one end will need this to recover, since effectively in OTR all delete messages are lost (since they aren't sent). > In fact, Openswan gives you additional protection here with the uniqueids= > option, which you can use to decide whether or not to ignore these new > plaintext IKE packets or not. If you decide to ignore them (eg to twart > spoofed IKE packets interfering with your established ISAKMP connection) > you also condemning yourself when you or your remote partner crashes or > receives a new IP address. You will have to wait the remainder of the SA > keylife before you can negotiate a new SA. Needless to say, uniqueids= > is on per default, meaning that if a known party appears on a new IP or > suddenly starts sending new plaintext IKE packets, you allow these packets > and when you have a new SA, you kill the old one. Sure, but calling the IKE messages 'plaintext' is not quite fair, since to complete an IKE exchange one has to create a signature. > Assuming th epacket makes it. You'll be suprised how often Notify > Delete's get lost, especially on roadwarrior type setups. (or worse, > someone losing their access point or just closing the lid on their > laptop, causing no Delete/Notify message to be sent at all). Sure, I'm mostly talking LAN environment, using transport mode for filesystem traffic. > The real potential information leak is at the restarted client. That user > might accidently send a cleartext message, forgetting his client or > connection got restarted. Exactly. This is why I suggested having a 'require' state bit per peer, much like an Ipsec SPD. > One way to resolve this would be to initiate OTR > for all buddies you had an OTR connect with when shutting down that are > currently listed as online, but I fear that would only add to the amount > of fingerprint windows I need to click away in the morning that I already > have. That would also send a lot of KM traffic when there was no data traffic. Do you have any objections to a per-user 'require' bit? From ian at cypherpunks.ca Thu Jan 27 13:14:18 2005 From: ian at cypherpunks.ca (Ian Goldberg) Date: Thu, 27 Jan 2005 13:14:18 -0500 Subject: [OTR-dev] Secure connections through a connect/disconnect cycle, OTR error messages In-Reply-To: References: <20050127173503.GE1060@smtp.paip.net> Message-ID: <20050127181418.GF1060@smtp.paip.net> On Thu, Jan 27, 2005 at 07:03:34PM +0100, Paul Wouters wrote: > On Thu, 27 Jan 2005, Ian Goldberg wrote: > > > So when you click "end private connection", the client first sends an IM > > like "[ending private connection]" (as if you'd typed that string), and > > then forgets the context? > > > > That'd be fine, security-wise; it'd just be an automated form of what > > people can do now. > > You mean it wasn't like this what was happening when I clicked the OTR > button to leave private mode?? Now, the client doesn't send any IM indicating it's leaving private mode. - Ian From paul at cypherpunks.ca Thu Jan 27 13:55:41 2005 From: paul at cypherpunks.ca (Paul Wouters) Date: Thu, 27 Jan 2005 19:55:41 +0100 (CET) Subject: [OTR-dev] Secure connections through a connect/disconnect cycle, OTR error messages In-Reply-To: <20050127181418.GF1060@smtp.paip.net> Message-ID: On Thu, 27 Jan 2005, Ian Goldberg wrote: > > > So when you click "end private connection", the client first sends an IM > > > like "[ending private connection]" (as if you'd typed that string), and > > > then forgets the context? > > > > > > That'd be fine, security-wise; it'd just be an automated form of what > > > people can do now. > > > > You mean it wasn't like this what was happening when I clicked the OTR > > button to leave private mode?? > > Now, the client doesn't send any IM indicating it's leaving private mode. Ah.. Then I'd definately like some sort of authenticated Notify/Delete message. It would prevent a lot of misencrypted messages. The remote end should do something noticable ofcourse, showing the encrypted state was lost. Hmm, so thinking about this, perhaps the current resend-if-not-readable is better from the UI point of view, even if not as clean from a protocol point of view. Paul From verbal at gmail.com Thu Jan 27 15:28:19 2005 From: verbal at gmail.com (verbal) Date: Thu, 27 Jan 2005 12:28:19 -0800 Subject: [OTR-dev] OTR encryption state In-Reply-To: <20050127143620.GC1060@smtp.paip.net> References: <20050126210740.DF8961F68@fnord.ir.bbn.com> <20050127143620.GC1060@smtp.paip.net> Message-ID: you dont need NEVER *and* MANUAL. In fact, you can replace NEVER and ALWAYS with MANUAL. just have MANUAL off = NEVER and MANUAL on = ALWAYS. to me, having MANUAL and OPPORTUNISTIC seems to be the simplist and most intuitive design. verbal > > which returns information about what OTR features should and should not > be enabled for this context? > > NEVER: Pretend OTR isn't enabled at all for this user > ALWAYS: It is an error to send unencrypted data to this user. > If you try, you'll get a notify(ERROR) callback and > the message to be sent will be turned into an OTR Error > message that the other side will see. > OPPORTUNISTIC: (the current mode) probe the other side with the > whitespace tag, and reply to any indication that he > speaks OTR with a Key Exchange Message (if we're not > already private) > MANUAL: Don't send the whitespace tag, and don't reply to one you > receive. Respond to explicit OTR Query Messages and Key Exchange > Messages, but not other indications of OTR. This mode is > useful if you for some reason want to communicate in the > clear, even though you know the other guy speaks OTR, and > also allow either side to start a private conversation > at any time. [If you don't want to allow that last > condition, use NEVER instead.] > > - Ian > _______________________________________________ > OTR-dev mailing list > OTR-dev at lists.cypherpunks.ca > http://lists.cypherpunks.ca/mailman/listinfo/otr-dev > From ian at cypherpunks.ca Thu Jan 27 15:35:44 2005 From: ian at cypherpunks.ca (Ian Goldberg) Date: Thu, 27 Jan 2005 15:35:44 -0500 Subject: [OTR-dev] Secure connections through a connect/disconnect cycle, OTR error messages In-Reply-To: References: <20050127181418.GF1060@smtp.paip.net> Message-ID: <20050127203544.GJ1060@smtp.paip.net> On Thu, Jan 27, 2005 at 07:55:41PM +0100, Paul Wouters wrote: > Ah.. Then I'd definately like some sort of authenticated Notify/Delete > message. It would prevent a lot of misencrypted messages. The remote > end should do something noticable ofcourse, showing the encrypted > state was lost. As I mentioned earlier, I really don't think the client should *ever* drop the private connection because of a network event. It's OK if the user gets informed that the person he was talking to dropped his connection (so long as that message goes over the private channel before it's dropped), but the user should then turn off his side manually. > Hmm, so thinking about this, perhaps the current > resend-if-not-readable is better from the UI point of view, even if > not as clean from a protocol point of view. It also has the benefit of working now. ;-) - Ian From ian at cypherpunks.ca Thu Jan 27 15:37:32 2005 From: ian at cypherpunks.ca (Ian Goldberg) Date: Thu, 27 Jan 2005 15:37:32 -0500 Subject: [OTR-dev] Secure connections through a connect/disconnect cycle, OTR error messages In-Reply-To: References: <20050126150732.GW1060@smtp.paip.net> <20050127120302.GB1060@smtp.paip.net> <7501094705012708501906b50b@mail.gmail.com> <20050127173503.GE1060@smtp.paip.net> Message-ID: <20050127203732.GK1060@smtp.paip.net> On Thu, Jan 27, 2005 at 01:08:36PM -0500, Greg Troxel wrote: > So when you click "end private connection", the client first sends an IM > like "[ending private connection]" (as if you'd typed that string), and > then forgets the context? > > This begs a larger issue, which is that there is a subchannel within > the IM channel for key management, and another for encrypted/maced > data. I would define a 'deleting context' message format within the > key management subchannel, that carries the hash of the context being > deleted. Pretty much what you are saying, but more of a focus on > KM-KM communication, and making it machine-parsable as priority #1. But we don't *want* the Key Manager (such as it is) to automatically deal with that message. - Ian From ian at cypherpunks.ca Thu Jan 27 15:40:35 2005 From: ian at cypherpunks.ca (Ian Goldberg) Date: Thu, 27 Jan 2005 15:40:35 -0500 Subject: [OTR-dev] OTR encryption state In-Reply-To: References: <20050127143620.GC1060@smtp.paip.net> Message-ID: <20050127204035.GL1060@smtp.paip.net> On Thu, Jan 27, 2005 at 06:43:26PM +0100, Paul Wouters wrote: > On Thu, 27 Jan 2005, Ian Goldberg wrote: > > > [Side note: libotr now can have separate UserStates (instead of the > > static context_root and privkey_root). It also will reencrypt and > > retransmit the last message it sent encrypted (if it's very recent) > > in the event that the other guy lost his OTR state. (Paul's been > > requesting that since the dawn of time.)] > > Yay! > > Release! release! :) Not yet. I'd like some input on whether the API proposal for the "policy" question is sane. [i.e. "is useful to the people (Evan?) who will be hooking it into clients"] Actually implementing it shouldn't be more than 1/2 an hour, if we agree on what "it" should be. - Ian From ian at cypherpunks.ca Thu Jan 27 15:53:08 2005 From: ian at cypherpunks.ca (Ian Goldberg) Date: Thu, 27 Jan 2005 15:53:08 -0500 Subject: [OTR-dev] OTR encryption state In-Reply-To: References: <20050126210740.DF8961F68@fnord.ir.bbn.com> <20050127143620.GC1060@smtp.paip.net> Message-ID: <20050127205308.GM1060@smtp.paip.net> On Thu, Jan 27, 2005 at 01:05:14PM -0500, Greg Troxel wrote: > ALWAYS: It is an error to send unencrypted data to this user. > If you try, you'll get a notify(ERROR) callback and > the message to be sent will be turned into an OTR Error > message that the other side will see. > > I'd say: > > if one tries to send data, and we don't have a context, try to do a > key exchange, and then send the data. Other than sending KEX > request, do not convey any information to the peer. If KEX fails, > notify locally of error. > > I realize that's missing the UI/libotr boundary, though. I think you'd actually send an OTR Query Message, since you're not guaranteed at that point that the other side knows about OTR. But that seems like a sensible modification. I think it'd be up to the UI to have some timeout if it wants to notify the user that the connection didn't start up. I think the user should be notify()d in any event, though. i.e.: - UI tries to send a message to a context that's UNCONNECTED, but nevertheless has its policy set to ALWAYS - libotr holds on to the message (using the same mechanism as currently used for the "bad-encryption" retransmits, as it turns out), and replaces it with an OTR Query message. - libotr notify(INFO)s the user that it's trying to start a private session - the UI transmits the OTR Query message it received from libotr (the same as it would for any message modified by libotr) If the other side does not speak OTR, there'll just be a timeout. The UI should let the user know. If it does, you'll get a Key Exchange message back, which will be handled in the normal way. A private session will start, and the original message which triggered this whole thing will get retransmitted in the secure session. What should happen if you receive an unencrypted message from someone if you're in the UNCONNECTED state, but the policy is ALWAYS? Maybe just act like you would if you were CONNECTED? (i.e. "The following message received from blah was NOT encrypted: [...]") - Ian From evan.s at dreskin.net Thu Jan 27 16:00:20 2005 From: evan.s at dreskin.net (Evan Schoenberg) Date: Thu, 27 Jan 2005 15:00:20 -0600 Subject: [OTR-dev] Secure connections through a connect/disconnect cycle, OTR error messages In-Reply-To: <20050127203544.GJ1060@smtp.paip.net> References: <20050127181418.GF1060@smtp.paip.net> <20050127203544.GJ1060@smtp.paip.net> Message-ID: <7456CF2C-70A6-11D9-8D4E-000A95685E80@dreskin.net> On Jan 27, 2005, at 2:35 PM, Ian Goldberg wrote: > As I mentioned earlier, I really don't think the client should *ever* > drop > the private connection because of a network event. It's OK if the user > gets informed that the person he was talking to dropped his connection > (so long as that message goes over the private channel before it's > dropped), but the user should then turn off his side manually. I think that's perfect. No automatic dropping of the connection, and automatic secure notification of the changed state. -Evan From ian at cypherpunks.ca Thu Jan 27 16:01:15 2005 From: ian at cypherpunks.ca (Ian Goldberg) Date: Thu, 27 Jan 2005 16:01:15 -0500 Subject: [OTR-dev] OTR encryption state In-Reply-To: References: <20050126210740.DF8961F68@fnord.ir.bbn.com> <20050127143620.GC1060@smtp.paip.net> Message-ID: <20050127210115.GN1060@smtp.paip.net> On Thu, Jan 27, 2005 at 12:28:19PM -0800, verbal wrote: > you dont need NEVER *and* MANUAL. > > In fact, you can replace NEVER and ALWAYS with MANUAL. just have > MANUAL off = NEVER and MANUAL on = ALWAYS. The difference between MANUAL and NEVER is whether you allow the other guy to start OTR. If so, it's MANUAL. If not, it's NEVER. The difference between MANUAL and ALWAYS is that's it's not possible to send plaintext with ALWAYS, but it is with MANUAL. Maybe "MANUAL" isn't the right word? > to me, having MANUAL and OPPORTUNISTIC seems to be the simplist and > most intuitive design. I think it leaves out important modes you might want to specify. - Ian From ian at cypherpunks.ca Thu Jan 27 16:15:17 2005 From: ian at cypherpunks.ca (Ian Goldberg) Date: Thu, 27 Jan 2005 16:15:17 -0500 Subject: [OTR-dev] Secure connections through a connect/disconnect cycle, OTR error messages In-Reply-To: <7456CF2C-70A6-11D9-8D4E-000A95685E80@dreskin.net> References: <20050127181418.GF1060@smtp.paip.net> <20050127203544.GJ1060@smtp.paip.net> <7456CF2C-70A6-11D9-8D4E-000A95685E80@dreskin.net> Message-ID: <20050127211517.GO1060@smtp.paip.net> On Thu, Jan 27, 2005 at 03:00:20PM -0600, Evan Schoenberg wrote: > >As I mentioned earlier, I really don't think the client should *ever* > >drop the private connection because of a network event. It's OK if > >the user gets informed that the person he was talking to dropped his > >connection (so long as that message goes over the private channel > >before it's dropped), but the user should then turn off his side > >manually. > > I think that's perfect. No automatic dropping of the connection, and > automatic secure notification of the changed state. But I still think the client should send that message, not libotr. You *don't* want the library to have to guess whether people you've got a context with are actually still online, since having the library send a message to an offline person causes no end of trouble. - Ian From evan.s at dreskin.net Thu Jan 27 16:20:23 2005 From: evan.s at dreskin.net (Evan Schoenberg) Date: Thu, 27 Jan 2005 15:20:23 -0600 Subject: [OTR-dev] OTR encryption state In-Reply-To: <20050127143620.GC1060@smtp.paip.net> References: <20050126210740.DF8961F68@fnord.ir.bbn.com> <20050127143620.GC1060@smtp.paip.net> Message-ID: <4172F8EF-70A9-11D9-8D4E-000A95685E80@dreskin.net> (Sorry, Ian, I didn't initially see this at the bottom of the email it was within). Ian wrote: > NEVER: Pretend OTR isn't enabled at all for this user In what context would this be useful? > ALWAYS: It is an error to send unencrypted data to this user. > If you try, you'll get a notify(ERROR) callback and > the message to be sent will be turned into an OTR Error > message that the other side will see. With the addition of the message queuing described later, this would be good. See below. > OPPORTUNISTIC: (the current mode) probe the other side with the > whitespace tag, and reply to any indication that he > speaks OTR with a Key Exchange Message (if we're not > already private) > How does the "whitespace tag" work? Do all contacts I speak with which don't have OTR receive an IM from me every time I start a chat? This doesn't seem to be the case.. but it's the current mode. > MANUAL: Don't send the whitespace tag, and don't reply to one you > receive. Respond to explicit OTR Query Messages and Key > Exchange > Messages, but not other indications of OTR. This mode is > useful if you for some reason want to communicate in the > clear, even though you know the other guy speaks OTR, and > also allow either side to start a private conversation > at any time. [If you don't want to allow that last > condition, use NEVER instead.] This seems more like the current mode to me. How would it differ from current behavior? Given these possibilities, this is what I would set up... please see if this description matches the use you envision. - In a messaging window, the user is presented with a visual indication of the current OTR state. "Encrypted" vs. "Plaintext" basically. This indicator offers a menu for toggling between the two states... "Start OTR session" / "End OTR session". I guess "End OTR session" would be disabled in ALWAYS mode. What happens in each of OPPORTUNISTIC and MANUAL modes when I select "End OTR session" ? - In a preferences area for each contact, offer the following checkboxes (the second dependent upon the first being checked): [ ] Automatically initiate encrypted OTR messaging [ ] Refuse unencrypted messages The first corresponds to to OPPORTUNISTIC. The second corresponds to ALWAYS (which is really a restricted version of OPPORTUNISTIC). -Evan On Jan 27, 2005, at 8:36 AM, Ian Goldberg wrote: > Implementation-wise, what do you think of adding a callback that looks > something like: > > OtrlMessagePolicy determine_policy(userstate, accountname, protocol, > username, context); > > which returns information about what OTR features should and should not > be enabled for this context? [pasted above] > - Ian From evan.s at dreskin.net Thu Jan 27 16:28:03 2005 From: evan.s at dreskin.net (Evan Schoenberg) Date: Thu, 27 Jan 2005 15:28:03 -0600 Subject: [OTR-dev] Secure connections through a connect/disconnect cycle, OTR error messages In-Reply-To: <20050127211517.GO1060@smtp.paip.net> References: <20050127181418.GF1060@smtp.paip.net> <20050127203544.GJ1060@smtp.paip.net> <7456CF2C-70A6-11D9-8D4E-000A95685E80@dreskin.net> <20050127211517.GO1060@smtp.paip.net> Message-ID: <53EFA304-70AA-11D9-8D4E-000A95685E80@dreskin.net> On Jan 27, 2005, at 3:15 PM, Ian Goldberg wrote: > But I still think the client should send that message, not libotr. You > *don't* want the library to have to guess whether people you've got a > context with are actually still online, since having the library send a > message to an offline person causes no end of trouble. > > - Ian Except then it has to show up as a message from the person. If I click a button, my IM client should NEVER send text to the person with whom I'm chatting which looks as if I have typed it. I want it to be able to show up inline but like other status changes/conversation errors/conversation updates/etc. Didn't you say in another thread that there should be no automatic disconnection of the ConnContext when signing off? So the notification wouldn't go out when the person signs off. And on another tack: Does the heartbeat present the same problem? -Evan From evan.s at dreskin.net Thu Jan 27 16:31:48 2005 From: evan.s at dreskin.net (Evan Schoenberg) Date: Thu, 27 Jan 2005 15:31:48 -0600 Subject: [OTR-dev] OTR encryption state In-Reply-To: <4172F8EF-70A9-11D9-8D4E-000A95685E80@dreskin.net> References: <20050126210740.DF8961F68@fnord.ir.bbn.com> <20050127143620.GC1060@smtp.paip.net> <4172F8EF-70A9-11D9-8D4E-000A95685E80@dreskin.net> Message-ID: I wrote: >> NEVER: Pretend OTR isn't enabled at all for this user > In what context would this be useful? Saw your reply to verbal. That makes sense, and updates my previously proposed options to: [ ] Enable encrypted messaging (Default: YES. Equivalent: NONE vs. MANUAL) [ ] Automatically initiate encrypted OTR messaging (Default: ???. See below. Equivalent: OPPORTUNISTIC vs MANUAL) [ ] Refuse unencrypted messages (Default: NO. Equivalent: AUTOMATIC vs. OPPORTUNISTIC) I am unsure of the second default because I don't understand the 'whitespace' thing yet. -Evan From ian at cypherpunks.ca Thu Jan 27 17:06:23 2005 From: ian at cypherpunks.ca (Ian Goldberg) Date: Thu, 27 Jan 2005 17:06:23 -0500 Subject: [OTR-dev] Secure connections through a connect/disconnect cycle, OTR error messages In-Reply-To: <53EFA304-70AA-11D9-8D4E-000A95685E80@dreskin.net> References: <20050127181418.GF1060@smtp.paip.net> <20050127203544.GJ1060@smtp.paip.net> <7456CF2C-70A6-11D9-8D4E-000A95685E80@dreskin.net> <20050127211517.GO1060@smtp.paip.net> <53EFA304-70AA-11D9-8D4E-000A95685E80@dreskin.net> Message-ID: <20050127220623.GQ1060@smtp.paip.net> On Thu, Jan 27, 2005 at 03:28:03PM -0600, Evan Schoenberg wrote: > >But I still think the client should send that message, not libotr. You > >*don't* want the library to have to guess whether people you've got a > >context with are actually still online, since having the library send a > >message to an offline person causes no end of trouble. > > Except then it has to show up as a message from the person. If I click > a button, my IM client should NEVER send text to the person with whom > I'm chatting which looks as if I have typed it. I want it to be able > to show up inline but like other status changes/conversation > errors/conversation updates/etc. But it *is* a message that's sent as if you typed it, whether the UI or libotr does it. Every (inline) message from OTR looks as if the other user typed it, since that's the only way to deliver inline messages. The way I'm thinking of it, that button is just a macro for typing "[closing private connection]" (and then forgetting the state, the way it does now). It's perfectly acceptable (securitywise) for the user to just type that himself, and is in fact the only real to do it currently. > Didn't you say in another thread that there should be no automatic > disconnection of the ConnContext when signing off? So the notification > wouldn't go out when the person signs off. Right. But then if *I* go non-private, it'll try to send the "Ian has closed the private connection" message to a user who isn't there anymore, and Nothing Good comes of that. Also, ConnContexts do get disconnected if the user quits the client (or otherwise unloads the OTR plugin). > And on another tack: Does the heartbeat present the same problem? The first attempt had this very problem. Now, heartbeats are only sent in immediate response to messages received, so you have a pretty good chance the other guy is logged in. But we can't make that claim in this case, since an arbitrary time may have passed since the last time we saw him. Really, the user is the only one who "knows" if he's in an active conversation, or if the window is idle. If it's idle, there's no harm in not sending the message. But if the user knows that his correspondent has just gone to do dishes or something, but it still "there", he may want to tell him that OTR is stopping. [Though I can't think of a good reason why he'd want to stop it in that circumstance.] I'm perfectly happy with just saying the user can let the other guy know he's planning to stop OTR if he wants to. Note that once the "policy" stuff goes in, the user can switch to "MANUAL" state, so that the other guy's typing doesn't cause OTR to auto-start back up. - Ian From evan.s at dreskin.net Thu Jan 27 17:20:33 2005 From: evan.s at dreskin.net (Evan Schoenberg) Date: Thu, 27 Jan 2005 16:20:33 -0600 Subject: [OTR-dev] Secure connections through a connect/disconnect cycle, OTR error messages In-Reply-To: <20050127220623.GQ1060@smtp.paip.net> References: <20050127181418.GF1060@smtp.paip.net> <20050127203544.GJ1060@smtp.paip.net> <7456CF2C-70A6-11D9-8D4E-000A95685E80@dreskin.net> <20050127211517.GO1060@smtp.paip.net> <53EFA304-70AA-11D9-8D4E-000A95685E80@dreskin.net> <20050127220623.GQ1060@smtp.paip.net> Message-ID: On Jan 27, 2005, at 4:06 PM, Ian Goldberg wrote: > > But it *is* a message that's sent as if you typed it, whether the UI or > libotr does it. Every (inline) message from OTR looks as if the other > user typed it, since that's the only way to deliver inline messages. > Which is a situation that I've been saying in several different threads should change. That's not the only way to deliver inline messages. For a client which can only display an inline message as an incoming message, it can implement the inform_error callback to simply call the inform_message callback. For a client which can differentiate and still be inline... such as Gaim and Adium... it can provide a better user experience by having the chance to handle the inline error differently. > The way I'm thinking of it, that button is just a macro for typing > "[closing private connection]" (and then forgetting the state, the way > it does now). It's perfectly acceptable (securitywise) for the user to > just type that himself, and is in fact the only real to do it > currently. >> Didn't you say in another thread that there should be no automatic >> disconnection of the ConnContext when signing off? So the >> notification >> wouldn't go out when the person signs off. > > Right. But then if *I* go non-private, it'll try to send the "Ian has > closed the private connection" message to a user who isn't there > anymore, and Nothing Good comes of that. > >> And on another tack: Does the heartbeat present the same problem? > > The first attempt had this very problem. Hm. Okay, what if the UI had a callback which could let the library know if the user is available for heartbeats and conversation closed messages? If the information is unavailable, the UI just returns NO, and we proceed as we do at present... but if the information is available (in Gaim, it's an easy check to find out if a given username/account/protocol combination is available, and in Adium similarly) then we can do the better behavior without running into the problem of sending messages to offline contacts. > Also, ConnContexts do get disconnected if the user quits the client (or > otherwise unloads the OTR plugin). > Ah, right. > Note that once the "policy" stuff goes in, the user can switch to > "MANUAL" state, so that the other guy's typing doesn't cause OTR to > auto-start back up. > I'm sending an email in another thread regarding the autostarting back up, as I don't want to crowd this one's continuity such as it is for those of us using threaded mail readers ;) -Evan From ian at cypherpunks.ca Thu Jan 27 17:22:16 2005 From: ian at cypherpunks.ca (Ian Goldberg) Date: Thu, 27 Jan 2005 17:22:16 -0500 Subject: [OTR-dev] OTR encryption state In-Reply-To: <4172F8EF-70A9-11D9-8D4E-000A95685E80@dreskin.net> References: <20050126210740.DF8961F68@fnord.ir.bbn.com> <20050127143620.GC1060@smtp.paip.net> <4172F8EF-70A9-11D9-8D4E-000A95685E80@dreskin.net> Message-ID: <20050127222216.GR1060@smtp.paip.net> On Thu, Jan 27, 2005 at 03:20:23PM -0600, Evan Schoenberg wrote: > > OPPORTUNISTIC: (the current mode) probe the other side with the > > whitespace tag, and reply to any indication that he > > speaks OTR with a Key Exchange Message (if we're not > > already private) > > > How does the "whitespace tag" work? Do all contacts I speak with which > don't have OTR receive an IM from me every time I start a chat? This > doesn't seem to be the case.. but it's the current mode. It's the clever thing suggested by Gregory Maxwell. The first time you send a message to someone, append a magic pattern of whitespace. OTR clients recognize the whitespace at the end of the message, and opportunistically start OTR. It's just meant as a more invisible (and automatic) version of the OTR Query message. So in OPPORTUNISTIC mode, if you send any old message to someone who speaks OTR (and is also in OPPORTUNISTIC mode), OTR will start. > > MANUAL: Don't send the whitespace tag, and don't reply to one you > > receive. Respond to explicit OTR Query Messages and Key > >Exchange > > Messages, but not other indications of OTR. This mode is > > useful if you for some reason want to communicate in the > > clear, even though you know the other guy speaks OTR, and > > also allow either side to start a private conversation > > at any time. [If you don't want to allow that last > > condition, use NEVER instead.] > This seems more like the current mode to me. How would it differ from > current behavior? MANUAL only starts OTR in response to explicit requests to do so. OPPORTUNISTIC (the current mode) starts OTR in response to any indication the other side speaks OTR, including the whitespace tag and OTR Error messages. - Ian From ian at cypherpunks.ca Thu Jan 27 17:28:32 2005 From: ian at cypherpunks.ca (Ian Goldberg) Date: Thu, 27 Jan 2005 17:28:32 -0500 Subject: [OTR-dev] OTR encryption state In-Reply-To: References: <20050126210740.DF8961F68@fnord.ir.bbn.com> <20050127143620.GC1060@smtp.paip.net> <4172F8EF-70A9-11D9-8D4E-000A95685E80@dreskin.net> Message-ID: <20050127222832.GS1060@smtp.paip.net> On Thu, Jan 27, 2005 at 03:31:48PM -0600, Evan Schoenberg wrote: > I wrote: > > >> NEVER: Pretend OTR isn't enabled at all for this user > >In what context would this be useful? > > Saw your reply to verbal. That makes sense, and updates my previously > proposed options to: > > [ ] Enable encrypted messaging (Default: YES. Equivalent: NONE vs. > MANUAL) > [ ] Automatically initiate encrypted OTR messaging (Default: > ???. See below. Equivalent: OPPORTUNISTIC vs MANUAL) > [ ] Refuse unencrypted messages (Default: NO. Equivalent: > AUTOMATIC vs. OPPORTUNISTIC) > > I am unsure of the second default because I don't understand the > 'whitespace' thing yet. I think it should be YES. That makes the current behaviour the default. So if the answers to those questions are (in order): N-- -> NEVER (if the first is N, the other two are greyed out) YN- -> MANUAL (if the first two are YN, the third is greyed out) YYN -> OPPORTUNISTIC (the default) YYY -> ALWAYS That seems sensible to me. For bonus points, it should be configurable both globally, and on a per-contact basis. ;-) - Ian From evan.s at dreskin.net Thu Jan 27 17:33:57 2005 From: evan.s at dreskin.net (Evan Schoenberg) Date: Thu, 27 Jan 2005 16:33:57 -0600 Subject: [OTR-dev] OTR encryption state In-Reply-To: <20050127222216.GR1060@smtp.paip.net> References: <20050126210740.DF8961F68@fnord.ir.bbn.com> <20050127143620.GC1060@smtp.paip.net> <4172F8EF-70A9-11D9-8D4E-000A95685E80@dreskin.net> <20050127222216.GR1060@smtp.paip.net> Message-ID: <88A9669A-70B3-11D9-8D4E-000A95685E80@dreskin.net> That's brilliant :) On Jan 27, 2005, at 4:22 PM, Ian Goldberg wrote: > On Thu, Jan 27, 2005 at 03:20:23PM -0600, Evan Schoenberg wrote: >>> OPPORTUNISTIC: (the current mode) probe the other side with the >>> whitespace tag, and reply to any indication that he >>> speaks OTR with a Key Exchange Message (if we're not >>> already private) >>> >> How does the "whitespace tag" work? Do all contacts I speak with >> which >> don't have OTR receive an IM from me every time I start a chat? This >> doesn't seem to be the case.. but it's the current mode. > > It's the clever thing suggested by Gregory Maxwell. The first time you > send a message to someone, append a magic pattern of whitespace. OTR > clients recognize the whitespace at the end of the message, and > opportunistically start OTR. It's just meant as a more invisible > (and automatic) version of the OTR Query message. > > So in OPPORTUNISTIC mode, if you send any old message to someone who > speaks OTR (and is also in OPPORTUNISTIC mode), OTR will start. > >>> MANUAL: Don't send the whitespace tag, and don't reply to one you >>> receive. Respond to explicit OTR Query Messages and Key >>> Exchange >>> Messages, but not other indications of OTR. This mode is >>> useful if you for some reason want to communicate in the >>> clear, even though you know the other guy speaks OTR, and >>> also allow either side to start a private conversation >>> at any time. [If you don't want to allow that last >>> condition, use NEVER instead.] >> This seems more like the current mode to me. How would it differ from >> current behavior? > > MANUAL only starts OTR in response to explicit requests to do so. > OPPORTUNISTIC (the current mode) starts OTR in response to any > indication the other side speaks OTR, including the whitespace tag and > OTR Error messages. > > - Ian > _______________________________________________ > OTR-dev mailing list > OTR-dev at lists.cypherpunks.ca > http://lists.cypherpunks.ca/mailman/listinfo/otr-dev > From evan.s at dreskin.net Thu Jan 27 17:40:06 2005 From: evan.s at dreskin.net (Evan Schoenberg) Date: Thu, 27 Jan 2005 16:40:06 -0600 Subject: [OTR-dev] OTR encryption state In-Reply-To: <20050127222832.GS1060@smtp.paip.net> References: <20050126210740.DF8961F68@fnord.ir.bbn.com> <20050127143620.GC1060@smtp.paip.net> <4172F8EF-70A9-11D9-8D4E-000A95685E80@dreskin.net> <20050127222832.GS1060@smtp.paip.net> Message-ID: <64820765-70B4-11D9-8D4E-000A95685E80@dreskin.net> Oh, of course; it could be no other way ;) On Jan 27, 2005, at 4:28 PM, Ian Goldberg wrote: > That seems sensible to me. For bonus points, it should be configurable > both globally, and on a per-contact basis. ;-) From ian at cypherpunks.ca Thu Jan 27 17:51:32 2005 From: ian at cypherpunks.ca (Ian Goldberg) Date: Thu, 27 Jan 2005 17:51:32 -0500 Subject: [OTR-dev] Secure connections through a connect/disconnect cycle, OTR error messages In-Reply-To: References: <20050127181418.GF1060@smtp.paip.net> <20050127203544.GJ1060@smtp.paip.net> <7456CF2C-70A6-11D9-8D4E-000A95685E80@dreskin.net> <20050127211517.GO1060@smtp.paip.net> <53EFA304-70AA-11D9-8D4E-000A95685E80@dreskin.net> <20050127220623.GQ1060@smtp.paip.net> Message-ID: <20050127225132.GV1060@smtp.paip.net> On Thu, Jan 27, 2005 at 04:20:33PM -0600, Evan Schoenberg wrote: > >But it *is* a message that's sent as if you typed it, whether the UI or > >libotr does it. Every (inline) message from OTR looks as if the other > >user typed it, since that's the only way to deliver inline messages. > > > Which is a situation that I've been saying in several different threads > should change. That's not the only way to deliver inline messages. > For a client which can only display an inline message as an incoming > message, it can implement the inform_error callback to simply call the > inform_message callback. For a client which can differentiate and > still be inline... such as Gaim and Adium... it can provide a better > user experience by having the chance to handle the inline error > differently. So I'm getting what you're saying. libotr should, when it receives an IM, look at its contents to decide if it's really a "control" message, and if so, display it with a new callback instead of returning it. Is that right? > >The first attempt had this very problem. > Hm. Okay, what if the UI had a callback which could let the library > know if the user is available for heartbeats and conversation closed > messages? If the information is unavailable, the UI just returns NO, > and we proceed as we do at present... but if the information is > available (in Gaim, it's an easy check to find out if a given > username/account/protocol combination is available, and in Adium > similarly) then we can do the better behavior without running into the > problem of sending messages to offline contacts. I'm pretty sure gaim doesn't provide this functionality, because that's where I ran into the problem with the heartbeats. For example, if you're talking with someone on AIM who's not in your (server-side) buddy list, the AIM network won't deliver you "logged out" messages, so you have no way of knowing he's gone. But if you try to send him a message, you'll get thwacked with an "Undeliverable message" error. - Ian From verbal at gmail.com Thu Jan 27 18:06:44 2005 From: verbal at gmail.com (verbal) Date: Thu, 27 Jan 2005 15:06:44 -0800 Subject: [OTR-dev] OTR encryption state In-Reply-To: <20050127222216.GR1060@smtp.paip.net> References: <20050126210740.DF8961F68@fnord.ir.bbn.com> <20050127143620.GC1060@smtp.paip.net> <4172F8EF-70A9-11D9-8D4E-000A95685E80@dreskin.net> <20050127222216.GR1060@smtp.paip.net> Message-ID: > It's the clever thing suggested by Gregory Maxwell. The first time you > send a message to someone, append a magic pattern of whitespace. OTR > clients recognize the whitespace at the end of the message, and > opportunistically start OTR. It's just meant as a more invisible > (and automatic) version of the OTR Query message. > so i was messaging someone on regular windows aol im client and i decided to see what would happen if i just tried to start an OTR conversation. she said it complained that aim said she didnt have the plugin for OTR which is fine, but then subsequent messages received from me had white spaces in it. it didnt stop until i restarted my client. =\ verbal From evan.s at dreskin.net Thu Jan 27 18:07:53 2005 From: evan.s at dreskin.net (Evan Schoenberg) Date: Thu, 27 Jan 2005 17:07:53 -0600 Subject: [OTR-dev] Secure connections through a connect/disconnect cycle, OTR error messages In-Reply-To: <20050127225132.GV1060@smtp.paip.net> References: <20050127181418.GF1060@smtp.paip.net> <20050127203544.GJ1060@smtp.paip.net> <7456CF2C-70A6-11D9-8D4E-000A95685E80@dreskin.net> <20050127211517.GO1060@smtp.paip.net> <53EFA304-70AA-11D9-8D4E-000A95685E80@dreskin.net> <20050127220623.GQ1060@smtp.paip.net> <20050127225132.GV1060@smtp.paip.net> Message-ID: <45F01740-70B8-11D9-8D4E-000A95685E80@dreskin.net> On Jan 27, 2005, at 4:51 PM, Ian Goldberg wrote: >> > > So I'm getting what you're saying. libotr should, when it receives an > IM, look at its contents to decide if it's really a "control" message, > and if so, display it with a new callback instead of returning it. > > Is that right? > Precisely. =) > I'm pretty sure gaim doesn't provide this functionality, because that's > where I ran into the problem with the heartbeats. For example, if > you're talking with someone on AIM who's not in your (server-side) > buddy > list, the AIM network won't deliver you "logged out" messages, so you > have no way of knowing he's gone. But if you try to send him a > message, > you'll get thwacked with an "Undeliverable message" error. > Grrr, I'd forgotten about that annoying AIM bug. There's some way it can be done... The official AIM client manages to give connected/disconnect messages I believe. I'll check into that... besides 'stranger' AIM contacts, Gaim could provide what would be needed. Come to think of it, though, there's no GaimBuddy* returned by gaim_find_buddy() for strangers like that; it just returns NULL... so given username/protocol/account, gaim can reliably tell you either Yes or Maybe. And the current behavior could still be done in the Maybe case. -Evan > - Ian > _______________________________________________ > OTR-dev mailing list > OTR-dev at lists.cypherpunks.ca > http://lists.cypherpunks.ca/mailman/listinfo/otr-dev > From ian at cypherpunks.ca Fri Jan 28 08:53:37 2005 From: ian at cypherpunks.ca (Ian Goldberg) Date: Fri, 28 Jan 2005 08:53:37 -0500 Subject: [OTR-dev] OTR encryption state In-Reply-To: <64820765-70B4-11D9-8D4E-000A95685E80@dreskin.net> References: <20050126210740.DF8961F68@fnord.ir.bbn.com> <20050127143620.GC1060@smtp.paip.net> <4172F8EF-70A9-11D9-8D4E-000A95685E80@dreskin.net> <20050127222832.GS1060@smtp.paip.net> <64820765-70B4-11D9-8D4E-000A95685E80@dreskin.net> Message-ID: <20050128135337.GX1060@smtp.paip.net> On Thu, Jan 27, 2005 at 04:40:06PM -0600, Evan Schoenberg wrote: > Oh, of course; it could be no other way ;) Do you know if gaim has a built-in API for handling per-buddy preferences? - Ian From ian at cypherpunks.ca Fri Jan 28 09:00:26 2005 From: ian at cypherpunks.ca (Ian Goldberg) Date: Fri, 28 Jan 2005 09:00:26 -0500 Subject: [OTR-dev] OTR encryption state In-Reply-To: References: <20050126210740.DF8961F68@fnord.ir.bbn.com> <20050127143620.GC1060@smtp.paip.net> <4172F8EF-70A9-11D9-8D4E-000A95685E80@dreskin.net> <20050127222216.GR1060@smtp.paip.net> Message-ID: <20050128140026.GY1060@smtp.paip.net> On Thu, Jan 27, 2005 at 03:06:44PM -0800, verbal wrote: > > It's the clever thing suggested by Gregory Maxwell. The first time you > > send a message to someone, append a magic pattern of whitespace. OTR > > clients recognize the whitespace at the end of the message, and > > opportunistically start OTR. It's just meant as a more invisible > > (and automatic) version of the OTR Query message. > > > > so i was messaging someone on regular windows aol im client and i > decided to see what would happen if i just tried to start an OTR > conversation. she said it complained that aim said she didnt have the > plugin for OTR which is fine, but then subsequent messages received > from me had white spaces in it. it didnt stop until i restarted my > client. =\ The whitespace should stop when she sends you back a non-OTR message. If that's not what happened, can you replicate the problem? - Ian From evan.schoenberg at vanderbilt.edu Thu Jan 27 17:20:55 2005 From: evan.schoenberg at vanderbilt.edu (Evan Schoenberg) Date: Thu, 27 Jan 2005 16:20:55 -0600 Subject: [OTR-dev] OPPORTUNISTIC: Problems with not using OTR when both sides have an OTR plugin Message-ID: Opportunistic is overzealous right now, I think, or I've got something configured wrong. 10 Bob and Jane both have OTR. Bob messages Jane. His OTR is immediately active, since the other side has it. Jane refuses Bob's fingerprint.. she's just not ready for that kind of commitment. 20 Bob's client thinks he has a secure connection. Messages he sends are encrypted. 30 Jane's client knows she has an unencrypted connection. She sends in plaintext, and can't read Bob's messages. 40 Bob is told that he is sending encrypted messages, so he toggles the "end private chat" and sends a message. It goes through in plaintext... Jane is asked to accept his fingerprint, she clicks No again. GOTO 20 Does this describe expected behavior? I'm not sure if the proposed policy system solves for this cleanly or not. -Evan From ian at cypherpunks.ca Fri Jan 28 09:09:58 2005 From: ian at cypherpunks.ca (Ian Goldberg) Date: Fri, 28 Jan 2005 09:09:58 -0500 Subject: [OTR-dev] OPPORTUNISTIC: Problems with not using OTR when both sides have an OTR plugin In-Reply-To: References: Message-ID: <20050128140958.GZ1060@smtp.paip.net> On Thu, Jan 27, 2005 at 04:20:55PM -0600, Evan Schoenberg wrote: > Opportunistic is overzealous right now, I think, or I've got something > configured wrong. > > 10 Bob and Jane both have OTR. Bob messages Jane. His OTR is > immediately active, since the other side has it. Jane refuses Bob's > fingerprint.. she's just not ready for that kind of commitment. > > 20 Bob's client thinks he has a secure connection. Messages he sends > are encrypted. > 30 Jane's client knows she has an unencrypted connection. She sends in > plaintext, and can't read Bob's messages. > > 40 Bob is told that he is sending encrypted messages, so he toggles the > "end private chat" and sends a message. It goes through in > plaintext... Jane is asked to accept his fingerprint, she clicks No > again. GOTO 20 > > Does this describe expected behavior? I'm not sure if the proposed > policy system solves for this cleanly or not. Yes, that's the expected behaviour. Bob's client is trying very hard to start an OTR session with Jane's client, which does in fact speak OTR. The fact that Jane wants OTR installed, but doesn't want to OTR with Bob in particular, is exactly the kind of thing the per-buddy policy system will handle. (Jane sets her OTR policy for Bob to NEVER, or Bob can set his for Jane to MANUAL.) - Ian From ian at cypherpunks.ca Fri Jan 28 11:15:00 2005 From: ian at cypherpunks.ca (Ian Goldberg) Date: Fri, 28 Jan 2005 11:15:00 -0500 Subject: [OTR-dev] OTR encryption state In-Reply-To: <20050128135337.GX1060@smtp.paip.net> References: <20050126210740.DF8961F68@fnord.ir.bbn.com> <20050127143620.GC1060@smtp.paip.net> <4172F8EF-70A9-11D9-8D4E-000A95685E80@dreskin.net> <20050127222832.GS1060@smtp.paip.net> <64820765-70B4-11D9-8D4E-000A95685E80@dreskin.net> <20050128135337.GX1060@smtp.paip.net> Message-ID: <20050128161500.GA1060@smtp.paip.net> On Fri, Jan 28, 2005 at 08:53:37AM -0500, Ian Goldberg wrote: > On Thu, Jan 27, 2005 at 04:40:06PM -0600, Evan Schoenberg wrote: > > Oh, of course; it could be no other way ;) > > Do you know if gaim has a built-in API for handling per-buddy > preferences? Ah, I found it. gaim_blist_node_set_{bool,string,int}. And there's even a hook for adding things (like the OTR conf panel) to the menu when you right-click on a buddy in the buddy list. So it's all good. I'm a little worried about *where* the global OTR conf will go: there's not a lot of room in that panel. Three cascaded checkboxes will take up quite a bit of space. Anyone have suggestions, here? - Ian From tclarke at ball.com Fri Jan 28 12:48:17 2005 From: tclarke at ball.com (Clarke, Trevor) Date: Fri, 28 Jan 2005 12:48:17 -0500 Subject: [OTR-dev] Initial Python wrappers Message-ID: <873043AF54FE794B912B616ABA7E9FE5067A6D@daytonmsg2k3.AERO.BALL.COM> I've put together some Python wrappers for libotr. They use SWIG and work with any recent version of Python. These wrappers are alpha and there will be some changes to the interface as I tune it but they work as they are. I've included a python script to demonstrate their usage. Try them out, play with them, send me bug fixes. You can find them at http://continuity.notcows.com/~retrev/PyOTR ------------------------------ Trevor R.H. Clarke tclarke at ball com Ball Aerospace & Technologies Corp -------------- next part -------------- An HTML attachment was scrubbed... URL: From ian at cypherpunks.ca Fri Jan 28 14:25:04 2005 From: ian at cypherpunks.ca (Ian Goldberg) Date: Fri, 28 Jan 2005 14:25:04 -0500 Subject: [OTR-dev] anything else for the libotr 2.0.0 API? Message-ID: <20050128192504.GB1060@smtp.paip.net> You can see the libotr CVS snapshot in the usual place: http://www.cypherpunks.ca/otr/libotr-cvs-latest.tar.gz Here's the ChangeLog so far (since 1.0.4). The new callbacks aren't tested yet, since that will require changes to gaim-otr. :-) So: do people have more requests for the libotr 2.0.0 API? - Ian * src/message.h: New callback for fetching OTR policy * src/message.c (otrl_message_sending): Create a ConnContext if we don't have one already. Use it to fetch the OTR policy. Just return if the policy is NEVER. Only append the whitespace tag if the policy is OPPORTUNISTIC or ALWAYS. Don't send unencrypted messages in ALWAYS, but store them for retransmission later. * src/message.c (otrl_message_receiving): Fetch the OTR policy. Just return if the policy is NEVER. Only send a Key Exchange Message in response to an unexpected Data or Error Message in OPPORTUNISTIC and ALWAYS. Only recognize the whitespace tag in OPPORTUNISTIC and ALWAYS. * src/message.h: * src/message.c: add accountname/protocol/username parameters to notify callback * src/message.h: * src/message.c: add display_otr_message callback for displaying OTR control messages * src/privkey.h: #include since we use things from libgcrypt in the .h file * src/proto.h: * src/proto.c: Make otrl_init take unsigned ints as arguments. * src/context.h: * src/context.c: * src/message.c: * src/proto.c: Keep track of the last message sent, and potentially resend it if sending it the first time triggered a rekey (because the other side had lost its OTR state, for example). * packaging/debian/control: Changed debian package names to libotr1 and libotr1-dev. * libotr.m4: Added copyright notice, more comments * src/userstate.c: * src/userstate.h: New files * src/Makefile.am: Added -Wall to default CFLAGS * toolkit/Makefile.am: Added -Wall to default CFLAGS * src/context.c (otrl_context_find, otrl_context_forget_all): * src/context.h (otrl_context_find, otrl_context_forget_all): * src/message.c (otrl_message_sending, process_kem) (process_confresp, otrl_message_receiving): * src/message.h (otrl_message_sending, otrl_message_receiving) (OtrlMessageAppOps.confirm_fingerprint): * src/privkey.c (otrl_privkey_fingerprint, otrl_privkey_read) (otrl_privkey_generate, otrl_privkey_read_fingerprints) (otrl_privkey_write_fingerprints, otrl_privkey_find) (otrl_privkey_forget_all): * src/privkey.h (otrl_privkey_fingerprint, otrl_privkey_read) (otrl_privkey_generate, otrl_privkey_read_fingerprints) (otrl_privkey_write_fingerprints, otrl_privkey_find) (otrl_privkey_forget_all): * src/proto.c (otrl_proto_create_key_exchange) (otrl_proto_accept_key_exchange): * src/proto.h (otrl_proto_create_key_exchange) (otrl_proto_accept_key_exchange): Added OtrlUserState parameter to many calls, eliminating global state. * src/privkey.c (otrl_privkey_fingerprint): the buffer is now passed in, and not static * src/version.h: bumped version number to 2.0.0 because API changed incompatibly * configure.ac: bumped version number to 2.0.0 because API changed incompatibly * src/message.h: added accountname parameter to confirm_fingerprint callback * src/message.c: passed accountname to confirm_fingerprint callback * libotr.m4: new file * Makefile.am: install (and uninstall) new libotr.m4 file * tools/Makefile.am: clean up manpage symlinks and add an uninstall rule * src/proto.h: moved numeric version defines into version.h * src/version.h: moved numeric version defines into version.h * src/message.c (otrl_message_receiving): Update the context list if we create a new context From mid at zigamorph.net Fri Jan 28 14:36:58 2005 From: mid at zigamorph.net (Adam Fritzler) Date: Fri, 28 Jan 2005 11:36:58 -0800 Subject: [OTR-dev] anything else for the libotr 2.0.0 API? In-Reply-To: <20050128192504.GB1060@smtp.paip.net> References: <20050128192504.GB1060@smtp.paip.net> Message-ID: <20050128193658.GC5342@zigamorph.net> In the ALWAYS case, what happens if there's more than one attempt to send a message before negotiation completes? It looks like it's silently lost, which there should at least be a warning about. asf. On Fri, Jan 28, 2005 at 02:25:04PM -0500, Ian Goldberg wrote: > You can see the libotr CVS snapshot in the usual place: > > http://www.cypherpunks.ca/otr/libotr-cvs-latest.tar.gz > > Here's the ChangeLog so far (since 1.0.4). The new callbacks aren't > tested yet, since that will require changes to gaim-otr. :-) > > So: do people have more requests for the libotr 2.0.0 API? > > - Ian > > * src/message.h: New callback for fetching OTR policy > * src/message.c (otrl_message_sending): Create a ConnContext if > we don't have one already. Use it to fetch the OTR policy. > Just return if the policy is NEVER. Only append the whitespace > tag if the policy is OPPORTUNISTIC or ALWAYS. Don't send > unencrypted messages in ALWAYS, but store them for > retransmission later. > * src/message.c (otrl_message_receiving): Fetch the OTR policy. > Just return if the policy is NEVER. Only send a Key Exchange > Message in response to an unexpected Data or Error Message in > OPPORTUNISTIC and ALWAYS. Only recognize the whitespace tag in > OPPORTUNISTIC and ALWAYS. From ian at cypherpunks.ca Fri Jan 28 15:33:26 2005 From: ian at cypherpunks.ca (Ian Goldberg) Date: Fri, 28 Jan 2005 15:33:26 -0500 Subject: [OTR-dev] anything else for the libotr 2.0.0 API? In-Reply-To: <20050128193658.GC5342@zigamorph.net> References: <20050128192504.GB1060@smtp.paip.net> <20050128193658.GC5342@zigamorph.net> Message-ID: <20050128203326.GC1060@smtp.paip.net> On Fri, Jan 28, 2005 at 11:36:58AM -0800, Adam Fritzler wrote: > > In the ALWAYS case, what happens if there's more than one attempt to > send a message before negotiation completes? It looks like it's > silently lost, which there should at least be a warning about. That seems reasonable. How about this: --- message.c 28 Jan 2005 19:12:41 -0000 1.9 +++ message.c 28 Jan 2005 20:35:29 -0000 @@ -115,7 +115,45 @@ if (policy == OTRL_POLICY_ALWAYS && context->state != CONN_CONNECTED) { /* We're trying to send an unencrypted message with policy * ALWAYS. Don't do that, but try to start up OTR instead. */ - gcry_free(context->lastmessage); + if (context->lastmessage) { + gcry_free(context->lastmessage); + if (ops->notify) { + const char *format = "You attempted to send another " + "unencrypted message to %s"; + char *primary = malloc(strlen(format) + strlen(recipient) - 1); + if (primary) { + sprintf(primary, format, recipient); + ops->notify(opdata, OTRL_NOTIFY_ERROR, accountname, + protocol, recipient, "OTR Policy Violation", + primary, + "Unencrypted messages to this recipient are not " + "allowed. Attempting to start a private " + "conversation.\n\nYour message will be " + "retransmitted when the private conversation " + "starts, but the previously saved message has " + "been discarded."); + free(primary); + } + } + } else { + if (ops->notify) { + const char *format = "You attempted to send an " + "unencrypted message to %s"; + char *primary = malloc(strlen(format) + strlen(recipient) - 1); + if (primary) { + sprintf(primary, format, recipient); + ops->notify(opdata, OTRL_NOTIFY_WARNING, accountname, + protocol, recipient, "OTR Policy Violation", + primary, + "Unencrypted messages to this recipient are not " + "allowed. Attempting to start a private " + "conversation.\n\nYour message will be " + "retransmitted when the private conversation " + "starts."); + free(primary); + } + } + } context->lastmessage = gcry_malloc_secure(strlen(message) + 1); if (context->lastmessage) { strcpy(context->lastmessage, message); From mid at zigamorph.net Fri Jan 28 15:56:47 2005 From: mid at zigamorph.net (Adam Fritzler) Date: Fri, 28 Jan 2005 12:56:47 -0800 Subject: [OTR-dev] anything else for the libotr 2.0.0 API? In-Reply-To: <20050128203326.GC1060@smtp.paip.net> References: <20050128192504.GB1060@smtp.paip.net> <20050128193658.GC5342@zigamorph.net> <20050128203326.GC1060@smtp.paip.net> Message-ID: <20050128205646.GD5342@zigamorph.net> Looks fine... asf. On Fri, Jan 28, 2005 at 03:33:26PM -0500, Ian Goldberg wrote: > On Fri, Jan 28, 2005 at 11:36:58AM -0800, Adam Fritzler wrote: > > > > In the ALWAYS case, what happens if there's more than one attempt to > > send a message before negotiation completes? It looks like it's > > silently lost, which there should at least be a warning about. > > That seems reasonable. How about this: > --- message.c 28 Jan 2005 19:12:41 -0000 1.9 > +++ message.c 28 Jan 2005 20:35:29 -0000 From verbal at smashedstacks.net Sat Jan 29 15:36:19 2005 From: verbal at smashedstacks.net (verbal) Date: Sat, 29 Jan 2005 12:36:19 -0800 Subject: [OTR-dev] new email address Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 hi everyone, just wanted to let you guys know that i will be using this email address for OTR from now on. so if there are any lingering threads i'm cc-ed on, please change to this email addr. thanks, verbal key: http://www.smashedstacks.net/verbal.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFB+/PHyyX3y0TuvsIRAtBrAJ9KTxMG7RZyHMNOp98gR3r0CRCqSgCg2/mq b5UcL9YcriTemhSNXsasUwI= =+C/S -----END PGP SIGNATURE----- From ian at cypherpunks.ca Sun Jan 30 11:03:00 2005 From: ian at cypherpunks.ca (Ian Goldberg) Date: Sun, 30 Jan 2005 11:03:00 -0500 Subject: [OTR-dev] user has stopped OTR message Message-ID: <20050130160300.GA24205@smtp.paip.net> So there's now support in libotr for the is_logged_in callback, and there's a call which checks that, and if it says yes, sends a message to the other side (in the private channel) saying the user has terminated his side of the OTR conversation. It then proceeds to terminate it. Upon receiving such messages, libotr uses the display_otr_message callback to show it. [gaim-otr now does this in a sensible way, too.] Question: what exactly should the text of the above message be? It will be shown as: OTR [otheruser]: something goes here in the conversation window. So, what "goes here"? I tried "The private conversation with you has ended.", but that's not quite right, since your (the receiver's) side *is* still private. We want the message to convey (concisely) that the other side has ended his private connection with you, and you probably should as well. Also, for Evan: you mentioned that gaim should be able to produce sensible yes/no/don't-know answers to the is_logged_in question. Can you supply some code for that? /* Report whether you think the given user is online. Return 1 if * you think he is, 0 if you think he isn't, -1 if you're not sure. * * If you return 1, messages such as heartbeats or other * notifications may be sent to the user, which could result in "not * logged in" errors if you're wrong. */ int (*is_logged_in)(void *opdata, const char *accountname, const char *protocol, const char *recipient); Thanks, - Ian From ian at cypherpunks.ca Sun Jan 30 11:16:13 2005 From: ian at cypherpunks.ca (Ian Goldberg) Date: Sun, 30 Jan 2005 11:16:13 -0500 Subject: [OTR-dev] user has stopped OTR message In-Reply-To: <20050130160300.GA24205@smtp.paip.net> References: <20050130160300.GA24205@smtp.paip.net> Message-ID: <20050130161613.GB24205@smtp.paip.net> On Sun, Jan 30, 2005 at 11:03:00AM -0500, Ian Goldberg wrote: > Also, for Evan: you mentioned that gaim should be able to produce > sensible yes/no/don't-know answers to the is_logged_in question. Can > you supply some code for that? > > /* Report whether you think the given user is online. Return 1 if > * you think he is, 0 if you think he isn't, -1 if you're not sure. > * > * If you return 1, messages such as heartbeats or other > * notifications may be sent to the user, which could result in "not > * logged in" errors if you're wrong. */ > int (*is_logged_in)(void *opdata, const char *accountname, > const char *protocol, const char *recipient); Ah, never mind. I think this should do it: static int is_logged_in_cb(void *opdata, const char *accountname, const char *protocol, const char *recipient) { GaimAccount *account; GaimBuddy *buddy; account = gaim_accounts_find(accountname, protocol); if (!account) return -1; buddy = gaim_find_buddy(account, recipient); if (!buddy) return -1; return (buddy->present == GAIM_BUDDY_ONLINE); } - Ian From evan.s at dreskin.net Sun Jan 30 14:20:34 2005 From: evan.s at dreskin.net (Evan Schoenberg) Date: Sun, 30 Jan 2005 13:20:34 -0600 Subject: [OTR-dev] user has stopped OTR message In-Reply-To: <20050130161613.GB24205@smtp.paip.net> References: <20050130160300.GA24205@smtp.paip.net> <20050130161613.GB24205@smtp.paip.net> Message-ID: <03D179A8-72F4-11D9-8D4E-000A95685E80@dreskin.net> That's what I would have replied if you hadn't beat me to it. :) On Jan 30, 2005, at 10:16 AM, Ian Goldberg wrote: > > Ah, never mind. I think this should do it: > > static int is_logged_in_cb(void *opdata, const char *accountname, > const char *protocol, const char *recipient) > { > GaimAccount *account; > GaimBuddy *buddy; > > account = gaim_accounts_find(accountname, protocol); > if (!account) return -1; > > buddy = gaim_find_buddy(account, recipient); > if (!buddy) return -1; > > return (buddy->present == GAIM_BUDDY_ONLINE); > } > > - Ian > _______________________________________________ > OTR-dev mailing list > OTR-dev at lists.cypherpunks.ca > http://lists.cypherpunks.ca/mailman/listinfo/otr-dev > From evan.s at dreskin.net Sun Jan 30 14:23:27 2005 From: evan.s at dreskin.net (Evan Schoenberg) Date: Sun, 30 Jan 2005 13:23:27 -0600 Subject: [OTR-dev] OTR encryption state In-Reply-To: <20050128161500.GA1060@smtp.paip.net> References: <20050126210740.DF8961F68@fnord.ir.bbn.com> <20050127143620.GC1060@smtp.paip.net> <4172F8EF-70A9-11D9-8D4E-000A95685E80@dreskin.net> <20050127222832.GS1060@smtp.paip.net> <64820765-70B4-11D9-8D4E-000A95685E80@dreskin.net> <20050128135337.GX1060@smtp.paip.net> <20050128161500.GA1060@smtp.paip.net> Message-ID: <6AF9ACFC-72F4-11D9-8D4E-000A95685E80@dreskin.net> On Jan 28, 2005, at 10:15 AM, Ian Goldberg wrote: > I'm a little worried about *where* the global OTR conf will go: there's > not a lot of room in that panel. Three cascaded checkboxes will take > up > quite a bit of space. > > Anyone have suggestions, here? Perhaps could save some space like so: [ ] Use encrypted messaging [ DROPDOWN MENU ] where dropdown has the options - only when requested - automatically - and refuse unencrypted messages So an enable/disable checkbox and 3 sentence completions selectable via the dropdown menu. Thoughts? -Evan From ian at cypherpunks.ca Sun Jan 30 16:52:16 2005 From: ian at cypherpunks.ca (Ian Goldberg) Date: Sun, 30 Jan 2005 16:52:16 -0500 Subject: [OTR-dev] OTR encryption state In-Reply-To: <6AF9ACFC-72F4-11D9-8D4E-000A95685E80@dreskin.net> References: <20050126210740.DF8961F68@fnord.ir.bbn.com> <20050127143620.GC1060@smtp.paip.net> <4172F8EF-70A9-11D9-8D4E-000A95685E80@dreskin.net> <20050127222832.GS1060@smtp.paip.net> <64820765-70B4-11D9-8D4E-000A95685E80@dreskin.net> <20050128135337.GX1060@smtp.paip.net> <20050128161500.GA1060@smtp.paip.net> <6AF9ACFC-72F4-11D9-8D4E-000A95685E80@dreskin.net> Message-ID: <20050130215216.GC24205@smtp.paip.net> On Sun, Jan 30, 2005 at 01:23:27PM -0600, Evan Schoenberg wrote: > > On Jan 28, 2005, at 10:15 AM, Ian Goldberg wrote: > > >I'm a little worried about *where* the global OTR conf will go: there's > >not a lot of room in that panel. Three cascaded checkboxes will take > >up > >quite a bit of space. > > > >Anyone have suggestions, here? > > Perhaps could save some space like so: > > [ ] Use encrypted messaging [ DROPDOWN MENU ] Actually, Kat had the helpful suggestion of putting tabs on the prefs page. Now there's one tab for known fingerprints, and one for config, which includes the private keys and the global OTR settings. This has the advantage that the global settings look just the same as the per-buddy settings. - Ian From ian at cypherpunks.ca Sun Jan 30 19:05:49 2005 From: ian at cypherpunks.ca (Ian Goldberg) Date: Sun, 30 Jan 2005 19:05:49 -0500 Subject: [OTR-dev] 2.0.0 pre-releases coming soon Message-ID: <20050131000549.GD24205@smtp.paip.net> If you'd like to see snapshots of what's coming in 2.0.0 (both libotr and gaim-otr), check out: http://www.cypherpunks.ca/otr/libotr-cvs-latest.tar.gz http://www.cypherpunks.ca/otr/gaim-otr-cvs-latest.tar.gz If anyone has any more requests for 2.0.0, now's the time to speak up. Sometime this week, we'll put together 1.99.99 packages for people to bang on for a short while, and then 2.0.0 a little later, assuming all goes well with the banging. - Ian From evan.s at dreskin.net Sun Jan 30 19:42:23 2005 From: evan.s at dreskin.net (Evan Schoenberg) Date: Sun, 30 Jan 2005 18:42:23 -0600 Subject: [OTR-dev] 2.0.0 pre-releases coming soon In-Reply-To: <20050131000549.GD24205@smtp.paip.net> References: <20050131000549.GD24205@smtp.paip.net> Message-ID: This is somewhat selfish... but I would rather use Adium's own preferences system for the global and per-buddy OTR policy setting than use Gaim's preferences system. Would you accept a patch to move the preference loading into gtk-ui.c and have a UI ops callback for it? -Evan On Jan 30, 2005, at 6:05 PM, Ian Goldberg wrote: > If you'd like to see snapshots of what's coming in 2.0.0 (both libotr > and gaim-otr), check out: > > http://www.cypherpunks.ca/otr/libotr-cvs-latest.tar.gz > http://www.cypherpunks.ca/otr/gaim-otr-cvs-latest.tar.gz > > If anyone has any more requests for 2.0.0, now's the time to speak up. > Sometime this week, we'll put together 1.99.99 packages for people to > bang on for a short while, and then 2.0.0 a little later, assuming all > goes well with the banging. > > - Ian > _______________________________________________ > OTR-dev mailing list > OTR-dev at lists.cypherpunks.ca > http://lists.cypherpunks.ca/mailman/listinfo/otr-dev > From ian at cypherpunks.ca Sun Jan 30 19:46:51 2005 From: ian at cypherpunks.ca (Ian Goldberg) Date: Sun, 30 Jan 2005 19:46:51 -0500 Subject: [OTR-dev] 2.0.0 pre-releases coming soon In-Reply-To: References: <20050131000549.GD24205@smtp.paip.net> Message-ID: <20050131004651.GE24205@smtp.paip.net> On Sun, Jan 30, 2005 at 06:42:23PM -0600, Evan Schoenberg wrote: > This is somewhat selfish... but I would rather use Adium's own > preferences system for the global and per-buddy OTR policy setting than > use Gaim's preferences system. Would you accept a patch to move the > preference loading into gtk-ui.c and have a UI ops callback for it? Sure. Send it on. - Ian From evan.s at dreskin.net Sun Jan 30 21:07:25 2005 From: evan.s at dreskin.net (Evan Schoenberg) Date: Sun, 30 Jan 2005 20:07:25 -0600 Subject: [OTR-dev] 2.0.0 pre-releases coming soon In-Reply-To: <20050131004651.GE24205@smtp.paip.net> References: <20050131000549.GD24205@smtp.paip.net> <20050131004651.GE24205@smtp.paip.net> Message-ID: Attached. As before, I can't compile the GTK part, so apologies if it has errors. Let me know if there are any problems. -------------- next part -------------- A non-text attachment was scrubbed... Name: prefs-to-ui-ops.diff Type: application/octet-stream Size: 10827 bytes Desc: not available URL: -------------- next part -------------- Also attached is a one-line diff squelching a compiler warning I received in otr-plugin.c. -------------- next part -------------- A non-text attachment was scrubbed... Name: warning-squelch.diff Type: application/octet-stream Size: 317 bytes Desc: not available URL: -------------- next part -------------- Both of these are against the cvs snapshot at http://www.cypherpunks.ca/otr/gaim-otr-cvs-latest.tar.gz -Evan On Jan 30, 2005, at 6:46 PM, Ian Goldberg wrote: > On Sun, Jan 30, 2005 at 06:42:23PM -0600, Evan Schoenberg wrote: >> This is somewhat selfish... but I would rather use Adium's own >> preferences system for the global and per-buddy OTR policy setting >> than >> use Gaim's preferences system. Would you accept a patch to move the >> preference loading into gtk-ui.c and have a UI ops callback for it? > > Sure. Send it on. > > - Ian > _______________________________________________ > OTR-dev mailing list > OTR-dev at lists.cypherpunks.ca > http://lists.cypherpunks.ca/mailman/listinfo/otr-dev > From evan.s at dreskin.net Sun Jan 30 23:38:46 2005 From: evan.s at dreskin.net (Evan Schoenberg) Date: Sun, 30 Jan 2005 22:38:46 -0600 Subject: [OTR-dev] 2.0.0 pre-releases coming soon In-Reply-To: <20050131000549.GD24205@smtp.paip.net> References: <20050131000549.GD24205@smtp.paip.net> Message-ID: Another minor modification to current source: there's no way to retrieve the OtrlUserState used by the plugin from code that isn't compiled immediately alongside otr-plugin.c. Could you please add to otr-plugin.c: OtrlUserState otr_plugin_get_userstate(void) { return otrg_plugin_userstate; } And to otr-plugin.h: /* Return the user state used by the gaim-otr plugin */ OtrlUserState otr_plugin_get_userstate(void); Without those, the Adium callbacks can no longer use the various context methods. Thanks, Evan On Jan 30, 2005, at 6:05 PM, Ian Goldberg wrote: > If you'd like to see snapshots of what's coming in 2.0.0 (both libotr > and gaim-otr), check out: > > http://www.cypherpunks.ca/otr/libotr-cvs-latest.tar.gz > http://www.cypherpunks.ca/otr/gaim-otr-cvs-latest.tar.gz > > If anyone has any more requests for 2.0.0, now's the time to speak up. > Sometime this week, we'll put together 1.99.99 packages for people to > bang on for a short while, and then 2.0.0 a little later, assuming all > goes well with the banging. > > - Ian > _______________________________________________ > OTR-dev mailing list > OTR-dev at lists.cypherpunks.ca > http://lists.cypherpunks.ca/mailman/listinfo/otr-dev > From evan.s at dreskin.net Mon Jan 31 01:15:23 2005 From: evan.s at dreskin.net (Evan Schoenberg) Date: Mon, 31 Jan 2005 00:15:23 -0600 Subject: [OTR-dev] 2.0.0 pre-releases coming soon In-Reply-To: References: <20050131000549.GD24205@smtp.paip.net> Message-ID: <143EB8BD-6ADE-44D9-84F9-9E66CB7DD381@dreskin.net> Erm, sorry, I think I meant: OtrlUserState* otr_plugin_get_userstate(void) { return &otrg_plugin_userstate; } and /* Return a pointer to the user state used by the gaim-otr plugin */ OtrlUserState* otr_plugin_get_userstate(void); On Jan 30, 2005, at 10:38 PM, Evan Schoenberg wrote: > Another minor modification to current source: there's no way to > retrieve the OtrlUserState used by the plugin from code that isn't > compiled immediately alongside otr-plugin.c. Could you please add to > otr-plugin.c: > > OtrlUserState otr_plugin_get_userstate(void) > { > return otrg_plugin_userstate; > } > > > And to otr-plugin.h: > > /* Return the user state used by the gaim-otr plugin */ > OtrlUserState otr_plugin_get_userstate(void); > > Without those, the Adium callbacks can no longer use the various > context methods. > > Thanks, > Evan > > On Jan 30, 2005, at 6:05 PM, Ian Goldberg wrote: > > >> If you'd like to see snapshots of what's coming in 2.0.0 (both libotr >> and gaim-otr), check out: >> >> http://www.cypherpunks.ca/otr/libotr-cvs-latest.tar.gz >> http://www.cypherpunks.ca/otr/gaim-otr-cvs-latest.tar.gz >> >> If anyone has any more requests for 2.0.0, now's the time to speak up. >> Sometime this week, we'll put together 1.99.99 packages for people to >> bang on for a short while, and then 2.0.0 a little later, assuming all >> goes well with the banging. >> >> - Ian >> _______________________________________________ >> OTR-dev mailing list >> OTR-dev at lists.cypherpunks.ca >> http://lists.cypherpunks.ca/mailman/listinfo/otr-dev >> > _______________________________________________ > OTR-dev mailing list > OTR-dev at lists.cypherpunks.ca > http://lists.cypherpunks.ca/mailman/listinfo/otr-dev > From gdt at ir.bbn.com Mon Jan 31 08:51:36 2005 From: gdt at ir.bbn.com (Greg Troxel) Date: 31 Jan 2005 08:51:36 -0500 Subject: [OTR-dev] user has stopped OTR message In-Reply-To: <20050130160300.GA24205@smtp.paip.net> References: <20050130160300.GA24205@smtp.paip.net> Message-ID: How about user has discarded OTR keys for this session But I think this should perhaps be a machine-parseable message within a signaling channeel, and the remote UI print this. -- Greg Troxel From ian at cypherpunks.ca Mon Jan 31 08:59:30 2005 From: ian at cypherpunks.ca (Ian Goldberg) Date: Mon, 31 Jan 2005 08:59:30 -0500 Subject: [OTR-dev] 2.0.0 pre-releases coming soon In-Reply-To: References: <20050131000549.GD24205@smtp.paip.net> Message-ID: <20050131135930.GG24205@smtp.paip.net> On Sun, Jan 30, 2005 at 10:38:46PM -0600, Evan Schoenberg wrote: > Another minor modification to current source: there's no way to > retrieve the OtrlUserState used by the plugin from code that isn't > compiled immediately alongside otr-plugin.c. Could you please add to > otr-plugin.c: > > OtrlUserState otr_plugin_get_userstate(void) > { > return otrg_plugin_userstate; > } But otrg_plugin_userstate is already exported by otr-plugin.h. Just reference the variable. - Ian From ian at cypherpunks.ca Mon Jan 31 09:17:43 2005 From: ian at cypherpunks.ca (Ian Goldberg) Date: Mon, 31 Jan 2005 09:17:43 -0500 Subject: [OTR-dev] 2.0.0 pre-releases coming soon In-Reply-To: References: <20050131000549.GD24205@smtp.paip.net> <20050131004651.GE24205@smtp.paip.net> Message-ID: <20050131141743.GH24205@smtp.paip.net> On Sun, Jan 30, 2005 at 08:07:25PM -0600, Evan Schoenberg wrote: > Attached. As before, I can't compile the GTK part, so apologies if it > has errors. Let me know if there are any problems. Wouldn't it be better to move the gaim-prefs-specific loads and saves to the gtk file, but leave the find_policy call alone? Won't you want to use the find_policy function as-is? > Also attached is a one-line diff squelching a compiler warning I > received in otr-plugin.c. I don't think this is valid; what's the warning? The switch statement already handles all possible values of the enumeration, and if the enumeration changes, *then* we want a compiler warning that you need to change something in the switch (which will be suppressed by the default:, which will in fact cause the wrong thing to happen). - Ian From ian at cypherpunks.ca Mon Jan 31 12:25:39 2005 From: ian at cypherpunks.ca (Ian Goldberg) Date: Mon, 31 Jan 2005 12:25:39 -0500 Subject: [OTR-dev] user has stopped OTR message In-Reply-To: References: <20050130160300.GA24205@smtp.paip.net> Message-ID: <20050131172539.GI24205@smtp.paip.net> On Mon, Jan 31, 2005 at 08:51:36AM -0500, Greg Troxel wrote: > How about > > user has discarded OTR keys for this session > > But I think this should perhaps be a machine-parseable message within > a signaling channeel, and the remote UI print this. OK, I think I've got a proposal for a machine-readable signalling channel inside the private channel, that also maintains complete back-compatibility with existing clients. Have the plaintext in a Data Message be: - Human-readable message optionally followed by: - NUL (\x00) - Zero or more TLV (type/length/value) records, of the form: - Type (SHORT) - Length (SHORT) - Value (length bytes of data) Anything you put in the TLV section must be ignorable by clients that don't understand that TLV type (or don't understand TLVs at all). It is acceptable for the plaintext message to be empty (that's in fact what the heartbeat does now). What do you all think? - Ian From evan.s at dreskin.net Mon Jan 31 11:49:36 2005 From: evan.s at dreskin.net (Evan Schoenberg) Date: Mon, 31 Jan 2005 10:49:36 -0600 Subject: [OTR-dev] user has stopped OTR message In-Reply-To: References: <20050130160300.GA24205@smtp.paip.net> Message-ID: <17300116-73A8-11D9-8034-000A95685E80@dreskin.net> " is no longer expecting encrypted data; you should end the OTR session" ? > > But I think this should perhaps be a machine-parseable message within > a signaling channeel, and the remote UI print this. I agree 100%. Primary reason in my mind is localization; this way it can be presented in the user's native language. -Evan On Jan 31, 2005, at 7:51 AM, Greg Troxel wrote: > How about > > user has discarded OTR keys for this session From evan.s at dreskin.net Mon Jan 31 12:03:30 2005 From: evan.s at dreskin.net (Evan Schoenberg) Date: Mon, 31 Jan 2005 11:03:30 -0600 Subject: [OTR-dev] 2.0.0 pre-releases coming soon In-Reply-To: <20050131141743.GH24205@smtp.paip.net> References: <20050131000549.GD24205@smtp.paip.net> <20050131004651.GE24205@smtp.paip.net> <20050131141743.GH24205@smtp.paip.net> Message-ID: <08255C6C-73AA-11D9-8034-000A95685E80@dreskin.net> On Jan 31, 2005, at 8:17 AM, Ian Goldberg wrote: > On Sun, Jan 30, 2005 at 08:07:25PM -0600, Evan Schoenberg wrote: >> Attached. As before, I can't compile the GTK part, so apologies if it >> has errors. Let me know if there are any problems. > > Wouldn't it be better to move the gaim-prefs-specific loads and saves > to > the gtk file, but leave the find_policy call alone? Won't you want to > use the find_policy function as-is? > I moved the whole thing to the gtk file because another UI may have preferences handled differently... and of course I speak in the generic there but mean that Adium has a different way of handling preferences ;) Our contact-specific prefs automatically handle inheritance, so if a value isn't set at the contact level, the group level will then be checked, and then the global level, with the most specific possible value returned. I guess a single function could return the appropriate values, either global or contact-specific or whatever... I'd just gone ahead and stored the preference as a value out of an enumeration rather than under three keys, so my function's implementation just asks the contact for the preference and then does a switch() on it to return the corresponding OTR value. >> Also attached is a one-line diff squelching a compiler warning I >> received in otr-plugin.c. > > I don't think this is valid; what's the warning? The switch statement > already handles all possible values of the enumeration, and if the > enumeration changes, *then* we want a compiler warning that you need to > change something in the switch (which will be suppressed by the > default:, which will in fact cause the wrong thing to happen). > My compiler was complaining that gaimlevel might be used uninitialized. I don't see how it could be, either, looking at that enum... Sorry for the haphazard patch; you're right that that would suppress a later change. No idea what my compiler is doing there, though. -Evan > - Ian > _______________________________________________ > OTR-dev mailing list > OTR-dev at lists.cypherpunks.ca > http://lists.cypherpunks.ca/mailman/listinfo/otr-dev > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 2228 bytes Desc: not available URL: From evan.s at dreskin.net Mon Jan 31 11:52:19 2005 From: evan.s at dreskin.net (Evan Schoenberg) Date: Mon, 31 Jan 2005 10:52:19 -0600 Subject: [OTR-dev] 2.0.0 pre-releases coming soon In-Reply-To: <20050131135930.GG24205@smtp.paip.net> References: <20050131000549.GD24205@smtp.paip.net> <20050131135930.GG24205@smtp.paip.net> Message-ID: <788C117A-73A8-11D9-8034-000A95685E80@dreskin.net> D'oh! Right you are. Thanks :) On Jan 31, 2005, at 7:59 AM, Ian Goldberg wrote: > But otrg_plugin_userstate is already exported by otr-plugin.h. Just > reference the variable. From gdt at ir.bbn.com Mon Jan 31 13:10:49 2005 From: gdt at ir.bbn.com (Greg Troxel) Date: 31 Jan 2005 13:10:49 -0500 Subject: [OTR-dev] user has stopped OTR message In-Reply-To: <20050131172539.GI24205@smtp.paip.net> References: <20050130160300.GA24205@smtp.paip.net> <20050131172539.GI24205@smtp.paip.net> Message-ID: Sounds fine, but note a) network order for type/length b) no padding between messages, even if they are odd length perhaps 'obvious', but perhaps not. -- Greg Troxel From ian at cypherpunks.ca Mon Jan 31 17:44:54 2005 From: ian at cypherpunks.ca (Ian Goldberg) Date: Mon, 31 Jan 2005 17:44:54 -0500 Subject: [OTR-dev] user has stopped OTR message In-Reply-To: <17300116-73A8-11D9-8034-000A95685E80@dreskin.net> References: <20050130160300.GA24205@smtp.paip.net> <17300116-73A8-11D9-8034-000A95685E80@dreskin.net> Message-ID: <20050131224454.GJ24205@smtp.paip.net> On Mon, Jan 31, 2005 at 10:49:36AM -0600, Evan Schoenberg wrote: > >But I think this should perhaps be a machine-parseable message within > >a signaling channeel, and the remote UI print this. > > I agree 100%. Primary reason in my mind is localization; this way it > can be presented in the user's native language. Done, and done. Programs that use libotr should check for the OTRL_TLV_DISCONNECTED TLV, and if it's there, notify the user however it likes. The prefs stuff in gaim-otr have also been moved to gtk-ui.c. http://www.cypherpunks.ca/otr/libotr-cvs-latest.tar.gz http://www.cypherpunks.ca/otr/gaim-otr-cvs-latest.tar.gz - Ian From evan.s at dreskin.net Mon Jan 31 17:52:54 2005 From: evan.s at dreskin.net (Evan Schoenberg) Date: Mon, 31 Jan 2005 16:52:54 -0600 Subject: [OTR-dev] user has stopped OTR message In-Reply-To: <20050131224454.GJ24205@smtp.paip.net> References: <20050130160300.GA24205@smtp.paip.net> <17300116-73A8-11D9-8034-000A95685E80@dreskin.net> <20050131224454.GJ24205@smtp.paip.net> Message-ID: And let the record show that Ian Goldberg continues to rock. On Jan 31, 2005, at 4:44 PM, Ian Goldberg wrote: > On Mon, Jan 31, 2005 at 10:49:36AM -0600, Evan Schoenberg wrote: >>> But I think this should perhaps be a machine-parseable message within >>> a signaling channeel, and the remote UI print this. >> >> I agree 100%. Primary reason in my mind is localization; this way it >> can be presented in the user's native language. > > Done, and done. Programs that use libotr should check for the > OTRL_TLV_DISCONNECTED TLV, and if it's there, notify the user however > it > likes. > > The prefs stuff in gaim-otr have also been moved to gtk-ui.c. > > http://www.cypherpunks.ca/otr/libotr-cvs-latest.tar.gz > http://www.cypherpunks.ca/otr/gaim-otr-cvs-latest.tar.gz > > - Ian > _______________________________________________ > OTR-dev mailing list > OTR-dev at lists.cypherpunks.ca > http://lists.cypherpunks.ca/mailman/listinfo/otr-dev > From ian at cypherpunks.ca Mon Jan 31 20:56:50 2005 From: ian at cypherpunks.ca (Ian Goldberg) Date: Mon, 31 Jan 2005 20:56:50 -0500 Subject: [OTR-dev] Initial Python wrappers In-Reply-To: <873043AF54FE794B912B616ABA7E9FE5067A6D@daytonmsg2k3.AERO.BALL.COM> References: <873043AF54FE794B912B616ABA7E9FE5067A6D@daytonmsg2k3.AERO.BALL.COM> Message-ID: <20050201015650.GN24205@smtp.paip.net> On Fri, Jan 28, 2005 at 12:48:17PM -0500, Clarke, Trevor wrote: > I've put together some Python wrappers for libotr. They use SWIG and > work with any recent version of Python. These wrappers are alpha and > there will be some changes to the interface as I tune it but they work > as they are. I've included a python script to demonstrate their usage. > Try them out, play with them, send me bug fixes. You can find them at > http://continuity.notcows.com/~retrev/PyOTR That's awesome. Keep up the good work! If you haven't already, you can take a peek at the current candidate for the version 2 API here: http://www.cypherpunks.ca/otr/libotr-cvs-latest.tar.gz - Ian