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=KDF(nonce) 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.