6

I'm looking for a convenient way to share a set of public keys across multiple services, while preserving privacy by preventing these services from tying the identity of these public key sets together across services.

E.g. If I share my public key set with both Service 1 and Service 2, Service 1 and Service 2 should not be able to work together to discover that I have an account on both services.

Note that I don't want to simply generate a new set of key pairs for each service, as the private keys are distributed across multiple devices for security reasons (to avoid a single point of failure), and generating a new key pair on each of these devices every time I want to set up authentication for a new service would be inconvenient for the user.

While considering the best way to satisfy these requirements, I believe I've reduced the problem to the following:

Given a public key Kpub and some other bit of information x, I want to derive a public key K'pub such that the holder of Kpriv, and only that keyholder, given x, can find K'priv, and such that it is hard to find Kpub given K'pub and x.

So basically, it seems I want a key derivation function that can derive a public key, but which can't derive the corresponding private key without knowing some additional, secret information.

Is this possible? Is there any existing solution which satisfies the above requirements? Or am I breaking new ground here?

Ajedi32
  • 163
  • 3
  • 11
  • The whole point of using a public key is for identification. I don't think what you want is securely possible. – RoraΖ Jan 08 '15 at 19:06
  • What kind of services will this be for? SSH? – Scott Weldon Jan 08 '15 at 23:06
  • 1
    @ScottWeldon I expect this system to be generic enough to work with any kind of service, though I did have web services in mind specifically while considering this scheme. – Ajedi32 Jan 09 '15 at 14:43
  • This sounds promising: http://theory.stanford.edu/~bwaters/publications/papers/incomparable.pdf – Ajedi32 May 28 '15 at 16:07
  • 1
    I believe BIP32 does what you describe. – Mumbleskates Feb 21 '18 at 00:49
  • 1
    @Mumbleskates Wow... that actually might do it. And unlike other solutions, it seems that one allows the derived keys to create digital signatures. Nice! – Ajedi32 Feb 21 '18 at 18:46
  • @Ajedi32 No problem. I also looked into constructions with the same properties on other curves like Ed25519, with some dubious results. BIP32 is the only construction of this type in production that I know of (there may easily be others I don't know about). – Mumbleskates Feb 22 '18 at 00:27
  • Also be advised there are definitely some caveats to using these "HD" schemes. – Mumbleskates Feb 22 '18 at 00:43
  • @Mumbleskates Yeah, I read the BIP. Those caveats are documented there too. Shouldn't be a problem in this case, since I don't intend to ever store the child private keys anywhere that the master key is not stored. If you want to flesh that out into an answer I'll accept it; otherwise I might do that myself after I have a better handle on exactly how this will work. – Ajedi32 Feb 22 '18 at 03:08
  • I've posted a more fleshed-out answer for you. – Mumbleskates Feb 22 '18 at 07:48

4 Answers4

2

For public key encryption, there's an easy solution using a variant of Elgamal. (If you want to do authentication, you can use standard algorithms. If you specifically want signature schemes, say so.)

Recall that the security of Elgamal is equivalent to DDH, which is talking about indistinguishability of certain subgroups, namely given a cyclic group $G$, a (arbitrary) generator $g$ and an element of the group $y$, decide if the pair $(x,z)$ lies in the subgroup of $G \times G$ generated by the pair $(g, y)$.

We can phrase Elgamal as follows: To encrypt using the public key $(g,y)$, choose a random number $r$, compute $x=g^r$, $z=y^r$ and $w = zm$. The ciphertext is the pair $(x,w)$.

Deciding if $(x,w)$ is an encryption of $m$ is equivalent to deciding if $(x,w/m)$ lies in the subgroup.

Now observe that if $(g,y)$ is a public key, then $(g',y') = (g^b,y^b)$ is just as good a key.

Finally, to decide if $(g',y')$ and $(g'', y'')$ represent the same public key is equivalent to deciding if one lies in the subgroup generated by the other.

Most tricks you would use to improve the security of Elgamal would work for this variant as well, even with randomized keys.

With a bit of thinking, I am sure you can come up with lots of variations of this general idea.

K.G.
  • 4,617
  • 16
  • 32
  • You'll have to forgive my ignorance in this area (I came from [security.se], as you can see from the notice at the bottom of my question), but I'm having trouble understanding how the concepts you listed in this scheme map to requirements I listed. In this scheme, where does the information x from my question come into play? And what exactly is K'_pub in this scenario? Are you saying the ciphertext (x, w) can be used as a public key K'_pub? – Ajedi32 Jan 12 '15 at 15:42
  • Also, are you saying Elgamal can't be used for creating digital signatures? If so, that's definitely a downside to this scheme, though not a big one. In any case, digital signatures aren't necessary to fulfill the requirements I gave in the question. A challenge-response "decrypt this nonce" scheme will work fine for authentication. – Ajedi32 Jan 12 '15 at 15:49
  • Any encryption of $1$ can be used as a public key. The extra per-key information is not needed, as the same decryption key can be used for all the public keys made in this way. – K.G. Jan 12 '15 at 23:26
  • The Elgamal signature scheme is quite different from the Elgamal encryption scheme. This idea won't work for Elgamal signatures, indeed, it can't work for any signature scheme. – K.G. Jan 12 '15 at 23:28
  • Ah, okay. Let me see if I have this right. K'_priv = K_priv, so the keyholder already has K'_priv, and any choice of r when encrypting the number 1 with K_pub will result in a different K'_pub, depending on the choice of r. Additionally, elgamal encryption keys cannot be used for creating digital signatures in the way that RSA keys can. Does all that sound right to you? – Ajedi32 Jan 13 '15 at 15:21
  • Yep. ten letters – K.G. Jan 13 '15 at 16:41
1

I believe BIP32 does what you describe, and is the best-documented implementation of such a scheme that I know of, with very great motivation to attack it.

Overall this pattern is typically referred to as a "Hierarchical Deterministic" scheme, or "Hierarchical Deterministic Wallet" (since it is usually used for cryptocurrency). I have gathered it is applicable to a variety of different ECDSA curves, and possibly EdDSA as well, but I disclaim any personal knowledge of the specifics.

Mumbleskates
  • 126
  • 3
  • 1
    This seems to be exactly what I was looking for. The algorithm for deriving new public keys is described here in the BIP, and the section on security claims that going the other direction for child private keys (and by extension, public keys, since they can be generated from the private keys) would require a 2^256 brute force of HMAC-SHA512. Do be aware however of the security caveats in that same section. – Ajedi32 Feb 22 '18 at 16:59
0

Is this possible?

Yes.


Is there any existing solution which satisfies the above requirements?

That depends on what you mean by "existing". Trapdoored key generation can be used for that.
x is the chosen key generation algorithm, K$_{\text{priv}}$ and K'$_{\text{priv}}$ are both
its trapdoor, and the derivation of K'$_{\text{pub}}$ simply ignores K$_{\text{pub}}$.

  • Backdoored Key Generation seems like a really interesting potential solution, but I'm not familiar enough with the algorithms and math used in RSA to understand the details of that paper. Could you briefly summarize how this system could be used to satisfy the requirements I specified? – Ajedi32 Jan 09 '15 at 14:30
0

Yes, it is possible. Steve Gibson's SQRL does a similar thing: the user has a master private key, which is hashed together with a domain name to produce a site-specific public/private key pair. (The hash in this case is HMAC-SHA256, with the domain name used as the message.)

Your post doesn't mention what kind of services this will be for. If SSH, then you won't be breaking new ground either. While looking around to see how this could be applied to SSH, I found this proof-of-concept repo that appears to implement what I just described.

The underlying crypto in both cases is based on Dan Bernstein's ed25519 elliptic curve algorithm.

Scott Weldon
  • 101
  • 1
  • 2
  • 1
    Yes, I'm familiar with SQRL. As I understand it though, SQRL generates key pairs based on a shared secret. That wouldn't work in my case though, for the same reason that I don't want to simply generate a new random set of public keys for each service. In my scenario, there is no shared secret. The "secrets" are distributed across multiple devices, and for convenience I don't want all devices to need to be involved in order for a public key set to be generated. (See the 3rd paragraph in my question for more on that.) – Ajedi32 Jan 09 '15 at 14:36
  • Ah okay. So you want to be able to derive a public key from your master public key, without (currently) having access to the master private key? If so, you are correct that SQRL doesn't help you, because its site-specific public keys are generated directly from the site-specific private key. – Scott Weldon Jan 09 '15 at 18:05
  • 1
    Correct, that's the problem I'm running into. – Ajedi32 Jan 09 '15 at 19:03