InvictusInnovations / keyhotee

Decentralized ID and Communication
54 stars 27 forks source link

able to add identical identities in same client. #265

Closed yuvarajgogoi closed 10 years ago

yuvarajgogoi commented 10 years ago

Steps to reproduce 1) Start a client 2) Open create Identity. 3) Open create Identity. 4) Now put same idenity on create Idenity dialog. 5) Save the Dialogs

Same idenitities are there in the contact list.

Tested on Ubuntu and is always reproducible.

dnotestein commented 10 years ago

I was just assisting a Keyhotee user for whom a variation of this issue was causing a problem, as he's able to create to multiple identities with what should be the same KehoteeID (one all lowercase and one with a leading uppercase character, which we should treat as the same) and each such identity was creating a different public key (that's not good) . What we need to do is first pass the kehoteeID through the same logic that's performed in the name_hash function prior to generating a hash code for the Keyhotee ID, so that all variations on a keyhotee ID that we consider the same key will all generate the same public key.

This also leaves us with an outstanding issue to resolve even after we fix this: many Keyhotee founders have already created identities with varying capitalization tied to a particular brainwallet key, with the understanding that the same public key will be generated again if they create a new profile with the same key and the same keyhoteeId. That would no longer hold once we change the algorithm for calculating that public key to avoid different keys for different capitalization styles.

bytemaster commented 10 years ago

Yikes... major issue.

Should be a simple 'tolower' call? right?

dnotestein commented 10 years ago

The fix isn't so difficult, just need to copy the same logic used in name_hash (it's a bit more than lowercase, but that's part of it). I'm just more concerned about need for everyone to re-register with a new public key, that's more of a marketing issue (unless we come up with something clever I'm missing on the technical side).

On 2/1/2014 11:44 PM, Daniel Larimer wrote:

Yikes... major issue.

Should be a simple 'tolower' call? right?

— Reply to this email directly or view it on GitHub https://github.com/InvictusInnovations/keyhotee/issues/265#issuecomment-33892005.

dnotestein commented 10 years ago

After some more thought, it seems like the best thing to maintain backwards compatibility with previously generated keyhoteeId/public key pairs is to leave KehoteeId's case-sensitive for re-generation of the public/private key pair, BUT we won't allow the user to create another identity that hashes to the same name_hash as any other existing identities in the profile. This will require users to recall the identity's case-sensitivity if and when they want to regenerate their keys in a new profile, but other users will be able to send to that KeyhoteeId regardless of what case they use. This behavior has a side benefit of increased security for the ID, since it requires knowledge of the brain wallet key and the exact string used to create the identity.

To code this, just run all the existing identities through name_hash, see if any match the name_hash of the new identity, and reject it if there's a match.

Yuvaraj, this needs to be fixed ASAP, so please try to complete it tomorrow.

yuvarajgogoi commented 10 years ago

Fixed in https://github.com/InvictusInnovations/BitShares/commit/e7e9de6a91f9ab4dfa27f22fdcfcf1a9879555b4 and 0aea590fda3664fd0360b86b824cc0b2019857d0