Using proper KDF

[savely-krasovsky]

Currently KDF is just SHA256, but there are a bunch of standards which defines what KDF should be. There is an old one ANSI-X9.63: http://www.secg.org/sec1-v2.pdf (clause 3.6.1).

But there is also newer ISO 18033-2 document that defines new KDF: https://www.shoup.net/iso/std6.pdf (clause 6.2). (Drafts contain discussion why not just Hash (https://www.shoup.net/papers/iso-2_1.pdf))

And pay an attention: Both documents define generic KDF for every algorithm described in the documents.

I guess we should replace current KDF with ISO 18033-2 variant.

[savely-krasovsky]

Drafts contain discussion why not just Hash (https://www.shoup.net/papers/iso-2_1.pdf)

TL;DR Victor Shoup proved that if public key (not only X part, but also Y) is not included into KDF parameters then ECIES is affected to adaptive chosen ciphertext attacks.

C++ Example: https://github.com/randombit/botan/blob/master/src/lib/pubkey/ecies/ecies.cpp#L142

[kigawas]

[savely-krasovsky]

@kigawas AFAIK OS2IP and I2OSP are just "octet string to integer procedure" and "integer to octet string procedure". I guess integer mean "big number" in our case.

There is more important clause with ECIES-KEM description:

[savely-krasovsky]

As far as I get it, KDF1 is just HKDF which is already ported to many languages and has own RFC.

For example Google use it as KDF it their own ECIES implementation based at ISO 18033-2:
https://github.com/google/tink

[savely-krasovsky]

And yes, Google Tink library feeds HKDF with shared ECDH secret and (!) UNCOMPRESSED public key. They use HKDF without salt which is ok in this case.
https://github.com/google/tink/blob/master/go/subtle/hybrid/ecies_hkdf_sender_kem.go#L29

I guess we should do the same: HKDF function fed with shared secret and public key X and Y coordinates, that's all.

[kigawas]

Looks like this HKDF:
https://pycryptodome.readthedocs.io/en/latest/src/protocol/kdf.html#Crypto.Protocol.KDF.HKDF

Crypto.Protocol.KDF.HKDF(master, key_len, salt, hashmod, num_keys=1, context=None)

[kigawas]

k1: bytes = sender_secret
k1_pub: bytes = sender_public  # uncompressed format
k2_pub: bytes = receiver_public  # uncompressed format
shared: bytes = k1.multiply(k2_pub)
master  =  shared + k1_pub
key_len = 32 # for aes-256-gcm
salt = b'0'*64 # random 64-byte bytes array for sha512
hashmod = 'sha512'

[savely-krasovsky]

@kigawas sha512 is overkill, imo. And it's even less safer in few cases like time attack. sha256 is more than enough. Salt is also unnecessary, otherwise we will get different keys every time and decrypt-encrypt process will be fully broken.

[kigawas]

Ok, then

k1: bytes = sender_secret
k1_pub: bytes = sender_public  # uncompressed format
k2_pub: bytes = receiver_public  # uncompressed format
shared: bytes = k1.multiply(k2_pub)
master  =  shared + k1_pub
key_len = 32 # for aes-256-gcm
salt = b'0'*32 # 32-byte zero bytes array for sha256
hashmod = 'sha256'

[savely-krasovsky]

Yeah, that's ok I guess. Can you give me your test vectors later?

[kigawas]

I'll update when ready