Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

The main problem with using a public key as your identity is that once it is leaked, you no longer have an "identity" (or more exactly, it's not uniquely you). There is no way you can change your identification without changing your identity.


Multi-key addresses would be more robust. Plus, when it's an Open Asset on Bitcoin blockchain, then you can "rotate" keys by moving your identity into a different multisig address when one of the previous keys gets compromised.


> The main problem with using a public key as your identity is that once it is leaked, you no longer have an "identity" (or more exactly, it's not uniquely you). There is no way you can change your identification without changing your identity.

The main problem with using a public key as your identity is that it's a horrible string of gibberish that people can't remember. What you want is some way of mapping some friendly name to your key.

But you can resolve friendly names to keys however you like. You can update that mapping however you like. That is orthogonal to what snow does.


True, you could have a bunch of SRVs in your DNS that redirects from _snow._tcp.my.best.friend.snow to aaa<..>.key or bbb<...>.key. You can even expire your keys after any amount of time for free thanks to DNS. Hey, that actually looks like a nice thing to add to snow !


It already supports CNAME. You can do example.com CNAME aaa<..>.key. SRV is on the todo list, not least because it also lets you look up the IP address and port in DNS as an alternative to the DHT.


Depends if the network has memory. If you can publish a "this key is compromised" message then at least you can take down your own identity so the thief can't use it, and work on re-establishing a new one.


That's true, however you would still need to possess the private key to be able to validate.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: