From alex323 at gmail.com Sat Apr 8 10:18:00 2006 From: alex323 at gmail.com (Alex) Date: Sat, 08 Apr 2006 10:18:00 -0400 Subject: [OTR-dev] Fragmenting? Message-ID: <4437C618.3070106@gmail.com> I have come to the point where I need to have fragmenting for OTR on IRC. However, I am unable to locate the fragmenting APIs to do so. I can see otrl_proto_fragment_accumulate, but where is the code that actually fragments messages? - Alex -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: OpenPGP digital signature URL: From ian at cypherpunks.ca Sat Apr 8 16:07:05 2006 From: ian at cypherpunks.ca (Ian Goldberg) Date: Sat, 8 Apr 2006 16:07:05 -0400 Subject: [OTR-dev] Fragmenting? In-Reply-To: <4437C618.3070106@gmail.com> References: <4437C618.3070106@gmail.com> Message-ID: <20060408200705.GQ31646@smtp.paip.net> On Sat, Apr 08, 2006 at 10:18:00AM -0400, Alex wrote: > I have come to the point where I need to have fragmenting for OTR on > IRC. However, I am unable to locate the fragmenting APIs to do so. I can > see otrl_proto_fragment_accumulate, but where is the code that actually > fragments messages? It's not in the current version. The plan was to let version 3.0 get out there for a while, so that it's likely people will be able to *accept* fragments before trying to figure out the annoying bits of how to pick a MMS (maximum message size). When there's a version that supports fragmentation, it's likely that you'll make a callback that, given the account/username/protocol triplet, returns an appropriate MMS to use, and otrl_message_sending() will take care of things, just as otrl_message_receiving() already takes care of fragment accumulation. - Ian From alex323 at gmail.com Sat Apr 8 22:12:23 2006 From: alex323 at gmail.com (Alex) Date: Sat, 08 Apr 2006 22:12:23 -0400 Subject: [OTR-dev] Fragmenting? In-Reply-To: <20060408200705.GQ31646@smtp.paip.net> References: <4437C618.3070106@gmail.com> <20060408200705.GQ31646@smtp.paip.net> Message-ID: <44386D87.4090003@gmail.com> Ian Goldberg wrote: >When there's a version that supports fragmentation, it's likely that >you'll make a callback that, given the account/username/protocol >triplet, returns an appropriate MMS to use, and otrl_message_sending() >will take care of things, just as otrl_message_receiving() already takes >care of fragment accumulation. > Has development of this started yet? - Alex -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: OpenPGP digital signature URL: From ian at cypherpunks.ca Sun Apr 9 12:39:07 2006 From: ian at cypherpunks.ca (Ian Goldberg) Date: Sun, 9 Apr 2006 12:39:07 -0400 Subject: [OTR-dev] Fragmenting? In-Reply-To: <44386D87.4090003@gmail.com> References: <4437C618.3070106@gmail.com> <20060408200705.GQ31646@smtp.paip.net> <44386D87.4090003@gmail.com> Message-ID: <20060409163907.GR31646@smtp.paip.net> On Sat, Apr 08, 2006 at 10:12:23PM -0400, Alex wrote: > Ian Goldberg wrote: > > >When there's a version that supports fragmentation, it's likely that > >you'll make a callback that, given the account/username/protocol > >triplet, returns an appropriate MMS to use, and otrl_message_sending() > >will take care of things, just as otrl_message_receiving() already takes > >care of fragment accumulation. > > > Has development of this started yet? No. - Ian From alex323 at gmail.com Wed Apr 12 13:47:55 2006 From: alex323 at gmail.com (Alex) Date: Wed, 12 Apr 2006 13:47:55 -0400 Subject: [OTR-dev] OTR Fragmenting Support Message-ID: <443D3D4B.5090702@gmail.com> Hey. I created a patch for limited fragmenting support in libotr. It only works with in the AKE, but that's where many of the longest messages are sent. I have not modified the library to include support for data messages, as I do not know how the fragmented messages should be returned. to the application. Attached is a README and the patch. You can also download the patch at sourceforge: http://sourceforge.net/tracker/index.php?func=detail&aid=1469420&group_id=128860&atid=713090 - Alex -------------- next part -------------- A non-text attachment was scrubbed... Name: otr_fragmenting_patch.tar.bz2 Type: application/x-bzip Size: 2333 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: OpenPGP digital signature URL: From ian at cypherpunks.ca Wed Apr 12 14:27:30 2006 From: ian at cypherpunks.ca (Ian Goldberg) Date: Wed, 12 Apr 2006 14:27:30 -0400 Subject: [OTR-dev] OTR Fragmenting Support In-Reply-To: <443D3D4B.5090702@gmail.com> References: <443D3D4B.5090702@gmail.com> Message-ID: <20060412182730.GG14888@smtp.paip.net> On Wed, Apr 12, 2006 at 01:47:55PM -0400, Alex wrote: > Hey. I created a patch for limited fragmenting support in libotr. It > only works with in the AKE, but that's where many of the longest > messages are sent. I have not modified the library to include support > for data messages, as I do not know how the fragmented messages should > be returned. to the application. Attached is a README and the patch. You > can also download the patch at sourceforge: A good start. Thanks! There are a few problems with it (mms is never initialized; your fragments are too large (they don't take into account the size of the header); you don't free memory properly in the event of an error; etc.), but it's definitely in line with what was intended. I probably won't get a chance to work on OTR too much until after the Computers, Freedom, and Privacy conference (www.cfp2006.org), but I should have some time after that. Data messages are a little tricky, since it's unclear whether messages sent with inject_message() will go out before or after the message left in *messagep at the end of otrl_message_sending() [this will depend on the structure of the application using libotr]. But I suppose all fragments *could* be sent using inject_message(). - Ian From alex323 at gmail.com Wed Apr 12 17:34:42 2006 From: alex323 at gmail.com (Alex) Date: Wed, 12 Apr 2006 17:34:42 -0400 Subject: [OTR-dev] OTR Fragmenting Support In-Reply-To: <20060412182730.GG14888@smtp.paip.net> References: <443D3D4B.5090702@gmail.com> <20060412182730.GG14888@smtp.paip.net> Message-ID: <443D7272.1070003@gmail.com> Ian Goldberg wrote: >On Wed, Apr 12, 2006 at 01:47:55PM -0400, Alex wrote: > > >>Hey. I created a patch for limited fragmenting support in libotr. It >>only works with in the AKE, but that's where many of the longest >>messages are sent. I have not modified the library to include support >>for data messages, as I do not know how the fragmented messages should >>be returned. to the application. Attached is a README and the patch. You >>can also download the patch at sourceforge: >> >> > >A good start. Thanks! > >There are a few problems with it (mms is never initialized; your >fragments are too large (they don't take into account the size of the >header); you don't free memory properly in the event of an error; etc.), >but it's definitely in line with what was intended. > This was my first real C project I've done, so any suggestions/tips are appreciated. Thanks. - Alex -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: OpenPGP digital signature URL: From twanfox at gmail.com Thu Apr 13 14:57:51 2006 From: twanfox at gmail.com (Twan Fox) Date: Thu, 13 Apr 2006 13:57:51 -0500 Subject: [OTR-dev] Self-referencing structure Message-ID: <443E9F2F.2030905@gmail.com> Greetings, While I understand that most don't work with Visual Studio .Net, I am running into a problem with that compiler as it relates to the Trillian OTR plugin I am writing. Specifically, this segment of code from the context.h file is giving it/me fits: typedef struct fingerprint { struct fingerprint *next; /* The next fingerprint in the list */ struct fingerprint **tous; /* A pointer to the pointer to us */ unsigned char *fingerprint; /* The fingerprint, or NULL */ struct context *context; /* The context to which we belong */ char *trust; /* The trust level of the fingerprint */ } Fingerprint; The error: c:\TrillCrypt\libotr.head\libotr\src\context.h(45): error C2461: 'fingerprint' : constructor syntax missing formal parameters I know what the compiler is complaining of. It believes that the 'unsigned char *fingerprint;' line is a constructor function for the struct 'fingerprint', but structs don't have constructor functions. I am, unfortunately, at a loss as to how to tell it to treat it as a regular C structure. I've attempted an extern "C" {} bracket around the included header files, but that seems to only work with functions, not data structures. Any insight anyone has would be appreciated. Thanks, Twan From ian at cypherpunks.ca Thu Apr 13 15:22:05 2006 From: ian at cypherpunks.ca (Ian Goldberg) Date: Thu, 13 Apr 2006 15:22:05 -0400 Subject: [OTR-dev] Self-referencing structure In-Reply-To: <443E9F2F.2030905@gmail.com> References: <443E9F2F.2030905@gmail.com> Message-ID: <20060413192205.GR14888@smtp.paip.net> On Thu, Apr 13, 2006 at 01:57:51PM -0500, Twan Fox wrote: > Greetings, > > While I understand that most don't work with Visual Studio .Net, I am > running into a problem with that compiler as it relates to the Trillian > OTR plugin I am writing. Specifically, this segment of code from the > context.h file is giving it/me fits: > > typedef struct fingerprint { > struct fingerprint *next; /* The next fingerprint in the > list */ > struct fingerprint **tous; /* A pointer to the pointer to us */ > unsigned char *fingerprint; /* The fingerprint, or NULL */ > struct context *context; /* The context to which we belong */ > char *trust; /* The trust level of the > fingerprint */ > } Fingerprint; Try changing the three instances of "struct fingerprint" to "struct _fingerprint". Someone suggested this a while back, but it didn't make it into CVS. Let us know if that works, and if it does, I'll check it in. The rest of the code references this type by its typedef "Fingerprint", so the struct name is completely arbitrary. - Ian From ian at cypherpunks.ca Thu Apr 13 17:27:50 2006 From: ian at cypherpunks.ca (Ian Goldberg) Date: Thu, 13 Apr 2006 17:27:50 -0400 Subject: [OTR-dev] Self-referencing structure In-Reply-To: <20060413192205.GR14888@smtp.paip.net> References: <443E9F2F.2030905@gmail.com> <20060413192205.GR14888@smtp.paip.net> Message-ID: <20060413212750.GS14888@smtp.paip.net> Twan reported it worked, so I committed the change (using "struct s_fingerprint"). C++ compilers should now be happier. ;-) - Ian From twanfox at gmail.com Thu Apr 13 23:38:54 2006 From: twanfox at gmail.com (Twan Fox) Date: Thu, 13 Apr 2006 22:38:54 -0500 Subject: [OTR-dev] Self-referencing structure In-Reply-To: <007201c65f3d$91816d20$0301000a@cheshire> References: <443E9F2F.2030905@gmail.com> <007201c65f3d$91816d20$0301000a@cheshire> Message-ID: <443F194E.8070806@gmail.com> mike davis wrote: > this is always a bit of a pain, you run into this a bit with linked > list stuff.. > > im curious though, because i got this code to build with vc 6.0 before: > > typedef struct pending_connection{ > char cookie[SLINK_COOKIE_SIZE]; > int socka; > pthread_t threadid; > struct pending_connection *pNext; > struct pending_connection *pPrev; > }pending_connection; > > which vc++ 6.0 seems to think is a perfectly valid syntax >> >> typedef struct fingerprint { >> struct fingerprint *next; /* The next fingerprint in the >> list */ >> struct fingerprint **tous; /* A pointer to the pointer to >> us */ >> unsigned char *fingerprint; /* The fingerprint, or NULL */ >> struct context *context; /* The context to which we >> belong */ >> char *trust; /* The trust level of the >> fingerprint */ >> } Fingerprint; >> The issue is not so much with the VS.NET 2003 being incapable or unwilling to understand the whole notion of a self-referenced structure. The issue relates to the conflict between the 'struct fingerprint' structure and the 'unsigned char *fingerprint' line. For a C++ compiler, that basic syntax is grounds for a constructor function. As in: class A { A::A; // This would generate the invalid constructor function A::A(); // This is proper syntax for a constructor function } ref: http://msdn2.microsoft.com/en-us/library/77e603b6.aspx What is terribly stupid about this issue is the notion that VS.NET 2003 seems to believe that a struct is somehow the same as a class, and should imply that any member that shares the same name as the structure is a constructor function. Because I wound up having issues rebuilding my plugin from scratch, setting out to make use of the Windows Template Library for the UI, this problem came up as well as a failure to link in the libotr library I had made. Ultimately, and I think this might've taken care of my problem had I done it first, doing the following would have allowed me to merge a library written in C to a project written in C++ extern "C" { #include #include } This would have told VS that the headers are true "C" syntax and should be treated as such. This also allowed me to link the library I built for libotr v3.0.0 into the resulting .dll from my project. Seems, as I kind of expected, this is a case of programmer error, with the programmer being me. Thanks for the feedback and assistance. - Twan From arodland at entermail.net Fri Apr 14 11:22:38 2006 From: arodland at entermail.net (Andrew Rodland) Date: Fri, 14 Apr 2006 10:22:38 -0500 Subject: [OTR-dev] Self-referencing structure In-Reply-To: <443F194E.8070806@gmail.com> References: <443E9F2F.2030905@gmail.com> <007201c65f3d$91816d20$0301000a@cheshire> <443F194E.8070806@gmail.com> Message-ID: <200604141022.38556.arodland@entermail.net> On Thursday 13 April 2006 22:38, Twan Fox wrote: > What is terribly stupid about this issue is the notion that VS.NET 2003 > seems to believe that a struct is somehow the same as a class, and > should imply that any member that shares the same name as the structure > is a constructor function. A struct _is_ somehow the same as a class. The only _real_ difference between the two is that members of structs are public by default, while members of classes are private by default. Any other difference between the two is strictly in your head, and a matter of convention. To the compiler, they're exactly the same except for a matter of access. Andrew From twanfox at gmail.com Wed Apr 19 21:17:54 2006 From: twanfox at gmail.com (Twan Fox) Date: Wed, 19 Apr 2006 20:17:54 -0500 Subject: [OTR-dev] Libgcrypt slowness in generation of keys Message-ID: <4446E142.6010500@gmail.com> Greetings, I know I've seen this issue around time and again, but after actually making a run at having libotr actually generate me a key for my Trillian OTR plugin, I found the whole process took 22 minutes before it finally returned. Obviously, this is unacceptable. I am currently using the libgcrypt v1.2.2 (as that is the only one that seems to be well supported by the Visual Studio .NET environment from s0rr0w") and have applied the patch as suggested on the main site in order to limit the heap walking. However, either I applied the patch wrong (since I applied it by hand, though after checking, I seem to have pegged it in the right place), or some other fix is needed in order to improve this. Now, I understand that Gaim happily builds private keys very quickly with the Gaim OTR plugin. However, I have no idea what libgcrypt version or patches were applied in order to make it work like it does. I am also not terribly sure that compiling the libgcrypt library via mingw will provide me a library capable of being used within Visual Studio, and unfortunately, I am not presently willing to divert from that compiler as I need it for the UI functionality it provides for me. I know there is something out there that is the probable fix, but I can't seem to locate it again. Any assistance or information is appreciated. Thanks, Twan From twanfox at gmail.com Wed Apr 19 21:49:32 2006 From: twanfox at gmail.com (Twan Fox) Date: Wed, 19 Apr 2006 20:49:32 -0500 Subject: [OTR-dev] Re: Libgcrypt slowness in generation of keys Message-ID: <4446E8AC.5050007@gmail.com> All, I might've been slightly hasty in my prior posting. Seems a full clean and rebuild of my plugin brought the time down to something more reasonable (sub-60 seconds or so), though part of me is a little bothered still by the way it the program was made unresponsive during the entropy gathering phase of the key generation. Sorry, Twan From ian at cypherpunks.ca Wed Apr 19 22:11:29 2006 From: ian at cypherpunks.ca (Ian Goldberg) Date: Wed, 19 Apr 2006 22:11:29 -0400 Subject: [OTR-dev] Re: Libgcrypt slowness in generation of keys In-Reply-To: <4446E8AC.5050007@gmail.com> References: <4446E8AC.5050007@gmail.com> Message-ID: <20060420021129.GU1474@smtp.paip.net> On Wed, Apr 19, 2006 at 08:49:32PM -0500, Twan Fox wrote: > All, > > I might've been slightly hasty in my prior posting. Seems a full clean > and rebuild of my plugin brought the time down to something more > reasonable (sub-60 seconds or so), though part of me is a little > bothered still by the way it the program was made unresponsive during > the entropy gathering phase of the key generation. If your UI thread is the one doing the key generation, then it will naturally make the app unresponsive. Just do appropriate locking in a separate thread. But 60 seconds still seems crazy. What happens if you just make a trivially small app that just calls otrl_privkey_generate with appropriate arguments? Can you track down what's causing the problem? - Ian From twanfox at gmail.com Wed Apr 19 23:08:34 2006 From: twanfox at gmail.com (Twan Fox) Date: Wed, 19 Apr 2006 22:08:34 -0500 Subject: [OTR-dev] Re: Libgcrypt slowness in generation of keys In-Reply-To: <20060420021129.GU1474@smtp.paip.net> References: <4446E8AC.5050007@gmail.com> <20060420021129.GU1474@smtp.paip.net> Message-ID: <4446FB32.5080003@gmail.com> Ian Goldberg wrote: > On Wed, Apr 19, 2006 at 08:49:32PM -0500, Twan Fox wrote: > >> All, >> >> I might've been slightly hasty in my prior posting. Seems a full clean >> and rebuild of my plugin brought the time down to something more >> reasonable (sub-60 seconds or so), though part of me is a little >> bothered still by the way it the program was made unresponsive during >> the entropy gathering phase of the key generation. >> > > If your UI thread is the one doing the key generation, then it will > naturally make the app unresponsive. Just do appropriate locking in a > separate thread. > > But 60 seconds still seems crazy. What happens if you just make a > trivially small app that just calls otrl_privkey_generate with > appropriate arguments? Can you track down what's causing the problem? > A trivially small app generates a key file pretty fast. I'd say around 5 seconds or so. It was a debug variant of the program, and for some reason, the libgcrypt program makes use of a set of dummy va_list args for one of it's calls when generating a key. Sends pop-up messages that kind of disrupt the process of generation and make accurate timekeeping difficult. I rebuilt the libraries (libgpg-error, libgcrypt, libotr) as a release version and compiled my plugin as a release version. Eliminating the pop-up warnings, I think it takes somewhere on the order of 10 seconds to generate a key for one account. Environment: Trillian |----> Plugins loaded: AIM/ICQ medium plugin Audio/Video Plugin (default) Trillian OTR plugin A pretty lean environment to test in. When I said 'sub-60 seconds,' I was making an out of my rear guestimation. It was no more than 60 seconds, but it was long enough for me to have noticed. I think 10 seconds is acceptable for key generation. I'm not sure what Gaim OTR's lag is on it. And, while I'd love to thread the key generation off into something behind the scenes, I'm not entirely sure just how, within Windows. :( Once again, this looks like it is programmer error, with the programmer being me. Thanks, Twan From rich.griffin at gmail.com Tue Apr 25 17:17:53 2006 From: rich.griffin at gmail.com (Rich Griffin) Date: Tue, 25 Apr 2006 17:17:53 -0400 Subject: [OTR-dev] OTR security analysis? Message-ID: <2984fd620604251417g5e7e2760u96a0a225d88d4e2d@mail.gmail.com> All: Does anyone know what the action items are in response to the OTR security analysis (http://www.stanford.edu/~amo/otr_analysis.pdf)? Can these issues be addressed? Is there a roadmap for this? I'm not at all being critical, just very eager to enjoy the use of the nicest security system I've yet seen. Anxiously awaiting, -- Rich Griffin From asm at CS.Stanford.EDU Tue Apr 25 20:29:43 2006 From: asm at CS.Stanford.EDU (Andrew S. Morrison) Date: Tue, 25 Apr 2006 17:29:43 -0700 Subject: [OTR-dev] OTR security analysis? In-Reply-To: <2984fd620604251417g5e7e2760u96a0a225d88d4e2d@mail.gmail.com> References: <2984fd620604251417g5e7e2760u96a0a225d88d4e2d@mail.gmail.com> Message-ID: <20060426002942.GA22961@xenon.Stanford.EDU> I'm still around to discuss the analysis with anyone willing to listen to me :) -- Andrew S. Morrison asm at cs.stanford.edu (650) 575 9261 On 0, Rich Griffin wrote: > All: > > Does anyone know what the action items are in response to the OTR > security analysis (http://www.stanford.edu/~amo/otr_analysis.pdf)? > > Can these issues be addressed? Is there a roadmap for this? > > I'm not at all being critical, just very eager to enjoy the use of the > nicest security system I've yet seen. > > Anxiously awaiting, > > -- > Rich Griffin > > _______________________________________________ > 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: application/pgp-signature Size: 189 bytes Desc: not available URL: From me at nikita.ca Tue Apr 25 23:53:02 2006 From: me at nikita.ca (Nikita Borisov) Date: Tue, 25 Apr 2006 22:53:02 -0500 Subject: [OTR-dev] OTR security analysis? In-Reply-To: <20060426002942.GA22961@xenon.Stanford.EDU> References: <2984fd620604251417g5e7e2760u96a0a225d88d4e2d@mail.gmail.com> <20060426002942.GA22961@xenon.Stanford.EDU> Message-ID: <16f0378d0604252053x1d1ace27r3dfd5f4c8dea8602@mail.gmail.com> From twanfox at gmail.com Fri Apr 28 14:29:35 2006 From: twanfox at gmail.com (Twan Fox) Date: Fri, 28 Apr 2006 13:29:35 -0500 Subject: [OTR-dev] app_find subroutine for otrl_context_find Message-ID: <44525F0F.6050603@gmail.com> Greetings, Drawing ever closer to a full Trillian plugin, I find myself wanting for an application-based extension to the otrl_context_find() function. What I mean by that is simple, and similar to how the otrl_message_receiving() and _sending() functions accept both a new_context function and app_data structure in the event a new context is created, to allow the app_data and app_data_free members of the ConnContext structure to be populated. The otrl_context_find() should take a 2 additional arguments, a function reference that points to a search subroutine and a data structure that holds data the additional search routine can use to match context to app_data. The returned value is likely to be the located ConnContext pointer. If there is merit in the idea of extending the otrl_context_find() function in that way, and it is necessary, I can draft up some code to make the appropriate call. It is just so much simpler than attempting to walk the userstate->context_root list myself and search through each app_data structure for what I want. Alternatively, I suppose that I can just write the subroutine and call it myself if otrl_context_find() returns nothing. Just seeking feedback. Thanks, Twan