3
$\begingroup$

I'm playing around with a package that does Elliptic Curve Cryptography from http://jecc.sourceforge.net/

Every time I encrypt a value it produced a different result (same private key). However I'm always able to decrypt this result with the related public key. For a 1 byte result the resulting data is 34 bytes, 2 bytes the resulting data is 35 bytes. I assume some knowledge of the curve is contained in the result.

Is this a feature of ECC or would you assume it is just this implementation?

Improve this question
$\endgroup$

2 Answers 2

Reset to default
7
$\begingroup$

It has to be this way.

First, if it was deterministic, you could trivially break the encryption. Say the encrypted message was a response to "which candidate for President do you vote for". An attacker would simply need to encrypt each candidate's name and see the response that matched the encrypted data.

Second, if it was the same length as the encrypted data, you'd have at least two problems. First, short messages could be trivially brute forced. For example, if the output were only two bytes (for any input) you could encrypt messages until you got a match. Second, there's an obvious pigeonhole problem for messages of any length. You can't encrypt all possible X byte messages into an X byte output unless the relationship is one-to-one, which requires it to be deterministic which fails for the reasons I explained above.

I'm not specifically familiar with jecc, but the usual way to use ECC for encryption (IES) involves two random steps. First, the data to be encrypted is encrypted with a random symmetric key. Second, a random public/private ECC key pair is used in the encryption of the symmetric key. This explains both the indeterminism and the length.

Improve this answer
$\endgroup$
5
  • 1
    $\begingroup$ This is all rubbish. RSA does not involve any randomness but is not "trivially breakable". Secondly,the ciphertext in RSA can be the same length as the plain text. Thirdly ECIES results in longer ciphertexts without any symmetric usage. For shame whoever marked this as +1! $\endgroup$
    – Barack Obama
    Commented Sep 3, 2013 at 1:14
  • 1
    $\begingroup$ I misspoke about ECIES. But jecc (which looks quite poor) sends one side of a ECDH key agreement and then appends the plaintext xor'ed with the hash of the shared key. This is a ElGamal encryption. See jecc.cvs.sourceforge.net/viewvc/jecc/jecc/elliptic/… It looks like it'll fall over if you encrypt more bytes than the length of their hash function outputs. $\endgroup$
    – Barack Obama
    Commented Sep 3, 2013 at 1:37
  • 3
    $\begingroup$ RSA does not involve any randomness, but it is trivially breakable (if used in the context involved here). Say I send you a message in plaintext, "Should we attack? Respond 'yes' or 'no' encrypting with RSA." This is trivially breakable, you can just trial encrypt both the 'yes' and the 'no'. This is one of the reasons RSA is not used alone. A public key algorithm that operates on short plaintext (which is what we're talking about here) must involve some randomness or it's trivially breakable by trial encryption. $\endgroup$
    – David Schwartz
    Commented Sep 3, 2013 at 2:38
  • $\begingroup$ Yes jecc does fall over (NPE) if you send more than 20 bytes. $\endgroup$
    – DavidG
    Commented Sep 8, 2013 at 16:58
  • $\begingroup$ This answer is essentially correct. One minor nitpick: ECIES is a combination of a KEM (that creates the ciphertext and the random key at the same time, instead of encrypting a random key) based on Diffie-Hellman and a one-time symmetric cryptosystem. $\endgroup$
    – K.G.
    Commented Oct 5, 2013 at 13:57
1
$\begingroup$

Depending on the specific method of encryption used, it may encrypting the data with a random key, using a symmetric algorithm, then encrypting that key with the private key.

It may also be using some kind of random padding to extend the 1 byte value to a larger size prior to encrypting it.

A quick look at their code revealed no classes for known block ciphers, but did make several references to cryptostreams...

Improve this answer
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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