4 ms·

And what happens when someone's private key leaks? Do they have to get issued a new one somehow? If someone has gone through 7 private keys, how do you know tha

And what happens when someone's private key leaks? Do they have to get issued a new one somehow? If someone has gone through 7 private keys, how do you know that the one person-claiming-to-be-someone is giving you the most up to date one vs an older one, etc. There would be a lot of non-trivial considerations by pushing all this on average joes (both as individuals and as people attempting to verify individuals). A system that appears secure but isn't is more dangerous. I can hear a 60 year old now: "Aunt Claire is stuck in london and needs money! We know its her, here's her [expired key] encrypted message!"

kiddico 9y ago
That is a solid question. The optimist in me says 'well if the private key is leaked we're in about the same spot we are now with SSNs'. Every other part of me just cries. In regards to "which version do we trust if a new key has been issued?": My gut says there would need to be a centralized system to for which ones have been voided, and which ones haven't. At that point what we're doing is making SSN's that we can invalidate, with the added disadvantage of being much more confusing to work with. I have no idea what the right answer is, but Aunt Claire is (possibly) in need so we need to figure this out fast.
tomschlick 9y ago
As a user above stated, use an oAuth service from the government. When at a business you could "prove" to their system who you are by authenticating with the govt service with your private key (most likely on a smart card like the military's CAC card). The business then gets an oauth token that you could revoke. If you lose your private key you would have to go to some government services office and bring additional documents to prove who you are just like a passport.
dredmorbius 9y ago
To prevent re-use of old keys, a key-revocation protocol should exist. There's an existing (though pretty crufty) version of this in PGP, though it relies on keeping your revocation key safe, which is a bit of a stretch as that's something you need ... once. A "bad keys" registry might be a useful / necessary thing. Enforcing a regular expiry might also be an option, though ... you'd have to think through that. Keep in mind that technology is continuously improving (or at least has been to date), and there might be a circumstance in which All Keys Suddenly Go Bad, which would have to be dealt with. (Figuring out ways in which to make such situations Less Obviously a Shitfest could be ... useful.) When I've very roughly scoped things out at Google Scale (> 3 billion registered Android profiles), and made modest assumptions such as 1% of users lose their token annually, you're looking at ~10,000 resets per day. So you'll have to have provisions for doing this in any system that's intended to be in the least part useful. As for attacks, I'd strongly suggest finding a good reference of 19th century financial frauds and reading through it. The fundamentals do not (generally) change. http://www.npr.org/sections/npr-history-dept/2015/02/12/385310877/how-scams-worked-in-the-1800s http://www.npr.org/sections/npr-history-dept/2015/02/12/3853...

kiddico 9y ago

That is a solid question. The optimist in me says 'well if the private key is leaked we're in about the same spot we are now with SSNs'. Every other part of me just cries. In regards to "which version do we trust if a new key has been issued?": My gut says there would need to be a centralized system to for which ones have been voided, and which ones haven't. At that point what we're doing is making SSN's that we can invalidate, with the added disadvantage of being much more confusing to work with. I have no idea what the right answer is, but Aunt Claire is (possibly) in need so we need to figure this out fast.

tomschlick 9y ago

As a user above stated, use an oAuth service from the government. When at a business you could "prove" to their system who you are by authenticating with the govt service with your private key (most likely on a smart card like the military's CAC card). The business then gets an oauth token that you could revoke. If you lose your private key you would have to go to some government services office and bring additional documents to prove who you are just like a passport.

dredmorbius 9y ago

To prevent re-use of old keys, a key-revocation protocol should exist. There's an existing (though pretty crufty) version of this in PGP, though it relies on keeping your revocation key safe, which is a bit of a stretch as that's something you need ... once. A "bad keys" registry might be a useful / necessary thing. Enforcing a regular expiry might also be an option, though ... you'd have to think through that. Keep in mind that technology is continuously improving (or at least has been to date), and there might be a circumstance in which All Keys Suddenly Go Bad, which would have to be dealt with. (Figuring out ways in which to make such situations Less Obviously a Shitfest could be ... useful.) When I've very roughly scoped things out at Google Scale (> 3 billion registered Android profiles), and made modest assumptions such as 1% of users lose their token annually, you're looking at ~10,000 resets per day. So you'll have to have provisions for doing this in any system that's intended to be in the least part useful. As for attacks, I'd strongly suggest finding a good reference of 19th century financial frauds and reading through it. The fundamentals do not (generally) change. http://www.npr.org/sections/npr-history-dept/2015/02/12/385310877/how-scams-worked-in-the-1800s http://www.npr.org/sections/npr-history-dept/2015/02/12/3853...