3
$\begingroup$

I would like to know the security of using key size that is larger than the message digest (output) of a HMAC in one time pad encryption. One time pads for the message and the key of HMAC are different, scenario:

  • A single message will be sent from A to B on insecure medium but is not known WHEN, in advance.
  • Both A and B agreed previously on the one-time pads (which are randomly generated) for the key of the HMAC, and for the message encryption of the message.
  • The message M of size L(> 50 bytes, padded) is encrypted with one-time pad of L bytes.
  • The key for the HMAC of message digest of size D bytes is a one-time pad and larger than D bytes.
  • HMAC uses encrypt-then-mac, so the MAC is HMAC(K, C), where K is the key and C is the ciphertext. Needless to say that one-time pads for the message and the key of HMAC are only used once for this message only.

Because the key size is larger than the output of the hash, can I say that a possible attacker will find the wrong key even if he tries to brute force it? So even if he finds a key, there is a high chance (as the input space "key" is larger than the output space "digest") that he finds it wrong and will be noticed by the recipient when he tries to send a crafted packet.

Is there somewhere that I miss? The one issue that I see here is my doubt of the hash function not mapping inputs to outputs "perfectly" (like the input size of CN not mapping to the output size of N, where each output is mapped to C inputs exactly).

$\endgroup$
1
  • 2
    $\begingroup$ When a MAC key is used only once as in the question, a common option is to use a universal hash like Carter-Wegman. It's "perfect" in the information-theoretic and the question's sense, and less costly than HMAC. $\endgroup$
    – fgrieu
    Feb 28, 2023 at 12:54

1 Answer 1

0
$\begingroup$

Addressing problems with OTP for HMAC:-

Your construction does not have two factor authentication and that’s poor form with OTPs. All OTP material has to be stored (what you have). If it’s also used for authentication, it’s stored too (what you have). There is no opportunity for authentication via what you know. Thus if I somehow access your key store, I can become you.

I suggest these problems swamp the issue of ”key size is larger than the output of the hash.” Mitigation can be had by exploring your faith in NSA, NIST, Quora, this and other forums and academic papers. Some say that contemporary hash functions used for HMACs are secure. If you believe so, a key correctly derived from a password would create exactly the same security level as current protocols like AES + HMAC. And that would provide two factor authentication. If not, it would be interesting to see reasoned arguments dissuading simple use of any CRC/hash function masked by OTP material.

$\endgroup$
2
  • $\begingroup$ I didn't get the first part exactly where "By using OTP material for the HMAC key, you create a denial of service (DoS) vulnerability in that an attacker can swamp your input with fake packets that all have to be authenticated draining your key store". Can you elaborate that part a bit further? $\endgroup$ Mar 2, 2023 at 8:45
  • 2
    $\begingroup$ @CuriousCrypto Rethinking, that's a good question. I'm going to put it to the community... $\endgroup$
    – Paul Uszak
    Mar 2, 2023 at 13:14

Your Answer

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

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