Take the 2-minute tour ×
Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It's 100% free, no registration required.

I'm working on a program that uses an ECC keypair in a (password protected) PKCS12 file (.pfx) to encrypt files. I like this method because I think it will be higher security (using ECDH to negotiate the key) and more easy to use (one PIN for all files). How I'm going about this is by using the public and private keys of the same certificate to negotiate a secret using ECDH. A SHA-256 of this secret is used every time to encrypt a random generated key just for that file. The program outputs file.enc, kek.iv, kek.enc, file.iv all in a zip for the encryption portion of the program. file.enc is the ciphertext of the original file, kek.iv is the IV used to encrypt the file-specific key (session key if you will). kek.enc is the ciphertext of the file-specific key that has been encrypted with the shared secret. And by "I'm working on this program", I mean I already wrote the program but it's not working and I'm starting to question the fundamental logic.

My question is, is it even possible to get the same ECDH secret every time between the same public/private key pair so that it can be used to encrypt files? If not, how can I achieve the goal of encrypting files with one keypair?

Btw I'm trying to implement Suite B so I'm using ECC(P-521) keys for ECDH and AES-256/GCM with BouncyCastle

share|improve this question

3 Answers 3

The ECIES (Elliptic Curve Integrated Encryption Scheme) should be used for encrypting file and data. ECC(P-521) is over kill, P-256 is enough secure and more efficient.

share|improve this answer
Looking through the specs on the algorithm, there is a message to be encrypted and decrypted so that wouldn't be the entire file but rather the regular symmetric AES key for encrypting the file, correct? In other words, the ECIES scheme only protects the key for regular AES file encryption? –  Андрей Feb 19 '13 at 21:16

I don't recommend implementing your own file encryption program (unless you are already a crypto expert, and maybe not even then). There are many tricky details that are easy to get wrong. Enumerating all of them is beyond the scope of what can be answered in a single question here.

Instead, I recommend using something that has already been well-vetted, like GPG or Truecrypt or some other highly regarded scheme for file encryption.

share|improve this answer

It is not possible to get the same secret every time. You get a new random shared secret reach time. The protocol (for a known generator $g \in G$ where $G$ and $g$ are chosen correctly) is Alice computes $A=g^a$ and sends $A$ to Bob.
$$Alice \ g^a\xrightarrow{A} Bob$$ Then Bob computes $B=A^b$ and sends it to Alice. $$Alice \xleftarrow{B} B=A^b\ Bob$$ where $a$ and $b$ are choosen at random and the shared seceret that comes out is $g^{ab}$. Because $a$ and $b$ are chosen randomly each time, you get a fresh secret.

Don't use your own file encryption. There are systems out there. GPG, Truecrypt, Bitlocker if you are on windows and are ok with closed source crypto (which is still probably better than homegrown)

share|improve this answer
I understand the risks with say temporary files being written to the disk and keys staying the in the RAM, especially in a high-level language as Java or C#. Basically I'm trying to implement NSA Suite B encryption for a personal project, not really to protect anything valuable. All the ZIPing and stuff is just to keep the required parts of the encryption together. –  Андрей Mar 23 '13 at 3:42

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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