Re: [CFRG] Reference for weakness in MAC=hash(key|msg) construct

[Dan Harkins <[e-mail]>]

   Hi Bob,

   I see you have gotten quite a few suggestions on how to do it right
but your question as I read it is more of "how can I show this is wrong?"

   You should ask the designers what security properties they think they 
have
in their protocol and how that is going to be proven. You don't say what
"hash" is in the Drone Command and Control protocol but if it's, say, the
SHA2-family then you can point to Bellare and Rogaway's paper "Random 
Oracles
are Practical" [1] where it says,

     "When instantiating a random oracle by a concrete function h, care 
must be
      taken first to ensure that h is adequately conservative in its 
design so
      as not to succumb to cryptanalytic attack, and second to ensure 
that h
      exposes no relevant 'structure' attributable to its being defined 
from
      some lower-level primitive. Examples of both types of pitfalls are 
given
      in Section 6. As explained in that section, standard hash 
functions like
      MD5 and SHA don't by themselves make good replacements for a 
random oracles;
      but one doesn't have to look much further. Candidate instantiations
      include hash functions with their outputs truncated; hash 
functions with
      their input lengths restricted; and hash functions used in some 
nonstandard
      way, such as h(x) = MD5(x | x). See Section 6."

And I believe HMAC's construction is a suitable instantiation using a hash
algorithm to produce a primitive with the desired properties. They're not
doing HMAC though, so if they're using one of the SHA2-family of hash 
algorithms
I think Bellare and Rogaway's paper is the reference you're looking for.

   regards,

   Dan.

[1] https://dl.acm.org/doi/pdf/10.1145/168588.168596

On 5/13/22 7:24 AM, Robert Moskowitz wrote:
>
> I need to show that a MAC based on hash(key|msg) is bad and this has 
> been known since the mid-90s.
>
> This is for the Drone Command and Control (C2) open protocol MAVlink's 
> 6 byte authentication:
>
> https://mavlink.io/en/guide/message_signing.html
>
> I am familiar with "Keying hash functions for message authentication 
> (1996)" by Mihir Bellare , Ran Canetti , Hugo Krawczyk, but it does 
> not clearly show the weakness of hash (key|msg). 
> (https://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.134.8430)
>
> I attended Hugo's presentations of HMAC and SIGMA at the ISOC Security 
> Conference in '96 and have been using them since.  But now I 
> encounter, and have to deal with what I believe is a flawed design.  I 
> need to show references that this was known flawed for 20 years prior 
> to MAVlink 2.0 (that added the auth).
>
> Well, anyway, what I learned 25 years ago set my mind that 
> MAC=hash(key|msg) construct is flawed.  Details tend to get hazy over 
> time.
>
> Note that MAVlink may be transported over UDP on port 14550.  By using 
> RFC8750 (and a 12-byte ICV for GCM) and draft-mglt-ipsecme-diet-esp I 
> can have ESP/AES-GCM-12/UDP in 16 bytes.  Compress the MAVlink Seq, 
> Checksum, and Sig out, replacing them with this design in the same 
> length (and include the 8 byte UDP cost).
>
> So anyway, the basic need is a reference on the weakness of 
> MAC=hash(key|msg) construct
>
> thanks.
>
>
> _______________________________________________
> CFRG mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/cfrg

-- 
"The object of life is not to be on the side of the majority, but to
escape finding oneself in the ranks of the insane." -- Marcus Aurelius