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