search

signalapp / libsignal

Home to the Signal Protocol as well as other cryptographic primitives which make Signal possible.
GNU Affero General Public License v3.0
3.63k stars 420 forks source link

Issue with sealed_sender_multi_recipient_encrypt #499

Closed Anblak closed 2 years ago

Anblak commented 2 years ago

Hey! My team is using this lib as a part of Turasa project for very important project for Ukraine (mb you know a situation in a country)

We have numerous exceptions like: Non-fatal Exception: java.lang.IllegalStateException: invalid state for call to sealed_sender_multi_recipient_encrypt to succeed: cannot get registration ID from session with 0730c772-7b3c-467a-bbbc-2b296bf0cd81.1 (maybe it was recently archived)

It's breaking our stability (what is very important for us) Please help with this

Full stacktrace: 

Non-fatal Exception: java.lang.IllegalStateException: invalid state for call to sealed_sender_multi_recipient_encrypt to succeed: cannot get registration ID from session with 0730c772-7b3c-467a-bbbc-2b296bf0cd81.1 (maybe it was recently archived)
       at org.signal.libsignal.internal.Native.SealedSessionCipher_MultiRecipientEncrypt(Native.java)
       at org.signal.libsignal.metadata.SealedSessionCipher.multiRecipientEncrypt(SealedSessionCipher.java:115)
       at org.whispersystems.signalservice.api.crypto.SignalSealedSessionCipher.multiRecipientEncrypt(SignalSealedSessionCipher.java:51)
       at org.whispersystems.signalservice.api.crypto.SignalServiceCipher.encryptForGroup(SignalServiceCipher.java:110)
       at org.whispersystems.signalservice.api.SignalServiceMessageSender.sendGroupMessage(SignalServiceMessageSender.java:2028)
       at org.whispersystems.signalservice.api.SignalServiceMessageSender.sendGroupDataMessage(SignalServiceMessageSender.java:463)
       at org.asamk.signal.manager.helper.SendHelper.lambda$sendGroupMessage$10(SendHelper.java:339)
       at org.asamk.signal.manager.helper.SendHelper$$ExternalSyntheticLambda13.send$50b4e1be(SendHelper.java)
       at org.asamk.signal.manager.helper.SendHelper.sendGroupMessageInternalWithSenderKey$17c099ae(SendHelper.java:546)
       at org.asamk.signal.manager.helper.SendHelper.sendGroupMessageInternal(SendHelper.java:416)
       at org.asamk.signal.manager.helper.SendHelper.sendGroupMessage(SendHelper.java:356)
       at org.asamk.signal.manager.helper.SendHelper.sendAsGroupMessage(SendHelper.java:304)
       at org.asamk.signal.manager.helper.SendHelper.sendAsGroupMessage(SendHelper.java:102)
       at org.asamk.signal.manager.ManagerImpl.sendMessage(ManagerImpl.java:498)
       at org.asamk.signal.manager.ManagerImpl.sendMessage(ManagerImpl.java:599)
       at org.asamk.signal.manager.transport.SignalAttachmentBufferedSender.flush(SignalAttachmentBufferedSender.java:68)
       at org.asamk.signal.manager.transport.SignalAttachmentBufferedSender.run(SignalAttachmentBufferedSender.java:49)
       at java.lang.Thread.run(Thread.java:761)
jrose-signal commented 2 years ago

Multi-recipient encryption assumes that you have an active 1:1 session with all recipients already. This is a reasonable assumption within Signal because SenderKey keys are always sent via 1:1 sessions, and since Turasa is using the actual Signal network you're responsible for this too. The registration IDs specifically are used by the server to detect if you're sending to a device that has been unlinked / relinked.

Before sending a multi-recipient message, make sure you have sessions for all participants, just as you would if you were going to send them individual 1:1 messages.

Does that solve your issue?

Anblak commented 2 years ago

@jrose-signal Yep, thanks a lot!

Anblak commented 2 years ago

@jrose-signal sorry, have one more question how to reproduce that? remove connected device and don't update session keys?

jrose-signal commented 2 years ago

You should be able to reproduce by explicitly archiving the current session for a recipient, then immediately trying to send a multi-recipient message to them.

Anblak commented 2 years ago

@jrose-signal repoduced, and to fix that - need to delete arhived session from the list or refresh that? (if refresh - than how?)

jrose-signal commented 2 years ago

Refresh, by processing a new pre-key bundle.

[Meta: GitHub Issues isn't the best place for this sort of discussion; it's probably better for the Development section fo the unofficial forums at https://community.signalusers.org/.]