Crypro++ ECIES compatybility with openSSL

1,037 views
Skip to first unread message

David Xanatos

unread,
Apr 15, 2015, 2:58:09 PM4/15/15
to cryptop...@googlegroups.com
Hello,

I would like to be able to use openSSL with data encrypted by crypto++ using ECIES with,
the ECDH key exchange and ECDSA seams compatible, but openSSL does not have any functions for EC based encryption.
since ECIES is something on the lines of a ECDH + some simple crypto operations I think its doable to implement it by hand using standard openSSL functions.
however it seams quite complicated is there some ware some simple description how ECIES as used by Crypto++ works?

Or has anyone did that already?

David X.

David Xanatos

unread,
Apr 15, 2015, 4:23:08 PM4/15/15
to cryptop...@googlegroups.com
ok that was indeed simple enough assuming its all right for all cases:


        int curve_id = EC_GROUP_get_curve_name(EC_KEY_get0_group((EC_KEY*)m_pPrivKey));
            EC_KEY
* temp_key = EC_KEY_new_by_curve_name(curve_id);
            size_t uPubLen
= i2o_ECPublicKey((EC_KEY*)m_pPrivKey, NULL);
            o2i_ECPublicKey
(&temp_key, (const byte**)&pCiphertext, uPubLen); // warnign this moves the pCiphertext pointer
            uCiphertextSize
-= uPubLen;

            size_t
SecLen = (EC_GROUP_get_degree(EC_KEY_get0_group((EC_KEY*)m_pPrivKey)) + 7) / 8;
           
byte* pSec = new byte[SecLen];
           
int ret = ECDH_compute_key(pSec, SecLen, EC_KEY_get0_public_key(temp_key), (EC_KEY*)m_pPrivKey, NULL);
            ASSERT
(ret == SecLen);

            EC_KEY_free
(temp_key);

           
CHashFunction GenFx(CHashFunction::eSHA1); // <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

            uPlaintextSize
= (uCiphertextSize > GenFx.GetSize()) ? (uCiphertextSize - GenFx.GetSize()) : 0;

           
int mac_key_len = 16;

           
int GenLen = uPlaintextSize + mac_key_len;

            uint32 counter
= 1;
           
CBuffer GenHash;
           
while(GenHash.GetSize() < GenLen)
           
{
               
GenFx.Add(pSec, SecLen);
               
CBuffer Buff;
               
Buff.WriteValue<uint32>(counter++, true);
               
GenFx.Add(&Buff);
               
GenFx.Finish();
               
GenHash.AppendData(GenFx.GetKey(), GenFx.GetSize());
               
GenFx.Reset();
           
}
           
GenHash.SetSize(GenLen); // truncate

           
delete pSec;

           
byte* key = GenHash.GetBuffer();
           
byte* macKey = key + uPlaintextSize;

           
unsigned char* result;
            size_t mac_len
= uCiphertextSize - uPlaintextSize;
            ASSERT
(mac_len == 20);
 
           
byte* mac_result = new byte[mac_len];

            HMAC_CTX ctx
;
            HMAC_CTX_init
(&ctx);
 
            HMAC_Init_ex
(&ctx, macKey, mac_key_len, EVP_sha1(), NULL);
            HMAC_Update
(&ctx, pCiphertext, uPlaintextSize);
            HMAC_Final
(&ctx, mac_result, &mac_len);
            HMAC_CTX_cleanup
(&ctx);

           
Ret = memcmp(pCiphertext + uPlaintextSize, mac_result, mac_len) == 0 ? 1 : 0;

           
delete mac_result;

            ASSERT
(pPlaintext == NULL);
            pPlaintext
= new byte[uPlaintextSize];
           
for(int i=0; i < uPlaintextSize; i++)
                pPlaintext
[i] = pCiphertext[i] ^ key[i];



Jeffrey Walton

unread,
Apr 15, 2015, 6:00:01 PM4/15/15
to cryptop...@googlegroups.com

I would like to be able to use openSSL with data encrypted by crypto++ using ECIES with,
OpenSSL does not offer ECIES.
 
the ECDH key exchange and ECDSA seams compatible, but openSSL does not have any functions for EC based encryption.
OpenSSL does offer EC in 1.0.0 and above. Its missing from 0.9.8 and below.
 
since ECIES is something on the lines of a ECDH + some simple crypto operations I think its doable to implement it by hand using standard openSSL functions.
Yes, its doable. But I don't think its trivial.
 
however it seams quite complicated is there some ware some simple description how ECIES as used by Crypto++ works?
For a simple description, see wikipedia's https://en.wikipedia.org/wiki/Integrated_Encryption_Scheme.

There are at least 4 different standards that have a specification for ECIES: ANSI X9.63, IEEE 1363a, ISO/IEC 18033-2, and SECG SEC-1. And I'm not sure which Crypto++ actually uses. I think its closer to Shoup's version proposed in his 2.1 paper. But the source code refers to P1363, and I don't have access to that.

We have some reading on ECIES at http://www.cryptopp.com/wiki/Elliptic_Curve_Integrated_Encryption_Scheme.

Jeff

Jeffrey Walton

unread,
Apr 15, 2015, 6:10:21 PM4/15/15
to cryptop...@googlegroups.com


On Wednesday, April 15, 2015 at 4:23:08 PM UTC-4, David Xanatos wrote:
ok that was indeed simple enough assuming its all right for all cases:

You might consider testing the output of the program with Crypto++ or Bouncy Castle.

Crypto++ or Bouncy Castle provide free and open source implementations of ECIES. But Crypto++ and Bouncy Castle produce different results (use ECIES_BC in Crypto++ for Bouncy Castle interop; thanks to Jessie Wilson and Daniele Perito).

You can also test with Certicom's SecurityBuilder or RSA Data Security's BSFAE. Both provide ECIES, but they are non-free.

David Xanatos

unread,
Apr 16, 2015, 1:56:47 AM4/16/15
to cryptop...@googlegroups.com
Yes I will run some more tests against crypto++, on a short test the code worked,
what I did was basically I encrypted data with with crypto++, and then looked in the debugger step by step hat it does for decryption and implemented it with openssl functions step by step.

The whole goal of switching to openssl is not to have to provide a separate crypto library for linux builds, using a proprietary non free implementation would be here the worst possible option. than I would just stick to crypto++ as it already does all in needed.

Jeffrey Walton

unread,
Apr 16, 2015, 8:55:45 AM4/16/15
to cryptop...@googlegroups.com

The whole goal of switching to openssl is not to have to provide a separate crypto library for linux builds, using a proprietary non free implementation would be here the worst possible option. than I would just stick to crypto++ as it already does all in needed.
Yeah, I agree. I feel like a lot of folks would benefit from ECIES if OpenSSL provided it. As a side benefit, people will want to avoid it in OpenSSL, so it will increase its usage in Crypto++, too :)

Related: http://security.stackexchange.com/q/86028/29925. Have you given any thought to how you would add it to OpenSSL's EVP interface?

I've been thinking about talking to OpenSSL folks about it, like Matt Caswell, Richard Levitte and Emilia.

Jeff

Jeffrey Walton

unread,
Apr 18, 2015, 5:08:51 PM4/18/15
to cryptop...@googlegroups.com

Related: http://security.stackexchange.com/q/86028/29925. Have you given any thought to how you would add it to OpenSSL's EVP interface?

I've been thinking about talking to OpenSSL folks about it, like Matt Caswell, Richard Levitte and Emilia.

I reached out to some of the OpenSSL devs about this. I could not include you because Google would share your email address.

If you are interested in pursuing this with OpenSSL, then send me an email. Noloader, gmail account.

Jeff

Luca Di Mauro

unread,
Jul 12, 2019, 3:27:35 AM7/12/19
to Crypto++ Users
Hello eveyone,
did you solve this problem? I'm facing this problem too and I'm looking for a quick solution.

Luca

Jeffrey Walton

unread,
Jul 12, 2019, 4:11:44 AM7/12/19
to Crypto++ Users


On Friday, July 12, 2019 at 3:27:35 AM UTC-4, Luca Di Mauro wrote:
Hello eveyone,
did you solve this problem? I'm facing this problem too and I'm looking for a quick solution.

When I talked to the OpenSSL devs about this they declined. They felt it was not part of their mission, which they feel is limited to TLS.

Crypto++ aligned with Botan and Bouncy Castle after the release of Crypto++ 5.6.5. That is, the Crypto++ implementation was changed for the release of Crypto++ 6.0.

Jeff

Luca Di Mauro

unread,
Jul 12, 2019, 4:20:28 AM7/12/19
to Crypto++ Users
So the current version of ECIES doesn't implement that version of scheme (IEEE 1363a). Is it correct?

Jeffrey Walton

unread,
Jul 12, 2019, 4:40:04 AM7/12/19
to Luca Di Mauro, Crypto++ Users
On Fri, Jul 12, 2019 at 4:20 AM Luca Di Mauro <luca.d...@cnit.it> wrote:
>
> So the current version of ECIES doesn't implement that version of scheme (IEEE 1363a). Is it correct?

By default, NO. But ECIES is parameterized, and the P1363 version is available.

The default ECIES version uses parameters that interop with Botan and
Bouncy Castle. The parameter selection actually comes from Shoup, who
advised IEEE to use them (but IEEE did not do).

If you select different parameters you will have the P1363 version. In
fact, we recently added code to test the old P1363 version. The P1363
version of ECIES is exercised in validat8.cpp around line 200
(https://github.com/weidai11/cryptopp/blob/master/validat8.cpp#L202):

FileSource fc(DataDir("TestData/ecies_p160.dat").c_str(), true, new HexDecoder);
ECIES<ECP,SHA1,NoCofactorMultiplication,false,true>::Decryptor privC(fc);
ECIES<ECP,SHA1,NoCofactorMultiplication,false,true>::Encryptor pubC(privC);

Also see the docs on ECIES at
https://www.cryptopp.com/docs/ref/struct_e_c_i_e_s.html , and the
ECIES wiki page at
https://www.cryptopp.com/wiki/Elliptic_Curve_Integrated_Encryption_Scheme
.

The wiki page is kind of crappy and needs a rewrite. But it has
important details that are easy to find once you know where to look.

Jeff

Luca Di Mauro

unread,
Jul 12, 2019, 5:00:21 AM7/12/19
to Crypto++ Users
Ok, thank you very much for the information!

Il giorno venerdì 12 luglio 2019 10:40:04 UTC+2, Jeffrey Walton ha scritto:
Reply all
Reply to author
Forward
0 new messages