How does the ECIES-AES encryption work with a key size that is not supported by AES?

Question

I am currently studying and implementing ECC algorithms but I encountered a problem. I want to use Secp521r1 for generating a shared key and encrypting with ECIES using AES256 but AES-256 requires a 256-bit key while the shared key is 521-bits. How can I use a 521-bit shared key for encrypting with ECIES AES-256?

Should it be hashed? If so, if I want to professionally use AES128, I could use md5 to hash the shared-key but isn't md5 considered unsafe for use?

Doesn't this many operations affect the speed of ECIES?

Another question I have is that the document: SEC, ver 1.9, on page 34 on MAC generations says:

1. Convert M to a bit string M and K to a bit string K using the conversion routine specified in Section 2.3.2.

I do not understand why I should convert the shared key to a bit string while HMAC_SHA512 gets key input as a byte array. The document also suggests the same thing for encryption specified in Section 3.8.3.

Answer 1

the shared key is 521-bits

The shared secret is an elliptic curve point, and so the entropy is not evenly distributed. Therefore, you need to use HKDF on the shared secret anyway. You can use HKDF based on SHA256 to generate your 256-bit key, and truncate the result if necessary to get a 128-bit key.

Doesn't this many operations affect the speed of ECIES?

The overhead of hashing is tiny compared to the EC scalar multiplication required to generate the shared secret.

Convert M to a bit string M and K to a bit string K

The only reason they're talking about bit strings is in order to ensure that they are 100% clear about how the octet string should be truncated to a shorter octet string when necessary.

Answer 2

Assuming you mean SEC1, I never saw a version 1.9 but in version 2.0:

• 3.7 on pp33-35 is the MAC portion (i.e. a sub-scheme)

• 3.8 on pp35-38 is the symmetric encryption portion (ditto)

• the actual complete ECIES scheme is 5.1 on pp50-54. It has a 'setup' phase in 5.1.1 that selects several things including the MAC and symmetric encryption subschemes plus a KDF and ECDH primitive and parameter-set (which we usually just call the curve, though that isn't exact). 5.1.3 then specifies that U (the encrypter) does the following, where I have emphasized the relevant bits:

1. (generate the ephemeral sender keypair)

2. (represent the ephemeral public key)

3. (apply the ECDH primitive to sender ephemeral plus receiver static giving "a shared secret field element $z \space \epsilon F_q$ -- that's your 521-bit value for P-521)

4. Convert $z$ ... to an octet string $Z$ ... (now it's 66 octets)

5. Use the key derivation function KDF [from setup] to generate keying data $K$ of length $enckeylen + mackeylen$ octets from $Z$ ....

6. Parse the leftmost $enckeylen$ octets of $K$ as an encryption key $EK$ and the rightmost $mackeylen$ octets of $K$ as a MAC key $MK$ ....

7. (use EK as the encryption key)

8. (use MK as the MAC key)

5.1.4 then has the decrypter do essentially the same things except with the opposite side of the ECDH primitive, and of course verifying the MAC before decrypting (required to avoid the doom principle).

Thus the symmetric encryption key and MAC key are the correct sizes for their selected sub-schemes, regardless of the size of the curve field used for the ECDH primitive. (But they will not have entropy and thus strength greater than that allowed by the 'curve' i.e. parameter-set and keypair generations.)