Is AES+hash rather than HMAC problematic?

Question

I will now ask a strange question, but bear with me. I can't share the entire usecase, but the point is to allow the holder of a secret key to create "strings" (used in other systems). The strings should be: non-reversible (=> hash) and should nobody but the key holder should be able to create them based on a known plaintext.

I know this sounds like an (H)MAC, but the goal is not message authentication.

So, to achieve that result (a non-reversible string that only the key-owner can generate), is encrypt(AES)-then-hash a good option as an alternative to HMAC?

A clarification - since it should be reproducible, the AES encryption (in CBC mode) should use a constant, rather than random initialization vector. This is in general wrong, but since the result of the encryption will be immediately hashed, the drawback of constant IV might be mitigated.

HMAC is faster than AES+hash (on my machine around 5 times), but both are fast enough for that to not be relevant.

HSMs support both encryption and HMAC. AWS KMS does not support HMAC.

Are there other drawbacks or benefits of AES+hash over HMAC? Or is there another canonical way to achieve to same goal - "irreversible result that only the key-holder can generate"

Answer 1

I'm not allowed to comment yet but you don't specify if somebody is supposed to be able to check if a string was created by a specific user.

If that's unnecessary you should probably simply use authenticated encryption. If somebody should be able to check then I don't know how they would achieve that given your scheme. Even if they have the key, how will they know what was encrypted?

I don't think this can be reasonably answered without more details about your use-case. With the information you have given so far it just sounds like a pretty bad idea.