<p>The best way to answer this is to look at the security model in that paper.  If the adversary is allowed to request the partial private key for the target identity (i.e. the one it uses in the left-right query during the attack), then partial-private-keys are not meant to be kept secret.  If the adversary is not allowed to do so, then they must remain confidential.</p>

<p>After scanning their model, it seems that all partial private keys are readily supplied to adversary via Extract-Partial-Private-Key-of-A queries. This means they don't need to be kept secret.</p>

<p>I've got to run now, but I'll edit later if I've gotten this wrong.</p>

CC BY-SA 2.5
2010-12-19T21:33:19.123Z
Extract-Partial-Private-Key-of-A queries must be authenticated somehow. That method is the basis of the trust that the KGC is giving for its users. If any adversary can just get a partial private key, the KGC brings no new trust over just self-signed certificates in the traditional model.
Nakedible
CC BY-SA 2.5
2010-09-21T00:47:36.397Z
I saw that, and I thought that that's what it meant, but if that's true I don't understand what the KGC is needed for - couldn't it be replaced with "generate a random number"?
zwol
CC BY-SA 2.5
2010-09-21T01:51:31.423Z
Interestingly, the paper directly contradicts what I said above: "The process of supplying partial private keys should take place confidentially and authentically: the KGC must ensure that the partial private keys are delivered securely to the correct entities."  The model does not represent this, at least in my reading of it.
David Cash
CC BY-SA 2.5
2010-09-21T02:08:36.577Z
Apparently the edits to comment above were lost.  I was adding that the KGC provides some sort of authenticity - without an authority, there is no way to distinguish real keys from fake keys.  I'm not sure what type of authenticity they provide.  (Sorry for the vague answer - crypto questions don't get much attention on here, so I'm doing my best without having read all of the CL-PKE papers...)
David Cash
CC BY-SA 2.5
2010-09-22T17:40:12.637Z
So what I'm really wondering is if it would be possible to use a public signature that exists for some other reason (like, it's the DNSSEC signature for the apex of your zone) as the partial private key.  I'm not sure that is better than just signing the complete public key, except that it might let you derive a whole bunch of keys from one signature without further involvement by the trusted third party.
zwol
CC BY-SA 2.5
2010-09-21T00:02:53.483Z
2010-09-21T00:02:53.483Z
David Cash
<p>In certificateless public key cryptography, the partial private keys <em>are</em> confidential information. Namely:</p>

<ul>
<li>If an adversary has access to party A's partial private key $D_a$, it can publish a false public key $P_a&#39;$, and is able to decrypt any communication addressed to it and able to create signatures with it</li>
</ul>

<p>The only thing keeping this from happening (that is, the only thing that is <em>authenticating</em> the user) is that it has possession of $D_a$ - the secret part that the user has is only used to prevent message decryption and signing by other parties except the user, but it obviously plays no part in authentication, as anybody can create such a secret part.</p>

<p>If the server is compromised, the server can fake any key for anybody any way they wish - just like in identity based cryptography - the only special sauce that certificateless public key cryptography adds is that on server compromise, the adversary still can not decrypt any messages for the user or fake any signatures for the <em>old</em> published public key.</p>

<ul>
<li>Even if an adversary gains access to $D_a$, the only thing lost is <em>authentication</em>, as the adversary can publish a new key $P_a&#39;$, but confidentiality or non-repudiation for messages with the old public key $P_a$ are not lost</li>
</ul>

<hr>

<p>A simple way to think about certificateless public key cryptography:</p>

<ul>
<li>KGC creates a keypair for you and sends it to you</li>
<li>You create a keypair by yourself</li>
<li>Possession of the KGC generated private key certifies that the KGC trusts you</li>
<li>Possession of your own private key certifies yourself, so the KGC can't fake you</li>
<li>When signing a message, you sign it with both keypairs, proving that the KGC trusts you, and that you are indeed you</li>
<li>When somebody verifies your signature, they need both public keys to be convinced that both conditions hold</li>
</ul>

<p>From this, it should be obvious that both keypairs need to be proper keypairs with public and private parts, and that the private parts need to be kept secret for the authentication to have meaning.</p>

<p>Obviously this is a crude simplification, as the real method combines the two keypairs and uses identity based cryptography for the KGC keypair - but the basic idea applies.</p>

CC BY-SA 2.5
2010-12-20T19:26:28.547Z
I think I get this, but could you comment particularly on the scenario I mentioned in my comments on David's answer, where instead of a KGC, you use a public signature that exists for some other reason as the partial private key?
zwol
CC BY-SA 2.5
2010-12-20T20:59:05.580Z
If the *public* signature for some other reason is really that, public, then anybody who has access to that can use that as a partial private key, create a keypair, and publish their own public key - and there would be no way to tell your correct key apart from the false key that other party has published. If that signature, on the other hand, is only available to you, then no outsider can verify the signature and you don't still gain anything beneficial.
Nakedible
CC BY-SA 2.5
2010-12-19T21:19:08.603Z
2010-12-20T21:11:31.043Z
2010-12-20T21:11:31.043Z
Nakedible
<p>I'm looking at alternatives to PKI and I'm having trouble understanding exactly how certificateless public key algorithms (e.g. <a href="https://doi.org/10.1007%2F978-3-540-40061-5_29?from=SL" rel="nofollow noreferrer">Al-Riyami and Paterson</a>, <a href="https://dl.acm.org/doi/10.1145/1229285.1266994" rel="nofollow noreferrer">Liu et al</a>) work in practice.  It <em>seems</em> like the &quot;partial private key&quot; generated by the KGC in these systems is not actually confidential information (which would be awfully convenient for practical use of the system), but if it isn't, then I don't understand why the KGC and its master secret are necessary.</p>
<p>(I hope this isn't too &quot;practical&quot; a question for this site.)</p>

CC BY-SA 2.5
2010-09-20T23:56:04.950Z
Since tags beginning with cs are being reorganized to remove the cs prefix (http://meta.cstheory.stackexchange.com/questions/340/retag-all-cs-xyz-abc-to-xyz-abc), the correct tag to use here is [cr.crypto-security].  Since no questions were given the [cr.crypto-security] tag before this one, you might have received some weird error message (or you might not, I do not know how the system of this website works).
Tsuyoshi Ito
CC BY-SA 2.5
2010-09-21T00:45:45.807Z
It was saying that I didn't have enough reputation points to create the tag [cr.crypto-security], which was completely baffling, but I think I understand now.  Thanks for fixing it.
zwol
<ds.algorithms><cr.crypto-security>
Confidentiality of "partial private keys" in certificateless public key crypto
zwol
# Confidentiality of "partial private keys" in certificateless public key crypto

(Asked by: username_0 on 2010-09-20)

I'm looking at alternatives to PKI and I'm having trouble understanding exactly how certificateless public key algorithms (e.g. [Al-Riyami and Paterson](https://doi.org/10.1007%2F978-3-540-40061-5_29?from=SL), [Liu et al](https://dl.acm.org/doi/10.1145/1229285.1266994)) work in practice. It *seems* like the "partial private key" generated by the KGC in these systems is not actually confidential information (which would be awfully convenient for practical use of the system), but if it isn't, then I don't understand why the KGC and its master secret are necessary.

(I hope this isn't too "practical" a question for this site.)

**Tags:** ds.algorithms, cr.crypto-security
> **Comments:**
> **username_1**: Since tags beginning with cs are being reorganized to remove the cs prefix (http://meta.cstheory.stackexchange.com/questions/340/retag-all-cs-xyz-abc-to-xyz-abc), the correct tag to use here is [cr.crypto-security].  Since no questions were given the [cr.crypto-security] tag before this one, you might have received some weird error message (or you might not, I do not know how the system of this website works).  
> **username_0**: It was saying that I didn't have enough reputation points to create the tag [cr.crypto-security], which was completely baffling, but I think I understand now.  Thanks for fixing it.  

---

## 2 answers

### Answer by username_2 on 2010-09-21. Score: 1 | Accepted answer

The best way to answer this is to look at the security model in that paper. If the adversary is allowed to request the partial private key for the target identity (i.e. the one it uses in the left-right query during the attack), then partial-private-keys are not meant to be kept secret. If the adversary is not allowed to do so, then they must remain confidential.

After scanning their model, it seems that all partial private keys are readily supplied to adversary via Extract-Partial-Private-Key-of-A queries. This means they don't need to be kept secret.

I've got to run now, but I'll edit later if I've gotten this wrong.

> **Comments:**
> **username_0**: I saw that, and I thought that that's what it meant, but if that's true I don't understand what the KGC is needed for - couldn't it be replaced with "generate a random number"?  
> **username_2**: Interestingly, the paper directly contradicts what I said above: "The process of supplying partial private keys should take place confidentially and authentically: the KGC must ensure that the partial private keys are delivered securely to the correct entities."  The model does not represent this, at least in my reading of it.  
> **username_2**: Apparently the edits to comment above were lost.  I was adding that the KGC provides some sort of authenticity - without an authority, there is no way to distinguish real keys from fake keys.  I'm not sure what type of authenticity they provide.  (Sorry for the vague answer - crypto questions don't get much attention on here, so I'm doing my best without having read all of the CL-PKE papers...)  
> **username_0**: So what I'm really wondering is if it would be possible to use a public signature that exists for some other reason (like, it's the DNSSEC signature for the apex of your zone) as the partial private key.  I'm not sure that is better than just signing the complete public key, except that it might let you derive a whole bunch of keys from one signature without further involvement by the trusted third party.  
> **username_3**: Extract-Partial-Private-Key-of-A queries must be authenticated somehow. That method is the basis of the trust that the KGC is giving for its users. If any adversary can just get a partial private key, the KGC brings no new trust over just self-signed certificates in the traditional model.  

---

### Answer by username_3 on 2010-12-19. Score: 1

In certificateless public key cryptography, the partial private keys *are* confidential information. Namely:

* If an adversary has access to party A's partial private key $D\_a$, it can publish a false public key $P\_a'$, and is able to decrypt any communication addressed to it and able to create signatures with it

The only thing keeping this from happening (that is, the only thing that is *authenticating* the user) is that it has possession of $D\_a$ - the secret part that the user has is only used to prevent message decryption and signing by other parties except the user, but it obviously plays no part in authentication, as anybody can create such a secret part.

If the server is compromised, the server can fake any key for anybody any way they wish - just like in identity based cryptography - the only special sauce that certificateless public key cryptography adds is that on server compromise, the adversary still can not decrypt any messages for the user or fake any signatures for the *old* published public key.

* Even if an adversary gains access to $D\_a$, the only thing lost is *authentication*, as the adversary can publish a new key $P\_a'$, but confidentiality or non-repudiation for messages with the old public key $P\_a$ are not lost

---

A simple way to think about certificateless public key cryptography:

* KGC creates a keypair for you and sends it to you
* You create a keypair by yourself
* Possession of the KGC generated private key certifies that the KGC trusts you
* Possession of your own private key certifies yourself, so the KGC can't fake you
* When signing a message, you sign it with both keypairs, proving that the KGC trusts you, and that you are indeed you
* When somebody verifies your signature, they need both public keys to be convinced that both conditions hold

From this, it should be obvious that both keypairs need to be proper keypairs with public and private parts, and that the private parts need to be kept secret for the authentication to have meaning.

Obviously this is a crude simplification, as the real method combines the two keypairs and uses identity based cryptography for the KGC keypair - but the basic idea applies.

> **Comments:**
> **username_0**: I think I get this, but could you comment particularly on the scenario I mentioned in my comments on David's answer, where instead of a KGC, you use a public signature that exists for some other reason as the partial private key?  
> **username_3**: If the *public* signature for some other reason is really that, public, then anybody who has access to that can use that as a partial private key, create a keypair, and publish their own public key - and there would be no way to tell your correct key apart from the false key that other party has published. If that signature, on the other hand, is only available to you, then no outsider can verify the signature and you don't still gain anything beneficial.  

---

