Given a random 256bit key used for data encryption with Streaming AES GCM

I would like to wrap it for backup with AES GCM.

Is it safe to use

    km = new random 256bit key
    salt = Argon2(weak password) 256bit
    algo = HMACSHA512
    outputkey = 256bit )

in theory the km parameter has to be stored safely offline in hex format, similarly on how bip39 does with mnenonic words. And the produced 256bit are used to wrap the first DEK with aes gcm

Is there a better way to hash a random 256bit with a user password to generate a new high entropy 256bit for aes?

Protocol clarification:

Master key 256bit generated within Android TEE -> 
wraps with GCM { Master Google Tink Key }

Master Google Tink Key -> 
wraps with GCM{ DEK1, DEK2 ... } 

Each DEK is generated randomly and it is used to encrypt 2 files with AES GCM Streaming AEAD HKDF 4K wich I suppose internally generates new keys and IV to encrypt each block

and then

km = new random 256bit key + Argon2(weak password) 256bit
salt = empty
info = empty
algo = HMACSHA512
outputkey = 256bit)

outputkey -> wraps with GCM { Master Google Tink Key }
  • 1
    $\begingroup$ The full HKDF uses any amount of input keying material. To me it would make more sense to concatenate the key and password hash retrieved from Argon2 instead of using it as a salt, which is not considered to contain key material. That way the function is used as you'd expect it to, and implementations may actually handle keying material and salts differently. Not sure what you are going to do with the next DEK keys, and there is nothing about IV handling and such for GCM. I don't think the protocol is fully described. $\endgroup$
    – Maarten Bodewes
    Nov 9, 2022 at 17:31
  • 1
    $\begingroup$ I don't understand the description, but I'd agree with Maarten, or you could use the Argon2 output as the key and the random key as the salt/info parameter. That way around seems more common. $\endgroup$ Nov 9, 2022 at 19:06
  • 1
    $\begingroup$ @MaartenBodewes I've updated the question. I have no control over the IV and i cannot really create an encryption scheme since the Tink library does everithing internally. $\endgroup$
    – zjmo
    Nov 10, 2022 at 6:11
  • 1
    $\begingroup$ @samuel-lucas6 i was thinking that using the high entropy key in the salt has less influence on the overall entropy of the generated hash. Do you know otherwise if there is another way to bound a random key to a password as bip39 does but withouth word indexing? $\endgroup$
    – zjmo
    Nov 10, 2022 at 6:16
  • 1
    $\begingroup$ The salt for HKDF is used as the HMAC key internally, so a secret salt is very good. It's discussed in the RFC. I'd say stick with BIP39. $\endgroup$ Nov 10, 2022 at 18:20


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.

Browse other questions tagged or ask your own question.