-
Aeneas
So what is the the Modern XMPP Project's take on using the same Resource ID and OMEMO signing key for multiple different accounts (different bareJIDs) on 1. the same app on the same client? *OR* 2. all clients on the same Operating System instance using the same Resource ID: e.g. one OS on a multiboot device or one VM on a device?
-
Aeneas
My take is that resource id SHOULD be a lower bit length hash of that device's user signing public key (like bitcoin uses RIPEMD-160 length hash for base security of the address which has been hash of the Schnorr public key (plus a check some and other stuff). The benefits of this would be: 1. Fewer things to trust because if you trust bob@domain1 on resource x you also trust bob@domain2 on resource x - if resource x's private keys are compromised for a specific client instance they will all or likely all be compromised. 2. Users/clients do not have go through two processes of trust both the rescource ID AND OMEMO fingerprint 3. It will be compatible with clients who support the current protocols - OMEMO or not.✎ -
Aeneas
My take is that resource id SHOULD be a lower bit length hash of that device's user signing public key (like bitcoin uses RIPEMD-160 length hash for base security of the address which has been hash of the Schnorr public key (plus a checksum and other stuff). The benefits of this would be: 1. Fewer things to trust because if you trust bob@domain1 on resource x you also trust bob@domain2 on resource x - if resource x's private keys are compromised for a specific client instance they will all or likely all be compromised. 2. Users/clients/developers do not have to go through two processes of trustng both the resource ID AND OMEMO fingerprint 3. It will be compatible with clients who support the current protocols - OMEMO or not. ✏