Cryptography Asked by mint branch conditioner on February 23, 2021
I have two devices that use a PSK. One is embedded and extremely resource confined. I’m already using ChaCha20-Poly1305 so it would be "free" to reuse this. There is no transport encryption layer, all clear and has middlemen.
I want to establish a randomvalue/salt/kdf-base and send this to the other device on authentication so that I’m never actually using my PSK directly. Both sides know the PSK, and use this modifier to alter their stored key, and use a common derivative for packets going forward.
My plan was to use some KDF to modify my key into a temporary session key.
Is it satisfactory to use my existing AEAD like this:
nonce: the generated salt
payload: empty
additional data: empty (OR a flag of key type I want, NIST 800-108)
key: my 16Byte PSK
tag: The 16Bytes I will use as this session's temporary key
What I FEEL like this is doing is giving me a tag that will be crypto secure to prevent leakage of my real PSK, and the salt will be OK to use here as well as send over the wire so the other side can do the same thing and evaluate the auth packets going forward.
Is this at all legitimate?
I found my answer in another post by using different keywords. It's not necessarily ChaCha20 that is the important factor, but rather the MAC/TAG that is produced as a result. Can that be used as my KDF / key generator?
The answer is Yes in this case, but also maybe not in other cases: Can any MAC be used as a KDF?
It should be ok if MAC/TAG output is a PRF output compared to the inputs, but MACs don't have to be by definition. In the case of ChaCha20-Poly1305 it is. The output is random compared to any and all changes on either the Nonce, Key, Payload, or Additional Data.
The HMAC KDF we tried had the relevant inputs Key, Salt, Additional Data. Where AD was supposed to be used to help generate multiple subset keys.
From my research it does seem like ChaCha20-Poly1305 used as
Nonce=Salt
Key=PSK
Payload=null
AD=optional_derivative_data
Tag=new_key
should be crypto secure. Although this is not the best use of this function. What this lacks over a real KDF (like RFC-5869) is the options of specifying key sizes. In my case I'll have a 16Byte mac / new key and no options past that. This works well for my application that is already using 16B PSK.
I should note the reason I'm going through all this work is that I just don't have the Flash memory on this constrained device to support ChaCha20-Poly1305 which we need, and SHA256-HMAC_HKDF which we would like to have. Same for BLAKE2 and other options we would have liked. Both are about 4K of ROM compiled without optimization. It will be a slight abuse of typical application and this will need to be well documented for us, but it's either this or nothing.
Answered by mint branch conditioner on February 23, 2021
Since you have ChaCha20 as the cipher, it shouldn't occupy too much resource to add a BLAKE2 hash function next to it.
The BLAKE2 hash function comes in 2 variants: BLAKE2b, and BLAKE2s. ChaCha20 uses 32-bit words, which is more compatible with BLAKE2s. The only major difference between the hash and the cipher are the shift/rotate amounts, and the HAIFA hash compression function mode of operation.
While @SAI_Peregrinus have a good suggestion, I find it a little bit radical, so if you prefer a conservative approach, you can implement an additional BLAKE2 hash function to be used in any hash-based KDF you prefer.
As for your original ideal, I wouldn't recommend it as the authenticator is based on universal hashing in a biased modular integer arithmetic.
Answered by DannyNiu on February 23, 2021
Get help from others!
Recent Answers
Recent Questions
© 2024 TransWikia.com. All rights reserved. Sites we Love: PCI Database, UKBizDB, Menu Kuliner, Sharing RPP