3
$\begingroup$

Given a PKI infrastructure with a root node that signs CSR's for nodes Alice, Bob, and Carol. Is it possible for Alice to encrypt some information, store it publicly somewhere, then later Bob or Carol can decrypt that information, without Alice, Bob, nor Carol directly communicating?

The only thing they have in common is their PKI (each their private key, their public key and root's public key), and the one-way transfer of ciphertext from Alice to the public storage, then on to Bob or Carol.

Neither Bob nor Carol's public keys are available to Alice (in the real problem, Bob and Carol don't yet exist but will in the future, after Alice has generated the ciphertext)

The root CA cannot participate in this other than as a typical signer; that is, we cannot ask the root to do the encryption/decryption for us.

$\endgroup$
6
  • $\begingroup$ Not possible for a typical PKI at least. Are there any restrictions on the PKI itself, i.e. must the CA be a common CA as used in e.g. browsers? Or can it use specific protocols, schemes and primitives. $\endgroup$
    – Maarten Bodewes
    Commented Aug 25, 2017 at 20:02
  • $\begingroup$ The P in PKI means you can publish your keys, if you can do that everybody has access to them. And by introducing a trusted thirdparty you do not need to worry about getting the wrong keys. $\endgroup$
    – eckes
    Commented Aug 25, 2017 at 20:07
  • $\begingroup$ @MaartenBodewes, eckes - Thanx for the quick response. I've simplified the problem for posting, in reality there's more involved, but this may help here instead of hinder. We don't have much control over the root CA, but there's another layer to the PKI, a layer of intermediate authorities (IA's) that are distributed around the world, and we do have control of what runs on those servers. It's possible we can use that for a trusted key store or similar. I had hoped for some clever mathematical trick or algorithm, but if it requires a keystore then we'll go that route. $\endgroup$ Commented Aug 25, 2017 at 20:29
  • 3
    $\begingroup$ It sounds like you want a way for Alice to encrypt something that a future Bob will be able to decrypt, but a future Dave (who's also a member of the PKI) will not, correct? If so, this future Bob will need to know something that future Dave won't (and tied to something that current Alice knows). IBE might be an answer (current Alice can know future Bob's public key), but that's not within the current PKI structure... $\endgroup$
    – poncho
    Commented Aug 25, 2017 at 20:49
  • $\begingroup$ If you don't want to store the keys centrally, then send them peer to peer before using. Like S/Mime which typically attaches the certificate so you can answer easy. $\endgroup$
    – eckes
    Commented Aug 26, 2017 at 15:41

2 Answers 2

1
$\begingroup$

This sounds like the scenario of identity-based encryption, or IBE.

In IBE, the ‘root CA’, called the private key generator or PKG in this scenario, doesn't handle encrypting or decrypting messages directly, but does have to furnish Bob and Carol with their respective private keys. As long as Alice knows the names Bob and Carol, and the long-term master public key of the PKG, Alice can send encrypted messages to Bob and Carol—even offline, without contact with the PKG. Then whoever can convince the PKG that they are named Bob or Carol will get a private key to decrypt those messages.

Of course, the PKG is a central point of failure: anyone who can compromise the PKG can decrypt all messages.

$\endgroup$
1
  • $\begingroup$ Thanx @Squeamish, this sounds like what I want. I'll dig into it! $\endgroup$ Commented Nov 12, 2017 at 19:39
0
$\begingroup$

sorry for the delay in responding. We've been busy with our Houston datacenters due to the hurricane. Anyway, here's the direction we're taking, FWIW:

  • I gave up on the idea of deriving some magical asymmetric key-pair from the PKI parameters, 'cuz, as you indicated, its not possible. :-(
  • For the first pass we're just going with a trusted key store.
  • On the back burner I'm investigating threshold schemes, such as Shamir's secret sharing algorithm. When future Bob's and Carol's "join" and get a certain level of trust, we recompute the shards for all. I'll probably come back here for your opinions at that time!

Thanx again!

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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