From ptierney at ucla.edu  Thu Feb 11 01:37:31 2010
From: ptierney at ucla.edu (Patrick Tierney)
Date: Thu, 11 Feb 2010 01:37:31 -0500
Subject: [OTR-dev] OTR Perl Module
Message-ID: <b61e1831002102237x710c80ecm62ac20934e734752@mail.gmail.com>

OTR Developers,

I'd like to let everyone know about a new Perl module to do OTR
communication.  It's called Crypt::OTR, and allows you to encrypt text, or
any serialized data.

We've only got the most basic features working, OTR encryption/decryption
and the generation of necessary tab communications, but we're looking to add
signing and verifying too.  We'd love it if some people could test the
module, or even verify the security of the data it produces.  Also, if
anyone's a C guru, we'd appreciate any pointers on the code.

Here's a link to the site module:
http://search.cpan.org/perldoc?Crypt::OTR

Thanks,

Mischa Spiegelmock and Patrick Tierney
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cypherpunks.ca/pipermail/otr-dev/attachments/20100211/8a5265c9/attachment.html>

From ian at cypherpunks.ca  Thu Feb 11 19:05:14 2010
From: ian at cypherpunks.ca (Ian Goldberg)
Date: Thu, 11 Feb 2010 19:05:14 -0500
Subject: [OTR-dev] OTR Perl Module
In-Reply-To: <b61e1831002102237x710c80ecm62ac20934e734752@mail.gmail.com>
References: <b61e1831002102237x710c80ecm62ac20934e734752@mail.gmail.com>
Message-ID: <20100212000514.GO22151@yoink.cs.uwaterloo.ca>

On Thu, Feb 11, 2010 at 01:37:31AM -0500, Patrick Tierney wrote:
> OTR Developers,
> 
> I'd like to let everyone know about a new Perl module to do OTR
> communication.  It's called Crypt::OTR, and allows you to encrypt text, or
> any serialized data.
> 
> We've only got the most basic features working, OTR encryption/decryption
> and the generation of necessary tab communications, but we're looking to add
> signing and verifying too.  We'd love it if some people could test the
> module, or even verify the security of the data it produces.  Also, if
> anyone's a C guru, we'd appreciate any pointers on the code.
> 
> Here's a link to the site module:
> http://search.cpan.org/perldoc?Crypt::OTR

Very cool!  Is there a perl-based IM client you're targetting, or just
getting it to work for perl in general?

   - Ian


From ptierney at ucla.edu  Fri Feb 12 23:31:29 2010
From: ptierney at ucla.edu (Patrick Tierney)
Date: Fri, 12 Feb 2010 23:31:29 -0500
Subject: [OTR-dev] OTR-dev Digest, Vol 16, Issue 2
In-Reply-To: <mailman.1.1265974131.20313.otr-dev@lists.cypherpunks.ca>
References: <mailman.1.1265974131.20313.otr-dev@lists.cypherpunks.ca>
Message-ID: <b61e1831002122031l4869c0ccuded87905dd7f99bd@mail.gmail.com>

Hey,

We weren't targeting it at IM in particular. Considering that Perl has
modules to handle all sorts of data, the plugin could expand OTR to secure
many new types of communication (file exchange, voice, video).

Patrick

On Fri, Feb 12, 2010 at 6:28 AM, <otr-dev-request at lists.cypherpunks.ca>wrote:

> Send OTR-dev mailing list submissions to
>        otr-dev at lists.cypherpunks.ca
>
> To subscribe or unsubscribe via the World Wide Web, visit
>        http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
> or, via email, send a message with subject or body 'help' to
>        otr-dev-request at lists.cypherpunks.ca
>
> You can reach the person managing the list at
>        otr-dev-owner at lists.cypherpunks.ca
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of OTR-dev digest..."
>
>
> Today's Topics:
>
>   1. Re: OTR Perl Module (Ian Goldberg)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 11 Feb 2010 19:05:14 -0500
> From: Ian Goldberg <ian at cypherpunks.ca>
> Subject: Re: [OTR-dev] OTR Perl Module
> To: otr-dev at lists.cypherpunks.ca
> Message-ID: <20100212000514.GO22151 at yoink.cs.uwaterloo.ca>
> Content-Type: text/plain; charset=us-ascii
>
> On Thu, Feb 11, 2010 at 01:37:31AM -0500, Patrick Tierney wrote:
> > OTR Developers,
> >
> > I'd like to let everyone know about a new Perl module to do OTR
> > communication.  It's called Crypt::OTR, and allows you to encrypt text,
> or
> > any serialized data.
> >
> > We've only got the most basic features working, OTR encryption/decryption
> > and the generation of necessary tab communications, but we're looking to
> add
> > signing and verifying too.  We'd love it if some people could test the
> > module, or even verify the security of the data it produces.  Also, if
> > anyone's a C guru, we'd appreciate any pointers on the code.
> >
> > Here's a link to the site module:
> > http://search.cpan.org/perldoc?Crypt::OTR
>
> Very cool!  Is there a perl-based IM client you're targetting, or just
> getting it to work for perl in general?
>
>   - Ian
>
>
> ------------------------------
>
> _______________________________________________
> OTR-dev mailing list
> OTR-dev at lists.cypherpunks.ca
> http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
>
>
> End of OTR-dev Digest, Vol 16, Issue 2
> **************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cypherpunks.ca/pipermail/otr-dev/attachments/20100212/075f9bb2/attachment.html>

From stpeter at stpeter.im  Sat Feb 13 00:24:10 2010
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Fri, 12 Feb 2010 22:24:10 -0700
Subject: [OTR-dev] OTR-dev Digest, Vol 16, Issue 2
In-Reply-To: <b61e1831002122031l4869c0ccuded87905dd7f99bd@mail.gmail.com>
References: <mailman.1.1265974131.20313.otr-dev@lists.cypherpunks.ca>
	<b61e1831002122031l4869c0ccuded87905dd7f99bd@mail.gmail.com>
Message-ID: <4B76377A.709@stpeter.im>

On 2/12/10 9:31 PM, Patrick Tierney wrote:

> We weren't targeting it at IM in particular. Considering that Perl has
> modules to handle all sorts of data, the plugin could expand OTR to
> secure many new types of communication (file exchange, voice, video).

Sounds intriguing. I'd be curious to hear how you propose to do that. My
understanding of OTR has always been that it is designed to exchange
basic text messages and perhaps XHTML-formatted versions of those
messages, but not the kind of extended data that is necessary to
negotiate multimedia sessions and not the data itself (which might be
transferred via direct TCP streams, UDP associations, media relays, and
the like).

Peter

-- 
Peter Saint-Andre
https://stpeter.im/



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6820 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.cypherpunks.ca/pipermail/otr-dev/attachments/20100212/7fd9b3df/attachment.bin>

From ian at cypherpunks.ca  Sat Feb 13 09:35:40 2010
From: ian at cypherpunks.ca (Ian Goldberg)
Date: Sat, 13 Feb 2010 09:35:40 -0500
Subject: [OTR-dev] OTR-dev Digest, Vol 16, Issue 2
In-Reply-To: <4B76377A.709@stpeter.im>
References: <mailman.1.1265974131.20313.otr-dev@lists.cypherpunks.ca>
	<b61e1831002122031l4869c0ccuded87905dd7f99bd@mail.gmail.com>
	<4B76377A.709@stpeter.im>
Message-ID: <20100213143540.GA9748@yoink.cs.uwaterloo.ca>

On Fri, Feb 12, 2010 at 10:24:10PM -0700, Peter Saint-Andre wrote:
> On 2/12/10 9:31 PM, Patrick Tierney wrote:
> 
> > We weren't targeting it at IM in particular. Considering that Perl has
> > modules to handle all sorts of data, the plugin could expand OTR to
> > secure many new types of communication (file exchange, voice, video).
> 
> Sounds intriguing. I'd be curious to hear how you propose to do that. My
> understanding of OTR has always been that it is designed to exchange
> basic text messages and perhaps XHTML-formatted versions of those
> messages, but not the kind of extended data that is necessary to
> negotiate multimedia sessions and not the data itself (which might be
> transferred via direct TCP streams, UDP associations, media relays, and
> the like).

There's nothing preventing the underlying OTR protocol from being used
to protect arbitrary binary data, so long as the network model
(unreliable, but in-order, delivery) is preserved.  The protocol spec
only says how to use it for IM messages, but someone could easily write
a spec for OTR-protected VoIP, for example.  [You'd probably want to
rekey a little less often, perhaps.]

   - Ian


From interrupt80h at gmail.com  Sat Feb 13 14:19:07 2010
From: interrupt80h at gmail.com (interrupt80h at gmail.com)
Date: Sat, 13 Feb 2010 11:19:07 -0800
Subject: [OTR-dev] OTR-dev Digest, Vol 16, Issue 2
In-Reply-To: <20100213143540.GA9748@yoink.cs.uwaterloo.ca>
References: <mailman.1.1265974131.20313.otr-dev@lists.cypherpunks.ca>
	<b61e1831002122031l4869c0ccuded87905dd7f99bd@mail.gmail.com>
	<4B76377A.709@stpeter.im>
	<20100213143540.GA9748@yoink.cs.uwaterloo.ca>
Message-ID: <F79BB9AC-B422-4295-9EBC-ACC25B92E361@gmail.com>

We're not just interested in securing the communications, but also using it for identity verification and message signing. That said, I couldn't find documentation anywhere for the functions otrl_privkey_sign() and otrl_privkey_verify() and we've had some difficulty getting them to work properly. Are there any examples of how to properly use them, in particular creating the pubkey object to pass to verify?

Does this look at all correct:

SV* crypt_otr_get_pubkey_str( CryptOTRUserState in_state, char *account, char *proto, int maxsize ) {
  OtrlPrivKey *privkey = crypt_otr_get_privkey( in_state, account, proto, maxsize );
  SV *privkey_sv = newSVpvn(privkey->pubkey_data, privkey->pubkey_datalen);
  return privkey_sv;
}

unsigned int crypt_otr_verify( unsigned char *msghash, unsigned char *sig, unsigned char *pubkey_data,
                               size_t pubkey_length, unsigned short pubkey_type) {

  // create s-expression object representing the public key
  gcry_sexp_t pubkey;

  gcry_sexp_new(&pubkey, pubkey_data, pubkey_length, 1);

  gcry_error_t err = otrl_privkey_verify( sig, strlen(sig), pubkey_type, pubkey, msghash, strlen(msghash) );

  gcry_sexp_release(pubkey);

  return err == 0;
}



On Feb 13, 2010, at 6:35 AM, Ian Goldberg wrote:

> On Fri, Feb 12, 2010 at 10:24:10PM -0700, Peter Saint-Andre wrote:
>> On 2/12/10 9:31 PM, Patrick Tierney wrote:
>> 
>>> We weren't targeting it at IM in particular. Considering that Perl has
>>> modules to handle all sorts of data, the plugin could expand OTR to
>>> secure many new types of communication (file exchange, voice, video).
>> 
>> Sounds intriguing. I'd be curious to hear how you propose to do that. My
>> understanding of OTR has always been that it is designed to exchange
>> basic text messages and perhaps XHTML-formatted versions of those
>> messages, but not the kind of extended data that is necessary to
>> negotiate multimedia sessions and not the data itself (which might be
>> transferred via direct TCP streams, UDP associations, media relays, and
>> the like).
> 
> There's nothing preventing the underlying OTR protocol from being used
> to protect arbitrary binary data, so long as the network model
> (unreliable, but in-order, delivery) is preserved.  The protocol spec
> only says how to use it for IM messages, but someone could easily write
> a spec for OTR-protected VoIP, for example.  [You'd probably want to
> rekey a little less often, perhaps.]
> 
>   - Ian
> _______________________________________________
> OTR-dev mailing list
> OTR-dev at lists.cypherpunks.ca
> http://lists.cypherpunks.ca/mailman/listinfo/otr-dev



From louis.granboulan.developer at gmail.com  Thu Feb 18 12:42:33 2010
From: louis.granboulan.developer at gmail.com (Louis Granboulan)
Date: Thu, 18 Feb 2010 18:42:33 +0100
Subject: [OTR-dev] OTR using PAKE and for group chat
Message-ID: <7da5e7281002180942j769f1c23hb672bf45b514696e@mail.gmail.com>

Dear all,

I would like to add to an instant messenging framework an end-to-end
password-based security layer. Therefore, instead of relying on a accepting
a public key like OTR, the authentication would rely on a shared password
(cf. http://en.wikipedia.org/wiki/Password-authenticated_key_agreement )
It appears that instead of re-doing everything from scratch, a better way
might be to add this possibility to the already existing OTR framework.

However, this would imply some important changes to the OTR library, by
adding a non-OTR protocol, and I would like to know if these changes can go
mainstream when the implementation would be stable.
Moreover, I would like to extend the PAKE security to group PAKE if the
encryption is started within a multi-user group chat. I did not see any
discussion on how to interface the OTR library with group chat.

Thank you,
Louis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cypherpunks.ca/pipermail/otr-dev/attachments/20100218/d3db1ccb/attachment.html>

From ian at cypherpunks.ca  Fri Feb 19 07:31:31 2010
From: ian at cypherpunks.ca (Ian Goldberg)
Date: Fri, 19 Feb 2010 07:31:31 -0500
Subject: [OTR-dev] OTR using PAKE and for group chat
In-Reply-To: <7da5e7281002180942j769f1c23hb672bf45b514696e@mail.gmail.com>
References: <7da5e7281002180942j769f1c23hb672bf45b514696e@mail.gmail.com>
Message-ID: <20100219123131.GL8930@yoink.cs.uwaterloo.ca>

On Thu, Feb 18, 2010 at 06:42:33PM +0100, Louis Granboulan wrote:
> Dear all,
> 
> I would like to add to an instant messenging framework an end-to-end
> password-based security layer. Therefore, instead of relying on a accepting
> a public key like OTR, the authentication would rely on a shared password
> (cf. http://en.wikipedia.org/wiki/Password-authenticated_key_agreement )
> It appears that instead of re-doing everything from scratch, a better way
> might be to add this possibility to the already existing OTR framework.
> 
> However, this would imply some important changes to the OTR library, by
> adding a non-OTR protocol, and I would like to know if these changes can go
> mainstream when the implementation would be stable.
> Moreover, I would like to extend the PAKE security to group PAKE if the
> encryption is started within a multi-user group chat. I did not see any
> discussion on how to interface the OTR library with group chat.

OTR already has a mechanism for authenticating with a shared secret.
Can you describe the advantages of your proposal over that?

As for group chat, it's work in progress.  We had a paper a few months
ago in ACM CCS describing a protocol for it, but quite a bit more work
still needs to be done.

   - Ian


From linux at tjworld.net  Sun Feb 21 09:08:54 2010
From: linux at tjworld.net (TJ)
Date: Sun, 21 Feb 2010 14:08:54 +0000
Subject: [OTR-dev] Chatzilla and/or Javascript library?
Message-ID: <1266761334.4984.58.camel@hephaestion>

I was wondering if there is a chatzilla plug-in for OTR or a Javascript
library that could be modified to support chatzilla?

My reason for asking is that I'm currently developing a cross-platform
private social networking application.

I chose to use Mozilla/Firefox as the base since its XPCOM makes it
relatively easy (after the XPCOM learning curve!) to develop a single
source-code solution for GNU/Linux, OS-X, and Windows without requiring
native libraries.

IRC will be the primary interactive medium, using SSL to secure
client<>server and OTR for user<>user communications.

If one isn't available would the OTR developers be willing to assist
with advice if I were to develop a Javascript library that mirrors
libotr which could then be wrapped for Chatzilla or other applications?

Alongside the IRC layer I am building a SWF video/audio layer, utilising
Red5 (for now) as the media server. I'm also working on adding the
support to Gnash and its media-server Cygnal to provide a fully
open-source solution that doesn't require a Java server.

Therefore I'm interested in hearing how user<>user multimedia streams
might be protected using OTR. I assume OTR would protect the packet data
but not the stream itself - that would allow the media server to relay
the streams without knowing/caring about OTR.

What thoughts have there been on the issues that multimedia protection
would have to overcome?

If it is practical I would implement the necessary wrapper in Gnash.





From michael_zanetti at gmx.net  Sun Feb 21 17:52:10 2010
From: michael_zanetti at gmx.net (Michael Zanetti)
Date: Sun, 21 Feb 2010 23:52:10 +0100
Subject: [OTR-dev] asynchronous privkey creation
Message-ID: <201002212352.17041.michael_zanetti@gmx.net>

Hi otr devs,

I'm the author of Kopetes otr plugin. Reading through the archives I have 
found a thread [1] discussing asynchronous creation of private keys. However, 
I haven't found a conclusion to this and would like to know what your plans 
are regarding this issue.

In kopetes otr plugin I have done my own thread that generates the private key 
to keep the UI updated but I'm blocking user input and socket notifiers (to 
prevent incoming messages jumping into libotr). This has been working fine for 
Kopete at KDE 3 times, but doesn't work any more in KDE4 as incoming messages 
are processed and I have no way to stop that within the plugin. The only way 
to fix that without blocking, would be to keep the list of incoming messages 
and re-process them all once the key generation has finshed. Also the previous 
discussion mentioned that this seems not to be a good option.

Do you have any suggestions how to deal with this issue? Should I implement 
the above mentioned workaround or should I wait for an updated version of the 
lib that adresses the issue?

Thanks,
Michael

[1] http://lists.cypherpunks.ca/pipermail/otr-dev/2008-June/000890.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.cypherpunks.ca/pipermail/otr-dev/attachments/20100221/e288488b/attachment.pgp>

From michael_zanetti at gmx.net  Sun Feb 21 18:08:30 2010
From: michael_zanetti at gmx.net (Michael Zanetti)
Date: Mon, 22 Feb 2010 00:08:30 +0100
Subject: [OTR-dev] Conversion of unencrypted messages to system-messages
Message-ID: <201002220008.34149.michael_zanetti@gmx.net>

Hi,

its me again. I decided to divide my requests into different mails to keep the 
discussions sorted.

The current implementation of kopete's otr plugin uses a message type called 
"Internal" to display messages generated in display_otr_message(). Those 
internal messages fit perfectly into Kopetes design, indicating encryption 
state changes and other notifications of the lib to the user in a way that 
they do not disturb the user but are definetly noticed. Such messages (also 
used for other types of notifications like online status changes) do neither 
produce system notification events nor get logged in chat history.

The problem now is, that incoming unencrypted messages during an established 
otr session are transformed into such messages because they are delivered 
using display_otr_message(). This leaves kopete users often in the situation 
that they do not notice such incoming messages or loose them in chat 
histories.

Could you think of a way to change that in future versions of libotr to keep 
the actual message as a normal message but informing the user in some other 
way of the unencrypted state of this message? Perhaps just leave it as a 
normal message, but prepend the usual warning. Or maybe better, split the 
warning message and the actual message into two, leaving the warning as an 
internal message, but delivering the actual message as a normal one?

This is one example bug-report I get for this issue:
https://bugs.kde.org/show_bug.cgi?id=204502

Cheers,
Michael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.cypherpunks.ca/pipermail/otr-dev/attachments/20100222/d09cc6c5/attachment.pgp>

From ian at cypherpunks.ca  Sun Feb 21 18:08:53 2010
From: ian at cypherpunks.ca (Ian Goldberg)
Date: Sun, 21 Feb 2010 18:08:53 -0500
Subject: [OTR-dev] Chatzilla and/or Javascript library?
In-Reply-To: <1266761334.4984.58.camel@hephaestion>
References: <1266761334.4984.58.camel@hephaestion>
Message-ID: <20100221230853.GJ20344@yoink.cs.uwaterloo.ca>

On Sun, Feb 21, 2010 at 02:08:54PM +0000, TJ wrote:
> I was wondering if there is a chatzilla plug-in for OTR or a Javascript
> library that could be modified to support chatzilla?
> 
> My reason for asking is that I'm currently developing a cross-platform
> private social networking application.
> 
> I chose to use Mozilla/Firefox as the base since its XPCOM makes it
> relatively easy (after the XPCOM learning curve!) to develop a single
> source-code solution for GNU/Linux, OS-X, and Windows without requiring
> native libraries.

A Javascript port of libotr would be very useful.  I imagine someone
could plug it into the web-based GTalk for some added coolness.  There
are certainly Javascript crypto and bignum libraries you could use to
start with.

My suggestion is to do what we did for the Java port: work from the
spec, but check out the C version if something's unclear.  Of course,
now you could choose to look at either the C or the Java version.  ;-)

   - Ian


From ian at cypherpunks.ca  Sun Feb 21 18:13:58 2010
From: ian at cypherpunks.ca (Ian Goldberg)
Date: Sun, 21 Feb 2010 18:13:58 -0500
Subject: [OTR-dev] asynchronous privkey creation
In-Reply-To: <201002212352.17041.michael_zanetti@gmx.net>
References: <201002212352.17041.michael_zanetti@gmx.net>
Message-ID: <20100221231358.GK20344@yoink.cs.uwaterloo.ca>

On Sun, Feb 21, 2010 at 11:52:10PM +0100, Michael Zanetti wrote:
> Hi otr devs,
> 
> I'm the author of Kopetes otr plugin. Reading through the archives I have 
> found a thread [1] discussing asynchronous creation of private keys. However, 
> I haven't found a conclusion to this and would like to know what your plans 
> are regarding this issue.
> 
> In kopetes otr plugin I have done my own thread that generates the private key 
> to keep the UI updated but I'm blocking user input and socket notifiers (to 
> prevent incoming messages jumping into libotr). This has been working fine for 
> Kopete at KDE 3 times, but doesn't work any more in KDE4 as incoming messages 
> are processed and I have no way to stop that within the plugin. The only way 
> to fix that without blocking, would be to keep the list of incoming messages 
> and re-process them all once the key generation has finshed. Also the previous 
> discussion mentioned that this seems not to be a good option.
> 
> Do you have any suggestions how to deal with this issue? Should I implement 
> the above mentioned workaround or should I wait for an updated version of the 
> lib that adresses the issue?
> 
> Thanks,
> Michael
> 
> [1] http://lists.cypherpunks.ca/pipermail/otr-dev/2008-June/000890.html

It's in the sourceforge CVS already.  You could use the CVS version, or
just pick out the June/July 2008 changes from privkey.[ch].

   - Ian


From ian at cypherpunks.ca  Sun Feb 21 18:18:32 2010
From: ian at cypherpunks.ca (Ian Goldberg)
Date: Sun, 21 Feb 2010 18:18:32 -0500
Subject: [OTR-dev] Conversion of unencrypted messages to system-messages
In-Reply-To: <201002220008.34149.michael_zanetti@gmx.net>
References: <201002220008.34149.michael_zanetti@gmx.net>
Message-ID: <20100221231832.GL20344@yoink.cs.uwaterloo.ca>

On Mon, Feb 22, 2010 at 12:08:30AM +0100, Michael Zanetti wrote:
> Hi,
> 
> its me again. I decided to divide my requests into different mails to keep the 
> discussions sorted.
> 
> The current implementation of kopete's otr plugin uses a message type called 
> "Internal" to display messages generated in display_otr_message(). Those 
> internal messages fit perfectly into Kopetes design, indicating encryption 
> state changes and other notifications of the lib to the user in a way that 
> they do not disturb the user but are definetly noticed. Such messages (also 
> used for other types of notifications like online status changes) do neither 
> produce system notification events nor get logged in chat history.
> 
> The problem now is, that incoming unencrypted messages during an established 
> otr session are transformed into such messages because they are delivered 
> using display_otr_message(). This leaves kopete users often in the situation 
> that they do not notice such incoming messages or loose them in chat 
> histories.
> 
> Could you think of a way to change that in future versions of libotr to keep 
> the actual message as a normal message but informing the user in some other 
> way of the unencrypted state of this message? Perhaps just leave it as a 
> normal message, but prepend the usual warning. Or maybe better, split the 
> warning message and the actual message into two, leaving the warning as an 
> internal message, but delivering the actual message as a normal one?
> 
> This is one example bug-report I get for this issue:
> https://bugs.kde.org/show_bug.cgi?id=204502

The new API in CVS passes such unexpected unencrypted messages to the
application via the hangle_msg_event callback, with the OtrlMessageEvent
type OTRL_MSGEVENT_RCVDMSG_UNENCRYPTED.  Your application can then do
whatever it likes with the message.  One of the features of the new API
is that it removes all of the English and HTML from libotr so that it's
more useful in a variety of projects.

   - Ian


From michael_zanetti at gmx.net  Sun Feb 21 18:23:03 2010
From: michael_zanetti at gmx.net (Michael Zanetti)
Date: Mon, 22 Feb 2010 00:23:03 +0100
Subject: [OTR-dev] asynchronous privkey creation
In-Reply-To: <20100221231358.GK20344@yoink.cs.uwaterloo.ca>
References: <201002212352.17041.michael_zanetti@gmx.net>
	<20100221231358.GK20344@yoink.cs.uwaterloo.ca>
Message-ID: <201002220023.06239.michael_zanetti@gmx.net>

On Monday 22 February 2010 00:13:58 Ian Goldberg wrote:
> On Sun, Feb 21, 2010 at 11:52:10PM +0100, Michael Zanetti wrote:
> > Hi otr devs,
> > 
> > I'm the author of Kopetes otr plugin. Reading through the archives I have
> > found a thread [1] discussing asynchronous creation of private keys.
> > However, I haven't found a conclusion to this and would like to know
> > what your plans are regarding this issue.
> > 
> > In kopetes otr plugin I have done my own thread that generates the
> > private key to keep the UI updated but I'm blocking user input and
> > socket notifiers (to prevent incoming messages jumping into libotr).
> > This has been working fine for Kopete at KDE 3 times, but doesn't work
> > any more in KDE4 as incoming messages are processed and I have no way to
> > stop that within the plugin. The only way to fix that without blocking,
> > would be to keep the list of incoming messages and re-process them all
> > once the key generation has finshed. Also the previous discussion
> > mentioned that this seems not to be a good option.
> > 
> > Do you have any suggestions how to deal with this issue? Should I
> > implement the above mentioned workaround or should I wait for an updated
> > version of the lib that adresses the issue?
> > 
> > Thanks,
> > Michael
> > 
> > [1] http://lists.cypherpunks.ca/pipermail/otr-dev/2008-June/000890.html
> 
> It's in the sourceforge CVS already.  You could use the CVS version, or
> just pick out the June/July 2008 changes from privkey.[ch].
> 

Great! But I cannot add a dependency to a cvs version or patched version of 
libotr to KDE. Any plans already when this change will hit the public?

Michael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.cypherpunks.ca/pipermail/otr-dev/attachments/20100222/88e61606/attachment.pgp>

From linux at tjworld.net  Sun Feb 21 18:23:43 2010
From: linux at tjworld.net (TJ)
Date: Sun, 21 Feb 2010 23:23:43 +0000
Subject: [OTR-dev] Chatzilla and/or Javascript library?
In-Reply-To: <20100221230853.GJ20344@yoink.cs.uwaterloo.ca>
References: <1266761334.4984.58.camel@hephaestion>
	<20100221230853.GJ20344@yoink.cs.uwaterloo.ca>
Message-ID: <1266794623.4984.74.camel@hephaestion>

On Sun, 2010-02-21 at 18:08 -0500, Ian Goldberg wrote:
> On Sun, Feb 21, 2010 at 02:08:54PM +0000, TJ wrote:
> > I was wondering if there is a chatzilla plug-in for OTR or a Javascript
> > library that could be modified to support chatzilla?
> > 
> > My reason for asking is that I'm currently developing a cross-platform
> > private social networking application.
> > 
> > I chose to use Mozilla/Firefox as the base since its XPCOM makes it
> > relatively easy (after the XPCOM learning curve!) to develop a single
> > source-code solution for GNU/Linux, OS-X, and Windows without requiring
> > native libraries.
> 
> A Javascript port of libotr would be very useful.  I imagine someone
> could plug it into the web-based GTalk for some added coolness.  There
> are certainly Javascript crypto and bignum libraries you could use to
> start with.
> 
> My suggestion is to do what we did for the Java port: work from the
> spec, but check out the C version if something's unclear.  Of course,
> now you could choose to look at either the C or the Java version.  ;-)

Hi Ian.

That was how I was going to approach it; try to ensure in as much as is
possible to maintain the same API.

It is a while since I did any heavy-lifting with Javascript (these days
I mostly do kernel hacking but I've a long history with Java and C++).

I'll put it on my To-Do list and get back to the -dev list once I'm
thinking about it and I've got my head around the XPCOM spaghetti.



From ian at cypherpunks.ca  Sun Feb 21 18:40:32 2010
From: ian at cypherpunks.ca (Ian Goldberg)
Date: Sun, 21 Feb 2010 18:40:32 -0500
Subject: [OTR-dev] asynchronous privkey creation
In-Reply-To: <201002220023.06239.michael_zanetti@gmx.net>
References: <201002212352.17041.michael_zanetti@gmx.net>
	<20100221231358.GK20344@yoink.cs.uwaterloo.ca>
	<201002220023.06239.michael_zanetti@gmx.net>
Message-ID: <20100221234032.GO20344@yoink.cs.uwaterloo.ca>

On Mon, Feb 22, 2010 at 12:23:03AM +0100, Michael Zanetti wrote:
> Great! But I cannot add a dependency to a cvs version or patched version of 
> libotr to KDE. Any plans already when this change will hit the public?

I know there's a bunch of stuff in CVS, and more stuff in git, that
desparately wants attention.

The problem is there's no one other than me working on OTR right now,
and I'm also not working on OTR right now.  :-(  It makes me sad to let
the project languish, but my cycles are unfortunately limited.

So: I'd like some volunteers to help package/clean/finish the stuff in
CVS and git.  The main changes:

- The API cleanup (I'd call it done; it's been in CVS for a while)
- The fix for people logged in multiple times: this is a protocol
  change, and so serious business.  It's in git, but last I heard there
  were stray interoperability problems with the current version.  So
  this needs more testing before it can be released.
- The beginnings of OTR-protected file transfer were implemented during
  the last GSoC.  It sends files over the IM channel, not over an
  out-of-band channel the way files are normally sent.  This of course
  may upset IM server operators.  I think it also blocks the IM
  conversation until the file is completely transmitted.  This is of
  course only useful for small files.  So a triage would have to happen
  here.
- While we're doing a protocol change, I wanted to tweak the key
  exchange to add a little bit of extra deniability.  But it's looking
  like I just won't have the cycles for that, so I'm willing to let it
  slide for wire protocol version 3.

If one or more people are willing to help, I'm willing to set up a
conference call or chat room or something like that to discuss details.

Thanks, and let me know.

   - Ian


From govnototalitarizm at gmail.com  Sun Feb 21 19:05:52 2010
From: govnototalitarizm at gmail.com (M)
Date: Mon, 22 Feb 2010 01:05:52 +0100
Subject: [OTR-dev] asynchronous privkey creation
In-Reply-To: <20100221234032.GO20344@yoink.cs.uwaterloo.ca>
References: <201002212352.17041.michael_zanetti@gmx.net>	<20100221231358.GK20344@yoink.cs.uwaterloo.ca>	<201002220023.06239.michael_zanetti@gmx.net>
	<20100221234032.GO20344@yoink.cs.uwaterloo.ca>
Message-ID: <4B81CA60.8000509@gmail.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ian Goldberg ?????:
> - The beginnings of OTR-protected file transfer were implemented during
>   the last GSoC.  It sends files over the IM channel, not over an
>   out-of-band channel the way files are normally sent.  This of course
>   may upset IM server operators.  I think it also blocks the IM
>   conversation until the file is completely transmitted.  This is of
>   course only useful for small files.  So a triage would have to happen
>   here.

Small update regarding this part because I was the student working on it.
Code is in git but it needs review by somebody experienced with otr\pidgin internals:
the main problem is that I was unable to correctly retrieve appropriate session
context e. g. map between OTR session and pidgin session.
For small files (<64k as far as I remember) it was working just fine.

Unfortunately I'm pretty busy with study assignments a.t.m. but I hope to have more
time later in spring.

cheers,
Max.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkuBymAACgkQe1oVzc159G/77QCfbna9CyUhjVXDMn499EfTy4HH
oYYAn0KU+Q7JUJ8urS6KRK9DnhtUMK88
=CXcZ
-----END PGP SIGNATURE-----


From michael_zanetti at gmx.net  Mon Feb 22 02:53:35 2010
From: michael_zanetti at gmx.net (Michael Zanetti)
Date: Mon, 22 Feb 2010 08:53:35 +0100
Subject: [OTR-dev] asynchronous privkey creation
In-Reply-To: <20100221234032.GO20344@yoink.cs.uwaterloo.ca>
References: <201002212352.17041.michael_zanetti@gmx.net>
	<201002220023.06239.michael_zanetti@gmx.net>
	<20100221234032.GO20344@yoink.cs.uwaterloo.ca>
Message-ID: <201002220853.40085.michael_zanetti@gmx.net>

On Monday 22 February 2010 00:40:32 Ian Goldberg wrote:
> On Mon, Feb 22, 2010 at 12:23:03AM +0100, Michael Zanetti wrote:
> > Great! But I cannot add a dependency to a cvs version or patched version
> > of libotr to KDE. Any plans already when this change will hit the
> > public?
> 
> I know there's a bunch of stuff in CVS, and more stuff in git, that
> desparately wants attention.
> 
> The problem is there's no one other than me working on OTR right now,
> and I'm also not working on OTR right now.  :-(  It makes me sad to let
> the project languish, but my cycles are unfortunately limited.
> 

I see... Indeed, it would be very sad to let those new changes molder in some 
repositories....

> So: I'd like some volunteers to help package/clean/finish the stuff in
> CVS and git.  The main changes:
> 
> - The API cleanup (I'd call it done; it's been in CVS for a while)
> - The fix for people logged in multiple times: this is a protocol
>   change, and so serious business.  It's in git, but last I heard there
>   were stray interoperability problems with the current version.  So
>   this needs more testing before it can be released.
> - The beginnings of OTR-protected file transfer were implemented during
>   the last GSoC.  It sends files over the IM channel, not over an
>   out-of-band channel the way files are normally sent.  This of course
>   may upset IM server operators.  I think it also blocks the IM
>   conversation until the file is completely transmitted.  This is of
>   course only useful for small files.  So a triage would have to happen
>   here.
> - While we're doing a protocol change, I wanted to tweak the key
>   exchange to add a little bit of extra deniability.  But it's looking
>   like I just won't have the cycles for that, so I'm willing to let it
>   slide for wire protocol version 3.
> 
> If one or more people are willing to help, I'm willing to set up a
> conference call or chat room or something like that to discuss details.
> 
> Thanks, and let me know.
> 

Well, currently I cannot guarantee to have enough time for such tasks 
(especially since I have about zero knowledge of libotr internals) because I 
should write a Masters Thesis while working for a company and there are still 
plenty of tasks in KDE waiting for my little bit of spare time.... However, If 
I find some time I could at least check out the latest changes and test them 
to provide some feedback. But don't count on me as a developer resource right 
now.

Anyways, thank you very much for your work on libotr.

Cheers,
Michael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.cypherpunks.ca/pipermail/otr-dev/attachments/20100222/a20920d6/attachment.pgp>