Tobias Markmann: > On Sun, Oct 2, 2016 at 1:48 PM, Ximin Luo <infini...@pwned.gg> wrote: > >> For sure, but then it should be called a common encryption component and >> *not* "standardisation of a next-gen messaging protocol" (the subject of >> this thread). > > True. Maybe I've misinterpreted Tony's message. IMO standardization of the > crypto protocol and its wire representation would have greater chances to > wide adoption. [..]
I can see the benefits in agreeing to standardise a cryptographic component including the packet flows and algorithms, but standardising the exact wire representation is less useful (and people have less incentive to do it) if there is no need for interoperation. For example, even ed25519 private keys have no standard format; there are about 3 different ones and everyone picks their own. Not that this *particular example* is a big deal, I'm just demonstrating how lack of interoperability reduces the need to standardise. In terms of adoption of a standard *messaging protocol*, well one doesn't succeed by not trying. I know everyone has the XKCD standardisation comic in mind, but funnily enough both the examples in that now have standards. :) And Matrix and OMEMO are already examples of efforts in this area. (I happen to disagree with parts of their approaches, but that's another topic.) > [..] It wouldn't just be another messaging protocol for end-users > but rather a core e2e encryption component that could be used in current > and future protocols to come. Similar to TLS that is used by many other > protocols. > Not to disagree, but just a nitpick so future people don't extend this in the wrong way: I think an analogy to WebRTC would be more accurate here. TLS servers and clients communicate directly and the application "goes through" TLS; nothing touches unencrypted TCP directly. However with the Signal ratchet and with WebRTC, there are other components operating on the side that the application chooses, that bypasses Signal and WebRTC respectively. (Sometimes there is quite a lot here, like file transfer metadata stanzas in OMEMO.) X -- GPG: ed25519/56034877E1F87C35 GPG: rsa4096/1318EFAC5FBBDBCE https://github.com/infinity0/pubkeys.git _______________________________________________ Messaging mailing list Messaging@moderncrypto.org https://moderncrypto.org/mailman/listinfo/messaging
