Split out of #403 (item 6).
The current design generates the invitation secret client-side and passes it only via the URL fragment, so the signaling server can't swap it unnoticed (see service/src/crypto/inviteCrypto.ts). However, neither participant has a way to confirm out-of-band that both sides actually derived the same secret — if the invite link itself is intercepted/retransmitted via a compromised channel, there's currently no detection mechanism, mirroring the lack of Signal-style "safety number" verification.
Proposed scope:
- SDK: derive a short, human-comparable fingerprint (digest of the invite-derived material, domain-separated from the chat/signaling secrets the same way
deriveChannelSecrets() already separates those) and expose it via a new IChatE2EE method (e.g. getSafetyNumber(): Promise<string>).
- Client: a small UI surface (e.g. in the existing chat header/settings area) letting both participants display and verbally/out-of-band compare the fingerprint.
Out of scope for this issue: re-architecting key exchange — this is purely an additional verification step layered on top of the existing invite-secret model. Should land after #447 is resolved/rebased so it builds on a settled key-exchange mechanism.
Split out of #403 (item 6).
The current design generates the invitation secret client-side and passes it only via the URL fragment, so the signaling server can't swap it unnoticed (see
service/src/crypto/inviteCrypto.ts). However, neither participant has a way to confirm out-of-band that both sides actually derived the same secret — if the invite link itself is intercepted/retransmitted via a compromised channel, there's currently no detection mechanism, mirroring the lack of Signal-style "safety number" verification.Proposed scope:
deriveChannelSecrets()already separates those) and expose it via a newIChatE2EEmethod (e.g.getSafetyNumber(): Promise<string>).Out of scope for this issue: re-architecting key exchange — this is purely an additional verification step layered on top of the existing invite-secret model. Should land after #447 is resolved/rebased so it builds on a settled key-exchange mechanism.