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 :/
Yagizа
jonas’, ok, I'll post a message there.
Yagizа
Can anyone here help me figure out the implementation of the latest version of OMEMO?
jonas’
I’m sure someone can
jonas’
some of the folks involved in working on new-OMEMO are right here
Yagizа
jonas’, sounds encouraging.
Yagizа
jonas’, just noticed that information about moving to this room is in that room's subject.
jonas’
Yagizа, ah, so that’s still there, very good
pulkomandyhas left
Yagizа
jonas’, the only problem is that it is not an XMPP URI.
pulkomandyhas joined
Yagizа
jonas’, do you mean someone here have a client with new OMEMO implementation?
jonas’
Yagizа, what is your specific question?
pulkomandyhas left
Yagizа
jonas’, first of all, I want to clarify section 4.2
jonas’
Yagizа, if there are questions about the standard itself, the mailing list would indeed be best I guess
Yagizа
jonas’, the question is about upgrading from old version of OMEMO to a new one.
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.
jonas’
yeah, I suppose this type of complex questions is better suited for the ML then
pulkomandyhas joined
goffihas joined
Yagizа
jonas’, ok. I'll post it there. But anyway, I hope someone will also reply here.
lovetox
Yagizа, how many people use your omemo impl
lovetox
when i remember correctly its not that old
lovetox
you may consider not trying to stay backwards compatibel
Yagizа
lovetox, I suppose right now no clients have new version of OMEMO implementation.
Yagizа
lovetox, so, I can't even test if my implementation is correct.
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.
lovetox
yes protocol wise its incompatible
Yagizа
lovetox, but I don't care bout it right now. Right now I just want correctly implement new version.
lovetox
but this part you posted is about the encryption keys
lovetox
and they should be compatibel with the old version
lovetox
means you can keep your secret keys
Yagizа
lovetox, in old version just Signal Protocol was used. But new version do not mention Signal Protocol. It says something about XEdDSA.
Yagizа
lovetox, it says that if I'm using libsignal-protocol, I have to modify it to use XEdDSA to be compatible with OMEMO.
Yagizа
lovetox, but I have no idea what I need to modify and how.
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
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?
lovetox
no im not saying that, i have no clue about it
Yagizа
lovetox, ah, ok
lovetox
if you have that question, either wait here, or write to the list
lovetox
larma, and Syndace probably can help you ^
Yagizа
lovetox, let's wait for their answer.
flow
Yagizа, I think this is telling in a few words how you can use it
larma
Yagizа: https://github.com/dino/libomemo-c
Yagizа
flow, this?
Yagizа
larma, ok, thank you. Investigating it.
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.
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.
kikuchiyohas left
Alexhas left
Alexhas joined
Yagizа
Syndace, larma , so, instead of using original libsignal-protocol-c, I just have to switch to libomemo-c?
larma
And set protocol version to 4 when working with session/cipher builder
larma
Like `session_builder_set_version(builder, 4);`
Yagizа
larma, ok, thanx.
larma
There is a test for it at https://github.com/dino/libomemo-c/blob/omemo/tests/test_session_builder.c#L492
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)
adrienhas left
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.
larma
Yeah, I guess so
pulkomandyhas left
pulkomandyhas joined
debaclehas joined
debaclehas left
debaclehas joined
pulkomandyhas left
pulkomandyhas joined
lovetoxhas left
Martinhas left
Martinhas joined
sonnyhas left
sonnyhas joined
sonnyhas left
sonnyhas joined
sonnyhas left
sonnyhas joined
Yagizаhas left
Yagizаhas joined
pulkomandyhas left
pulkomandyhas joined
Marchas left
Marchas joined
pulkomandyhas left
pulkomandyhas joined
lovetoxhas joined
pulkomandyhas left
pulkomandyhas joined
DebXWoodyhas left
pulkomandyhas left
pulkomandyhas joined
adrienhas joined
DebXWoodyhas joined
adrienhas left
pulkomandyhas left
pulkomandyhas joined
adrienhas joined
pulkomandyhas left
adrienhas left
pulkomandyhas joined
adrienhas joined
pulkomandyhas left
pulkomandyhas joined
adrienhas left
adrienhas joined
Zashhas left
Zashhas joined
pulkomandyhas left
pulkomandyhas joined
pulkomandyhas left
pulkomandyhas joined
pulkomandyhas left
pulkomandyhas joined
pulkomandyhas left
Marchas left
Marchas joined
kikuchiyohas joined
pulkomandyhas joined
pulkomandyhas left
pulkomandyhas joined
debaclehas left
alexishas left
alexishas joined
pulkomandyhas left
rionhas left
rionhas joined
pulkomandyhas joined
pulkomandyhas left
sonnyhas left
sonnyhas joined
sonnyhas left
pulkomandyhas joined
lovetoxhas left
pulkomandyhas left
pulkomandyhas joined
paulhas left
paulhas joined
adrienhas left
pulkomandyhas left
pulkomandyhas joined
lovetoxhas joined
pulkomandyhas left
pulkomandyhas joined
sonnyhas joined
adrienhas joined
pulkomandyhas left
pulkomandyhas joined
pulkomandyhas left
pulkomandyhas joined
debaclehas joined
pulkomandyhas left
sonnyhas left
sonnyhas joined
Marchas left
Marchas joined
adrienhas left
adrienhas joined
pulkomandyhas joined
Marchas left
Marchas joined
sonnyhas left
sonnyhas joined
sonnyhas left
sonnyhas joined
sonnyhas left
sonnyhas joined
sonnyhas left
sonnyhas joined
sonnyhas left
sonnyhas joined
strarhas left
edhelashas left
edhelashas joined
pulkomandyhas left
pulkomandyhas joined
Marchas left
Marchas joined
kikuchiyohas left
kikuchiyohas joined
strarhas joined
sonnyhas left
sonnyhas joined
pulkomandyhas left
pulkomandyhas joined
lovetoxhas left
rionhas left
rionhas joined
pulkomandyhas left
pulkomandyhas joined
lovetoxhas joined
pulkomandyhas left
lovetoxhas left
lovetoxhas joined
pulkomandyhas joined
pulkomandyhas left
pulkomandyhas joined
rionhas left
rionhas joined
strarhas left
Yagizа
larma, do I have to execute session_cipher_set_version() as well?
larma
depends on how you use the lib, but usually yes
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)
pulkomandyhas left
Yagizа
larma, ok. So, I can use *_set_version(..., 3) to use encryption protocols compatible with old versions of OMEMO?
strarhas joined
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.
Yagizа
larma, ok, thanx.
pulkomandyhas joined
ralphmhas left
ralphmhas joined
Yagizа
larma, and what abut signal_protocol_session_load_session()? Its 'version' parameter is required.
larma
why do you need to call it directly?
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
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?
larma
yes
larma
default to 2 if unsure
larma
(which is the lowest supported version and thus can be upgraded if needed)
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?
pulkomandyhas left
pulkomandyhas joined
larma
well, session_cipher and session_builder or doing all the session loading needed in the background for you
larma
at least for normal decryption/encryption work
larma
or do I miss something?
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?
pulkomandyhas left
pulkomandyhas joined
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
pulkomandyhas left
strarhas left
strarhas joined
Marchas left
Marchas joined
strarhas left
Yagizа
larma, so existing sessions will work ok without loading them with that function?
larma
what have you been doing with it after loading?
Yagizа
larma, nothing. I just though I have to do it to make it work.
larma
ah. no that shouldn't be needed
Yagizа
larma, ok. I'll try to remove that code.
pulkomandyhas joined
Yagizа
larma, well...
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.
Yagizа
larma, but I see no changes in functionality. New client still normally communicates via OMEMO with previous build, which uses libsignal-protoco-c.
Yagizа
larma, is that normal?
larma
If you use old libsignal database it will have sessions properly initialized at version 3 and continue to use those.
Yagizа
So, if I delete the database, I won't be able to initiate an OMEMO session anymore?
pulkomandyhas left
pulkomandyhas joined
Yagizа
BTW, is there a client around with latest version of OMEMO implemented? Just for testing.
larma
Only outgoing, incoming will probably still work
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
Yagizа
larma, ok. I'll check. Thank you.
sonnyhas left
sonnyhas joined
larma
There is a branch of dino with very basic omemo:1 support: https://github.com/dino/dino/tree/feature/omemo1
Yagizа
larma, ok, thanx.
Yagizа
larma, BTW... about fingerprints. Are there functions for fingerprint generation in libomemo, which generate fingerprints, compatible with XEP?
strarhas joined
larma
Yagizа, no, but probably something worth adding
Yagizа
larma, ok
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?
Yagizа
Or deserialize_pre_key_signal_message_omemo instead of deserialize_pre_key_signal_message is the only change?
pulkomandyhas left
DebXWoodyhas left
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)
pulkomandyhas joined
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
sonnyhas left
sonnyhas joined
pulkomandyhas left
pulkomandyhas joined
asterixhas left
ajhas joined
Yagizа
larma, all XMPP part is already upgraded to v0.5
Yagizа
larma, cryptographic protocols is the only part left.
larma
ah, ok
ajhas left
goffihas left
lovetoxhas left
sonnyhas left
sonnyhas joined
alexishas left
alexishas joined
lovetoxhas joined
Yagizа
larma, here's my code for getting session initialization status:
https://pastebin.com/gy2yEGtF
Yagizа
Is signal_protocol_session_load_session() call redundant here?