Free Republic
Browse · Search
News/Activism
Topics · Post Article

To: ConservativeWarrior
Ah I see, I think....

Seems to defeat the purpose of having key pairs for validation.

When I think of a design for the problem, I keep thinking that key pairs are only useful as a replacement for passwords. Seems each person in the system would still need an id number or the like associated with the public key. Presuming a relational db, they could have the public key be an index to the id of the user in a separate table or db, that can be updated when someone has to change their key pair....and then the id would reference everything else about the person. So somebody signs in say to access their SS benefits, and the server checks what public key their private key solves, and then sees what user is associated with that public key.

They could try to use the public key as the id itself, but that is problematic and could cause transaction/syncing issues with all the other tables and various databases when one tries to change their key pair.

76 posted on 10/04/2017 11:47:49 AM PDT by AndyTheBear
[ Post Reply | Private Reply | To 54 | View Replies ]


To: AndyTheBear

“Seems to defeat the purpose of having key pairs for validation.”


Absolutely correct. We’d be better off simply moving to longer alphanumeric SSNs.

Ironically, the “last four” companies are so fond of logging and tracking are the actually the most secure part of current SSNs. The first 3 digits usually designate the state you were born in. It’s only the last 7 that provide any sort of uniqueness.


78 posted on 10/04/2017 12:00:34 PM PDT by ConservativeWarrior (Fall down 7 times, stand up 8. - Japanese proverb)
[ Post Reply | Private Reply | To 76 | View Replies ]

To: AndyTheBear
They could try to use the public key as the id itself, but that is problematic and could cause transaction/syncing issues with all the other tables and various databases when one tries to change their key pair.

Key management is really the hardest thing about PK crypto. Even when you're careful about such things people get confused when you update a key. I generally put a 5-year expiration on my PGP key. Sometime in year 4 it is necessary to generate a new key. Then you sign it with the old key. Then you revoke the old. That keeps the trust between the old and the new. If you have a hard drive crash, and don't have a backup, there is no way to revoke the old. It's now out there forever with no way to call it back. Sure, you can generate a new key, but then you'll run into folks trying to use the old one, and you can't decrypt anything encrypted to the old public key.

Most of the above could be easily dealt with through software, but really can't do much against the inevitable hardware failure unless you are careful about keeping a spare copy of your keyring.

83 posted on 10/04/2017 12:18:57 PM PDT by zeugma (I live in the present due to the constraints of the Space-Time Continuum. —Hank Green)
[ Post Reply | Private Reply | To 76 | View Replies ]

Free Republic
Browse · Search
News/Activism
Topics · Post Article


FreeRepublic, LLC, PO BOX 9771, FRESNO, CA 93794
FreeRepublic.com is powered by software copyright 2000-2008 John Robinson