From chris-tuchs at hushmail.com  Wed Jul  8 20:05:31 2009
From: chris-tuchs at hushmail.com (chris-tuchs at hushmail.com)
Date: Wed, 08 Jul 2009 17:05:31 -0700
Subject: [OTR-dev] OTR + Second Life Client
Message-ID: <20090709000531.8D3D5B8040@smtp.hushmail.com>

Ian, thanks for the pointers they were just what I needed.  I now 
have libotr, libgcrypt, and libgpg-error all building as part of 
the second life client.  So I am about to actually start writing 
code to use OTR now.  Yay!

However a niggling feature request keeps coming up, at the least it 
is a request for education.  How can OTR be used for more than two 
people to share an off the record conversation?


On Thu, 25 Jun 2009 08:59:55 -0700 Ian Goldberg 
<ian at cypherpunks.ca> wrote:
[...snip...]
>So you could either get libotr to build under Visual C++ (which I 
>think the Trillian plugin author did:
>http://trillianotr.kittyfox.net/downloads.php )
[...snip...]

--
Click now to get the general liability insurance you need to protect yourself!
 http://tagline.hushmail.com/fc/BLSrjkqmFEZmXb0wwHkqEAeAwAN585RwIiEiXvBMUNVFM7pYlYC4jdHPdSY/


From ian at cypherpunks.ca  Thu Jul  9 13:54:48 2009
From: ian at cypherpunks.ca (Ian Goldberg)
Date: Thu, 9 Jul 2009 13:54:48 -0400
Subject: [OTR-dev] OTR + Second Life Client
In-Reply-To: <20090709000531.8D3D5B8040@smtp.hushmail.com>
References: <20090709000531.8D3D5B8040@smtp.hushmail.com>
Message-ID: <20090709175448.GL22290@thunk.cs.uwaterloo.ca>

On Wed, Jul 08, 2009 at 05:05:31PM -0700, chris-tuchs at hushmail.com wrote:
> Ian, thanks for the pointers they were just what I needed.  I now 
> have libotr, libgcrypt, and libgpg-error all building as part of 
> the second life client.  So I am about to actually start writing 
> code to use OTR now.  Yay!
> 
> However a niggling feature request keeps coming up, at the least it 
> is a request for education.  How can OTR be used for more than two 
> people to share an off the record conversation?

That is Very Complicated, because it's not obvious what "deniable" and
"off-the-record" mean when there are more than two people involved.  We
have a tech report that addresses that question:

Multi-party Off-the-Record Messaging
Ian Goldberg, Berkant Ustao?lu, Matthew Van Gundy, Hao Chen, CACR Tech
Report 2009-27, June 2009. 
http://www.cacr.math.uwaterloo.ca/techreports/2009/cacr2009-27.pdf

But for now, the answer is that OTR can only be used between two people.
So you can set up all-pairs OTR communication, but Bob has no assurance
that Alice sent the same messages to him as she did to Carol.

   - Ian

From secq.002 at rediffmail.com  Thu Jul  9 15:54:35 2009
From: secq.002 at rediffmail.com (Sec )
Date: 9 Jul 2009 19:54:35 -0000
Subject: [OTR-dev] Cross compile pidgin-otr for windows
Message-ID: <20090709195435.60093.qmail@f5mail-237-208.rediffmail.com>

Hi,

I am trying to compile pidgin-otr in linux. If I compile for linux (Debian), I get following errors although pidgin and libpurple are installed . 

No package 'gtk+-2.0' found
No package 'pidgin' found
No package 'purple' found

Is the configure script out of date or not suited for Debian ? 

I tried make -f Makefile.mingw since I am basically trying to compile the library for windows
but get a lot of these errors : 
error: expected ?=?, ?,?, ?;?, ?asm? or ?__attribute__? b


Can anyone please outline steps to compile pidgin-otr for windows please ?!


Thanks,
Sec

Kill spammers, snoopers dead
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/otr-dev/attachments/20090709/f1da8031/attachment.html>

From secq.002 at rediffmail.com  Thu Jul  9 22:11:40 2009
From: secq.002 at rediffmail.com (Sec )
Date: 10 Jul 2009 02:11:40 -0000
Subject: [OTR-dev] Compiling pidgin-otr for windows (cygwin OR
	cross-compile) errors
Message-ID: <20090710021140.17274.qmail@f5mail-236-219.rediffmail.com>

Hi,

Has anyone successfully compiled this for windows ? 

I have tried cross compiling using linux and also tried to compile using windows and cygwin. 

With windows cygwin I get the following error when I try to "make -f Makefile.mingw"
make: i586-mingw32msvc-gcc: Command not found

On linux, I followed the instructions at 
http://ubuntuforums.org/showthread.php?t=558197
and get error with trying to find some header files. I am using debian lenny.

otr-plugin.c:32:20: error: gcrypt.h: No such file or directory
In file included from /usr/include/gtk-2.0/gdk/gdkx.h:36,
                 from /usr/include/pidgin/pidgin.h:33,
                 from otr-plugin.c:35:
/usr/include/X11/Xlib.h:60:19: error: X11/X.h: No such file or directory
/usr/include/X11/Xlib.h:63:28: error: X11/Xfuncproto.h: No such file or directory
/usr/include/X11/Xlib.h:64:25: error: X11/Xosdefs.h: No such file or directory

- I have libgcrypt11-dev installed and I can see /usr/include/gcrypt.h
- Its as though the directory /usr/include is not being seen. For example a header file of a devel package has #include  and Xlib.h is in /usr/include/X11/Xlib.h but it looks "make -f Makefile.mingw" makes it look for /X11/Xlib.h instead of /usr/include/X11/Xlib.h

Can anyone help fix the above two problems for cross-compiling in linux. OR how to get it compile in cygwin ? 

Many thanks,
Sec

Kill spammers and snoopers dead
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/otr-dev/attachments/20090710/641c6234/attachment.htm>

From ian at cypherpunks.ca  Fri Jul 10 08:07:13 2009
From: ian at cypherpunks.ca (Ian Goldberg)
Date: Fri, 10 Jul 2009 08:07:13 -0400
Subject: [OTR-dev] Cross compile pidgin-otr for windows
In-Reply-To: <20090709195435.60093.qmail@f5mail-237-208.rediffmail.com>
References: <20090709195435.60093.qmail@f5mail-237-208.rediffmail.com>
Message-ID: <20090710120713.GX9279@yoink.cs.uwaterloo.ca>

On Thu, Jul 09, 2009 at 07:54:35PM -0000, Sec  wrote:
> Hi,
> 
> I am trying to compile pidgin-otr in linux. If I compile for linux (Debian), I get following errors although pidgin and libpurple are installed . 
> 
> No package 'gtk+-2.0' found
> No package 'pidgin' found
> No package 'purple' found
> 
> Is the configure script out of date or not suited for Debian ? 

Do you have the pidgin-dev package installed?  That contains the files
you need to compile pidgin plugins.

   - Ian

From ian at cypherpunks.ca  Fri Jul 10 08:12:41 2009
From: ian at cypherpunks.ca (Ian Goldberg)
Date: Fri, 10 Jul 2009 08:12:41 -0400
Subject: [OTR-dev] Compiling pidgin-otr for windows (cygwin
	OR	cross-compile) errors
In-Reply-To: <20090710021140.17274.qmail@f5mail-236-219.rediffmail.com>
References: <20090710021140.17274.qmail@f5mail-236-219.rediffmail.com>
Message-ID: <20090710121241.GY9279@yoink.cs.uwaterloo.ca>

On Fri, Jul 10, 2009 at 02:11:40AM -0000, Sec  wrote:
> Hi,
> 
> Has anyone successfully compiled this for windows ? 
> 
> I have tried cross compiling using linux and also tried to compile using windows and cygwin. 
> 
> With windows cygwin I get the following error when I try to "make -f Makefile.mingw"
> make: i586-mingw32msvc-gcc: Command not found

Makefile.mingw is meant for cross compiling on Linux, with the mingw32
package installed.

> On linux, I followed the instructions at 
> http://ubuntuforums.org/showthread.php?t=558197
> and get error with trying to find some header files. I am using debian lenny.
> 
> otr-plugin.c:32:20: error: gcrypt.h: No such file or directory

This sounds like you haven't installed a cross-compiled version of
libgcrypt.  The include files and libraries should live under
/usr/i586-mingw32msvc/.

> In file included from /usr/include/gtk-2.0/gdk/gdkx.h:36,
>                  from /usr/include/pidgin/pidgin.h:33,
>                  from otr-plugin.c:35:
> /usr/include/X11/Xlib.h:60:19: error: X11/X.h: No such file or directory
> /usr/include/X11/Xlib.h:63:28: error: X11/Xfuncproto.h: No such file or directory
> /usr/include/X11/Xlib.h:64:25: error: X11/Xosdefs.h: No such file or directory

This seems wrong; the Windows cross-compile should not be using X, I'm
pretty sure (but that's in the pidgin stuff, which I don't know as well
as the OTR stuff).

   - Ian

From secq.002 at rediffmail.com  Fri Jul 10 20:31:37 2009
From: secq.002 at rediffmail.com (Sec )
Date: 11 Jul 2009 00:31:37 -0000
Subject: [OTR-dev] Compiling pidgin-otr for windows (cygwin OR
	cross-compile) errors
Message-ID: <1247236096.S.2932.31953.f5mail-236-223.rediffmail.com.1247272297.56126@webmail.rediffmail.com>

Ian,

Thanks for the response.

>Makefile.mingw is meant for cross compiling on Linux, with the mingw32
>package installed.
I have/had the following installed
mingw32 - Minimalist GNU win32 (cross) compiler
mingw32-binutils - Minimalist GNU win32 (cross) binutils
mingw32-runtime - Minimalist GNU win32 (cross) runtime

>This sounds like you haven't installed a cross-compiled version of
>libgcrypt.  The include files and libraries should live under
>/usr/i586-mingw32msvc/.
Can you tell me how to install a cross compiled version of this ? 

I will try to figure the X11 stuff from pidgin. 

Thanks,
Sec

Kill snoopers dead

On Fri, 10 Jul 2009 19:58:16 +0530  wrote
>On Fri, Jul 10, 2009 at 02:11:40AM -0000, Sec  wrote:
>> Hi,
>> 
>> Has anyone successfully compiled this for windows ? 
>> 
>> I have tried cross compiling using linux and also tried to compile using windows and cygwin. 
>> 
>> With windows cygwin I get the following error when I try to "make -f Makefile.mingw"
>> make: i586-mingw32msvc-gcc: Command not found
>
>Makefile.mingw is meant for cross compiling on Linux, with the mingw32
>package installed.
>
>> On linux, I followed the instructions at 
>> http://ubuntuforums.org/showthread.php?t=558197
>> and get error with trying to find some header files. I am using debian lenny.
>> 
>> otr-plugin.c:32:20: error: gcrypt.h: No such file or directory
>
>This sounds like you haven't installed a cross-compiled version of
>libgcrypt.  The include files and libraries should live under
>/usr/i586-mingw32msvc/.
>
>> In file included from /usr/include/gtk-2.0/gdk/gdkx.h:36,
>>                  from /usr/include/pidgin/pidgin.h:33,
>>                  from otr-plugin.c:35:
>> /usr/include/X11/Xlib.h:60:19: error: X11/X.h: No such file or directory
>> /usr/include/X11/Xlib.h:63:28: error: X11/Xfuncproto.h: No such file or directory
>> /usr/include/X11/Xlib.h:64:25: error: X11/Xosdefs.h: No such file or directory
>
>This seems wrong; the Windows cross-compile should not be using X, I'm
>pretty sure (but that's in the pidgin stuff, which I don't know as well
>as the OTR stuff).
>
>   - Ian
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/otr-dev/attachments/20090711/1718267a/attachment.html>

From secq.002 at rediffmail.com  Fri Jul 10 20:32:45 2009
From: secq.002 at rediffmail.com (Sec )
Date: 11 Jul 2009 00:32:45 -0000
Subject: [OTR-dev] Cross compile pidgin-otr for windows
Message-ID: <1247235057.S.3107.52748.f5mail-147-101.rediffmail.com.1247272365.26898@webmail.rediffmail.com>

Ian,

Thanks for the response. 

Yes I had pidgin-dev installed (on debian lenny) but I still get the errors below. I also had libpurple-dev installed.

My main goal is to cross compile for windows, but I tried this to check if it compiles on linux first.

Can you please tell the instructions or point me to a page that might give how to cross-compile for windows, the way you guys might do it ?

Thanks,
Sec

Kill snoopers dead

On Fri, 10 Jul 2009 19:40:57 +0530  wrote
>On Thu, Jul 09, 2009 at 07:54:35PM -0000, Sec  wrote:
>> Hi,
>> 
>> I am trying to compile pidgin-otr in linux. If I compile for linux (Debian), I get following errors although pidgin and libpurple are installed . 
>> 
>> No package 'gtk+-2.0' found
>> No package 'pidgin' found
>> No package 'purple' found
>> 
>> Is the configure script out of date or not suited for Debian ? 
>
>Do you have the pidgin-dev package installed?  That contains the files
>you need to compile pidgin plugins.
>
>   - Ian
>_______________________________________________
>OTR-dev mailing list
>OTR-dev at lists.cypherpunks.ca
>http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/otr-dev/attachments/20090711/12e7afa7/attachment.htm>

From ian at cypherpunks.ca  Sat Jul 11 10:01:10 2009
From: ian at cypherpunks.ca (Ian Goldberg)
Date: Sat, 11 Jul 2009 10:01:10 -0400
Subject: [OTR-dev] Compiling pidgin-otr for windows (cygwin
	OR	cross-compile) errors
In-Reply-To: <1247236096.S.2932.31953.f5mail-236-223.rediffmail.com.1247272297.56126@webmail.rediffmail.com>
References: <1247236096.S.2932.31953.f5mail-236-223.rediffmail.com.1247272297.56126@webmail.rediffmail.com>
Message-ID: <20090711140110.GD10856@yoink.cs.uwaterloo.ca>

On Sat, Jul 11, 2009 at 12:31:37AM -0000, Sec  wrote:
> Ian,
> 
> Thanks for the response.
> 
> >Makefile.mingw is meant for cross compiling on Linux, with the mingw32
> >package installed.
> I have/had the following installed
> mingw32 - Minimalist GNU win32 (cross) compiler
> mingw32-binutils - Minimalist GNU win32 (cross) binutils
> mingw32-runtime - Minimalist GNU win32 (cross) runtime

Right, but you said you tried to run it on Windows + cygwin, which won't
work at all.

> >This sounds like you haven't installed a cross-compiled version of
> >libgcrypt.  The include files and libraries should live under
> >/usr/i586-mingw32msvc/.
> Can you tell me how to install a cross compiled version of this ? 

I'm pretty sure all I did was download the source and compile it.  I
think libgcrypt even came with instructions on how to cross-compile it
with mingw.

   - Ian

From ian at cypherpunks.ca  Sat Jul 11 10:04:25 2009
From: ian at cypherpunks.ca (Ian Goldberg)
Date: Sat, 11 Jul 2009 10:04:25 -0400
Subject: [OTR-dev] Cross compile pidgin-otr for windows
In-Reply-To: <1247235057.S.3107.52748.f5mail-147-101.rediffmail.com.1247272365.26898@webmail.rediffmail.com>
References: <1247235057.S.3107.52748.f5mail-147-101.rediffmail.com.1247272365.26898@webmail.rediffmail.com>
Message-ID: <20090711140425.GE10856@yoink.cs.uwaterloo.ca>

On Sat, Jul 11, 2009 at 12:32:45AM -0000, Sec  wrote:
> Ian,
> 
> Thanks for the response. 
> 
> Yes I had pidgin-dev installed (on debian lenny) but I still get the
> errors below. I also had libpurple-dev installed.

What happens if you run "pkg-config --cflags gtk+-2.0"?

> My main goal is to cross compile for windows, but I tried this to
> check if it compiles on linux first.
> 
> Can you please tell the instructions or point me to a page that might
> give how to cross-compile for windows, the way you guys might do it ?

We just cross-compile libotr as described in the INSTALL file:

 ./configure --with-pic --build=`./config.guess` --host=i586-mingw32msvc \
         --prefix=/usr/i586-mingw32msvc
 make
 make install

Then cross-compile pidgin-otr with:

 make -f Makefile.mingw

   - Ian

From secq.002 at rediffmail.com  Sun Jul 12 00:21:21 2009
From: secq.002 at rediffmail.com (Sec )
Date: 12 Jul 2009 04:21:21 -0000
Subject: [OTR-dev] Cross compile pidgin-otr for windows
Message-ID: <1247322567.S.3521.49195.f5mail-236-228.rediffmail.com.old.1247372481.37684@webmail.rediffmail.com>

Ian,

>What happens if you run "pkg-config --cflags gtk+-2.0"?
I installed gtk2.0-dev now I get output 
-D_REENTRANT -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/freetype2 -I/usr/include/directfb -I/usr/include/libpng12 -I/usr/include/pixman-1


> ./configure --with-pic --build=`./config.guess` --host=i586-mingw32msvc \
>         --prefix=/usr/i586-mingw32msvc
> make
> make install
>
>Then cross-compile pidgin-otr with:
>
> make -f Makefile.mingw

This wasn't there in the INSTALL of pidgin-otr but was in the libotr I am going to try this. However I still have the libgcrypt.h not being found issue (from other mail).

Can you tell me how to compile. I looked for several hours for mingw32 and libgcrypt etc. but couldn't find a way to cross-compile or 'mingw32 compile' it. Its not described in the package. Can you tell me how you got this to work ? 

Thanks,
Sec

Kill snoopers dead



On Sat, 11 Jul 2009 19:59:27 +0530  wrote
>On Sat, Jul 11, 2009 at 12:32:45AM -0000, Sec  wrote:
>> Ian,
>> 
>> Thanks for the response. 
>> 
>> Yes I had pidgin-dev installed (on debian lenny) but I still get the
>> errors below. I also had libpurple-dev installed.
>
>What happens if you run "pkg-config --cflags gtk+-2.0"?
>
>> My main goal is to cross compile for windows, but I tried this to
>> check if it compiles on linux first.
>> 
>> Can you please tell the instructions or point me to a page that might
>> give how to cross-compile for windows, the way you guys might do it ?
>
>We just cross-compile libotr as described in the INSTALL file:
>
> ./configure --with-pic --build=`./config.guess` --host=i586-mingw32msvc \
>         --prefix=/usr/i586-mingw32msvc
> make
> make install
>
>Then cross-compile pidgin-otr with:
>
> make -f Makefile.mingw
>
>   - Ian
>_______________________________________________
>OTR-dev mailing list
>OTR-dev at lists.cypherpunks.ca
>http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/otr-dev/attachments/20090712/06c4b567/attachment.html>

From secq.002 at rediffmail.com  Sun Jul 12 00:43:56 2009
From: secq.002 at rediffmail.com (Sec )
Date: 12 Jul 2009 04:43:56 -0000
Subject: [OTR-dev] Cross compile pidgin-otr for windows
Message-ID: <1247372636.S.8697.61712.f5mail-236-222.rediffmail.com.1247373836.13014@webmail.rediffmail.com>

I do have gcrypt.h in /usr/include I was wondering if there is a way to tell the compilation to see it (as alternative to cross-compile way of installing it to make it be seen) by modifying the make file or configure script or something like that ? 

Sec

Kill snoopers dead


On Sun, 12 Jul 2009 09:53:56 +0530  wrote
>Ian,
>
>>What happens if you run "pkg-config --cflags gtk+-2.0"?
>I installed gtk2.0-dev now I get output 
>-D_REENTRANT -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/freetype2 -I/usr/include/directfb -I/usr/include/libpng12 -I/usr/include/pixman-1
>
>
>> ./configure --with-pic --build=`./config.guess` --host=i586-mingw32msvc \
>>         --prefix=/usr/i586-mingw32msvc
>> make
>> make install
>>
>>Then cross-compile pidgin-otr with:
>>
>> make -f Makefile.mingw
>
>This wasn't there in the INSTALL of pidgin-otr but was in the libotr I am going to try this. However I still have the libgcrypt.h not being found issue (from other mail).
>
>Can you tell me how to compile. I looked for several hours for mingw32 and libgcrypt etc. but couldn't find a way to cross-compile or 'mingw32 compile' it. Its not described in the package. Can you tell me how you got this to work ? 
>
>Thanks,
>Sec
>
>Kill snoopers dead
>
>
>
>On Sat, 11 Jul 2009 19:59:27 +0530  wrote
>>On Sat, Jul 11, 2009 at 12:32:45AM -0000, Sec  wrote:
>>> Ian,
>>> 
>>> Thanks for the response. 
>>> 
>>> Yes I had pidgin-dev installed (on debian lenny) but I still get the
>>> errors below. I also had libpurple-dev installed.
>>
>>What happens if you run "pkg-config --cflags gtk+-2.0"?
>>
>>> My main goal is to cross compile for windows, but I tried this to
>>> check if it compiles on linux first.
>>> 
>>> Can you please tell the instructions or point me to a page that might
>>> give how to cross-compile for windows, the way you guys might do it ?
>>
>>We just cross-compile libotr as described in the INSTALL file:
>>
>> ./configure --with-pic --build=`./config.guess` --host=i586-mingw32msvc \
>>         --prefix=/usr/i586-mingw32msvc
>> make
>> make install
>>
>>Then cross-compile pidgin-otr with:
>>
>> make -f Makefile.mingw
>>
>>   - Ian
>>_______________________________________________
>>OTR-dev mailing list
>>OTR-dev at lists.cypherpunks.ca
>>http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
>>_______________________________________________
>OTR-dev mailing list
>OTR-dev at lists.cypherpunks.ca
>http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/otr-dev/attachments/20090712/6ccd21cc/attachment.html>

From ian at cypherpunks.ca  Sun Jul 12 09:34:36 2009
From: ian at cypherpunks.ca (Ian Goldberg)
Date: Sun, 12 Jul 2009 09:34:36 -0400
Subject: [OTR-dev] Cross compile pidgin-otr for windows
In-Reply-To: <1247372636.S.8697.61712.f5mail-236-222.rediffmail.com.1247373836.13014@webmail.rediffmail.com>
References: <1247372636.S.8697.61712.f5mail-236-222.rediffmail.com.1247373836.13014@webmail.rediffmail.com>
Message-ID: <20090712133436.GM10856@yoink.cs.uwaterloo.ca>

On Sun, Jul 12, 2009 at 04:43:56AM -0000, Sec  wrote:
> I do have gcrypt.h in /usr/include I was wondering if there is a way
> to tell the compilation to see it (as alternative to cross-compile way
> of installing it to make it be seen) by modifying the make file or
> configure script or something like that ? 

That wouldn't really help, since you'll need to have the
compiled-for-win32 library around as well, to link to it.

I'm pretty sure all I did to cross-compile libgcrypt was to configure it
with --target=i586-mingw32msvc.  Maybe also
--prefix=/usr/i586-mingw32msvc.

   - Ian

From Werner.Dittmann at t-online.de  Sat Jul 18 11:00:18 2009
From: Werner.Dittmann at t-online.de (Werner Dittmann)
Date: Sat, 18 Jul 2009 17:00:18 +0200
Subject: [OTR-dev] Interop problems with libotr - DSA signature
Message-ID: <4A61E382.5060803@t-online.de>

Dear all,

for the SIP Communicator project one of the GSOC'09 students (George)
develops a Java version of the OTR library (otr4j). During this
development he found an interoperability  problem with the libotr
DSA signature. George contacted me (I'm one of his mentors) to help
him to clarify this issue.

George digged into the problem and tracked it down: otr4j uses the DSA
implementation of the BouncyCastle (BC) library which in turn
implements DSA according to FIPS-186-3. The libotr library uses the
DSA signature implementation of libgcrypt that is a generic DSA
implementation.

The interoperability problem is due to the following part of the OTR
protocol specification (reveal signature message, Signature message):

# Compute the 32-byte value MB to be the SHA256-HMAC of the
  following data, using the key m1:

gx (MPI)
gy (MPI)
pubB (PUBKEY)
keyidB (INT)

# Let XB be the following structure:

pubB (PUBKEY)
keyidB (INT)
sigB(MB) (SIG)
    This is the signature, using the private part of the key pubB,
    of the 32-byte MB (which does not need to be hashed again to
    produce the signature).

libotr implments this as follows (simlified for brevity)

- generates the SHA256-HMAC ot get the 32 byte MB
- hands over this 32 byte data to libgcrypt to sign this data
- the DSA keypair that libotr uses (and generated and stored) some
  time before has the following parameter attributes:
  p bit length (L) is 1024, q bit length (N) is 160.

Thus libotr uses a 160 bit q to sign 256 bit data. This is possible
because libgcrypt implements a generic DSA signature, thus the caller
of libgcrypt must truncate the data if necessary. I don't know if
using a 160 bit q to sign 256 bit of data causes any security problems
or if it is allowed according the the DSA algorithm.

Therefore libotr uses DSA in a way that is not in accordance to
FIPS-186-1, 186-2, and 186-3. The two older standard versions (1 and
2) allow 160 bit data only, the new standard allows different length
but in that case the data has to be truncated to the bit length of
q. Because BC implements this truncation an otr4j DSA signature does
not verify with the libotr DSA verification and vice versa. To
overcome this problem George uses a modified BC DSA implementation.

However the main problem of the incorrect usage of DSA signature
remains.

Any ideas or comments?

Regards,
Werner

From ian at cypherpunks.ca  Sat Jul 18 11:57:04 2009
From: ian at cypherpunks.ca (Ian Goldberg)
Date: Sat, 18 Jul 2009 11:57:04 -0400
Subject: [OTR-dev] Interop problems with libotr - DSA signature
In-Reply-To: <4A61E382.5060803@t-online.de>
References: <4A61E382.5060803@t-online.de>
Message-ID: <20090718155704.GG20935@yoink.cs.uwaterloo.ca>

On Sat, Jul 18, 2009 at 05:00:18PM +0200, Werner Dittmann wrote:
> Dear all,
> 
> for the SIP Communicator project one of the GSOC'09 students (George)
> develops a Java version of the OTR library (otr4j). During this
> development he found an interoperability  problem with the libotr
> DSA signature. George contacted me (I'm one of his mentors) to help
> him to clarify this issue.
> 
> George digged into the problem and tracked it down: otr4j uses the DSA
> implementation of the BouncyCastle (BC) library which in turn
> implements DSA according to FIPS-186-3. The libotr library uses the
> DSA signature implementation of libgcrypt that is a generic DSA
> implementation.
> 
> Thus libotr uses a 160 bit q to sign 256 bit data. This is possible
> because libgcrypt implements a generic DSA signature, thus the caller
> of libgcrypt must truncate the data if necessary. I don't know if
> using a 160 bit q to sign 256 bit of data causes any security problems
> or if it is allowed according the the DSA algorithm.
> 
> Therefore libotr uses DSA in a way that is not in accordance to
> FIPS-186-1, 186-2, and 186-3. The two older standard versions (1 and
> 2) allow 160 bit data only, the new standard allows different length
> but in that case the data has to be truncated to the bit length of
> q. Because BC implements this truncation an otr4j DSA signature does
> not verify with the libotr DSA verification and vice versa. To
> overcome this problem George uses a modified BC DSA implementation.
> 
> However the main problem of the incorrect usage of DSA signature
> remains.
> 
> Any ideas or comments?

In fact, we came across the same problem while implementing java-otr
just a couple of weeks ago.  It's definitely a problem in the spec, and
we'll fix it in the next version of the wire protocol.  That of course
doesn't help you interoperate with current implementations, which
conform to the current spec.

Note that if you can get the standard DSA implementation you're using to
not hash its input, you should be able to pass it ((256-bit value) mod q),
(rather than truncating the 256-bit value) and all should be well.
Otherwise, a slightly modified DSA implementation is probably the best
you'll be able to do.

Totally my bad, sorry.  :-(

   - Ian

From Werner.Dittmann at t-online.de  Sat Jul 18 13:34:01 2009
From: Werner.Dittmann at t-online.de (Werner Dittmann)
Date: Sat, 18 Jul 2009 19:34:01 +0200
Subject: [OTR-dev] Interop problems with libotr - DSA signature
In-Reply-To: <20090718155704.GG20935@yoink.cs.uwaterloo.ca>
References: <4A61E382.5060803@t-online.de>
	<20090718155704.GG20935@yoink.cs.uwaterloo.ca>
Message-ID: <4A620789.7080808@t-online.de>

Ian Goldberg schrieb:
> On Sat, Jul 18, 2009 at 05:00:18PM +0200, Werner Dittmann wrote:
>> Dear all,
>>
>> for the SIP Communicator project one of the GSOC'09 students (George)
>> develops a Java version of the OTR library (otr4j). During this
>> development he found an interoperability  problem with the libotr
>> DSA signature. George contacted me (I'm one of his mentors) to help
>> him to clarify this issue.
>>
>> George digged into the problem and tracked it down: otr4j uses the DSA
>> implementation of the BouncyCastle (BC) library which in turn
>> implements DSA according to FIPS-186-3. The libotr library uses the
>> DSA signature implementation of libgcrypt that is a generic DSA
>> implementation.
>>
>> Thus libotr uses a 160 bit q to sign 256 bit data. This is possible
>> because libgcrypt implements a generic DSA signature, thus the caller
>> of libgcrypt must truncate the data if necessary. I don't know if
>> using a 160 bit q to sign 256 bit of data causes any security problems
>> or if it is allowed according the the DSA algorithm.
>>
>> Therefore libotr uses DSA in a way that is not in accordance to
>> FIPS-186-1, 186-2, and 186-3. The two older standard versions (1 and
>> 2) allow 160 bit data only, the new standard allows different length
>> but in that case the data has to be truncated to the bit length of
>> q. Because BC implements this truncation an otr4j DSA signature does
>> not verify with the libotr DSA verification and vice versa. To
>> overcome this problem George uses a modified BC DSA implementation.
>>
>> However the main problem of the incorrect usage of DSA signature
>> remains.
>>
>> Any ideas or comments?
> 
> In fact, we came across the same problem while implementing java-otr
> just a couple of weeks ago.  It's definitely a problem in the spec, and
> we'll fix it in the next version of the wire protocol.  That of course
> doesn't help you interoperate with current implementations, which
> conform to the current spec.
> 
> Note that if you can get the standard DSA implementation you're using to
> not hash its input, 

The current BC DSA signature implemenation just takes the input and does not
hash it (only the JCE variant performs a hash before it signs, the
BC lightweight library provides a "raw" DSA implemenation acc. to FIPS-186-3).
Thus it is possible to hand over a (input mod 256) to the DSA (lightweight).
I'll ask George to check this and to modify the code accordingly.

you should be able to pass it ((256-bit value) mod q),
> (rather than truncating the 256-bit value) and all should be well.

Well, the wonders of mod mathematics remain a mystery to me ;-)

Regards,
Werner

> Otherwise, a slightly modified DSA implementation is probably the best
> you'll be able to do.
> 
> Totally my bad, sorry.  :-(
> 
>    - Ian
> _______________________________________________
> OTR-dev mailing list
> OTR-dev at lists.cypherpunks.ca
> http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
> 


From secq.002 at rediffmail.com  Sat Jul 18 23:32:06 2009
From: secq.002 at rediffmail.com (Sec)
Date: 19 Jul 2009 03:32:06 -0000
Subject: [OTR-dev] Cross compile pidgin-otr for windows
Message-ID: <1247536840.S.2486.5557.f5mail-237-243.rediffmail.com.replied.old.1247974326.47301@webmail.rediffmail.com>

Ian,

I compiled the ligcrypt and ligpgerror now using the configure method for mingw below and I was able to compile libotr now successfully under mingw.

Now I tried compiling pidgin-otr using make -f Makefile.mingw after giving the paths to pidgin and libpurple sources, but I get still some *.h files not found like X11/Xutil.h etc. 

--> So I guess I guess similar compiling (like libgcrypt must be done for all the once listed below as well in order to avoid not finding some *.h files ? And the same follows for all *.h files it complains as you start with one ? On Tue, Jul 14, 2009 at 12:17:22AM -0000, Sec ?wrote:
>> Ian,
>> 
>> Thanks, that seemed to make it see the gcrypt.h now (INSTALL says use the libgcrypt11-dev package, but that didn't get it working somehow). I also did the same for libgpg-error and it can see that header too, but I get yet another error when I try to "make" libotr
>> 
>> i586-mingw32msvc-gcc -g -O2 -o .libs/otr_parse.exe otr_parse.o readotr.o parse.o sha1hmac.o ?../src/.libs/libotr.so /usr/lib/libgcrypt.so /usr/i586-mingw32msvc/lib/libgcrypt.so /usr/lib/libgpg-error.so -L/usr/i586-mingw32msvc/lib
>> ../src/.libs/libotr.so: could not read symbols: File in wrong format
>> 
>> The last path seems really strange :?"/usr/i586-mingw32msvc/lib
>> ../src/.libs/libotr.so" - there is no / after lib
>> 
>> Can you tell me how to fix it ? 
>
>That's not the link line I get. ?When I compile libgpg-error and
>libgcrypt, I get .a files, not .so files. ?Then this line links them:
>
>i586-mingw32msvc-gcc -g -O2 -o otr_parse.exe otr_parse.o readotr.o
> ? ?parse.o sha1hmac.o ?../src/.libs/libotr.a -lgcrypt -lgpg-error
>
>
> ? - Ian
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/otr-dev/attachments/20090719/2366c6b6/attachment.htm>

From ian at cypherpunks.ca  Sat Jul 18 23:47:37 2009
From: ian at cypherpunks.ca (Ian Goldberg)
Date: Sat, 18 Jul 2009 23:47:37 -0400
Subject: [OTR-dev] Cross compile pidgin-otr for windows
In-Reply-To: <1247536840.S.2486.5557.f5mail-237-243.rediffmail.com.replied.old.1247974326.47301@webmail.rediffmail.com>
References: <1247536840.S.2486.5557.f5mail-237-243.rediffmail.com.replied.old.1247974326.47301@webmail.rediffmail.com>
Message-ID: <20090719034737.GD1952@yoink.cs.uwaterloo.ca>

On Sun, Jul 19, 2009 at 03:32:06AM -0000, Sec wrote:
> Ian,
> 
> I compiled the ligcrypt and ligpgerror now using the configure method
> for mingw below and I was able to compile libotr now successfully
> under mingw.

Great!

> Now I tried compiling pidgin-otr using make -f Makefile.mingw after
> giving the paths to pidgin and libpurple sources, but I get still some
> *.h files not found like X11/Xutil.h etc. 
> 
> --> So I guess I guess similar compiling (like libgcrypt must be done
> for all the once listed below as well in order to avoid not finding
> some *.h files ? And the same follows for all *.h files it complains
> as you start with one ?

When you're cross-compiling for Windows, nothing at all should be
looking for X11/Xutil.h.  Did you give the paths to the *win32* pidgin
and libpurple sources in /usr/i586-mingw32msvc/include/ ?  You should
also have the gtk-2.0/{gtk,gdk,gdk-pixbuf} header files in there.  There
should be no references to include files under X11 in those.

   - Ian

From chris-tuchs at hushmail.com  Sun Jul 19 03:27:52 2009
From: chris-tuchs at hushmail.com (chris-tuchs at hushmail.com)
Date: Sun, 19 Jul 2009 00:27:52 -0700
Subject: [OTR-dev] OTR + Second Life Client
Message-ID: <20090719072752.60EFBB8040@smtp.hushmail.com>

I have gotten OTR compiled and working in the Greenlife Emerald 
Viewer for Second Life.  I have not yet implemented any way to 
authenticate a buddy; that is what I will be working on next.  
However I wanted to put out an early plea for experienced OTR devs 
to audit the code.  If you are interested in ensuring I didn't do 
something dumb that might make OTR look bad, please send me an 
email and I'll arrange for you to see the code.

One sign I may be doing something dumb is that during the compile 
of OTR there are a number of warnings in the cryptographic 
libraries.  Although most look OK to me, a few look serious.  I am 
most concerned about those in libotr's auth.c and in libgcrypt's 
mpih-div.c.  Thanks for your time!

Chris



24>------ Rebuild All started: Project: libotr, Configuration: 
RelWithDebInfo Win32 ------
24>Deleting intermediate and output files for project 'libotr', 
configuration 'RelWithDebInfo|Win32'
24>Compiling...
24>auth.c
24>..\..\libotr\libotr-3.2.0\src\auth.c(385) : warning C4333: '>>' 
: right shift by too large amount, data loss
24>..\..\libotr\libotr-3.2.0\src\auth.c(416) : warning C4333: '>>' 
: right shift by too large amount, data loss
24>..\..\libotr\libotr-3.2.0\src\auth.c(523) : warning C4333: '>>' 
: right shift by too large amount, data loss
24>sm.c
24>..\..\libotr\libotr-3.2.0\src\sm.c(358) : warning C4018: '<' : 
signed/unsigned mismatch
24>..\..\libotr\libotr-3.2.0\src\sm.c(362) : warning C4018: '<' : 
signed/unsigned mismatch
24>..\..\libotr\libotr-3.2.0\src\sm.c(363) : warning C4018: '<' : 
signed/unsigned mismatch
24>..\..\libotr\libotr-3.2.0\src\sm.c(370) : warning C4018: '<' : 
signed/unsigned mismatch
24>proto.c
24>..\..\libotr\libotr-3.2.0\src\proto.c(785) : warning C4018: '>' 
: signed/unsigned mismatch
24>privkey.c
24>..\..\libotr\libotr-3.2.0\src\privkey.c(243) : warning C4018: 
'<' : signed/unsigned mismatch
24>libotr - 0 error(s), 9 warning(s)

16>------ Rebuild All started: Project: libgcrypt, Configuration: 
RelWithDebInfo Win32 ------
16>Deleting intermediate and output files for project 'libgcrypt', 
configuration 'RelWithDebInfo|Win32'
16>Compiling...
16>mpiutil.c
16>..\..\libgcrypt\libgcrypt-1.2.2\mpi\mpiutil.c(124) : warning 
C4018: '<=' : signed/unsigned mismatch
16>mpih-div.c
16>..\..\libgcrypt\libgcrypt-1.2.2\mpi\mpih-div.c(85) : warning 
C4146: unary minus operator applied to unsigned type, result still 
unsigned
16>..\..\libgcrypt\libgcrypt-1.2.2\mpi\mpih-div.c(85) : warning 
C4146: unary minus operator applied to unsigned type, result still 
unsigned
16>..\..\libgcrypt\libgcrypt-1.2.2\mpi\mpih-div.c(122) : warning 
C4146: unary minus operator applied to unsigned type, result still 
unsigned
16>..\..\libgcrypt\libgcrypt-1.2.2\mpi\mpih-div.c(122) : warning 
C4146: unary minus operator applied to unsigned type, result still 
unsigned
16>..\..\libgcrypt\libgcrypt-1.2.2\mpi\mpih-div.c(284) : warning 
C4146: unary minus operator applied to unsigned type, result still 
unsigned
16>..\..\libgcrypt\libgcrypt-1.2.2\mpi\mpih-div.c(432) : warning 
C4146: unary minus operator applied to unsigned type, result still 
unsigned
16>..\..\libgcrypt\libgcrypt-1.2.2\mpi\mpih-div.c(432) : warning 
C4146: unary minus operator applied to unsigned type, result still 
unsigned
16>..\..\libgcrypt\libgcrypt-1.2.2\mpi\mpih-div.c(468) : warning 
C4146: unary minus operator applied to unsigned type, result still 
unsigned
16>..\..\libgcrypt\libgcrypt-1.2.2\mpi\mpih-div.c(468) : warning 
C4146: unary minus operator applied to unsigned type, result still 
unsigned
16>mpicoder.c
16>..\..\libgcrypt\libgcrypt-1.2.2\mpi\mpicoder.c(112) : warning 
C4018: '<' : signed/unsigned mismatch
16>..\..\libgcrypt\libgcrypt-1.2.2\mpi\mpicoder.c(604) : warning 
C4018: '<' : signed/unsigned mismatch
16>mpi-scan.c
16>..\..\libgcrypt\libgcrypt-1.2.2\mpi\mpi-scan.c(117) : warning 
C4018: '<' : signed/unsigned mismatch
16>..\..\libgcrypt\libgcrypt-1.2.2\mpi\mpi-scan.c(122) : warning 
C4146: unary minus operator applied to unsigned type, result still 
unsigned
16>Generating Code...
16>c:\greenlife\trunk\indra\libgcrypt\libgcrypt-1.2.2\mpi\mpi-
pow.c(73) : warning C4723: potential divide by 0
16>c:\greenlife\trunk\indra\libgcrypt\libgcrypt-1.2.2\mpi\mpih-
div.c(217) : warning C4723: potential divide by 0
16>c:\greenlife\trunk\indra\libgcrypt\libgcrypt-
1.2.2\mpi\mpiutil.c(427) : warning C4715: 'gcry_mpi_get_flag' : not 
all control paths return a value
16>mpi-bit.c
16>..\..\libgcrypt\libgcrypt-1.2.2\mpi\mpi-bit.c(106) : warning 
C4018: '>=' : signed/unsigned mismatch
16>..\..\libgcrypt\libgcrypt-1.2.2\mpi\mpi-bit.c(124) : warning 
C4018: '>=' : signed/unsigned mismatch
16>..\..\libgcrypt\libgcrypt-1.2.2\mpi\mpi-bit.c(125) : warning 
C4018: '>=' : signed/unsigned mismatch
16>..\..\libgcrypt\libgcrypt-1.2.2\mpi\mpi-bit.c(143) : warning 
C4018: '>=' : signed/unsigned mismatch
16>..\..\libgcrypt\libgcrypt-1.2.2\mpi\mpi-bit.c(144) : warning 
C4018: '>=' : signed/unsigned mismatch
16>..\..\libgcrypt\libgcrypt-1.2.2\mpi\mpi-bit.c(165) : warning 
C4018: '>=' : signed/unsigned mismatch
16>..\..\libgcrypt\libgcrypt-1.2.2\mpi\mpi-bit.c(184) : warning 
C4018: '>=' : signed/unsigned mismatch
16>..\..\libgcrypt\libgcrypt-1.2.2\mpi\mpi-bit.c(227) : warning 
C4018: '<' : signed/unsigned mismatch
16>..\..\libgcrypt\libgcrypt-1.2.2\mpi\mpi-bit.c(231) : warning 
C4018: '<' : signed/unsigned mismatch
16>..\..\libgcrypt\libgcrypt-1.2.2\mpi\mpi-bit.c(248) : warning 
C4018: '>=' : signed/unsigned mismatch
16>tiger.c
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\tiger.c(817) : warning 
C4244: '=' : conversion from 'u64' to 'byte', possible loss of data
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\tiger.c(817) : warning 
C4244: '=' : conversion from 'u64' to 'byte', possible loss of data
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\tiger.c(817) : warning 
C4244: '=' : conversion from 'u64' to 'byte', possible loss of data
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\tiger.c(817) : warning 
C4244: '=' : conversion from 'u64' to 'byte', possible loss of data
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\tiger.c(817) : warning 
C4244: '=' : conversion from 'u64' to 'byte', possible loss of data
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\tiger.c(817) : warning 
C4244: '=' : conversion from 'u64' to 'byte', possible loss of data
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\tiger.c(817) : warning 
C4244: '=' : conversion from 'u64' to 'byte', possible loss of data
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\tiger.c(817) : warning 
C4244: '=' : conversion from 'u64' to 'byte', possible loss of data
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\tiger.c(818) : warning 
C4244: '=' : conversion from 'u64' to 'byte', possible loss of data
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\tiger.c(818) : warning 
C4244: '=' : conversion from 'u64' to 'byte', possible loss of data
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\tiger.c(818) : warning 
C4244: '=' : conversion from 'u64' to 'byte', possible loss of data
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\tiger.c(818) : warning 
C4244: '=' : conversion from 'u64' to 'byte', possible loss of data
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\tiger.c(818) : warning 
C4244: '=' : conversion from 'u64' to 'byte', possible loss of data
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\tiger.c(818) : warning 
C4244: '=' : conversion from 'u64' to 'byte', possible loss of data
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\tiger.c(818) : warning 
C4244: '=' : conversion from 'u64' to 'byte', possible loss of data
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\tiger.c(818) : warning 
C4244: '=' : conversion from 'u64' to 'byte', possible loss of data
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\tiger.c(819) : warning 
C4244: '=' : conversion from 'u64' to 'byte', possible loss of data
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\tiger.c(819) : warning 
C4244: '=' : conversion from 'u64' to 'byte', possible loss of data
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\tiger.c(819) : warning 
C4244: '=' : conversion from 'u64' to 'byte', possible loss of data
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\tiger.c(819) : warning 
C4244: '=' : conversion from 'u64' to 'byte', possible loss of data
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\tiger.c(819) : warning 
C4244: '=' : conversion from 'u64' to 'byte', possible loss of data
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\tiger.c(819) : warning 
C4244: '=' : conversion from 'u64' to 'byte', possible loss of data
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\tiger.c(819) : warning 
C4244: '=' : conversion from 'u64' to 'byte', possible loss of data
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\tiger.c(819) : warning 
C4244: '=' : conversion from 'u64' to 'byte', possible loss of data
16>sha512.c
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\sha512.c(315) : warning 
C4244: '=' : conversion from 'u64' to 'byte', possible loss of data
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\sha512.c(316) : warning 
C4244: '=' : conversion from 'u64' to 'byte', possible loss of data
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\sha512.c(317) : warning 
C4244: '=' : conversion from 'u64' to 'byte', possible loss of data
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\sha512.c(318) : warning 
C4244: '=' : conversion from 'u64' to 'byte', possible loss of data
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\sha512.c(319) : warning 
C4244: '=' : conversion from 'u64' to 'byte', possible loss of data
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\sha512.c(320) : warning 
C4244: '=' : conversion from 'u64' to 'byte', possible loss of data
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\sha512.c(321) : warning 
C4244: '=' : conversion from 'u64' to 'byte', possible loss of data
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\sha512.c(322) : warning 
C4244: '=' : conversion from 'u64' to 'byte', possible loss of data
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\sha512.c(324) : warning 
C4244: '=' : conversion from 'u64' to 'byte', possible loss of data
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\sha512.c(325) : warning 
C4244: '=' : conversion from 'u64' to 'byte', possible loss of data
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\sha512.c(326) : warning 
C4244: '=' : conversion from 'u64' to 'byte', possible loss of data
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\sha512.c(327) : warning 
C4244: '=' : conversion from 'u64' to 'byte', possible loss of data
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\sha512.c(328) : warning 
C4244: '=' : conversion from 'u64' to 'byte', possible loss of data
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\sha512.c(329) : warning 
C4244: '=' : conversion from 'u64' to 'byte', possible loss of data
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\sha512.c(330) : warning 
C4244: '=' : conversion from 'u64' to 'byte', possible loss of data
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\sha512.c(331) : warning 
C4244: '=' : conversion from 'u64' to 'byte', possible loss of data
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\sha512.c(344) : warning 
C4244: '=' : conversion from 'u64' to 'byte', possible loss of data
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\sha512.c(344) : warning 
C4244: '=' : conversion from 'u64' to 'byte', possible loss of data
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\sha512.c(344) : warning 
C4244: '=' : conversion from 'u64' to 'byte', possible loss of data
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\sha512.c(344) : warning 
C4244: '=' : conversion from 'u64' to 'byte', possible loss of data
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\sha512.c(344) : warning 
C4244: '=' : conversion from 'u64' to 'byte', possible loss of data
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\sha512.c(344) : warning 
C4244: '=' : conversion from 'u64' to 'byte', possible loss of data
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\sha512.c(344) : warning 
C4244: '=' : conversion from 'u64' to 'byte', possible loss of data
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\sha512.c(344) : warning 
C4244: '=' : conversion from 'u64' to 'byte', possible loss of data
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\sha512.c(345) : warning 
C4244: '=' : conversion from 'u64' to 'byte', possible loss of data
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\sha512.c(345) : warning 
C4244: '=' : conversion from 'u64' to 'byte', possible loss of data
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\sha512.c(345) : warning 
C4244: '=' : conversion from 'u64' to 'byte', possible loss of data
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\sha512.c(345) : warning 
C4244: '=' : conversion from 'u64' to 'byte', possible loss of data
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\sha512.c(345) : warning 
C4244: '=' : conversion from 'u64' to 'byte', possible loss of data
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\sha512.c(345) : warning 
C4244: '=' : conversion from 'u64' to 'byte', possible loss of data
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\sha512.c(345) : warning 
C4244: '=' : conversion from 'u64' to 'byte', possible loss of data
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\sha512.c(345) : warning 
C4244: '=' : conversion from 'u64' to 'byte', possible loss of data
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\sha512.c(346) : warning 
C4244: '=' : conversion from 'u64' to 'byte', possible loss of data
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\sha512.c(346) : warning 
C4244: '=' : conversion from 'u64' to 'byte', possible loss of data
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\sha512.c(346) : warning 
C4244: '=' : conversion from 'u64' to 'byte', possible loss of data
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\sha512.c(346) : warning 
C4244: '=' : conversion from 'u64' to 'byte', possible loss of data
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\sha512.c(346) : warning 
C4244: '=' : conversion from 'u64' to 'byte', possible loss of data
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\sha512.c(346) : warning 
C4244: '=' : conversion from 'u64' to 'byte', possible loss of data
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\sha512.c(346) : warning 
C4244: '=' : conversion from 'u64' to 'byte', possible loss of data
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\sha512.c(346) : warning 
C4244: '=' : conversion from 'u64' to 'byte', possible loss of data
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\sha512.c(347) : warning 
C4244: '=' : conversion from 'u64' to 'byte', possible loss of data
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\sha512.c(347) : warning 
C4244: '=' : conversion from 'u64' to 'byte', possible loss of data
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\sha512.c(347) : warning 
C4244: '=' : conversion from 'u64' to 'byte', possible loss of data
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\sha512.c(347) : warning 
C4244: '=' : conversion from 'u64' to 'byte', possible loss of data
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\sha512.c(347) : warning 
C4244: '=' : conversion from 'u64' to 'byte', possible loss of data
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\sha512.c(347) : warning 
C4244: '=' : conversion from 'u64' to 'byte', possible loss of data
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\sha512.c(347) : warning 
C4244: '=' : conversion from 'u64' to 'byte', possible loss of data
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\sha512.c(347) : warning 
C4244: '=' : conversion from 'u64' to 'byte', possible loss of data
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\sha512.c(348) : warning 
C4244: '=' : conversion from 'u64' to 'byte', possible loss of data
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\sha512.c(348) : warning 
C4244: '=' : conversion from 'u64' to 'byte', possible loss of data
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\sha512.c(348) : warning 
C4244: '=' : conversion from 'u64' to 'byte', possible loss of data
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\sha512.c(348) : warning 
C4244: '=' : conversion from 'u64' to 'byte', possible loss of data
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\sha512.c(348) : warning 
C4244: '=' : conversion from 'u64' to 'byte', possible loss of data
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\sha512.c(348) : warning 
C4244: '=' : conversion from 'u64' to 'byte', possible loss of data
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\sha512.c(348) : warning 
C4244: '=' : conversion from 'u64' to 'byte', possible loss of data
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\sha512.c(348) : warning 
C4244: '=' : conversion from 'u64' to 'byte', possible loss of data
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\sha512.c(349) : warning 
C4244: '=' : conversion from 'u64' to 'byte', possible loss of data
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\sha512.c(349) : warning 
C4244: '=' : conversion from 'u64' to 'byte', possible loss of data
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\sha512.c(349) : warning 
C4244: '=' : conversion from 'u64' to 'byte', possible loss of data
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\sha512.c(349) : warning 
C4244: '=' : conversion from 'u64' to 'byte', possible loss of data
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\sha512.c(349) : warning 
C4244: '=' : conversion from 'u64' to 'byte', possible loss of data
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\sha512.c(349) : warning 
C4244: '=' : conversion from 'u64' to 'byte', possible loss of data
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\sha512.c(349) : warning 
C4244: '=' : conversion from 'u64' to 'byte', possible loss of data
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\sha512.c(349) : warning 
C4244: '=' : conversion from 'u64' to 'byte', possible loss of data
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\sha512.c(352) : warning 
C4244: '=' : conversion from 'u64' to 'byte', possible loss of data
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\sha512.c(352) : warning 
C4244: '=' : conversion from 'u64' to 'byte', possible loss of data
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\sha512.c(352) : warning 
C4244: '=' : conversion from 'u64' to 'byte', possible loss of data
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\sha512.c(352) : warning 
C4244: '=' : conversion from 'u64' to 'byte', possible loss of data
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\sha512.c(352) : warning 
C4244: '=' : conversion from 'u64' to 'byte', possible loss of data
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\sha512.c(352) : warning 
C4244: '=' : conversion from 'u64' to 'byte', possible loss of data
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\sha512.c(352) : warning 
C4244: '=' : conversion from 'u64' to 'byte', possible loss of data
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\sha512.c(352) : warning 
C4244: '=' : conversion from 'u64' to 'byte', possible loss of data
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\sha512.c(353) : warning 
C4244: '=' : conversion from 'u64' to 'byte', possible loss of data
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\sha512.c(353) : warning 
C4244: '=' : conversion from 'u64' to 'byte', possible loss of data
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\sha512.c(353) : warning 
C4244: '=' : conversion from 'u64' to 'byte', possible loss of data
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\sha512.c(353) : warning 
C4244: '=' : conversion from 'u64' to 'byte', possible loss of data
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\sha512.c(353) : warning 
C4244: '=' : conversion from 'u64' to 'byte', possible loss of data
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\sha512.c(353) : warning 
C4244: '=' : conversion from 'u64' to 'byte', possible loss of data
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\sha512.c(353) : warning 
C4244: '=' : conversion from 'u64' to 'byte', possible loss of data
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\sha512.c(353) : warning 
C4244: '=' : conversion from 'u64' to 'byte', possible loss of data
16>serpent.c
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\serpent.c(588) : warning 
C4018: '<' : signed/unsigned mismatch
16>rijndael.c
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\rijndael.c(1767) : 
warning C4018: '<' : signed/unsigned mismatch
16>random.c
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\random.c(762) : warning 
C4018: '<' : signed/unsigned mismatch
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\random.c(1093) : warning 
C4244: 'function' : conversion from 'time_t' to 'unsigned int', 
possible loss of data
16>pubkey.c
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\pubkey.c(1436) : warning 
C4018: '<' : signed/unsigned mismatch
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\pubkey.c(1650) : warning 
C4018: '<' : signed/unsigned mismatch
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\pubkey.c(1991) : warning 
C4018: '<' : signed/unsigned mismatch
16>primegen.c
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\primegen.c(711) : warning 
C4018: '<' : signed/unsigned mismatch
16>cipher.c
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\cipher.c(784) : warning 
C4018: '<' : signed/unsigned mismatch
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\cipher.c(813) : warning 
C4018: '<' : signed/unsigned mismatch
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\cipher.c(844) : warning 
C4018: '<' : signed/unsigned mismatch
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\cipher.c(867) : warning 
C4018: '<' : signed/unsigned mismatch
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\cipher.c(870) : warning 
C4018: '<' : signed/unsigned mismatch
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\cipher.c(884) : warning 
C4018: '<=' : signed/unsigned mismatch
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\cipher.c(908) : warning 
C4018: '<' : signed/unsigned mismatch
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\cipher.c(932) : warning 
C4018: '<=' : signed/unsigned mismatch
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\cipher.c(937) : warning 
C4244: '=' : conversion from 'ulong' to 'byte', possible loss of 
data
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\cipher.c(938) : warning 
C4244: '=' : conversion from 'ulong' to 'byte', possible loss of 
data
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\cipher.c(948) : warning 
C4244: '=' : conversion from 'ulong' to 'byte', possible loss of 
data
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\cipher.c(949) : warning 
C4244: '=' : conversion from 'ulong' to 'byte', possible loss of 
data
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\cipher.c(960) : warning 
C4018: '<' : signed/unsigned mismatch
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\cipher.c(962) : warning 
C4244: '=' : conversion from 'ulong' to 'byte', possible loss of 
data
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\cipher.c(963) : warning 
C4244: '=' : conversion from 'ulong' to 'byte', possible loss of 
data
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\cipher.c(976) : warning 
C4244: '=' : conversion from 'ulong' to 'byte', possible loss of 
data
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\cipher.c(977) : warning 
C4244: '=' : conversion from 'ulong' to 'byte', possible loss of 
data
16>ac.c
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\ac.c(148) : warning 
C4018: '<' : signed/unsigned mismatch
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\ac.c(270) : warning 
C4018: '<' : signed/unsigned mismatch
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\ac.c(387) : warning 
C4018: '<' : signed/unsigned mismatch
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\ac.c(397) : warning 
C4018: '<' : signed/unsigned mismatch
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\ac.c(437) : warning 
C4018: '<' : signed/unsigned mismatch
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\ac.c(502) : warning 
C4018: '<' : signed/unsigned mismatch
16>..\..\libgcrypt\libgcrypt-1.2.2\cipher\ac.c(1051) : warning 
C4018: '<' : signed/unsigned mismatch
16>sexp.c
16>..\..\libgcrypt\libgcrypt-1.2.2\src\sexp.c(1104) : warning 
C4018: '>' : signed/unsigned mismatch
16>..\..\libgcrypt\libgcrypt-1.2.2\src\sexp.c(1458) : warning 
C4018: '<' : signed/unsigned mismatch
16>secmem.c
16>..\..\libgcrypt\libgcrypt-1.2.2\src\secmem.c(128) : warning 
C4018: '<' : signed/unsigned mismatch
16>..\..\libgcrypt\libgcrypt-1.2.2\src\secmem.c(184) : warning 
C4018: '<' : signed/unsigned mismatch
16>..\..\libgcrypt\libgcrypt-1.2.2\src\secmem.c(207) : warning 
C4018: '<' : signed/unsigned mismatch
16>..\..\libgcrypt\libgcrypt-1.2.2\src\secmem.c(588) : warning 
C4018: '<' : signed/unsigned mismatch




From ian at cypherpunks.ca  Sun Jul 19 10:41:43 2009
From: ian at cypherpunks.ca (Ian Goldberg)
Date: Sun, 19 Jul 2009 10:41:43 -0400
Subject: [OTR-dev] OTR + Second Life Client
In-Reply-To: <20090719072752.60EFBB8040@smtp.hushmail.com>
References: <20090719072752.60EFBB8040@smtp.hushmail.com>
Message-ID: <20090719144143.GE1952@yoink.cs.uwaterloo.ca>

On Sun, Jul 19, 2009 at 12:27:52AM -0700, chris-tuchs at hushmail.com wrote:
> I have gotten OTR compiled

Using a native Win32 compiler like VC++?  We'd love it if you posted
some detailed instructions on how to get that to work!

> and working in the Greenlife Emerald Viewer for Second Life.

Fantastic!

> I have
> not yet implemented any way to 
> authenticate a buddy; that is what I will be working on next.  
> However I wanted to put out an early plea for experienced OTR devs 
> to audit the code.  If you are interested in ensuring I didn't do 
> something dumb that might make OTR look bad, please send me an 
> email and I'll arrange for you to see the code.

While I good idea in theory, that would pretty much have to be me
personally, and I don't have the cycles to audit all third-party code
that uses OTR, unfortunately.  :-(  Normally we suggest ensuring that it
interoperates with other OTR-enabled software, but in your particular
case, I can imagine that might be tricky, since you're not talking to an
IM network that other OTR clients can speak to.

> One sign I may be doing something dumb is that during the compile 
> of OTR there are a number of warnings in the cryptographic 
> libraries.  Although most look OK to me, a few look serious.  I am 
> most concerned about those in libotr's auth.c and in libgcrypt's 
> mpih-div.c.  Thanks for your time!

Comments below.  Upshot: don't worry about it.

> 24>------ Rebuild All started: Project: libotr, Configuration: 
> RelWithDebInfo Win32 ------
> 24>Deleting intermediate and output files for project 'libotr', 
> configuration 'RelWithDebInfo|Win32'
> 24>Compiling...
> 24>auth.c
> 24>..\..\libotr\libotr-3.2.0\src\auth.c(385) : warning C4333: '>>' 
> : right shift by too large amount, data loss
> 24>..\..\libotr\libotr-3.2.0\src\auth.c(416) : warning C4333: '>>' 
> : right shift by too large amount, data loss
> 24>..\..\libotr\libotr-3.2.0\src\auth.c(523) : warning C4333: '>>' 
> : right shift by too large amount, data loss

Are the three lines above all of the form (pubkey_type >> 16)?  That was
a bug that's since been fixed in CVS; it should be 8, not 16.  But it
doesn't affect anything right now, since the only existing pubkey_type
is 0.

> 24>sm.c
> 24>..\..\libotr\libotr-3.2.0\src\sm.c(358) : warning C4018: '<' : 
> signed/unsigned mismatch
> 24>..\..\libotr\libotr-3.2.0\src\sm.c(362) : warning C4018: '<' : 
> signed/unsigned mismatch
> 24>..\..\libotr\libotr-3.2.0\src\sm.c(363) : warning C4018: '<' : 
> signed/unsigned mismatch
> 24>..\..\libotr\libotr-3.2.0\src\sm.c(370) : warning C4018: '<' : 
> signed/unsigned mismatch

No big deal, but it could be cleaned up.

> 24>proto.c
> 24>..\..\libotr\libotr-3.2.0\src\proto.c(785) : warning C4018: '>' 
> : signed/unsigned mismatch

Also not a big deal, since a signed int is being compared to an unsigned
short.

> 24>privkey.c
> 24>..\..\libotr\libotr-3.2.0\src\privkey.c(243) : warning C4018: 
> '<' : signed/unsigned mismatch
> 24>libotr - 0 error(s), 9 warning(s)

No issue here.

I can't comment on the libgcrypt issues.

   - Ian

From secq.002 at rediffmail.com  Sun Jul 19 15:33:54 2009
From: secq.002 at rediffmail.com (Sec)
Date: 19 Jul 2009 19:33:54 -0000
Subject: [OTR-dev] Cross compile pidgin-otr for windows
Message-ID: <1247976410.S.3724.27583.f5mail-236-220.rediffmail.com.1248032034.18471@webmail.rediffmail.com>

Ian,

On Sun, 19 Jul 2009 09:36:50 +0530  wrote
>On Sun, Jul 19, 2009 at 03:32:06AM -0000, Sec wrote:
>> Ian,
>> 
>> I compiled the ligcrypt and ligpgerror now using the configure method
>> for mingw below and I was able to compile libotr now successfully
>> under mingw.
>
>Great!
>
>> Now I tried compiling pidgin-otr using make -f Makefile.mingw after
>> giving the paths to pidgin and libpurple sources, but I get still some
>> *.h files not found like X11/Xutil.h etc. 
>> 
>> --> So I guess I guess similar compiling (like libgcrypt must be done
>> for all the once listed below as well in order to avoid not finding
>> some *.h files ? And the same follows for all *.h files it complains
>> as you start with one ?
>
>When you're cross-compiling for Windows, nothing at all should be
>looking for X11/Xutil.h. ?

> Did you give the paths to the *win32* pidgin
>and libpurple sources in /usr/i586-mingw32msvc/include/ ? ?You should
>also have the gtk-2.0/{gtk,gdk,gdk-pixbuf} header files in there. ?There
>should be no references to include files under X11 in those.
>

It was looking for X11 stuff due to some header file in  /usr/include/gtk-2.0/gdk/gdkx.h I think. I thought it will get the gtk paths from GTK_HDRS ?= `pkg-config --cflags glib-2.0 gtk+-2.0` (in Makefile.mingw) and we dont need have them in /usr/i586-mingw32msvc/include ? 

Should I have compiled gtk also in the mingw environment instead ? (Looking the above pkg-config in the Makefile.mingw I though native one should do). I tried also compiling gtk using the same configure method as in libotr
(./configure --with-pic --build=`./config.guess` --host=i586mingw32msvc --prefix=/usr/i586-mingw32msvc) but not with much luck.

Also I think the pidgin source is same for windows or linux (?)

I had extracted the tarball into my home directory and set the paths in Makefile.mingw of the pidgin-otr to directory that contained pidgin-source-root/pidgin and pidgin-source-root/libpurple respectively (this make it get the header files except gtkwin32dep.h which was in pidgin-source-root/pidgin/win32 and win32dep.h which was in pidgin-source-root/libpurple/win32. So simply copied these two *win32dep.h one directory up and compiled). 

Can you let me know how to get the right headers for the gtk related and if the copying of the *win32dep.h like above is the right way  ?

Sec

Kill snoopers dead
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/otr-dev/attachments/20090719/411638be/attachment.html>

From ian at cypherpunks.ca  Sun Jul 19 16:41:56 2009
From: ian at cypherpunks.ca (Ian Goldberg)
Date: Sun, 19 Jul 2009 16:41:56 -0400
Subject: [OTR-dev] Cross compile pidgin-otr for windows
In-Reply-To: <1247976410.S.3724.27583.f5mail-236-220.rediffmail.com.1248032034.18471@webmail.rediffmail.com>
References: <1247976410.S.3724.27583.f5mail-236-220.rediffmail.com.1248032034.18471@webmail.rediffmail.com>
Message-ID: <20090719204156.GH1952@yoink.cs.uwaterloo.ca>

On Sun, Jul 19, 2009 at 07:33:54PM -0000, Sec wrote:
> It was looking for X11 stuff due to some header file in
> /usr/include/gtk-2.0/gdk/gdkx.h I think. I thought it will get the gtk
> paths from GTK_HDRS ?= `pkg-config --cflags glib-2.0 gtk+-2.0` (in
> Makefile.mingw) and we dont need have them in
> /usr/i586-mingw32msvc/include ? 

The problem is that the GTK header files in /usr/include reference X11
stuff (as they should).  You need the Windows version (no X11) installed
in /usr/i586-mingw32msvc/include.

This is what I see.

$ ls -R /usr/i586-mingw32msvc/include/gtk-2.0
/usr/i586-mingw32msvc/include/gtk-2.0:
gdk  gdk-pixbuf  gtk

/usr/i586-mingw32msvc/include/gtk-2.0/gdk:
gdkalias.h           gdkdrawable.h   gdkimage.h    gdkprivate.h    gdktypes.h
gdkcairo.h           gdkenumtypes.h  gdkinput.h    gdkproperty.h   gdkvisual.h
gdkcolor.h           gdkevents.h     gdkkeys.h     gdkregion.h     gdkwin32.h
gdkcursor.h          gdkfont.h       gdkkeysyms.h  gdkrgb.h        gdkwindow.h
gdkdisplay.h         gdkgc.h         gdkpango.h    gdkscreen.h
gdkdisplaymanager.h  gdk.h           gdkpixbuf.h   gdkselection.h
gdkdnd.h             gdki18n.h       gdkpixmap.h   gdkspawn.h

/usr/i586-mingw32msvc/include/gtk-2.0/gdk-pixbuf:
gdk-pixbuf-animation.h   gdk-pixbuf.h          gdk-pixbuf-simple-anim.h
gdk-pixbuf-core.h        gdk-pixbuf-io.h       gdk-pixbuf-transform.h
gdk-pixbuf-enum-types.h  gdk-pixbuf-loader.h   gdk-pixdata.h
gdk-pixbuf-features.h    gdk-pixbuf-marshal.h

/usr/i586-mingw32msvc/include/gtk-2.0/gtk:
gtkaboutdialog.h           gtk.h                       gtkrecentfilter.h
gtkaccelgroup.h            gtkhandlebox.h              gtkrecentmanager.h
gtkaccellabel.h            gtkhbbox.h                  gtkruler.h
gtkaccelmap.h              gtkhbox.h                   gtkscale.h
gtkaccessible.h            gtkhpaned.h                 gtkscrollbar.h
gtkactiongroup.h           gtkhruler.h                 gtkscrolledwindow.h
gtkaction.h                gtkhscale.h                 gtkselection.h
gtkadjustment.h            gtkhscrollbar.h             gtkseparator.h
gtkalignment.h             gtkhseparator.h             gtkseparatormenuitem.h
gtkarrow.h                 gtkiconfactory.h            gtkseparatortoolitem.h
gtkaspectframe.h           gtkicontheme.h              gtksettings.h
gtkassistant.h             gtkiconview.h               gtksignal.h
gtkbbox.h                  gtkimage.h                  gtksizegroup.h
gtkbindings.h              gtkimagemenuitem.h          gtksocket.h
gtkbin.h                   gtkimcontext.h              gtkspinbutton.h
gtkbox.h                   gtkimcontextsimple.h        gtkstatusbar.h
gtkbutton.h                gtkimmodule.h               gtkstatusicon.h
gtkcalendar.h              gtkimmulticontext.h         gtkstock.h
gtkcelleditable.h          gtkinputdialog.h            gtkstyle.h
gtkcelllayout.h            gtkinvisible.h              gtktable.h
gtkcellrendereraccel.h     gtkitemfactory.h            gtktearoffmenuitem.h
gtkcellrenderercombo.h     gtkitem.h                   gtktextbuffer.h
gtkcellrenderer.h          gtklabel.h                  gtktextbufferrichtext.h
gtkcellrendererpixbuf.h    gtklayout.h                 gtktextchild.h
gtkcellrendererprogress.h  gtklinkbutton.h             gtktextdisplay.h
gtkcellrendererspin.h      gtklist.h                   gtktext.h
gtkcellrenderertext.h      gtklistitem.h               gtktextiter.h
gtkcellrenderertoggle.h    gtkliststore.h              gtktextlayout.h
gtkcellview.h              gtkmain.h                   gtktextmark.h
gtkcheckbutton.h           gtkmarshal.h                gtktexttag.h
gtkcheckmenuitem.h         gtkmenubar.h                gtktexttagtable.h
gtkclipboard.h             gtkmenu.h                   gtktextview.h
gtkclist.h                 gtkmenuitem.h               gtktipsquery.h
gtkcolorbutton.h           gtkmenushell.h              gtktoggleaction.h
gtkcolorseldialog.h        gtkmenutoolbutton.h         gtktogglebutton.h
gtkcolorsel.h              gtkmessagedialog.h          gtktoggletoolbutton.h
gtkcomboboxentry.h         gtkmisc.h                   gtktoolbar.h
gtkcombobox.h              gtkmodules.h                gtktoolbutton.h
gtkcombo.h                 gtknotebook.h               gtktoolitem.h
gtkcontainer.h             gtkobject.h                 gtktooltips.h
gtkctree.h                 gtkoldeditable.h            gtktreednd.h
gtkcurve.h                 gtkoptionmenu.h             gtktree.h
gtkdebug.h                 gtkpagesetup.h              gtktreeitem.h
gtkdialog.h                gtkpaned.h                  gtktreemodelfilter.h
gtkdnd.h                   gtkpapersize.h              gtktreemodel.h
gtkdrawingarea.h           gtkpixmap.h                 gtktreemodelsort.h
gtkeditable.h              gtkplug.h                   gtktreeselection.h
gtkentrycompletion.h       gtkpreview.h                gtktreesortable.h
gtkentry.h                 gtkprintcontext.h           gtktreestore.h
gtkenums.h                 gtkprintoperation.h         gtktreeviewcolumn.h
gtkeventbox.h              gtkprintoperationpreview.h  gtktreeview.h
gtkexpander.h              gtkprintsettings.h          gtktypebuiltins.h
gtkfilechooserbutton.h     gtkprivate.h                gtktypeutils.h
gtkfilechooserdialog.h     gtkprogressbar.h            gtkuimanager.h
gtkfilechooser.h           gtkprogress.h               gtkvbbox.h
gtkfilechooserwidget.h     gtkradioaction.h            gtkvbox.h
gtkfilefilter.h            gtkradiobutton.h            gtkversion.h
gtkfilesel.h               gtkradiomenuitem.h          gtkviewport.h
gtkfilesystem.h            gtkradiotoolbutton.h        gtkvpaned.h
gtkfixed.h                 gtkrange.h                  gtkvruler.h
gtkfontbutton.h            gtkrc.h                     gtkvscale.h
gtkfontsel.h               gtkrecentchooserdialog.h    gtkvscrollbar.h
gtkframe.h                 gtkrecentchooser.h          gtkvseparator.h
gtkgamma.h                 gtkrecentchoosermenu.h      gtkwidget.h
gtkgc.h                    gtkrecentchooserwidget.h    gtkwindow.h

> Should I have compiled gtk also in the mingw environment instead ?
> (Looking the above pkg-config in the Makefile.mingw I though native
> one should do). I tried also compiling gtk using the same configure
> method as in libotr (./configure --with-pic --build=`./config.guess`
> --host=i586mingw32msvc --prefix=/usr/i586-mingw32msvc) but not with
> much luck.

I certainly didn't compile gtk myself.  I'm sure I found a
tarball/zipfile of the Windows GTK headers somewhere.  But it was years
ago, so I have no memory of where, unfortunately.

> Also I think the pidgin source is same for windows or linux (?)

Yes, that's probably true.

> I had extracted the tarball into my home directory and set the paths
> in Makefile.mingw of the pidgin-otr to directory that contained
> pidgin-source-root/pidgin and pidgin-source-root/libpurple
> respectively (this make it get the header files except gtkwin32dep.h
> which was in pidgin-source-root/pidgin/win32 and win32dep.h which was
> in pidgin-source-root/libpurple/win32. So simply copied these two
> *win32dep.h one directory up and compiled). 

I do have files names /usr/i586-mingw32msvc/include/pidgin/gtkwin32dep.h
and /usr/i586-mingw32msvc/include/libpurple/win32dep.h on my system.

   - Ian

From chris-tuchs at hushmail.com  Sun Jul 19 21:54:10 2009
From: chris-tuchs at hushmail.com (chris-tuchs at hushmail.com)
Date: Sun, 19 Jul 2009 18:54:10 -0700
Subject: [OTR-dev] OTR + Second Life Client
Message-ID: <20090720015410.2F8B720045@smtp.hushmail.com>

On Sun, 19 Jul 2009 07:41:43 -0700 Ian Goldberg 
<ian at cypherpunks.ca> wrote:
>On Sun, Jul 19, 2009 at 12:27:52AM -0700, chris-tuchs at hushmail.com 
>wrote:
>> I have gotten OTR compiled
>
>Using a native Win32 compiler like VC++?  We'd love it if you 
>posted some detailed instructions on how to get that to work!
>
>> and working in the Greenlife Emerald Viewer for Second Life.
>
>Fantastic!

I would be happy to share what I know.  But mostly what I did was 
take trilian's port of libgcrypt, libgpg-error, and libotr and 
converted it to use cmake.  I 'read' the project files they had and 
hand built/edited existing cmake files.  The Secondlife Client code 
uses cmake to generate platform specific makefiles.  In my case 
.proj files for Microsoft's Visual C++ 2005 Express Edition.  Then 
I replaced the older libotr in trillian with the latest from the 
otr website.  The code will be published in the next public release 
of Greenlife Emerald client.  I will also probably make a patch to 
run against a stock version of the secondlife client.  But all that 
after we get the otr stuff running right on all three platforms 
(Linux, Mac, and Microsoft.)

>> plea to audit the code
>While I good idea in theory, that would pretty much have to be me
>personally, and I don't have the cycles to audit all third-party 
>code that uses OTR, unfortunately.  :-(  Normally we suggest 
ensuring 
>that it interoperates with other OTR-enabled software

This is my proposed test procedure.  Secondlife-Avy1(otr) -> 
secondlife-avy2(no otr) -> manual cut and paste -> im-user1(no otr) 
-> im-user2(otr).  And back and forth with 3 men-in-the-middle.  
Hopefully secondlife-avy1(otr) and im-user2(otr) will be able to 
communicate and eventually even authenticate each other.  Will that 
work?  Will I need to play tricks with the names of the IM and 
second life users?  Make the secondlife client "lie" about what 
protocol it's using?

>I can't comment on the libgcrypt issues.
>
>   - Ian

Thanks for looking at the libotr issues.  I'll bug the libgcrypt 
folks with the others.

When I have SMP and can authenticate buddies, I would like to have 
the Greenlife Emerald viewer listed on the software page if you 
don't mind.

Chris


From ian at cypherpunks.ca  Sun Jul 19 22:02:14 2009
From: ian at cypherpunks.ca (Ian Goldberg)
Date: Sun, 19 Jul 2009 22:02:14 -0400
Subject: [OTR-dev] OTR + Second Life Client
In-Reply-To: <20090720015410.2F8B720045@smtp.hushmail.com>
References: <20090720015410.2F8B720045@smtp.hushmail.com>
Message-ID: <20090720020214.GK1952@yoink.cs.uwaterloo.ca>

On Sun, Jul 19, 2009 at 06:54:10PM -0700, chris-tuchs at hushmail.com wrote:
> This is my proposed test procedure.  Secondlife-Avy1(otr) -> 
> secondlife-avy2(no otr) -> manual cut and paste -> im-user1(no otr) 
> -> im-user2(otr).  And back and forth with 3 men-in-the-middle.  
> Hopefully secondlife-avy1(otr) and im-user2(otr) will be able to 
> communicate and eventually even authenticate each other.  Will that 
> work?

That should work great, actually.  [And very clever. ;-) ]

> Will I need to play tricks with the names of the IM and second life
> users?  Make the secondlife client "lie" about what protocol it's
> using?

Nope, it should all work smoothly, at least until you try to
authenticate.  At that point, im-user2 will be asking you to
authenticate im-user1 (since that's who the IM client thinks it's
talking to).  But of course, since you're controlling the MITM channel,
you could just authenticate Secondlife-Avy1 instead.  Or something like
that.

> When I have SMP and can authenticate buddies, I would like to have 
> the Greenlife Emerald viewer listed on the software page if you 
> don't mind.

Will do.  Just let us know when it's ready for prime time.

   - Ian

From kaner.mail at gmail.com  Mon Jul 20 04:36:34 2009
From: kaner.mail at gmail.com (Christian Fromme)
Date: Mon, 20 Jul 2009 10:36:34 +0200
Subject: [OTR-dev] Interop problems with libotr - DSA signature
In-Reply-To: <4A620789.7080808@t-online.de>
References: <4A61E382.5060803@t-online.de>
	<20090718155704.GG20935@yoink.cs.uwaterloo.ca>
	<4A620789.7080808@t-online.de>
Message-ID: <dcec83710907200136r2d2316b3m4eca0bb874b55635@mail.gmail.com>

Hi,

On Sat, Jul 18, 2009 at 7:34 PM, Werner
Dittmann<Werner.Dittmann at t-online.de> wrote:
>> Note that if you can get the standard DSA implementation you're using to
>> not hash its input,
>
> The current BC DSA signature implemenation just takes the input and does not
> hash it (only the JCE variant performs a hash before it signs, the

We're working on a Java version of OTR, too. We also use BC DSA but
didn't encounter the problem described yet because we didn't test this
so far. So thanks for the heads up!

I am wondering, under what licence will your otr4j lib be released, Werner?

And also, are you using BC libs as well for your implementation, Ian?
Or something else? Wrote your own?

Best,
Christian

From geekius.caesar at gmail.com  Mon Jul 20 06:05:19 2009
From: geekius.caesar at gmail.com (Geekius Caesar)
Date: Mon, 20 Jul 2009 12:05:19 +0200
Subject: [OTR-dev] Interop problems with libotr - DSA signature
In-Reply-To: <dcec83710907200136r2d2316b3m4eca0bb874b55635@mail.gmail.com>
References: <4A61E382.5060803@t-online.de>
	<20090718155704.GG20935@yoink.cs.uwaterloo.ca>
	<4A620789.7080808@t-online.de>
	<dcec83710907200136r2d2316b3m4eca0bb874b55635@mail.gmail.com>
Message-ID: <e1d91e910907200305r2e7e133by27f7f95c9c334dd1@mail.gmail.com>

Hello Christian,

otr4j is available here http://code.google.com/p/otr4j and is released under
LGPL. Also what Ian proposes works like a charm :)

kind regards,
George.

On Mon, Jul 20, 2009 at 10:36 AM, Christian Fromme <kaner.mail at gmail.com>wrote:

> Hi,
>
> On Sat, Jul 18, 2009 at 7:34 PM, Werner
> Dittmann<Werner.Dittmann at t-online.de> wrote:
> >> Note that if you can get the standard DSA implementation you're using to
> >> not hash its input,
> >
> > The current BC DSA signature implemenation just takes the input and does
> not
> > hash it (only the JCE variant performs a hash before it signs, the
>
> We're working on a Java version of OTR, too. We also use BC DSA but
> didn't encounter the problem described yet because we didn't test this
> so far. So thanks for the heads up!
>
> I am wondering, under what licence will your otr4j lib be released, Werner?
>
> And also, are you using BC libs as well for your implementation, Ian?
> Or something else? Wrote your own?
>
> Best,
> Christian
> _______________________________________________
> OTR-dev mailing list
> OTR-dev at lists.cypherpunks.ca
> http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/otr-dev/attachments/20090720/a5cbd979/attachment.htm>

From ian at cypherpunks.ca  Mon Jul 20 08:54:38 2009
From: ian at cypherpunks.ca (Ian Goldberg)
Date: Mon, 20 Jul 2009 08:54:38 -0400
Subject: [OTR-dev] Interop problems with libotr - DSA signature
In-Reply-To: <dcec83710907200136r2d2316b3m4eca0bb874b55635@mail.gmail.com>
References: <4A61E382.5060803@t-online.de>
	<20090718155704.GG20935@yoink.cs.uwaterloo.ca>
	<4A620789.7080808@t-online.de>
	<dcec83710907200136r2d2316b3m4eca0bb874b55635@mail.gmail.com>
Message-ID: <20090720125438.GF19760@thunk.cs.uwaterloo.ca>

On Mon, Jul 20, 2009 at 10:36:34AM +0200, Christian Fromme wrote:
> And also, are you using BC libs as well for your implementation, Ian?
> Or something else? Wrote your own?

We abstracted the crypto, allowing us to "plug in" different
implementations.  So far, we've plugged in JCA and RIM's crypto API.  BC
was intended to be the third option, but we haven't had the need for it
just yet.

   - Ian

From chris-tuchs at hushmail.com  Wed Jul 22 04:40:50 2009
From: chris-tuchs at hushmail.com (chris-tuchs at hushmail.com)
Date: Wed, 22 Jul 2009 01:40:50 -0700
Subject: [OTR-dev] Reccomended version of libgcrypt? Libotr status
	messages.
Message-ID: <20090722084050.DB4F1B8044@smtp.hushmail.com>

One of the other developers on the GreenLife Emerald Viewer team 
found and fixed a bug in libgcrypt 1.2.2 that causes the program to 
hang when generating a private/public key pair under microsoft 
windows 7 OS.  I went to the libgcrypt site to see what they knew 
about the issue.  Turns out the most current version is 1.4.4 and 
is GPL3, and the most recent LGPL version is 1.2.3.

What version of libgcrypt is recommended?

Due to the nature of IM in Second Life, HTML markup looks ugly.  Is 
there a better way to change the messages libotr generates than to 
edit proto.c and message.c?

We have a significant number of German speakers who use GreenLife, 
how is localization/translation handled?

Chris


From ian at cypherpunks.ca  Wed Jul 22 08:21:53 2009
From: ian at cypherpunks.ca (Ian Goldberg)
Date: Wed, 22 Jul 2009 08:21:53 -0400
Subject: [OTR-dev] Reccomended version of libgcrypt? Libotr
	status	messages.
In-Reply-To: <20090722084050.DB4F1B8044@smtp.hushmail.com>
References: <20090722084050.DB4F1B8044@smtp.hushmail.com>
Message-ID: <20090722122153.GB29739@thunk.cs.uwaterloo.ca>

On Wed, Jul 22, 2009 at 01:40:50AM -0700, chris-tuchs at hushmail.com wrote:
> One of the other developers on the GreenLife Emerald Viewer team 
> found and fixed a bug in libgcrypt 1.2.2 that causes the program to 
> hang when generating a private/public key pair under microsoft 
> windows 7 OS.  I went to the libgcrypt site to see what they knew 
> about the issue.  Turns out the most current version is 1.4.4 and 
> is GPL3, and the most recent LGPL version is 1.2.3.
> 
> What version of libgcrypt is recommended?

I'm still using 1.2.x, with the patch on the OTR website to fix the key
generation problem:

http://www.cypherpunks.ca/otr/rndw32.diff

But 1.4.4 still seems to be LGPL:
http://hpux.connect.org.uk/hppd/hpux/Gnu/libgcrypt-1.4.4/readme.html

Were you looking at GNUtls, perchance?  That's GPL3, I think.

> Due to the nature of IM in Second Life, HTML markup looks ugly.  Is 
> there a better way to change the messages libotr generates than to 
> edit proto.c and message.c?
> 
> We have a significant number of German speakers who use GreenLife, 
> how is localization/translation handled?

Both of these issues relate to constant strings in libotr.  Those have
been removed in the development version of the library (for exactly the
reasons you identify), currently checked into CVS at sourceforge.  If
you want to use the last release, editing the strings is probably the
best you can do, or you can see if you can use the CVS version of the
API.

   - Ian

From js-otrim at webkeks.org  Wed Jul 22 10:07:14 2009
From: js-otrim at webkeks.org (Jonathan Schleifer)
Date: Wed, 22 Jul 2009 16:07:14 +0200
Subject: [OTR-dev] Reccomended version of libgcrypt? Libotr status
 messages.
In-Reply-To: <20090722122153.GB29739@thunk.cs.uwaterloo.ca>
References: <20090722084050.DB4F1B8044@smtp.hushmail.com>
	<20090722122153.GB29739@thunk.cs.uwaterloo.ca>
Message-ID: <20090722160714.0462301c@webkeks.org>

Ian Goldberg <ian at cypherpunks.ca> wrote:

> Both of these issues relate to constant strings in libotr.  Those have
> been removed in the development version of the library (for exactly
> the reasons you identify), currently checked into CVS at
> sourceforge.  If you want to use the last release, editing the
> strings is probably the best you can do, or you can see if you can
> use the CVS version of the API.

Good to hear that - we might implement OTR again in Gajim if this is
really a clean design now.

One question though: Would it be possible to encrypt whole stanzas
maybe in a way that is still compatible with transports? For example
you encrypt the body in a way that is backwards-compatible and then you
encrypt additional tags that can be attached to a message (like
XHTML-IM) separately, which are then only handled if the client on the
other side is a Jabber client.

Btw, there is currently discussion about an end to end encryption on
the XMPP IETF list, maybe you could join it and OTR could be made more
XMPP-compatible :). Who knows, maybe it'll even get the official
solution for XMPP then ;).

-- 
Jonathan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: </pipermail/otr-dev/attachments/20090722/a38f0601/attachment.pgp>

From chris-tuchs at hushmail.com  Wed Jul 22 13:43:30 2009
From: chris-tuchs at hushmail.com (chris-tuchs at hushmail.com)
Date: Wed, 22 Jul 2009 10:43:30 -0700
Subject: [OTR-dev] Reccomended version of libgcrypt? Libotr status
	messages.
Message-ID: <20090722174331.40827B8044@smtp.hushmail.com>

On Wed, 22 Jul 2009 05:21:53 -0700 Ian Goldberg 
<ian at cypherpunks.ca> wrote:
>On Wed, Jul 22, 2009 at 01:40:50AM -0700, chris-tuchs at hushmail.com 
wrote:
>> What version of libgcrypt is recommended?
>
>I'm still using 1.2.x, with the patch on the OTR website to fix 
>the key generation problem:
>
>http://www.cypherpunks.ca/otr/rndw32.diff
>
>But 1.4.4 still seems to be LGPL:
>http://hpux.connect.org.uk/hppd/hpux/Gnu/libgcrypt-
>1.4.4/readme.html
>
>Were you looking at GNUtls, perchance?  That's GPL3, I think.

I was reading the FSF website not the source code.

http://directory.fsf.org/project/libgcrypt/

Chris


From ian at cypherpunks.ca  Wed Jul 22 16:00:22 2009
From: ian at cypherpunks.ca (Ian Goldberg)
Date: Wed, 22 Jul 2009 16:00:22 -0400
Subject: [OTR-dev] Reccomended version of libgcrypt? Libotr
	status	messages.
In-Reply-To: <20090722174331.40827B8044@smtp.hushmail.com>
References: <20090722174331.40827B8044@smtp.hushmail.com>
Message-ID: <20090722200022.GB31892@thunk.cs.uwaterloo.ca>

On Wed, Jul 22, 2009 at 10:43:30AM -0700, chris-tuchs at hushmail.com wrote:
> On Wed, 22 Jul 2009 05:21:53 -0700 Ian Goldberg 
> <ian at cypherpunks.ca> wrote:
> >On Wed, Jul 22, 2009 at 01:40:50AM -0700, chris-tuchs at hushmail.com 
> wrote:
> >> What version of libgcrypt is recommended?
> >
> >I'm still using 1.2.x, with the patch on the OTR website to fix 
> >the key generation problem:
> >
> >http://www.cypherpunks.ca/otr/rndw32.diff
> >
> >But 1.4.4 still seems to be LGPL:
> >http://hpux.connect.org.uk/hppd/hpux/Gnu/libgcrypt-
> >1.4.4/readme.html
> >
> >Were you looking at GNUtls, perchance?  That's GPL3, I think.
> 
> I was reading the FSF website not the source code.
> 
> http://directory.fsf.org/project/libgcrypt/

I see; the reason seems to be that there are helper programs (gcryptrnd
and getrandom) that are GPL, but the library itself is LGPL.

   - Ian

From ian at cypherpunks.ca  Wed Jul 22 16:02:03 2009
From: ian at cypherpunks.ca (Ian Goldberg)
Date: Wed, 22 Jul 2009 16:02:03 -0400
Subject: [OTR-dev] Reccomended version of libgcrypt? Libotr
	status	messages.
In-Reply-To: <20090722160714.0462301c@webkeks.org>
References: <20090722084050.DB4F1B8044@smtp.hushmail.com>
	<20090722122153.GB29739@thunk.cs.uwaterloo.ca>
	<20090722160714.0462301c@webkeks.org>
Message-ID: <20090722200203.GC31892@thunk.cs.uwaterloo.ca>

On Wed, Jul 22, 2009 at 04:07:14PM +0200, Jonathan Schleifer wrote:
> Ian Goldberg <ian at cypherpunks.ca> wrote:
> 
> > Both of these issues relate to constant strings in libotr.  Those have
> > been removed in the development version of the library (for exactly
> > the reasons you identify), currently checked into CVS at
> > sourceforge.  If you want to use the last release, editing the
> > strings is probably the best you can do, or you can see if you can
> > use the CVS version of the API.
> 
> Good to hear that - we might implement OTR again in Gajim if this is
> really a clean design now.

I'd actually love to get your feedback on whether what's in CVS now
would work for you.

> One question though: Would it be possible to encrypt whole stanzas
> maybe in a way that is still compatible with transports? For example
> you encrypt the body in a way that is backwards-compatible and then you
> encrypt additional tags that can be attached to a message (like
> XHTML-IM) separately, which are then only handled if the client on the
> other side is a Jabber client.

Sorry, I'm not following.  Can you give an example?

Thanks,

   - Ian

From paul at cypherpunks.ca  Wed Jul 22 17:13:46 2009
From: paul at cypherpunks.ca (Paul Wouters)
Date: Wed, 22 Jul 2009 17:13:46 -0400 (EDT)
Subject: [OTR-dev] Reccomended version of libgcrypt? Libotr status
 messages.
In-Reply-To: <20090722122153.GB29739@thunk.cs.uwaterloo.ca>
References: <20090722084050.DB4F1B8044@smtp.hushmail.com>
	<20090722122153.GB29739@thunk.cs.uwaterloo.ca>
Message-ID: <alpine.LFD.1.10.0907221709130.2422@newtla.xelerance.com>

On Wed, 22 Jul 2009, Ian Goldberg wrote:

> Both of these issues relate to constant strings in libotr.  Those have
> been removed in the development version of the library (for exactly the
> reasons you identify), currently checked into CVS at sourceforge.  If

Or check the git repository at: http://gsoc.xelerance.com/projects/otr-symkey

git clone git://gsoc.xelerance.com/libotr.git/
git clone git://gsoc.xelerance.com/pidgin-otr.git/

There are also some pre-release source tar.gz files at ftp://ftp.xelerance.com/
for libotr and pidgin-otr that contain the latest cvs code plus some patches.

Paul

From chris-tuchs at hushmail.com  Wed Jul 22 17:48:24 2009
From: chris-tuchs at hushmail.com (chris-tuchs at hushmail.com)
Date: Wed, 22 Jul 2009 14:48:24 -0700
Subject: [OTR-dev] Require encryption
Message-ID: <20090722214824.834CEB0048@smtp.hushmail.com>

There seems to be code to support setting up libotr with a policy 
that requires encryption.  Who notifies whom about policy 
'breaches' in this case?

Suppose Bob requires encryption, Alice doesn't.  Then Alice tries 
to IM Bob in plain text.  What parts of their respective libotr 
code gets executed and who gets told it isn't allowed?

The symptoms we are seeing are that Alice gets no reply from Bob 
and that neither gets any notification of the problem.  Is there a 
bug in libotr, in our use of it, in our understanding of it?  I 
suspect a bug in our use, a co-developer is implementing a auto-
responder outside the libotr code base.

Chris


From ian at cypherpunks.ca  Wed Jul 22 18:34:27 2009
From: ian at cypherpunks.ca (Ian Goldberg)
Date: Wed, 22 Jul 2009 18:34:27 -0400
Subject: [OTR-dev] Reccomended version of libgcrypt? Libotr
	status	messages.
In-Reply-To: <alpine.LFD.1.10.0907221709130.2422@newtla.xelerance.com>
References: <20090722084050.DB4F1B8044@smtp.hushmail.com>
	<20090722122153.GB29739@thunk.cs.uwaterloo.ca>
	<alpine.LFD.1.10.0907221709130.2422@newtla.xelerance.com>
Message-ID: <20090722223427.GC14841@yoink.cs.uwaterloo.ca>

On Wed, Jul 22, 2009 at 05:13:46PM -0400, Paul Wouters wrote:
> On Wed, 22 Jul 2009, Ian Goldberg wrote:
>
>> Both of these issues relate to constant strings in libotr.  Those have
>> been removed in the development version of the library (for exactly the
>> reasons you identify), currently checked into CVS at sourceforge.  If
>
> Or check the git repository at: http://gsoc.xelerance.com/projects/otr-symkey
>
> git clone git://gsoc.xelerance.com/libotr.git/
> git clone git://gsoc.xelerance.com/pidgin-otr.git/
>
> There are also some pre-release source tar.gz files at ftp://ftp.xelerance.com/
> for libotr and pidgin-otr that contain the latest cvs code plus some patches.

Note that the above git repos contain a modified wire protocol which
calls itself v3, but which will *not* be the same as the final version
of v3.  DO NOT release software with the above libraries!

   - Ian

From chris-tuchs at hushmail.com  Sat Jul 25 21:00:33 2009
From: chris-tuchs at hushmail.com (chris-tuchs at hushmail.com)
Date: Sat, 25 Jul 2009 18:00:33 -0700
Subject: [OTR-dev]  GreenLife Emerald Viewer supports OTR
Message-ID: <20090726010033.7EE1F20041@smtp.hushmail.com>

I am writing to announce that GreenLife Emerald Viewer version 433 
is now shipping to users with OTR support.  The implementation 
currently only does "Manual fingerprint verification" for 
"authenticate buddy" but I am in the middle of implementing SMP and 
it will appear in a future release.  Source and binaries for Linux, 
Mac and Microsoft windows are available at 
http://modularsystems.sl/.  The website is currently being slash-
dotted with all the users downloading the new version so the home 
page looks ugly.

The Second Life IM system unfortunately displays tab characters as 
small white blocks, so OTR's white space tag is not sent as part of 
regular messages.  Instead it is put on the "stopped typing" 
messages which are never displayed, but which are examined for the 
presence/absence of the white space tag.  Nothing was done to stop 
OTR from seeing white space tags in regular IM so if another 
implementation chooses to send them there GreenLife's 
implementation will see and honor them.

This implementation does not encrypt "started typing" or "stopped 
typing" messages, so there is a "traffic analysis" type privacy 
leak.  Neither does it try to randomly pad message lengths giving 
another traffic analysis privacy leak.  This implementation does 
not support V1 of the protocol, that is disabled in the "policy" 
choice, but it is an easy change to make if you want V1 in second 
life.

Please add "GreenLife Emerald Viewer, a Second Life Client" to the 
list of systems that support OTR and link the entry to  
http://modularsystems.sl/

Thank you for all the support I received here.

Chris


From chris-tuchs at hushmail.com  Sun Jul 26 05:25:29 2009
From: chris-tuchs at hushmail.com (chris-tuchs at hushmail.com)
Date: Sun, 26 Jul 2009 02:25:29 -0700
Subject: [OTR-dev] Pidgin + Yahoo not support SMP?
Message-ID: <20090726092529.1EBDFB8046@smtp.hushmail.com>

Does Pidgin correctly do SMP over a Yahoo IM connection?  I have 
never seen it work and I suspect I know the cause.  When I test my 
SMP code using the 3-men-in-the-middle set up, I only see the last 
chunk of fragmented messages coming from Pidgin.  When I initiate 
the SMP in Second life I get only the fourth of four chunks from 
Pidgin, and when Pidgin initiates SMP I get only the second chunk 
of a two part message.

Is this a known issue?  Is the a fix or work-around?  I am using 
Pidgin 2.5.8 (libpurple 2.5.8) according to "help > about"

Chris


From ian at cypherpunks.ca  Tue Jul 28 16:50:38 2009
From: ian at cypherpunks.ca (Ian Goldberg)
Date: Tue, 28 Jul 2009 16:50:38 -0400
Subject: [OTR-dev] GreenLife Emerald Viewer supports OTR
In-Reply-To: <20090726010033.7EE1F20041@smtp.hushmail.com>
References: <20090726010033.7EE1F20041@smtp.hushmail.com>
Message-ID: <20090728205038.GS14841@yoink.cs.uwaterloo.ca>

On Sat, Jul 25, 2009 at 06:00:33PM -0700, chris-tuchs at hushmail.com wrote:
> Please add "GreenLife Emerald Viewer, a Second Life Client" to the 
> list of systems that support OTR and link the entry to  
> http://modularsystems.sl/

Done.

   - Ian

From ian at cypherpunks.ca  Tue Jul 28 16:53:05 2009
From: ian at cypherpunks.ca (Ian Goldberg)
Date: Tue, 28 Jul 2009 16:53:05 -0400
Subject: [OTR-dev] Pidgin + Yahoo not support SMP?
In-Reply-To: <20090726092529.1EBDFB8046@smtp.hushmail.com>
References: <20090726092529.1EBDFB8046@smtp.hushmail.com>
Message-ID: <20090728205305.GT14841@yoink.cs.uwaterloo.ca>

On Sun, Jul 26, 2009 at 02:25:29AM -0700, chris-tuchs at hushmail.com wrote:
> Does Pidgin correctly do SMP over a Yahoo IM connection?  I have 
> never seen it work and I suspect I know the cause.  When I test my 
> SMP code using the 3-men-in-the-middle set up, I only see the last 
> chunk of fragmented messages coming from Pidgin.  When I initiate 
> the SMP in Second life I get only the fourth of four chunks from 
> Pidgin, and when Pidgin initiates SMP I get only the second chunk 
> of a two part message.
> 
> Is this a known issue?  Is the a fix or work-around?  I am using 
> Pidgin 2.5.8 (libpurple 2.5.8) according to "help > about"

I've never seen this problem before.  But I know Yahoo just changed
their wire protocol, and them having lowered their MSS would be totally
consistent with your observations.  Can you try lowering the yahoo MSS
in the pidgin-otr code and see if that fixes it?

Thanks,

   - Ian

From chris-tuchs at hushmail.com  Wed Jul 29 01:52:08 2009
From: chris-tuchs at hushmail.com (chris-tuchs at hushmail.com)
Date: Tue, 28 Jul 2009 22:52:08 -0700
Subject: [OTR-dev] Pidgin + Yahoo not support SMP?
Message-ID: <20090729055208.8DB0320042@smtp.hushmail.com>

On Tue, 28 Jul 2009 13:53:05 -0700 Ian Goldberg 
<ian at cypherpunks.ca> wrote:
>On Sun, Jul 26, 2009 at 02:25:29AM -0700, chris-tuchs at hushmail.com 
wrote:
>> Does Pidgin correctly do SMP over a Yahoo IM connection?
>[...snip...]I know Yahoo just changed their wire protocol, and them
>having lowered their MSS would be totally consistent with your
>observations.  Can you try lowering the yahoo MSS in the pidgin-otr
>code and see if that fixes it?

My experiments with the Yahoo web client limit me to transmitting 
650
characters, using the Yahoo supplied Microsoft windows client I can
send 800.  My test string was "123456789." repeated with no spaces. 
 I
read the source code for pidgin-otr plugin, and created a file named
"otr.max_message_size" in the directory containing my key files.  
The
file contains:
prpl-msn	1409
prpl-icq	2346
prpl-aim	2343
prpl-yahoo	799
prpl-gg	1999
prpl-irc	417
prpl-oscar	2343
Which is <protocol-name><tab><MSS><newline> for each protocol.  The
source opens the file in text mode so I used the OS preferred line
terminator, \r\n, not the bare \n character.  I used the defaults 
from
the source, except I lowered prpl-yahoo from 832 to 799.  I was able
to receive two parts of a two part message that Pidgin generated to
initiate a Question and Answer style SMP exchange.  I have not yet
run a Pidgin to Pidgin via Yahoo SMP test.  I believe this will be
sufficient for my purposes while finishing the SMP protocol handling
in GreenLife Emerald Viewer.

Chris

P.S. Thanks for the listing on the software page!


From chris-tuchs at hushmail.com  Thu Jul 30 22:26:57 2009
From: chris-tuchs at hushmail.com (chris-tuchs at hushmail.com)
Date: Thu, 30 Jul 2009 19:26:57 -0700
Subject: [OTR-dev] Pidgin + Yahoo not support SMP?
Message-ID: <20090731022657.95C11B0058@smtp.hushmail.com>

I just ran a pidgin to pidgin via yahoo test of SMP.  It doesn't 
seem to work with the MSS set to 799 or to 640 using the method I 
described in my previous email.  Alice and Bob have a private 
(authenticated) conversation.  Alice and Bob are able to send each 
other 2000 character IMs which OTR seems to encrypt, fragment, 
reassemble, and decrypt correctly.  Alice does "Authenticate buddy" 
and uses "Type the word secret" as the question and "secret" as the 
answer.  Bob enters secret when prompted, presses the authenticate 
button.  Both Alice and Bob see a progress bar dialog box that 
remains stalled.  I have not run the test in a 3-men-in-the-middle 
configuration so I have no data on the actual messages sent and 
received.

Chris