Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl Monk, Perl Meditation
PerlMonks ecc_encrypt $message clear text is limited in length

by JalapenoBob (Initiate)
on Feb 08, 2018 at 00:02 UTC ( #1208664=perlquestion: print w/replies, xml ) Need Help??
JalapenoBob has asked for the wisdom of the Perl Monks concerning the following question:

Hello. Exploring I must be missing something really simple. Happen to be on Windows 10. Interested in ECDH in Perl5. Use case is to leverage an elliptical public private key method to sign then encrypt a string of text. At the moment, focusing on encrypting the string. The string of text to encrypt may be up to 5000 characters but could be much longer. Question: When using ecc_encrypt the clear text appears to be limited to 20 bytes (20 characters) (SHA1) or 32 characters (SHA256) for $message. Now, there is no surprise on known hash length output. BTW I will not be using SHA1… just trying to figure this problem out. But, the surprise is that a hash function is used at (i.e. SHA1 or SHA256) all in the implementation of ECC based encryption.

Note: You'll notice that I have not included the signing part… just the encryption part. How I am generating keys

use Crypt::PK::ECC; open (OUT_priv,">.\\keys\\priv_pem.txt"); open (OUT_pub,">.\\keys\\pub_pem.txt"); #Key generation my $pk = Crypt::PK::ECC->new(); $pk->generate_key('secp256k1'); my $private_pem = $pk->export_key_pem('private'); my $public_pem = $pk->export_key_pem('public'); print OUT_priv "priv_pem $private_pem\n"; print OUT_pub "pub_pem $public_pem\n";

How I am attempting to encrypt and then decrypt a string.

use Crypt::PK::ECC; use strict; my $pub_key_filename = ".\\keys\\pub_pem.txt"; my $priv_key_filename = ".\\keys\\priv_pem.txt"; my $message = "123456789 123456789 123456789 12"; print "Encrypting now...\n"; my $pk = Crypt::PK::ECC->new($pub_key_filename); my $ct = $pk->ecc_encrypt($message,'SHA256'); #Why do I have to specif +ify a hash function? print "ct... \n $ct\n"; ### In session decrypt my $ciphertext = $ct; my $pk = Crypt::PK::ECC->new($priv_key_filename); my $pt = $pk->ecc_decrypt($ciphertext); print "decrypted...\n $pt\n";

So, if I add one more character to $message then I get an error
FATAL: ecc_encrypt_key failed: Invalid hash specified. at C:/Perl64/site/lib/Crypt/PK/ line 574.

Within line 574 specifies (by default) SHA1. And, this is where I am confused because I am hoping to not use a hash function but elliptic curve cryptography.

Now if I keep the message size to say 32 characters then no problem at all. So, any ideas?

Replies are listed 'Best First'.
Re: ecc_encrypt $message clear text is limited in length
by roboticus (Chancellor) on Feb 08, 2018 at 03:07 UTC


    I've not used Crypt::PK::ECC before, but on reading the documentation, it looks like you don't need the second argument on encrypt since you provided the public key file in the constructor.

    Update: OK, I installed it and tried it out myself. I'm not having any luck yet. I'll update again if I can make something interesting happen.

    Update 2: After digging around in the tests and source code a little, I haven't been able to come up with anything that works. I get the same problem: I can encrypt/decrypt very short strings (up to 20 characters), but once I hit the twenty-first character, I get "Invalid hash specified".


    When your only tool is a hammer, all problems look like your thumb.

      @roboticus, thanks, any help is appreciated! ...JalapenoBob
Re: ecc_encrypt $message clear text is limited in length
by hippo (Canon) on Feb 09, 2018 at 09:36 UTC

    I've not yet attempted to diagnose what you've done fully but I believe I can answer one question you posed:

    my $ct = $pk->ecc_encrypt($message,'SHA256'); #Why do I have to specifify a hash function?

    The documentation for ecc_encrypt says "ECCDH Encryption is performed by producing a random key, hashing it, and XOR'ing the digest against the plaintext", so that is where the hash algorithm comes in. Note that the documentation also says that ecc_encrypt() is a function as opposed to a method but a perusal of the source suggests that it can be called either way. HTH.

      @hippo, thanks... that clears things up a lot. I had not seen that in the documentation and it makes perfect sense now.
Re: ecc_encrypt $message clear text is limited in length
by JalapenoBob (Initiate) on Feb 09, 2018 at 00:48 UTC
    Well I don't see many other folks commenting on this but recognize that this same challenge may be presented to other folks moving from RSA to ECC. My latest thought is that what I am experiencing is similar to maximum clear text length available for encryption in RSA being defined by key length. So, in RSA a 2048 bit length key will provide for a clear text length (string) of just under 256 bytes. So, my error, it appears, was in thinking that I could encrypt the entirety of a long string via ECC but in reality I need to leverage a symmetric (like AES) solution to encrypt the larger string and then ECC to encrypt the password.

    Obviously, elliptical curve cryptography is not my day job. :-) Feel free to provide clarity to the nonsense that I have described.

Re: ecc_encrypt $message clear text is limited in length
by JalapenoBob (Initiate) on Feb 08, 2018 at 20:35 UTC
    Just had a thought. I think I am using this module completely wrong? Maybe? Perhaps I am attempting to "sign" vs "encrypt" the $message.

    If that is the case then using the aforementioned code for signing seems to work fine, but that leaves me at a loss for using elliptical curve cryptography to encrypt with a ECC based public key.

    Thanks all!

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://1208664]
Approved by kcott
Front-paged by haukex
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others taking refuge in the Monastery: (4)
As of 2019-01-21 03:05 GMT
Find Nodes?
    Voting Booth?
    After Perl5, I'm mostly interested in:

    Results (351 votes). Check out past polls.

    • (Sep 10, 2018 at 22:53 UTC) Welcome new users!