[OTR-dev] OTR version 4 Draft
Hi! I am Rosalie from the STRIKE team at Thoughtworks, and I'd like to present a draft of OTR version four: https://github.com/twstrike/otrv4 The STRIKE team has incorporated many updates such as a new Deniable Authenticated Key Exchange, the Double Ratchet Algorithm, and the replacement of SHA-1 and SHA-2 with SHA-3. Further details about these and other decisions are included in the "architecture-decisions" folder. We appreciate any feedback, questions, and concerns. Thanks, Rosalie -- Rosalie Tolentino Pure Energy She/Her They/Them Thoughtworks Fingerprint: 55A0 392B C270 DEBD 6842 A1A7 682A BA98 875D 87B9 signature.asc Description: PGP signature ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
Re: [OTR-dev] OTR version 4 Draft
On Tue, 13 Dec 2016, Rosalie Tolentino wrote: I am Rosalie from the STRIKE team at Thoughtworks, and I'd like to present a draft of OTR version four: https://github.com/twstrike/otrv4 The STRIKE team has incorporated many updates such as a new Deniable Authenticated Key Exchange, the Double Ratchet Algorithm, and the replacement of SHA-1 and SHA-2 with SHA-3. Further details about these and other decisions are included in the "architecture-decisions" folder. So I am very confused about this specification. This is your version of what you would like to be otrv4, but you are not the OTR team, so this is not anything "official" ? Paul ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
Re: [OTR-dev] OTR version 4 Draft
Hi Paul, My name is Ola Bini - I am part of the STRIKE team that has done this work. > So I am very confused about this specification. This is your version of > what you would like to be otrv4, but you are not the OTR team, so this > is not anything "official" ? You are correct, we are not the OTR team. We are a team of people that have had bandwidth to work on OTR in different capacities (including creating a production ready OTRv3 implementation in Golang). We started talking about creating a new specification for OTRv4 back in the beginning of March at the IFF - you can see the report and discussion about that starting here: https://lists.cypherpunks.ca/pipermail/otr-dev/2016-March/002447.html Take it as you want - this is not official in any way - although we hope it will be official once we people have looked it over and given thoughts and comments about the work. As you can see in the above thread, the thoughts and ideas in the spec goes back to lots of discussions with the core OTR team. Hope that clarifies things. Cheers -- Ola Bini (https://olabini.se) "Yields falsehood when quined" yields falsehood when quined. signature.asc Description: PGP signature ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
Re: [OTR-dev] OTR version 4 Draft
Ola Bini: > Take it as you want - this is not official in any way - although we > hope it will be official once we people have looked it over and given > thoughts and comments about the work. Thanks for your work! I agree with Paul here, using "OTRv4" for protocol name that is not actually an OTR one is a bit confusing. If you have plans for "merging" this spec upstream it's better to go under some temporal codename for it. It will prevent situations like "Do you mean OTRv4 by STRIKE or official one?"/"I read official specs and going to use OTRv4 implementation by STRIKE team in my project"/etc. -- Ivan Markin ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
Re: [OTR-dev] OTR version 4 Draft
Hi Ivan, > I agree with Paul here, using "OTRv4" for protocol name that is not > actually an OTR one is a bit confusing. If you have plans for "merging" I'm not sure I understand your point. The specification is aiming to be the new OTR version - and in fact, if it doesn't end up being that we have failed, and the specification should not be used. > this spec upstream it's better to go under some temporal codename for > it. It will prevent situations like "Do you mean OTRv4 by STRIKE or > official one?"/"I read official specs and going to use OTRv4 > implementation by STRIKE team in my project"/etc. As far as I know, there are no other people working on a specification of OTRv4. The idea from our standpoint is that we hope that we will get some comments and suggestions on changes and improvements, but sooner or later will achieve broad consensus on this specification - and once that happens it will be published on the OTR web page as the official specification for version 4. If you think it would help understanding to have a temporary code name we could absolutely do that - but at the moment I don't exactly see the point. Cheers -- Ola Bini (https://olabini.se) "Yields falsehood when quined" yields falsehood when quined. signature.asc Description: PGP signature ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
Re: [OTR-dev] OTR version 4 Draft
Ola Bini: > As far as I know, there are no other people working on a specification > of OTRv4. The idea from our standpoint is that we hope that we will > get some comments and suggestions on changes and improvements, but > sooner or later will achieve broad consensus on this specification - > and once that happens it will be published on the OTR web page as the > official specification for version 4. If you think it would help > understanding to have a temporary code name we could absolutely do > that - but at the moment I don't exactly see the point. The closest illustration that comes to my mind of this idea is NIST hash function competition. In the framework of OTR it's something like that: There are some candidates for OTRv4. As of now there is only one candidate here (call it e.g. Thunder) from STRIKE team. Maybe there will be others, maybe not. Anyway, after some polishing/discussions there should be consensus that, e.g. "OTRv4 is Thunder" (like "SHA3 is Keccak"). This is just to not mess things up. -- Ivan Markin ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
Re: [OTR-dev] OTR version 4 Draft
On 12/13/2016 06:25 PM, Rosalie Tolentino wrote: > I am Rosalie from the STRIKE team at Thoughtworks, and I'd like to > present a draft of OTR version four: https://github.com/twstrike/otrv4 Hello everyone, I took a look at the proposed specification earlier this month. Independent of the naming of this initiative (as discussed in the other reply thread), I have a few comments on the specification itself. I've also incorporated some comments from Ian on the first few sections. Before jumping into more detailed points, I'd like to raise a broader issue that merits discussion: what should the purpose of "OTRv4" be? Is our goal to update OTRv3 so that we get more modern cryptographic primitives and better deniability properties for instant messaging over XMPP, or is our goal to design a protocol that provides a competitive alternative to protocols like Signal in newer messaging environments? The best design decisions depend on the objective. If the goal of this effort is to improve OTRv3, then I think that this proposal provides an excellent foundation for discussion and iteration. However, I also think that we should have a discussion about whether this is the best objective. One of the reasons for Signal's success is that the messaging landscape has changed substantially since OTRv3 was designed; asynchronous communication networks are now one of the most important environments. Moreover, Google's move away from XMPP has decreased the importance of the protocol for mainstream users. For the remaining XMPP market, the acceptance of OMEMO (Signal for XMPP) by the XMPP Standards Foundation in December has cleared the way for Signal to become the dominant secure messaging layer. At the same time, criticisms of Open Whisper Systems' management of the Signal protocol and app suggest that there is room for an alternative, as long as it can compete in the same markets. This proposal does not appear to have been designed to do that (e.g., due to a requirement for synchronous communication, and compromises related to the need for OTRv3-style session initiation). I would prefer to see a design that provides an alternative to Signal. I would also like to see some discussion about this design direction on this list. With that out of the way, here's some of our specific comments on the specification as written: I'd like to point out some major design decisions for discussion on this list. Justifications are given in the specification (particularly in the "architecture-decisions" directory), but these choices are worth highlighting: - XSalsa20 is used instead of AES. - 3072-bit DH is used to offer resistance against elliptic curve weaknesses. There is no explicit attempt to provide forward secrecy against quantum cryptanalysis. Some high-level points that apply throughout the document: - All group elements received from another party should be checked to ensure that they are in the correct group and that they are not the identity element. This is pointed out at one point in the document, but not in other places where this check must be performed. - For maximum usefulness, the document should be entirely self-contained. Concepts referenced from the OTRv3 specification and other documents should be included in the OTRv4 specification. - When using abbreviations or ideas that are introduced later in the specification, either include forward references, or move the definitions before their first use. One thing that I would like to see in any OTRv4 specification would be explicit instructions for the production of forged transcripts, for the benefit of deniability. Ideally, any library that implements an OTRv4 API should be able to produce forged transcripts using the same functions that are used to conduct honest conversations, and this design should be strongly encouraged and guided by the specification. Concerning the choice of Spawn as the DAKE, we are hoping to publish an updated scheme soon (certainly before any deployment of OTRv4). Although we have some improvements to the design of Spawn and our other DAKEs, the changes will not affect the specification too much. That said, Spawn is the least efficient of the three DAKEs that we have described. Its use here appears to be motivated by the synchronous network environment and the need to send an OTR initiation request in the first message flow (without the ability to include a ciphertext). The specification should explicitly justify the use of this inferior DAKE in the design decision documents. The constraint on the first flow comes from the need for the underlying messaging platform to support insecure communication; this is one of the reasons that I would like to see a discussion about the objectives of OTRv4. Specific points and questions about the specification as written (our comments are preceded by asterisks): - High Level Overview: - "An OTRv4 conversation is established when o
Re: [OTR-dev] OTR version 4 Draft
Hi Nik, everyone, Thanks to you and Ian for the review, thoughts and comments! I would like to address your general comments in this email, and the rest of the team will look over your specific comments and fix them or ask questions about them in separate emails! =3D) When it comes to the purpose of "OTRv4" - I don't actually think you have to choose between your two alternatives. Our specification is in no way tied to XMPP or any other messaging protocol. Specifically, when it comes to things that make our "OTRv4" unsuitable as a competitor for Signal, it is only out-of-order delivery and offline messages that are missing. When it comes to out-of-order delivery, we had first planned on supporting that - but the consensus from the meeting at Tor dev end of September in Seattle was that it was too large of a burden. Ian was present at that meeting. But if that's something that should be re-evaluated, we can definitely do that. "OTRv4" doesn't explicitly contain support for offline session initiation - but we have designed to protocol in such a way that it's possible to build an offline protocol on top of it, without any changes to "OTRv4". Our plan was to first get the online use cases sorted out, and then create a separate smaller specification for offline OTRv4. The reason for that is because of the complications involved in requiring third-party servers and other aspects. But it's been part of - and is - part of our plan for "OTRv4". > compromises related to the need for OTRv3-style session initiation).=20 I'm not sure I understand what you mean with this. Can you elaborate? > Concerning the choice of Spawn as the DAKE, we are hoping to publish an > updated scheme soon (certainly before any deployment of OTRv4). Although > we have some improvements to the design of Spawn and our other DAKEs, > the changes will not affect the specification too much. That said, Spawn > is the least efficient of the three DAKEs that we have described. Its > use here appears to be motivated by the synchronous network environment > and the need to send an OTR initiation request in the first message flow > (without the ability to include a ciphertext). The specification should > explicitly justify the use of this inferior DAKE in the design decision > documents. The constraint on the first flow comes from the need for the > underlying messaging platform to support insecure communication; this is > one of the reasons that I would like to see a discussion about the > objectives of OTRv4. As mentioned above - we designed OTRv4 to allow for both online and offline session initiation. We choose SPAWN, since that would allow us better security properties in the online case - but we could still use the same primitives and algorithms for the offline case.=20 > * Is in-order delivery a necessary assumption, given the use of the > double ratchet? What about if an active attacker modifies the > order? As currently written, order modification will have the same effect as dropped packages. > - Key Management > * Why the term "mix key"? In previous discussions about OTRv4, this > was called an "insurance key". Actually, it has been called "super encryption" in all discussions I was part of. I never heard it called an "insurance key", which is completely fine. We ended up with "mix key" since it's a key that will be mixed in with the rest of the material for the ratchet. > - "Version (BYTE)" > * Can a user profile support multiple versions? Not as we currently wrote it, but that's something we should consider. > * Since you are using Spawn interactively, it's misleading to refer > to the first flow (psi_1) as a "prekey". That term implies > non-interactive storage of multiple values by a central server, as > in Signal. We used the name "prekey" since we expect to use Spawn both interactively and non-interactively, but that's certainly something ew can change. > Ian will be attending the Tor meeting in Amsterdam, so perhaps Ola, he, > and any other interested parties could set aside some time to go over > the document (or an iterated version of it) in person there? Me, Iv=E1n and Yakira will all be attending the Tor meeting, so we should be able to have a discussion there - but it would be great if we could continue making progress here in the meantime too! Cheers -- Ola Bini (https://olabini.se) "Yields falsehood when quined" yields falsehood when quined. signature.asc Description: PGP signature ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
[OTR-dev] OTR version 4 Draft #2
Hey! I am Sofia from the team that previously sent a draft of the OTRv4 protocol. We, as a team, would like to present the third version of this draft. It has been reviewed by Ian and Nik two times in the interim. The draft is at Github[1]. There are many changes on this version as compared with the version 3 of the OTR protocol. Just to briefly summarize them: * Security level raised to 224 bits and based on Elliptic Curve * Cryptography (ECC) (using ed448, Goldilocks, -huge thanks to Mike Hamburg!-). * Additional protection against transcript decryption in the case of ECC compromise. * Support for both online and offline conversations. * Support for an out-of-order network model. * The following cryptographic primitives and protocols have been updated: * Deniable authenticated key exchanges (DAKE) using "DAKE with Zero Knowledge" (DAKEZ) and "Extended Zero-knowledge Diffie-Hellman" (XZDH). DAKEZ corresponds to conversations when both parties are online (interactive) and XZDH to conversations when one of the parties is offline (non-interactive). * Key management using the Double Ratchet Algorithm. * Upgraded SHA-1 and SHA-2 to SHAKE-256. * Switched from AES to XSalsa20. * Support for different modes in how the specification can be used (OTRv4 only, OTRv4+v3 compatibility mode, OTRv4 interactive only). * Explicit instructions for producing forged transcripts using the same functions used to conduct honest conversations. The DAKEs we are using are based upon the ones defined by Nik and Ian in their paper: Improved Strongly Deniable Authenticated Key Exchanges for Secure Messaging[2]. Nik will be talking about them at the next PETS [3], if you are interested, or you can check this diagram around them [4]. Previously, there were some comments inquiring whether this was the "official" draft of OTRv4. As we have been closely working with Ian and Nik on this, we consider this an official version 4 of the OTR protocol. Just for context, this version of the protocol started with a discussion held at the beginning of March, 2015, at the IFF - you can see the report and discussion about that beginning here [5]. This proposal have had two reviews. We briefly held a meeting around it with Ian at Real World Crypto, 2018. Notice that the draft points to another specification for how a prekey server used for offline conversations works. This specific specification is still a work in progress. But we will finish it soon. ;) We are sending this in order to get a third review from Nik and Ian, but also to get the opinions, thoughts, discussions and much more from the OTR community. This is by no means a finished draft, so, we welcome your feedback on it (please, do so). Let's discuss and share our opinions! :) Thanks and have a very good weekend! The OTRv4 team 1- https://github.com/otrv4/otrv4/blob/master/otrv4.md 2- http://cacr.uwaterloo.ca/techreports/2016/cacr2016-06.pdf 3- https://petsymposium.org/2018/paperlist.php 4- https://cs.uwaterloo.ca/~njunger/dake_csdf17_poster_72dpi.png 5- https://lists.cypherpunks.ca/pipermail/otr-dev/2016-March/002447.html -- Sofía Celi (aka cherenkov) @claucece / @cherenkov_d EF74 1A5F 5692 E56F 14F6 243C 3992 6144 F89D 996F ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
Re: [OTR-dev] OTR version 4 Draft #2
On 3/16/18, Sofia wrote: > Hey! > > I am Sofia from the team that previously sent a draft of the OTRv4 > protocol. We, as a team, would like to present the third version of this > draft. It has been reviewed by Ian and Nik two times in the interim. The > draft is at Github[1]. > > There are many changes on this version as compared with the version 3 of > the OTR protocol. Just to briefly summarize them: > > * Security level raised to 224 bits and based on Elliptic Curve > * Cryptography (ECC) (using ed448, Goldilocks, -huge thanks to Mike > Hamburg!-). > * Additional protection against transcript decryption in the case of ECC > compromise. > * Support for both online and offline conversations. > * Support for an out-of-order network model. > * The following cryptographic primitives and protocols have been updated: > * Deniable authenticated key exchanges (DAKE) using "DAKE with Zero > Knowledge" (DAKEZ) and "Extended Zero-knowledge Diffie-Hellman" (XZDH). > DAKEZ corresponds to conversations when both parties are online > (interactive) and XZDH to conversations when one of the parties is > offline (non-interactive). > * Key management using the Double Ratchet Algorithm. > * Upgraded SHA-1 and SHA-2 to SHAKE-256. > * Switched from AES to XSalsa20. > * Support for different modes in how the specification can be used > (OTRv4 only, OTRv4+v3 compatibility mode, OTRv4 interactive only). > * Explicit instructions for producing forged transcripts using the same > functions used to conduct honest conversations. Thank you for working on this! I still use XMPP+OTRv3 because: 1. XMPP has comfortable clients of choice (on desktop, native) 2. OTRv3 just works 3. OMEMO is only supported in a few clients and incompletely at that, and it doesn't work seamlessly like libotr integration in Pidgin or mcabber I suppose (couldn't find it) that there is a libotr branch implementing the draft, right? This is very important if we want to upgrade pidgin, weechat, mcabber, jackline, adium, etc to OTRv4. ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
Re: [OTR-dev] OTR version 4 Draft #2
Hi Carsten, > I suppose (couldn't find it) that there is a libotr branch implementing > the draft, right? This is very important if we want to upgrade pidgin, > weechat, mcabber, jackline, adium, etc to OTRv4. You are completely right that having an implementation that offers a similar API to libotr is incredibly important for adoption. You can find it here https://github.com/otrv4/libotrv4 It's currently not anywhere near complete - we are planning on pushing forward on that work now that I have a fairly stable version of the specification. Cheers -- Ola Bini (https://olabini.se) "Yields falsehood when quined" yields falsehood when quined. signature.asc Description: PGP signature ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
Re: [OTR-dev] OTR version 4 Draft #2
On 3/16/18, Carsten Mattner wrote: > I suppose (couldn't find it) that there is a libotr branch implementing > the draft, right? This is very important if we want to upgrade pidgin, > weechat, mcabber, jackline, adium, etc to OTRv4. Well, minus jackline, which doesn't use libotr. Sorry for include it in the list. ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
Re: [OTR-dev] OTR version 4 Draft #2
On 3/16/18, Ola Bini wrote: > Hi Carsten, > > > >> I suppose (couldn't find it) that there is a libotr branch implementing >> the draft, right? This is very important if we want to upgrade pidgin, >> weechat, mcabber, jackline, adium, etc to OTRv4. > > You are completely right that having an implementation that offers a > similar API to libotr is incredibly important for adoption. > > You can find it here https://github.com/otrv4/libotrv4 > > It's currently not anywhere near complete - we are planning on pushing > forward on that work now that I have a fairly stable version of the > specification. It says it depends on 'libotr 4.x'. I don't understand, isn't that the project itself? Thank you again for working on this and I wish it wouldn't add so many non-trivial library dependencies. The nice thing about libotr3 is that it is reliable because it's low on external dependencies. From libglib2.0-dev libdecaf libsodium-dev libotr 4.x libgcrypt 1.8.0 or newer I feel like libsodium-dev should be the only one a v4 libotr may depend on, if we consider the use DJB's crypto designs in place of OTRv3's past (reasonable) choices. This isn't meant to diminish the work on v4 and meant as critique to consider as improvements. ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
Re: [OTR-dev] OTR version 4 Draft #2
On 3/17/18, Carsten Mattner wrote: > I feel like libsodium-dev should be the only one a v4 libotr Ideally s2n's set of ciphers would suffice and we would use a formally verified library, which is super useful for OTR's goals. Just throwing these ideas out there since v4 is still in design/development mode. ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
Re: [OTR-dev] OTR version 4 Draft #2
Hey! Thanks so much for looking at the library. > It says it depends on 'libotr 4.x'. I don't understand, isn't that > the project itself? That is actually libotr (often called libotr3) that implements OTRv3, whose library version is 4. > I feel like libsodium-dev should be the only one a v4 libotr > may depend on, if we consider the use DJB's crypto designs > in place of OTRv3's past (reasonable) choices. Well, for libotr4 we also need the library of ed448, "Goldilocks" elliptic curve, which is not implemented in libsodium. It was implemented by Mike Hamburg here: https://sourceforge.net/p/ed448goldilocks/code/ci/master/tree/ This library (libdecaf) is a multi-purpose elliptic curve library, so right now we are also working on a "pure" implementation of ed448 elliptic curve, "Goldilocks". Libgcrypt is a library that libotr3 also depends upon, to use MPIs, for example. Libotr is included for backwards compatibility with OTRv3. This of course, can change ;) > This isn't > meant to diminish the work on v4 and meant as critique > to consider as improvements. Np. It is nice that people are looking at the library ;) On 3/16/18 8:57 PM, Carsten Mattner wrote: > On 3/16/18, Ola Bini wrote: >> Hi Carsten, >> >> >> >>> I suppose (couldn't find it) that there is a libotr branch implementing >>> the draft, right? This is very important if we want to upgrade pidgin, >>> weechat, mcabber, jackline, adium, etc to OTRv4. >> >> You are completely right that having an implementation that offers a >> similar API to libotr is incredibly important for adoption. >> >> You can find it here https://github.com/otrv4/libotrv4 >> >> It's currently not anywhere near complete - we are planning on pushing >> forward on that work now that I have a fairly stable version of the >> specification. > > It says it depends on 'libotr 4.x'. I don't understand, isn't that > the project itself? > > Thank you again for working on this and I wish it wouldn't add > so many non-trivial library dependencies. The nice thing about > libotr3 is that it is reliable because it's low on external > dependencies. > > From > > libglib2.0-dev > libdecaf > libsodium-dev > libotr 4.x > libgcrypt 1.8.0 or newer > > I feel like libsodium-dev should be the only one a v4 libotr > may depend on, if we consider the use DJB's crypto designs > in place of OTRv3's past (reasonable) choices. This isn't > meant to diminish the work on v4 and meant as critique > to consider as improvements. > -- Sofía Celi (aka cherenkov) @claucece / @cherenkov_d EF74 1A5F 5692 E56F 14F6 243C 3992 6144 F89D 996F ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
Re: [OTR-dev] OTR version 4 Draft #2
On 3/17/18, Sofia wrote: > Hey! > > Thanks so much for looking at the library. > > >> It says it depends on 'libotr 4.x'. I don't understand, isn't that >> the project itself? > > That is actually libotr (often called libotr3) that implements OTRv3, > whose library version is 4. Yeah, I was expecting the work to be part of a future libotr release, though it doesn't seem viable. > Well, for libotr4 we also need the library of ed448, "Goldilocks" > elliptic curve, which is not implemented in libsodium. It was > implemented by Mike Hamburg here: > https://sourceforge.net/p/ed448goldilocks/code/ci/master/tree/ > This library (libdecaf) is a multi-purpose elliptic curve library, so > right now we are also working on a "pure" implementation of ed448 > elliptic curve, "Goldilocks". > > Libgcrypt is a library that libotr3 also depends upon, to use MPIs, > for example. Libotr is included for backwards compatibility > with OTRv3. Like I wrote above, I was naively thinking it would be a branch of libotr that implements a new protocol, while leaving the existing code untouched or modified where needed. I totally understand how the "multitude" (no negative meaning implied) libs came to be dependencies. From experience with open source projects, I'm certain this will raise eyebrows and/or upset downstream, in addition to the uncertainty and irregular reliability of pulling in many independently developed libraries, especially if it's for crypto primitives we put our trust in. ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
Re: [OTR-dev] OTR version 4 Draft #2
On 3/17/18, Carsten Mattner wrote: > On 3/17/18, Carsten Mattner wrote: > >> I feel like libsodium-dev should be the only one a v4 libotr > > Ideally s2n's set of ciphers would suffice and we would use > a formally verified library, which is super useful for > OTR's goals. > > Just throwing these ideas out there since v4 is still in > design/development mode. Forget s2n, it's a slimmed down implementation, focusing on mainstream ciphers only. Missing everything, basically. ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
Re: [OTR-dev] OTR version 4 Draft #2
Hi Carsten, I just wanted to add a few comments on what Sofi already said. First, about libraries: glib: This is really the only _significant_ dependency we are adding. However, it's not a runtime dependency, we only use glib for tests, so when installing using package managers etc, it will not be a dependency. decaf: This is the current depenency that give us access to Ed448, which is the elliptic curve we are using for all operations. We opted for Ed448 instead of 25519, in order to increase the security level - and thus, sodium doesn't give us this curve. sodium: Primarily, libsodium gives us xsalsa. otr: See below for a longer explanation. gcrypt: This dependency is primarily for the multi-precision integer library, MPIs. As you can see, the decaf and sodium dependencies give us cryptographic primitives that we need. In the same way, gcrypt give us MPI's, which is also necessary for most of our implementation. In theory, you could argue that these three libraries have significant sizes, and adding them to OTR is problematic. We could in theory take the pieces we need and put them directly into the OTR code base, but I would argue that this wouldn't increase the security and reliability of OTR, rather the other way around. Having smart people making sure our XSalsa20 implementation is running fast on all architectures instead of us having to do the work ourselves is quite nice. The other way of looking at it, would be to say that OTR should only use simple primitives that can be implemented inside the single library, in the way the old libotr implements DH and DSA. However, with todays threat landscape, that would restrict us to primitives that are not well suited, OR, implementations that are not viable at naive implementation speeds, in order to have a resonable security level. When it comes to libotr, vs the new libotrv4 (we are thinking about changing the name, since it's confusing), we really had a few different choices. Considering that OTRv4 comes with new primitives and new capabilities, it would be close to impossible to keep the same API as libotr without doing horrible things. Our choices were, roughly: - Ignore libotr and OTRv3 and backwards compatibility - Subsume libotr, add OTRv4 functionality around the existing library and expose a new API, side-by-side with the OTRv3 API - Create a separate OTRv4 implementation that ONLY does v4, but delegates to the old libotr implementation for v3 functionality. From our perspective, #1 was not viable, #2 would lead to a lot of complexity, and potentially maintenance of a significant amount of code that wasn't live most of the time anymore. Also, v3 and v4 have significant differences, so there wouldn't be that much shared code paths. For us, #3 struck the right balance between user functionality and maintenance ease for the developers. Hope that helps! Cheers -- Ola Bini (https://olabini.se) "Yields falsehood when quined" yields falsehood when quined. signature.asc Description: PGP signature ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
Re: [OTR-dev] OTR version 4 Draft #2
On Friday 16 Mar 2018 à 22:55:32 (+), Carsten Mattner wrote: > On 3/16/18, Sofia wrote: > > Hey! > > > > I am Sofia from the team that previously sent a draft of the OTRv4 > > protocol. We, as a team, would like to present the third version of this > > draft. It has been reviewed by Ian and Nik two times in the interim. The > > draft is at Github[1]. > > > > There are many changes on this version as compared with the version 3 of > > the OTR protocol. Just to briefly summarize them: > > > > * Security level raised to 224 bits and based on Elliptic Curve > > * Cryptography (ECC) (using ed448, Goldilocks, -huge thanks to Mike > > Hamburg!-). > > * Additional protection against transcript decryption in the case of ECC > > compromise. > > * Support for both online and offline conversations. > > * Support for an out-of-order network model. > > * The following cryptographic primitives and protocols have been updated: > > * Deniable authenticated key exchanges (DAKE) using "DAKE with Zero > > Knowledge" (DAKEZ) and "Extended Zero-knowledge Diffie-Hellman" (XZDH). > > DAKEZ corresponds to conversations when both parties are online > > (interactive) and XZDH to conversations when one of the parties is > > offline (non-interactive). > > * Key management using the Double Ratchet Algorithm. > > * Upgraded SHA-1 and SHA-2 to SHAKE-256. > > * Switched from AES to XSalsa20. > > * Support for different modes in how the specification can be used > > (OTRv4 only, OTRv4+v3 compatibility mode, OTRv4 interactive only). > > * Explicit instructions for producing forged transcripts using the same > > functions used to conduct honest conversations. > > Thank you for working on this! I still use XMPP+OTRv3 because: > > 1. XMPP has comfortable clients of choice (on desktop, native) > 2. OTRv3 just works > 3. OMEMO is only supported in a few clients and incompletely at that, >and it doesn't work seamlessly like libotr integration in Pidgin >or mcabber > > I suppose (couldn't find it) that there is a libotr branch implementing > the draft, right? This is very important if we want to upgrade pidgin, > weechat, mcabber, jackline, adium, etc to OTRv4. Hello, Allow me to jump in, as weechat is mentionned. I contributed to the weechat plugin (weechat-otr), and then to its underlying python OTR implementation (pure-python-otr, aka potr), for which I am the current QUOTEmaintainerENDQUOTE. As much as I'm excited about all this, and *will* read this draft, I have bad news for weechat adoption, and python clients in general. The current state of potr is bleak. I'm having a hard time finding time and energy for this project, and there is much to be done. Allow me to elaborate. Before we can talk about implementing an otrv4 for weechat, we need to finish potr support for otrv3. Right now it lives in a post-2/pre-3 state that freaks me out. Before we can talk about finishing the otrv3 support, we must finish switching over to a better (=maintained) underlying primitives library (pycrypto -> pycryptodome) which still requires some work to comply with the CTR handling described in the RFC https://github.com/python-otr/pure-python-otr/issues/68 As you can see this has been in my "urgent" bin for more than a year now. And then there's the fact that the current git "stable" was never packaged, so any distribution-published package is grossly out of date and contains ugly old bugs. TL;DR: Any python client is stuck with potr, which is miles away from being less than hacky at the moment, and lightyears away from any OTRv4 support :( This directly affects at least weechat (irc) and Poezio (xmpp), that I know of. I have booked a weekend to fixing issue 68 early April, but clearly, being alone won't cut it in the longterm. … and then there's the whole debate about whether a python implementation *can* be secure at all, which I won't even get into. I think having a proper python OTRv4 implementation would do great things for adoption. If this matters to you, please send help :( .koolfy ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
Re: [OTR-dev] OTR version 4 Draft #2
Hey, koolfy So sad to read this. > I think having a proper python OTRv4 implementation would do great > things for adoption. > If this matters to you, please send help :( Ok. I'm not an experienced python developer, but I'll try this weekend to see what is missing from the C libotr that implements OTRv3 library with its python counterpart, and create issues around it. I'll try to reach to the python community to see who is willing to help. I'll think this will take a long time but we can do something about it :) Thanks for pointing this out! -- Sofía Celi (aka cherenkov) @claucece / @cherenkov_d EF74 1A5F 5692 E56F 14F6 243C 3992 6144 F89D 996F ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
Re: [OTR-dev] OTR version 4 Draft #2
Hi all, Thanks for you efforts in defining OTRv4. I am currently looking into the spec and have been for a few months. I've gradually started implementing parts of the spec, as I've been reading the various parts to try and wrap my head around them. So, I intend to do this implementation. The implementation is in java and is based on otr4j, however with a bit of history. I started out doing heavy refactoring of github.com/otr4j/otr4j, the (abandoned) initiative of GuardianProject to unify all otr4j developers in a single independent otr4j project. Over the last 2 years I've done some significant refactoring (see https://github.com/cobratbq/otr4j/blob/master/MODIFICATIONS). Apart from fixing a few bugs, I've modified the code base to use state machines for state transitions to ensure protocol is followed strictly. As a nice benefit it isolates secret data to the "Encrypted" message state. This effort was never merged into otr4j/otr4j. It would require peer review as per original agreements. In time, I could use some help: * Peer reviews. The OTRv4 implementation strictly builds upon https://github.com/cobratbq/otr4j. * Adoption. (obviously) * I have not found a (suitable) Ed448-Goldilocks implementation for Java. Currently I'm implementing a naive version myself. After the otr4j version 4 support has sufficiently progressed, I may need some help to optimize the implementation, including some constant-time implementations. * I would be interested to hear if any other implementors are willing to set up a basic "test runner" that could set up otr testclients (in various languages) to chat with each other, as way to do interop testing. I've been thinking about this for a while but never got to actually implementing it. It might be an interesting way to do interop testing between Java, C and Go (etc.) libraries. I will most likely update Jitsi (desktop client) to otrv4 support simply to be able to test the library in an application. So far, I've only just started implementing. Mostly individual snippets to discover the API I would expect from Ed448-Goldilocks. The otrv4 changes are not in a public repo yet. However, they will in time once there's some progress. Few small points of feedback: * The sections on signing and verifying user profiles apply RFC 8032 algorithms unmodified. However the spec currently defines the SHAKE-256 application as KDF_2. I personally would prefer to use the original SHAKE-256 as in the RFC to avoid confusion and doubt. * Last I've seen, it wasn't explicitly stated whether or not OTRv2 is to be dropped. In the implementation I should be able to preserve support for OTRv2, but is this desirable? (I know the modes imply OTRv3 and/or 4, still ...) * As mentioned before, it may be good to define how state transitions look in case multiple clients respond to a query message. (That is, single account, multiple active chat clients.) With clients having mixed OTR protocol versions. I'm happy to be involved in this discussion if you need a more practical perspective. * I think I read somewhere in an issue on the otrv4 github that you may rename "UserProfile" to "ClientProfile" or something, because it's corresponds better to the intention of this profile. Reading this particular suggestion in itself clarified a few things I did not realize before, so I'm all for doing this name change. Regards, Danny On 03/16/2018 05:39 PM, Sofia wrote: > Hey! > > I am Sofia from the team that previously sent a draft of the OTRv4 > protocol. We, as a team, would like to present the third version of this > draft. It has been reviewed by Ian and Nik two times in the interim. The > draft is at Github[1]. > > There are many changes on this version as compared with the version 3 of > the OTR protocol. Just to briefly summarize them: > > * Security level raised to 224 bits and based on Elliptic Curve > * Cryptography (ECC) (using ed448, Goldilocks, -huge thanks to Mike > Hamburg!-). > * Additional protection against transcript decryption in the case of ECC > compromise. > * Support for both online and offline conversations. > * Support for an out-of-order network model. > * The following cryptographic primitives and protocols have been updated: > * Deniable authenticated key exchanges (DAKE) using "DAKE with Zero > Knowledge" (DAKEZ) and "Extended Zero-knowledge Diffie-Hellman" (XZDH). > DAKEZ corresponds to conversations when both parties are online > (interactive) and XZDH to conversations when one of the parties is > offline (non-interactive). > * Key management using the Double Ratchet Algorithm. > * Upgraded SHA-1 and SHA-2 to SHAKE-256. > * Switched from AES to XSalsa20. > * Support for different modes in how the specification can be used > (OTRv4 only, OTRv4+v3 compatibility mode, OTRv4 interactive only). > * Explicit instructions for producing forged transcripts using the same > functions used to conduct honest conversations. > > The DAKEs we are using are based upon the ones defined by N
Re: [OTR-dev] OTR version 4 Draft #2
Hey! > Thanks for you efforts in defining OTRv4. > I am currently looking into the spec and have been for a few months. > I've gradually started implementing parts of the spec, as I've been > reading the various parts to try and wrap my head around them. So, I > intend to do this implementation. > > The implementation is in java and is based on otr4j, however with a > bit of history. I started out doing heavy refactoring of > github.com/otr4j/otr4j, the (abandoned) initiative of GuardianProject > to unify all otr4j developers in a single independent otr4j project. Thank you! It is great that this initiative has been retaken. :) > Over the last 2 years I've done some significant refactoring (see > https://github.com/cobratbq/otr4j/blob/master/MODIFICATIONS). Apart > from fixing a few bugs, I've modified the code base to use state > machines for state transitions to ensure protocol is followed > strictly. As a nice benefit it isolates secret data to the "Encrypted" > message state. This effort was never merged into otr4j/otr4j. It would > require peer review as per original agreements. I see. Do you have any plans of merging it? I have also found out your blog post, which I'm sharing as it sums out very nicely all of this work: http://dannyvanheumen.nl/post/refactoring-otr4j/ This is a very nice work. > * Peer reviews. The OTRv4 implementation strictly builds upon > https://github.com/cobratbq/otr4j. > * Adoption. (obviously) I think this is something we can help after the C library comes into place. > * I have not found a (suitable) Ed448-Goldilocks implementation for > Java. Currently I'm implementing a naive version myself. After the > otr4j version 4 support has sufficiently progressed, I may need some > help to optimize the implementation, including some constant-time > implementations. Yeah. Currently there is the 'libdecaf' library that Mike Hamburg implemented in C: https://sourceforge.net/p/ed448goldilocks/code/ci/master/tree/ This library does not only implement ed448-Goldilocks, but other curves and encodings as well. I'll suggest you take a look at libgoldilocks: https://github.com/otrv4/libgoldilocks This is basically the same implementation of Hamburg's library but with everything that is not ed448-Goldilocks taken away. Eventually the Golang implementation of ed448-Goldilocks will also come into place: https://github.com/twstrike/ed448 Of course, it should be noted that internally Hamburg's library uses the "decaf" technique. It will be awesome to have a java implementation of Goldilocks. > * I would be interested to hear if any other implementors are willing > to set up a basic "test runner" that could set up otr testclients (in > various languages) to chat with each other, as way to do interop > testing. I've been thinking about this for a while but never got to > actually implementing it. It might be an interesting way to do interop > testing between Java, C and Go (etc.) libraries. This is a nice idea. Of course, it needs that the C library is finished ;) > So far, I've only just started implementing. Mostly individual > snippets to discover the API I would expect from Ed448-Goldilocks. The > otrv4 changes are not in a public repo yet. However, they will in time > once there's some progress. From Ed448-Goldilocks you will basically need point addition, point subtraction, scalar multiplication and the EdDSA specific operations (encoding and decoding, sign and verification, private and public key generation). We can talk more about this if you like and how this operations are done in the C library :) > Few small points of feedback: > * The sections on signing and verifying user profiles apply RFC 8032 > algorithms unmodified. However the spec currently defines the > SHAKE-256 application as KDF_2. I personally would prefer to use the > original SHAKE-256 as in the RFC to avoid confusion and doubt. I think you are completely right on this matter. Using SHAKE-256 in these sections should suffice. > * Last I've seen, it wasn't explicitly stated whether or not OTRv2 is > to be dropped. In the implementation I should be able to preserve > support for OTRv2, but is this desirable? (I know the modes imply > OTRv3 and/or 4, still ...) OTRv4 is backwards compatible only with OTRv3, and does not accept OTRv2. Speculatively, it should also be compatible with future versions. OTRv3 keeps its same compatibility. > * As mentioned before, it may be good to define how state transitions > look in case multiple clients respond to a query message. (That is, > single account, multiple active chat clients.) With clients having > mixed OTR protocol versions. I'm happy to be involved in this > discussion if you need a more practical perspective. Instance tags should work for some of these cases. Section "Receiving a Query Message" details how the different versions are handled. I think it should be better detailed in the protocol or maybe somewhere else. Let's start some discussion around th
Re: [OTR-dev] OTR version 4 Draft #2
Hi all, Response in line ... On 03/20/2018 05:25 AM, Sofia wrote: > Hey! > >> Thanks for you efforts in defining OTRv4. >> I am currently looking into the spec and have been for a few months. >> I've gradually started implementing parts of the spec, as I've been >> reading the various parts to try and wrap my head around them. So, I >> intend to do this implementation. >> >> The implementation is in java and is based on otr4j, however with a >> bit of history. I started out doing heavy refactoring of >> github.com/otr4j/otr4j, the (abandoned) initiative of GuardianProject >> to unify all otr4j developers in a single independent otr4j project. > Thank you! It is great that this initiative has been retaken. :) > >> Over the last 2 years I've done some significant refactoring (see >> https://github.com/cobratbq/otr4j/blob/master/MODIFICATIONS). Apart >> from fixing a few bugs, I've modified the code base to use state >> machines for state transitions to ensure protocol is followed >> strictly. As a nice benefit it isolates secret data to the "Encrypted" >> message state. This effort was never merged into otr4j/otr4j. It would >> require peer review as per original agreements. > I see. Do you have any plans of merging it? If I can find someone willing to do the review on this work, sure. Currently, people seem to be preoccupied with other concerns. > > I have also found out your blog post, which I'm sharing as it sums out > very nicely all of this work: > http://dannyvanheumen.nl/post/refactoring-otr4j/ This is a very nice work. Thank you. > >> * Peer reviews. The OTRv4 implementation strictly builds upon >> https://github.com/cobratbq/otr4j. >> * Adoption. (obviously) > I think this is something we can help after the C library comes into place. > >> * I have not found a (suitable) Ed448-Goldilocks implementation for >> Java. Currently I'm implementing a naive version myself. After the >> otr4j version 4 support has sufficiently progressed, I may need some >> help to optimize the implementation, including some constant-time >> implementations. > Yeah. Currently there is the 'libdecaf' library that Mike Hamburg > implemented in C: > https://sourceforge.net/p/ed448goldilocks/code/ci/master/tree/ This > library does not only implement ed448-Goldilocks, but other curves and > encodings as well. I'll suggest you take a look at libgoldilocks: > https://github.com/otrv4/libgoldilocks This is basically the same > implementation of Hamburg's library but with everything that is not > ed448-Goldilocks taken away. Eventually the Golang implementation of > ed448-Goldilocks will also come into place: > https://github.com/twstrike/ed448 > > Of course, it should be noted that internally Hamburg's library uses the > "decaf" technique. I have found all of the mentioned libraries, except for libgoldilocks. Additionally, I found a rust implementation for Ed25519. I used all of these to get my initial bearings. In the end, I got stuck on Mike's original source code due to the amount of "extras": * Some of the core code generated * Decaf * Pre-computed multiples (IIRC) * constant-time operations * Alternative representation, ... IIRC he used the Extended representation at the time * Not sure if Elligator was also in, in any case, I read about that too. In the end, I could not figure out which parts were relevant and given that I'm new to EC in general, it was too much information for me to confidently, reliably extract the critical core parts. Currently, I've picked up the necessary basics and noticed in the mean time that a lot of OTRv4 depends on RFC 8032 approach, i.s.o. of plain Ed448-Goldilocks. This also made it significant more approachable. > It will be awesome to have a java implementation of Goldilocks. The Ed448-Goldilocks parts will be in a separate repository. It may be far from complete compared to Mike Hamburg's ref. implementation. But it should contain most - if not all - of the parts that are not strictly specific to OTRv4. (Ed448-Goldilocks basics and RFC 8032.) > >> * I would be interested to hear if any other implementors are willing >> to set up a basic "test runner" that could set up otr testclients (in >> various languages) to chat with each other, as way to do interop >> testing. I've been thinking about this for a while but never got to >> actually implementing it. It might be an interesting way to do interop >> testing between Java, C and Go (etc.) libraries. > This is a nice idea. Of course, it needs that the C library is finished ;) And the Java library, for that matter ... > >> So far, I've only just started implementing. Mostly individual >> snippets to discover the API I would expect from Ed448-Goldilocks. The >> otrv4 changes are not in a public repo yet. However, they will in time >> once there's some progress. > From Ed448-Goldilocks you will basically need point addition, point > subtraction, scalar multiplication and the EdDSA specific operations > (encoding and decoding, sign and ver
Re: [OTR-dev] OTR version 4 Draft #2
Hey! > I have found all of the mentioned libraries, except for libgoldilocks. This library is a simplification of libdecaf that only takes care of ed448-Golidlocks, while still internally using the decaf technique. > Additionally, I found a rust implementation for Ed25519. Well, for OTRv4 we use ed448-Goldilocks, because we want to achieve a security level of 224~ ;) We are planning on still working on the Golang implementation. > In the end, I got stuck on Mike's original source code due to the > amount of "extras": > * Some of the core code generated > * Decaf > * Pre-computed multiples (IIRC) > * constant-time operations > * Alternative representation, ... IIRC he used the Extended > representation at the time > * Not sure if Elligator was also in, in any case, I read about that > too. So libdecaf is not only for ed448-Goldilocks. It is multiple purpose elliptic curve library that internally uses the decaf technique for several curves, like Iso-25519, ed448-Goldilocks, 25519, p521.. You can check the multiple data for different curves on the library here: https://sourceforge.net/p/ed448goldilocks/code/ci/master/tree/src/generator/curve_data.py So, basically, what decaf means is to remove cofactors through point compression, or through quotients and isogenies. The internal representation of points in libdecaf is as "even" elements of a twisted Edwards curve with a=-1. Using this subgroup removes a factor of 2 from the "original" cofactor (note that for ed448-Goldilocks, this is 4). The remaining factor of 2 is removed with a quotient group: any two points which differ by an element of the 2- or 4-torsion subgroup are considered equal to each other. This is applied to several curves. There are precomputed tables and constant-time operations in the library. The latter is a must for any cryptographic library. You can read about the reasons for it over here: https://www.bearssl.org/constanttime.html Yes, there are several places with different coordinates. If I remember correctly, most of the time extended homogenous projective coordinates are used, of the form (X : Y : Z : T). Homogeneous projective coordinates, for example, are of the form (X : Y : Z), which correspond to the affine point (X/Z, Y/Z) with Z != 0. For extended homogeneous projective coordinates this will be (X : Y : Z : T), as said, where T = X^2 / Z. There is a very nice thesis from Hisil, around this: https://core.ac.uk/download/pdf/10898289.pdf Elligator is also included if there is the will to use it, and it is mostly used internally for tests, I think. What it does is basically make curve points indistinguishable from uniform random strings. Sorry, for the long rant ;) > In the end, I could not figure out which parts were relevant and given > that I'm new to EC in general, it was too much information for me to > confidently, reliably extract the critical core parts. Currently, I've > picked up the necessary basics and noticed in the mean time that a lot > of OTRv4 depends on RFC 8032 approach, i.s.o. of plain > Ed448Goldilocks. This also made it significant more approachable. Don't worry ;). Yes, we mostly used RFC8032 operations and encodings. We are still working on libgoldilocks, but this library contains only ed448-Goldilocks: https://github.com/otrv4/libgoldilocks I think the file: https://github.com/otrv4/libgoldilocks/blob/master/src/eddsa.c can clarify a lot of things. > The Ed448-Goldilocks parts will be in a separate repository. It may be > far from complete compared to Mike Hamburg's ref. implementation. But > it should contain most - if not all - of the parts that are not > strictly specific to OTRv4. (Ed448-Goldilocks basics and RFC 8032.) This sounds awesome! > So far I've managed to do addition, multiplication and EdDSA > operations. I believe private key generation is slightly differently > applied in OTRv4 (IIRC not sure right now but I remember kdf1 or so > being applied). It is the same: 1. You generate first a 57 bytes of cryptographically secure random data (this is 'sym_key'). 2. You hash those values using 'SHAKE-256(sym_key, 114)'. 3. You prune this buffer: the two least significant bits of the first byte are cleared, all eight bits of the last byte are cleared, and the highest bit of the second to last byte is set. 4. You interpret this as a scalar. > However, currently using Affine notation, i.s.o. one of the faster > defined representation as in hyperelliptic.org/EFD. (I started out > with Extended, but struggled with the math. I believe I know my > mistake now.) Additionally, the math currently relies on BigInteger, > so I'm not operating directly on byte[] yet. Mmm. > Like I said, a naive implementation. I'll drop a note on this list, > once I'm far enough ahead that it makes sense to open it up for > feedback. By then I hope people will jump in to give feedback or help > with optimizing the implementation. Ok, I'll love to see this. :) Thanks a lot! -- Sofía Celi (aka cherenkov)
Re: [OTR-dev] OTR version 4 Draft #2
Hi, On 03/25/2018 01:41 AM, Sofia wrote: > Hey! > >> I have found all of the mentioned libraries, except for libgoldilocks. > This library is a simplification of libdecaf that only takes care of > ed448-Golidlocks, while still internally using the decaf technique. Okay, good to know. This can be a good starting point. > >> Additionally, I found a rust implementation for Ed25519. > Well, for OTRv4 we use ed448-Goldilocks, because we want to achieve a > security level of 224~ ;) We are planning on still working on the Golang > implementation. Sure, that's clear to me. I was referring to it for the similarities it has. Furthermore, the rust implementation allows me to look at it with a different perspective. Anything that helps improve my understanding of the ECC field is welcome. > >> In the end, I got stuck on Mike's original source code due to the >> amount of "extras": >> * Some of the core code generated >> * Decaf >> * Pre-computed multiples (IIRC) >> * constant-time operations >> * Alternative representation, ... IIRC he used the Extended >> representation at the time >> * Not sure if Elligator was also in, in any case, I read about that >> too. > So libdecaf is not only for ed448-Goldilocks. It is multiple purpose > elliptic curve library that internally uses the decaf technique for > several curves, like Iso-25519, ed448-Goldilocks, 25519, p521.. You can > check the multiple data for different curves on the library here: > https://sourceforge.net/p/ed448goldilocks/code/ci/master/tree/src/generator/curve_data.py Okay, this is clear. I read up on the intentions of decaf from the original paper. But skipped the details so far. > > So, basically, what decaf means is to remove cofactors through point > compression, or through quotients and isogenies. The internal > representation of points in libdecaf is as "even" elements of a twisted > Edwards curve with a=-1. Using this subgroup removes a factor of 2 from > the "original" cofactor (note that for ed448-Goldilocks, this is 4). The > remaining factor of 2 is removed with a quotient group: any two points > which differ by an element of the 2- or 4-torsion subgroup are > considered equal to each other. This is applied to several curves. Thanks for clarifying. > > There are precomputed tables and constant-time operations in the > library. The latter is a must for any cryptographic library. You can > read about the reasons for it over here: > https://www.bearssl.org/constanttime.html Don't worry, the importance of constant-time operations is absolutely clear to me. That is also the reason I mentioned it. To make clear that this (and its importance) is "on the radar". > > Yes, there are several places with different coordinates. If I remember > correctly, most of the time extended homogenous projective coordinates > are used, of the form (X : Y : Z : T). Homogeneous projective > coordinates, for example, are of the form (X : Y : Z), which > correspond to the affine point (X/Z, Y/Z) with Z != 0. For extended > homogeneous projective coordinates this will be (X : Y : Z : T), as > said, where T = X^2 / Z. There is a very nice thesis from Hisil, around > this: https://core.ac.uk/download/pdf/10898289.pdf This part is clear to me. So far I've been using hyperelliptic's explicit formulas database. > > Elligator is also included if there is the will to use it, and it is > mostly used internally for tests, I think. What it does is basically > make curve points indistinguishable from uniform random strings. > > Sorry, for the long rant ;) Also clear. The "rant" is fine. It helps touch on some parts. Let's be clear, I intend to make the work as transparent as possible. This includes mentioning things that I'm aware of that have not been implemented yet. (Hence mentioning the constant-time operations.) First, I will make things function, then continue to improve on the other requirements. The advantage then is that I have a reference to compare against in case I fail to do a correct implementation. > >> In the end, I could not figure out which parts were relevant and given >> that I'm new to EC in general, it was too much information for me to >> confidently, reliably extract the critical core parts. Currently, I've >> picked up the necessary basics and noticed in the mean time that a lot >> of OTRv4 depends on RFC 8032 approach, i.s.o. of plain >> Ed448Goldilocks. This also made it significant more approachable. > Don't worry ;). Yes, we mostly used RFC8032 operations and encodings. We > are still working on libgoldilocks, but this library contains only > ed448-Goldilocks: https://github.com/otrv4/libgoldilocks I think the > file: https://github.com/otrv4/libgoldilocks/blob/master/src/eddsa.c can > clarify a lot of things. > >> The Ed448-Goldilocks parts will be in a separate repository. It may be >> far from complete compared to Mike Hamburg's ref. implementation. But >> it should contain most - if not all - of the parts that are not >> strictly specifi
Re: [OTR-dev] OTR version 4 Draft #2
Hey! > Let's be clear, I intend to make the work as transparent as possible. > This includes mentioning things that I'm aware of that have not been > implemented yet. (Hence mentioning the constant-time operations.) > First, I will make things function, then continue to improve on the > other requirements. The advantage then is that I have a reference to > compare against in case I fail to do a correct implementation. Ok :) > I don't think so. Have a look at: > https://github.com/otrv4/otrv4/blame/master/otrv4.md#L956 > That is, line 956 (currently), start of section "Generating ECDH and > DH keys". It lists the following code for generating an (short-lived) > ECDH key: > > ~~~ > generateECDH() > - pick a random value r (57 bytes) > - generate 'h' = KDF_1(0x01 || r, 57). > - prune 'h': the two least significant bits of the first byte are > cleared, all eight bits of the last byte are cleared, and the highest > bit of the second to last byte is set. > - Interpret the buffer as the little-endian integer, forming the > secret scalar 's'. > - Securely delete 'r' and 'h'. > - return our_ecdh.public = G * s, our_ecdh.secret = s > ~~~ > > Notice the second step: generating 'h' using KDF_1 and using an > 58-byte value. > Granted, this is not the long-lived Ed448 signing key, however it is > an ECDH key and generation slighly differs here. > I expect that this is intentional, but in any case, this is the > procedure I was referring to in my previous statement. As you said, this is for the ephemeral keys, where we don't follow the RFC8032. Only for the generation of the long-term keys is that we use the same method as the RCF8032, so the generation and the verification of the signature are the same. If you see the section where the long-term keys are generated, you will see that they are the same as the RFC8032. But the ephemeral keys are generated differently, they don't follow the RFC, and that is why that section don't mention it (in contrast to the other sections, where it is mentioned). Thanks! :) On 3/25/18 11:35 AM, Danny van Heumen wrote: > Hi, > > On 03/25/2018 01:41 AM, Sofia wrote: >> Hey! >> >>> I have found all of the mentioned libraries, except for libgoldilocks. >> This library is a simplification of libdecaf that only takes care of >> ed448-Golidlocks, while still internally using the decaf technique. > > Okay, good to know. This can be a good starting point. > >> >>> Additionally, I found a rust implementation for Ed25519. >> Well, for OTRv4 we use ed448-Goldilocks, because we want to achieve a >> security level of 224~ ;) We are planning on still working on the Golang >> implementation. > > Sure, that's clear to me. I was referring to it for the similarities it > has. Furthermore, the rust implementation allows me to look at it with a > different perspective. Anything that helps improve my understanding of > the ECC field is welcome. > >> >>> In the end, I got stuck on Mike's original source code due to the >>> amount of "extras": >>> * Some of the core code generated >>> * Decaf >>> * Pre-computed multiples (IIRC) >>> * constant-time operations >>> * Alternative representation, ... IIRC he used the Extended >>> representation at the time >>> * Not sure if Elligator was also in, in any case, I read about that >>> too. >> So libdecaf is not only for ed448-Goldilocks. It is multiple purpose >> elliptic curve library that internally uses the decaf technique for >> several curves, like Iso-25519, ed448-Goldilocks, 25519, p521.. You can >> check the multiple data for different curves on the library here: >> https://sourceforge.net/p/ed448goldilocks/code/ci/master/tree/src/generator/curve_data.py > > Okay, this is clear. I read up on the intentions of decaf from the > original paper. But skipped the details so far. >> >> So, basically, what decaf means is to remove cofactors through point >> compression, or through quotients and isogenies. The internal >> representation of points in libdecaf is as "even" elements of a twisted >> Edwards curve with a=-1. Using this subgroup removes a factor of 2 from >> the "original" cofactor (note that for ed448-Goldilocks, this is 4). The >> remaining factor of 2 is removed with a quotient group: any two points >> which differ by an element of the 2- or 4-torsion subgroup are >> considered equal to each other. This is applied to several curves. > > Thanks for clarifying. > >> >> There are precomputed tables and constant-time operations in the >> library. The latter is a must for any cryptographic library. You can >> read about the reasons for it over here: >> https://www.bearssl.org/constanttime.html > > Don't worry, the importance of constant-time operations is absolutely > clear to me. That is also the reason I mentioned it. To make clear that > this (and its importance) is "on the radar". > >> >> Yes, there are several places with different coordinates. If I remember >> correctly, most of the time extended homogenous projective coordinates >> are u
Re: [OTR-dev] OTR version 4 Draft #2
Hi, On 03/19/2018 04:47 PM, Danny van Heumen wrote: * I would be interested to hear if any other implementors are willing to set up a basic "test runner" that could set up otr testclients (in various languages) to chat with each other, as way to do interop testing. I've been thinking about this for a while but never got to actually implementing it. It might be an interesting way to do interop testing between Java, C and Go (etc.) libraries. We've been thinking about this at otr.im for a while but never got to it, i'm interested in helping out in this particular area! * Last I've seen, it wasn't explicitly stated whether or not OTRv2 is to be dropped. In the implementation I should be able to preserve support for OTRv2, but is this desirable? (I know the modes imply OTRv3 and/or 4, still ...) I think once OTRv4 is out of the door, just like OTRv1, OTRv2 should be dropped. @ian? @nik? Best, Jurre ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
Re: [OTR-dev] OTR version 4 Draft #2
On Tue, May 08, 2018 at 02:48:12PM -0400, Jurre van Bergen wrote: > Hi, > > On 03/19/2018 04:47 PM, Danny van Heumen wrote: > >* I would be interested to hear if any other implementors are willing to > >set up a basic "test runner" that could set up otr testclients (in > >various languages) to chat with each other, as way to do interop > >testing. I've been thinking about this for a while but never got to > >actually implementing it. It might be an interesting way to do interop > >testing between Java, C and Go (etc.) libraries. > > We've been thinking about this at otr.im for a while but never got to it, > i'm interested in helping out in this particular area! > >* Last I've seen, it wasn't explicitly stated whether or not OTRv2 is to > >be dropped. In the implementation I should be able to preserve support > >for OTRv2, but is this desirable? (I know the modes imply OTRv3 and/or > >4, still ...) > I think once OTRv4 is out of the door, just like OTRv1, OTRv2 should be > dropped. @ian? @nik? I'm in principle fine with dropping v2 support. I wouldn't mind a quick look-around at what OTR implementations still don't support v3, though. pidgin-otr does, of course. What about Adium? Others? ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
Re: [OTR-dev] OTR version 4 Draft #2
Ian Goldberg writes: > On Tue, May 08, 2018 at 02:48:12PM -0400, Jurre van Bergen wrote: >> I think once OTRv4 is out of the door, just like OTRv1, OTRv2 should be >> dropped. @ian? @nik? > > I'm in principle fine with dropping v2 support. I wouldn't mind a quick > look-around at what OTR implementations still don't support v3, though. > pidgin-otr does, of course. What about Adium? Others? By dropping support, is this about removing it from libotr? I am not quite following standard vs reference implementation vs ? As a user, a few semi-related semi-OT things come to mind: I had perceived Adium to be no longer a viable project. But I see that it has a stable release that's new enough, but the unstable channel is multiple years old. The trac has an expired certificate. So I wonder if Adium is still viable. With pidgin and adium, I have had lost OTR messages, apparently from one side using keys the other side has lost due to restart. I hope v4 has systematic mitigation for this. Conversations has dropped OTR support, leaving OMEMO. I am unclear on the relative merits of OMEMO and OTR, but I've been an OTR user for a really long time (<= 2005), so I have a pro-OTR cultural bias and would like to see it succeed. I wonder if anyone for otr-land has engaged Conversations about this. ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
Re: [OTR-dev] OTR version 4 Draft #2
Here is some information on Adium. * stable The current release is 1.5.10.4 dated 4/27/17. This has: Adium.app/Contents/Frameworks/libotr.framework/Versions/3.2.1/ and does OTRv2 only. With pidgin and libotr 4.1.1, and the pidgin instance *having previously done an OTR exchange with the beta*, OTR got into a terrible, non-useful state. * beta, out of date There was a beta version 1.6hgr5946, dated 9/5/16 (that I can't find online now), and this has: Adium.app/Contents/Frameworks/libotr.framework/Versions/4.0.0/ and does OTR 2 and 3, sending "?OTRv23?". This interoperated with pidgin with libotr 4.1.1. * comments It appears that the 1-year-ago release is still old code, from the 1.5 branch, with old OTR. The beta of 1.6 seems to have been updated to libotr 4 -- but there is no hint of a current beta. I tried to look on trac.adium.im to find out more, but: - the ssl certificate is expired (easy to click through :) - the trac itself throws errors (missing pgsql module) So, it doesn't seem like Adium is currently maintained. The list at https://riseup.net/en/chat/clients politely agrees. ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
Re: [OTR-dev] OTR version 4 Draft #2
Quoting Ian Goldberg (2018-05-08 21:15:00) > On Tue, May 08, 2018 at 02:48:12PM -0400, Jurre van Bergen wrote: > > I think once OTRv4 is out of the door, just like OTRv1, OTRv2 should be > > dropped. @ian? @nik? > > I'm in principle fine with dropping v2 support. I wouldn't mind a quick > look-around at what OTR implementations still don't support v3, though. > pidgin-otr does, of course. What about Adium? Others? AFAIK this overview is up to date on the client implementation of OTR: https://github.com/otrv4/otrv4/wiki/Client-OTR-implementation-overview From it I see only potr not supporting OTRv3, which means weechat and gajim are lagging behind. -- meskio | http://meskio.net/ -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- My contact info: http://meskio.net/crypto.txt -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Nos vamos a Croatan. signature.asc Description: signature ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
Re: [OTR-dev] OTR version 4 Draft #2
Hey! > I think once OTRv4 is out of the door, just like OTRv1, OTRv2 should > be dropped. Yeah, OTRv4 is only backwards compatible with OTRv3.;) Thanks, meskio! Yes, here it is a list of the up to date on the client implementation of OTR: https://github.com/otrv4/otrv4/wiki/Client-OTR-implementation-overview > From it I see only potr not supporting OTRv3, which means weechat and > gajim are lagging behind. potr does have OTRv3 but it is not complete (it lacks instance tags, etc). There has been some work around it these days. Cheers, -- Sofía Celi (aka cherenkov) @claucece / @cherenkov_d EF74 1A5F 5692 E56F 14F6 243C 3992 6144 F89D 996F ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
Re: [OTR-dev] OTR version 4 Draft #2
Hi, I'm Ola - one of the members of the OTRv4 team. I would like to clarify and answer a few of your questions in the following email! Hope it's helpful! > > I'm in principle fine with dropping v2 support. I wouldn't mind a quick > > look-around at what OTR implementations still don't support v3, though. > > pidgin-otr does, of course. What about Adium? Others? > > By dropping support, is this about removing it from libotr? I am not > quite following standard vs reference implementation vs ? Actually, the way we have thought about this is from the specification standpoint. Our current OTRv4 has fallback to OTRv3 - but it doesn't include any facility for falling back to v2. We followed the pattern that the OTRv3 spec used for this. I would also argue that removing support for v2 is about time - v3 adds several things that are quite important, and there are several parameters in v2 that are too small for my comfort. About implementations - we are currently working on a library called libotr-ng - which will be the production level implementation of OTRv4. It does _not_ contain full support for OTRv3 - instead, it links the old libotr implementation for that functionality. Hope this clarifies things! > With pidgin and adium, I have had lost OTR messages, apparently from > one side using keys the other side has lost due to restart. I hope v4 > has systematic mitigation for this. I'm wondering if you could create a new email chain for this so we can discuss it more in depth - v4 does not currently have any specific support for this, and there are good reasons for it - but let's move that to a new thread? > Conversations has dropped OTR support, leaving OMEMO. I am unclear on > the relative merits of OMEMO and OTR, but I've been an OTR user for a > really long time (<= 2005), so I have a pro-OTR cultural bias and > would like to see it succeed. I wonder if anyone for otr-land has > engaged Conversations about this. The situation between OTR and OMEMO is a bit complicated. Short story - from my perspective: OTR and OMEMO have quite different viewpoints and perspectives on several things, including supporting networks other than XMPP, support for SMP, stronger AKE's and several other aspects. We, in the OTRv4 team, believe that the choices we have made in the design of v4 will lead to a significantly stronger protocol, both from a purely cryptographic perspective, but also from a usability and deployability perspective. Not speaking for the OMEMO team, but my impression is that they disagree with this belief. There have been interactions with people involved in Conversations and OMEMO at several times. I would characterize those interactions as not being super constructive. Cheers -- Ola Bini (https://olabini.se) "Yields falsehood when quined" yields falsehood when quined. signature.asc Description: PGP signature ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
Re: [OTR-dev] OTR version 4 Draft #2
On 05/08/2018 03:15 PM, Ian Goldberg wrote: * Last I've seen, it wasn't explicitly stated whether or not OTRv2 is to be dropped. In the implementation I should be able to preserve support for OTRv2, but is this desirable? (I know the modes imply OTRv3 and/or 4, still ...) I think once OTRv4 is out of the door, just like OTRv1, OTRv2 should be dropped. @ian? @nik? I'm in principle fine with dropping v2 support. I wouldn't mind a quick look-around at what OTR implementations still don't support v3, though. pidgin-otr does, of course. What about Adium? Others? As per the excellent list made by the otrv4 team: https://github.com/otrv4/otrv4/wiki/Client-OTR-implementation-overview The only implementation not fully otrv3 would be Potr, that target weechat-otr and Gajim. The problem with Adium, it's badly maintained, it's missing SMP and their Trac SSL certificate has been expired and when you click through the error you get a python stack trace. I really wish Adium was better maintained but at this point, I think people should use Coy.im (for various reasons) over Adium. Which includes an otrv3 implementation in Golang. I think it's more or less safe to say we can drop otrv2. I'll look with koolfy into Potr. Best, Jurre ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
Re: [OTR-dev] OTR version 4 Draft #2
Ola Bini writes: >> > I'm in principle fine with dropping v2 support. I wouldn't mind a quick >> > look-around at what OTR implementations still don't support v3, though. >> > pidgin-otr does, of course. What about Adium? Others? >> >> By dropping support, is this about removing it from libotr? I am not >> quite following standard vs reference implementation vs ? > Actually, the way we have thought about this is from the specification > standpoint. Our current OTRv4 has fallback to OTRv3 - but it doesn't > include any facility for falling back to v2. We followed the pattern > that the OTRv3 spec used for this. I see - that indeed makes sense. > I would also argue that removing support for v2 is about time - v3 > adds several things that are quite important, and there are several > parameters in v2 that are too small for my comfort. > > About implementations - we are currently working on a library called > libotr-ng - which will be the production level implementation of > OTRv4. It does _not_ contain full support for OTRv3 - instead, it > links the old libotr implementation for that functionality. Hope this > clarifies things! It would be good to look at how all the various packaging systems are dealing with the existing libotr. In pkgsrc, it's libotr, version 4.1.1. Some systems seem to have packages called libotr2 and libotr5, or something like that, but I'm not sure why. A big question is if you expect systems to allow building with an OTRv3 implementation that does v2 fallback. I think you are heading for the old library with the old filename and so versions, and a new library with a different name (why ng, vs otr4, because 5 may happen, and ng2 gets awkward). The old library will support v2 compat, but the new library will only have v3 compat, using the old one in a way that doesn't admit v2. Is that what you mean? The real problem is that many in-use clients are using old code. That's more of an intrinsic problem than an OTR problem, but OTR is coming along for the ride. I don't really know what to do, other than having OTR supporters dig in and help the lagging projects along (or declare some of them nonviable). Given this, there's a tension between requiring v3-or-newer only and allowing older things to work for a bit longer in the hopes of getting them updated. Otherwise, we risk two clients that both "support OTR" not interworking, and developers dropping OTR to avoid this. Without thinking too much, I wonder if the best thing is to let the protocol allow v2 (as "MAY") or not allow v2, augment libotr for OTRv4, and have a build-time config to enable or not enable v2, leave it enabled by default at first -- expecting packagers to take your default -- and change the default when you are willing to abandon all systems and users that are v2 only. (If Adium's stable release did v3, I would probably not have suggested this.) >> Conversations has dropped OTR support, leaving OMEMO. I am unclear on >> the relative merits of OMEMO and OTR, but I've been an OTR user for a >> really long time (<= 2005), so I have a pro-OTR cultural bias and >> would like to see it succeed. I wonder if anyone for otr-land has >> engaged Conversations about this. > > The situation between OTR and OMEMO is a bit complicated. Short story > - from my perspective: OTR and OMEMO have quite different viewpoints > and perspectives on several things, including supporting networks > other than XMPP, support for SMP, stronger AKE's and several other > aspects. We, in the OTRv4 team, believe that the choices we have made > in the design of v4 will lead to a significantly stronger protocol, > both from a purely cryptographic perspective, but also from a > usability and deployability perspective. Not speaking for the OMEMO > team, but my impression is that they disagree with this belief. Thanks. It would be nice if thre were a dispassionate comparison someplace. In particular the usability issues are very hard (will follow up separately on that). > There have been interactions with people involved in Conversations and > OMEMO at several times. I would characterize those interactions as not > being super constructive. That's unfortunate. The removal of OTR from Conversations seemed surprising and abrupt to me, but that's all I know. Thanks for answering my questions so thoroughly. ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
Re: [OTR-dev] OTR version 4 Draft #2
Excerpts from Jurre van Bergen's message of May 9, 2018 10:21 pm: > The only implementation not fully otrv3 would be Potr, that target > weechat-otr and Gajim. [SNIP] > I think it's more or less safe to say we can drop otrv2. [SNIP] > I'll look with koolfy into Potr. > > Best, > Jurre > Hello, quick proof-of-life. Work has resumed on potr as of last month, I am working towards using a better underlying crypto library but reading this thread I might just shift priority to the full OTRv3 support. Ideally I would release both "big changes" as a unified 1.1.0 release, but really the sooner a OTRv3 release hits weechat/gajim/PoeZio users, the better. So if OTRv3 support is done first, and I encounter significant delays in the crypto primitives lib integration, 1.1.0 will be the OTRv3 release that I'll push to pip and to the debian people. My goal being to push a OTRv3 release as soon as I can so OTRv2 gets phased out and potr interoperability doesn't leave us stuck with OTRv2. I'll try to have some good news to share here in the coming weeks, if life allows it :) .koolfy pgpot9TI_q7mN.pgp Description: PGP signature ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
Re: [OTR-dev] OTR version 4 Draft #2
Hi Greg, > It would be good to look at how all the various packaging systems are > dealing with the existing libotr. In pkgsrc, it's libotr, version > 4.1.1. Some systems seem to have packages called libotr2 and libotr5, > or something like that, but I'm not sure why. Yes, we noticed the same thing. In fact, the whole landscape of package names for libotr is so confusing, that we realized there was no way we could call our library anything that ended with a number. That's why we came up with libotr-ng. > A big question is if you expect systems to allow building with an OTRv3 > implementation that does v2 fallback. I think you are heading for the > old library with the old filename and so versions, and a new library > with a different name (why ng, vs otr4, because 5 may happen, and ng2 > gets awkward). The old library will support v2 compat, but the new > library will only have v3 compat, using the old one in a way that > doesn't admit v2. Is that what you mean? Yes, that's what I mean. Basically, the main entry point for all OTR messages will always be in libotr-ng - and that piece of code will dispatch to v3 or v4 depending on what's requested. So the v2 code will not be accessible from libotr-ng at all. A plugin could in theory use libotr directly and get access to v2, but I have a hard time seeing how that could be done in a way that's compatible with ALSO using libotr-ng. About the naming - the idea is not that libotr-ng will only be for v4 of the protocol. In fact, let me quickly mention why we didn't do it all in one library, and decided to create a new code base. Fundamentally, the v4 spec is a large upgrade to OTR. It changes a significant amount of things - enough so that the old API wouldn't be compatible at all. Trying to shoehorn v4 into the v3 API would have made for horrible code and terrible usability. And since the internals of v4 are also significantly different, we decided it was cleaner to implement this completely separately. As we all know, code complexity lead to bugs. But, most of these reasons for creating libotr-ng will not be concerns for v5 and upwards. We expect the changes in upcoming versions of OTR to be smaller, and fit well within the concepts of the libotr-ng implementation, so our plan is that libotr-ng will be the codebase for several versions going forward. Hope that makes sense! > The real problem is that many in-use clients are using old code. That's > more of an intrinsic problem than an OTR problem, but OTR is coming > along for the ride. I don't really know what to do, other than having > OTR supporters dig in and help the lagging projects along (or declare > some of them nonviable). Given this, there's a tension between > requiring v3-or-newer only and allowing older things to work for a bit > longer in the hopes of getting them updated. Otherwise, we risk two > clients that both "support OTR" not interworking, and developers > dropping OTR to avoid this. This is definitely a problem, and I'm unclear if there's much we can do to help here, except for pitch in directly on other projects. > Without thinking too much, I wonder if the best thing is to let the > protocol allow v2 (as "MAY") or not allow v2, augment libotr for OTRv4, > and have a build-time config to enable or not enable v2, leave it > enabled by default at first -- expecting packagers to take your default > -- and change the default when you are willing to abandon all systems > and users that are v2 only. (If Adium's stable release did v3, I would > probably not have suggested this.) Well, as I mentioned above, it's not so easy to "augment" libotr for v4 support. In fact, if we were to do that, it would lead to significant differences in API, not to mention code complexity. So, that would mean that older projects wouldn't get access to the v4 functionality anyway. At least now they can continue using libotr without any changes for the time being, and then link against libotr-ng when they are ready to change things. > > The situation between OTR and OMEMO is a bit complicated. Short story > > - from my perspective: OTR and OMEMO have quite different viewpoints > > and perspectives on several things, including supporting networks > > other than XMPP, support for SMP, stronger AKE's and several other > > aspects. We, in the OTRv4 team, believe that the choices we have made > > in the design of v4 will lead to a significantly stronger protocol, > > both from a purely cryptographic perspective, but also from a > > usability and deployability perspective. Not speaking for the OMEMO > > team, but my impression is that they disagree with this belief. > > Thanks. It would be nice if thre were a dispassionate comparison > someplace. In particular the usability issues are very hard (will > follow up separately on that). Yeah. We have tried to come up with something like that, but I don't think we have published it anywhere yet. > > There have been interactions with people involved in Con
Re: [OTR-dev] OTR version 4 Draft #2
On 5/11/18, Ola Bini wrote: > About the naming - the idea is not that libotr-ng will only be for > v4 of the protocol. In fact, let me quickly mention why we didn't do > it all in one library, and decided to create a new code base. > Fundamentally, the v4 spec is a large upgrade to OTR. It changes a > significant amount of things - enough so that the old API wouldn't > be compatible at all. Trying to shoehorn v4 into the v3 API would > have made for horrible code and terrible usability. And since the > internals of v4 are also significantly different, we decided it was > cleaner to implement this completely separately. As we all know, > code complexity lead to bugs. > > But, most of these reasons for creating libotr-ng will not be > concerns for v5 and upwards. We expect the changes in upcoming > versions of OTR to be smaller, and fit well within the concepts of > the libotr-ng implementation, so our plan is that libotr-ng will be > the codebase for several versions going forward. What are your ideas/plans for v5, and how do you envision the v4 API to support those? It sounds like you have a vague vision that would fit within v4's model. What do we gain by including v3 support in libotr-ng? Shouldn't we remove it and avoid complexity? If a client wants to support v3 and v4, and libotr-ng would link v3's lib, then why shouldn't the new code path use libotr-ng for v4 only? Since our last discussion here, I've come to the conclusion that libotr-ng should really reduce its external dependencies and try to find a single crypto primitives lib or bundle those that are written in C or Go anyway. Their implementation doesn't change, and any change in a crypto primitive is dubious and worthy of a lenghty code and crypto review anyway. As you mention the name of lib has been getting confusing, so why not take the opportunity to use a unique name, rather than libotr-ng? ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
Re: [OTR-dev] OTR version 4 Draft #2
Hey, Carsten I think Ola will answer this too, but here are my thoughts: > What are your ideas/plans for v5, and how do you envision the v4 API > to support those? It sounds like you have a vague vision that would > fit within v4's model. We don't have a clear path of when v5 is going to come, as we are dedicating the next months to finish all the implementation of v4 in C. Around ideas we have had for v5, we have thought of including a post-quantum algorithm if they are sufficiently stabled and implemented (in a production-ready way) by the time v5 comes. We will probably update some cryptographic primitives, if efficient ones are available by that time. And lastly, I hope that in that version we have a secure, efficient and good way of supporting group chat (but this needs a lot of work). > What do we gain by including v3 support in libotr-ng? Shouldn't we > remove it and avoid complexity? If a client wants to support v3 and > v4, and libotr-ng would link v3's lib, then why shouldn't the new code > path use libotr-ng for v4 only? This is just to give implements and users time, as v3 is more implemented than v4. A client can have v4 implemented but is talking to a client that only has v3 implemented: the idea is that they can still talk with OTR. Yet, this same client will know how to work when a request from v4 or more comes. > Since our last discussion here, I've come to the conclusion that > libotr-ng should really reduce its external dependencies and try to > find a single crypto primitives lib or bundle those that are written > in C or Go anyway. Their implementation doesn't change, and any change > in a crypto primitive is dubious and worthy of a lenghty code and > crypto review anyway. Well, the libraries we have for crypto primitives per se are "libsodium-dev", "libgcrypt" and "libgoldilocks". The latter is just for the curve. Mmm... what can be pushed for this is including ed448-Goldilocks in libsodium (https://github.com/jedisct1/libsodium/issues/254). I don't know the state of this issue, though.. I'll ask around. > As you mention the name of lib has been getting confusing, so why not > take the opportunity to use a unique name, rather than libotr-ng? We thought of this. But we wanted to follow the pattern of written libraries by using 'lib' and then the name of the protocol. OTR is a unique name anyway. Thanks! -- Sofía Celi (aka cherenkov) @claucece / @cherenkov_d EF74 1A5F 5692 E56F 14F6 243C 3992 6144 F89D 996F ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
Re: [OTR-dev] OTR version 4 Draft #2
Hi, I do want to add to some of these points! > We don't have a clear path of when v5 is going to come, as we are > dedicating the next months to finish all the implementation of v4 in C. > Around ideas we have had for v5, we have thought of including a > post-quantum algorithm if they are sufficiently stabled and implemented > (in a production-ready way) by the time v5 comes. We will probably > update some cryptographic primitives, if efficient ones are available by > that time. And lastly, I hope that in that version we have a secure, > efficient and good way of supporting group chat (but this needs a lot of > work). Personally, I'm strongly against adding group chat to the core protocol - I think if and when a good group chat proposal exists, it should be separate. It would add too much complexity, in my point of view. The main reasons from an API standpoint is things like callbacks to the plugins, how the DAKE is managed and a few other things - all these we think will remain stable for the medium term future. > > What do we gain by including v3 support in libotr-ng? Shouldn't we > > remove it and avoid complexity? If a client wants to support v3 and > > v4, and libotr-ng would link v3's lib, then why shouldn't the new code > > path use libotr-ng for v4 only? > > This is just to give implements and users time, as v3 is more > implemented than v4. A client can have v4 implemented but is talking to > a client that only has v3 implemented: the idea is that they can still > talk with OTR. Yet, this same client will know how to work when a > request from v4 or more comes. There is another reason. It is _not_ an easy task for a plugin to support both v3 and v4 by calling directly into respesctive library. Since v3 and v4 functionality goes semideep into the state machines for the functionality, a plugin would need to duplicate a bunch of the state machine transitions before handing things over to the libraries, which I don't think is something we want. > > Since our last discussion here, I've come to the conclusion that > > libotr-ng should really reduce its external dependencies and try to > > find a single crypto primitives lib or bundle those that are written > > in C or Go anyway. Their implementation doesn't change, and any change > > in a crypto primitive is dubious and worthy of a lenghty code and > > crypto review anyway. > > Well, the libraries we have for crypto primitives per se are > "libsodium-dev", "libgcrypt" and "libgoldilocks". The latter is just for > the curve. Mmm... what can be pushed for this is including > ed448-Goldilocks in libsodium > (https://github.com/jedisct1/libsodium/issues/254). I don't know the > state of this issue, though.. I'll ask around. I don't know how valuable it is to push for goldilocks to be added to libsodium. I personally prefer _more_ smaller libraries, than _fewer_ larger libraries. And I'm personally not at all concerned with our number of dependencies at this point. Cheers -- Ola Bini (https://olabini.se) "Yields falsehood when quined" yields falsehood when quined. signature.asc Description: PGP signature ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
Re: [OTR-dev] OTR version 4 Draft #2
On 5/11/18, Sofia wrote: > We don't have a clear path of when v5 is going to come, as we are > dedicating the next months to finish all the implementation of v4 in C. > Around ideas we have had for v5, we have thought of including a > post-quantum algorithm if they are sufficiently stabled and implemented > (in a production-ready way) by the time v5 comes. We will probably > update some cryptographic primitives, if efficient ones are available by > that time. And lastly, I hope that in that version we have a secure, > efficient and good way of supporting group chat (but this needs a lot of > work). I would actually love to see a forward compatibility mode in existing plugins when v4.5 or v5.1 adds PQ ciphers. You know, automatic upgrade, and later down the road a safe way to block downgrades - unlike TLS. > Well, the libraries we have for crypto primitives per se are > "libsodium-dev", "libgcrypt" and "libgoldilocks". The latter is just for > the curve. Mmm... what can be pushed for this is including > ed448-Goldilocks in libsodium > (https://github.com/jedisct1/libsodium/issues/254). I don't know the > state of this issue, though.. I'll ask around. That sounds like a nice improvement. Hope it gets through. ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
Re: [OTR-dev] OTR version 4 Draft #2
On 5/11/18, Ola Bini wrote: > Personally, I'm strongly against adding group chat to the core > protocol - I think if and when a good group chat proposal exists, it > should be separate. It would add too much complexity, in my point of > view. Group chat has still not been solved in a safe way, so I'd stay clear of it, as well. What I would love to see instead is similar cryptographically safe improvements to Mumble. Sometimes I want to have a voice chat, and given the options and what everyone else is comfortable to use, I avoid voice chats as much as possible. There was ZRTP and then there's Signal's voice chat, but Signal is Signal and I cannot use it for multiple reasons anyway. And ZRTP isn't implemented widely. Of course I could rely on SIP+SRTP, but that has its own problems. It's a shame we're dealing with isolated centralized solutions users have happily adopted in the meantime. And WebRTC is unreliable and buggy, too. I do realize those things work to the satisfaction of some, no need to discuss that. Some is not everyone or including those who care about open and dependable solutions. > There is another reason. It is _not_ an easy task for a plugin to > support both v3 and v4 by calling directly into respesctive library. > Since v3 and v4 functionality goes semideep into the state machines > for the functionality, a plugin would need to duplicate a bunch of > the state machine transitions before handing things over to the > libraries, which I don't think is something we want. I hear you, can you explain how this gets easier with the current design of libotr-ng which links libotr-v3? I may have missed this from past emails, sorry if I did. > I don't know how valuable it is to push for goldilocks to be added > to libsodium. I personally prefer _more_ smaller libraries, than > _fewer_ larger libraries. And I'm personally not at all concerned > with our number of dependencies at this point. Cryptography has no way of dealing with a buggy implementation, so instead of 5 different teams working on 5 or more libraries, I prefer the concentration of skilled developers in 2 or 3 bigger libraries. That means I do trust them to bundle only stuff they care about and understand. I understand your preference for many small libraries, but since those are C libraries and not Rust, Go, Haskell packages, my experience tells me to favor less libs in order to have higher reliability and less issues with system wide installation and distro package management. ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
Re: [OTR-dev] OTR version 4 Draft #2
Hi, > Group chat has still not been solved in a safe way, so I'd stay clear > of it, as well. Completely agree! > What I would love to see instead is similar cryptographically safe > improvements to Mumble. Sometimes I want to have a voice chat, and > given the options and what everyone else is comfortable to use, I > avoid voice chats as much as possible. There was ZRTP and then there's > Signal's voice chat, but Signal is Signal and I cannot use it for > multiple reasons anyway. And ZRTP isn't implemented widely. Of course > I could rely on SIP+SRTP, but that has its own problems. It's a shame > we're dealing with isolated centralized solutions users have happily > adopted in the meantime. And WebRTC is unreliable and buggy, too. I do > realize those things work to the satisfaction of some, no need to > discuss that. Some is not everyone or including those who care about > open and dependable solutions. Yeah, I agree about all these points - we have internally discussed both video and audio, and the many shortcomings with current solutions. OTRv4 could be used for those kinds of solutions, just as OTRv3 could (using the symmetric key, for example). But full solutions would require a very different concept and project. Personally, the authentication mechanisms used in ZRTP and SRTP are starting to feel very scary, in the modern age of good enough voice faking etc. > > There is another reason. It is _not_ an easy task for a plugin to > > support both v3 and v4 by calling directly into respesctive library. > > Since v3 and v4 functionality goes semideep into the state machines > > for the functionality, a plugin would need to duplicate a bunch of > > the state machine transitions before handing things over to the > > libraries, which I don't think is something we want. > > I hear you, can you explain how this gets easier with the current > design of libotr-ng which links libotr-v3? I may have missed this from > past emails, sorry if I did. Sorry, maybe I wasn't very clear about this. Basically, libotr-ng is in charge of the full state-machine for OTR. > Cryptography has no way of dealing with a buggy implementation, so > instead of 5 different teams working on 5 or more libraries, I prefer > the concentration of skilled developers in 2 or 3 bigger libraries. > That means I do trust them to bundle only stuff they care about and > understand. I strongly disagree. No matter how skilled a developer is, a larger library means more internal complexity, something that has been shown increases the likelihood of bugs. I don't trust any developer, no matter how skilled, to not make mistakes. =) Cheers -- Ola Bini (https://olabini.se) "Yields falsehood when quined" yields falsehood when quined. signature.asc Description: PGP signature ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
Re: [OTR-dev] OTR version 4 Draft #2
On 05/11/2018 10:49 AM, Carsten Mattner wrote: > On 5/11/18, Ola Bini wrote: > >> Personally, I'm strongly against adding group chat to the core >> protocol - I think if and when a good group chat proposal exists, it >> should be separate. It would add too much complexity, in my point of >> view. > > Group chat has still not been solved in a safe way, so I'd stay clear > of it, as well. I would also recommend against anticipating group chat support in the libotr-ng API. The current cryptographic protocols for secure group chat have many problems. Nonetheless, based on our current work and my read on the progress of other efforts, it is reasonable to expect one or more good solutions with a common API to appear within the next year. However, our current understanding is that it is not possible to create a simultaneously non-interactive (i.e., suitable for text messaging), authenticated, and deniable group messaging protocol with our current tools. This means that the hypothetical group chat version of libotr-ng (libotr-ng-ng?) will need a significantly different API: either it will need to drop the new non-interactivity support in OTRv4 (dramatically limiting the applications), or deniability (and at that point, why should it be called "off-the-record"?). In either case, designing the current API to anticipate one of these compromises would almost certainly be a mistake for these reasons and also the aforementioned complexity issue. Getting OTRv4 out the door and into users' hands soon is far more important. ~Nik ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
Re: [OTR-dev] OTR version 4 Draft #2
On 5/11/18, Ola Bini wrote: > Yeah, I agree about all these points - we have internally discussed > both video and audio, and the many shortcomings with current > solutions. OTRv4 could be used for those kinds of solutions, just as > OTRv3 could (using the symmetric key, for example). But full solutions > would require a very different concept and project. Personally, the > authentication mechanisms used in ZRTP and SRTP are starting to feel > very scary, in the modern age of good enough voice faking etc. Therefore I will use voice chat only when people insist on it and try to avoid discussing sensitive topics. Man this sucks. > I strongly disagree. No matter how skilled a developer is, a larger > library means more internal complexity, something that has been shown > increases the likelihood of bugs. I don't trust any developer, no > matter how skilled, to not make mistakes. =) It doesn't necessarily increase complexity as more often than not it's just a well-curated collection of primitives with a common abstraction on top. I still understand what you're saying and don't really disagree, but I don't consider trusting 5 independent projects an improvement over trusting just gcrypt, sodium and one of the OpenSSL branches. Either way this is a philosophical and highly speculative topic, no need in going on. I believe we've had different priorities and possibly different experiences with software quality and have therefore formed different preferences. Nothing unusual or surprising there. ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
Re: [OTR-dev] OTR version 4 Draft #2
On 5/11/18, Nik Unger wrote: > In either case, designing the current API to anticipate one of these > compromises would almost certainly be a mistake for these reasons and > also the aforementioned complexity issue. Getting OTRv4 out the door and > into users' hands soon is far more important. Totally agree that getting this finished and into the plugins, which will take time, is most important. Maybe it's time to prototype libotr-ng integration in pidgin-otr and friends and possibly incorporate feedback before the first stable release. ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
Re: [OTR-dev] OTR version 4 Draft #2
Hey, > Therefore I will use voice chat only when people insist on it > and try to avoid discussing sensitive topics. Man this sucks. Indeed. =( =( =( > > I strongly disagree. No matter how skilled a developer is, a larger > > library means more internal complexity, something that has been shown > > increases the likelihood of bugs. I don't trust any developer, no > > matter how skilled, to not make mistakes. =) > > It doesn't necessarily increase complexity as more often than not > it's just a well-curated collection of primitives with a > common abstraction on top. I still understand what you're > saying and don't really disagree, but I don't consider > trusting 5 independent projects an improvement over > trusting just gcrypt, sodium and one of the OpenSSL > branches. > > Either way this is a philosophical and highly speculative topic, > no need in going on. I believe we've had different priorities > and possibly different experiences with software quality and > have therefore formed different preferences. Nothing unusual > or surprising there. Yep, completely agree that this is both individual and specualtive. Something to discuss over a beer sometime instead, maybe. =) Cheers -- Ola Bini (https://olabini.se) "Yields falsehood when quined" yields falsehood when quined. signature.asc Description: PGP signature ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
Re: [OTR-dev] OTR version 4 Draft #2
Hey, > > In either case, designing the current API to anticipate one of these > > compromises would almost certainly be a mistake for these reasons and > > also the aforementioned complexity issue. Getting OTRv4 out the door and > > into users' hands soon is far more important. > > Totally agree that getting this finished and into the plugins, > which will take time, is most important. Maybe it's time to > prototype libotr-ng integration in pidgin-otr and friends and > possibly incorporate feedback before the first stable release. In fact, when we started doing libotr-ng we also started on prototype pidgin-otr implementation. A first version of libotr-ng worked quite well from inside of Pidgin - however, things on the spec side have now raised away and we haven't looked at the Pidgin side for a while. We do expect to re-initiate that work very soon. We are of course using these experiences in our thinking around the design of the API for libotr-ng. Cheers -- Ola Bini (https://olabini.se) "Yields falsehood when quined" yields falsehood when quined. signature.asc Description: PGP signature ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
Re: [OTR-dev] OTR version 4 Draft #2
Hey! > In either case, designing the current API to anticipate one of these > compromises would almost certainly be a mistake for these reasons and > also the aforementioned complexity issue. Getting OTRv4 out the door > and into users' hands soon is far more important. Yes, completely agree. We are absolutely not doing this. It was just an idea of something to would be nice to have on the future. Thanks! -- Sofía Celi (aka cherenkov) @claucece / @cherenkov_d EF74 1A5F 5692 E56F 14F6 243C 3992 6144 F89D 996F ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
Re: [OTR-dev] OTR version 4 Draft #2
Hey! > Totally agree that getting this finished and into the plugins, > which will take time, is most important. Maybe it's time to > prototype libotr-ng integration in pidgin-otr and friends and > possibly incorporate feedback before the first stable release. Yes! We are taking in consideration developing the pidgin-otr plugin with libotr-ng as part of the current work. Once that libotr-ng reaches a stable place, we will focus our full attention into the plugin, and, of course, send it over here for discussions and review. Thanks! -- Sofía Celi (aka cherenkov) @claucece / @cherenkov_d EF74 1A5F 5692 E56F 14F6 243C 3992 6144 F89D 996F ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
Re: [OTR-dev] OTR version 4 Draft #2
Hey, Daniel > Work has resumed on potr as of last month, I am working towards using > a better underlying crypto library but reading this thread I might > just shift priority to the full OTRv3 support. While I think that having the full OTRv3 support is needed, using a better underlying crypto library will be very needed for future support too ;) > My goal being to push a OTRv3 release as soon as I can so OTRv2 gets > phased out and potr interoperability doesn't leave us stuck with > OTRv2. This is true. > I'll try to have some good news to share here in the coming weeks, if > life allows it Thanks!! -- Sofía Celi (aka cherenkov) @claucece / @cherenkov_d EF74 1A5F 5692 E56F 14F6 243C 3992 6144 F89D 996F signature.asc Description: OpenPGP digital signature ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
Re: [OTR-dev] OTR version 4 Draft #2
On Fri, 11 May 2018 14:49:37 + Carsten Mattner wrote: > and then there's Signal's voice chat, but Signal is Signal and I cannot use > it for > multiple reasons anyway. Other than Signal being centralized, what problems do you see? Why are you unable to use it? -- Alex ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
Re: [OTR-dev] OTR version 4 Draft #2
On 5/11/18, Alex wrote: > On Fri, 11 May 2018 14:49:37 + > Carsten Mattner wrote: > >> and then there's Signal's voice chat, but Signal is Signal and I >> cannot use it for multiple reasons anyway. > > Other than Signal being centralized, what problems do you see? Why > are you unable to use it? 1. no proper native desktop client 2. disagreement over how Moxie handles criticism and follows the rule of "dissuading" alternative implementation to keep control and compatibility in check. 3. the inability to use without a phone number and the loss of the profile when phone number becomes unoperational 4. no federation with anything, caused mainly by (2) 5. its SPoF Signal servers for circumventing local regimes or store and forward of messages when receiver is offline 6. their clients are slow and bulky and isolated, not integrating with anything else 7. another closed system trying to grab users, leading to users signing up at another system to connect with friends. And now we have Discord getting popular. This has to stop before it becomes normality and everyone forgets why P2P was pursued, but building a closed messenger is a business rather than a service to users. They know that building a P2P system that can have 100's of different servers and clients makes no money, so nobody invest in the idea. Yes, I've tried Matrix, and right now it's a hot mess. Tox and Ring equally or even worse. Yet, convenience trumps and people use Kik and Snapchat for sexting with strangers. Even if 2-7 wouldn't be issues, I can't use a tool day to day which doesn't have native desktop clients to choose from. The way OTR works, XMPP doesn't care and I can use any server or set up my own without running into problems when connecting chatting with other users. Those users don't have to sign up or use a different tool. Heck, even IRC+OTR is better in that regard than the popular messaging services. Bittorrent is still going strong, yet we still have no DHT based true P2P messaging solution in wide use. At least with XMPP, we're not bound to a single server but can interoperate and move around like in real life. When I move around with XMPP, my contacts just need to add my new id to their roster, they don't have to install a new client or sign up somewhere. The cynic in me thinks that there's powers that prefer centralized solutions that can be controlled while doing so for true P2P would require bad mouthing the service like they did Bittorrent and Tor. You know, "only use P2P". It's high time P2P is adopted in commercial mainstream tools for it to lose its stigma it acquired in the last decade. XMPP+OTR is the practical middle ground we can get for the moment. ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
