From ian at cypherpunks.ca Wed Jul 2 11:59:05 2008 From: ian at cypherpunks.ca (Ian Goldberg) Date: Wed, 2 Jul 2008 11:59:05 -0400 Subject: [OTR-dev] SMP event handling Message-ID: <20080702155905.GF5309@thunk.cs.uwaterloo.ca> I've checked in changes (largely from Willy) to add a callback to handle SMP events. Now there's no need to do anything at all in your message_receiving function. (Before, you had to implement part of the SMP state machine there yourself. Ick!) The callback for gaim-otr is this: static void handle_smp_event(void *opdata, OtrlSMPEvent smp_event, ConnContext *context, unsigned short progress_percent, char *question) { if (!context) return; switch (smp_event) { case OTRL_SMPEVENT_ASK_FOR_SECRET : otrg_dialog_socialist_millionaires(context); break; case OTRL_SMPEVENT_ASK_FOR_ANSWER : otrg_dialog_socialist_millionaires_q(context, question); break; case OTRL_SMPEVENT_CHEATED : otrg_plugin_abort_smp(context); /* FALLTHROUGH */ case OTRL_SMPEVENT_IN_PROGRESS : case OTRL_SMPEVENT_SUCCESS : case OTRL_SMPEVENT_FAILURE : case OTRL_SMPEVENT_ABORT : otrg_dialog_update_smp(context, smp_event, ((gdouble)progress_percent)/100.0); break; case OTRL_SMPEVENT_ERROR : otrg_plugin_abort_smp(context); break; } } Does this look good to people? Any changes you'd like? Thanks, - Ian From ian at cypherpunks.ca Wed Jul 2 14:41:01 2008 From: ian at cypherpunks.ca (Ian Goldberg) Date: Wed, 2 Jul 2008 14:41:01 -0400 Subject: [OTR-dev] Symmetric key retrieval Message-ID: <20080702184101.GJ5309@thunk.cs.uwaterloo.ca> For Paul :-) I've checked in support for applications asking libotr for a forward-secret symmetric key. Call this function if you want one: /* Get the current extra symmetric key (of size OTRL_EXTRAKEY_BYTES * bytes) and let the other side know what we're going to use it for. * The key is stored in symkey, which must already be allocated * and OTRL_EXTRAKEY_BYTES bytes long. */ gcry_error_t otrl_message_symkey(OtrlUserState us, const OtrlMessageAppOps *ops, void *opdata, ConnContext *context, unsigned int use, const unsigned char *usedata, size_t usedatalen, unsigned char *symkey); This callback will be called on the other side: /* We received a request from the buddy to use the current "extra" * symmetric key. The key will be passed in symkey, of length * OTRL_EXTRAKEY_BYTES. The requested use, as well as use-specific * data will be passed so that the applications can communicate other * information (some id for the data transfer, for example). */ void (*received_symkey)(void *opdata, ConnContext *context, unsigned int use, const unsigned char *usedata, size_t usedatalen, const unsigned char *symkey); [OTRL_EXTRAKEY_BYTES is currently 32, so you get 256 bits out of it.] Paul, is that what you were looking for? Thanks, - Ian From ian at cypherpunks.ca Thu Jul 3 07:53:00 2008 From: ian at cypherpunks.ca (Ian Goldberg) Date: Thu, 3 Jul 2008 07:53:00 -0400 Subject: [OTR-dev] Delphi bindings for libotr? Message-ID: <20080703115300.GA9173@yoink.cs.uwaterloo.ca> Do any of the Windows users on the dev list have the ability to compile libotr into a form suitable for creating Delphi bindings? I believe all you need is the Borland C compiler, and you just have to get it to output an OBJ file and the exported list of functions. Anyone can do the latter, but the former needs the Borland C compiler in particular, since the OBJ has to be in Borland's OMF format. Thanks, - Ian From paul at cypherpunks.ca Thu Jul 3 15:08:43 2008 From: paul at cypherpunks.ca (Paul Wouters) Date: Thu, 3 Jul 2008 15:08:43 -0400 (EDT) Subject: [OTR-dev] Symmetric key retrieval In-Reply-To: <20080702184101.GJ5309@thunk.cs.uwaterloo.ca> References: <20080702184101.GJ5309@thunk.cs.uwaterloo.ca> Message-ID: On Wed, 2 Jul 2008, Ian Goldberg wrote: > For Paul :-) > I've checked in support for applications asking libotr for a > forward-secret symmetric key. Excellent! This is a step towards using session keys to protect file transfers and video/audio conferencing! > [OTRL_EXTRAKEY_BYTES is currently 32, so you get 256 bits out of it.] > > Paul, is that what you were looking for? Yes, though I am not sure if 256bits is strong enough for a session key. Is that the strength within our OTR session anyway? When used for 3des, aes or blowfish symmetric crypto? Paul From ian at cypherpunks.ca Thu Jul 3 16:38:31 2008 From: ian at cypherpunks.ca (Ian Goldberg) Date: Thu, 3 Jul 2008 16:38:31 -0400 Subject: [OTR-dev] Symmetric key retrieval In-Reply-To: References: <20080702184101.GJ5309@thunk.cs.uwaterloo.ca> Message-ID: <20080703203831.GL7467@thunk.cs.uwaterloo.ca> On Thu, Jul 03, 2008 at 03:08:43PM -0400, Paul Wouters wrote: > On Wed, 2 Jul 2008, Ian Goldberg wrote: > > >For Paul :-) > > >I've checked in support for applications asking libotr for a > >forward-secret symmetric key. > > Excellent! This is a step towards using session keys to protect file > transfers and video/audio conferencing! > > >[OTRL_EXTRAKEY_BYTES is currently 32, so you get 256 bits out of it.] > > > >Paul, is that what you were looking for? > > Yes, though I am not sure if 256bits is strong enough for a session key. > Is that the strength within our OTR session anyway? When used for 3des, > aes or blowfish symmetric crypto? OTR uses AES-128. I made 256 bits available so you can get two 128-bit keys out of it (say, one for encrypting in each direction, or one for encrypting and one for a MAC). The 256 bits are basically a SHA-256 hash of the current Diffie-Hellman g^{xy} value (in order to preserve forward secrecy). - Ian From ian at cypherpunks.ca Thu Jul 3 19:11:04 2008 From: ian at cypherpunks.ca (Ian Goldberg) Date: Thu, 3 Jul 2008 19:11:04 -0400 Subject: [OTR-dev] Symmetric key retrieval In-Reply-To: References: <20080702184101.GJ5309@thunk.cs.uwaterloo.ca> <20080703203831.GL7467@thunk.cs.uwaterloo.ca> Message-ID: <20080703231104.GU6417@yoink.cs.uwaterloo.ca> On Thu, Jul 03, 2008 at 06:08:34PM -0400, px at xelerance.com wrote: > > > OTR uses AES-128. I made 256 bits available so you can get two 128-bit > > keys out of it (say, one for encrypting in each direction, or one for > > encrypting and one for a MAC). The 256 bits are basically a SHA-256 > > hash of the current Diffie-Hellman g^{xy} value (in order to preserve > > forward secrecy). > > Hmm, if it is derived from g^{xy}, then wouldn't it be enough to > send the request without the key material? The other end also has > g^{xy} right? Yes. That's what it does. No keys are sent (even encrypted). > What is the risk here when a malicious client is trying to leak > encrypted content. Could it pick something weak so that g^{xy} > is easilly guessable when having more crypted text available to it? > > Though I guess this case is better protected, as it prevents one > side from using a known OTP to leak out information via this > feature. (But I'm not a crypto buf :) A malicious client could just leak the key directly. I'm not sure what you're asking? If you could figure out g^{xy} given a lot of data AES-encrypted with SHA-256(g^{xy}), then you've nontrivially broken either AES or SHA-256 (and probably both). - Ian From ian at cypherpunks.ca Sun Jul 6 18:09:07 2008 From: ian at cypherpunks.ca (Ian Goldberg) Date: Sun, 6 Jul 2008 18:09:07 -0400 Subject: [OTR-dev] Re: Requirements for libotr4 In-Reply-To: <20080621145205.GT6417@yoink.cs.uwaterloo.ca> References: <20080619183738.GW26418@thunk.cs.uwaterloo.ca> <20080621134210.GR6417@yoink.cs.uwaterloo.ca> <20080621145205.GT6417@yoink.cs.uwaterloo.ca> Message-ID: <20080706220907.GC6417@yoink.cs.uwaterloo.ca> On Sat, Jun 21, 2008 at 10:52:05AM -0400, Ian Goldberg wrote: > With the specified division of threads, the callbacks are now > unnecessary. I've checked in the support for background privkey generation. Here are the new functions in privkey.h. Uli, does this do what you want? - Ian /* Begin a private key generation that will potentially take place in * a background thread. This routine must be called from the main * thread. It will set *newkeyp, which you can pass to * otrl_privkey_generate_calculate in a background thread. If it * returns gcry_error(GPG_ERR_EEXIST), then a privkey creation for * this accountname/protocol is already in progress, and *newkeyp will * be set to NULL. */ gcry_error_t otrl_privkey_generate_start(OtrlUserState us, const char *accountname, const char *protocol, void **newkeyp); /* Do the private key generation calculation. You may call this from a * background thread. When it completes, call * otrl_privkey_generate_finish from the _main_ thread. */ gcry_error_t otrl_privkey_generate_calculate(void *newkey); /* Call this from the main thread only. It will write the newly created * private key into the given file and store it in the OtrlUserState. */ gcry_error_t otrl_privkey_generate_finish(OtrlUserState us, void *newkey, const char *filename); /* Call this from the main thread only. It will write the newly created * private key into the given FILE* (which must be open for reading and * writing) and store it in the OtrlUserState. */ gcry_error_t otrl_privkey_generate_finish_FILEp(OtrlUserState us, void *newkey, FILE *privf); From a.sporto+bee at gmail.com Tue Jul 8 07:47:51 2008 From: a.sporto+bee at gmail.com (Uli M) Date: Tue, 8 Jul 2008 11:47:51 +0000 (UTC) Subject: [OTR-dev] Re: Requirements for libotr4 References: <20080619183738.GW26418@thunk.cs.uwaterloo.ca> <20080621134210.GR6417@yoink.cs.uwaterloo.ca> <20080621145205.GT6417@yoink.cs.uwaterloo.ca> <20080706220907.GC6417@yoink.cs.uwaterloo.ca> Message-ID: On 2008-07-06, Ian Goldberg wrote: > On Sat, Jun 21, 2008 at 10:52:05AM -0400, Ian Goldberg wrote: >> With the specified division of threads, the callbacks are now >> unnecessary. > > I've checked in the support for background privkey generation. Here are the > new functions in privkey.h. > > Uli, does this do what you want? > > - Ian > > /* Begin a private key generation that will potentially take place in > * a background thread. This routine must be called from the main > * thread. It will set *newkeyp, which you can pass to > * otrl_privkey_generate_calculate in a background thread. If it > * returns gcry_error(GPG_ERR_EEXIST), then a privkey creation for > * this accountname/protocol is already in progress, and *newkeyp will > * be set to NULL. */ > gcry_error_t otrl_privkey_generate_start(OtrlUserState us, > const char *accountname, const char *protocol, void **newkeyp); > > /* Do the private key generation calculation. You may call this from a > * background thread. When it completes, call > * otrl_privkey_generate_finish from the _main_ thread. */ > gcry_error_t otrl_privkey_generate_calculate(void *newkey); > > /* Call this from the main thread only. It will write the newly created > * private key into the given file and store it in the OtrlUserState. */ > gcry_error_t otrl_privkey_generate_finish(OtrlUserState us, > void *newkey, const char *filename); > > /* Call this from the main thread only. It will write the newly created > * private key into the given FILE* (which must be open for reading and > * writing) and store it in the OtrlUserState. */ > gcry_error_t otrl_privkey_generate_finish_FILEp(OtrlUserState us, > void *newkey, FILE *privf); From a.sporto+bee at gmail.com Wed Jul 9 05:56:01 2008 From: a.sporto+bee at gmail.com (Uli M) Date: Wed, 9 Jul 2008 11:56:01 +0200 Subject: [OTR-dev] Re: Requirements for libotr4 In-Reply-To: <20080706220907.GC6417@yoink.cs.uwaterloo.ca> References: <20080619183738.GW26418@thunk.cs.uwaterloo.ca> <20080621134210.GR6417@yoink.cs.uwaterloo.ca> <20080621145205.GT6417@yoink.cs.uwaterloo.ca> <20080706220907.GC6417@yoink.cs.uwaterloo.ca> Message-ID: <20080709095600.GA8464@gmail.com> On Sun 06.07.08 18:09, Ian Goldberg wrote: > On Sat, Jun 21, 2008 at 10:52:05AM -0400, Ian Goldberg wrote: > > With the specified division of threads, the callbacks are now > > unnecessary. > > I've checked in the support for background privkey generation. Here are the > new functions in privkey.h. > > Uli, does this do what you want? Yeah, that looks good. There's just one problem I see: there's no cancel method. So when the background generation fails or is aborted and then at a later point in time generate_start is called again for the same accountname/protocol pair I guess it will return GPG_ERR_EEXIST (because generate_finish hasn't been called for this pair). One could work around this in the app by storing the newkey pointers of aborted generations for later reuse in generate_calculate calls but a cancel method would be better. Uli P.S.: sry for the last empty message > > - Ian > > /* Begin a private key generation that will potentially take place in > * a background thread. This routine must be called from the main > * thread. It will set *newkeyp, which you can pass to > * otrl_privkey_generate_calculate in a background thread. If it > * returns gcry_error(GPG_ERR_EEXIST), then a privkey creation for > * this accountname/protocol is already in progress, and *newkeyp will > * be set to NULL. */ > gcry_error_t otrl_privkey_generate_start(OtrlUserState us, > const char *accountname, const char *protocol, void **newkeyp); > > /* Do the private key generation calculation. You may call this from a > * background thread. When it completes, call > * otrl_privkey_generate_finish from the _main_ thread. */ > gcry_error_t otrl_privkey_generate_calculate(void *newkey); > > /* Call this from the main thread only. It will write the newly created > * private key into the given file and store it in the OtrlUserState. */ > gcry_error_t otrl_privkey_generate_finish(OtrlUserState us, > void *newkey, const char *filename); > > /* Call this from the main thread only. It will write the newly created > * private key into the given FILE* (which must be open for reading and > * writing) and store it in the OtrlUserState. */ > gcry_error_t otrl_privkey_generate_finish_FILEp(OtrlUserState us, > void *newkey, FILE *privf); > _______________________________________________ > OTR-dev mailing list > OTR-dev at lists.cypherpunks.ca > http://lists.cypherpunks.ca/mailman/listinfo/otr-dev From ian at cypherpunks.ca Wed Jul 9 11:11:19 2008 From: ian at cypherpunks.ca (Ian Goldberg) Date: Wed, 9 Jul 2008 11:11:19 -0400 Subject: [OTR-dev] Re: Requirements for libotr4 In-Reply-To: <20080709095600.GA8464@gmail.com> References: <20080619183738.GW26418@thunk.cs.uwaterloo.ca> <20080621134210.GR6417@yoink.cs.uwaterloo.ca> <20080621145205.GT6417@yoink.cs.uwaterloo.ca> <20080706220907.GC6417@yoink.cs.uwaterloo.ca> <20080709095600.GA8464@gmail.com> Message-ID: <20080709151119.GE29567@thunk.cs.uwaterloo.ca> On Wed, Jul 09, 2008 at 11:56:01AM +0200, Uli M wrote: > On Sun 06.07.08 18:09, Ian Goldberg wrote: > > On Sat, Jun 21, 2008 at 10:52:05AM -0400, Ian Goldberg wrote: > > > With the specified division of threads, the callbacks are now > > > unnecessary. > > > > I've checked in the support for background privkey generation. Here are the > > new functions in privkey.h. > > > > Uli, does this do what you want? > > Yeah, that looks good. There's just one problem I see: there's no > cancel method. So when the background generation fails or is aborted > and then at a later point in time generate_start is called again for > the same accountname/protocol pair I guess it will return > GPG_ERR_EEXIST (because generate_finish hasn't been called for this > pair). > > One could work around this in the app by storing the newkey pointers > of aborted generations for later reuse in generate_calculate calls but > a cancel method would be better. Fair enough. I just checked this in: /* Call this from the main thread only, in the event that the background * thread generating the key is cancelled. The newkey is deallocated, * and must not be used further. */ void otrl_privkey_generate_cancel(OtrlUserState us, void *newkey); - Ian From a.sporto+bee at gmail.com Thu Jul 10 09:02:45 2008 From: a.sporto+bee at gmail.com (Uli M) Date: Thu, 10 Jul 2008 15:02:45 +0200 Subject: [OTR-dev] Re: Requirements for libotr4 In-Reply-To: <20080709151119.GE29567@thunk.cs.uwaterloo.ca> References: <20080619183738.GW26418@thunk.cs.uwaterloo.ca> <20080621134210.GR6417@yoink.cs.uwaterloo.ca> <20080621145205.GT6417@yoink.cs.uwaterloo.ca> <20080706220907.GC6417@yoink.cs.uwaterloo.ca> <20080709095600.GA8464@gmail.com> <20080709151119.GE29567@thunk.cs.uwaterloo.ca> Message-ID: <20080710130149.GB10153@gmail.com> Ian, one last question: Is the assessment I made somewhere else in this thread[1] correct that not creating a key in the create privkey callback leads to the same result as not defining the callback at all? I.e. is it indeed OK to start background generation there and just let the ongoing handshake fail? Uli [1] http://article.gmane.org/gmane.comp.security.otr.devel/892 On Wed 09.07.08 11:11, Ian Goldberg wrote: > On Wed, Jul 09, 2008 at 11:56:01AM +0200, Uli M wrote: > > On Sun 06.07.08 18:09, Ian Goldberg wrote: > > > On Sat, Jun 21, 2008 at 10:52:05AM -0400, Ian Goldberg wrote: > > > > With the specified division of threads, the callbacks are now > > > > unnecessary. > > > > > > I've checked in the support for background privkey generation. Here are the > > > new functions in privkey.h. > > > > > > Uli, does this do what you want? > > > > Yeah, that looks good. There's just one problem I see: there's no > > cancel method. So when the background generation fails or is aborted > > and then at a later point in time generate_start is called again for > > the same accountname/protocol pair I guess it will return > > GPG_ERR_EEXIST (because generate_finish hasn't been called for this > > pair). > > > > One could work around this in the app by storing the newkey pointers > > of aborted generations for later reuse in generate_calculate calls but > > a cancel method would be better. > > Fair enough. I just checked this in: > > /* Call this from the main thread only, in the event that the background > * thread generating the key is cancelled. The newkey is deallocated, > * and must not be used further. */ > void otrl_privkey_generate_cancel(OtrlUserState us, void *newkey); > > - 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 Jul 10 11:05:16 2008 From: ian at cypherpunks.ca (Ian Goldberg) Date: Thu, 10 Jul 2008 11:05:16 -0400 Subject: [OTR-dev] Faster key generation Message-ID: <20080710150516.GB13613@thunk.cs.uwaterloo.ca> Thanks to Simon Josefsson! http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=489523#37 If you want your IM client to use /dev/urandom instead of /dev/random to generate keys, stick this line just before the call to OTRL_INIT: gcry_control(GCRYCTL_ENABLE_QUICK_RANDOM, 0); I've checked the change into pidgin-otr's cvs; the Debian/Ubuntu, Fedora, BSD, etc. package maintainers may wish to manually apply the patch until the next release: --- otr-plugin.c 2 Jul 2008 18:33:09 -0000 1.21 +++ otr-plugin.c 10 Jul 2008 12:42:44 -0000 1.22 @@ -973,6 +973,11 @@ otrg_dialog_set_ui_ops(otrg_gtk_dialog_get_ui_ops()); #endif +#ifndef WIN32 + /* Make key generation use /dev/urandom instead of /dev/random */ + gcry_control(GCRYCTL_ENABLE_QUICK_RANDOM, 0); +#endif + /* Initialize the OTR library */ OTRL_INIT; - Ian From ian at cypherpunks.ca Thu Jul 10 11:08:49 2008 From: ian at cypherpunks.ca (Ian Goldberg) Date: Thu, 10 Jul 2008 11:08:49 -0400 Subject: [OTR-dev] Re: Requirements for libotr4 In-Reply-To: <20080710130149.GB10153@gmail.com> References: <20080619183738.GW26418@thunk.cs.uwaterloo.ca> <20080621134210.GR6417@yoink.cs.uwaterloo.ca> <20080621145205.GT6417@yoink.cs.uwaterloo.ca> <20080706220907.GC6417@yoink.cs.uwaterloo.ca> <20080709095600.GA8464@gmail.com> <20080709151119.GE29567@thunk.cs.uwaterloo.ca> <20080710130149.GB10153@gmail.com> Message-ID: <20080710150849.GC13613@thunk.cs.uwaterloo.ca> On Thu, Jul 10, 2008 at 03:02:45PM +0200, Uli M wrote: > Ian, > > one last question: Is the assessment I made somewhere else in this > thread[1] correct that not creating a key in the create privkey > callback leads to the same result as not defining the callback at all? > I.e. is it indeed OK to start background generation there and just let > the ongoing handshake fail? I believe nothing will break, except of course that the handshake will fail rather than automatically continuing after the key is generated (the way it works now). But perhaps with the patch to use /dev/urandom I just posted, this whole background thread thing is unnecessary. I'll leave the facility in, though, in case some IM client really does want to use /dev/random in the background. - Ian From ian at cypherpunks.ca Thu Jul 10 12:05:01 2008 From: ian at cypherpunks.ca (Ian Goldberg) Date: Thu, 10 Jul 2008 12:05:01 -0400 Subject: [OTR-dev] Re: [Pkg-gnutls-maint] Bug#489523: pidgin-otr: key generation uses too much entropy from /dev/random In-Reply-To: <58B7FFC7-E2E7-4650-9F1F-E2BA263FCD06@josefsson.org> References: <20080709125711.GA29567@thunk.cs.uwaterloo.ca> <7d01f9f00807090615ve815683h2c2e98dc0afbef29@mail.gmail.com> <20080709145400.GD29567@thunk.cs.uwaterloo.ca> <7d01f9f00807090758q5cd85e6ftd12cb452c4e9a40@mail.gmail.com> <20080709153406.GG29567@thunk.cs.uwaterloo.ca> <7d01f9f00807090848y1c7c17b0l59f815b9e02d07dd@mail.gmail.com> <7d01f9f00807100146p277d6b22w9785af4cae0801eb@mail.gmail.com> <20080710150103.GA13613@thunk.cs.uwaterloo.ca> <7d01f9f00807100820n434bb6cfx3018b26a21bf781f@mail.gmail.com> <58B7FFC7-E2E7-4650-9F1F-E2BA263FCD06@josefsson.org> Message-ID: <20080710160501.GE13613@thunk.cs.uwaterloo.ca> On Thu, Jul 10, 2008 at 05:49:27PM +0200, Simon Josefsson wrote: > Do be careful about using that function though: its exact semantics are > not documented as far as I know. It may result in having long-term > private key based on no or little entropy. The current library does the "right" thing; i.e. random bytes are obtained from /dev/urandom. But if it's undocumented, then it might change in the future to use the output of rand() or something, which would be bad indeed. The problem is that people run key generation with libgcrypt on machines that gather very little entropy into /dev/random, and key generation can literally take over an hour. I'm happy to use /dev/urandom instead, since the output of a PRNG that only gets, say, 200 bits of entropy, had better be indistinguishable from a truly random source. But if libgcrypt decides to make that call use an even weaker source for some reason, Badness would indeed occur. What do people think? - Ian From paul at cypherpunks.ca Thu Jul 10 18:24:55 2008 From: paul at cypherpunks.ca (Paul Wouters) Date: Thu, 10 Jul 2008 18:24:55 -0400 (EDT) Subject: [OTR-dev] Faster key generation In-Reply-To: <20080710150516.GB13613@thunk.cs.uwaterloo.ca> References: <20080710150516.GB13613@thunk.cs.uwaterloo.ca> Message-ID: On Thu, 10 Jul 2008, Ian Goldberg wrote: > Thanks to Simon Josefsson! > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=489523#37 > > If you want your IM client to use /dev/urandom instead of /dev/random to > generate keys, stick this line just before the call to OTRL_INIT: > > gcry_control(GCRYCTL_ENABLE_QUICK_RANDOM, 0); > > I've checked the change into pidgin-otr's cvs; the Debian/Ubuntu, > Fedora, BSD, etc. package maintainers may wish to manually apply the > patch until the next release: What's the effect of security on using this? I tend to prefer /dev/random for long term keys, and only use /dev/urandom for session keys. Paul From paul at cypherpunks.ca Thu Jul 10 18:28:43 2008 From: paul at cypherpunks.ca (Paul Wouters) Date: Thu, 10 Jul 2008 18:28:43 -0400 (EDT) Subject: [OTR-dev] Re: [Pkg-gnutls-maint] Bug#489523: pidgin-otr: key generation uses too much entropy from /dev/random In-Reply-To: <20080710160501.GE13613@thunk.cs.uwaterloo.ca> References: <20080709125711.GA29567@thunk.cs.uwaterloo.ca> <7d01f9f00807090615ve815683h2c2e98dc0afbef29@mail.gmail.com> <20080709145400.GD29567@thunk.cs.uwaterloo.ca> <7d01f9f00807090758q5cd85e6ftd12cb452c4e9a40@mail.gmail.com> <20080709153406.GG29567@thunk.cs.uwaterloo.ca> <7d01f9f00807090848y1c7c17b0l59f815b9e02d07dd@mail.gmail.com> <7d01f9f00807100146p277d6b22w9785af4cae0801eb@mail.gmail.com> <20080710150103.GA13613@thunk.cs.uwaterloo.ca> <7d01f9f00807100820n434bb6cfx3018b26a21bf781f@mail.gmail.com> <58B7FFC7-E2E7-4650-9F1F-E2BA263FCD06@josefsson.org> <20080710160501.GE13613@thunk.cs.uwaterloo.ca> Message-ID: On Thu, 10 Jul 2008, Ian Goldberg wrote: > The problem is that people run key generation with libgcrypt on machines > that gather very little entropy into /dev/random, and key generation can > literally take over an hour. On a desktop with IM client? They don't use disk or network IO, both of which gather entropy (on linux)? Which systems do people use that are so entropyless, and can we only use /dev/urandom on those? > I'm happy to use /dev/urandom instead, > since the output of a PRNG that only gets, say, 200 bits of entropy, > had better be indistinguishable from a truly random source. I am not sure I understand this sentence with respect to random vs urandom. Paul From e.aca35 at westtoer.be Fri Jul 11 18:56:42 2008 From: e.aca35 at westtoer.be (e.aca35 at westtoer.be) Date: Fri, 11 Jul 2008 15:56:42 -0700 Subject: [OTR-dev] Be smarter, get your medicaments online. Message-ID: <4877E52A.4050806@westtoer.be> Real enhaning products that always work. http://ypk.doctorbutgood.eu From efs22 at shimada-shokai.co.jp Fri Jul 11 17:29:36 2008 From: efs22 at shimada-shokai.co.jp (Chanel Watches) Date: Fri, 11 Jul 2008 21:29:36 +0000 Subject: [OTR-dev] Breitling Watches Message-ID: <000501c8e3ac$01f9d636$7846139c@encjteo> Why would you want to purchase a replica watch from King-replicas? There may be many reasons: 1. You want a genuine Rolex / Breitling watch, but the price is too ridiculous 2. You want to impress your friends or business clients 3. You want to keep your original safe, while using the replica for daily wear and tear on it. Browse our King-replica watches shop! -------------- next part -------------- An HTML attachment was scrubbed... URL: From supernaturalsnci5 at anotherticket.com Fri Jul 11 19:28:19 2008 From: supernaturalsnci5 at anotherticket.com (Jolene Beatty) Date: Sat, 12 Jul 2008 02:28:19 +0300 Subject: [OTR-dev] No test, No class, buy yourself Bacheelor/MasteerMBA/Doctoraate dip1omas, VALID in all countries Message-ID: <01c8e3c6$f2fd1080$2ae8fe59@supernaturalsnci5> Bacheelor, MasteerMBA, and Doctoraate diplomas available in the field of your choice that's right, you can even become a Doctor and receive all the benefits that comes with it! Our Diplomas/Certificates are recognised in most countries No required examination, tests, classes, books, or interviews. ** No one is turned down ** Confidentiality assured CALL US 24 HOURS A DAY, 7 DAYS A WEEK For US: 1-781-634-7970 Outside US: +1-781-634-7970 "Just leave your NAME & PHONE NO. (with CountryCode)" in the voicemail our staff will get back to you in next few days -------------- next part -------------- An HTML attachment was scrubbed... URL: From JennyslabSchmitt at european-films.net Fri Jul 11 09:22:49 2008 From: JennyslabSchmitt at european-films.net (Ramona Ames) Date: Fri, 11 Jul 2008 18:22:49 +0500 Subject: [OTR-dev] With Vacheron Constantin replica watch time becomes ... Message-ID: 7eff001c8e3ad$6e6836b0$0a00a8c0@windows QUALITY REPLICA WATCHES! 100% EXACT! ALL BRANDS! To Men Who Want To Buy Rolex Watches At A Fraction Of The Price Replica Classics trendy replica watches for you http://musedpia.com/ From dorothyrichmond at fsmail.net Fri Jul 11 17:39:55 2008 From: dorothyrichmond at fsmail.net (bink katsufum) Date: Fri, 11 Jul 2008 21:39:55 +0000 Subject: [OTR-dev] 75% pills discount. Message-ID: <000801c8e3ad$015fe6df$122a8692@jixdwyvg> Dear otr-dev, visit the best online store http://www.palabrario.com/redir.html Coupon #GB8S fernando joaquim From dodot.pradigdo at pajak.go.id Fri Jul 11 17:50:18 2008 From: dodot.pradigdo at pajak.go.id (bartlett gershom) Date: Fri, 11 Jul 2008 21:50:18 +0000 Subject: [OTR-dev] 95% drugs discount. Message-ID: <000501c8e3af$07e74281$86fb1e84@xxjpykl> Hello otr-dev, visit the most reliable provider http://www.palabrario.com/redir.html Code #1ceF bentlee nanette From bifbrutal at chegg.com Fri Jul 11 19:51:16 2008 From: bifbrutal at chegg.com (Julian Arredondo) Date: Fri, 11 Jul 2008 18:51:16 -0500 Subject: [OTR-dev] Pharm mall Message-ID: <001301c8e387$19197cd0$01487764@MARK102> Powerful female response enhancer Make sure she never needs her dildo again! Here! ev'rything epicnemial enthoven's epistrophy erechtheum ex-frogman exscinding estabelece farmington epimeritic evangelism erlandsens -------------- next part -------------- An HTML attachment was scrubbed... URL: From Xghvhs1 at nbed.nb.ca Fri Jul 11 18:50:32 2008 From: Xghvhs1 at nbed.nb.ca (andrew manley) Date: Fri, 11 Jul 2008 22:50:32 +0000 Subject: [OTR-dev] Bonjour, chez moi est bon Soft Message-ID: <05787501.20080712003754@lists.cypherpunks.ca> Nous sommes ravis de vous offrir le logiciel localisé le plus populaire. Le français, l’anglais, l’allemand, l’italien, l’espagnol et plusieurs d’autres langues du monde! Il est possible de télécharger et installer n'importe quel programme tout de suite après l'achat, vous ne devez plus attendre quelques semaines le logiciel sur un support. Notre prix: Windows XP Pro SP2 - 59.95 euroWindows Vista Ultimate 32-bit - 79.95 euroAdobe Acrobat Pro 8 - 79.95 euroOffice 2003 Pro - 59.95 euroOffice Enterprise 2007 - 79.95 euroAdobe Photoshop CS2 - 79.95 euroAutoCAD 2008 - 149.95 euroNous vendons les programmes pour für MacintoshMicrosoft Office 2004 for MAC – 79.95 euroAdobe Acrobat 7 Professional for MAC – 59.95 euroAdobe Creative Suite 2 Premium for MAC – 229.95 euroMacromedia Dreamweaver 8 for MAC – 69.95 euroNous avons plus de 300 programmes pour PC et Mac! Achetez maintenant, et épargnez beaucoup d’argent! www.vaiwosoft.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From 2Lhand at jeraisy.com Fri Jul 11 18:55:18 2008 From: 2Lhand at jeraisy.com (algernon galen) Date: Fri, 11 Jul 2008 22:55:18 +0000 Subject: [OTR-dev] Salut, je le manager "Euro Software" et moi suis content de te proposer>>> Message-ID: <000501c8e3b8$049a7f2c$3bf45bb1@nknjbqb> Nous sommes ravis de vous offrir le logiciel localisé le plus populaire. Le français, l’anglais, l’allemand, l’italien, l’espagnol et plusieurs d’autres langues du monde! Il est possible de télécharger et installer n'importe quel programme tout de suite après l'achat, vous ne devez plus attendre quelques semaines le logiciel sur un support. Notre prix: Windows XP Pro SP2 - 59.95 euroWindows Vista Ultimate 32-bit - 79.95 euroAdobe Acrobat Pro 8 - 79.95 euroOffice 2003 Pro - 59.95 euroOffice Enterprise 2007 - 79.95 euroAdobe Photoshop CS2 - 79.95 euroAutoCAD 2008 - 149.95 euroNous vendons les programmes pour für MacintoshMicrosoft Office 2004 for MAC – 79.95 euroAdobe Acrobat 7 Professional for MAC – 59.95 euroAdobe Creative Suite 2 Premium for MAC – 229.95 euroMacromedia Dreamweaver 8 for MAC – 69.95 euroNous avons plus de 300 programmes pour PC et Mac! Achetez maintenant, et épargnez beaucoup d’argent! www.vaiwosoft.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From deescalatesfbj72 at novahealthcare.com Fri Jul 11 20:49:42 2008 From: deescalatesfbj72 at novahealthcare.com (Roberto Shapiro) Date: Sat, 12 Jul 2008 08:49:42 +0800 Subject: [OTR-dev] InfoCialisPhentrimine Message-ID: <01c8e3fc$39d19780$7d1948da@deescalatesfbj72> Pay less and get more in our health care store! *Offer expires November 30, 2008. As a valued Windows Live Hotmail customer, we hope you find this Windows Vista Ultimate offer valuable. If you would prefer to no longer receive promotional offers about Windows Vista Ultimate please click here. For general information about how to manage your Communication Preferences with Microsoft please click here. If you have questions about Microsoft privacy policies, please read our online Privacy Statement. Opting out of Microsoft e-mail offers will not affect any newsletters you have requested nor restrict important customer communications concerning your Microsoft products. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kpt.bm at acledabank.com.kh Fri Jul 11 19:10:42 2008 From: kpt.bm at acledabank.com.kh (viagar cilais ) Date: Fri, 11 Jul 2008 23:10:42 +0000 Subject: [OTR-dev] 90% off for otr-dev Message-ID: <000401c8e3ba$032d07fa$3d85179d@gqcuood> Hello, make a wise decision, get your pills from the most well-known onine shop. http://www.palabrario.com/redir.html Coupon #BKns amerigo khueh From otr-dev at lists.cypherpunks.ca Fri Jul 11 21:03:53 2008 From: otr-dev at lists.cypherpunks.ca (Mathew Vernon) Date: Fri, 11 Jul 2008 21:03:53 -0400 Subject: [OTR-dev] Dear otr-dev@lists.cypherpunks.ca July 81% 0FF Message-ID: <20080712150359.6387.qmail@win06v3> An HTML attachment was scrubbed... URL: From itsakq at lists.cypherpunks.ca Fri Jul 11 23:01:38 2008 From: itsakq at lists.cypherpunks.ca (Amy) Date: Sat, 12 Jul 2008 04:01:38 +0100 Subject: [OTR-dev] Casino, magick casino Message-ID: <48781082.9050802@lists.cypherpunks.ca> An HTML attachment was scrubbed... URL: From thevalera at pdcglass.com Fri Jul 11 22:12:18 2008 From: thevalera at pdcglass.com (thevalera at pdcglass.com) Date: Sat, 12 Jul 2008 03:12:18 +0100 Subject: [OTR-dev] Online chemist where you can save on all your health needs. Message-ID: <000601c8e3c5$d6690b50$9547bcc9@wgh> Learn how and when enhancing products work. http://xtju.surgeongood.eu From epost.fyw at telesp.net.br Fri Jul 11 22:38:26 2008 From: epost.fyw at telesp.net.br (Edelgard) Date: Fri, 11 Jul 2008 22:38:26 -0400 Subject: [OTR-dev] Outdoorsex Treffpunkte Message-ID: <484F1963.EC931C2B@telesp.net.br> Hier sind die besten Parkplatztreffs und Outdoorsex Treffpunkte In unserer Datenbank findest Du Girls, Paare und M?nner die geile Kontakte auf Parkpl?tzen suchen. Wer viel auf Reisen ist, oder zuhause der Partner wartet, wird hier jede Menge M?glichkeiten entdecken. Bei uns erhalten Sie die sch?rfsten Parkplatz Sex Adressen! Unsere Datenbank ist vorallem f?r jedermann zug?ngig und liefert dir die besten Informationen zu allen g?ngigen Sextreffpunkten rund um die Parkpl?tze Europas. Bei den Parkplatztreffen fallen f?r Sie keine Kosten an, da es sich bei bei den Treffen um private Sextreffen handelt die ohne finanzielles Interesse zustande kommen. http://www.musst-du-sehen.com/user/parkplatzsex/ Gruss, Edelgard Hier k?nnen Sie sich aus dem Verteiler austragen: http://www.profiletter.de/RWCode/subscribe.asp?SID=10&SiteID=3664&Email=&Hi tID=1207984903000 cxpwlqiv iqvctfyeeci fbfzsobdycesb From hae at lists.cypherpunks.ca Fri Jul 11 23:26:48 2008 From: hae at lists.cypherpunks.ca (Ronnie) Date: Fri, 11 Jul 2008 23:26:48 --300 Subject: [OTR-dev] Casino, magick casino Message-ID: <48781668.5060605@lists.cypherpunks.ca> Win, win with us - our royal casino http://stylelinux.net/ -- http://iphones.ru From LeagoatherdStallings at buffalosoldier.net Sat Jul 12 03:31:30 2008 From: LeagoatherdStallings at buffalosoldier.net (Lea Woody) Date: Sat, 12 Jul 2008 05:31:30 -0200 Subject: [OTR-dev] *3 FREE Bottles Of VPXL !! Message-ID: 1066e701c8e3c7$94bed2f0$6700a8c0@EMADS Impress the ladies with the new tool in your pants, and watch them moan in pleasure when you fill them up deeper and more tightly. Be the stud in 2008, and achieve all your dreams of super size! http://backfeel.com/ From bogus@does.not.exist.com Fri Jul 11 23:42:55 2008 From: bogus@does.not.exist.com (Charmaine) Date: Sat, 12 Jul 2008 04:42:55 +0100 Subject: [OTR-dev] Linux style Message-ID: <48781A2F.3000102@lists.cypherpunks.ca> An HTML attachment was scrubbed... URL: From elhgdecro at blueorbb.com Fri Jul 11 23:42:57 2008 From: elhgdecro at blueorbb.com (Byron Hood) Date: Sat, 12 Jul 2008 11:42:57 +0800 Subject: [OTR-dev] Ladies, here is the ultimate gift for your men, used by pornstarrs worldwide. Message-ID: <01c8e414$6da3f680$690c347b@elhgdecro> You need a thing she would adore! http://courierwant.com From outgoing_0130 at yahoo.co.jp Fri Jul 11 09:11:24 2008 From: outgoing_0130 at yahoo.co.jp (=?iso-2022-jp?B?b3V0Z29pbmdfMDEzMEB5YWhvby5jby5qcA==?=) Date: Fri, 11 Jul 2008 22:11:24 +0900 Subject: [OTR-dev] =?iso-2022-jp?B?GyRCJEkkJiQ3JEYkYkNOJGokPyQkSn0kTiRfOCskRiQvJEAkNSQkGyhC?= Message-ID: <200807120357.m6C3v47k004152@paip.net> ????????????????????????????? ????????????????????? ???--?30?????????????-- ??????????325????? ????????????????????????????? ???????????????? ?????????????? ???????????????? ????????????????????????? ??????????????????? ?????????????????????????????? ??????????????????????????? ???????????????? ???????????????? ???????????????? ??????????Special http://hp-b.com/fnv/ex3.php?media=pcy17 ?????????????????????? ????????????????????????????? ?????????????????????????????? ?????????????????????? ??????????????????????????? ???????????????????????????????? ==============================? ???????????????????????????????? ????????????????????????? ?????????????(? ? ?)??? ??????????????????????????? ????????????????????????? ????????????????????? ?????????????????????????????? ??????????????? ?????????????????????? ???????? ????????????????????????????? ??????????????????????? ???????????????????????? From gmanager at fsasports.com Fri Jul 11 22:47:17 2008 From: gmanager at fsasports.com (giffer madhusud) Date: Sat, 12 Jul 2008 02:47:17 +0000 Subject: [OTR-dev] ID:68241 Killer discounts on all accessories and bags Message-ID: <000501c8e3d8$0352a1fa$c899de8b@iqdag> Speed up to the nightclub with a diamond studded luxury watch strapped around your wrist, and watch everybody stare in awe. Business colleagues will envy your wealth; with $20,000 around your wrist, success and a statement is assured. With famous luxury brands to choose from: Rolex Patek Cartier Breitling Bell & Ross and more than two dozen other designer brands - what are you waiting for? Pay only $99 for watches that are worth thousands and thousands. Shop safely and securely online in 2008. - Visit our site - www.roieis.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From 94nimda at rimbundahan.org Sat Jul 12 07:51:46 2008 From: 94nimda at rimbundahan.org (herrmann marco) Date: Sat, 12 Jul 2008 11:51:46 +0000 Subject: [OTR-dev] to otr-dev Message-ID: <000901c8e424$0686f8b5$67738ba6@pbbduvag> Get the great discounts on popular software today ! All software is instantly available to download - No Need Wait! ALL OUR SOFTWARES ON ALL EUROPEAN LANGUAGES - USA, English, France, Italy, Spanish, German and more!!! Windows XP Pro With SP2 - $59.95 Adobe Acrobat Pro 8 - $69.95 Office 2003 Pro - $59.95 Adobe Photoshop CS2 - $79.95 AutoCAD 2007 - $149.95 Also we have so much soft for MACINTOSH!!! Microsoft Office 2004 for MAC $79.95 Adobe Acrobat 7 Professional for MAC $59.95 Adobe Creative Suite 2 Premium for MAC $229.95 Macromedia Dreamweaver 8 for MAC $69.95 - Visit our site: www.rahwosoft[DOT]com (copy this link and then replace "[DOT]" to ".") From a-audryf at accessworldwide.net Sat Jul 12 00:38:24 2008 From: a-audryf at accessworldwide.net (Coy Orozco) Date: Sat, 12 Jul 2008 12:38:24 +0800 Subject: [OTR-dev] I'd like to show you my pic Message-ID: <01c8e41c$2cafe000$7ca5273a@a-audryf> Hello! I am tired this afternoon. I am nice girl that would like to chat with you. Email me at Karin at GuideLo.info only, because I am using my friend's email to write this. To see some pictures of me. -------------- next part -------------- A non-text attachment was scrubbed... Name: me Type: image/gif Size: 44235 bytes Desc: not available URL: From 0Oanne-ceciloux at infonie.fr Fri Jul 11 23:22:31 2008 From: 0Oanne-ceciloux at infonie.fr (adrian aubrey) Date: Sat, 12 Jul 2008 03:22:31 +0000 Subject: [OTR-dev] Salut, freine Soft? Le remplacement qualitatif est necessaire ? Message-ID: <000701c8e3dd$0213ee55$63347791@vcjes> Nous sommes ravis de vous offrir le logiciel localisé le plus populaire. Le français, l’anglais, l’allemand, l’italien, l’espagnol et plusieurs d’autres langues du monde! Il est possible de télécharger et installer n'importe quel programme tout de suite après l'achat, vous ne devez plus attendre quelques semaines le logiciel sur un support. Notre prix: Windows XP Pro SP2 - 59.95 euroWindows Vista Ultimate 32-bit - 79.95 euroAdobe Acrobat Pro 8 - 79.95 euroOffice 2003 Pro - 59.95 euroOffice Enterprise 2007 - 79.95 euroAdobe Photoshop CS2 - 79.95 euroAutoCAD 2008 - 149.95 euroNous vendons les programmes pour für MacintoshMicrosoft Office 2004 for MAC – 79.95 euroAdobe Acrobat 7 Professional for MAC – 59.95 euroAdobe Creative Suite 2 Premium for MAC – 229.95 euroMacromedia Dreamweaver 8 for MAC – 69.95 euroNous avons plus de 300 programmes pour PC et Mac! Achetez maintenant, et épargnez beaucoup d’argent! www.vaiwosoft.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From jank at tipa-czech.com Sat Jul 12 01:12:18 2008 From: jank at tipa-czech.com (jank at tipa-czech.com) Date: Sat, 12 Jul 2008 12:12:18 +0700 Subject: [OTR-dev] Get fit for summer beach season. Message-ID: <48783D32.2040108@tipa-czech.com> Waste no time on useless exercise to gett of some kilos, there is better way. http://qolau.medicgoodguide.eu From kyaekoso at focusers.com Sat Jul 12 01:19:51 2008 From: kyaekoso at focusers.com (Karma Yaeko) Date: Fri, 11 Jul 2008 22:19:51 -0700 Subject: [OTR-dev] Free ViagraCializ pills for Any purchase, Buy more FREE more! bop 0ko In-Reply-To: Message-ID: <1215839991.1813@focusers.com> == A-Z Medications to choose from == We give You FreeViagraPills (Free you 4-12 pills with any order) == ViagraPill === == Cialix Pills == == Phentrimine == == Levitr == == PenisGrowth Pack == == SQMA == == Tramadol == == FemaleViagra == & 400 more meds to choose from Claim Your Free 4-12 ViagraPills here with us http://kreb.bicut.com.cn From ko_lee at att.net Sat Jul 12 00:13:16 2008 From: ko_lee at att.net (gannon ivor) Date: Sat, 12 Jul 2008 04:13:16 +0000 Subject: [OTR-dev] Free porno DVD's to download Message-ID: <000801c8e3e4$010aec22$602af391@jyyaeqpu> No credit card needed -------------- next part -------------- An HTML attachment was scrubbed... URL: From 5apagliarani at deloitte.it Sat Jul 12 00:47:40 2008 From: 5apagliarani at deloitte.it (heinrich julian) Date: Sat, 12 Jul 2008 04:47:40 +0000 Subject: [OTR-dev] wonder tic-tac Message-ID: <000601c8e3e9$04ef47b8$123592b9@kkxcbr> " My order arrived yesterday via registered mail in good order THE WATCH IS BEAUTIFUL AND EVEN BETTER THAN I EXPECTED." Try it for yourself - u will be amazed!! - The worlds largest online retailer of luxury products, including: Rolex Sports Models Rolex Datejusts Breitling Cartier Porsche Design Dolce & Gabbana Dior Gucci Hermes Watches Patek Philippe Visit - www.proooe.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From 6benefits at tides.org Sat Jul 12 00:26:40 2008 From: 6benefits at tides.org (giancarlo irene) Date: Sat, 12 Jul 2008 04:26:40 +0000 Subject: [OTR-dev] 15% best offer Message-ID: <000901c8e3e6$05678cb2$becf8f95@gourvgh> " My order arrived yesterday via registered mail in good order THE WATCH IS BEAUTIFUL AND EVEN BETTER THAN I EXPECTED." Try it for yourself - u will be amazed!! - The worlds largest online retailer of luxury products, including: Rolex Sports Models Rolex Datejusts Breitling Cartier Porsche Design Dolce & Gabbana Dior Gucci Hermes Watches Patek Philippe Visit - www.proooe.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From sportscast7758 at baileybridge.com Sat Jul 12 02:17:44 2008 From: sportscast7758 at baileybridge.com (Joesph Fischer) Date: Sat, 12 Jul 2008 15:17:44 +0900 Subject: [OTR-dev] YourHealthFDAapprovedCanadian Message-ID: <01c8e432$6ee41c00$93f5ccd3@sportscast7758> Pay less and get more in our health care store! *Offer expires November 30, 2008. As a valued Windows Live Hotmail customer, we hope you find this Windows Vista Ultimate offer valuable. If you would prefer to no longer receive promotional offers about Windows Vista Ultimate please click here. For general information about how to manage your Communication Preferences with Microsoft please click here. If you have questions about Microsoft privacy policies, please read our online Privacy Statement. Opting out of Microsoft e-mail offers will not affect any newsletters you have requested nor restrict important customer communications concerning your Microsoft products. -------------- next part -------------- An HTML attachment was scrubbed... URL: From flavell at floridabt.com Sat Jul 12 02:31:46 2008 From: flavell at floridabt.com (Curnalia) Date: Sat, 12 Jul 2008 08:31:46 +0200 Subject: [OTR-dev] Check out what I found Message-ID: <3006A8F3-A530-1017-8FD9-768E638CBF74@floridabt.com> Drive your lady mad with desire and pleasure http://www.wentteam.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From otr-dev at lists.cypherpunks.ca Sat Jul 12 02:35:52 2008 From: otr-dev at lists.cypherpunks.ca (Wilbur Ingram) Date: Sat, 12 Jul 2008 02:35:52 -0400 Subject: [OTR-dev] Dear otr-dev@lists.cypherpunks.ca July 80% 0FF Message-ID: <20080712170558.3319.qmail@viny> An HTML attachment was scrubbed... URL: From TommyparryArnold at electronic-school.com Sat Jul 12 05:42:09 2008 From: TommyparryArnold at electronic-school.com (Greg Matthews) Date: Sat, 12 Jul 2008 08:42:09 -0100 Subject: [OTR-dev] Penis Enlargment Reviews Message-ID: fa4d01c8e3ea$82371700$6502a8c0@zsuzsa Natural Penis Enlargement 1 to 4 Inches in just Weeks. Read and get! http://shapeangel.com/ From WarrenignorantHart at cjtf101.com Fri Jul 11 17:43:02 2008 From: WarrenignorantHart at cjtf101.com (Dan Berry) Date: Sat, 12 Jul 2008 02:13:02 +0430 Subject: [OTR-dev] Quality Replica Watches Message-ID: 12e45001c8e3ea$fab334c0$1400a8c0@Supervisores Cheap High Quality Replica Fake Watches... 3000+ Styles! http://grailaspbiz.com/ From burt at surecom.com Sat Jul 12 01:30:26 2008 From: burt at surecom.com (aluino jessica) Date: Sat, 12 Jul 2008 05:30:26 +0000 Subject: [OTR-dev] Join most played casin0 Message-ID: <11491.sugih@wandojo> Join me and over 2.300.000 gamers playing and receive 300 Euros free on your first deposit. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ian at cypherpunks.ca Mon Jul 14 23:08:13 2008 From: ian at cypherpunks.ca (Ian Goldberg) Date: Mon, 14 Jul 2008 23:08:13 -0400 Subject: [OTR-dev] [ADMIN] Sorry about the spam Message-ID: <20080715030813.GQ6417@yoink.cs.uwaterloo.ca> The global security upgrade this week broke the mailing lists; sorry. When I tried to fix it, some spam leaked through. Hopefully the lists are fixed now (but the web interface still isn't up; that will take some more work, I'm afraid). - Ian From ian at cypherpunks.ca Tue Jul 15 10:02:31 2008 From: ian at cypherpunks.ca (Ian Goldberg) Date: Tue, 15 Jul 2008 10:02:31 -0400 Subject: [OTR-dev] irssi-otr 0.1 released In-Reply-To: <20080715130932.GA16624@nets.rwth-aachen.de> References: <20080619234833.GE8251@nets.rwth-aachen.de> <20080715085710.GA7420@gmail.com> <20080715120244.GT6417@yoink.cs.uwaterloo.ca> <20080715130932.GA16624@nets.rwth-aachen.de> Message-ID: <20080715140231.GB22444@thunk.cs.uwaterloo.ca> [Moved to otr-dev.] On Tue, Jul 15, 2008 at 01:09:02PM +0000, Uli M wrote: > From irssi-otr's viewpoint the other end's MMS is at least when used > with bitlbee in 99% of the cases too high. Jabber clients use 2 > kilobytes, IRC needs something below 500 bytes. That's why irssi-otr > needs to do reassembly by itself and potentially on top of libotr > reassembly (the fragmentation is done by bitlbee). If libotr would > negotiate the MMS between the two parties the whole reassembly code in > irssi-otr would be unneccessary. > > Now the problem was that the reassembly code in irssi-otr tried to > reassemble messages fragmented by libotr that didn't need reassembling. > It depended on messages being terminated by '.' but fragmented messages > are terminated by ','. That wasn't a problem before because irssi-otr > has the same MMS as irssi-otr (obviously,so no reassembly) and all other > clients don't fragment messages at all (since they don't need to). The > exception being communication with pidgin over IRC - and here the bug > occurred. > > The code was something like > > if len(msg)>MMS and msg[len(msg)-1]!='.' then reassemble > > which I corrected by > > if len(msg)>MMS and msg[len(msg)-1]!='.' and > msg[len(msg)-1]!=',' then reassemble > > It ain't pretty but it works. Prettier would be MMS negotation ;) Is this "then reassemble" doing libotr reassembly or bitlbee reassembly? What does bitlbee fragmentation look like? If the sender (pidgin-otr for example) fragments the message, and bitlbee refragments it, why could irssi-otr not do bitlbee-reassembly to recover the otr fragment, then pass that to otrl_message_receiving as usual, which will automatically perform the appropriate otr reassembly? Thanks, - Ian From a.sporto+bee at gmail.com Tue Jul 15 11:25:30 2008 From: a.sporto+bee at gmail.com (Uli M) Date: Tue, 15 Jul 2008 15:25:30 +0000 (UTC) Subject: [OTR-dev] irssi-otr 0.1 released In-Reply-To: <20080715140231.GB22444@thunk.cs.uwaterloo.ca> References: <20080619234833.GE8251@nets.rwth-aachen.de> <20080715085710.GA7420@gmail.com> <20080715120244.GT6417@yoink.cs.uwaterloo.ca> <20080715130932.GA16624@nets.rwth-aachen.de> <20080715140231.GB22444@thunk.cs.uwaterloo.ca> Message-ID: <20080715152600.GB16624@nets.rwth-aachen.de> On Tue 15.07.08 10:02, Ian Goldberg wrote: > [Moved to otr-dev.] > > On Tue, Jul 15, 2008 at 01:09:02PM +0000, Uli M wrote: > > From irssi-otr's viewpoint the other end's MMS is at least when used > > with bitlbee in 99% of the cases too high. Jabber clients use 2 > > kilobytes, IRC needs something below 500 bytes. That's why irssi-otr > > needs to do reassembly by itself and potentially on top of libotr > > reassembly (the fragmentation is done by bitlbee). If libotr would > > negotiate the MMS between the two parties the whole reassembly code in > > irssi-otr would be unneccessary. > > > > Now the problem was that the reassembly code in irssi-otr tried to > > reassemble messages fragmented by libotr that didn't need reassembling. > > It depended on messages being terminated by '.' but fragmented messages > > are terminated by ','. That wasn't a problem before because irssi-otr > > has the same MMS as irssi-otr (obviously,so no reassembly) and all other > > clients don't fragment messages at all (since they don't need to). The > > exception being communication with pidgin over IRC - and here the bug > > occurred. > > > > The code was something like > > > > if len(msg)>MMS and msg[len(msg)-1]!='.' then reassemble > > > > which I corrected by > > > > if len(msg)>MMS and msg[len(msg)-1]!='.' and > > msg[len(msg)-1]!=',' then reassemble > > > > It ain't pretty but it works. Prettier would be MMS negotation ;) > > Is this "then reassemble" doing libotr reassembly or bitlbee reassembly? > What does bitlbee fragmentation look like? IIRC bitlbee splits IRC messages longer than 512 bytes (note that an IRC message also contains other stuff like nick and server, so the actually payload should be less than that). I can be very thankful for that because irssi-otr wouldn't exist if bitlbee would cut the messages off (which I'm sure some IRC servers do). By splitting I mean making two messages out of it, so for example :nick!nick at irc.server.net PRIVMSG ulim : FOO.........BAR....... becomes :nick!nick at irc.server.net PRIVMSG ulim : FOO......... :nick!nick at irc.server.net PRIVMSG ulim : BAR....... How does irssi-otr detect and reassemble this: So if "FOO....." contains "?OTR:", is longer than MMS and does not end with "." or "," then it was hopefully split up and the message is queued. The next message is appended and queued as well if >MMS and unless it ends with "." or ",". The best documentation is probably the code itself which isn't that long, look at otr_receive(), starting at line 527 here [1]. > If the sender (pidgin-otr for example) fragments the message, and > bitlbee refragments it, why could irssi-otr not do bitlbee-reassembly > to recover the otr fragment, then pass that to otrl_message_receiving as > usual, which will automatically perform the appropriate otr reassembly? That is exactly what happens. It ain't beautiful and it is very error prone but it seems to work most of the time at least with jabber...I heard of more problems with ICQ but I don't know yet if they are related to reassembly. Note that this all depends on OTR messages not containing a "." or "," anywhere but in the end (and there always). It also depends on the users not writing clear text messages >MMS that contain "?OTR:" because they would get queued/reassembled as well. I'm sure there are other scenarios that cause problems. Since the 3-line otr query msg unfortunately doesnt fit the above restrictions it's handled specially(=hardcoded) in the code. Uli [1] http://git.tuxfamily.org/irssiotr/irssiotr.git?p=gitroot/irssiotr/irssiotr.git;a=blob;f=otrutil.c;h=104870eb58e91588f89d9db7fa2d0b939a48ab8b;hb=HEAD From ian at cypherpunks.ca Tue Jul 15 17:31:31 2008 From: ian at cypherpunks.ca (Ian Goldberg) Date: Tue, 15 Jul 2008 17:31:31 -0400 Subject: [OTR-dev] irssi-otr 0.1 released In-Reply-To: <20080715152600.GB16624@nets.rwth-aachen.de> References: <20080619234833.GE8251@nets.rwth-aachen.de> <20080715085710.GA7420@gmail.com> <20080715120244.GT6417@yoink.cs.uwaterloo.ca> <20080715130932.GA16624@nets.rwth-aachen.de> <20080715140231.GB22444@thunk.cs.uwaterloo.ca> <20080715152600.GB16624@nets.rwth-aachen.de> Message-ID: <20080715213131.GV6417@yoink.cs.uwaterloo.ca> On Tue, Jul 15, 2008 at 03:25:30PM +0000, Uli M wrote: > IIRC bitlbee splits IRC messages longer than 512 bytes (note that an IRC > message also contains other stuff like nick and server, so the actually > payload should be less than that). I can be very thankful for that > because irssi-otr wouldn't exist if bitlbee would cut the messages off > (which I'm sure some IRC servers do). By splitting I mean making two > messages out of it, so for example > > :nick!nick at irc.server.net PRIVMSG ulim : FOO.........BAR....... > > becomes > > :nick!nick at irc.server.net PRIVMSG ulim : FOO......... > :nick!nick at irc.server.net PRIVMSG ulim : BAR....... > > How does irssi-otr detect and reassemble this: Ah, I see. So there's no actual framing, saying "this is fragment 1/3" or anything like that. I guess what you're doing is about all you can do, in that event. - Ian From a.sporto+bee at gmail.com Tue Jul 15 19:08:00 2008 From: a.sporto+bee at gmail.com (Uli M) Date: Tue, 15 Jul 2008 23:08:00 +0000 (UTC) Subject: [OTR-dev] irssi-otr 0.1 released In-Reply-To: <20080715213131.GV6417@yoink.cs.uwaterloo.ca> References: <20080619234833.GE8251@nets.rwth-aachen.de> <20080715085710.GA7420@gmail.com> <20080715120244.GT6417@yoink.cs.uwaterloo.ca> <20080715130932.GA16624@nets.rwth-aachen.de> <20080715140231.GB22444@thunk.cs.uwaterloo.ca> <20080715152600.GB16624@nets.rwth-aachen.de> <20080715213131.GV6417@yoink.cs.uwaterloo.ca> Message-ID: <20080715230830.GA31379@nets.rwth-aachen.de> On Tue 15.07.08 17:31, Ian Goldberg wrote: > On Tue, Jul 15, 2008 at 03:25:30PM +0000, Uli M wrote: > > IIRC bitlbee splits IRC messages longer than 512 bytes (note that an IRC > > message also contains other stuff like nick and server, so the actually > > payload should be less than that). I can be very thankful for that > > because irssi-otr wouldn't exist if bitlbee would cut the messages off > > (which I'm sure some IRC servers do). By splitting I mean making two > > messages out of it, so for example > > > > :nick!nick at irc.server.net PRIVMSG ulim : FOO.........BAR....... > > > > becomes > > > > :nick!nick at irc.server.net PRIVMSG ulim : FOO......... > > :nick!nick at irc.server.net PRIVMSG ulim : BAR....... > > > > How does irssi-otr detect and reassemble this: > > Ah, I see. So there's no actual framing, saying "this is fragment 1/3" > or anything like that. I guess what you're doing is about all you can > do, in that event. Yeah, the whole thing is only a workaround. The real problem is that the MMS on the other end is too high for IRC. Which wouldn't be the case if libotr chose the smaller MMS of the two peers on both ends. I imagine an additional field for the MMS in the initial message exchange would suffice. Or maybe even in the query message...something like ?OTR?MMS=416. Then all the other end has to do is compare its value and choose the smaller number. Such a change probably wouldn't be reasonable just for irssi-otr but I can imagine that this problem arises in other contexts where gatewaying or proxying is done as well. Uli From ian at cypherpunks.ca Wed Jul 16 08:34:21 2008 From: ian at cypherpunks.ca (Ian Goldberg) Date: Wed, 16 Jul 2008 08:34:21 -0400 Subject: [OTR-dev] irssi-otr 0.1 released In-Reply-To: <20080715230830.GA31379@nets.rwth-aachen.de> References: <20080619234833.GE8251@nets.rwth-aachen.de> <20080715085710.GA7420@gmail.com> <20080715120244.GT6417@yoink.cs.uwaterloo.ca> <20080715130932.GA16624@nets.rwth-aachen.de> <20080715140231.GB22444@thunk.cs.uwaterloo.ca> <20080715152600.GB16624@nets.rwth-aachen.de> <20080715213131.GV6417@yoink.cs.uwaterloo.ca> <20080715230830.GA31379@nets.rwth-aachen.de> Message-ID: <20080716123421.GB25650@thunk.cs.uwaterloo.ca> On Tue, Jul 15, 2008 at 11:08:00PM +0000, Uli M wrote: > On Tue 15.07.08 17:31, Ian Goldberg wrote: > > On Tue, Jul 15, 2008 at 03:25:30PM +0000, Uli M wrote: > > > IIRC bitlbee splits IRC messages longer than 512 bytes (note that an IRC > > > message also contains other stuff like nick and server, so the actually > > > payload should be less than that). I can be very thankful for that > > > because irssi-otr wouldn't exist if bitlbee would cut the messages off > > > (which I'm sure some IRC servers do). By splitting I mean making two > > > messages out of it, so for example > > > > > > :nick!nick at irc.server.net PRIVMSG ulim : FOO.........BAR....... > > > > > > becomes > > > > > > :nick!nick at irc.server.net PRIVMSG ulim : FOO......... > > > :nick!nick at irc.server.net PRIVMSG ulim : BAR....... > > > > > > How does irssi-otr detect and reassemble this: > > > > Ah, I see. So there's no actual framing, saying "this is fragment 1/3" > > or anything like that. I guess what you're doing is about all you can > > do, in that event. > > Yeah, the whole thing is only a workaround. The real problem is that the > MMS on the other end is too high for IRC. And that's because the other end thinks it's talking XMPP? It doesn't know that the buddy is actually on IRC? > Which wouldn't be the case if > libotr chose the smaller MMS of the two peers on both ends. I imagine an > additional field for the MMS in the initial message exchange would > suffice. Or maybe even in the query message...something like > ?OTR?MMS=416. Then all the other end has to do is compare its value and > choose the smaller number. Unfortunately, the latter is too ugly, even for me. :-) Not to mention that it would be nice if the MMS value were authenticated. And the former doesn't quite work, since the initial key exchange messages themselves need to be fragmented on IRC. > Such a change probably wouldn't be reasonable just for irssi-otr but I > can imagine that this problem arises in other contexts where gatewaying > or proxying is done as well. I guess the question is what delivery claims is bitlbee making? It's performing fragmentation, but it looks to me like it's up to every IRC client to do the defragmentation. Most of the time, the clients just do nothing, and display the fragmented messages to the user, which is close enough for plaintext, I suppose. - Ian From a.sporto+bee at gmail.com Wed Jul 16 12:18:19 2008 From: a.sporto+bee at gmail.com (Uli M) Date: Wed, 16 Jul 2008 16:18:19 +0000 (UTC) Subject: [OTR-dev] irssi-otr 0.1 released In-Reply-To: <20080716123421.GB25650@thunk.cs.uwaterloo.ca> References: <20080619234833.GE8251@nets.rwth-aachen.de> <20080715085710.GA7420@gmail.com> <20080715120244.GT6417@yoink.cs.uwaterloo.ca> <20080715130932.GA16624@nets.rwth-aachen.de> <20080715140231.GB22444@thunk.cs.uwaterloo.ca> <20080715152600.GB16624@nets.rwth-aachen.de> <20080715213131.GV6417@yoink.cs.uwaterloo.ca> <20080715230830.GA31379@nets.rwth-aachen.de> <20080716123421.GB25650@thunk.cs.uwaterloo.ca> Message-ID: <20080716161850.GA28169@nets.rwth-aachen.de> On Wed 16.07.08 08:34, Ian Goldberg wrote: > On Tue, Jul 15, 2008 at 11:08:00PM +0000, Uli M wrote: > > On Tue 15.07.08 17:31, Ian Goldberg wrote: > > > On Tue, Jul 15, 2008 at 03:25:30PM +0000, Uli M wrote: > > > > IIRC bitlbee splits IRC messages longer than 512 bytes (note that an IRC > > > > message also contains other stuff like nick and server, so the actually > > > > payload should be less than that). I can be very thankful for that > > > > because irssi-otr wouldn't exist if bitlbee would cut the messages off > > > > (which I'm sure some IRC servers do). By splitting I mean making two > > > > messages out of it, so for example > > > > > > > > :nick!nick at irc.server.net PRIVMSG ulim : FOO.........BAR....... > > > > > > > > becomes > > > > > > > > :nick!nick at irc.server.net PRIVMSG ulim : FOO......... > > > > :nick!nick at irc.server.net PRIVMSG ulim : BAR....... > > > > > > > > How does irssi-otr detect and reassemble this: > > > > > > Ah, I see. So there's no actual framing, saying "this is fragment 1/3" > > > or anything like that. I guess what you're doing is about all you can > > > do, in that event. > > > > Yeah, the whole thing is only a workaround. The real problem is that the > > MMS on the other end is too high for IRC. > > And that's because the other end thinks it's talking XMPP? It doesn't > know that the buddy is actually on IRC? Nope, bitlbee is a transparent IM-to-IRC gateway. The ICQ/Jabber/AIM/... end doesn't know that bitlbee is on the other end and the IRC end could know it (if someone told it how to recognize bitlbee) but doesn't need to know ;) And my assumption is that this situation(one end not knowing the MMS capabilities of the other) is not unique to bitlbee - but maybe I'm wrong. > > Which wouldn't be the case if > > libotr chose the smaller MMS of the two peers on both ends. I imagine an > > additional field for the MMS in the initial message exchange would > > suffice. Or maybe even in the query message...something like > > ?OTR?MMS=416. Then all the other end has to do is compare its value and > > choose the smaller number. > > Unfortunately, the latter is too ugly, even for me. :-) OK, I agree the query message isn't a very good place for it ;) > Not to mention that it would be nice if the MMS value were > authenticated. And the former doesn't quite work, since the initial > key exchange messages themselves need to be fragmented on IRC. Well since the MMS doesn't affect the generation of the encrypted messages themselves but only how they are delivered from A to B (as I understand it) I imagine it isn't much of a security risk. If that's true including it in the initial exchange wouldn't hurt. Another option would be to always use a low enough MMS for the initial exchange and when the connection is authenticated agree on a higher MMS. > > Such a change probably wouldn't be reasonable just for irssi-otr but I > > can imagine that this problem arises in other contexts where gatewaying > > or proxying is done as well. > > I guess the question is what delivery claims is bitlbee making? Well it can't really offer more than the underlying protocol which offers messages of up to about 500 bytes length (exact amount depends on how you count). As RFC 1459 and RFC 2812 state "There is no provision for continuation of message lines." so from the standards perspective that is all you have. > It's performing fragmentation, but it looks to me like it's up to > every IRC client to do the defragmentation. Seeing that there is no method for fragmentation in IRC bitlbee does the only sensible thing to do with overlong messages: it splits them up (fragmentation is a very nice word that ;) ). And I'm sure the developer who wrote that never thought an IRC client would want to reassemble these messages again into one. Luckily the OTR message format is (mostly) specific enough so that it works here. One could implement some kind of indication that splitting has taken place in bitlbee (and indeed I had some discussion about that with a bitlbee developer initially) but that would also require modification of the IRC client (which is probably why the devs wouldn't be very inclined to implement it). > Most of the time, the clients just do nothing, and display the > fragmented messages to the user, which is close enough for plaintext, > I suppose. Indeed. Since there is no client that has been written specifically for bitlbee. Uli From georgsievers at gmx.net Fri Jul 25 12:32:12 2008 From: georgsievers at gmx.net (Georg Sievers) Date: Fri, 25 Jul 2008 18:32:12 +0200 Subject: [OTR-dev] Bug in libotr-3.1 / 3.2: no herthbeat message is send Message-ID: <20080725163212.17730@gmx.net> Hallo, my name is Georg Sievers and I' m just working on a diploma thesis at the university of applied sciences TFH, Berlin, Germany, which deals with possible usecases for OTR/libotr beyond Instant Messaging. I belive I found a remarkable bug in libotr. In message.c, funktion "otrl_message_receiving" the field "edata.ignore_message" is initialised with "-1" (Line 747, libotr-3.2). In Line 1088 a check for "edata.ignore_message == 0" is performed, which will always evaluate to false, preventing the following hearthbeat-sending code from beeing executed. So no heartbeat messages are ever send. A quick fix should be changing "edata.ignore_message == 0" to "edata.ignore_message != 1" (line 1088). Wathsoever, I don't feel to comfortable with having "ignore_message" set to an initale state "-1" at all. As far as I understood the code, their doesn't seem to be a good reason for having a three-state flag at this point. I could offer to deliver a patch for this issue but first wanted to ask if there is some reason I have missed for doing it the way it is done. - Georg Sievers From georgsievers at gmx.net Fri Jul 25 12:56:48 2008 From: georgsievers at gmx.net (Georg Sievers) Date: Fri, 25 Jul 2008 18:56:48 +0200 Subject: [OTR-dev] Correction: Bug in libotr-3.1 / 3.2: no hearthbeat message is send In-Reply-To: <20080725163212.17730@gmx.net> References: <20080725163212.17730@gmx.net> Message-ID: <20080725165648.17750@gmx.net> Hallo, the coorect location of the bug is not line numner 1088 but line number 1138: "} else if (edata.ignore_message == 0 && " in libotr release_3_2_0 , revision 1.12. Sorry for causing confusion. - Georg