jdev - 2020-05-03

  1. Yagizа


  2. jonas’

    welcome back :)

  3. Yagizа

    jonas’, (^_^)

  4. jonas’

    Yagizа, if there are still people in the old jdev@, can you make sure that they know about new-jdev? I can’t even join there because the server uses outdated SSL settings :/

  5. Yagizа

    jonas’, ok, I'll post a message there.

  6. Yagizа

    Can anyone here help me figure out the implementation of the latest version of OMEMO?

  7. jonas’

    I’m sure someone can

  8. jonas’

    some of the folks involved in working on new-OMEMO are right here

  9. Yagizа

    jonas’, sounds encouraging.

  10. Yagizа

    jonas’, just noticed that information about moving to this room is in that room's subject.

  11. jonas’

    Yagizа, ah, so that’s still there, very good

  12. Yagizа

    jonas’, the only problem is that it is not an XMPP URI.

  13. Yagizа

    jonas’, do you mean someone here have a client with new OMEMO implementation?

  14. jonas’

    Yagizа, what is your specific question?

  15. Yagizа

    jonas’, first of all, I want to clarify section 4.2

  16. jonas’

    Yagizа, if there are questions about the standard itself, the mailing list would indeed be best I guess

  17. Yagizа

    jonas’, the question is about upgrading from old version of OMEMO to a new one.

  18. Yagizа

    jonas’, this part is too complicated for me:
XEdDSA OMEMO does not mandate the usage of XEdDSA [10] with X3DH [9] for the IdentityKey. Instead, there are three simple rules that implementations MUST follow: Implementations must use the birational map between the curves Curve25519 and Ed25519 to convert the public part of the IdentityKey whenever required, as defined in RFC 7748 [11] (on page 5). Implementations must be able to perform X25519 (ECDH on Curve25519) using the IdentityKey. Implementations must be able to create EdDSA-compatible signatures on the curve Ed25519 using the IdentityKey. There are essentially two ways in which libraries can fulfill these requirements: Libraries can use a Curve25519 key pair as their internal IdentityKey. In this case, the IdentityKey can be used for X25519 directly, and XEdDSA has to be used to produce EdDSA-compatible signatures. Note that libsignal by default does NOT use XEdDSA. libsignal includes XEdDSA though and has to be modified to use that to be compatible with OMEMO. Libraries can use an Ed25519 key pair as their internal IdentityKey. In this case, the IdentityKey can create EdDSA-compatible signatures directly, and has to be converted first to perform X25519.

  19. jonas’

    yeah, I suppose this type of complex questions is better suited for the ML then

  20. Yagizа

    jonas’, ok. I'll post it there. But anyway, I hope someone will also reply here.

  21. lovetox

    Yagizа, how many people use your omemo impl

  22. lovetox

    when i remember correctly its not that old

  23. lovetox

    you may consider not trying to stay backwards compatibel

  24. Yagizа

    lovetox, I suppose right now no clients have new version of OMEMO implementation.

  25. Yagizа

    lovetox, so, I can't even test if my implementation is correct.

  26. Yagizа

    lovetox, it is absolutely incompatible with old version, so it's impossible to keep backwards compatibility at all. All I can do it make both versions supported at the same time.

  27. lovetox

    yes protocol wise its incompatible

  28. Yagizа

    lovetox, but I don't care bout it right now. Right now I just want correctly implement new version.

  29. lovetox

    but this part you posted is about the encryption keys

  30. lovetox

    and they should be compatibel with the old version

  31. lovetox

    means you can keep your secret keys

  32. Yagizа

    lovetox, in old version just Signal Protocol was used. But new version do not mention Signal Protocol. It says something about XEdDSA.

  33. Yagizа

    lovetox, it says that if I'm using libsignal-protocol, I have to modify it to use XEdDSA to be compatible with OMEMO.

  34. Yagizа

    lovetox, but I have no idea what I need to modify and how.

  35. lovetox

    yes you need to ave a good understanding of the crypto now to implement the new omemo, or you wait until someone writes a lib for you in your language

  36. Yagizа

    lovetox, so, it's impossible just tell in a few words how can I use xeddsa.c/h together with libsignal-protocol-c to make it compatible with new version of OMEMO?

  37. lovetox

    no im not saying that, i have no clue about it

  38. Yagizа

    lovetox, ah, ok

  39. lovetox

    if you have that question, either wait here, or write to the list

  40. lovetox

    larma, and Syndace probably can help you ^

  41. Yagizа

    lovetox, let's wait for their answer.

  42. flow

    Yagizа, I think this is telling in a few words how you can use it

  43. larma

    Yagizа: https://github.com/dino/libomemo-c

  44. Yagizа

    flow, this?

  45. Yagizа

    larma, ok, thank you. Investigating it.

  46. Syndace

    Yagizа: Section 4 is for people who want to write new OMEMO libraries. The rest is for people who want to use existing OMEMO libraries. Basically. So 4 is very technical and crypto-heavy.

  47. Syndace

    Yagizа: We aim to provide OMEMO libraries for C (what larma linked), Java, JavaScript and Python at some point. Also note that the spec is still moving, a rather large PR is currently being worked on.

  48. Yagizа

    Syndace, larma , so, instead of using original libsignal-protocol-c, I just have to switch to libomemo-c?

  49. larma

    And set protocol version to 4 when working with session/cipher builder

  50. larma

    Like `session_builder_set_version(builder, 4);`

  51. Yagizа

    larma, ok, thanx.

  52. larma

    There is a test for it at https://github.com/dino/libomemo-c/blob/omemo/tests/test_session_builder.c#L492

  53. larma

    Yagizа: note however that the planned changes for the next iteration of omemo will not be fully compatible (although I think they can be rolled out backwards compatible)

  54. Yagizа

    larma, thanx. Anyway, I hope upgrade from 0.3 to 0.5 will leave less work, when I'll upgrade it to the next version.

  55. larma

    Yeah, I guess so

  56. Yagizа

    larma, do I have to execute session_cipher_set_version() as well?

  57. larma

    depends on how you use the lib, but usually yes

  58. larma

    it never hurts to do so if you don't run in a mixed environment (where you use both old omemo and omemo:1 at the same time)

  59. Yagizа

    larma, ok. So, I can use *_set_version(..., 3) to use encryption protocols compatible with old versions of OMEMO?

  60. larma

    old omemo uses versions 2 and 3 (though practically you only see 3). If you want to use old omemo, just do not set version on the corresponding builder/cipher at all, it will then select automatically 2 or 3.

  61. Yagizа

    larma, ok, thanx.

  62. Yagizа

    larma, and what abut signal_protocol_session_load_session()? Its 'version' parameter is required.

  63. larma

    why do you need to call it directly?

  64. larma

    IIRC, `signal_protocol_session_load_session()` creates a new session with specified version when it doesn't exist yet. if it already exists, the version parameter is ignored

  65. Yagizа

    larma, so, it doesn't matter which version I'll specify, if I use it only for loading existing session, not for creating a new session?

  66. larma


  67. larma

    default to 2 if unsure

  68. larma

    (which is the lowest supported version and thus can be upgraded if needed)

  69. Yagizа

    larma, and what did you mean by "why do you need to call it directly"? Is there any way for loading sessions without calling the function directly?

  70. larma

    well, session_cipher and session_builder or doing all the session loading needed in the background for you

  71. larma

    at least for normal decryption/encryption work

  72. larma

    or do I miss something?

  73. Yagizа

    larma, well... I still don't understand. Now I'm calling that function to load existing OMEMO session from local storage. How can I do it without calling that function?

  74. larma

    well, you can't do it without that, but the question is more *why* you need to load a session. To find out if you already have a session (so you know if you need to fetch a bundle or not) - signal_protocol_session_contains_session To process the bundle before encrypting the first message for a device you do - session_builder_create - session_builder_process_pre_key_bundle When encrypting a message you do - session_cipher_create - session_cipher_encrypt When decrypting a message you do - session_cipher_create - session_cipher_decrypt_pre_key_signal_message / session_cipher_decrypt_signal_message

  75. Yagizа

    larma, so existing sessions will work ok without loading them with that function?

  76. larma

    what have you been doing with it after loading?

  77. Yagizа

    larma, nothing. I just though I have to do it to make it work.

  78. larma

    ah. no that shouldn't be needed

  79. Yagizа

    larma, ok. I'll try to remove that code.

  80. Yagizа

    larma, well...

  81. Yagizа

    larma, just substituted libsignal-protocol-c with libomemo-c in my code. Then added session_builder_set_version() and session_cipher_set_version() in proper places, specifying version as 4.

  82. Yagizа

    larma, but I see no changes in functionality. New client still normally communicates via OMEMO with previous build, which uses libsignal-protoco-c.

  83. Yagizа

    larma, is that normal?

  84. larma

    If you use old libsignal database it will have sessions properly initialized at version 3 and continue to use those.

  85. Yagizа

    So, if I delete the database, I won't be able to initiate an OMEMO session anymore?

  86. Yagizа

    BTW, is there a client around with latest version of OMEMO implemented? Just for testing.

  87. larma

    Only outgoing, incoming will probably still work

  88. larma

    also when parsing incoming messages you'll need to use deserialize_pre_key_signal_message_omemo instead of deserialize_pre_key_signal_message for omemo:1 and doing that on a incoming message of old omemo will break

  89. Yagizа

    larma, ok. I'll check. Thank you.

  90. larma

    There is a branch of dino with very basic omemo:1 support: https://github.com/dino/dino/tree/feature/omemo1

  91. Yagizа

    larma, ok, thanx.

  92. Yagizа

    larma, BTW... about fingerprints. Are there functions for fingerprint generation in libomemo, which generate fingerprints, compatible with XEP?

  93. larma

    Yagizа, no, but probably something worth adding

  94. Yagizа

    larma, ok

  95. Yagizа

    larma, and... is there any docs, which describe changes in code I have to perform when upgrading from v3 libsignal-protocol to v4 libomemo?

  96. Yagizа

    Or deserialize_pre_key_signal_message_omemo instead of deserialize_pre_key_signal_message is the only change?

  97. larma

    what do you meain with upgrading? the protocols are very much incompatible on the XMPP side. Also libomemo-c only implements the same feature set of libsignal-protocol-c (just adjusted for omemo:1), which equals to 4.2 and 4.3 of XEP-0384. You'll still have to implement 4.4/4.5 on top of that (just as you also had to do some AES-GCM in old omemo)

  98. larma

    https://github.com/dino/dino/blob/feature/omemo1/plugins/omemo/src/logic/trust_manager.vala#L226 <- here is the legacy omemo and omemo:1 encryption code (4.4 in the XEP) next to each other

  99. Yagizа

    larma, all XMPP part is already upgraded to v0.5

  100. Yagizа

    larma, cryptographic protocols is the only part left.

  101. larma

    ah, ok

  102. Yagizа

    larma, here's my code for getting session initialization status: https://pastebin.com/gy2yEGtF

  103. Yagizа

    Is signal_protocol_session_load_session() call redundant here?