End to End Encryption SIG - 2021-12-28


  1. hello has joined
  2. Titi has left
  3. Millesimus has joined
  4. hello has left
  5. Millesimus has left
  6. Seve has joined
  7. thilo.molitor has left
  8. thilo.molitor has joined
  9. Seve has left
  10. hello has joined
  11. hello has left
  12. Seve has joined
  13. hello has joined
  14. Millesimus has joined
  15. meeson_ has left
  16. meeson_ has joined
  17. msavoritias has joined
  18. Titi has joined
  19. Jeroen has joined
  20. Jeroen has left
  21. larma has left
  22. larma has joined
  23. hello has left
  24. Thilo Molitor has left
  25. Thilo Molitor has joined
  26. Jeroen has joined
  27. Jeroen has left
  28. Jeroen has joined
  29. Jeroen has left
  30. Jeroen has joined
  31. Jeroen has left
  32. Jeroen has joined
  33. Jeroen has left
  34. Jeroen has joined
  35. Jeroen has left
  36. Jeroen has joined
  37. Jeroen has left
  38. Jeroen has joined
  39. Jeroen has left
  40. Jeroen has joined
  41. Jeroen has left
  42. Jeroen has joined
  43. Jeroen has left
  44. Chuck has joined
  45. Jeroen has joined
  46. Jeroen has left
  47. Jeroen has joined
  48. atomicwatch has joined
  49. Jeroen has left
  50. tritium has left
  51. Jeroen has joined
  52. Jeroen has left
  53. Jeroen has joined
  54. hello has joined
  55. hello has left
  56. Seve has left
  57. Seve has joined
  58. Titi has left
  59. Titi has joined
  60. hello has joined
  61. tritium has joined
  62. Thilo Molitor has left
  63. Thilo Molitor has joined
  64. atomicwatch has left
  65. atomicwatch has joined
  66. tritium has left
  67. tritium has joined
  68. meeson_ has left
  69. meeson_ has joined
  70. Titi has left
  71. meeson_ has left
  72. melvo has left
  73. meeson_ has joined
  74. atomicwatch has left
  75. atomicwatch has joined
  76. yvo has left
  77. yvo has joined
  78. Millesimus has left
  79. tritium has left
  80. hello has left
  81. meeson_ has left
  82. meeson_ has joined
  83. tritium has joined
  84. Millesimus has joined
  85. hello has joined
  86. Jeroen has left
  87. Jeroen has joined
  88. hello has left
  89. qy has joined
  90. melvo has joined
  91. qy o/
  92. Jeroen has left
  93. John Angelo has left
  94. qy Is anyone aware of why session_pre_key_bundle in libomemo-c/libsignal-protocol-c indicates only one prekey, whereas both prekeymessages and bundles in xep-0384 indicate specifically more than one?
  95. Chuck has left
  96. moparisthebest Which version of 384 are you looking at? The current one no one implements or the previous one that everyone implements?
  97. qy Both, tbh
  98. qy Afaict so far the main difference is the namespaces
  99. qy Ive mainly focused on the axolotl version, since it's more accurate
  100. qy I think i see now that only one prekey is used in a signal session, but i still have no clue how to feed an xmpp bundle into libsignal based on that
  101. qy Or does libsignal not store bundles themselves?
  102. qy Perhaps they remain ephemeral, requested on need, and only sessions are stored?
  103. qy My understanding was that bundles were stored too
  104. melvo qy: You upload multiple pre keys. A device building a session with your device, takes one of them and calls `session_pre_key_bundle()`. That pre key is passed to `session_pre_key_bundle()`.
  105. melvo qy: You upload multiple pre keys. A device building a session with your device takes one of them and calls `session_pre_key_bundle()`. That pre key is passed to `session_pre_key_bundle()`.
  106. melvo moparisthebest‎: UWPX already implemented the latest version and we are working on an implementation for QXmpp / Kaidan.
  107. melvo You have to remove that pre key from your published bundle and publish a new one in order to you ensure that other devices do not take an already used pre key.
  108. qy I follow :) are sessions created reciprocally? i.e. Must i create one in response to someone creating one with me, or is one direction enough?
  109. melvo libomemo-c stores pre keys with `store_pre_key()` of the struct `signal_protocol_pre_key_store`.
  110. qy I think i was mainly thrown because libsignal makes no reference to randomly choosing from a prekey list
  111. qy > melvo wrote: > libomemo-c stores pre keys with `store_pre_key()` of the struct `signal_protocol_pre_key_store`. For local prekeys, right?
  112. qy `store_pre_key(uint32_t pre_key_id, uint8_t *record, size_t record_len, void *user_data)` has no discriminator for foreign keys
  113. qy I've implemented all the stores
  114. melvo Signal has a better approach for distributing pre keys. A device request one pre key, the server returns only one and removes it automatically. In OMEMO, we use PubSub and it has no such logic. So, we have to retrieve all pre keys and take care of them by ourselves.
  115. melvo Signal has a better approach for distributing pre keys. A device requests one pre key, the server returns only one and removes it automatically. In OMEMO, we use PubSub and it has no such logic. So, we have to retrieve all pre keys and take care of them by ourselves.
  116. melvo >For local prekeys, right? Yes.
  117. qy Ahh.
  118. melvo > `store_pre_key(uint32_t pre_key_id, uint8_t *record, size_t record_len, void *user_data)` has no discriminator for foreign keys You only have to store your own pre keys.
  119. qy Right, i think im clear on this now
  120. tritium has left
  121. tritium has joined
  122. Jeroen has joined
  123. Jeroen has left
  124. Jeroen has joined
  125. melvo 🙂
  126. Jeroen has left
  127. *IM* has joined
  128. hello has joined
  129. hello has left
  130. Jeroen has joined
  131. Jeroen has left
  132. Jeroen has joined
  133. Jeroen has left
  134. Jeroen has joined
  135. Jeroen has left
  136. Jeroen has joined
  137. Jeroen has left
  138. Thilo Molitor has left
  139. Jeroen has joined
  140. Jeroen has left
  141. qy Hmm, just realised the biggest issue is that i need to close the loop and fully implement callbacks
  142. qy Since it uses pubsub rather than persistence
  143. tritium has left
  144. Thilo Molitor has joined
  145. Jeroen has joined
  146. Jeroen has left
  147. sequals has left
  148. sequals has joined
  149. hello has joined
  150. Jeroen has joined
  151. Jeroen has left
  152. msavoritias has left
  153. Jeroen has joined
  154. melvo qy: What client is it?
  155. qy melvo: https://github.com/bqv/weechat-xmpp
  156. qy Another question, also
  157. qy Since clients have multiple devices, does that imply a session should be created for each device? Or one with every device as a recipient?
  158. qy I don't quite follow that workflow yet
  159. meeson_ has left
  160. hello has left
  161. melvo Your client builds a session for each device (in practice, a client instance) in your contact's device list and for each device in your own device list but not to your own device.
  162. hello has joined
  163. Jeroen has left
  164. Jeroen has joined
  165. melvo Unfortunately, the term *device* is not precise because multiple client instances may run on one physical device. But in the world of Signal there is only one client instance per device...
  166. Jeroen has left
  167. Jeroen has joined
  168. melvo has left
  169. melvo has joined
  170. qy Yeah that makes sense, a device is a client. So is the group_session code used to make things work for all present clients?
  171. qy Or, is every stanza sent done n times for each client?
  172. qy I feel like if it was the latter i'd have noticed
  173. sequals has left
  174. Jeroen has left
  175. meeson_ has joined
  176. qy Yes, all in one, per the spec. I thought libsignal had something for multiple recipients but maybe i need to do that manually?
  177. Jeroen has joined
  178. vanitasvitae qy: just add all recipient devices to the message header
  179. vanitasvitae The message itself is only encrypted once.
  180. vanitasvitae And only one stanza is being sent
  181. vanitasvitae But each recipient can encrypt it (hopefully)
  182. melvo > Yeah that makes sense, a device is a client. And each client instance could even use multiple sessions for communicating with same end. Thus, I prefer the term endpoint. Enough meta discussion 😁
  183. atomicwatch has left
  184. atomicwatch has joined
  185. meeson_ has left
  186. melvo > Yeah that makes sense, a device is a client. And each client instance could even use multiple sessions for communicating with same end. Thus, I prefer the term *endpoint*. Enough meta discussion 😁
  187. qy Right, so the message is the payload, and each device gets a the key encrypted to their prekey in the header. But how does that translate to libsignal calls, if you excuse my ignorance 😅 `session_cipher_encrypt(cipher, message, message_len, &encrypted_message)` drops out the payload, so where do the keys come from?
  188. qy Right, so the message is the payload, and each endpoint gets a the key encrypted to their prekey in the header. But how does that translate to libsignal calls, if you excuse my ignorance 😅 `session_cipher_encrypt(cipher, message, message_len, &encrypted_message)` drops out the payload, so where do the keys come from?
  189. qy melvo: noted :p
  190. melvo The key material is retrieved by the store functions / PreKeyMessage.
  191. Jeroen has left
  192. meeson_ has joined
  193. Jeroen has joined
  194. Jeroen has left
  195. Titi has joined
  196. qy Im trying to interpret this from the dino code but it's nontrivial
  197. qy So libsignal's session_cipher creates the ciphertextmessage object, which is the message encrypted for that specific session/pair of endpoints
  198. qy Surely if that's done for every endpoint, the payloads will all be different?
  199. meeson_ has left
  200. qy Modelling this on the libsignal readme code: ``` /* Create the session cipher and encrypt the message */ session_cipher *cipher; session_cipher_create(&cipher, store_context, &address, global_context); session_builder_set_version(cipher, 4); ciphertext_message *encrypted_message; session_cipher_encrypt(cipher, message, message_len, &encrypted_message); /* Get the serialized content and deliver it */ signal_buffer *serialized = ciphertext_message_get_serialized(encrypted_message); deliver(signal_buffer_data(serialized), signal_buffer_len(serialized)); ```
  201. qy Modelling this on the libsignal readme code: ``` /* Create the session cipher and encrypt the message */ session_cipher *cipher; session_cipher_create(&cipher, store_context, &address, global_context); ciphertext_message *encrypted_message; session_cipher_encrypt(cipher, message, message_len, &encrypted_message); /* Get the serialized content and deliver it */ signal_buffer *serialized = ciphertext_message_get_serialized(encrypted_message); deliver(signal_buffer_data(serialized), signal_buffer_len(serialized)); ```
  202. meeson_ has joined
  203. qy To [encrypt the message] as vanitasvitae was saying above, i'd need to do it with no recipient and then fetch the symmetric key used for the returned ciphertext, or something? Then encrypt _that_ for each endpoint, into the header
  204. qy > melvo wrote: > The key material is retrieved by the store functions / PreKeyMessage. Dino seems to create prekeymessage from the ciphertext_message in a test at least, am i missing a trick?
  205. Jeroen has joined
  206. meeson_ has left
  207. Jeroen has left
  208. meeson_ has joined
  209. qy I really wish i understood this thoroughly, i feel like im reinventing things i dont need to
  210. Seve has left
  211. Jeroen has joined
  212. vanitasvitae I'm not familiar with C code, so I can't help with the details
  213. Jeroen has left
  214. vanitasvitae But the flow is: fetch the device list(s), check if you have a session with each device, if not then fetch missing bundles and select a random prekey to build missing sessions (session_builder_process_prekey_bundle), then encrypt the message using a message key and encrypt the message key for each recipient
  215. Jeroen has joined
  216. Jeroen has left
  217. qy Right, i think from that and scanning github for a while, i might be able to implement it
  218. qy vanitasvitae: Thanks :D
  219. vanitasvitae In libsignal-protocol-c, afaict what's called message is actually an AES message key
  220. vanitasvitae But I might be wrong
  221. qy Yeah, that confused me
  222. vanitasvitae So ciphertext_message is an encrypted message key
  223. hello has left
  224. qy Yeah, i think im clear on it all now :D thanks for bearing with me
  225. vanitasvitae you're welcome 🙂
  226. Jeroen has joined