From rob.smits at uwaterloo.ca Thu Nov 18 14:24:03 2010 From: rob.smits at uwaterloo.ca (Rob Smits) Date: Thu, 18 Nov 2010 14:24:03 -0500 Subject: [OTR-dev] New OTR Development Message-ID: <1290108243.4487.57.camel@scspc293.cs> [Please note that while I have included both the dev and users lists in this message, only send your replies to the dev list] Hello, I am a past OTR contributor who is now working with Ian as a grad student. This means there will be some new OTR development happening! The current focus is tackling some of the items on this list: http://lists.cypherpunks.ca/pipermail/otr-dev/2010-February/001108.html We've also done some analysis regarding the XMPP Resource/Fingerprint issue ( http://lists.cypherpunks.ca/pipermail/otr-users/2010-September/001869.html ). As it turns out, some of the design changes required to fix the "multiple logins" problem (described in the first link above) can actually give us a clean solution to this fingerprint issue. Regards, Rob Smits From stpeter at stpeter.im Thu Nov 18 14:50:37 2010 From: stpeter at stpeter.im (Peter Saint-Andre) Date: Thu, 18 Nov 2010 12:50:37 -0700 Subject: [OTR-dev] New OTR Development In-Reply-To: <1290108243.4487.57.camel@scspc293.cs> References: <1290108243.4487.57.camel@scspc293.cs> Message-ID: <4CE5838D.8000908@stpeter.im> On 11/18/10 12:24 PM, Rob Smits wrote: > > Hello, > > I am a past OTR contributor who is now working with Ian as a grad > student. This means there will be some new OTR development > happening! I'm excited to hear it! > The current focus is tackling some of the items on this list: > http://lists.cypherpunks.ca/pipermail/otr-dev/2010-February/001108.html Regarding the file transfer issue, you might look at the "in-band bytestreams" protocol that we use as a fallback in the Jabber world: http://xmpp.org/extensions/xep-0047.html See also: http://xmpp.org/extensions/xep-0261.html http://xmpp.org/extensions/xep-0234.html > We've also done some analysis regarding the XMPP > Resource/Fingerprint issue ( > http://lists.cypherpunks.ca/pipermail/otr-users/2010-September/001869.html > ). As it turns out, some of the design changes required to fix the > "multiple logins" problem (described in the first link above) can > actually give us a clean solution to this fingerprint issue. That sounds right. BTW, over the summer I pinged Ian about potentially formalizing OTR at a standards body (I think the IETF is the right place, but opinions might differ). Now that I'm very close to finished with revisions to the base XMPP specs, I could free up some time to help with that. I'd love to see an RFC published about OTR so that we can further encourage more implementations. Peter -- Peter Saint-Andre https://stpeter.im/ -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6105 bytes Desc: S/MIME Cryptographic Signature URL: From govnototalitarizm at gmail.com Thu Nov 18 15:41:54 2010 From: govnototalitarizm at gmail.com (M) Date: Thu, 18 Nov 2010 22:41:54 +0200 Subject: [OTR-dev] New OTR Development In-Reply-To: <4CE5838D.8000908@stpeter.im> References: <1290108243.4487.57.camel@scspc293.cs> <4CE5838D.8000908@stpeter.im> Message-ID: <4CE58F92.3040206@gmail.com> 18.11.2010 21:50, Peter Saint-Andre ?????: >> The current focus is tackling some of the items on this list: >> http://lists.cypherpunks.ca/pipermail/otr-dev/2010-February/001108.html > > Regarding the file transfer issue, you might look at the "in-band > bytestreams" protocol that we use as a fallback in the Jabber world It's also mentioned that "This is of course only useful for small files" - actually it's even worse: it doesn't work for big files at all due to bug which I was unable to track down in time (in short - I couldn't get otr session context from pidgin session context). So everything which will not fit into single otr TLV message cannot be transmitted. On the other hand - such small messages are less lickely to upset server operators :-) One more point: "I think it also blocks the IM conversation until the file is completely transmitted." - as far as I remember it is undistinguishable from regular jabber file transfer... although I might have missed something because all the tests were done with very small files. Using bytestream for file transfer was one of the initial ideas - I hope it will be implemented as well. I think small files (<= otr TLV size) should be sent inband and bigger files should be send via bytestream. Of course with ability to fallback both ways in case some of XEPs are not supported by server\client in particular case. best regards, Max. From n-roeser at gmx.net Mon Nov 22 09:04:23 2010 From: n-roeser at gmx.net (Nico R.) Date: Mon, 22 Nov 2010 15:04:23 +0100 Subject: [OTR-dev] Digital signature for Java OTR library Message-ID: <4CEA7867.8070308@gmx.net> Hello! For most OTR downloads on , there are digital (OpenPGP) signatures available. I did not find an OpenPGP signature for the Java OTR library, . Is this on purpose? If not, could you add a signature? Thanks, -- Nico -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature URL: From ian at cypherpunks.ca Mon Nov 22 21:01:48 2010 From: ian at cypherpunks.ca (Ian Goldberg) Date: Mon, 22 Nov 2010 21:01:48 -0500 Subject: [OTR-dev] Digital signature for Java OTR library In-Reply-To: <4CEA7867.8070308@gmx.net> References: <4CEA7867.8070308@gmx.net> Message-ID: <20101123020148.GT12049@yoink.cs.uwaterloo.ca> On Mon, Nov 22, 2010 at 03:04:23PM +0100, Nico R. wrote: > Hello! > > For most OTR downloads on > , there are digital > (OpenPGP) signatures available. > > I did not find an OpenPGP signature for the Java OTR library, > . Is this on > purpose? If not, could you add a signature? Whoops; total oversight on my part. Done! - Ian