When using Crypto++ to implements ECC encrypt&decrypt, can I make the encrypted text smaller?

Question

Recently I was using Bouncy Castle and Crypto++ to do some ECC decryption & encryption

After all the effort I make finally I implements the basic function : generate key pair, decrypt and encrypt text. They are implements in both C++ (using Crypto++) and Java (using Bouncy Castle), but I found these 2 projects' implements were rather different.

So here are my two related questions:

1. In JAVA I need to create 2 pair of keys, I don't know why I should create 2 pair of keys? Here is another user ask the same question another same question on stackoverflow .What's the point to use 2 pair of keys?

2. I encrypt & decrypt a string(10 bytes) by both JAVA and C++, of course, follow the example code. In Java I generate 2 pair of keys on the curve prime256k1. In C++ I generate a pair of keys on the curve secp256k1. The length of the keys are both 256 bit. When I get my encrypted text, I found the Java encrypted text's length is about 30 bytes, but the C++ length of the encrypted text is about 100 bytes. What makes these so different? Maybe because the 2 pair of keys? If so, why?

Answer 1

1. What's the point to use 2 pair of keys?

That's because you cannot directly encrypt with EC cryptography as you can with RSA (after secure padding). Instead ECDH is used, which is basically key agreement. You first import the public key of the other party, then you create your own key pair using the same parameters. Then you perform key agreement deriving the secret key seed. Then you simply toss away the temporarily required private key . This can be performed either implicitly or explicitly depending on the implementation.

Now if you send the other party your public key then the other party can also perform the key agreement and retrieve the secret key seed. This key seed is used as (base for) a secret key that's used to actually encrypt the data. This scheme is called EC-IES.

2. Maybe because the 2 pair of keys? If so, why?

As indicated above, the temporarily used public key of the sender needs to be included. This key will usually take once or twice the size of the ECC private key size. If you only get a ciphertext of 30 bytes with a key size of 256 bits / 32 bytes then the public key is probably not included in the ciphertext.

Of course using a different mode of encryption or inclusion of the IV or not may also make a difference. We'll need the used protocol, implementation and library specification to be sure of that.

So, no, you cannot make the ciphertext (much) smaller, as you need to encode the public key. You can use an implicit / named curve and point compression + possibly CTR mode with a zero IV to make the ciphertext smaller though.