Rationale for mac storage algorithm

[FreekPaans]

Hi,

I'm reading https://github.com/ethereum/wiki/wiki/Web3-Secret-Storage-Definition and am wondering about the (security) design decisions for the mac storage, specifically:

• Why is the ciphertext concatenated to the decrypted key, instead of just using the decryption key?
• Why is the 2nd 16 leftmost bytes used from the decryption key as input to the hash, instead of the full key?

Perhaps this is common knowledge and therefore ignorance on my part, but I guess it would be nice if it's documented somewhere too.

Regards,

-Freek

[FreekPaans]

So, I've done some more research on this, and now think these are (parts of) the answers:

The generated DK represents not one, but two keys: the first 16 bytes being for encrypting/decrypting the private key corresponding to the account, and the second 16 for generating a key for validating the password.

Validating the password is by constructing a MAC by SHA3'ing over the concatenation of those second 16 bytes and the ciphertext for the private key.

What I now wonder about is what the rationale is for choosing this MAC function. It feels like an HMAC which can be done this way because SHA3 isn't vulnerable for length extension attacks. But I guess an HMAC is usually done to verify the data, not the key. I guess you could also interpret the ciphertext as a salt in a password hashing scheme, but since the key in this case is already strong, I don't think that would be necessary (you could just SHA3 the second part of DK, or even the entire thing?).