Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Plausible deniability #23

Open
ghost opened this issue Dec 18, 2014 · 3 comments
Open

Plausible deniability #23

ghost opened this issue Dec 18, 2014 · 3 comments

Comments

@ghost
Copy link

ghost commented Dec 18, 2014

I got together in meatspace to talk about these ideas with an acquaintance of mine, @tjgillies, and one of the questions that came up was how to help protect against "tire iron" attacks. If we succeed, the cryptographic identities created with this system could prove very valuable. Re-verifying biometrics every time one wants to use one's cryptographic identity is not really an option. So a person could feasibly kidnap another person and break their kneecaps until they give up their private key. We had a couple ideas for allowing a degree of protection/deterrence from these sorts of attacks:

  1. Allow for key expiration and provide a sane default in whatever software comes out of this project.
  2. Allow for key reassignment at "induction" events by presenting n-of-m identity proofs.
  3. Create an arbitrary/random-length chain of keys where each public key serves as the seed for deriving the private key portion of the next key pair in the chain. Users would use the last link in the chain as their cryptographic identity and then keep as many of the key pairs higher up in the chain as they wish as "higher" proofs of ownership for the lower keys. That way an attacker could never be sure if I'd given them the highest key pair or not. Using deadman switches and Shamir's Secret Sharing, you could even set up a system where you yourself don't even know your highest key, but only have a single piece of it and your compatriots have the rest.
@wrapperband
Copy link

I can also see proof of anonymous identity would be useful, say for whistleblowers. But they then need to prove it was them, say to get the wrong person out of jail, or write the official book, at a later date without showing their real identity. Or, Satoshi for that matter, you donate free code and don't want any "comeback" or your "name" taken over. In which case the "photo" could be retained and encrypted "matadata" of the photo / identity mechanism would be on the "license". i.e this could be achieved by having anonymous identity (or generation instructions) built in to the card. worth considering

@ghost
Copy link
Author

ghost commented Dec 18, 2014

Hmm... I wasn't even thinking about this in terms of anonymous identities and whistleblowers, but yeah, you're totally right. My own mindset has been around trying to create reliable, publicly-verifiable one-to-one mappings of physical identities to cryptographic identities, but this idea can certainly be generalized out to less stringent identities as well.

Going a bit deeper with item number 3 on my list and playing off of your whistleblower with anonymous identities example, one could actually create identity trees if one wanted to. Appending or prepending nonces to the private keys at the levels you wish to branch at should do quite handily, unless this introduces some kind of cryptographic weakness I'm unaware of. (Obviously the nonce would be non-random, but if there are already enough random bits preceding or following the nonce, the nonce shouldn't do anything to reduce security any lower than the security of the key it's been added to, as far as I can tell.)

That way a person could prove ownership of as many seemingly-unrelated identities as their branching scheme allows all at once using a single private key. (A different private key for each unique set of identities, of course.) That might be more flexibility than anyone needs, but you never know.

There's no way I'm the first person to think of this, though. Does anyone else recognize this idea and know the proper name for it? I'd be interested in seeing what others have written about it.

One more thing in closing: I'm not sure I understood what you said in the last part of your post regarding Satoshi and photo metadata. Could you clarify?

@MrChrisJ
Copy link
Owner

Hey @ryepdx these are great ideas and thanks to your high technical understanding you have formulated a good plan which has specifics.

  1. I think it's a good idea for expiration
  2. It would be good if the protocol had baked in an automatic revocation upon the creation of new identities. So at induction you want to be sure you have a protocol that is air tight and easy to follow
  3. That is quite genius, how did you think of that? Or is it something that's been done, I haven't heard of it. I was thinking in case of kidnappings that you would have a higher key that would require some kind of next of kin or "Someone-Who-Knows-You" verify it. So your plan of using Shamir's Secret could work.

The idea in my head was that at the ID Induction you would create a parent key which would then created child keys with revoke certificates. You might want to create a few and just use those for your everyday online dealings.

Then in the case of a lost or stolen key you just upload the revoke cert.

In cases where someone hijacks your online identity your friends on social network could petition you via Keybase to revoke your key to stop the attacker having access.

Now let's suppose the kidnapping example. In addition to your idea we can also use Steganography. You could predefine a panic word used with a specific key which when used would also trigger a distress signal or a revocation. It could do this silently or overtly.

I wonder if there's anything we could do using something like TrueCrypt which can full disk encrypt a volume with two partitions, one real one, one fake one, this also gives plausible deniability. Not sure if this could be useful because the attacker would have a way of knowing your key usage by looking at your public profile and ID card.

Deadman's switch has also occurred to me specifically in conjuction with biometric wearables that monitor heart rate and proximity alarms (detectors that go off when taken apart). This could also trigger an alarm. If attackers knew ahead of time that a good proportion of the population were wearing these it could be enough of a disincentive to prevent such cases.

Good thoughts. What do you need to get this moving?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants
@wrapperband @MrChrisJ and others