Requirement of integer registration id

[McCrafterIV]

For the Signal protocol to work, each USER needs to have a unique USER-ID together with a DEVICE-ID unique to the user. A user address is represented using the SignalProtocolAddress class in the package. This requires a NAME for the user provided as a string (e.g. a UUID, phone number or username) and a DEVICE-ID provided as an integer.

But the PreKeyBundle requires a registrationId of the user as an integer, making it impossible to use anything else than an integer as a unique user identifier. Using a username as a USER-ID is only possible when two unique user identifiers are keept (the username and the integer id).

Are those assumptions correct?

If so, would it be possible to remove the requirement for a integer registrationId in the PreKeyBundle class and change the type to a string to allow for an easier/possible use of usernames/UUIDs etc. as USER-IDs? I could't find any mention of this requirement in the Signal docs. If I missed them, could you please give me a hint as to where to look?

[Tougee]

I didn't find any mention in the docs either, but the protobuf definitions in Signal implementations are all uint32, so maybe this is an above-protocol convention? I think registrationId is not associated with a user identifier, there is already a generateRegistrationId in key_helper.dart that can deal with this.

https://github.com/signalapp/libsignal-protocol-java/blob/master/protobuf/WhisperTextProtocol.proto#L16 https://github.com/signalapp/libsignal/blob/main/rust/protocol/src/proto/wire.proto#L18

[McCrafterIV]

Yeah I saw the function and figured that it is a helper for generating a random number with specific requirements. I've done some testing after reading your answer and figured out that you can indeed use the same registrationId for multiple users. It seems like it would be easier to just set a static number for all users. Is this a bad idea? If I understand you correctly, it would it be sufficient to use the provided generateRegistrationId function local for each user even if multiple users therefore have the same registrationId?

[Tougee]

I think it's better to use different registrationIds and build a mapping of accounts to deviceIds <-> registrationIds. https://signal.org/docs/specifications/sesame/#protecting-server-communications

[McCrafterIV]

So a different registrationId is to be used for each user.

I understand the UserID in the Signal docs (like Sesame) to be e.g. a username or other type of string and unique identifier as used in SignalProtocolAdress.

Therefore the registrationId can't be the UserID (since that can't be any string), but should it still be unique across users or is "just a random number" enaugh? The first would mean that generateRegistrationId wouldn't be sufficient for any use case since there is always the chance of two id's being the same.

If the risks mentioned in https://signal.org/docs/specifications/sesame/#protecting-server-communications would apply to the registrationId too (which is never mentioned in any of the documents), this could be mitigated by verifying the identityKey.

[Tougee]

So a different registrationId is to be used for each user.

IMO same user(device) with different registrationId in every login state is enough, and the mapping is on server side which client should register to when logged in.

[McCrafterIV]

What do you define as a login state? If you see a login state as the period where a user is authenticated against the server, I don't see where the mentioned limitation of uniqueness is applied, since other users don't know if/when/for how long I'm currently authenticated against the server.

[McCrafterIV]

May I tag you @Tougee to ask for clarification again?