From alexander.buchner@gmx.de Fri May 2 13:42:44 2008 From: alexander.buchner@gmx.de (Alexander Buchner) Date: Fri, 02 May 2008 14:42:44 +0200 Subject: [OTR-users] "Automatically initiate private messaging" doesn't work Message-ID: <481B0C44.7050804@gmx.de> This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig560516F5D4B3D59D688EBBCD Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi, I'm new to the mailing list and I don't know if/how I can reply to an exi= sting=20 thread. My problem looks like the same problem that was posted here=20 http://lists.cypherpunks.ca/pipermail/otr-users/2008-April/001273.html. T= oday I=20 exchanged 20 or so messages with a friend before I noticed, that no priva= te=20 conversation was initiated. By manually starting the OTR-session, this wo= rks=20 fine, but not automatically. In my global OTR Settings [X] Automatically initiate private messaging is= =20 activated and with this friend I use the standard options. I know that I can activate "Require private messaging" per buddy, but thi= s is=20 quite annoying if one has to do this for 15-20 people. I can't globally s= et this=20 option, because there are people on my ContactList, who can't encrypt wit= h OTR. Is this a known bug? What could go wrong? My system: Windows XP SP 3, Pidgin 2.4.1, OTR 3.1.0 My friend's system Windows XP SP 2, Pidgin 2.4.1, OTR 3.1.0 Alexander --=20 Mein =F6ffentlicher PGP-Key: http://www.rzuser.uni-heidelberg.de/~abuchner/pgp.asc --------------enig560516F5D4B3D59D688EBBCD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQIcBAEBAgAGBQJIGwxEAAoJEByY8i5PPbAisgQQALkm/mL0BDIsFrCoRg+iqWwj EpxocL2f7LEkCZ4/zJWqMjrhBHWlffQLNJdFAWov+BoXu1Tgd0HIY1Tgv6dnBdhX unb2yaLYDc3h4TLAeYOB429CfZlPWGiDFcjd0lwFr0adpU/ImS06/woo5boLB4ft 7Oc77bJf9YzXk2JVFgSJGM8kjgRO58U1YDPl01gHSXl/B5JvTW8DyBCLJLrEJbX8 GQcn/VHn9W3Lg+MHxucYSMejo5deu2N6OPWCf8ihtuXf0NNOl5EsXmKbyfbj+qIm AZvuLWKo/7Lbxgb378Cr/IbPNyhh74liq8RpMAyZmi7KdKYGAimx2cGDoSaHpBYr FTRxvs9iHstqi8iU0Brkpf6orHObesAWanfi6CUQhyaTseSSHWpyY8GN9EebfVTr w72jP2KAXb8ltNYU0UTZeFPcGMA8BmJOBucLTswBbfG/vGqdo8Zv8419bhoe+Flv ZNBM0bDtrSZoS3JklF7TwgzC2xbGoeY5hJb13eU851JDAdV4lelr/h7QJpBQ7Jdc iYI8PjIJRfNx9qjVFiZpO5JhDrs/TyHigVAg9VIA0QpvXuY5K1XVaDFfIaFeh9cf zBA8NDq3OqLYrNWVqqrVxFHx+MeBNjOY65askrRIGJqsiYj/wRy9Hn7CHvWuX4t/ 1wdqiahGvOuHhNesuHQG =yUk3 -----END PGP SIGNATURE----- --------------enig560516F5D4B3D59D688EBBCD-- From ian@cypherpunks.ca Sat May 3 02:35:20 2008 From: ian@cypherpunks.ca (Ian Goldberg) Date: Fri, 2 May 2008 21:35:20 -0400 Subject: [OTR-users] "Automatically initiate private messaging" doesn't work In-Reply-To: <481B0C44.7050804@gmx.de> References: <481B0C44.7050804@gmx.de> Message-ID: <20080503013520.GE6425@yoink.cs.uwaterloo.ca> On Fri, May 02, 2008 at 02:42:44PM +0200, Alexander Buchner wrote: > Hi, > > I'm new to the mailing list and I don't know if/how I can reply to an > existing thread. > My problem looks like the same problem that was posted here > http://lists.cypherpunks.ca/pipermail/otr-users/2008-April/001273.html. > Today I exchanged 20 or so messages with a friend before I noticed, that no > private conversation was initiated. By manually starting the OTR-session, > this works fine, but not automatically. > In my global OTR Settings [X] Automatically initiate private messaging is > activated and with this friend I use the standard options. > I know that I can activate "Require private messaging" per buddy, but this > is quite annoying if one has to do this for 15-20 people. I can't globally > set this option, because there are people on my ContactList, who can't > encrypt with OTR. > Is this a known bug? What could go wrong? > > My system: > Windows XP SP 3, Pidgin 2.4.1, OTR 3.1.0 > > My friend's system > Windows XP SP 2, Pidgin 2.4.1, OTR 3.1.0 Could you possibly capture the raw incoming and outgoing packets? What IM network are you using? Thanks, - Ian From alexander.buchner@gmx.de Sat May 3 09:37:20 2008 From: alexander.buchner@gmx.de (Alexander Buchner) Date: Sat, 03 May 2008 10:37:20 +0200 Subject: [OTR-users] "Automatically initiate private messaging" doesn't work In-Reply-To: <20080503013520.GE6425@yoink.cs.uwaterloo.ca> References: <481B0C44.7050804@gmx.de> <20080503013520.GE6425@yoink.cs.uwaterloo.ca> Message-ID: <481C2440.2090403@gmx.de> This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA191F74F1EDD08809E688CC7 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable It's the jabber/xmpp network. Since I have no experience in packet=20 capturing, I googled a bit. Can I use "Wireshark" to capture the packets = in=20 the way you would like to see them? I hope so, it looks simple. When my=20 friend comes online, I will capture the packages. In which way should I provide the data in eMails to mailing lists? Are=20 normal attachments ok, or pasted as text into the eMail? Alexander Ian Goldberg wrote: > On Fri, May 02, 2008 at 02:42:44PM +0200, Alexander Buchner wrote: >> Hi, >> >> I'm new to the mailing list and I don't know if/how I can reply to an = >> existing thread. >> My problem looks like the same problem that was posted here=20 >> http://lists.cypherpunks.ca/pipermail/otr-users/2008-April/001273.html= =2E=20 >> Today I exchanged 20 or so messages with a friend before I noticed, th= at no=20 >> private conversation was initiated. By manually starting the OTR-sessi= on,=20 >> this works fine, but not automatically. >> In my global OTR Settings [X] Automatically initiate private messaging= is=20 >> activated and with this friend I use the standard options. >> I know that I can activate "Require private messaging" per buddy, but = this=20 >> is quite annoying if one has to do this for 15-20 people. I can't glob= ally=20 >> set this option, because there are people on my ContactList, who can't= =20 >> encrypt with OTR. >> Is this a known bug? What could go wrong? >> >> My system: >> Windows XP SP 3, Pidgin 2.4.1, OTR 3.1.0 >> >> My friend's system >> Windows XP SP 2, Pidgin 2.4.1, OTR 3.1.0 >=20 > Could you possibly capture the raw incoming and outgoing packets? What= > IM network are you using? >=20 > Thanks, >=20 > - Ian > _______________________________________________ > OTR-users mailing list > OTR-users@lists.cypherpunks.ca > http://lists.cypherpunks.ca/mailman/listinfo/otr-users --=20 Mein =F6ffentlicher PGP-Key: http://www.rzuser.uni-heidelberg.de/~abuchner/pgp.asc --------------enigA191F74F1EDD08809E688CC7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQIcBAEBAgAGBQJIHCRIAAoJEByY8i5PPbAiDzUQALL6A3gyk0T6L6iDZ0E6LgdA stMfduz8ssZEq0DHZ4TYF50uPzGUfNdL3JKc9XuaqtWAFvBX2DpkBoj5JjAOqP3B 2w9M2OHMl80TVnkm+Z47Kmfj+PF20qJraoxONwZfMEJmmwwDAizrKI3+UjV5F9F3 azvhKpkDwcCahGylGjgwSqwRfdzPnmV3QXGeLNLtQqfpR+Rut1Oryg61pjzFian3 zEo78Wm/619HCHVC0tvHSKAhyJI+PoH8ja9FBGTBPVzvLDH9z8OY/DkGm69b5/8z MtRzmllU6HTnemtJSe1kHAfq8Yuq1gE6C7n5+kcjcjhbSiNPT/pIlp+5YCa5t6Pu Jtk6PUrBEIfR4+ftusWPHAhkCvIa9YxO91GZTrgX6r2U4xUi3MRUrUTRP8YGnZ7c aYuCkIfdRyG00iHpAf4x5U2VJGXKKMfEB4UVjBif7E0ObVXvtLt+Xi06iL2fcgiC 8fzcDPEjOxoDDnuPkC4yxMn8jl463f3OTSI2XL37H6rlI648khQV8rYRNlRsm3h3 Gs7cj3jg6+EV4uKOTvAdq2smR2SsVyTqRgikeNUBdomOvlgre58TmWgbxKIJ51Tm 4kqTLUhOVEJDosfpaRD8yG6z85Rbi2Io0R72ZRbt2krFezoixdZxk+52wZvPDouG bIzdkWVq6r+tJCRwOeuD =n9EU -----END PGP SIGNATURE----- --------------enigA191F74F1EDD08809E688CC7-- From alexander.buchner@gmx.de Sat May 3 10:51:56 2008 From: alexander.buchner@gmx.de (Alexander Buchner) Date: Sat, 03 May 2008 11:51:56 +0200 Subject: [OTR-users] "Automatically initiate private messaging" doesn't work In-Reply-To: <481C2440.2090403@gmx.de> References: <481B0C44.7050804@gmx.de> <20080503013520.GE6425@yoink.cs.uwaterloo.ca> <481C2440.2090403@gmx.de> Message-ID: <481C35BC.1020404@gmx.de> This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig1B503525E993A955F4E1ADC3 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Now I captured the packages. The output is at=20 http://www.rzuser.uni-heidelberg.de/~abuchner/otr.txt I hope I did that right and you can help me better now. Alexander Alexander Buchner wrote: > It's the jabber/xmpp network. Since I have no experience in packet=20 > capturing, I googled a bit. Can I use "Wireshark" to capture the packet= s=20 > in the way you would like to see them? I hope so, it looks simple. When= =20 > my friend comes online, I will capture the packages. >=20 > In which way should I provide the data in eMails to mailing lists? Are = > normal attachments ok, or pasted as text into the eMail? >=20 > Alexander >=20 > Ian Goldberg wrote: >> On Fri, May 02, 2008 at 02:42:44PM +0200, Alexander Buchner wrote: >>> Hi, >>> >>> I'm new to the mailing list and I don't know if/how I can reply to an= =20 >>> existing thread. >>> My problem looks like the same problem that was posted here=20 >>> http://lists.cypherpunks.ca/pipermail/otr-users/2008-April/001273.htm= l.=20 >>> Today I exchanged 20 or so messages with a friend before I noticed,=20 >>> that no private conversation was initiated. By manually starting the = >>> OTR-session, this works fine, but not automatically. >>> In my global OTR Settings [X] Automatically initiate private=20 >>> messaging is activated and with this friend I use the standard option= s. >>> I know that I can activate "Require private messaging" per buddy, but= =20 >>> this is quite annoying if one has to do this for 15-20 people. I=20 >>> can't globally set this option, because there are people on my=20 >>> ContactList, who can't encrypt with OTR. >>> Is this a known bug? What could go wrong? >>> >>> My system: >>> Windows XP SP 3, Pidgin 2.4.1, OTR 3.1.0 >>> >>> My friend's system >>> Windows XP SP 2, Pidgin 2.4.1, OTR 3.1.0 >> >> Could you possibly capture the raw incoming and outgoing packets? Wha= t >> IM network are you using? >> >> Thanks, >> >> - Ian >> _______________________________________________ >> OTR-users mailing list >> OTR-users@lists.cypherpunks.ca >> http://lists.cypherpunks.ca/mailman/listinfo/otr-users >=20 --=20 Mein =F6ffentlicher PGP-Key: http://www.rzuser.uni-heidelberg.de/~abuchner/pgp.asc --------------enig1B503525E993A955F4E1ADC3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQIcBAEBAgAGBQJIHDW8AAoJEByY8i5PPbAi1UQQAK02INTL/0mf3RlZzzEpZyVP /7CgjzGQgfkUeqvmixFp9tFA6ZLz748BQZPuwCyQEDusiV0y9LeZhY6QIa5XDjUE fylrZoGqVcQm0zIDMTGkCE2+Ij8FdZ877rCVY7ShR1D9AeDzcL23BcuN0/E7rHKz /rCsMX6YdFYDssWr6YKXv+hHggQuFd4Mi4IHZf9SASIBmBD4OhuK5Q0ZcBIwKWT+ 8zLSn9L0VAXlI1bV1JmxSIOp4AkPzmD+WC22OZw3j8Tk0THU4th0LH30ZgBKl3lQ nsyeykopcbe1cIdVOc9U7ZnYmQ1ZaEtcjeoKB7Xqh5qKdo5tiK94eIB42SSJZO8M 0iSt+PlSNNjT4jI1B0ZV0znRiESJbjO6GKdFmBZ7Su9BKHaysohx1vv77y3lcKXy AotjXyo3Ua22Jb0tFBqtYiD/XsBp33lDUliYZE5d4ULXdo7gVQPtKCygrj+XySGB VIOwpsBK2BWLeyPFlk9QZHkJtFcsMqamELAZpUkNvusMZ/3Ppm87XYePsDBZjMuf Y3iy3pdj+pkLBWhSlgll3abcGvHQe2JSnE6HQTtA9KflG4nir3gmlKL4ChTHPLbr 6TLW3cAgbmjtdyy9KZYolaAGxU5W0Qamp0FKTZE1+QSUWo/EoP2+2yk95WdfUP2L AZElVZ/zWLdzBPSXTUvq =WhWD -----END PGP SIGNATURE----- --------------enig1B503525E993A955F4E1ADC3-- From ian@cypherpunks.ca Sat May 3 22:45:30 2008 From: ian@cypherpunks.ca (Ian Goldberg) Date: Sat, 3 May 2008 17:45:30 -0400 Subject: [OTR-users] "Automatically initiate private messaging" doesn't work In-Reply-To: <481C35BC.1020404@gmx.de> References: <481B0C44.7050804@gmx.de> <20080503013520.GE6425@yoink.cs.uwaterloo.ca> <481C2440.2090403@gmx.de> <481C35BC.1020404@gmx.de> Message-ID: <20080503214530.GG6425@yoink.cs.uwaterloo.ca> On Sat, May 03, 2008 at 11:51:56AM +0200, Alexander Buchner wrote: > Now I captured the packages. The output is at > http://www.rzuser.uni-heidelberg.de/~abuchner/otr.txt > > I hope I did that right and you can help me better now. Unfortuantely, Jabber connections are TLS-encrypted by default, so I can't see what's going on. :-( Try running "pidgin -d"; I believe that will output a lot of useful information, Jabber-wise. - Ian From esurnir@gmail.com Sat May 3 22:51:30 2008 From: esurnir@gmail.com (Jean-Baptiste Zeller) Date: Sat, 03 May 2008 17:51:30 -0400 Subject: [OTR-users] "Automatically initiate private messaging" doesn't work In-Reply-To: <20080503214530.GG6425@yoink.cs.uwaterloo.ca> References: <481B0C44.7050804@gmx.de> <20080503013520.GE6425@yoink.cs.uwaterloo.ca> <481C2440.2090403@gmx.de> <481C35BC.1020404@gmx.de> <20080503214530.GG6425@yoink.cs.uwaterloo.ca> Message-ID: <481CDE62.6010500@gmail.com> This is a cryptographically signed message in MIME format. --------------ms040909040409070302070803 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Ian Goldberg wrote: > On Sat, May 03, 2008 at 11:51:56AM +0200, Alexander Buchner wrote: >> Now I captured the packages. The output is at >> http://www.rzuser.uni-heidelberg.de/~abuchner/otr.txt >> >> I hope I did that right and you can help me better now. > > Unfortuantely, Jabber connections are TLS-encrypted by default, so I > can't see what's going on. :-( > > Try running "pidgin -d"; I believe that will output a lot of useful > information, Jabber-wise. > > - Ian > _______________________________________________ > OTR-users mailing list > OTR-users@lists.cypherpunks.ca > http://lists.cypherpunks.ca/mailman/listinfo/otr-users Even simpler, Run Pidgin with the debug window open and save the debug log. Pidgin DO make every message it send and receive appear (save password information). - Jean-Baptiste Zeller --------------ms040909040409070302070803 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJSTCC Av8wggJooAMCAQICEEiMH5xSXNHW0I/oJcVZzEYwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDQyMTIzNDIzN1oX DTA5MDQyMTIzNDIzN1owQzEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEgMB4G CSqGSIb3DQEJARYRZXN1cm5pckBnbWFpbC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQCoVf0wm7v9SCmAeICUXVfr5bUX9fgvfxUzsWvu7JXw2nAjbhNpSAOlM55hwsYX eetnLLTbtkxz2/fM/Bx21yW/7K1F2gvaT7WV1VhpdZMNgdvRwST7uSTRT4ZZV+yray1ou2BJ SN5TdaHC+wxViXLQ5Di4vLfr62tYT5/PQtoC3s6F36AEzqbONM8/K3lWl9z1XvsSZIxeiLV2 nkkWR3/ax3fGSn0zy2Vdsb88Y9H1FN/s/+u8SaIRr5ogj7IM3fCWsx6MMMN8pNJeobER3/zH J/lc2mvNaIDanMhFb5DXoMSRlWTueseXAoTl2kJgyuH21hLUijkf88grQE8S/4Y3AgMBAAGj UTBPMA4GA1UdDwEB/wQEAwID+DARBglghkgBhvhCAQEEBAMCBaAwHAYDVR0RBBUwE4ERZXN1 cm5pckBnbWFpbC5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQCgan9WRY98 sy9y6Eat2HjayMJVdOGV6Gb5RfEd4sT4peHwAddiXaxtt66U6lBcejAC8sNiR3tVUZzIDELn nK31kleh2cLOsPGgALt5mF0Mr2lhrrk9Ipzrm9WsK9Gbg5c5KIKxKTi58b3va2PTGMNaEepQ sk1zrJkOTgH2L7jFGDCCAv8wggJooAMCAQICEEiMH5xSXNHW0I/oJcVZzEYwDQYJKoZIhvcN AQEFBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkp IEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4X DTA4MDQyMTIzNDIzN1oXDTA5MDQyMTIzNDIzN1owQzEfMB0GA1UEAxMWVGhhd3RlIEZyZWVt YWlsIE1lbWJlcjEgMB4GCSqGSIb3DQEJARYRZXN1cm5pckBnbWFpbC5jb20wggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQCoVf0wm7v9SCmAeICUXVfr5bUX9fgvfxUzsWvu7JXw 2nAjbhNpSAOlM55hwsYXeetnLLTbtkxz2/fM/Bx21yW/7K1F2gvaT7WV1VhpdZMNgdvRwST7 uSTRT4ZZV+yray1ou2BJSN5TdaHC+wxViXLQ5Di4vLfr62tYT5/PQtoC3s6F36AEzqbONM8/ K3lWl9z1XvsSZIxeiLV2nkkWR3/ax3fGSn0zy2Vdsb88Y9H1FN/s/+u8SaIRr5ogj7IM3fCW sx6MMMN8pNJeobER3/zHJ/lc2mvNaIDanMhFb5DXoMSRlWTueseXAoTl2kJgyuH21hLUijkf 88grQE8S/4Y3AgMBAAGjUTBPMA4GA1UdDwEB/wQEAwID+DARBglghkgBhvhCAQEEBAMCBaAw HAYDVR0RBBUwE4ERZXN1cm5pckBnbWFpbC5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0B AQUFAAOBgQCgan9WRY98sy9y6Eat2HjayMJVdOGV6Gb5RfEd4sT4peHwAddiXaxtt66U6lBc ejAC8sNiR3tVUZzIDELnnK31kleh2cLOsPGgALt5mF0Mr2lhrrk9Ipzrm9WsK9Gbg5c5KIKx KTi58b3va2PTGMNaEepQsk1zrJkOTgH2L7jFGDCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcN AQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcT CUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRp ZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNv bTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYD VQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA xKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkV cI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUq VIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMG A1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZy ZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJp dmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIX oUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydx VyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggNkMIIDYAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWlu ZyBDQQIQSIwfnFJc0dbQj+glxVnMRjAJBgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wODA1MDMyMTUxMzBaMCMGCSqGSIb3DQEJBDEW BBQjKigY0SjjVqNAMk2wAm+8NwRS7zBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4G CCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB hQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElz c3VpbmcgQ0ECEEiMH5xSXNHW0I/oJcVZzEYwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYD VQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEEiMH5xSXNHW0I/oJcVZ zEYwDQYJKoZIhvcNAQEBBQAEggEAOCm/+mkh+Adt+7T/fxRIz/Os4uFYoxaLlk5GfGeuvAmg EIusThcY3x+ITktAET5v4A5bTbr37kKiqwe1xLZEeuhO5SAx+dxLOHMgiZ0HatJjzxkEGB+b FCN9GVrfQoMQ1/zWFuNsEsmNKjpIannF1lvjnKnOWL1WFqUpy+aO+e/dwNSLGsLrccR2s9qi S/WjNDOEZ5rSv7lYpT43h2sFdaBGjYm/IKaM4SniXUnTPtx3WnekaTXeu75ybSu0Nx06Gpnk zZ7ebVHuJef/cp8DLHRYRh+RDwekGlJoShwVQhb80wBk0FZEIOgtzaVWAJsN51368eW1AIBE FpGi2iZZ+AAAAAAAAA== --------------ms040909040409070302070803-- From alexander.buchner@gmx.de Sun May 4 10:30:09 2008 From: alexander.buchner@gmx.de (Alexander Buchner) Date: Sun, 04 May 2008 11:30:09 +0200 Subject: [OTR-users] "Automatically initiate private messaging" doesn't work In-Reply-To: <481CDE62.6010500@gmail.com> References: <481B0C44.7050804@gmx.de> <20080503013520.GE6425@yoink.cs.uwaterloo.ca> <481C2440.2090403@gmx.de> <481C35BC.1020404@gmx.de> <20080503214530.GG6425@yoink.cs.uwaterloo.ca> <481CDE62.6010500@gmail.com> Message-ID: <481D8221.6060702@gmx.de> This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD9FD46400609B28DA7CFA32E Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi again, here is the output of Pidgin's debug window while sending some messages t= o=20 my friend: http://www.rzuser.uni-heidelberg.de/~abuchner/purple-debug.log= =2E=20 This time one can see the messages as plain text. Do these logs help you? Alexander Jean-Baptiste Zeller wrote: > Ian Goldberg wrote: >> On Sat, May 03, 2008 at 11:51:56AM +0200, Alexander Buchner wrote: >>> Now I captured the packages. The output is at=20 >>> http://www.rzuser.uni-heidelberg.de/~abuchner/otr.txt >>> >>> I hope I did that right and you can help me better now. >> >> Unfortuantely, Jabber connections are TLS-encrypted by default, so I >> can't see what's going on. :-( >> >> Try running "pidgin -d"; I believe that will output a lot of useful >> information, Jabber-wise. >> >> - Ian >> _______________________________________________ >> OTR-users mailing list >> OTR-users@lists.cypherpunks.ca >> http://lists.cypherpunks.ca/mailman/listinfo/otr-users > Even simpler, >=20 > Run Pidgin with the debug window open and save the debug log. Pidgin DO= =20 > make every message it send and receive appear (save password informatio= n). >=20 > - Jean-Baptiste Zeller --=20 Mein =F6ffentlicher PGP-Key: http://www.rzuser.uni-heidelberg.de/~abuchner/pgp.asc --------------enigD9FD46400609B28DA7CFA32E Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQIcBAEBAgAGBQJIHYIiAAoJEByY8i5PPbAiZ54QAMBRODMlWcpMmiEvJGjax5h+ uIwKtPV2Drxt7ySviyZl8lpm6Vf5rkXrHYai6PvFn+bLwhtQ/68UU5FX6RMlOcdK vTkeT2NUoItvXUvsIgU4pUfn9dF+k4ebsT1kLSMOJ4EfuZc8DWYyYoJat020f+rJ AZb9Obv+SsaGF2sEId+jcmvrZfEsB4rORuXmm02USe8iPWDYeqP93BKWj5ZEdwvH ncACX66rHaNPjBswH/UkkgAvthh+SJEPdg1oAp6X5J/iIpaXCQteP7jDr0IKtwpm WSFuGV5yrI2F6OEwC1EYjm4dx2nMbJA2b4DPmvSwFSr7r3+9PtCfe/hP44sTKqUa EBOmWy4hRum1I2T1CGYlPrHaRueTEnJi/PqU18ffCQ+lcMgW6b2USQVpVIWmkkLR rVhp2jxIikKfU+v2JZt2RAoAxXkxmx/N4d2z0l/IgWG/sFMsOV8KKagbR0iNr5Zh c4krtNFW2yOeIGnINa3yn0mZKO243jq/umTxTqKcuUCgyYH+m/nZQcrHXCMHVtDz 6GcDn9eo98meWyStvcup84fj8pxXhDW3t24RUS0MA+zO2bhMNw62lqDgtQXcXcTN oBt3nxgQnDWBQKN12V7nBIQzi2v3f/2oK0XaLtRiERSJk0P8QZP4kRGefFDammaa O42WFrLOyY/y8qLofaJB =u0VV -----END PGP SIGNATURE----- --------------enigD9FD46400609B28DA7CFA32E-- From ian@cypherpunks.ca Sun May 4 17:22:02 2008 From: ian@cypherpunks.ca (Ian Goldberg) Date: Sun, 4 May 2008 12:22:02 -0400 Subject: [OTR-users] "Automatically initiate private messaging" doesn't work In-Reply-To: <481D8221.6060702@gmx.de> References: <481B0C44.7050804@gmx.de> <20080503013520.GE6425@yoink.cs.uwaterloo.ca> <481C2440.2090403@gmx.de> <481C35BC.1020404@gmx.de> <20080503214530.GG6425@yoink.cs.uwaterloo.ca> <481CDE62.6010500@gmail.com> <481D8221.6060702@gmx.de> Message-ID: <20080504162202.GL6425@yoink.cs.uwaterloo.ca> On Sun, May 04, 2008 at 11:30:09AM +0200, Alexander Buchner wrote: > Hi again, > > here is the output of Pidgin's debug window while sending some messages to > my friend: http://www.rzuser.uni-heidelberg.de/~abuchner/purple-debug.log. > This time one can see the messages as plain text. > Do these logs help you? Perfect. It shows that your end is properly sending the whitespace tag that should trigger the other end into starting OTR. (See the "Test" message.) Can you do the same thing again, but capture both sides at once? Your buddy checked the per-buddy configuration on his/her side as well? Thanks, - Ian From esurnir@gmail.com Sun May 4 17:35:16 2008 From: esurnir@gmail.com (Jean-Baptiste Zeller) Date: Sun, 04 May 2008 12:35:16 -0400 Subject: [OTR-users] "Automatically initiate private messaging" doesn't work In-Reply-To: <20080504162202.GL6425@yoink.cs.uwaterloo.ca> References: <481B0C44.7050804@gmx.de> <20080503013520.GE6425@yoink.cs.uwaterloo.ca> <481C2440.2090403@gmx.de> <481C35BC.1020404@gmx.de> <20080503214530.GG6425@yoink.cs.uwaterloo.ca> <481CDE62.6010500@gmail.com> <481D8221.6060702@gmx.de> <20080504162202.GL6425@yoink.cs.uwaterloo.ca> Message-ID: <481DE5C4.4060302@gmail.com> Ian Goldberg wrote: > On Sun, May 04, 2008 at 11:30:09AM +0200, Alexander Buchner wrote: >> Hi again, >> >> here is the output of Pidgin's debug window while sending some messages to >> my friend: http://www.rzuser.uni-heidelberg.de/~abuchner/purple-debug.log. >> This time one can see the messages as plain text. >> Do these logs help you? > > Perfect. It shows that your end is properly sending the whitespace tag > that should trigger the other end into starting OTR. (See the "Test" > message.) > > Can you do the same thing again, but capture both sides at once? Your > buddy checked the per-buddy configuration on his/her side as well? > > Thanks, > > - Ian > _______________________________________________ > OTR-users mailing list > OTR-users@lists.cypherpunks.ca > http://lists.cypherpunks.ca/mailman/listinfo/otr-users Perhaps it would be good in the future to have off the record be a bit more talkative in terms of the pidgin debug log in the future. Like showing when does it initialise, because sometime, it seems to take a bit of time before the plugin finaly catch up that it must start working. From alexander.buchner@gmx.de Sun May 4 23:13:54 2008 From: alexander.buchner@gmx.de (Alexander Buchner) Date: Mon, 05 May 2008 00:13:54 +0200 Subject: [OTR-users] "Automatically initiate private messaging" doesn't work In-Reply-To: <20080504162202.GL6425@yoink.cs.uwaterloo.ca> References: <481B0C44.7050804@gmx.de> <20080503013520.GE6425@yoink.cs.uwaterloo.ca> <481C2440.2090403@gmx.de> <481C35BC.1020404@gmx.de> <20080503214530.GG6425@yoink.cs.uwaterloo.ca> <481CDE62.6010500@gmail.com> <481D8221.6060702@gmx.de> <20080504162202.GL6425@yoink.cs.uwaterloo.ca> Message-ID: <481E3522.90506@gmx.de> This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig4ED70DE61DA43ECD372684D8 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Sorry, it's kind of weird. The situation is like this: I know my friend's ICQ and Jabber Account. Bo= th=20 are in my contact list and I "melted" them per "Expand"-Command. He did t= he=20 same with my two Accounts, but we both had a different order. For me his = "main account" (the upper one) was his Jabber, and vice versa. And here is the problem. When you rightclick on a "bundled" Contact, I=20 think you know what I mean, and select "OTR-Settings" only the main accou= nt=20 will be affected. So he didn't look up his OTR-settings for my jabber but= =20 for my ICQ account. Can you follow me? In our last test he noticed, that my Jabber account had different=20 OTR-Settings, "Automatically initiate..." was deactivated. After he=20 activated this option, everything worked fine. So we went back and put the options as they were to produce the log for y= ou=20 but we couldn't reproduce the scenario. The OTR encryption always kicked = in=20 immediately. Actually I think his client should have responded to my OTR-Request,=20 independently from his option "Automatically initiate...". It didn't but = we=20 can't reproduce for now. I'm sorry. But you should think about the rightclick->OTR-Settings problem. The=20 settings one edits should be applied for ALL Accounts under this=20 "meta-account", not only the most upper one. Am I right? Alexander Ian Goldberg wrote: > On Sun, May 04, 2008 at 11:30:09AM +0200, Alexander Buchner wrote: >> Hi again, >> >> here is the output of Pidgin's debug window while sending some message= s to=20 >> my friend: http://www.rzuser.uni-heidelberg.de/~abuchner/purple-debug.= log.=20 >> This time one can see the messages as plain text. >> Do these logs help you? >=20 > Perfect. It shows that your end is properly sending the whitespace tag= > that should trigger the other end into starting OTR. (See the "Test" > message.) >=20 > Can you do the same thing again, but capture both sides at once? Your > buddy checked the per-buddy configuration on his/her side as well? >=20 > Thanks, >=20 > - Ian > _______________________________________________ > OTR-users mailing list > OTR-users@lists.cypherpunks.ca > http://lists.cypherpunks.ca/mailman/listinfo/otr-users --=20 Mein =F6ffentlicher PGP-Key: http://www.rzuser.uni-heidelberg.de/~abuchner/pgp.asc --------------enig4ED70DE61DA43ECD372684D8 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQIcBAEBAgAGBQJIHjUiAAoJEByY8i5PPbAijf0P/1S45fVzihKpvkXOesF9uM/Y X0V6/ByH5v9e9sVzynfud/CCAgzs6gXCxT5MDS6GbdFNrnKqnMuHZ4NU6fM6WnP5 PhgPKFvRrhR3Rk/1xu9SKlOEbb/8UarJpr0mIcbFL80UWXuPUf7tvOTxmCLnmv7h 7mhuv9bPx9QOJ7G5w/tuzBw2Mz6Cv5cSFPB1NDnTWt6+KaQ3Pp97nql5h09z+KDF ARhjnOseC5oaoCkUppCDuOba55sJySHG2alYHj221j5r4viQDPy4UYkBNOsEcRTt QfNksXLj7i48gjLTBXCN0hHHh8lv+b38WTQRBZkJQh3DFDZmO8ilqNx0Dgr82hZn fxR2SV0KtJYlkZetDnJIGAlUtd+baq/XFuQu0K0jGXAFF3pi5kZHH+4yOzd/TypV Eflv7uIjAi+G4joUoQH1q0Ysgp1rH2ZhCEOmULB5IpIcawZAmLYz8ayffnDDFyIC hd6xSfxXmfIDnmp1iaoIzXPzHzRNyjLdAiyAC3AOTjWchiX9i0ve2AA2BmYXHazk CoFRzoFUj5gAHgEhKd10VPUqa5AEIf/RqQ0ADxydiWwdYV/csluBzkgWFN0vb97Z 6S4xPaswV/h+NayDop3RNauB1SK2mK7RQa9LWZuU6zOPpzp01eSby7EfouIG+cgV 2znH21hlvWniP3XXN18h =fx1E -----END PGP SIGNATURE----- --------------enig4ED70DE61DA43ECD372684D8-- From js-otrim@webkeks.org Sat May 10 12:59:49 2008 From: js-otrim@webkeks.org (Jonathan Schleifer) Date: Sat, 10 May 2008 13:59:49 +0200 Subject: [OTR-users] Stronger crypto? Message-ID: <20080510135949.67ab1f75@webkeks.org> --Sig_/PV.x_baNaSxr_OzWSv2xg3I Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi! I looked at the specification of the OTR protocol and have a few suggestions. First: Why not move from AES128-CTR to AES256-CBC? It only needs a few cycles more, but provides stronger crypto. Shouldn't be a problem, even on slower machines. Second: Why not increase the public/private key to 4096 bit? DSA2 can handle that. And since that key isn't generated every 5 minutes, performance on slow machines shouldn't be an issue here either. I haven't read the whole specification, only had a quick look at it, so feel free to correct me if I've missed something. I'd welcome it if there'd be a new OTR version providing stronger cryto. --=20 Jonathan --Sig_/PV.x_baNaSxr_OzWSv2xg3I Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- iQIcBAEBAwAGBQJIJY44AAoJEMtRg9d5cXHk3wYP/3ngSdPdvnfdGGm88ynZR7Wg PLqYnZ9+K9JwocB5HBYRAWYQYq1tTUON9q36cyhqzSmS+d/l8e30AB6Z1xRQhjMH g378ncdRLpnVgiQkDoCrEa9VthL1RALjeE1qoXantRIyY8jHVOADDScllSm4S8XG MD6yLBW01+A8tDh+yw+eSSGwJoTcoZAyswEVM4sx1MwVpdqhBU5+cRoUm1IqU6lZ LEHDkyoCTRlkdZfKcSyuFCrLcSX9Wn70zxc70GAIajI7pRGXPFFqJHTygC6WpKmq 596GD5c51hibibwoFcuTY6HpIOGmIGWk3vip29y67J35y7n5rVZDAuTIJT9WRZxY dCZ9Qb5F1RGh91nmoD4tp1urrhNGWVFjpTYEz+bx1QvyGx3g3vopV5x5Z81RijQa 2KgFj5RixUAfPBE5NzwzXoTVEy1D5hMewSGjQhWE0A2ptwkHwJzJneDRsLtoPhwo uveBve4oy7+ur6DFawDlsvxXVy8ihrFa/UiydNGDl1s3MTvWJMTyZys0k2Dx1VUr oyj/+v07A0XDaOp4EijpB88xOfICr+KwyNXAPIQzwDiP4rLksOq7aJgtvvzitrKL iu3cdMd450igxbAFLunq1x/ziP9g63sOKhqZey1uCgnOQHIIE48Avxk7tiClf61/ h8Bg4oJd9HCQ6TK3K9Ne =v5wa -----END PGP SIGNATURE----- --Sig_/PV.x_baNaSxr_OzWSv2xg3I-- From michael_reichenbach@freenet.de Sat May 10 14:27:45 2008 From: michael_reichenbach@freenet.de (Michael Reichenbach) Date: Sat, 10 May 2008 15:27:45 +0200 Subject: [OTR-users] Stronger crypto? In-Reply-To: <20080510135949.67ab1f75@webkeks.org> References: <20080510135949.67ab1f75@webkeks.org> Message-ID: <4825A2D1.7060106@freenet.de> Jonathan Schleifer wrote: > Hi! > > I looked at the specification of the OTR protocol and have a few > suggestions. > > First: Why not move from AES128-CTR to AES256-CBC? It only needs a few > cycles more, but provides stronger crypto. Shouldn't be a problem, even > on slower machines. > > Second: Why not increase the public/private key to 4096 bit? DSA2 can > handle that. And since that key isn't generated every 5 minutes, > performance on slow machines shouldn't be an issue here either. > > I haven't read the whole specification, only had a quick look at it, so > feel free to correct me if I've missed something. > > I'd welcome it if there'd be a new OTR version providing stronger cryto. > I can second this and would like to see strongest cryptography. Instant of AES128 or AES256 a cascade with AES256-Twofish-Serpent could be used. From gmaxwell@gmail.com Sat May 10 17:38:30 2008 From: gmaxwell@gmail.com (Gregory Maxwell) Date: Sat, 10 May 2008 12:38:30 -0400 Subject: [OTR-users] Stronger crypto? In-Reply-To: <4825A2D1.7060106@freenet.de> References: <20080510135949.67ab1f75@webkeks.org> <4825A2D1.7060106@freenet.de> Message-ID: On Sat, May 10, 2008 at 9:27 AM, Michael Reichenbach wrote: >> First: Why not move from AES128-CTR to AES256-CBC? It only needs a few >> cycles more, but provides stronger crypto. Shouldn't be a problem, even >> on slower machines. [snip] > I can second this and would like to see strongest cryptography. Instant of > AES128 or AES256 a cascade with AES256-Twofish-Serpent could be used. The need to have a counter-mode cypher stems from the desire to preserve blind modification, one of OTR's features. OTR intentionally releases the authentication keys after a message is received, with these keys in hand you can blindly modify message ... For example if you think it's very likely that someone wrote "I'd like to meet John" you can flip the bits to make it say "I'd like to kill John", even without the encryption keys. This property requires a counter mode cipher. Because the system, properly, has an IV which is unique per key a counter mode cipher should be equally secure unless AES is broken. ... but if AES is broken we have bigger problems than the difference between CTR and CBC mode. > Second: Why not increase the public/private key to 4096 bit? DSA2 can > handle that. And since that key isn't generated every 5 minutes, > performance on slow machines shouldn't be an issue here either. First off... as seem to be aware, It's only used for initial authentication. ... cracking your private key would only allow someone to impersonate you in the future, and not read your past messages. It's not a very interesting attack for an attacker and if it were the attacker would probably be better of breaking into your home or office for this one. Secondly, longer RSA keys *are* slower and more memory hungry. Not every device someone would want to run OTR on is a PC... think PDAs and other wireless devices. There are probably better ways to to use CPU to improve security. I could propose some things which would increase security ... but the biggest improvements for security will come from increasing the number of people that use OTR and number of ways they can use OTR... Supporting more platforms, supporting multi-user chat. Getting rid of the AIM multiple computers signed on at once OTR-fights.. etc.. From ian@cypherpunks.ca Sat May 10 17:51:13 2008 From: ian@cypherpunks.ca (Ian Goldberg) Date: Sat, 10 May 2008 12:51:13 -0400 Subject: [OTR-users] Stronger crypto? In-Reply-To: <20080510135949.67ab1f75@webkeks.org> References: <20080510135949.67ab1f75@webkeks.org> Message-ID: <20080510165113.GT30190@yoink.cs.uwaterloo.ca> On Sat, May 10, 2008 at 01:59:49PM +0200, Jonathan Schleifer wrote: > Hi! > > I looked at the specification of the OTR protocol and have a few > suggestions. > > First: Why not move from AES128-CTR to AES256-CBC? It only needs a few > cycles more, but provides stronger crypto. Shouldn't be a problem, even > on slower machines. > > Second: Why not increase the public/private key to 4096 bit? DSA2 can > handle that. And since that key isn't generated every 5 minutes, > performance on slow machines shouldn't be an issue here either. > > I haven't read the whole specification, only had a quick look at it, so > feel free to correct me if I've missed something. > > I'd welcome it if there'd be a new OTR version providing stronger cryto. Can you elucidate what your threat model is that you think 128-bit AES isn't enough? The existence of AES-256 is largely to hedge against a future advent of a working quantum computer (which could break AES-128 in 2^64 work, but need 2^128 work to break AES-256). But a quantum computer would plow right through the DH key exchange used to generate the 256-bit key, and you'd be sunk anyway. Speaking of the DH, if we were to switch to 256-bit symmetric keys, we'd have to switch the DH to something in the 10,000-bit range for equivalent security. (Otherwise, it would be way easier to break the DH to determine the symmetric key than it would be to break the AES directly, and you gain nothing.) This would be way too slow, since it's performed almost every time a message is sent. We'd probably need something elliptic-curve based, which opens up other cans of worms. There's a similar issue with the authentication keys: it doesn't help to greatly raise the security level of the signature scheme, if the thing you're signing (a MAC in this case) is of weaker security. All parts of the system need to fit together. In addition, authentication keys can be changed easily, and with no loss of past message secrecy, if it does turn out for some reason that people begin to be able to forge signatures with existing DSA keys. The OTR protocol already includes a key type feature, anticipating this possible future need. But in my opinion, the need isn't there at this time. Thanks, - Ian From gmaxwell@gmail.com Sat May 10 18:09:17 2008 From: gmaxwell@gmail.com (Gregory Maxwell) Date: Sat, 10 May 2008 13:09:17 -0400 Subject: [OTR-users] Stronger crypto? In-Reply-To: <20080510165113.GT30190@yoink.cs.uwaterloo.ca> References: <20080510135949.67ab1f75@webkeks.org> <20080510165113.GT30190@yoink.cs.uwaterloo.ca> Message-ID: On Sat, May 10, 2008 at 12:51 PM, Ian Goldberg wrote: [snip] > Speaking of the DH, if we were to switch to 256-bit symmetric keys, we'd > have to switch the DH to something in the 10,000-bit range for > equivalent security. (Otherwise, it would be way easier to break the DH > to determine the symmetric key than it would be to break the AES > directly, and you gain nothing.) This would be way too slow, since it's > performed almost every time a message is sent. We'd probably need > something elliptic-curve based, which opens up other cans of worms. [snip] Hey, I did propose something OTR could do to improve key establishment security without expanding the DH size: Cache an established shared secret and mix it with the DH negoitated key. I.e. take the password provided on each side for authentication, strengthen it with a zillion rounds of a hash, store it, then use it to encrypt the DH provided keys. This means that if DH is found to be weaker than expected OTR between authenticated users reduces to symmetric crypto without PFS rather than being totally broken. In any case... it still would be an insignificant improvement in security compared to what would be provided just about any usability improvement. From js-otrim@webkeks.org Sun May 11 16:25:42 2008 From: js-otrim@webkeks.org (Jonathan Schleifer) Date: Sun, 11 May 2008 17:25:42 +0200 Subject: [OTR-users] Pidgin plugin sends and parses HTML Message-ID: <20080511172542.181da3f6@webkeks.org> --Sig_/WNQx5uz6t_5+5=8S.K_C4tt Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable I just talked for the first time with a pidgin user using Gajim's new OTR implementation and I noticed that it seems that Pidgin encrypts the HTML, not the Text. Is this intended? Miranda seems to does it like Gajim, while Trillian also sends HTML. So it's 2 vs. 2. What would be the correct approach? Should I change it in Gajim so it tries to strip all HTML tags and decode the entities + encode outgoing messages? I also noticed that libotr returns HTML error messages, which we think is bad, they are not translatable and we have to strip HTML from them. --=20 Jonathan --Sig_/WNQx5uz6t_5+5=8S.K_C4tt Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- iQIcBAEBAwAGBQJIJw/6AAoJEMtRg9d5cXHkLHUQALwsrAk7zqzU411eVCcfU6Qs 1vEMZfjEwx3s2nXA6IPyYKHql+AkbjR6OTrdpB2DNYrUm4JGlq1x0fQTMa1hu+uk A/f17oN21LAwLxSttVH6E+2lZpsMMdrOR8V6JHgLWfKT9DAzhSahmPihc/xwEVXF VEzwu0aC/92hUaukq3KITGM7Iy93kyzZk/eXGXpSzdqRRJDy0q3SpmVoA3We/e+L +gi5qiaoJO7PHt8qMOf5G8kc3whAMJ/3ayL3Q2tn1lp2ls2f+e+BH5yzOPmdyzrA rinpLB+4XZiDWP8VFHFjsJcU6R06HK2sv8A/MmMhnLJNXSuZcVwaAW9C8/GnXpR8 5NaGiSErpufdd6nBEj29QUYsL3ybNnvVuKnbeT+r4ya+hDyQo0jhsvUaR8vXcNvn MhFKN0FSiy5hOu93fbowwIQR4080YiHbW88/4LmSjpdv704aWoi82lNzMg/tsgv0 r+ChpWa81f8EOsEW+33t/noDrCR1yMzui2fgt4lB3mesIiPI1tYo2lIlvIHUt1lh dyRz9RMFdetCq3RTlTx9Yl/7VR3qtj3gfZNIzb/jcubqE0tvo8UWQtPzMmebLszy EOEXCw1iRjIcvmLZTwulOHyezw7U1OSmaEo86u/zfYs/j+5ribzUKSdYcJzV0INB lFa0sXdGxLoP2EIW3ded =TzgU -----END PGP SIGNATURE----- --Sig_/WNQx5uz6t_5+5=8S.K_C4tt-- From =?iso-8859-1?Q?R=FCdiger?= Kuhlmann Sun May 11 16:48:15 2008 From: =?iso-8859-1?Q?R=FCdiger?= Kuhlmann (=?iso-8859-1?Q?R=FCdiger?= Kuhlmann) Date: Sun, 11 May 2008 17:48:15 +0200 Subject: [otr-users] Pidgin plugin sends and parses HTML In-Reply-To: <20080511172542.181da3f6@webkeks.org> References: <20080511172542.181da3f6@webkeks.org> Message-ID: <20080511154815.GA5693@msgids.ruediger-kuhlmann.de> --1yeeQ81UyVL57Vl7 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Jonathan! >--[Jonathan Schleifer]-- > I just talked for the first time with a pidgin user using Gajim's new > OTR implementation and I noticed that it seems that Pidgin encrypts the > HTML, not the Text. Is this intended? Miranda seems to does it like > Gajim, while Trillian also sends HTML. So it's 2 vs. 2. Add "climm" to the list of clients who do _NOT_ send HTML. According to the OTR spec, the library is supposed to do nothing more than replace the plain text with the encrypted text. As such, the place for text/plain is supposed to contain encryped text/plain, while the place for text/html is supposed to contain encrypted text/html. So much, so obvious, unfortunately the OTR authors are quite resistant to reality and are not reachable by any kind of logic. Any time this comes up on this list, the poster is pointed to the list archive (where nobody can find any argument supporting the OTR author's position). So the situation quite similar to the mplayer guys and their home-grown autoconf look-alike. Well, I'm interested how to explain away the stupidity of Trillian to interpret text as HTML (and thus discard newlines) when climm doesn't even send HTML at all... > Should I change it in Gajim so it > tries to strip all HTML tags and decode the entities + encode outgoing > messages? Please don't. Btw, climm will simply reject messages where the encrypted text/plain and text/html part agree, but < are somewhere in the decrypted text. > I also noticed that libotr returns HTML error messages, which > we think is bad, they are not translatable and we have to strip HTML > from them. Well, I'd say "bad" is a nice euphemism for "very poor interface design". libOTR was split from GAIM, pardon, Pitch-in code, and it shows. It isn't usable in any other environment without problems. If any usage of this library isn't as it is used by Pitch-in, then it will require stupid work-arounds and additional coding. Another example would, by the way, be the outgoing fragmentation "support". Sorry for the not-quite so friendly email, but the situation just doesn't seem to improve. Yours, R=FCdiger. --=20 "See, free nations are peaceful nations. Free nations don't attack each other. Free nations don't develop weapons of mass destruction." - George W. Bush, Milwaukee, Wis., Oct. 3, 2003 --1yeeQ81UyVL57Vl7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIJxU/HFs/RFyJr1ERApSqAJ9M+azUVUtpWG5MXJGqOFwJ/IsgvwCdGbgC a/QtxTkPuZRhIT6gzwHptJc= =uXXG -----END PGP SIGNATURE----- --1yeeQ81UyVL57Vl7-- From js-otrim@webkeks.org Sun May 11 17:04:06 2008 From: js-otrim@webkeks.org (Jonathan Schleifer) Date: Sun, 11 May 2008 18:04:06 +0200 Subject: [otr-users] Pidgin plugin sends and parses HTML In-Reply-To: <20080511154815.GA5693@msgids.ruediger-kuhlmann.de> References: <20080511172542.181da3f6@webkeks.org> <20080511154815.GA5693@msgids.ruediger-kuhlmann.de> Message-ID: <20080511180406.538e0610@webkeks.org> --Sig_/wKJqjbtOO1ujHfOpFdgBKfJ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable R=C3=BCdiger Kuhlmann wrote: > As such, the place > for text/plain is supposed to contain encryped text/plain, while > the place for text/html is supposed to contain encrypted text/html. That's exactly what I thought would be the right way to do it, thanks. The problem is that Pidgin puts the HTML inside the XMPP *body*, which is wrong, wrong and once again very wrong! It should put plaintext there! It *may* use XHTML in the namespace reserved for it, but even if it does so, it MUST also send a plain text variant, otherwise it violates the RFC and the XHTML XEP! Please fix that! --=20 Jonathan --Sig_/wKJqjbtOO1ujHfOpFdgBKfJ Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- iQIcBAEBAwAGBQJIJxj6AAoJEMtRg9d5cXHkRO0P/RW37Gt++h99rsdUE2D3NXwU brvYMZOPCdJvExOgCgLFzxogxWiwziRyofHvDoiUQPTMTERhW+uwiuqZQSOgwvGd 8xRijxwYFQ19oSc8YOxwWoLZJPnqUpNY3g7iNORv42A0xP0rIlPp9LUCzhrEDuAu QluNMYrqoxb+a0V+EVUMyGtv2I+owI9IOLbpYN4cWdY60xuX1Ot0PkGKVYhwN8F+ mCH5tgTQpHg3SIB0cg5iIFxrYyN2HCYmNV0smwFQsAcVtV/NWfrlZ6psmZHXzwIa uC7mz1c/0YxjXDTVFAG4PZRe6Un1ZWjer771Xl6F7Pmczrn7w6PpGhv+JSv3XsI2 C30HW8DlDvLIoIVwiQqZ7Ey0b0IPkNo9EXISm+r2qqiVrbyDtzwmj0WPM7aHh0IP w8zaY8R5F9R5GwKEp4D3cHVAR1sGDZKWZ1DdbRssbMzZ2Te9xGhebNYGvz+JIgi0 dcIUhEDP0g42+Z+gYxsKwdTb8WZptoKaAw9I04bYSVfrUswhP4rWZgqzrUhKS9ro +JFH5zOgqPSU7VI0PdFJ9QNqhJ5/MnZqV/laYtJGZy2OH6tPF+qc0pHKdp2DskcS zcOw3AzJ2Krr314kD+oomXk2P9iGb1UboauIcp33axqu39qOCHPUx0uUhWZ3gJmY SGkuNOsSlYW8MF/K1pSr =POWh -----END PGP SIGNATURE----- --Sig_/wKJqjbtOO1ujHfOpFdgBKfJ-- From =?iso-8859-1?Q?R=FCdiger?= Kuhlmann Sun May 11 17:30:37 2008 From: =?iso-8859-1?Q?R=FCdiger?= Kuhlmann (=?iso-8859-1?Q?R=FCdiger?= Kuhlmann) Date: Sun, 11 May 2008 18:30:37 +0200 Subject: [otr-users] Pidgin plugin sends and parses HTML In-Reply-To: <20080511180406.538e0610@webkeks.org> References: <20080511172542.181da3f6@webkeks.org> <20080511154815.GA5693@msgids.ruediger-kuhlmann.de> <20080511180406.538e0610@webkeks.org> Message-ID: <20080511163037.GB5693@msgids.ruediger-kuhlmann.de> --rS8CxjVDS/+yyDmU Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable >--[Jonathan Schleifer]-- > R=FCdiger Kuhlmann wrote: > > As such, the place > > for text/plain is supposed to contain encryped text/plain, while > > the place for text/html is supposed to contain encrypted text/html. > That's exactly what I thought would be the right way to do it, thanks. > The problem is that Pidgin puts the HTML inside the XMPP *body*, which > is wrong, wrong and once again very wrong! It should put plaintext > there! It *may* use XHTML in the namespace reserved for it, but even if > it does so, it MUST also send a plain text variant, otherwise it > violates the RFC and the XHTML XEP! The excuse that will pop up on the list will be: | But the encrypted text _is_ plain text and not HTML | and thus doesn't violate the XMPP RfC!!!111oneeleven!!! =2E.. which is technically true, but totally misses the point why this is wrong. The only thing ever said about integration says (from the README distributed with the libOTR source code): | If newmessage gets set by the call to something non-NULL, then you | should replace your message with the contents of newmessage, and | send that instead. So it says the only change to the data sent out is that the actual message is replaced by the encrypted one. In particular, it doesn't say to put the encrypted HTML in place of the text/plain part of the message, nor does it say anything about having to support HTML somewhere. I'm still waiting for someone to even try to bring any argument refusing my conclusion. Yours, R=FCdiger. --=20 "See, free nations are peaceful nations. Free nations don't attack each other. Free nations don't develop weapons of mass destruction." - George W. Bush, Milwaukee, Wis., Oct. 3, 2003 --rS8CxjVDS/+yyDmU Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIJx8tHFs/RFyJr1ERAhmRAKCwwvcvdfugwWtkg5I4wdT70slFTACeLjoE 21qA5lcAfn3svKS3p+rf41w= =MdDE -----END PGP SIGNATURE----- --rS8CxjVDS/+yyDmU-- From mail@scottellis.com.au Mon May 12 04:20:05 2008 From: mail@scottellis.com.au (Scott Ellis) Date: Mon, 12 May 2008 13:20:05 +1000 Subject: [otr-users] Pidgin plugin sends and parses HTML In-Reply-To: <20080511163037.GB5693@msgids.ruediger-kuhlmann.de> References: <20080511172542.181da3f6@webkeks.org> <20080511154815.GA5693@msgids.ruediger-kuhlmann.de> <20080511180406.538e0610@webkeks.org> <20080511163037.GB5693@msgids.ruediger-kuhlmann.de> Message-ID: <96e269140805112020k6ea60e9jaa2a0814cee3ca55@mail.gmail.com> ------=_Part_15291_17682721.1210562405988 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline QWN0dWFsbHkgdGhlcmUgaXMgYSBzZXBhcmF0ZSBwbHVnaW4gYXZhaWxhYmxlIGZvciBNaXJhbmRh IChzYW1lIGF1dGhvciBhcwp0aGUgT1RSIHBsdWdpbiAtIGkuZS4gbWUpIHRoYXQgd2lsbCBzdHJp cCBIVE1MIGZyb20gaW5jb21pbmcgbWVzc2FnZXMgLSB0aGlzCmlzIHRvIGFsbG93IGZvciBPVFIg aW50ZXJvcGVyYWJpbGl0eSB3aXRoIHRob3NlIGNsaWVudHMgdGhhdCBkbyB3b3JrCmRpZmZlcmVu dGx5LgoKSSBoYWQgYSBzaW1pbGFyIGRpc2N1c3Npb24gd2l0aCB0aGUgT1RSIGF1dGhvcnMgYWJv dXQgdGhpcyBhcyB3ZWxsLCB3aGVuIEkKZmlyc3QgaW1wbGVtZW50ZWQgbXkgcGx1Z2luLiBJIHdh cyBuZXZlciBnaXZlbiB1c2VsZXNzIGxpbmtzIC0gdGhleQpleHBsYWluZWQgdGhlaXIgcG9zaXRp b24gcXVpdGUgY2xlYXJseS4gSG93ZXZlciBJIGRpZG4ndCBhbmQgc3RpbGwgZG9uJ3QKYWdyZWUu IFRvIHRoZW0sIE9UUiBpcyBhIHByb3RvY29sIGluIGl0J3Mgb3duIHJpZ2h0LCBleGlzdGluZyBv biB0b3Agb2YKb3RoZXIgSU0gcHJvdG9jb2xzIGJ1dCBoYXZpbmcgaXQncyBvd24gcnVsZXMuIElu IHRoZSBPVFIgc3BlYyBpdCBkb2VzIHNheQp0aGF0IG1lc3NhZ2VzIGJlbG9uZ2luZyB0byB0aGUg T1RSIHByb3RvY29sIG1heSBjb250YWluIEhUTUwuIEkgd291bGQgbXVjaApyYXRoZXIgT1RSIGJl IGNvbnNpZGVyZWQgYW4gZXh0ZW5zaW9uIHRvIGV4aXN0aW5nIHByb3RvY29scywgYW5kIGhhdmUg dGhlCnVuZW5jcnlwdGVkIG1lc3NhZ2VzIGZvbGxvdyB0aGUgcnVsZXMgb2YgdGhlIHVuZGVybHlp bmcgcHJvdG9jb2wuIE9uZQptb3RpdmF0aW9uIGZvciB0aGlzIGludGVycHJldGF0aW9uLCBJIHRo aW5rLCBpcyB0aGF0IGl0IG1heSBiZSBtb3JlCmRpZmZpY3VsdCB0byBhY2hpZXZlIHRoaXMgaW4g dGhlIHBpZGdpbiBhcmNoaXRlY3R1cmUgKGkuZS4gdGhlIG1lc3NhZ2UgdG8gYmUKc2VudCBjb21l cyB3aXRoIEhUTUwgZnJvbSB0aGUgbWVzc2FnZSB3aW5kb3csIGdvZXMgdmlhIG90ciBhbmQgdGhl biB0byB0aGUKcHJvdG9jb2wgZm9yIHNlbmRpbmcgLSB1c3VhbGx5IHRoZSBwcm90byB3aWxsIGRl Y2lkZSBpZiBpdCBjYW4gc2VuZCB0aGUgSFRNTApidXQgaWYgT1RSIGhhcyBlbmNyeXB0ZWQgdGhl IG1lc3NhZ2UgdGhhdCdzIG5vdCBwb3NzaWJsZSkuIFdpdGggTWlyYW5kYSB0aGF0CnByb2JsZW0g aXMgZWFzaWx5IHNvbHZlZCwgYnV0IG90aGVyIHRoaW5ncyBhcmUgaGFyZGVyIChpLmUuIHNlbmRp bmcgYW4gJ2knbQpnb2luZyBvZmZsaW5lIG5vdycgbWVzc2FnZSkuCgpJIGRvbid0IHRoaW5rIHRo ZXJlJ3MgYW55dGhpbmcgY29uZnVzaW5nIHRvIGl0IC0ganVzdCBhIGRpZmZlcmVuY2UgaW4KcGhp bG9zb3BoeS4gTXkgY29uY2VybiBpcyB0aGF0IHRoZSBkZWNpc2lvbiB0byBjYWxsIE9UUiBhICdw cm90b2NvbCcgaXMKbW90aXZhdGVkIGJ5IGNvbnZlbmllbmNlLgoKU2NvdHQKCk9uIE1vbiwgTWF5 IDEyLCAyMDA4IGF0IDI6MzAgQU0sIFLDvGRpZ2VyIEt1aGxtYW5uIDwKbC1vdHIuMDcwNSsyM2p2 LWxAcnVlZGlnZXIta3VobG1hbm4uZGU8bC1vdHIuMDcwNSUyQjIzanYtbEBydWVkaWdlci1rdWhs bWFubi5kZT4+Cndyb3RlOgoKPgo+ID4tLVtKb25hdGhhbiBTY2hsZWlmZXJdLS08anMtb3RyaW1A d2Via2Vrcy5vcmc+Cj4gPiBSw7xkaWdlciBLdWhsbWFubiA8bC1vdHIuMDcwNSsyM2p2LWxAcnVl ZGlnZXIta3VobG1hbm4uZGU8bC1vdHIuMDcwNSUyQjIzanYtbEBydWVkaWdlci1rdWhsbWFubi5k ZT4+Cj4gd3JvdGU6Cj4gPiA+IEFzIHN1Y2gsIHRoZSBwbGFjZQo+ID4gPiBmb3IgdGV4dC9wbGFp biBpcyBzdXBwb3NlZCB0byBjb250YWluIGVuY3J5cGVkIHRleHQvcGxhaW4sIHdoaWxlCj4gPiA+ IHRoZSBwbGFjZSBmb3IgdGV4dC9odG1sIGlzIHN1cHBvc2VkIHRvIGNvbnRhaW4gZW5jcnlwdGVk IHRleHQvaHRtbC4KPiA+IFRoYXQncyBleGFjdGx5IHdoYXQgSSB0aG91Z2h0IHdvdWxkIGJlIHRo ZSByaWdodCB3YXkgdG8gZG8gaXQsIHRoYW5rcy4KPiA+IFRoZSBwcm9ibGVtIGlzIHRoYXQgUGlk Z2luIHB1dHMgdGhlIEhUTUwgaW5zaWRlIHRoZSBYTVBQICpib2R5Kiwgd2hpY2gKPiA+IGlzIHdy b25nLCB3cm9uZyBhbmQgb25jZSBhZ2FpbiB2ZXJ5IHdyb25nISBJdCBzaG91bGQgcHV0IHBsYWlu dGV4dAo+ID4gdGhlcmUhIEl0ICptYXkqIHVzZSBYSFRNTCBpbiB0aGUgbmFtZXNwYWNlIHJlc2Vy dmVkIGZvciBpdCwgYnV0IGV2ZW4gaWYKPiA+IGl0IGRvZXMgc28sIGl0IE1VU1QgYWxzbyBzZW5k IGEgcGxhaW4gdGV4dCB2YXJpYW50LCBvdGhlcndpc2UgaXQKPiA+IHZpb2xhdGVzIHRoZSBSRkMg YW5kIHRoZSBYSFRNTCBYRVAhCj4KPiBUaGUgZXhjdXNlIHRoYXQgd2lsbCBwb3AgdXAgb24gdGhl IGxpc3Qgd2lsbCBiZToKPgo+IHwgQnV0IHRoZSBlbmNyeXB0ZWQgdGV4dCBfaXNfIHBsYWluIHRl eHQgYW5kIG5vdCBIVE1MCj4gfCBhbmQgdGh1cyBkb2Vzbid0IHZpb2xhdGUgdGhlIFhNUFAgUmZD ISEhMTExb25lZWxldmVuISEhCj4KPiAuLi4gd2hpY2ggaXMgdGVjaG5pY2FsbHkgdHJ1ZSwgYnV0 IHRvdGFsbHkgbWlzc2VzIHRoZSBwb2ludCB3aHkKPiB0aGlzIGlzIHdyb25nLiBUaGUgb25seSB0 aGluZyBldmVyIHNhaWQgYWJvdXQgaW50ZWdyYXRpb24gc2F5cwo+IChmcm9tIHRoZSBSRUFETUUg ZGlzdHJpYnV0ZWQgd2l0aCB0aGUgbGliT1RSIHNvdXJjZSBjb2RlKToKPgo+IHwgSWYgbmV3bWVz c2FnZSBnZXRzIHNldCBieSB0aGUgY2FsbCB0byBzb21ldGhpbmcgbm9uLU5VTEwsIHRoZW4geW91 Cj4gfCBzaG91bGQgcmVwbGFjZSB5b3VyIG1lc3NhZ2Ugd2l0aCB0aGUgY29udGVudHMgb2YgbmV3 bWVzc2FnZSwgYW5kCj4gfCBzZW5kIHRoYXQgaW5zdGVhZC4KPgo+IFNvIGl0IHNheXMgdGhlIG9u bHkgY2hhbmdlIHRvIHRoZSBkYXRhIHNlbnQgb3V0IGlzIHRoYXQgdGhlIGFjdHVhbAo+IG1lc3Nh Z2UgaXMgcmVwbGFjZWQgYnkgdGhlIGVuY3J5cHRlZCBvbmUuIEluIHBhcnRpY3VsYXIsIGl0IGRv ZXNuJ3QKPiBzYXkgdG8gcHV0IHRoZSBlbmNyeXB0ZWQgSFRNTCBpbiBwbGFjZSBvZiB0aGUgdGV4 dC9wbGFpbiBwYXJ0IG9mCj4gdGhlIG1lc3NhZ2UsIG5vciBkb2VzIGl0IHNheSBhbnl0aGluZyBh Ym91dCBoYXZpbmcgdG8gc3VwcG9ydCBIVE1MCj4gc29tZXdoZXJlLiBJJ20gc3RpbGwgd2FpdGlu ZyBmb3Igc29tZW9uZSB0byBldmVuIHRyeSB0byBicmluZyBhbnkKPiBhcmd1bWVudCByZWZ1c2lu ZyBteSBjb25jbHVzaW9uLgo+Cj4gWW91cnMsIFLDvGRpZ2VyLgo+Cj4gLS0KPiAiU2VlLCBmcmVl IG5hdGlvbnMgYXJlIHBlYWNlZnVsIG5hdGlvbnMuIEZyZWUgbmF0aW9ucyBkb24ndCBhdHRhY2sK PiAgZWFjaCBvdGhlci4gRnJlZSBuYXRpb25zIGRvbid0IGRldmVsb3Agd2VhcG9ucyBvZiBtYXNz IGRlc3RydWN0aW9uLiIKPiAgICAgIC0gR2VvcmdlIFcuIEJ1c2gsIE1pbHdhdWtlZSwgV2lzLiwg T2N0LiAzLCAyMDAzCj4KPiAtLS0tLUJFR0lOIFBHUCBTSUdOQVRVUkUtLS0tLQo+IFZlcnNpb246 IEdudVBHIHYxLjQuNiAoR05VL0xpbnV4KQo+Cj4gaUQ4REJRRklKeDh0SEZzL1JGeUpyMUVSQWht UkFLQ3d3dmN2ZGZ1Z3dXdGtnNUk0d2RUNzBzbEZUQUNlTGpvRQo+IDIxcUE1bGNBZm4zc3ZLUzNw K3JmNDF3PQo+ID1NZERFCj4gLS0tLS1FTkQgUEdQIFNJR05BVFVSRS0tLS0tCj4KPgo= ------=_Part_15291_17682721.1210562405988 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline QWN0dWFsbHkgdGhlcmUgaXMgYSBzZXBhcmF0ZSBwbHVnaW4gYXZhaWxhYmxlIGZvciBNaXJhbmRh IChzYW1lIGF1dGhvciBhcyB0aGUgT1RSIHBsdWdpbiAtIGkuZS4gbWUpIHRoYXQgd2lsbCBzdHJp cCBIVE1MIGZyb20gaW5jb21pbmcgbWVzc2FnZXMgLSB0aGlzIGlzIHRvIGFsbG93IGZvciBPVFIg aW50ZXJvcGVyYWJpbGl0eSB3aXRoIHRob3NlIGNsaWVudHMgdGhhdCBkbyB3b3JrIGRpZmZlcmVu dGx5Ljxicj4KPGJyPkkgaGFkIGEgc2ltaWxhciBkaXNjdXNzaW9uIHdpdGggdGhlIE9UUiBhdXRo b3JzIGFib3V0IHRoaXMgYXMgd2VsbCwgd2hlbiBJIGZpcnN0IGltcGxlbWVudGVkIG15IHBsdWdp bi4gSSB3YXMgbmV2ZXIgZ2l2ZW4gdXNlbGVzcyBsaW5rcyAtIHRoZXkgZXhwbGFpbmVkIHRoZWly IHBvc2l0aW9uIHF1aXRlIGNsZWFybHkuIEhvd2V2ZXIgSSBkaWRuJiMzOTt0IGFuZCBzdGlsbCBk b24mIzM5O3QgYWdyZWUuIFRvIHRoZW0sIE9UUiBpcyBhIHByb3RvY29sIGluIGl0JiMzOTtzIG93 biByaWdodCwgZXhpc3Rpbmcgb24gdG9wIG9mIG90aGVyIElNIHByb3RvY29scyBidXQgaGF2aW5n IGl0JiMzOTtzIG93biBydWxlcy4gSW4gdGhlIE9UUiBzcGVjIGl0IGRvZXMgc2F5IHRoYXQgbWVz c2FnZXMgYmVsb25naW5nIHRvIHRoZSBPVFIgcHJvdG9jb2wgbWF5IGNvbnRhaW4gSFRNTC4gSSB3 b3VsZCBtdWNoIHJhdGhlciBPVFIgYmUgY29uc2lkZXJlZCBhbiBleHRlbnNpb24gdG8gZXhpc3Rp bmcgcHJvdG9jb2xzLCBhbmQgaGF2ZSB0aGUgdW5lbmNyeXB0ZWQgbWVzc2FnZXMgZm9sbG93IHRo ZSBydWxlcyBvZiB0aGUgdW5kZXJseWluZyBwcm90b2NvbC4gT25lIG1vdGl2YXRpb24gZm9yIHRo aXMgaW50ZXJwcmV0YXRpb24sIEkgdGhpbmssIGlzIHRoYXQgaXQgbWF5IGJlIG1vcmUgZGlmZmlj dWx0IHRvIGFjaGlldmUgdGhpcyBpbiB0aGUgcGlkZ2luIGFyY2hpdGVjdHVyZSAoaS5lLiB0aGUg bWVzc2FnZSB0byBiZSBzZW50IGNvbWVzIHdpdGggSFRNTCBmcm9tIHRoZSBtZXNzYWdlIHdpbmRv dywgZ29lcyB2aWEgb3RyIGFuZCB0aGVuIHRvIHRoZSBwcm90b2NvbCBmb3Igc2VuZGluZyAtIHVz dWFsbHkgdGhlIHByb3RvIHdpbGwgZGVjaWRlIGlmIGl0IGNhbiBzZW5kIHRoZSBIVE1MIGJ1dCBp ZiBPVFIgaGFzIGVuY3J5cHRlZCB0aGUgbWVzc2FnZSB0aGF0JiMzOTtzIG5vdCBwb3NzaWJsZSku IFdpdGggTWlyYW5kYSB0aGF0IHByb2JsZW0gaXMgZWFzaWx5IHNvbHZlZCwgYnV0IG90aGVyIHRo aW5ncyBhcmUgaGFyZGVyIChpLmUuIHNlbmRpbmcgYW4gJiMzOTtpJiMzOTttIGdvaW5nIG9mZmxp bmUgbm93JiMzOTsgbWVzc2FnZSkuIDxicj4KPGJyPkkgZG9uJiMzOTt0IHRoaW5rIHRoZXJlJiMz OTtzIGFueXRoaW5nIGNvbmZ1c2luZyB0byBpdCAtIGp1c3QgYSBkaWZmZXJlbmNlIGluIHBoaWxv c29waHkuIE15IGNvbmNlcm4gaXMgdGhhdCB0aGUgZGVjaXNpb24gdG8gY2FsbCBPVFIgYSAmIzM5 O3Byb3RvY29sJiMzOTsgaXMgbW90aXZhdGVkIGJ5IGNvbnZlbmllbmNlLjxicj48YnI+U2NvdHQ8 YnI+PGJyPjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj4KT24gTW9uLCBNYXkgMTIsIDIwMDggYXQg MjozMCBBTSwgUsO8ZGlnZXIgS3VobG1hbm4gJmx0OzxhIGhyZWY9Im1haWx0bzpsLW90ci4wNzA1 JTJCMjNqdi1sQHJ1ZWRpZ2VyLWt1aGxtYW5uLmRlIj5sLW90ci4wNzA1KzIzanYtbEBydWVkaWdl ci1rdWhsbWFubi5kZTwvYT4mZ3Q7IHdyb3RlOjxicj48YmxvY2txdW90ZSBjbGFzcz0iZ21haWxf cXVvdGUiIHN0eWxlPSJib3JkZXItbGVmdDogMXB4IHNvbGlkIHJnYigyMDQsIDIwNCwgMjA0KTsg bWFyZ2luOiAwcHQgMHB0IDBwdCAwLjhleDsgcGFkZGluZy1sZWZ0OiAxZXg7Ij4KPGRpdiBjbGFz cz0iSWgyRTNkIj48YnI+CiZndDstLVtKb25hdGhhbiBTY2hsZWlmZXJdLS0mbHQ7PGEgaHJlZj0i bWFpbHRvOmpzLW90cmltQHdlYmtla3Mub3JnIj5qcy1vdHJpbUB3ZWJrZWtzLm9yZzwvYT4mZ3Q7 PGJyPgo8L2Rpdj48ZGl2PjxkaXY+PC9kaXY+PGRpdiBjbGFzcz0iV2ozQzdjIj4mZ3Q7IFLDvGRp Z2VyIEt1aGxtYW5uICZsdDs8YSBocmVmPSJtYWlsdG86bC1vdHIuMDcwNSUyQjIzanYtbEBydWVk aWdlci1rdWhsbWFubi5kZSI+bC1vdHIuMDcwNSsyM2p2LWxAcnVlZGlnZXIta3VobG1hbm4uZGU8 L2E+Jmd0OyB3cm90ZTo8YnI+CiZndDsgJmd0OyBBcyBzdWNoLCB0aGUgcGxhY2U8YnI+CiZndDsg Jmd0OyBmb3IgdGV4dC9wbGFpbiBpcyBzdXBwb3NlZCB0byBjb250YWluIGVuY3J5cGVkIHRleHQv cGxhaW4sIHdoaWxlPGJyPgomZ3Q7ICZndDsgdGhlIHBsYWNlIGZvciB0ZXh0L2h0bWwgaXMgc3Vw cG9zZWQgdG8gY29udGFpbiBlbmNyeXB0ZWQgdGV4dC9odG1sLjxicj4KJmd0OyBUaGF0JiMzOTtz IGV4YWN0bHkgd2hhdCBJIHRob3VnaHQgd291bGQgYmUgdGhlIHJpZ2h0IHdheSB0byBkbyBpdCwg dGhhbmtzLjxicj4KJmd0OyBUaGUgcHJvYmxlbSBpcyB0aGF0IFBpZGdpbiBwdXRzIHRoZSBIVE1M IGluc2lkZSB0aGUgWE1QUCAqYm9keSosIHdoaWNoPGJyPgomZ3Q7IGlzIHdyb25nLCB3cm9uZyBh bmQgb25jZSBhZ2FpbiB2ZXJ5IHdyb25nISBJdCBzaG91bGQgcHV0IHBsYWludGV4dDxicj4KJmd0 OyB0aGVyZSEgSXQgKm1heSogdXNlIFhIVE1MIGluIHRoZSBuYW1lc3BhY2UgcmVzZXJ2ZWQgZm9y IGl0LCBidXQgZXZlbiBpZjxicj4KJmd0OyBpdCBkb2VzIHNvLCBpdCBNVVNUIGFsc28gc2VuZCBh IHBsYWluIHRleHQgdmFyaWFudCwgb3RoZXJ3aXNlIGl0PGJyPgomZ3Q7IHZpb2xhdGVzIHRoZSBS RkMgYW5kIHRoZSBYSFRNTCBYRVAhPGJyPgo8YnI+CjwvZGl2PjwvZGl2PlRoZSBleGN1c2UgdGhh dCB3aWxsIHBvcCB1cCBvbiB0aGUgbGlzdCB3aWxsIGJlOjxicj4KPGJyPgp8IEJ1dCB0aGUgZW5j cnlwdGVkIHRleHQgX2lzXyBwbGFpbiB0ZXh0IGFuZCBub3QgSFRNTDxicj4KfCBhbmQgdGh1cyBk b2VzbiYjMzk7dCB2aW9sYXRlIHRoZSBYTVBQIFJmQyEhITExMW9uZWVsZXZlbiEhITxicj4KPGJy PgouLi4gd2hpY2ggaXMgdGVjaG5pY2FsbHkgdHJ1ZSwgYnV0IHRvdGFsbHkgbWlzc2VzIHRoZSBw b2ludCB3aHk8YnI+CnRoaXMgaXMgd3JvbmcuIFRoZSBvbmx5IHRoaW5nIGV2ZXIgc2FpZCBhYm91 dCBpbnRlZ3JhdGlvbiBzYXlzPGJyPgooZnJvbSB0aGUgUkVBRE1FIGRpc3RyaWJ1dGVkIHdpdGgg dGhlIGxpYk9UUiBzb3VyY2UgY29kZSk6PGJyPgo8YnI+CnwgSWYgbmV3bWVzc2FnZSBnZXRzIHNl dCBieSB0aGUgY2FsbCB0byBzb21ldGhpbmcgbm9uLU5VTEwsIHRoZW4geW91PGJyPgp8IHNob3Vs ZCByZXBsYWNlIHlvdXIgbWVzc2FnZSB3aXRoIHRoZSBjb250ZW50cyBvZiBuZXdtZXNzYWdlLCBh bmQ8YnI+Cnwgc2VuZCB0aGF0IGluc3RlYWQuPGJyPgo8YnI+ClNvIGl0IHNheXMgdGhlIG9ubHkg Y2hhbmdlIHRvIHRoZSBkYXRhIHNlbnQgb3V0IGlzIHRoYXQgdGhlIGFjdHVhbDxicj4KbWVzc2Fn ZSBpcyByZXBsYWNlZCBieSB0aGUgZW5jcnlwdGVkIG9uZS4gSW4gcGFydGljdWxhciwgaXQgZG9l c24mIzM5O3Q8YnI+CnNheSB0byBwdXQgdGhlIGVuY3J5cHRlZCBIVE1MIGluIHBsYWNlIG9mIHRo ZSB0ZXh0L3BsYWluIHBhcnQgb2Y8YnI+CnRoZSBtZXNzYWdlLCBub3IgZG9lcyBpdCBzYXkgYW55 dGhpbmcgYWJvdXQgaGF2aW5nIHRvIHN1cHBvcnQgSFRNTDxicj4Kc29tZXdoZXJlLiBJJiMzOTtt IHN0aWxsIHdhaXRpbmcgZm9yIHNvbWVvbmUgdG8gZXZlbiB0cnkgdG8gYnJpbmcgYW55PGJyPgph cmd1bWVudCByZWZ1c2luZyBteSBjb25jbHVzaW9uLjxicj4KPGRpdj48ZGl2PjwvZGl2PjxkaXYg Y2xhc3M9IldqM0M3YyI+PGJyPgpZb3VycywgUsO8ZGlnZXIuPGJyPgo8YnI+Ci0tPGJyPgomcXVv dDtTZWUsIGZyZWUgbmF0aW9ucyBhcmUgcGVhY2VmdWwgbmF0aW9ucy4gRnJlZSBuYXRpb25zIGRv biYjMzk7dCBhdHRhY2s8YnI+CiZuYnNwO2VhY2ggb3RoZXIuIEZyZWUgbmF0aW9ucyBkb24mIzM5 O3QgZGV2ZWxvcCB3ZWFwb25zIG9mIG1hc3MgZGVzdHJ1Y3Rpb24uJnF1b3Q7PGJyPgogJm5ic3A7 ICZuYnNwOyAmbmJzcDstIEdlb3JnZSBXLiBCdXNoLCBNaWx3YXVrZWUsIFdpcy4sIE9jdC4gMywg MjAwMzxicj4KPC9kaXY+PC9kaXY+PGJyPi0tLS0tQkVHSU4gUEdQIFNJR05BVFVSRS0tLS0tPGJy PgpWZXJzaW9uOiBHbnVQRyB2MS40LjYgKEdOVS9MaW51eCk8YnI+Cjxicj4KaUQ4REJRRklKeDh0 SEZzL1JGeUpyMUVSQWhtUkFLQ3d3dmN2ZGZ1Z3dXdGtnNUk0d2RUNzBzbEZUQUNlTGpvRTxicj4K MjFxQTVsY0FmbjNzdktTM3ArcmY0MXc9PGJyPgo9TWRERTxicj4KLS0tLS1FTkQgUEdQIFNJR05B VFVSRS0tLS0tPGJyPgo8YnI+PC9ibG9ja3F1b3RlPjwvZGl2Pjxicj4K ------=_Part_15291_17682721.1210562405988-- From =?iso-8859-1?Q?R=FCdiger?= Kuhlmann Mon May 12 13:17:37 2008 From: =?iso-8859-1?Q?R=FCdiger?= Kuhlmann (=?iso-8859-1?Q?R=FCdiger?= Kuhlmann) Date: Mon, 12 May 2008 14:17:37 +0200 Subject: [otr-users] Pidgin plugin sends and parses HTML In-Reply-To: <96e269140805112020k6ea60e9jaa2a0814cee3ca55@mail.gmail.com> References: <20080511172542.181da3f6@webkeks.org> <20080511154815.GA5693@msgids.ruediger-kuhlmann.de> <20080511180406.538e0610@webkeks.org> <20080511163037.GB5693@msgids.ruediger-kuhlmann.de> <96e269140805112020k6ea60e9jaa2a0814cee3ca55@mail.gmail.com> Message-ID: <20080512121737.GA5688@msgids.ruediger-kuhlmann.de> >--[Scott Ellis]-- > I was never given useless links - they > explained their position quite clearly. However I didn't and still don't > agree. To them, OTR is a protocol in it's own right, existing on top of > other IM protocols but having it's own rules. In the OTR spec it does say > that messages belonging to the OTR protocol may contain HTML. Uhm. I can only find one place where it mentiones HTML at all. And while it mentions that it may contain markup, it still doesn't qualify as allowing to put HTML into a place where only text/plain is allowed. Of course the text to encrypt may contain HTML, if an HTML message is about to be sent. Just as it may contain rtf, M$ .doc or any other markup if that is what is to be sent. But the data type of the data to be encrypted can only be determined by the underlying protocol, otherwise an extensive chapter on integration would HAVE to be part of the spec. It isn't. It claims that using libOTR is as simple as replacing the plain text with the output of the function. And it does not provide any functionality to encode or decode plain text to HTML. > I don't think there's anything confusing to it - just a difference in > philosophy. My concern is that the decision to call OTR a 'protocol' is > motivated by convenience. Which is why I'd consider libOTR to be essentially a misnamed libGaimOTR. I think I remember a statement from libOTR developers that any change to libOTR could only be made at the same time as a change to Gaim-libOTR-plugin. Which highlights this concern well enough for everyone to notice. The question is how to proceed without hampering the broken interoperability of the OTR-wonnabe-protocol further. Maybe the best idea would be to increase the version number and in the new version make the protocol provide means to specify the type of data (plain/text, a well-defined subset of HTML, whatever) and means to determine the receiver's preferences. Anyone who doesn't agree? -- "See, free nations are peaceful nations. Free nations don't attack each other. Free nations don't develop weapons of mass destruction." - George W. Bush, Milwaukee, Wis., Oct. 3, 2003 From js-otrim@webkeks.org Mon May 12 13:31:49 2008 From: js-otrim@webkeks.org (Jonathan Schleifer) Date: Mon, 12 May 2008 14:31:49 +0200 Subject: [otr-users] Pidgin plugin sends and parses HTML In-Reply-To: <20080512121737.GA5688@msgids.ruediger-kuhlmann.de> References: <20080511172542.181da3f6@webkeks.org> <20080511154815.GA5693@msgids.ruediger-kuhlmann.de> <20080511180406.538e0610@webkeks.org> <20080511163037.GB5693@msgids.ruediger-kuhlmann.de> <96e269140805112020k6ea60e9jaa2a0814cee3ca55@mail.gmail.com> <20080512121737.GA5688@msgids.ruediger-kuhlmann.de> Message-ID: <20080512143149.46c0484e@webkeks.org> --Sig_/MwoG5xYFPubdWo5Diz4EgCb Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable R=C3=BCdiger Kuhlmann wrote: > The question is how to proceed without hampering the broken > interoperability of the OTR-wonnabe-protocol further. Maybe the best > idea would be to increase the version number and in the new version > make the protocol provide means to specify the type of data > (plain/text, a well-defined subset of HTML, whatever) and means to > determine the receiver's preferences. Anyone who doesn't agree? Yes, me. XMPP offers XHTML IM. You can just put the HTML code there and put plain-text in the message body. This way, Pidgin can use it damned HTML (seems it can't even work without it!) and those who don't understand XHTML IM get the plain message, like wanted. For ICQ, HTML should just NEVER be used as it doesn't support it, even in ICQ6. OTR shouldn't change anything about the data it encrypts. It should just encrypt it, nothing more. That way, you can encrypt HTML messages and put them in the *RIGHT* place, which is *NOT* the XMPP message body and you can encrypt plain text and put it in the XMPP message body. --=20 Jonathan --Sig_/MwoG5xYFPubdWo5Diz4EgCb Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- iQIcBAEBAwAGBQJIKDi5AAoJEMtRg9d5cXHkWLoP+wXGe25T4w2000ZhGMUyIinc rQEeJtUZjV8IeFanJTMrOlMdCmPh1f6lHQaqw5l5DO5CeaHZGZe0I25CDyUAUqXh euZdm/QcIGAqfFedJcYS4VdV04Gr5Td1jRCt1BhPTTX8VKM8lTYd1PzaiH1LBPQB s8BfloGGASfSX4yUnhSl4F4aC7oZYZdHa0unpw7D+Ja01BFUJ+LF8cYKvKEZ7hao oz90mhgary8iUKk6bofNubAVziLMiGcQzxpI/lHYAStB8YcjaasyL+g825nhMz1u G6cX1nBDF5FaQVR+PHE9vFH0F8gyrUCM9UtoN+t3xvvw+sSKHxc9u8aeIiIYkYTP 6zzHzpUpRR/lcP0rG9ns+eLJ+f6F7lNNuFc5VlKTB3OCJ/ExXfSDYkiNyDsmeOJ6 RqdcPiApMh5CodpPdU5jLHEHnswglDbmSRMIj00IP3o3445yqmhB2QXcOIrVrW5K 70NzJYfZnqM0XduPE14KrhYGMv3lSR/yVInDdwUo7Y+Nv0EpgMJ/H+UJVFIH0ZIb jKl9fgyccRIW/SPZVXLnxlJ/kmG6Q8ypzmQbZngtEirj9PKG/MrcsWAVe0IptDaZ EX+i2eD3jqD+XOW4QflIGFlsq/tqijBRhGBk3GiRblEV6LxuWHawMca/aK1yTJ5y 9SMsMzfiyCocH4HP8TlK =rwfH -----END PGP SIGNATURE----- --Sig_/MwoG5xYFPubdWo5Diz4EgCb-- From =?iso-8859-1?Q?R=FCdiger?= Kuhlmann Mon May 12 14:35:38 2008 From: =?iso-8859-1?Q?R=FCdiger?= Kuhlmann (=?iso-8859-1?Q?R=FCdiger?= Kuhlmann) Date: Mon, 12 May 2008 15:35:38 +0200 Subject: [otr-users] Pidgin plugin sends and parses HTML In-Reply-To: <20080512143149.46c0484e@webkeks.org> References: <20080511172542.181da3f6@webkeks.org> <20080511154815.GA5693@msgids.ruediger-kuhlmann.de> <20080511180406.538e0610@webkeks.org> <20080511163037.GB5693@msgids.ruediger-kuhlmann.de> <96e269140805112020k6ea60e9jaa2a0814cee3ca55@mail.gmail.com> <20080512121737.GA5688@msgids.ruediger-kuhlmann.de> <20080512143149.46c0484e@webkeks.org> Message-ID: <20080512133538.GC5688@msgids.ruediger-kuhlmann.de> --Kj7319i9nmIyA2yE Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable >--[Jonathan Schleifer]-- > R=FCdiger Kuhlmann wrote: > > The question is how to proceed without hampering the broken > > interoperability of the OTR-wonnabe-protocol further. Maybe the best > > idea would be to increase the version number and in the new version > > make the protocol provide means to specify the type of data > > (plain/text, a well-defined subset of HTML, whatever) and means to > > determine the receiver's preferences. Anyone who doesn't agree? > Yes, me. > XMPP offers XHTML IM. You can just put the HTML code there and put > plain-text in the message body. This way, Pidgin can use it damned HTML > (seems it can't even work without it!) and those who don't understand > XHTML IM get the plain message, like wanted. > For ICQ, HTML should just NEVER be used as it doesn't support it, even > in ICQ6. Well, it was a try at getting the Pitchin people also on board. I certainly agree that this is the best way (which is what I do - putting plain text (encrypted) in the body, and no html tag, and rejecting all messages with html =3D plaintext and < in it). The question is how to get the Pitchin and Trillian people do the same. And that depends on how many pull how strong into correct direction. Like: Who would spend time replacing libOTR by a non-Gaim-specific library with a well thought-out interface? Who would join in in rejecting garbage messages from Pitchin? Who would massage the Pitchin guys with arguments until they try to make libOTR be what they claim it already is, a generic encryption library? > OTR shouldn't change anything about the data it encrypts. It should > just encrypt it, nothing more. That way, you can encrypt HTML messages > and put them in the *RIGHT* place, which is *NOT* the XMPP message body > and you can encrypt plain text and put it in the XMPP message body. --=20 "See, free nations are peaceful nations. Free nations don't attack each other. Free nations don't develop weapons of mass destruction." - George W. Bush, Milwaukee, Wis., Oct. 3, 2003 --Kj7319i9nmIyA2yE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIKEeqHFs/RFyJr1ERAoG8AJ9NqUroFzJF+/xAe9EItxNQ5XyT4ACfTEST DczfJfRHpHk94ON1rnZvPu4= =hawG -----END PGP SIGNATURE----- --Kj7319i9nmIyA2yE-- From mail@scottellis.com.au Mon May 12 16:01:55 2008 From: mail@scottellis.com.au (Scott Ellis) Date: Tue, 13 May 2008 01:01:55 +1000 Subject: [otr-users] Pidgin plugin sends and parses HTML In-Reply-To: <20080512121737.GA5688@msgids.ruediger-kuhlmann.de> References: <20080511172542.181da3f6@webkeks.org> <20080511154815.GA5693@msgids.ruediger-kuhlmann.de> <20080511180406.538e0610@webkeks.org> <20080511163037.GB5693@msgids.ruediger-kuhlmann.de> <96e269140805112020k6ea60e9jaa2a0814cee3ca55@mail.gmail.com> <20080512121737.GA5688@msgids.ruediger-kuhlmann.de> Message-ID: <96e269140805120801s5aa23cc9p37c200bedb59ba95@mail.gmail.com> ------=_Part_1850_29134663.1210604515986 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline > > Uhm. I can only find one place where it mentiones HTML at all. And while > it > mentions that it may contain markup, it still doesn't qualify as allowing > to > put HTML into a place where only text/plain is allowed. Of course the text > to encrypt may contain HTML, if an HTML message is about to be sent. Just > as > it may contain rtf, M$ .doc or any other markup if that is what is to be > sent. But the data type of the data to be encrypted can only be determined > by the underlying protocol, otherwise an extensive chapter on integration > would HAVE to be part of the spec. It isn't. The actual text transferred over the underlying protocol is made up of plaintext chars - and as such none of the rules of the underlying protocol are being broken. Even jabber XEPs cannot lay claim to the *meaning* of plaintext within messages - just as you and a friend are not prevented from using some code language you make up yourselves over jabber. Under this interpretation the unencrpyted messages of OTR conversations have nothing to do with the transport protocol. The phrase that was used by the developers in my earlier conversations on this topic was 'higher level protocol'. It's ugly and inconvenient to most of us, but it does make sense from a certain point of view. It claims that using libOTR is > as simple as replacing the plain text with the output of the function. You're very right there - in most cases it doesn't perform 'as advertised'. But it does work that way for a lot of clients - almost anything Qt or Java based, for example. Can I suggest this discussion continue on the dev mailing list though? Scott ------=_Part_1850_29134663.1210604515986 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Uhm. I can only find one place where it mentiones HTML at all. And while it
mentions that it may contain markup, it still doesn't qualify as allowing to
put HTML into a place where only text/plain is allowed. Of course the text
to encrypt may contain HTML, if an HTML message is about to be sent. Just as
it may contain rtf, M$ .doc or any other markup if that is what is to be
sent. But the data type of the data to be encrypted can only be determined
by the underlying protocol, otherwise an extensive chapter on integration
would HAVE to be part of the spec. It isn't.
 
The actual text transferred over the underlying protocol is made up of plaintext chars - and as such none of the rules of the underlying protocol are being broken. Even jabber XEPs cannot lay claim to the meaning of plaintext within messages - just as you and a friend are not prevented from using some code language you make up yourselves over jabber. Under this interpretation the unencrpyted messages of OTR conversations have nothing to do with the transport protocol. The phrase that was used by the developers in my earlier conversations on this topic was 'higher level protocol'. It's ugly and inconvenient to most of us, but it does make sense from a certain point of view.

It claims that using libOTR is
as simple as replacing the plain text with the output of the function.
 
You're very right there - in most cases it doesn't perform 'as advertised'. But it does work that way for a lot of clients - almost anything Qt or Java based, for example.

Can I suggest this discussion continue on the dev mailing list though?

Scott
------=_Part_1850_29134663.1210604515986-- From paul@cypherpunks.ca Mon May 12 19:09:48 2008 From: paul@cypherpunks.ca (Paul Wouters) Date: Mon, 12 May 2008 14:09:48 -0400 (EDT) Subject: [otr-users] Pidgin plugin sends and parses HTML In-Reply-To: <20080512133538.GC5688@msgids.ruediger-kuhlmann.de> References: <20080511172542.181da3f6@webkeks.org> <20080511154815.GA5693@msgids.ruediger-kuhlmann.de> <20080511180406.538e0610@webkeks.org> <20080511163037.GB5693@msgids.ruediger-kuhlmann.de> <96e269140805112020k6ea60e9jaa2a0814cee3ca55@mail.gmail.com> <20080512121737.GA5688@msgids.ruediger-kuhlmann.de> <20080512143149.46c0484e@webkeks.org> <20080512133538.GC5688@msgids.ruediger-kuhlmann.de> Message-ID: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323328-2028433139-1210615788=:11018 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT On Mon, 12 May 2008, Rüdiger Kuhlmann wrote: > agree that this is the best way (which is what I do - putting plain text > (encrypted) in the body, and no html tag, and rejecting all messages with > html = plaintext and < in it). "Be liberal in what to expect, be strict in what to send". Don't start rejecting messages based on html. what if I send a plaintext message with "you need to use the tag for that"...... Paul --8323328-2028433139-1210615788=:11018-- From =?iso-8859-1?Q?R=FCdiger?= Kuhlmann Mon May 12 19:20:13 2008 From: =?iso-8859-1?Q?R=FCdiger?= Kuhlmann (=?iso-8859-1?Q?R=FCdiger?= Kuhlmann) Date: Mon, 12 May 2008 20:20:13 +0200 Subject: [otr-users] Pidgin plugin sends and parses HTML In-Reply-To: References: <20080511172542.181da3f6@webkeks.org> <20080511154815.GA5693@msgids.ruediger-kuhlmann.de> <20080511180406.538e0610@webkeks.org> <20080511163037.GB5693@msgids.ruediger-kuhlmann.de> <96e269140805112020k6ea60e9jaa2a0814cee3ca55@mail.gmail.com> <20080512121737.GA5688@msgids.ruediger-kuhlmann.de> <20080512143149.46c0484e@webkeks.org> <20080512133538.GC5688@msgids.ruediger-kuhlmann.de> Message-ID: <20080512182013.GE5688@msgids.ruediger-kuhlmann.de> Hi Paul, >--[Paul Wouters]-- > On Mon, 12 May 2008, Rüdiger Kuhlmann wrote: > > agree that this is the best way (which is what I do - putting plain text > > (encrypted) in the body, and no html tag, and rejecting all messages with > > html = plaintext and < in it). > "Be liberal in what to expect, be strict in what to send". > Don't start rejecting messages based on html. what if I send a plaintext > message with "you need to use the tag for that"...... I do reject messages that claim that text/plain == text/html when they obviously can't as they're clearly broken and cannot be assigned a well-defined meaning. And while I'd like to be more literal in what I accept, it wouldn't do anything to solve the problem of Pitchin's (and Trillian's) broken OTR implementation - if I can't reach anyone with arguments (nobody has yet said anything insightful about it from the libOTR or Pitchin people), I just have to make sure it pops up as their problem, or they'll just ignore it. So let me ask you: will you clarify the OTR spec to make sure it won't pack encrypted HTML into a plain text field and fix the Pitchin OTR plugin accordingly, OR will you continue to ignore (or argue away) the problem? PS. Please respect the Mail-Followup-To:. I happen to read the mailing lists that I write to, thank you. -- "See, free nations are peaceful nations. Free nations don't attack each other. Free nations don't develop weapons of mass destruction." - George W. Bush, Milwaukee, Wis., Oct. 3, 2003 From bdm@fenrir.org.uk Mon May 12 19:50:43 2008 From: bdm@fenrir.org.uk (Brian Morrison) Date: Mon, 12 May 2008 19:50:43 +0100 Subject: [otr-users] Pidgin plugin sends and parses HTML In-Reply-To: <20080512133538.GC5688@msgids.ruediger-kuhlmann.de> References: <20080511172542.181da3f6@webkeks.org> <20080511154815.GA5693@msgids.ruediger-kuhlmann.de> <20080511180406.538e0610@webkeks.org> <20080511163037.GB5693@msgids.ruediger-kuhlmann.de> <96e269140805112020k6ea60e9jaa2a0814cee3ca55@mail.gmail.com> <20080512121737.GA5688@msgids.ruediger-kuhlmann.de> <20080512143149.46c0484e@webkeks.org> <20080512133538.GC5688@msgids.ruediger-kuhlmann.de> Message-ID: <20080512195043.3c9d4958@peterson.fenrir.org.uk> On Mon, 12 May 2008 15:35:38 +0200 Rüdiger Kuhlmann wrote: > Well, it was a try at getting the Pitchin people also on board. I'm astonished that you're lecturing the developers about the treatment of (spit!) HTML when you can't even be bothered to write Pidgin correctly. Frankly, I care not a single whit what happens with HTML, and I don't see why anyone should put any effort into its handling until everything else works properly. -- Brian Morrison bdm at fenrir dot org dot uk "Arguing with an engineer is like wrestling with a pig in the mud; after a while you realize you are muddy and the pig is enjoying it." GnuPG key ID DE32E5C5 - http://wwwkeys.uk.pgp.net/pgpnet/wwwkeys.html From mail@scottellis.com.au Tue May 13 00:42:42 2008 From: mail@scottellis.com.au (Scott Ellis) Date: Tue, 13 May 2008 09:42:42 +1000 Subject: [otr-users] Pidgin plugin sends and parses HTML In-Reply-To: <20080512182013.GE5688@msgids.ruediger-kuhlmann.de> References: <20080511172542.181da3f6@webkeks.org> <20080511154815.GA5693@msgids.ruediger-kuhlmann.de> <20080511180406.538e0610@webkeks.org> <20080511163037.GB5693@msgids.ruediger-kuhlmann.de> <96e269140805112020k6ea60e9jaa2a0814cee3ca55@mail.gmail.com> <20080512121737.GA5688@msgids.ruediger-kuhlmann.de> <20080512143149.46c0484e@webkeks.org> <20080512133538.GC5688@msgids.ruediger-kuhlmann.de> <20080512182013.GE5688@msgids.ruediger-kuhlmann.de> Message-ID: <96e269140805121642n68805906qf06d1a274e780eef@mail.gmail.com> ------=_Part_4702_12430794.1210635762590 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline > PS. Please respect the Mail-Followup-To:. I happen to read the > mailing lists that I write to, thank you. > Sorry - sender's addy and list addy both show in the 'reply-to' field in emails from this list, and gmail respects that. Not sure if it's a list config problem - it is annoying. ------=_Part_4702_12430794.1210635762590 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline
PS. Please respect the Mail-Followup-To:. I happen to read the
mailing lists that I write to, thank you.

Sorry - sender's addy and list addy both show in the 'reply-to' field in emails from this list, and gmail respects that. Not sure if it's a list config problem - it is annoying.
------=_Part_4702_12430794.1210635762590-- From mail@scottellis.com.au Tue May 13 00:57:36 2008 From: mail@scottellis.com.au (Scott Ellis) Date: Tue, 13 May 2008 09:57:36 +1000 Subject: [otr-users] Pidgin plugin sends and parses HTML In-Reply-To: <20080512195043.3c9d4958@peterson.fenrir.org.uk> References: <20080511172542.181da3f6@webkeks.org> <20080511154815.GA5693@msgids.ruediger-kuhlmann.de> <20080511180406.538e0610@webkeks.org> <20080511163037.GB5693@msgids.ruediger-kuhlmann.de> <96e269140805112020k6ea60e9jaa2a0814cee3ca55@mail.gmail.com> <20080512121737.GA5688@msgids.ruediger-kuhlmann.de> <20080512143149.46c0484e@webkeks.org> <20080512133538.GC5688@msgids.ruediger-kuhlmann.de> <20080512195043.3c9d4958@peterson.fenrir.org.uk> Message-ID: <96e269140805121657k5de257br794e450ff5ef55fe@mail.gmail.com> ------=_Part_4765_31504868.1210636656428 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline > I'm astonished that you're lecturing the developers about the treatment > of (spit!) HTML when you can't even be bothered to write Pidgin > correctly. > It's called a 'pun'. > > Frankly, I care not a single whit what happens with HTML, and I don't > see why anyone should put any effort into its handling until everything > else works properly. Complaints about HTML handling are easily the most common problem reported by users of my OTR plugin - even though it does follow everyone's interpretation of the spec depending on the other plugins in use. If you're using a messenger that handles HTML natively then you may well not care - it won't affect you. But there are a lot of people out there whom it does affect, and in many ways this is the single biggest problem with using and supporting the OTR library. What is this 'everything else' that you're referring to? The other serious problem in my mind is the need for a 'i'm going offline now' message, another feature of the OTR protocol - as I mentioned earlier this just isn't possible with Miranda's plugin API, and there are a bunch of other reasons why it's a very bad idea...but that's another story ------=_Part_4765_31504868.1210636656428 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline
I'm astonished that you're lecturing the developers about the treatment
of (spit!) HTML when you can't even be bothered to write Pidgin
correctly.
It's called a 'pun'.

Frankly, I care not a single whit what happens with HTML, and I don't
see why anyone should put any effort into its handling until everything
else works properly.
 
Complaints about HTML handling are easily the most common problem reported by users of my OTR plugin - even though it does follow everyone's interpretation of the spec depending on the other plugins in use. If you're using a messenger that handles HTML natively then you may well not care - it won't affect you. But there are a lot of people out there whom it does affect, and in many ways this is the single biggest problem with using and supporting the OTR library.

What is this 'everything else' that you're referring to? The other serious problem in my mind is the need for a 'i'm going offline now' message, another feature of the OTR protocol - as I mentioned earlier this just isn't possible with Miranda's plugin API, and there are a bunch of other reasons why it's a very bad idea...but that's another story
------=_Part_4765_31504868.1210636656428-- From ian@cypherpunks.ca Tue May 13 13:10:05 2008 From: ian@cypherpunks.ca (Ian Goldberg) Date: Tue, 13 May 2008 08:10:05 -0400 Subject: [otr-users] Pidgin plugin sends and parses HTML In-Reply-To: <96e269140805120801s5aa23cc9p37c200bedb59ba95@mail.gmail.com> References: <20080511172542.181da3f6@webkeks.org> <20080511154815.GA5693@msgids.ruediger-kuhlmann.de> <20080511180406.538e0610@webkeks.org> <20080511163037.GB5693@msgids.ruediger-kuhlmann.de> <96e269140805112020k6ea60e9jaa2a0814cee3ca55@mail.gmail.com> <20080512121737.GA5688@msgids.ruediger-kuhlmann.de> <96e269140805120801s5aa23cc9p37c200bedb59ba95@mail.gmail.com> Message-ID: <20080513121005.GA7120@thunk.cs.uwaterloo.ca> On Tue, May 13, 2008 at 01:01:55AM +1000, Scott Ellis wrote: > > > > Uhm. I can only find one place where it mentiones HTML at all. And while > > it > > mentions that it may contain markup, it still doesn't qualify as allowing > > to > > put HTML into a place where only text/plain is allowed. Of course the text > > to encrypt may contain HTML, if an HTML message is about to be sent. Just > > as > > it may contain rtf, M$ .doc or any other markup if that is what is to be > > sent. But the data type of the data to be encrypted can only be determined > > by the underlying protocol, otherwise an extensive chapter on integration > > would HAVE to be part of the spec. It isn't. > > > The actual text transferred over the underlying protocol is made up of > plaintext chars - and as such none of the rules of the underlying protocol > are being broken. Even jabber XEPs cannot lay claim to the *meaning* of > plaintext within messages - just as you and a friend are not prevented from > using some code language you make up yourselves over jabber. Under this > interpretation the unencrpyted messages of OTR conversations have nothing to > do with the transport protocol. The phrase that was used by the developers > in my earlier conversations on this topic was 'higher level protocol'. It's > ugly and inconvenient to most of us, but it does make sense from a certain > point of view. > > It claims that using libOTR is > > as simple as replacing the plain text with the output of the function. > > > You're very right there - in most cases it doesn't perform 'as advertised'. > But it does work that way for a lot of clients - almost anything Qt or Java > based, for example. > > Can I suggest this discussion continue on the dev mailing list though? Agreed. I'll start a thread over there. - Ian From gmaxwell@gmail.com Sat May 17 05:20:05 2008 From: gmaxwell@gmail.com (Gregory Maxwell) Date: Sat, 17 May 2008 00:20:05 -0400 Subject: [OTR-users] Debian OpenSSL weak PRNG - OTR vulnerable? Message-ID: Some sort of statement should probably be made about the security of user identities with respect to the recently uncovered issue with Debian's patches to OpenSSL. From esurnir@gmail.com Sat May 17 05:27:02 2008 From: esurnir@gmail.com (Jean-Baptiste Zeller) Date: Sat, 17 May 2008 00:27:02 -0400 Subject: [OTR-users] Debian OpenSSL weak PRNG - OTR vulnerable? In-Reply-To: References: Message-ID: <482E5E96.2040004@gmail.com> This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig598161E74FD8EECA474FAB6B Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Gregory Maxwell wrote: > Some sort of statement should probably be made about the security of > user identities with respect to the recently uncovered issue with > Debian's patches to OpenSSL. > _______________________________________________ > OTR-users mailing list > OTR-users@lists.cypherpunks.ca > http://lists.cypherpunks.ca/mailman/listinfo/otr-users OTR don't use a single line of code from OpenSSL, the prng used is based = on the libgcrypt library, which isn't concerned as far as I know. So I guess we can sleep well now that it's covered. Jean-Baptiste Zeller --------------enig598161E74FD8EECA474FAB6B Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFILl6d5Zo8rPlqN+sRAt3CAJ489Ivfv/Fy51F9G0wvuhljHR0KNACgpMuK RxQlx3izdM8Flzzx+6EYvDU= =X0Dt -----END PGP SIGNATURE----- --------------enig598161E74FD8EECA474FAB6B-- From ananda.kumar.samaddar@googlemail.com Sat May 17 17:52:10 2008 From: ananda.kumar.samaddar@googlemail.com (Ananda Samaddar) Date: Sat, 17 May 2008 17:52:10 +0100 Subject: [OTR-users] OTR messaging is vulnerable to censorship Message-ID: <20080517175210.0caf7b1b@ananda-dell> Hi, all Apologies if this has already been discussed, I've googled this and the mailing list archives do not appear to be searchable. I'm no security or networking expert but consider myself to be a reasonably competent Debian user. Out of curiosity I ran Wireshark to do some traffic logging whilst engaged in an OTR chat session. From this I discovered that all OTR messages begin with the string '?OTR:' (without quotes). Surely this means that IM providers could simply block OTR messages by blocking all messages that contain the string '?OTR:'. There is a precedent to potential blocking already established. MSN / Windows Live messaging already blocks certain urls on their network particularly ones containing php links. There is also speculation that they might be blocking youtube links. This is of concern to me as I use OTR to talk to friends in the PRC, and it's well known that they heavily censor internet use in that country. If anyone can point me to a thread where this has already been discussed then please do. regards, Ananda Samaddar From esurnir@gmail.com Sat May 17 18:19:12 2008 From: esurnir@gmail.com (Esurnir) Date: Sat, 17 May 2008 13:19:12 -0400 Subject: [OTR-users] OTR messaging is vulnerable to censorship In-Reply-To: <20080517175210.0caf7b1b@ananda-dell> References: <20080517175210.0caf7b1b@ananda-dell> Message-ID: <78ce815d0805171019m4e9a2358p2610bae879476ed9@mail.gmail.com> ------=_Part_1015_15122430.1211044752583 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Suppressing ?OTR: bring some problem, namely identify which message is a plaintext and which is an otr message (example of such case, where a plaintext could arrive when they are the least expected would be if one of the client crash and the guy in question log back in). To evade such possible censorship problem would be to make the traffic indistinguishable from normal message. Obfuscating it. Now the problem is to keep the condition the deniability and malleability of OTR while obfuscating it, sounds difficult. If we reveal an obfuscating encryption key to keep it, the whole problem would be when to reveal it, cause after being revealed an automated could then reveal that all the past message have been OTR message and block further ones. On Sat, May 17, 2008 at 12:52 PM, Ananda Samaddar < ananda.kumar.samaddar@googlemail.com> wrote: > Hi, all > > Apologies if this has already been discussed, I've googled this and the > mailing list archives do not appear to be searchable. > > I'm no security or networking expert but consider myself to be a > reasonably competent Debian user. Out of curiosity I ran Wireshark to > do some traffic logging whilst engaged in an OTR chat session. From > this I discovered that all OTR messages begin with the string > '?OTR:' (without quotes). > > Surely this means that IM providers could simply block OTR messages by > blocking all messages that contain the string '?OTR:'. There is a > precedent to potential blocking already established. MSN / Windows > Live messaging already blocks certain urls on their network > particularly ones containing php links. There is also speculation that > they might be blocking youtube links. > > This is of concern to me as I use OTR to talk to friends in the PRC, > and it's well known that they heavily censor internet use in that > country. > > If anyone can point me to a thread where this has already been > discussed then please do. > > regards, > > Ananda Samaddar > > _______________________________________________ > OTR-users mailing list > OTR-users@lists.cypherpunks.ca > http://lists.cypherpunks.ca/mailman/listinfo/otr-users > -- Jean-Baptiste Zeller GPG Keyid 0xF96A37EB ------=_Part_1015_15122430.1211044752583 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Suppressing ?OTR: bring some problem, namely identify which message is a plaintext and which is an otr message (example of such case, where a plaintext could arrive when they are the least expected would be if one of the client crash and the guy in question log back in).

To evade such possible censorship problem would be to make the traffic indistinguishable from normal message. Obfuscating it. Now the problem is to keep the condition the deniability and malleability of OTR while obfuscating it, sounds difficult. If we reveal an obfuscating encryption key to keep it, the whole problem would be when to reveal it, cause after being revealed an automated could then reveal that all the past message have been OTR message and block further ones.

On Sat, May 17, 2008 at 12:52 PM, Ananda Samaddar <ananda.kumar.samaddar@googlemail.com> wrote:
Hi, all

Apologies if this has already been discussed, I've googled this and the
mailing list archives do not appear to be searchable.

I'm no security or networking expert but consider myself to be a
reasonably competent Debian user.  Out of curiosity I ran Wireshark to
do some traffic logging whilst engaged in an OTR chat session.  From
this I discovered that all OTR messages begin with the string
'?OTR:' (without quotes).

Surely this means that IM providers could simply block OTR messages by
blocking all messages that contain the string '?OTR:'.  There is a
precedent to potential blocking already established.  MSN / Windows
Live messaging already blocks certain urls on their network
particularly ones containing php links.  There is also speculation that
they might be blocking youtube links.

This is of concern to me as I use OTR to talk to friends in the PRC,
and it's well known that they heavily censor internet use in that
country.

If anyone can point me to a thread where this has already been
discussed then please do.

regards,

Ananda Samaddar

_______________________________________________
OTR-users mailing list
OTR-users@lists.cypherpunks.ca
http://lists.cypherpunks.ca/mailman/listinfo/otr-users



--
Jean-Baptiste Zeller
GPG Keyid 0xF96A37EB ------=_Part_1015_15122430.1211044752583-- From chazefroy@gmail.com Sat May 17 21:42:20 2008 From: chazefroy@gmail.com (ChazeFroy) Date: Sat, 17 May 2008 16:42:20 -0400 Subject: [OTR-users] OTR support for bitlbee Message-ID: <8ba68aae0805171342m3679df04se06786f5c0bf1c6b@mail.gmail.com> A couple of months ago, "Pesco" published support for OTR using the bitlbee client. This is quite significant as it is the first multi-protocol command-line client to support OTR. This also allows users to simply "screen" their IM on a shell somewhere without needing all of the GUI stuff required by previous clients that supported OTR (or the GUI-only OTR proxy). Furthermore, this could be a good starting point for those wishing to implement OTR support for other CLI clients, such as Finch. Here is the announcement: http://bugs.bitlbee.org/bitlbee/ticket/115 To obtain the code, you must have "bazaar" installed (www.bazaar-ng.org). It also requires libotr 3.1. To download it, simply run: bzr checkout http://khjk.org/~pesco/bitlbee-otr/ I have not seen an ETA on when OTR support will be included in the next release of bitlbee, but hopefully it will be soon. Can the OTR admins link this news to their website so others will know about it? From js-otrim@webkeks.org Sat May 17 22:00:09 2008 From: js-otrim@webkeks.org (Jonathan Schleifer) Date: Sat, 17 May 2008 23:00:09 +0200 Subject: [OTR-users] OTR support for bitlbee In-Reply-To: <8ba68aae0805171342m3679df04se06786f5c0bf1c6b@mail.gmail.com> References: <8ba68aae0805171342m3679df04se06786f5c0bf1c6b@mail.gmail.com> Message-ID: <20080517230009.7aa93fc5@webkeks.org> --Sig_/d4fYMF+i8pj.T3uijX7eDqL Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable ChazeFroy wrote: > This is quite significant as it is the first multi-protocol > command-line client to support OTR. This also allows users to simply > "screen" their IM on a shell somewhere without needing all of the GUI > stuff required by previous clients that supported OTR (or the > GUI-only OTR proxy). Wrong. centericq already supports it and it's, though the name says otherwise, multi IM. --=20 Jonathan --Sig_/d4fYMF+i8pj.T3uijX7eDqL Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- iQIcBAEBAwAGBQJIL0deAAoJEMtRg9d5cXHkfTEQAJCOtfLfJv7F8wxdhT8bZzx2 uSkh4zB3osRYwuT7pNN/MCsjSYkvkKmsJT/vOkrn0w3a3zJ+wN5JHBSSWpGFPMUA Vo0wuu4Nhuc847C0ZribBPhTuO3GtXOJpluZOfFGUcmtS/ps2TbafbwYbe8X/fcg L2UtKdKkv3EP36XOOqoc+6FafDYMFm0lpqtbXRcAsK4eHDUItspP4R0K2jLizNHu 4gJ4/08qFKLIsIfIkziFgxGQUFqtQoF3cIw7RTPToNhgmEzkZG/URSYnb+UbWqQn 2oK766CCLzrUwq7gzetK/IRDYpTYdn36x96IdUwXbjkm0OBOgpSvPdpBx+w78DTv rkD0ec2PWb84e3OD0cNH7Bpr60PgEYZyZMGxlA66WShznSLiUfGSRW1MP150El1a B6ydQmWRH/zuHZ/HPqn46mTSjNtdEe4qwOjuhZc5Gi2QwiffW2CetUwDogevTzEp TZPKwYUzDucnW0wktOi1+mm/u/cmGjuqFlgwxLm9PWiAV3K5cG5cq0OP8pDfVE14 25w6JL227QvJO2XWXMZF8hr6rP1rT+FmUgzWZDHPR2785HFpD9R/xg6x1NW78OqM W2mKtC/F+DYFWioIuSozM7Gz80CgvCSB0Vc/CP2vXxD4UD5uVwOaipImktauEMDZ PWa3HyLwZyeT2X593BBw =TQVU -----END PGP SIGNATURE----- --Sig_/d4fYMF+i8pj.T3uijX7eDqL-- From chazefroy@gmail.com Sat May 17 23:35:30 2008 From: chazefroy@gmail.com (ChazeFroy) Date: Sat, 17 May 2008 18:35:30 -0400 Subject: [OTR-users] OTR support for bitlbee In-Reply-To: <20080517230009.7aa93fc5@webkeks.org> References: <8ba68aae0805171342m3679df04se06786f5c0bf1c6b@mail.gmail.com> <20080517230009.7aa93fc5@webkeks.org> Message-ID: <8ba68aae0805171535k1a7b1938v1d215a2824450f0@mail.gmail.com> On Sat, May 17, 2008 at 5:00 PM, Jonathan Schleifer wrote: > > Wrong. centericq already supports it and it's, though the name says > otherwise, multi IM. Ah, good to know. I didn't see it on OTR's website, and nothing is mentioned on centericq's website at http://thekonst.net/en/centericq. Where is more information about it? Did you mean mICQ/climm? From js-otrim@webkeks.org Sat May 17 23:42:51 2008 From: js-otrim@webkeks.org (Jonathan Schleifer) Date: Sun, 18 May 2008 00:42:51 +0200 Subject: [OTR-users] OTR support for bitlbee In-Reply-To: <8ba68aae0805171535k1a7b1938v1d215a2824450f0@mail.gmail.com> References: <8ba68aae0805171342m3679df04se06786f5c0bf1c6b@mail.gmail.com> <20080517230009.7aa93fc5@webkeks.org> <8ba68aae0805171535k1a7b1938v1d215a2824450f0@mail.gmail.com> Message-ID: <20080518004251.090b4038@webkeks.org> --Sig_/M6VtCDFSBCoys_6UOaYVmKt Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable ChazeFroy wrote: > I didn't see it on OTR's website, and nothing is mentioned on > centericq's website at http://thekonst.net/en/centericq. Where is > more information about it? Did you mean mICQ/climm? It's for example listed on Wikipedia. And no, I mean centericq. --=20 Jonathan --Sig_/M6VtCDFSBCoys_6UOaYVmKt Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- iQIcBAEBAwAGBQJIL19uAAoJEMtRg9d5cXHk+2sP/0GcEOevwynePHCdRDwL6BRy 9LeDgYV+TYCWrebJ9RlZP1Co73nQuMnFaE/d+EL6Lnk7oPaKxD39Yxuoul3EzpVs +Aigz6dJ0+xh7QsFMMLqX6V4oOnPBDMbXtFcYOE/AlzFyZKfib43HJbzTE/4xBvK X8Q1bIliuIfciWDUV4W2J5nRzpG1olV7evfuHgCofkmR8TS1iGTnOP/hNIfud2FQ 8Shfm7skIPI8FQnp/+B6X0JMNdHNPTQO2un3Cp9+LAemT3Qk4eYZkZvExxF9+TqL TUR6MJrT6mUkjxJ7dOtRmJnjz8VGRzuWKvA9UkSZXE1ItnuacMWlJNQrOzGudNcf jwO0E73Rc22REbUnTMglWRdzOOejUj89dWyS4i8ooR3EOXBjmeEE6VU3PWK2c+58 E/B6wovFHVS7wqDneC7KYBfKJ2vg9dopiQyBkO0QmbiG+PggjvCXChMQMXXhLwWS kCoDguAP3Rbn4FTEYPTCeJhHbjNwjhmz2ip6lcIYcvKxGC0Bn3OY+QAU7PVp1pAN t3c8t7Pv52QwnD9ZTit0VMuxGTxWUR6HXebmN1ids4MzA9ycnGA2F+w2oDVQdIbM zzKsnCoawgMs+8xErtgKuAjr8PY2Jzi84mu27nGzrBu4dq45rdRPq2V47b0RWXIX wB6NPzrB8s7GbIITMB4m =9WCU -----END PGP SIGNATURE----- --Sig_/M6VtCDFSBCoys_6UOaYVmKt-- From chazefroy@gmail.com Sun May 18 02:23:49 2008 From: chazefroy@gmail.com (ChazeFroy) Date: Sat, 17 May 2008 21:23:49 -0400 Subject: [OTR-users] OTR support for bitlbee In-Reply-To: <20080518004251.090b4038@webkeks.org> References: <8ba68aae0805171342m3679df04se06786f5c0bf1c6b@mail.gmail.com> <20080517230009.7aa93fc5@webkeks.org> <8ba68aae0805171535k1a7b1938v1d215a2824450f0@mail.gmail.com> <20080518004251.090b4038@webkeks.org> Message-ID: <8ba68aae0805171823xb361cdl59f61928637b9972@mail.gmail.com> On Sat, May 17, 2008 at 6:42 PM, Jonathan Schleifer wrote: > > It's for example listed on Wikipedia. And no, I mean centericq. Centericq does not have it, but Centerim (http://www.centerim.org) does. According to its changelog, it looks like Centerim added OTR support for Jabber in August 2007. Does it work with Oscar, Yahoo, MSN, etc? Could somebody update the OTR webpage to list both Centerim and Bitlbee as supporting OTR now? From perrin@apotheon.com Sun May 18 18:46:00 2008 From: perrin@apotheon.com (Chad Perrin) Date: Sun, 18 May 2008 11:46:00 -0600 Subject: [OTR-users] OTR support for bitlbee In-Reply-To: <8ba68aae0805171823xb361cdl59f61928637b9972@mail.gmail.com> References: <8ba68aae0805171342m3679df04se06786f5c0bf1c6b@mail.gmail.com> <20080517230009.7aa93fc5@webkeks.org> <8ba68aae0805171535k1a7b1938v1d215a2824450f0@mail.gmail.com> <20080518004251.090b4038@webkeks.org> <8ba68aae0805171823xb361cdl59f61928637b9972@mail.gmail.com> Message-ID: <20080518174600.GA96475@demeter.hydra> --5mCyUwZo2JvN/JJP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, May 17, 2008 at 09:23:49PM -0400, ChazeFroy wrote: > On Sat, May 17, 2008 at 6:42 PM, Jonathan Schleifer > wrote: > > > > It's for example listed on Wikipedia. And no, I mean centericq. >=20 > Centericq does not have it, but Centerim (http://www.centerim.org) > does. According to its changelog, it looks like Centerim added OTR > support for Jabber in August 2007. Does it work with Oscar, Yahoo, > MSN, etc? >=20 > Could somebody update the OTR webpage to list both Centerim and > Bitlbee as supporting OTR now? I looked into this a while ago, talked to some of the CenterIM people, because I like CenterIM's interface (and that of CenterICQ, which I had discovered first back in 2003). Apparently, the OTR support was only for one protocol, and was less than perfectly stable because nobody's supporting that functionality now. That, at least, is the impression I got from speaking to several of the CenterIM folks in IRC last year. If there's more/new information suggesting that it works with more protocols, I'd love to hear it. I, unfortunately, don't have the time and familiarity right now to improve OTR support in CenterIM myself, but I'd love to see that support improve so I could finally ditch Pidgin. I recall choosing to forego Bitlbee for some reason, but don't remember why. I guess I'll have another look at it and see if it's something I want to use now. --=20 Chad Perrin [ content licensed PDL: http://pdl.apotheon.org ] Leon Festinger: "A man with a conviction is a hard man to change. Tell him you disagree and he turns away. Show him facts and figures and he questions your sources. Appeal to logic and he fails to see your point." --5mCyUwZo2JvN/JJP Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEUEARECAAYFAkgwa1gACgkQ9mn/Pj01uKUazgCg6HIxpFyW/zJ0EmFRLu2Ia9ca a4gAmJ63cPmF4ZOb8Hi0nx1xLJC/7ok= =36C1 -----END PGP SIGNATURE----- --5mCyUwZo2JvN/JJP-- From william@escapevelocitypub.com Sun May 18 22:44:16 2008 From: william@escapevelocitypub.com (William) Date: Sun, 18 May 2008 17:44:16 -0400 Subject: [OTR-users] pidgin-otr install errors Message-ID: <4830A330.10502@escapevelocitypub.com> Hello, I'm currently trying to re-install pidgin-otr-3.1.0 on Mandriva2006. I had it working once but had to do a OS re-install Running Pidgin 2.2.2 I run: ./configure --prefix=/usr and get the following error: checking for otrl_message_receiving in -lotr... yes checking for pkg-config... /usr/bin/pkg-config checking pkg-config is at least version 0.9.0... yes checking for EXTRA... configure: error: Package requirements (glib-2.0 >= 2.6 gtk+-2.0 >= 2.6 pidgin >= 2.0 purple >= 2.0) were not met: Package pidgin was not found in the pkg-config search path. Perhaps you should add the directory containing `pidgin.pc' to the PKG_CONFIG_PATH environment variable No package 'pidgin' found Consider adjusting the PKG_CONFIG_PATH environment variable if you installed software in a non-standard prefix. Alternatively, you may set the environment variables EXTRA_CFLAGS and EXTRA_LIBS to avoid the need to call pkg-config. See the pkg-config man page for more details. From js-otrim@webkeks.org Mon May 19 11:12:39 2008 From: js-otrim@webkeks.org (Jonathan Schleifer) Date: Mon, 19 May 2008 12:12:39 +0200 Subject: [OTR-users] pidgin-otr install errors In-Reply-To: <4830A330.10502@escapevelocitypub.com> References: <4830A330.10502@escapevelocitypub.com> Message-ID: <20080519121239.0521eaea@webkeks.org> --Sig_/OE2vFGHfWeluP85AeFGddRv Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable William wrote: > Running Pidgin 2.2.2 Why are you using such an old version? > checking for EXTRA... configure: error: Package requirements > (glib-2.0=20 > >=3D 2.6 gtk+-2.0 >=3D 2.6 pidgin >=3D 2.0 purple >=3D 2.0) were not met: >=20 > Package pidgin was not found in the pkg-config search path. This tells you just what I told you in the first line of this mail: Your pidgin version is way too old. --=20 Jonathan --Sig_/OE2vFGHfWeluP85AeFGddRv Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- iQIcBAEBAwAGBQJIMVKbAAoJEMtRg9d5cXHknyYP/AlTdzp2zpK/yDD1hxVT3E7C 8SCqj+HN2bRISG2R6ENlqWYxVjg0fm79l/GLIqh9UfgmWmA8E5TYlQWwuzc7UKRL Kkp3N3wIWu6P0MH1mCC8PexWfCZHV9aqj2NOvgIH7tmbq/ohRFTOtVe7rQ0Pl3vU bCk4S1BTVArXzs6YFUI6busHQR2+BEk+P+DZsK8ltfuwzA3zKX4y3641ua4MS5xG B9pZyp9QrfYW1Ldg86Vo5psm6V+V0amNfq/NHg90gaSfjUQiUM62qvG1pxd6DrkJ DQUwubp9gnYv8rFa6UCHZB+Dr+tq52l0/CO7M6Pb13sNYaqmBQH/nF0j/r0C/TAa d7COtS03pzP74uUhFdUrWHn5RAbvr7JzMuMDYJoCstxFUikcirpJnCJsTFDpSyjs BAxGYMKT/+02zJkn1KbtfsOZi3QWW9AQHPtrzFRHuBNpy8ljX85nvJ+tmN9fOjoF QG/IHtLpubs4P5FmV8bThGPYoATHpbpyb1hEWzg4KcMbZpXnrsy+lUTBq05XHBPV FJX24FCNIpWEQKrXNrwSTMcNSNkf+mZNitxBpY7fIUTAiB70SDb57yqtfUqUy4ol 1j0HKN6VSfeAKcA1qt6uDBozwWvjvxTzaSx7fLJ4PD2FiM0gBqIfSvl9q6UK7cHD 1xlrevpTQQXxJ60RMczu =0BTO -----END PGP SIGNATURE----- --Sig_/OE2vFGHfWeluP85AeFGddRv-- From chazefroy@gmail.com Mon May 19 12:54:08 2008 From: chazefroy@gmail.com (ChazeFroy) Date: Mon, 19 May 2008 07:54:08 -0400 Subject: [OTR-users] OTR support for bitlbee In-Reply-To: <20080518174600.GA96475@demeter.hydra> References: <8ba68aae0805171342m3679df04se06786f5c0bf1c6b@mail.gmail.com> <20080517230009.7aa93fc5@webkeks.org> <8ba68aae0805171535k1a7b1938v1d215a2824450f0@mail.gmail.com> <20080518004251.090b4038@webkeks.org> <8ba68aae0805171823xb361cdl59f61928637b9972@mail.gmail.com> <20080518174600.GA96475@demeter.hydra> Message-ID: <8ba68aae0805190454x67fd5d5ex4261897942c7ce4d@mail.gmail.com> On Sun, May 18, 2008 at 1:46 PM, Chad Perrin wrote: > > I looked into this a while ago, talked to some of the CenterIM people, > because I like CenterIM's interface (and that of CenterICQ, which I had > discovered first back in 2003). Apparently, the OTR support was only for > one protocol, and was less than perfectly stable because nobody's > supporting that functionality now. That, at least, is the impression I > got from speaking to several of the CenterIM folks in IRC last year. That's what I've read from CenterIM's website, too. Bitlbee seems to support more than one protocol, which is a good thing. I used Bitlbee with OTR for about 24 hours and it seemed fine 99% of the time. However, it seemed that when it got an unexpected OTR message, it would disconnect completely from the network. If it ran into this issue during the first session after you initially set up your account (without quitting or bouncing it), it would even forget your account details (username, network, everything). I have not yet filed a bug report because I cannot reliably reproduce it. Hopefully this random bug will get fixed once the OTR code makes its way into the official distribution. From samslists@gmail.com Mon May 19 23:48:35 2008 From: samslists@gmail.com (Sam's Lists) Date: Mon, 19 May 2008 15:48:35 -0700 Subject: [OTR-users] Openssl fiasco and otr... Message-ID: <558124520805191548p5aec305x198513a76fb43355@mail.gmail.com> ------=_Part_15815_31575264.1211237315784 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi... I'm 99% positive the answer is that otr in no relies on any of the openssl infrastructure. But given the recent Debian/Ubuntu fiasco I just want to double check. Can someone confirm that I have nothing to worry about? Thanks ------=_Part_15815_31575264.1211237315784 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi...

I'm 99% positive the answer is that otr in no relies on any of the openssl infrastructure.  But given the recent Debian/Ubuntu fiasco I just want to double check.  Can someone confirm that I have nothing to worry about?

Thanks
------=_Part_15815_31575264.1211237315784-- From esurnir@gmail.com Mon May 19 23:57:00 2008 From: esurnir@gmail.com (Jean-Baptiste Zeller) Date: Mon, 19 May 2008 18:57:00 -0400 Subject: [OTR-users] Openssl fiasco and otr... In-Reply-To: <558124520805191548p5aec305x198513a76fb43355@mail.gmail.com> References: <558124520805191548p5aec305x198513a76fb43355@mail.gmail.com> Message-ID: <483205BC.2000705@gmail.com> This is a cryptographically signed message in MIME format. --------------ms070807000903060009020402 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sam's Lists wrote: > Hi... > > I'm 99% positive the answer is that otr in no relies on any of the > openssl infrastructure. But given the recent Debian/Ubuntu fiasco I > just want to double check. Can someone confirm that I have nothing to > worry about? > > Thanks OTR don't use a single line of code from OpenSSL, the prng used is the one in the libgcrypt library, which isn't concerned as far as I know. So I guess we can sleep well now that it's covered. Jean-Baptiste Zeller --------------ms070807000903060009020402 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJSTCC Av8wggJooAMCAQICEEiMH5xSXNHW0I/oJcVZzEYwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDQyMTIzNDIzN1oX DTA5MDQyMTIzNDIzN1owQzEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEgMB4G CSqGSIb3DQEJARYRZXN1cm5pckBnbWFpbC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQCoVf0wm7v9SCmAeICUXVfr5bUX9fgvfxUzsWvu7JXw2nAjbhNpSAOlM55hwsYX eetnLLTbtkxz2/fM/Bx21yW/7K1F2gvaT7WV1VhpdZMNgdvRwST7uSTRT4ZZV+yray1ou2BJ SN5TdaHC+wxViXLQ5Di4vLfr62tYT5/PQtoC3s6F36AEzqbONM8/K3lWl9z1XvsSZIxeiLV2 nkkWR3/ax3fGSn0zy2Vdsb88Y9H1FN/s/+u8SaIRr5ogj7IM3fCWsx6MMMN8pNJeobER3/zH J/lc2mvNaIDanMhFb5DXoMSRlWTueseXAoTl2kJgyuH21hLUijkf88grQE8S/4Y3AgMBAAGj UTBPMA4GA1UdDwEB/wQEAwID+DARBglghkgBhvhCAQEEBAMCBaAwHAYDVR0RBBUwE4ERZXN1 cm5pckBnbWFpbC5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQCgan9WRY98 sy9y6Eat2HjayMJVdOGV6Gb5RfEd4sT4peHwAddiXaxtt66U6lBcejAC8sNiR3tVUZzIDELn nK31kleh2cLOsPGgALt5mF0Mr2lhrrk9Ipzrm9WsK9Gbg5c5KIKxKTi58b3va2PTGMNaEepQ sk1zrJkOTgH2L7jFGDCCAv8wggJooAMCAQICEEiMH5xSXNHW0I/oJcVZzEYwDQYJKoZIhvcN AQEFBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkp IEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4X DTA4MDQyMTIzNDIzN1oXDTA5MDQyMTIzNDIzN1owQzEfMB0GA1UEAxMWVGhhd3RlIEZyZWVt YWlsIE1lbWJlcjEgMB4GCSqGSIb3DQEJARYRZXN1cm5pckBnbWFpbC5jb20wggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQCoVf0wm7v9SCmAeICUXVfr5bUX9fgvfxUzsWvu7JXw 2nAjbhNpSAOlM55hwsYXeetnLLTbtkxz2/fM/Bx21yW/7K1F2gvaT7WV1VhpdZMNgdvRwST7 uSTRT4ZZV+yray1ou2BJSN5TdaHC+wxViXLQ5Di4vLfr62tYT5/PQtoC3s6F36AEzqbONM8/ K3lWl9z1XvsSZIxeiLV2nkkWR3/ax3fGSn0zy2Vdsb88Y9H1FN/s/+u8SaIRr5ogj7IM3fCW sx6MMMN8pNJeobER3/zHJ/lc2mvNaIDanMhFb5DXoMSRlWTueseXAoTl2kJgyuH21hLUijkf 88grQE8S/4Y3AgMBAAGjUTBPMA4GA1UdDwEB/wQEAwID+DARBglghkgBhvhCAQEEBAMCBaAw HAYDVR0RBBUwE4ERZXN1cm5pckBnbWFpbC5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0B AQUFAAOBgQCgan9WRY98sy9y6Eat2HjayMJVdOGV6Gb5RfEd4sT4peHwAddiXaxtt66U6lBc ejAC8sNiR3tVUZzIDELnnK31kleh2cLOsPGgALt5mF0Mr2lhrrk9Ipzrm9WsK9Gbg5c5KIKx KTi58b3va2PTGMNaEepQsk1zrJkOTgH2L7jFGDCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcN AQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcT CUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRp ZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNv bTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYD VQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA xKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkV cI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUq VIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMG A1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZy ZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJp dmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIX oUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydx VyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggNkMIIDYAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWlu ZyBDQQIQSIwfnFJc0dbQj+glxVnMRjAJBgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wODA1MTkyMjU3MDBaMCMGCSqGSIb3DQEJBDEW BBQn54ke3FgFtkV3FRytV1LjMrdJYDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4G CCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB hQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElz c3VpbmcgQ0ECEEiMH5xSXNHW0I/oJcVZzEYwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYD VQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEEiMH5xSXNHW0I/oJcVZ zEYwDQYJKoZIhvcNAQEBBQAEggEAmhL5JaPTALXLPA2J3Nq2AH8hZm5pgi0eCiNtCx9yalAZ bgfCKVAYQQ0n8nUuyFgSxmV1QnYU5uOTf+xenVfc+xziEsmhzzBbdSZ9ETvop1kk2PRTHM9L 7jdS2Nrv08/XJ7Bf/MqsUxwnlJAdNm0VFy2Qcw3cJ03NKMT2OOwyed8+e8iN0dIuk7h/cJG4 ieXy1hzqgweUlBblMc7Asq8Crj1dCG+L5rfRlLWMw7DXckNyOWxLoUc7wWZ2ZarS6jIgwCAT zrNPNYMSrvbb51FonFBfXqfYfEXMPs6f1rh3cqmPo8Z9QVJr6ZRu+Zwz43FHcIjlLHPdZf5E BMEf3uLIkAAAAAAAAA== --------------ms070807000903060009020402-- From zythrix@gmail.com Tue May 20 08:30:31 2008 From: zythrix@gmail.com (Zythrix) Date: Tue, 20 May 2008 00:30:31 -0700 Subject: [OTR-users] OTR with PortableApps.com Pidgin Message-ID: <3869c3f00805200030m2855fc09l545a09f1a1f548b3@mail.gmail.com> ------=_Part_335_20552971.1211268631083 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Okay, I've had 100% success in getting this wonderful application to work with Pidgin, but quite often I find myself using the PortableApps.com version from my flash drive. With this version I cannot use the Pidgin-OTR installer (it doesn't find the installtion in the registry so I can't install) and I had my friend send me the files from his pidgin-otr directory, but that didn't work either. What I'm getting at is, have any of you gotten Pidgin-OTR to work on Pidgin portable or the PortableApps.com Pidgin? Thank you. ------=_Part_335_20552971.1211268631083 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Okay, I've had 100% success in getting this wonderful application to work with Pidgin, but quite often I find myself using the PortableApps.com version from my flash drive. With this version I cannot use the Pidgin-OTR installer (it doesn't find the installtion in the registry so I can't install) and I had my friend send me the files from his pidgin-otr directory, but that didn't work either. What I'm getting at is, have any of you gotten Pidgin-OTR to work on Pidgin portable or the PortableApps.com Pidgin?

Thank you.
------=_Part_335_20552971.1211268631083-- From roy@rant-central.com Tue May 20 11:10:21 2008 From: roy@rant-central.com (Roy M. Silvernail) Date: Tue, 20 May 2008 06:10:21 -0400 Subject: [OTR-users] OTR with PortableApps.com Pidgin In-Reply-To: <3869c3f00805200030m2855fc09l545a09f1a1f548b3@mail.gmail.com> References: <3869c3f00805200030m2855fc09l545a09f1a1f548b3@mail.gmail.com> Message-ID: <4832A38D.3070802@rant-central.com> Zythrix wrote: > Okay, I've had 100% success in getting this wonderful application to work > with Pidgin, but quite often I find myself using the PortableApps.com > version from my flash drive. With this version I cannot use the Pidgin-OTR > installer (it doesn't find the installtion in the registry so I can't > install) and I had my friend send me the files from his pidgin-otr > directory, but that didn't work either. What I'm getting at is, have any of > you gotten Pidgin-OTR to work on Pidgin portable or the PortableApps.com > Pidgin? Check out the OTR-Portable installer. http://sourceforge.net/project/showfiles.php?group_id=151265 -- Roy M. Silvernail is roy@rant-central.com, and you're not "It's just this little chromium switch, here." - TFT http://www.rant-central.com From ian@cypherpunks.ca Fri May 23 15:00:01 2008 From: ian@cypherpunks.ca (Ian Goldberg) Date: Fri, 23 May 2008 10:00:01 -0400 Subject: [OTR-users] pidgin-otr install errors In-Reply-To: <20080519121239.0521eaea@webkeks.org> References: <4830A330.10502@escapevelocitypub.com> <20080519121239.0521eaea@webkeks.org> Message-ID: <20080523140001.GL28889@thunk.cs.uwaterloo.ca> On Mon, May 19, 2008 at 12:12:39PM +0200, Jonathan Schleifer wrote: > William wrote: > > > Running Pidgin 2.2.2 > > Why are you using such an old version? > > > checking for EXTRA... configure: error: Package requirements > > (glib-2.0 > > >= 2.6 gtk+-2.0 >= 2.6 pidgin >= 2.0 purple >= 2.0) were not met: > > > > Package pidgin was not found in the pkg-config search path. > > This tells you just what I told you in the first line of this mail: > Your pidgin version is way too old. Huh? OTR works fine with pidgin >= 2.0, as the above line indicates. 2.2.2 should pose no problem. What's probably happening is that your OS reinstall failed to install the -dev (sometimes called -devel) version of the pidgin package. That package contains pidgin.pc, as well as the pidgin header files needed to compile pidgin plugins like pidgin-otr. - Ian From william@escapevelocitypub.com Fri May 23 16:41:21 2008 From: william@escapevelocitypub.com (William) Date: Fri, 23 May 2008 11:41:21 -0400 Subject: [OTR-users] pidgin-otr install errors In-Reply-To: <20080523140001.GL28889@thunk.cs.uwaterloo.ca> References: <4830A330.10502@escapevelocitypub.com> <20080519121239.0521eaea@webkeks.org> <20080523140001.GL28889@thunk.cs.uwaterloo.ca> Message-ID: <4836E5A1.9070904@escapevelocitypub.com> Hey Ian, Thanks for the suggestion. I finally got it though, and I'm using v 2.4.2 Sorry for the caps, but I just copied and pasted the below from the notes I'm saving for future reference. "export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig:$PKG_CONFIG_PATH BEFORE YOU RUN THE ./CONFIG STRING IN THE PIDGIN-OTR SOURCE DIRECTORY! THEN.......... YOU HAVE TO COPY ALL THE OTR FILES FROM /USR/LIB/PIDGIN TO /USR/LOCAL/LIB/PIDGIN TO GET THE PLUGIN TO SHOW UP IN THE PIDGIN TOOLS MENU!" Ian Goldberg wrote: > On Mon, May 19, 2008 at 12:12:39PM +0200, Jonathan Schleifer wrote: > >> William wrote: >> >> >>> Running Pidgin 2.2.2 >>> >> Why are you using such an old version? >> >> >>> checking for EXTRA... configure: error: Package requirements >>> (glib-2.0 >>> >= 2.6 gtk+-2.0 >= 2.6 pidgin >= 2.0 purple >= 2.0) were not met: >>> >>> Package pidgin was not found in the pkg-config search path. >>> >> This tells you just what I told you in the first line of this mail: >> Your pidgin version is way too old. >> > > Huh? OTR works fine with pidgin >= 2.0, as the above line indicates. > 2.2.2 should pose no problem. > > What's probably happening is that your OS reinstall failed to install > the -dev (sometimes called -devel) version of the pidgin package. > > That package contains pidgin.pc, as well as the pidgin header files > needed to compile pidgin plugins like pidgin-otr. > > - Ian > _______________________________________________ > OTR-users mailing list > OTR-users@lists.cypherpunks.ca > http://lists.cypherpunks.ca/mailman/listinfo/otr-users > > From mwirth@adobe.com Tue May 27 23:45:33 2008 From: mwirth@adobe.com (Mike Wirth) Date: Tue, 27 May 2008 15:45:33 -0700 Subject: [OTR-users] Using OTR clients for visually impaired users? Message-ID: > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3294747934_19460281 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Folks, I work with several visually impaired engineers here at Adobe Systems (on ways to make Acrobat PDF files more accessible to the blind, of course). W= e have an internal Jabber server, which is normally used for work-related IM traffic, and which is also available when offsite (over VPN). But of the known IM clients, the only one which is accessible to blind users (via screen reader software, e.g., JAWS on Windows) is AIM. One solution for us to communicate might be to use AOL IM accounts. But this exposes work-related traffic to the open Internet. Therefore, I=B9d lik= e to use OTR to encrypt the AIM traffic to and from the AIM server. Additional complications: * I=B9m typically running Adium on a Mac at my end which shouldn=B9t be an issu= e for OTR and which allows me to talk to people on the internal Jabber server= , as well as AOL IM, simultaneously. * Both I and the blind user may be remote, i.e., connected via VPN, which may complicate the proxy configuration. My questions: 1. Is there a Jabber client which is =B3accessible=B2 (i.e., usable via a scree= n reader)? If so, this would be the simplest solution. 2. If not, and we have to use AIM, what=B9s the appropriate OTR setup? Something like: ---------------..... {Internet}...-------...{Internet}...--------- Any advice would be appreciated, Mike Wirth --B_3294747934_19460281 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Using OTR clients for visually impaired users? Folks,

I work with several visually impaired engineers here at Adobe Systems (on w= ays to make Acrobat PDF files more accessible to the blind, of course). &nbs= p;We have an internal Jabber server, which is normally used for work-related= IM traffic, and which is also available when offsite (over VPN).  But = of the known IM clients, the only one which is accessible to blind users (vi= a screen reader software, e.g., JAWS on Windows) is AIM.

One solution for us to communicate might be to use AOL IM accounts.  B= ut this exposes work-related traffic to the open Internet.  Therefore, = I’d like to use OTR to encrypt the AIM traffic to and from the AIM ser= ver.

Additional complications:
  • I’m typically running Ad= ium on a Mac at my end which shouldn’t be an issue for OTR and which a= llows me to talk to people on the internal Jabber server, as well as AOL IM,= simultaneously.
  • Both I and the blind user may be r= emote, i.e., connected via VPN, which may complicate the proxy configuration= .

My questions:
  1. Is there a Jabber client which= is “accessible” (i.e., usable via a screen reader)?  If so= , this would be the simplest solution.
  2. If not, and we have to use AIM, wh= at’s the appropriate OTR setup?  Something like:

<blind user>---<JAWS on a Windows machine, running AIM>---<O= TR/SOCKS proxy>---<VPN>---<local net connection>---.....

{Internet}...----<AIM server>---...{Internet}...<local net connect= ion>---<VPN>---<Mac, running Adium with OTR>---<me>

Any advice would be appreciated,

Mike Wirth
 --B_3294747934_19460281-- From ian@cypherpunks.ca Wed May 28 01:13:46 2008 From: ian@cypherpunks.ca (Ian Goldberg) Date: Tue, 27 May 2008 20:13:46 -0400 Subject: [OTR-users] Using OTR clients for visually impaired users? In-Reply-To: References: Message-ID: <20080528001346.GH30190@yoink.cs.uwaterloo.ca> On Tue, May 27, 2008 at 03:45:33PM -0700, Mike Wirth wrote: > Folks, > > I work with several visually impaired engineers here at Adobe Systems (on > ways to make Acrobat PDF files more accessible to the blind, of course). We > have an internal Jabber server, which is normally used for work-related IM > traffic, and which is also available when offsite (over VPN). But of the > known IM clients, the only one which is accessible to blind users (via > screen reader software, e.g., JAWS on Windows) is AIM. > > One solution for us to communicate might be to use AOL IM accounts. But > this exposes work-related traffic to the open Internet. Therefore, I¹d like > to use OTR to encrypt the AIM traffic to and from the AIM server. > > Additional complications: > * I¹m typically running Adium on a Mac at my end which shouldn¹t be an issue > for OTR and which allows me to talk to people on the internal Jabber server, > as well as AOL IM, simultaneously. > * Both I and the blind user may be remote, i.e., connected via VPN, which > may complicate the proxy configuration. > > My questions: > 1. Is there a Jabber client which is ³accessible² (i.e., usable via a screen > reader)? If so, this would be the simplest solution. > 2. If not, and we have to use AIM, what¹s the appropriate OTR setup? > Something like: > > ------ proxy>---------..... > > {Internet}...-------...{Internet}... connection>--------- > > Any advice would be appreciated, Interesting question. Would a command-line OTR-aware client like climm be easier for a screen reader to handle? - Ian From js-otrim@webkeks.org Wed May 28 14:55:27 2008 From: js-otrim@webkeks.org (Jonathan Schleifer) Date: Wed, 28 May 2008 15:55:27 +0200 Subject: [OTR-users] Using OTR clients for visually impaired users? In-Reply-To: References: Message-ID: <20080528155527.1a6811b1@webkeks.org> --Sig_/U=f5Ex4b7jsKKaxf/T34K+P Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Have a look at mcabber. It a console based Jaber client which also supports OTR. If you have to use Windows machines, you could just setup a server in the internal network that runs mcabber for those, so they can ssh to it. I don't know how easy to use that would be for visually impaired users, but I have often read that console programs on a unix are the easiest to use for them. --=20 Jonathan --Sig_/U=f5Ex4b7jsKKaxf/T34K+P Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- iQIcBAEBAwAGBQJIPWRUAAoJEMtRg9d5cXHknPQP+gPqaZqmqDgMeNtF1Cb22UxX ATB78X9GRhu8TlmCGNI/8N1asSLLxJ5QD14Imz2xUh6w/aQ3XLmBcXziNzUH1QRH 5UZ89lC0yFzix/75Q/CHz3wj3s4girD5YJjhnce2iuyxaQKku2NWu+pSdZw0Ql0l lfqjWhw/djv6Yr2S6PyPNjflYxBH0a5JIxD73t1YV0jAyq9ZVGVq0zwDoAUMNvXx fYgdx7v4c/LzJMWREoogIzLciBZznvHI+21EhPnXvmbHAojCL5JDwRGGEwTCd5uk wCp4TXLkuzTtGJ5cHntPa2hZ3Ayabc6x3T0vLzeZEAnmVWMEhLf9WkP5kTS3LNNY savUZJoW948SSgLBZ4kFSLuqo85hfPrqaE6/A+9jyvCZfEDFVI2A7xvevgFwYfLk MBdI2ChMYaVr0VzC3n+kXraD1j3CAZzpmS/GKBAX/MmbWM7KxPCcFzDICZ2ZFPaa Njqi+sJJa6cJHcQAWnNvmg37udBfoLXH+agF6j/0PBKv59Int4T+8Q8UAXC+sMIB gDQdDgrAjIqUndIFrm5eVxrkcKntrmETVKz+jXo3DyXIyHChb5s6BtLGp3Ucqz2E OjeblGq1TarjizfJQM4/CtU3gTy+SBTcu1LZggk4V6Edvr8NKwbC2ZvbDo10LBbS Q5eUuY5VaEP2AUq24wdb =WERT -----END PGP SIGNATURE----- --Sig_/U=f5Ex4b7jsKKaxf/T34K+P--