Conversation
|
Depends on #42 |
|
|
||
| proc generateRemoteKeyIdentifier*(publicKey: PublicKey): RemoteKeyIdentifier = | ||
| let bytes = cast[seq[byte]]("WAP") & publicKey.bytes().toSeq() | ||
| let hash = utils.hash_func_bytes(4,bytes) |
There was a problem hiding this comment.
My AI friend tells me that the collision seems high,
With a 4-byte (32-bit) hash, collisions are extremely easy to find.
There are only 2³² ≈ 4.29 billion possible distinct hash outputs.
By the birthday paradox, you only need about 2¹⁶ ≈ 65,536 different inputs to have a ~50% chance of finding at least one collision.
With around 77,000 to 100,000 random inputs, the probability of a collision becomes virtually certain (>99%).
There was a problem hiding this comment.
Collisions are not really a concern here.
- The identifier is scoped to the ephemeral key set of a single user. The expected number of keys over a clients lifetime is expected to be ~2^11 = 2048 keys - one for each Introduction sent (0.05%).
- These keys are deleted after they are used, which reduces the number of keys active at a single moment
- The result of a collision is clients would check all keys in the
index - The public key is not considered Secret/confidential
There was a problem hiding this comment.
It seems an increased counter could achieve similar goal as the boundary is clear, not sure if it's a good idea to use it here.
Also, after a quick search in the code, I don't see there is places using keyStore after set, is it not implemented yet?
There was a problem hiding this comment.
is it not implemented yet?
Requires the Noise Protocol integration into Inbox. This change integrates the keyId into the invite, and the follow up will handle keyManagement
There was a problem hiding this comment.
It seems an increased counter could achieve similar goal as the boundary is clear
I generally like this idea, as it saves some more bytes. However it would leak how many invites a given contact has created. I'd have to check to see how that fits with our privacy model.
2 participants
This PR replaces the scaffolding of the ephemeral keyId with a valid implementation.
Recipient Key Id's help receiving clients identify which key was used during initialization without senders having to transmit it again.
This PR populates the ephemeral keyId correctly for outbound invites. The parsing and subsequent lookup of the ephemeralKeyId is left for future work, once the noise handshake is implemented.