jdev - 2020-05-03

Hello!

welcome back :)

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 :/

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

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

I’m sure someone can

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

jonas’, sounds encouraging.

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

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

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

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

Yagizа, what is your specific question?

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

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

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

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.

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

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

Yagizа, how many people use your omemo impl

when i remember correctly its not that old

you may consider not trying to stay backwards compatibel

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

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

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.

yes protocol wise its incompatible

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

but this part you posted is about the encryption keys

and they should be compatibel with the old version

means you can keep your secret keys

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

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

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

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

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?

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

lovetox, ah, ok

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

larma, and Syndace probably can help you ^

lovetox, let's wait for their answer.

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

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

flow, this?

larma, ok, thank you. Investigating it.

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.

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.

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

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

Like `session_builder_set_version(builder, 4);`

larma, ok, thanx.

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

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)

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.

Yeah, I guess so

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

depends on how you use the lib, but usually yes

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)

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

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.

larma, ok, thanx.

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

why do you need to call it directly?

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

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?

yes

default to 2 if unsure

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

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?

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

at least for normal decryption/encryption work

or do I miss something?

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?

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

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

what have you been doing with it after loading?

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

ah. no that shouldn't be needed

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

larma, well...

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.

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

larma, is that normal?

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

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

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

Only outgoing, incoming will probably still work

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

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

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

larma, ok, thanx.

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

Yagizа, no, but probably something worth adding

larma, ok

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

Or deserialize_pre_key_signal_message_omemo instead of deserialize_pre_key_signal_message is the only change?

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)

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

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

larma, cryptographic protocols is the only part left.

ah, ok

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

Is signal_protocol_session_load_session() call redundant here?