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 >
- [CFRG] Reference for weakness in MAC=hash(key|msg… Robert Moskowitz
- Re: [CFRG] Reference for weakness in MAC=hash(key… Nimrod Aviram
- Re: [CFRG] Reference for weakness in MAC=hash(key… John Mattsson
- Re: [CFRG] Reference for weakness in MAC=hash(key… Richard Barnes
- Re: [CFRG] Reference for weakness in MAC=hash(key… Blumenthal, Uri - 0553 - MITLL
- Re: [CFRG] Reference for weakness in MAC=hash(key… Dan Harkins
- Re: [CFRG] Reference for weakness in MAC=hash(key… Robert Moskowitz
- Re: [CFRG] Reference for weakness in MAC=hash(key… Samuel Neves
- Re: [CFRG] Reference for weakness in MAC=hash(key… Yann Droneaud