The situation involves a single party (single certificate) who would want to AES encrypt a file that they can later decrypt. Assume the EC certificate + EC keys have a purpose i.e. "File encryption" (similar to EFS perhaps), issued to a human ("Mr CSO") or an application ("My cat photo app"). Certs would be off existing organizational PKI.

EDIT: Certificate's are involved as there is already a PKI being maintained. We'd like to reuse that instead of introducing another (AES)-Key-Infrastructure. The AES key is encrypted in file header and it later decrypted via the private key. It's a usability issue.

EDIT#2: It's a storage use-case, the receiver IS the sender, timeshifted. Storage medium itself is untrusted. Actually the signature might be an overkill since the internal AES is authenticated AES.

With RSA Certs, at an abstract level can be as simple as

AESKey_encrypted = RSA_Encrypt(public key, AESKey) ---- (1)
AESKey_signed = RSA_Sign(private key, AESKey)      ---- (2)

File = AESKey_encrypted | AESKey_signed | AES(File_clear, AESKey)

FYI, the AES is authenticated AES which is why there is no separate HMAC. Anyway, a customer wants Elliptic curve crypto (the 521p curve) instead of RSA. The EC counterpart for (2) is clear (ECDSA) but the EC counterpart for (1) is something I'd like to hear from you guys. Any other comments also appreciated. Just to remind, there is no 2nd party/2nd party's cert.

Finally, any algorithmic concerns on mixing public key + bucket of bits AND private key + same bucket of bits (1, 2 above)? To the best of my understanding, those interactions have no proven algorithmic or structural weaknesses.

  • 1
    $\begingroup$ Using asymmetric encryption is rather silly if the target is yourself. It's easier and stronger to use a symmetric secret for that. Can't you derive the P521 private key and the AES key from the same master key? That'd be a strong an clean solution. $\endgroup$ – CodesInChaos Jul 2 '13 at 20:05
  • $\begingroup$ @CodesInChaos: True, but it's a usability issue if the file encryption required a separate (symmetric)-key-infrastructure in parallel to the existing PKI. The certificates are involved to limit secrecy to just that of the private key (which is already kept secret). The per-file AES key is stored in file, recovered via the private key. At least for the RSA part. $\endgroup$ – DeepSpace101 Jul 3 '13 at 0:16
  • 1
    $\begingroup$ There is a very good reason why you should keep encryption and signing keys and certificates separate from each other. Requiring the same private key to be available to the sender and receiver is clearly not a smart thing to do. Use two key pairs & matching certificates instead. Or go with symmetric encryption as CodesInChaos suggested. $\endgroup$ – Maarten Bodewes Jul 3 '13 at 0:24
  • 1
    $\begingroup$ @owlstead: It's a storage use case, receiver IS the sender, timeshifted. $\endgroup$ – DeepSpace101 Jul 3 '13 at 0:32
  • $\begingroup$ Well, if you really require ECC you could maybe try ephemeral static elliptic curve Diffie-Hellman - but that's a stretch. $\endgroup$ – Maarten Bodewes Jul 3 '13 at 0:45

You can use ECIES, though it's not widely implemented.


For anyone reading this, the decision was to use ephemeral-static EC keys. Take a look at NIST SP800-56A. Section 6.2.2 describes some interesting details.


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.