End to End Encryption SIG - 2022-10-22


  1. daags has joined

  2. belong has left

  3. belong has joined

  4. belong has left

  5. belong has joined

  6. belong has left

  7. belong has joined

  8. Jeroen has left

  9. test_h has joined

  10. test_h has left

  11. test_h has joined

  12. test_h

    Does anyone know OMEMO? Are the ciphers restricted to AES-128 and AES-256. or can better ones be used?

  13. moparisthebest

    What's better

  14. test_h

    Good - question - simple answer: anything but AES? Something with pretty curves?

  15. test_h

    Or mabe I'm wrong - maybe it does support X25519 https://ianix.com/pub/curve25519-deployment.html but just not the code I was looking at... Anyone know?

  16. Jeroen has joined

  17. L29Ah

    test_h: AES is symmetric, 25519 is asymmetric, they are used for different use cases

  18. Jeroen has left

  19. L29Ah

    hypothetically you can use an asymmetric cypher instead of a symmetric one, but it will be grossly inefficient for the same level of security

  20. test_h

    I withdraw the question and will come back when I've read the code more completely. It was my first look at the python-omemo code and I was surprised to see AES-128

  21. test_h

    # Prepare AES-GCM key and IV aes_gcm_iv = os.urandom(12) aes_gcm_key = os.urandom(16) aes_secret_data = aes_gcm_key if plaintext is not None: # Create the AES-GCM instance aes_gcm = Cipher( algorithms.AES(aes_gcm_key), modes.GCM(aes_gcm_iv), backend=default_backend() ).encryptor()

  22. test_h

    But that may be just a tiny part of the negotiation and exchange.

  23. test_h

    On a more birds eye view, I think my question was more like: is OMEMO a negotiation protocol where weak or maybe stronger ciphers can be chosen for any given connection, or does the protocol firmly specify all the ciphers?

  24. trollge has joined

  25. test_h has left

  26. test_h has joined

  27. test_h has left

  28. atomicwatch has joined

  29. atomicwatch has left

  30. atomicwatch has joined

  31. *IM* has joined

  32. yvo has joined

  33. atomicwatch has left

  34. atomicwatch has joined

  35. atomicwatch has left

  36. atomicwatch has joined

  37. atomicwatch has left

  38. atomicwatch has joined

  39. atomicwatch has left

  40. atomicwatch has joined

  41. *IM* has left

  42. test_h has joined

  43. atomicwatch has left

  44. atomicwatch has joined

  45. tritium has joined

  46. *IM* has joined

  47. MSavoritias (fae,ve) has joined

  48. Titi has joined

  49. atomicwatch has left

  50. MSavoritias (fae,ve)

    https://xmpp.org/extensions/xep-0384.html The specification is here ^ test_h

  51. atomicwatch has joined

  52. *IM* has left

  53. *IM* has joined

  54. test_h

    Yes thanks; I read that. It's why I asked the question, because the spec says: "The encryption step uses authenticated encryption consisting of AES-256-CBC with HMAC-SHA-256." but the code seems to be saying AES-128 "aes_gcm_key = os.urandom(16)"

  55. Martin has left

  56. Martin has joined

  57. *IM* has left

  58. tim has left

  59. larma

    test_h: that's for the old version of OMEMO, AES-256-CBC + HMAC-SHA-256 is used since OMEMO 0.4.0, before that it was AES-128-GCM

  60. *IM* has joined

  61. test_h

    What does code have to do to keep up these days :-) Thanks; so the answer is that OMEMO is NOT a negotiated protocol and the ciphers are fixed in the spec. Thanks for clarifying for me.

  62. test_h

    One more ignorant question from a crypto noob: OMEMO is a specification tailored to XMPP. If you stripped out the XMPP part for argument's sake, is it different from NoiseC as a protocol>

  63. larma

    Well, clients negotiate the version of OMEMO to use and thereby negotiate the ciphers ;)

  64. test_h

    OK - the version gets negotiated - no problem.

  65. test_h

    Is NoiseC fundamentally similar to OMEMO-XMPP?

  66. test_h

    (apply grains of salt liberally.)

  67. *IM* has left

  68. yvo has left

  69. tim has joined

  70. test_h has left

  71. test_h has joined

  72. test_h has left

  73. test_h has joined

  74. test_h has left

  75. test_h has joined

  76. test_h has left

  77. test_h has joined

  78. test_h has left

  79. test_h has joined

  80. test_h has left

  81. test_h has joined

  82. test_h has left

  83. test_h has joined

  84. test_h has left

  85. test_h has joined

  86. test_h has left

  87. test_h has joined

  88. melvo has left

  89. test_h has left

  90. tritium has left

  91. dequbed

    If you by "NoiseC" mean the Noise protocol then no.

  92. Millesimus has left

  93. melvo has joined

  94. trollge

    is effective key length of 56 bit for AES-XTS generally considered secure for personal cybersecurity needs?..

  95. trollge

    and what does "effective" mean?..

  96. *IM* has joined

  97. trollge

    I've been browsing a prominent AV vendor page and it says it offers software that can encrypt files using AES with this cipher mode... I lmao'ed but now I wonder how different "effective key length" is different from "key length"...

  98. Martin

    larma: You recently mentioned that you don't like Ox anymore. Could you elaborate what you don't like? I'm really hoping that MUC and file upload will get specified and clients will adapt it to end the Omemo key mess and make MAM usable for new clients.

  99. test_h has joined

  100. trollge

    https://crypto.stackexchange.com/questions/24210/128-bit-3des-key-and-aes-key-whats-the-difference > If a 128 bit triple DES key is created the amount of effective key bits - the bits actually used in the protocol - is 112 bits. This is because there is one bit (the least significant one) in each byte assigned to create odd parity. This way the correctness of the key can be validated with certainty if a bit is flipped by mistake. Some implementations require these parity bits to be set correctly, other implementations simply ignore the parity bits. it looks like effectiveness of the key measures how much enthropy the key's bits actually provide

  101. larma

    Martin, I don't like the PGP part of it. PGP is a complex message and key format, which we don't make any use of. But using those complex formats adds a lot of complexty to implementations

  102. dequbed

    trollge: That doesn't apply to AES though, it has a dense keyspace and doesn't do parity bits.

  103. trollge

    I know, it's DES-specific...

  104. dequbed

    That being said, maybe somebody just used their DES key for AES by just doing a K || K. Then it would hold up but I do hope that's not the case.

  105. Martin

    Hmm, not sure if it makes implementations complex. I found it pretty straightforward compared to OMEMO which gives me headache when looking at the XEP only. 😂

  106. Martin

    I think the complexity is handled by the PGP lib and I am only doing the easy part.

  107. Martin

    🙂

  108. dequbed

    That doesn't mean the complexity goes away and clients that can't use your PGP lib suffer doubly

  109. Martin

    Shouldn't there be a reasonable PGP lib for every language?

  110. dequbed

    No?

  111. tritium has joined

  112. *IM* has left

  113. Martin

    Don't know. That's why I asked.

  114. daags has left

  115. daags has joined

  116. dequbed

    No there shouldn't and while I haven't exhaustively checked, I'd assume there isn't.

  117. MSavoritias (fae,ve)

    I doubt omemo will go away in favor of ox for a lot of reasons. One being the less privacy which doesnt mabe sense as default. Also the keys are harder to manage with ox unless you cut corners. Also library support. Is there actually anything outside of gnu? I dont have that much confidence in the project imo

  118. Millesimus has joined

  119. Martin

    > I doubt omemo will go away in favor of ox for a lot of reasons. Who said it should? Ox is the successor of 0027 and not of OMEMO. > One being the less privacy which doesnt mabe sense as default. There are people who would trade forward secrecy and deniability for working MAM. I think Ox is good enough for a default encryption to have no unencrypted messages stored on the server and those who need whistle blower or political activist grade security could enable OMEMO.

  120. Martin

    > Also the keys are harder to manage with ox unless you cut corners. Not sure what you mean by this. Ox should get the ability to transfer the encrypted private key via pep (like an autocrypt setup message). But I don't know of any client implementing it yet. > Also library support. Is there actually anything outside of gnu? I dont have that much confidence in the project imo I am using protonmail/gopenpgp and there is also Sequoia.

  121. MSavoritias (fae,ve)

    Can you please stop referring to people who want forward secrecy only the ones being whistleblowers or something? I get if you dont like the privacy community but lets not devalue the conversation like this.

  122. trollge

    MSavoritias (fae,ve)‎: u sure you didn't confuse your recipient?

  123. Martin

    > Can you please stop referring to people who want forward secrecy only the ones being whistleblowers or something? I didn't say that. I called it whistle blower grade security. I didn't say people who want it have to be whistle blowers. > I get if you dont like the privacy community but lets not devalue the conversation like this. I also didn't say I don't like them. I just like to have a choice to also use encryption without FS and stuff which makes mam usable on new devices. Either you got me wrong or you want to push me into a corner where I look like I want to take you FS and stuff away. So far I assume the first and hope you read my messages again more carefully.

  124. tritium has left

  125. Link Mauve has left

  126. *IM* has joined

  127. Millesimus has left

  128. trollge has left

  129. trollge has joined

  130. Link Mauve has joined

  131. larma

    Martin: just hiding the complexity in a library doesn't mean it's not there. As a whole thing I would say OX is more complex to implement than OMEMO. Yes, often enough there are libraries that can take a lot of the work from you. I'm also not saying that OMEMO is much better in this regard, but its complexity is mostly due to cryptographic complexity of its properties. I'm rather proposing to build a simple encryption protocol with the same properties as OX, just minus the PGP stuff: One asymmetric key per user used for both, signing an encrypting, public key and encrypted private key on PEP. Asymmetric key is used to encrypt a symmetric key, which is then used to SCE encrypt the content. You probably want to use ed25519/x25519 for asymmetric and ChaCha or similar for symmetric, which would give you great performance even on low end devices.

  132. Martin

    Indeed using ed25519/x25519 keys with Ox is a lot faster than RSA 4096bit. But it seems programs using gnupg are especially slow. No idea if sequoia is better in this regard.

  133. trollge has left

  134. belong has left

  135. Millesimus has joined

  136. larma has left

  137. larma has joined

  138. Martin

    But I think the Ox creators did choose PGP because it is already widespread and has existing libs and they don't have to invent their own crypto.

  139. tritium has joined

  140. test_h has left

  141. Millesimus has left

  142. Millesimus has joined

  143. *IM* has left

  144. Jeroen has joined

  145. Jeroen has left

  146. *IM* has joined

  147. belong has joined

  148. Millesimus has left

  149. larma has left

  150. Millesimus has joined

  151. *IM* has left

  152. larma has joined

  153. trollge has joined

  154. tritium has left

  155. larma has left

  156. larma has joined

  157. Millesimus has left

  158. Millesimus has joined

  159. *IM* has joined

  160. melvo has left

  161. Millesimus has left

  162. Millesimus has joined

  163. tritium has joined

  164. larma has left

  165. trollge has left

  166. Millesimus has left

  167. Millesimus has joined

  168. larma has joined

  169. *IM* has left

  170. trollge has joined

  171. *IM* has joined

  172. trollge has left

  173. *IM* has left

  174. trollge has joined

  175. trollge has left

  176. belong has left

  177. belong has joined

  178. Jeroen has joined

  179. Jeroen has left

  180. tritium has left

  181. belong has left

  182. belong has joined

  183. melvo has joined

  184. belong has left

  185. belong has joined

  186. belong has left

  187. belong has joined

  188. trollge has joined

  189. belong has left

  190. belong has joined

  191. tritium has joined

  192. *IM* has joined

  193. tritium has left

  194. tritium has joined

  195. tritium has left

  196. tritium has joined

  197. test_h has joined

  198. test_h has left

  199. test_h has joined

  200. test_h has left

  201. test_h has joined

  202. test_h has left

  203. test_h has joined

  204. test_h has left

  205. test_h has joined

  206. test_h has left

  207. test_h has joined

  208. test_h has left

  209. test_h has joined

  210. test_h has left

  211. test_h has joined

  212. test_h has left

  213. test_h has joined

  214. test_h has left

  215. test_h has joined

  216. test_h has left

  217. test_h has joined

  218. test_h has left

  219. test_h has joined

  220. test_h has left

  221. test_h has joined

  222. test_h has left

  223. test_h has joined

  224. test_h has left

  225. test_h has joined

  226. test_h

    Thanks dequbed : noob level question rephrased - If a team was looking at using the Noise protocol for the AKE part of a chat/AV application, and could also use "OMEMO minus XMPP" as a protocol that might give them interoperability with XMPP, are there clear reasons to use the Noise protocol over OMEMO-XMPP?

  227. TheCoffeMaker has left

  228. *IM* has left

  229. test_h

    (I know OMEMO is more than handshake, but this question just focuses on that part.)

  230. test_h

    (("might give them interoperability" now or some day in the future.))

  231. moparisthebest

    test_h: I think the thing that you are missing is there is absolutely nothing wrong or weak about AES

  232. moparisthebest

    It's even safe against the non-existent theoretical "quantum computers"

  233. Link Mauve

    moparisthebest, some AES methods are weak against wrong usage of them, for instance using AES-CBC without integrity checks.

  234. test_h

    For me, "quantum computers" died with Schrodinger's cat :-)

  235. moparisthebest

    Sure some modes aren't good, but AES is fine

  236. *IM* has joined

  237. test_h

    OK AES is fine, and OMEMO 0.4.0 is fine AES. I'm a noob who knows nothing about the NoiseP and little about OMEMO except that if they had the crypto equivalent in their handskake they might be in a better position to interoperate with XMPP/OMEMO. So is NoiseP fundamentally different from the AKE in OMEMO.

  238. TheCoffeMaker has joined

  239. trollge

    > some AES methods are weak against wrong usage of them, for instance using AES-CBC without integrity checks. Link Mauve: u mean cipher codebook mode? Isn't it purely theoretical mode that should never be used irl because of its awful anti-cryptanalysis properties?

  240. trollge

    No taking in account CBC-like modes as XTS

  241. Link Mauve

    trollge, dunno, I’m not really good at cryptography, but it’s the only AES mode available on the AES engine of the Wii, so it’s the one I’ve played with the most.

  242. trollge

    Oh it stands for Cipher blockChaining... all good with that one

  243. Link Mauve

    trollge, I’m not aware of anything wrong if you check the integrity of the data, e.g. through a hash mechanism.

  244. Millesimus has left

  245. test_h has left

  246. Millesimus has joined

  247. Millesimus has left

  248. Millesimus has joined

  249. test_h has joined

  250. Millesimus has left

  251. Millesimus has joined

  252. test_h

    Thanks dequbed : noob level question rephrased - If a team was looking at using the Noise protocol for the AKE part of a chat/AV application, and could also use "OMEMO minus XMPP" as a protocol that might give them interoperability with XMPP, are there clear reasons to use the Noise protocol over OMEMO-XMPP? (I know OMEMO is more than handshake, but this question just focuses on that part.) (("might give them interoperability" now or some day in the future.))

  253. test_h has left

  254. TheCoffeMaker has left

  255. MSavoritias (fae,ve) has left

  256. trollge has left

  257. TheCoffeMaker has joined

  258. test_h has joined

  259. trollge has joined

  260. *IM* has left

  261. melvo has left

  262. melvo has joined

  263. *IM* has joined

  264. belong has left

  265. tim has left

  266. belong has joined

  267. test_h has left

  268. tim has joined

  269. test_h has joined

  270. trollge has left

  271. test_h has left

  272. Titi has left

  273. tritium has left

  274. *IM* has left

  275. test_h has joined