0
$\begingroup$

Assume, there is a certificate authority whose public key: $pk$, is known. Also, the certificate $c$ is known, but not the signed certificate.

I want to encrypt a message: $m$, such that whoever has a signed certificate can decrypt the message. Note that the signed certificate may not be present at encryption time. To clarify, the signed certificate must be valid and related to $c$ and $pk$.

Question: What encryption can support the above scenario?


I'm aware that witness encryption may help but it's so inefficient.


Edit

Application: assume, party $A$ has a message $m$, it encrypts it: $Enc(m)$, such that when he dies, whoever gets his death certificate (i.e. a signed messages from a certain authority that confirms his death) can decrypt the ciphertext: $Enc(m)$.

So the question is what encryption scheme can the encryptor use?

$\endgroup$
  • $\begingroup$ What is certificate $c$ supposed to attest? What's it for? Also, a "signed certificate" is a signed public key. How do you suppose that one can decrypt with a public key and what does this signed certificate attest? $\endgroup$ – Artjom B. Dec 2 '17 at 9:54
  • $\begingroup$ What is a ‘certificate’ that is not a ‘signed certificate’? Wild guess: Maybe you're looking for identity-based encryption? $\endgroup$ – Squeamish Ossifrage Dec 3 '17 at 0:00
  • $\begingroup$ thanks for the comments, could you please see the edit section of my question. $\endgroup$ – Ay. Dec 4 '17 at 11:12
0
$\begingroup$

You can use a standard asymmetric encryption like RSA. Certificates merely serve the purpose of linking things to other things, approved by some (hopefully trusted and trustworthy) entity.

What you're probably thinking about is an ID certificate which links an identity to a public key. This key is in no way encrypted. It simply occurs in a field of the certificate. Signing the certificate does not change its fields. It just adds a signature of everything else.

This means that anyone with access to the certificate has access to the public key, be the certificate signed or not. Signing the certificate mere means: "I approve of this."

Regarding your edit: When you want to decrypt something, you have that something and it's not enough to attain the plain text, given the encryption is secure. You need some other information. Note that I don't say what that other information is but we know for certain that additional information is needed because if it wasn't anyone who obtained the ciphertext could compute the plain text which would mean that the encryption is not secure.

We now need to determine a possible piece of additional information α. That information has to come from somewhere. It doesn't just emerge for no reason because some outside event happened.

You dictated in your edit that that α has to be found on the death certificate. To have any chance of encrypting something using any such information, we need to require at least that these conditions are met:

  • As the encrypter, need to know some mathematical property of α. Note that we don't necessarily need to know α itself.
  • α needs to be of a nature such that there are plenty of possible variations for different α with the same structure. Otherwise an attacker could brute-force α.
  • The attacker must not know α or be able to reduce the solution space to a small number of known elements.

If it's not possible for the encrypter to collaborate with the authority issuing the death certificate, there is no α we can find because we can only use the information found on any normal death certificate: Name of the issuer, name of the person who died and other personal information like date of birth or address, date of death, location of death, file number, and signature of the issuer.

The name of the person and their other personal information is not a secret. As the encrypter, we don't have control over the signature of the issuer nor ever the file number as we cannot collaborate with the authority. The attacker will already know what authority issues the death certificate, so the issuer is known. So we're left with date and location.

As the date is only stated with the precision of days and we can be sure to know the date of death as an attacker, except for an uncertainty of approximately 100 years which is 36524 days and therefore 36524 possibilities (if we're generous). As the location of death is only stated to the precision of the municipality where the person died, there aren't many options for this either. Even for large countries like the US, there only are 19492 options. So we have a total solution space of 36524*19492 = 711925808 < 10^9 elements.

This is far too small to exclude brute-force attacks and this assumes we have total control over where in the country the person dies and how old they become which is both impractical.

So there are no possible α we can choose one from and therefore there cannot be any such encryption.

$\endgroup$
  • $\begingroup$ thanks for the answer, could you please see the edit section of my question. $\endgroup$ – Ay. Dec 4 '17 at 11:12
  • $\begingroup$ @AdrianAd Done. $\endgroup$ – UTF-8 Dec 4 '17 at 14:18
  • $\begingroup$ thanks, but witness encryption can do it. I need something more efficient.... $\endgroup$ – Ay. Dec 8 '17 at 10:26
  • $\begingroup$ It can't. You still need a large enough secret. This is fundamentally always the case. $\endgroup$ – UTF-8 Dec 9 '17 at 1:42
0
$\begingroup$

Think of it as using DSA or RSA on an encrypted certificate. The user signs an encrypted certificate. Now when the user try's to read the encrypted certificate. First the sign is confirmed using user's public key. Only after that confirmation completes the user will get the access to the decryption of certificate.

$\endgroup$
  • $\begingroup$ thanks for the answer, could you please see the edit section of my question. $\endgroup$ – Ay. Dec 4 '17 at 11:12
0
$\begingroup$

You seem to want to send a message based on a not yet verified certificate. This is a two part problem one is making sure only the owner of the matching private key can decrypt. The other is requiring the certificate be signed at some point. The first is easy. The second not so much. Especially if you want to use standard pki which will pad and add randomness so the signed certificate isn't even uniquely defined. However I suspect a smart contract may allow solving this.

$\endgroup$
  • $\begingroup$ thanks for the answer, could you please see the edit section of my question. $\endgroup$ – Ay. Dec 4 '17 at 11:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.