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

Robert Moskowitz <rgm-sec@htt-consult.com> Fri, 13 May 2022 16:15 UTC

Return-Path: <rgm-sec@htt-consult.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E707C159496 for <cfrg@ietfa.amsl.com>; Fri, 13 May 2022 09:15:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.755
X-Spam-Level:
X-Spam-Status: No, score=-2.755 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-1.857, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URI_DOTEDU=1] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bbtgr7XgWlBk for <cfrg@ietfa.amsl.com>; Fri, 13 May 2022 09:14:59 -0700 (PDT)
Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [23.123.122.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B695CC159485 for <cfrg@irtf.org>; Fri, 13 May 2022 09:14:59 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 098036250B; Fri, 13 May 2022 12:14:12 -0400 (EDT)
X-Virus-Scanned: amavisd-new at htt-consult.com
Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id LOznV7rErLJP; Fri, 13 May 2022 12:14:07 -0400 (EDT)
Received: from [192.168.160.11] (unknown [192.168.160.11]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 67B1E6247F; Fri, 13 May 2022 12:14:07 -0400 (EDT)
Message-ID: <324e5753-f774-e20f-32da-eab761ada029@htt-consult.com>
Date: Fri, 13 May 2022 12:14:52 -0400
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.0
Content-Language: en-US
To: Dan Harkins <dharkins@lounge.org>, cfrg@irtf.org
References: <5eec9c58-4bfd-7ada-2fdd-90d1180100e1@htt-consult.com> <17ec03ed-4420-cff4-729a-e18af595b20d@lounge.org>
From: Robert Moskowitz <rgm-sec@htt-consult.com>
In-Reply-To: <17ec03ed-4420-cff4-729a-e18af595b20d@lounge.org>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/07zuGA40P1w_ozlOPfn5aH-PJ9o>
Subject: Re: [CFRG] Reference for weakness in MAC=hash(key|msg) construct
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.34
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 May 2022 16:15:04 -0000

Thank you Dan.

Got a lot of information here.  Won't get it all into the draft I need 
to push out shortly, but enough...

On 5/13/22 12:05, Dan Harkins wrote:
>
>   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
>> CFRG@irtf.org
>> https://www.irtf.org/mailman/listinfo/cfrg
>