Page MenuHomePhabricator

[lib] add session version to EncryptedData
ClosedPublic

Authored by kamil on Aug 8 2024, 8:50 AM.
Tags
None
Referenced Files
Unknown Object (File)
Wed, Nov 20, 3:10 AM
Unknown Object (File)
Wed, Nov 20, 3:09 AM
Unknown Object (File)
Wed, Nov 20, 2:44 AM
Unknown Object (File)
Sun, Nov 10, 12:55 PM
Unknown Object (File)
Fri, Nov 8, 11:05 PM
Unknown Object (File)
Fri, Nov 8, 12:24 PM
Unknown Object (File)
Thu, Oct 31, 8:44 AM
Unknown Object (File)
Oct 15 2024, 4:45 PM
Subscribers

Details

Summary

ENG-6982.

When there are multiple messages queued for the device, and we start resetting the session the messages already queued will for sure fail to be decrypted - to distinguish that and avoid resetting the session multiple times we need to add the session version to each message. This is optional to backward compatibility and to avoid adding this for notif when this is not needed.

Depends on D13032

Test Plan
  1. Create a session between devices A and B
  2. On B comment out sending confirmation.
  3. Send some messages from A to B
  4. Receive couple of messages from B
  5. Reset session
  6. Make sure other messages throws INVALID_SESSION_VERSION error when decrypting

Diff Detail

Repository
rCOMM Comm
Lint
No Lint Coverage
Unit
No Test Coverage

Event Timeline

kamil held this revision as a draft.
kamil edited the test plan for this revision. (Show Details)
kamil published this revision for review.Aug 12 2024, 2:47 AM
tomek added inline comments.
native/cpp/CommonCpp/CryptoTools/CryptoModule.cpp
402

Shouldn't we check for equality?

native/cpp/CommonCpp/NativeModules/CommCoreModule.cpp
1850

Why do we round?

This revision is now accepted and ready to land.Aug 20 2024, 2:05 AM
native/cpp/CommonCpp/CryptoTools/CryptoModule.cpp
402

This is on purpose:
encryptedData.sessionVersion == session->getVersion() -> The same session, we should be able to decrypt
encryptedData.sessionVersion < session->getVersion() -> We have a newer session, we should ignore this message, that's why we're throwing a specific error to ignore in JS
encryptedData.sessionVersion > session->getVersion() -> We have an older session, this is a very rare edge case when there was a session reset from the other client but the session init message was not delivered, in that case, we want to throw an error to heal session state.

native/cpp/CommonCpp/NativeModules/CommCoreModule.cpp
1850

we do it always for numbers because JSI uses double when passing numbers from JS

native/cpp/CommonCpp/CryptoTools/CryptoModule.cpp
402

I'm confused... it seems like you're saying that for both the < and > case, we should throw an error... but we're only throwing an error here for the < case, no?

native/cpp/CommonCpp/CryptoTools/CryptoModule.cpp
402

For case < we should throw specific error, other than Olm's error to ignore this fact and avoid resetting the session.
For case > we should keep the default behavior which is decrypt, or on Olm error reset session. We're not throwing an error explicitly but Olm will do it (OLM_BAD_MESSAGE_MAC). If you think it's better to introduce another specific error - not ignored but causing resetting session like internal Olm errors I can do it as a follow-up, the logic will remain unchanged, this is just about code readability/avoiding calling the decrypt method.

This revision was automatically updated to reflect the committed changes.