7

A quick question, we know that raw RSA is a no go. To solve this we have different PKCS standards forcing structure on the input messages.

For EC the story is something else. For signatures we have ECDSA, for general encryption we have ECIES (hybrid) and ElGamal encryption. Or ECDH for key agreement

None of those schemes define any formatting, does that mean that there a no know attacks against the raw schemes? Just compute the output and incorporate the raw binary into our network protocol?

Anonymous
  • 431
  • 3
  • 10
  • ECIES should be IND-CCA2, ElGamal should be IND-CPA and falls due to standard CCA attacks, plain ECDH suffers from missing authentication, but has no other known weaknesses, ECDSA should be safe. – SEJPM Jun 02 '15 at 18:25
  • There are no other EC schemes which i'm missing here? RSA can safely encrypt up to 245 bytes if I remember correctly (exchanging session keys using some defined format for example). EC has no such means of exchanging session keys. If you want that you should use it in a key agreement scheme. – Anonymous Jun 02 '15 at 18:37
  • I think you're referring to RSA public key encryption, ECIES can do the same but isn't standardized for TLS because ECDH is superior. – SEJPM Jun 02 '15 at 18:39
  • Indeed. I'm referring to RSA public key encryption. – Anonymous Jun 02 '15 at 18:45
  • 1
    ECIES corresponds to RSA-KEM, with both you hash the shared secret using a KDF. Typical ECC signatures are similar to RSA-FDH, since in both cases you use a hash as big as the modulus as a number. – CodesInChaos Jun 02 '15 at 18:53
  • So there is no equivalent to RSA public key encryption in the ECC world (I'm pretty sure that I'm not overlooking any schemes in my literature.. But having verification would be nice)? ECIES is hybrid, ECDH is a key agreement. ElGamal is a scheme that uses any DH construction. – Anonymous Jun 02 '15 at 20:11
  • 1
    @SOJPM : $:$ "raw/textbook" ECDH produces a group element that is hopefully indistinguishable from random, rather than a bit-string that is hopefully indistinguishable from random. $;;;;$ –  Jun 03 '15 at 10:58

1 Answers1

4

None of those schemes define any formatting

You don't needs any input formatting for ECDSA, you just feed your plaintext into the hash function.
You only need a formatting if you want to exchange public keys and / or private keys (I'll count "with yourself" in the future as exchange here).
As far as ECIES goes, the situation is a bit more complicated. There are standards defining formats for ECIES (so you can decide how the payload was encrypted for example), but they haven't seen wide adoption (may be due to the pay walls) yet. Refer to this paper for a comparison of the standards.
EC-ElGamal isn't widely used and it's already hard to find good standards to achieve IND-CCA2 security with (EC-)ElGamal. I'd strongly recommend against using (EC-)ElGamal unless you need the homomorphic property.

Does that mean that there a no know attacks against the raw schemes?

These schemes are different from RSA in that they are fairly "recent" and people already learned how to describe schemes when defining them, whereas the issue with RSA is that it's "just a modular exponentiation with the right exponents", these schemes are comparable in detail of specification to PKCS#1 (i.e. RSA-OAEP and RSA-PSS).

As for the security:

  • ECIES is a secure public key encryption scheme (IND-CCA2) assuming the hash can be modeled as a random oracle(RM) and the elliptic curve computational diffie-hellman(ECCDH) problem holds
  • ECDSA is a secure signature scheme (existentially unforgeable under chosen message attacks (EUF-CMA)) assuming the EC discrete logarithm problem (ECDLP) holds
  • ECDH is a secure key agreement scheme (provided that you authenticate the exchange and that you hash the derived point) assuming ECDDH (EC decisional DH) (or ECCDH + RM-Hash) holds.
  • EC-ElGamal is a somewhat secure public key encryption scheme (IND-CPA and maybe IND-CCA1, but not IND-CCA2) assuming that ECDDH holds

See our canonical "IND-" question for the basic notions.

SEJPM
  • 45,967
  • 7
  • 99
  • 205