Unable to receive messages sent by another person from gurk

[maximbaz]

Person A and person B both run signal on Android, scli and gurk.

If person A sends message from android or scli, person B will receive them in all 3 apps.
If person A sends message from gurk, person B will only receive them in android and scli, but not in gurk.
The same in reverse, when person B sends a message.

--verbose doesn't show anything, when person A sends message via gurk, person B will only see this one line in the log:

2023-07-10T17:22:51.116446Z  INFO libsignal_protocol::session_cipher: decrypted Whisper message from xxx with current session state (base key xxx)

I'm a bit puzzled what can be going on here, any suggestions how to debug this further?

[boxdot]

My guess would be that it has something to do with the websocket bug. Presage currently has a bug caching the websockets in use. Also there is no reconnect there, in case a connection to the websocket is closed.

There is another problem that sent messages from gurk do not appear in the android or desktop signal app. This might be connected.

[0xErnie]

I can reproduce this using the recent version v0.5.1 with aarch64-unknown-linux-gnu and x86_64-unknown-linux-musl
Main device is using the official client on iOS version 7.28.
Upstream issue is here: whisperfish/presage#229
Another duplicate seems to be #297

Would be happy to assist with more information if needed.

[boxdot]

What I see in the logs, when the message is not showing is the following line:

libsignal_protocol::session_cipher: Message from [uuid].1 failed to decrypt; sender ratchet public key 4b4e86abaa7a234025d0c5866021700c44852e33053ed20f0107653546f71529 message counter 0

We still don't know why this happens.

After resetting the session messages arrive again.

[hrdl-github]

I've been running gurk with #321 and with

gurk-rs/src/main.rs

Line 140 in 6bcc592

let mut contact_sync_task = app.request_contacts_sync();

and

gurk-rs/src/main.rs

Lines 188 to 201 in 6bcc592

	if let Some(task) = contact_sync_task.take() {
	let inner_tx = inner_tx.clone();
	tokio::task::spawn_local(async move {
	match task.await {
	Ok(at) => inner_tx
	.send(Event::ContactSynced(at))
	.await
	.expect("logic error: events channel closed"),
	Err(error) => {
	error!(%error, "failed to sync contacts");
	}
	}
	});
	}

removed for a couple of days now. I experienced a single session refresh just after starting that version for the first time, but not since.

This avoids briefly having two identified websockets open before one of them is closed with reason Connected elsewhere.

[hrdl-github]

I'm reasonably confident that I have found the ultimate cause. When reconnecting (which is simply made more likely by gurk's request_contacts_sync()), presage creates a couple of StdRng instances, reusing a historical state. This can cause libsignal to create key chains that share the same sender ratchet keys as a recent historic chain https://github.com/signalapp/libsignal/blob/c6a1e5cec6a30759716a33d0586c84ef6f4f613e/rust/protocol/src/session_cipher.rs#L664, but with the remaining key material differing. If the sender ratchet key is known by the receiving device (i.e. an illegal reuse has taken place and the chain hasn't been trimmed yet) the correct chain will not be created. Instead, the old chain will be used, causing either Duplicate message errors if the counters have already been used, or Bad Mac errors as the key material differs despite the sender ratchet key being the same.

whisperfish/libsignal-service-rs@b0fcd8b has taken the first step prevent this, so once presage is updated, gurk just needs to follow suit.

The contact sync should be fine, despite its other issues.

[boxdot]

Nicht catch. I will try to verify this empirically by a quick and dirty patch of Gurk.Am 03.11.2024 00:52 schrieb hrdl ***@***.***>: I'm reasonably confident that I have found the ultimate cause. When reconnecting (which is simply made more likely by gurk's request_contacts_sync()), presage creates a couple of StdRng instances, reusing a historical state. This can cause libsignal to create key chains that share the same sender ratchet keys as a recent historic chain https://github.com/signalapp/libsignal/blob/c6a1e5cec6a30759716a33d0586c84ef6f4f613e/rust/protocol/src/session_cipher.rs#L664, but with the remaining key material differing. If the sender ratchet key is known by the receiving device (i.e. an illegal reuse has taken place and the chain hasn't been trimmed yet) the correct chain will not be created. Instead, the old chain will be used, causing either Duplicate message errors if the counters have already been used, or Bad Mac errors as the key material differs despite the sender ratchet key being the same. ***@***.*** has taken the first step prevent this, so once presage is updated, gurk just needs to follow suit. The contact sync should be fine, despite its other issues. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: ***@***.***>

[hrdl-github]

Let me push my presage branch that features a workaround: https://github.com/hrdl-github/presage/tree/fix-rng