3
$\begingroup$

I am trying to consider the feasibility of implementing an encrypted file sharing system, which both provides forward secrecy but also allows public key verification. I am stuck on the marriage between these two requirements that hopefully someone can help me out with.

In order to provide forward secrecy, I think a new random keypair should be generated for every file transfer request rather than two users sharing long-term public keys in advance. That way, if a private key for a particular file share is somehow compromised, it would only compromise that one file and not all of the files ever sent from that user.

However, the creation of a new keypair for every file share introduces a problem with public key verification. Traditionally speaking, the fingerprint of a public key should be verified in person and would remain verified for the lifetime of the keypair. If a new keypair is generated for every file share, then that means each new public key needs to be verified in person, which is infeasible.

Is it possible to utilize unique keypairs for every file share for forward secrecy while also securely verifying a public key is sent from the correct user only once?

Note that the system is meant for asynchronous file transfer, meaning the encrypted data would be uploaded to the cloud temporarily until downloaded by the recipient. However, file share requests would include a mandatory expiration date.

Improve this question
$\endgroup$
11
  • 3
    $\begingroup$ When a transfer is requested, are both ends online? $\endgroup$
    – mikeazo
    Jul 20, 2015 at 19:54
  • 1
    $\begingroup$ Did you consider the performance impact of generating many new keypairs? Generating a new keypair may not be cheap. (It is for ECIES / ElGamal, but not for RSA). You could use maybe a long-term signature key (strongly verified), which signs every ephemeral public key you provide. That's the standard approach for key-exchange and may be useful in your situation as well. $\endgroup$
    – SEJPM
    Jul 20, 2015 at 19:57
  • 1
    $\begingroup$ @WilliamThomas I edited that into the question. $\endgroup$
    – mikeazo
    Jul 20, 2015 at 20:03
  • 1
    $\begingroup$ @RickyDemer I didn't even know forward authenticity was a thing. $\endgroup$
    – mikeazo
    Jul 20, 2015 at 23:41
  • 1
    $\begingroup$ @WilliamThomas BTW, welcome to our site! $\endgroup$
    – mikeazo
    Jul 21, 2015 at 0:44

1 Answer 1

Reset to default
1
$\begingroup$

I'm going to describe two options that you have. There may be more that I don't know about.

The first is to use long-term signing keys to sign public diffie-hellman keys. Upload a bunch of those to the cloud. Then when someone wants to share a file with you, they:

  1. download your "next" signed public diffie-hellman key
  2. verify the signature using OpenPGP, abort if it fails
  3. generate their own new public diffie-hellman key
  4. use your "next" key to generate a shared secret key (using their private diffie-hellman key), encrypt the file with that (you can actually use OpenPGP for this too, it would be the symmetric key for encryption)
  5. sign their new public diffie-hellman key with their long term secret (using OpenPGP)
  6. upload their signed public ephemeral diffie-hellman key, an index describing which of your temporary public keys they used, and the encrypted message
  7. delete their new public diffie-hellman key, etc.

When you come along later to download the file, you:

  1. download everything they uploaded in #5
  2. check the digital signature using OpenPGP, if it fails abort
  3. use your temporary private key for the given index to compute the shared secret key
  4. decrypt the file
  5. delete your temporary private key, their signed temporary public key, etc.

This is basically what Open Whisper Systems does for encrypted text messages.

Your other option is to throw away OpenPGP and do what is described in A Forward-Secure Public-Key Encryption Scheme and discussed in this answer*.

*Okay, that answer does mention my first proposal too as a "trivial (and hence awful) solution". I've added more detail and the link to Open Whisper Systems. Since Open Whisper Systems is doing it, it can't be too awful, right?

Improve this answer
$\endgroup$
7
  • 1
    $\begingroup$ Note, I am assuming that the cloud is trusted to enforce the expiration date. $\endgroup$
    – mikeazo
    Jul 20, 2015 at 20:20
  • $\begingroup$ Before seeing this answer, I had written out a schema using long-term signing keys after seeing @SEJPM's comment. It's similar but has some differences from your suggested implementation. If you don't mind, could you take a look here and tell me what you think? - ghostbin.com/paste/rggcb $\endgroup$
    – William Thomas
    Jul 20, 2015 at 22:27
  • 1
    $\begingroup$ @WilliamThomas I took a look at it. It doesn't provide forward secrecy. In step 2, Alice encrypts the temporary RSA key pair with Bob's long-term key. So, if in the future, Bob's long-term key is compromised, the attacker can get the temporary RSA key pair and therefore, can get the key with which the file was encrypted. $\endgroup$
    – mikeazo
    Jul 20, 2015 at 23:50
  • 1
    $\begingroup$ Also, as a side note, in the scheme you posted, Alice gets to pick the expiration date for her request for Bob's data. That seems backwards. $\endgroup$
    – mikeazo
    Jul 20, 2015 at 23:51
  • 1
    $\begingroup$ @WilliamThomas, you can definitely create it when requesting the file. I don't see any issues there. $\endgroup$
    – mikeazo
    Jul 21, 2015 at 0:43

Your Answer

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

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