2
$\begingroup$

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?

Improve this question
$\endgroup$
2
  • 2
    $\begingroup$ nvlpubs.nist.gov/nistpubs/Legacy/SP/… provides a way to turn a PRF in CTR mode into a KDF. ChaCha20 internally is a PRF in CTR mode. $\endgroup$
    – SAI Peregrinus
    Jan 16, 2021 at 0:14
  • $\begingroup$ @SAIPeregrinus Thanks, I'll look at that. I wonder though, I'm using a crypto backend that integrates chacha20-poly1305 into one set of functions I can use. So while CC20 may be PFR in CTR, all I'll have is the "tag" output. Which I can't think is worse, just no exactly what NIST is describing. Everything else, the key hierarchy, the PSK derivatives, and the idea of using these as a KDF all lines up. $\endgroup$
    – mint branch conditioner
    Jan 16, 2021 at 0:49

2 Answers 2

Reset to default
1
$\begingroup$

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.

Improve this answer
$\endgroup$
1
  • $\begingroup$ This was good advice I thought, but ultimately I didn't have the room to support BLAKE2 and @SAI_Peregruinus advice led me to something I had suspected about the output of ChaCha20 being pseudo-random enough that I think I have a viable option. $\endgroup$
    – mint branch conditioner
    Jan 19, 2021 at 18:45
0
$\begingroup$

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.

Improve this answer
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.