-
-
Notifications
You must be signed in to change notification settings - Fork 25
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Using proper KDF #82
Comments
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 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. |
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: |
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. I guess we should do the same: HKDF function fed with shared secret and public key X and Y coordinates, that's all. |
Looks like this HKDF:
|
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' |
@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' |
Yeah, that's ok I guess. Can you give me your test vectors later? |
I'll update when ready |
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.
The text was updated successfully, but these errors were encountered: