[CFRG] Re: Using ASCON particularly for a keyed MAC and PQC

[Robert Moskowitz <[e-mail]>]

Oops!

That is a 192-bit key in a 196-bit packet.

And 51+196=247

Which only allows for 224-bit keys.  Can that be justified at the cost 
of another PPM packet every 5s against a 196-bit PO payload on top of 
some existing PPM packet.

On 8/7/26 5:58 AM, Robert Moskowitz wrote:
> Thank you, John for responding:
>
> On 8/7/26 4:45 AM, John Mattsson wrote:
>> Hi Bob,
>>
>> Some questions:
>>
>> 1. *Do you need NIST-approved constructions?*
>>
>> If yes, I think HMAC-Ascon-Hash256 is your only choice, which is 
>> unfortunate. HMAC's only raison d'être is outdated fixed-length hash 
>> functions with severe weaknesses like SHA-2.
>
> 6.2 msg/sec (BURST-MODE with 7 allowed), each with a keyed-MAC on a 
> highly constrained processor, potentially purpose built CHEAP for the 
> transponders and simply built to get certified.  Though the cost of 
> certification is more driving the industry to COTS chips.  This is why 
> the transponder in an A320 or B-737 costs $250,000US.  For your Cessna 
> you can get away with only $50,000US (though I have heard of a 
> $5,000US product).  This is compared to open source receivers (and 
> transponders for baggage trucks) on a RPi.
>
> HMAC is 2 hashes.  KMAC is 1.  This matters.
>
>>
>> 2. *Do you need standardized constructions?*
>>
>> If yes, I think HMAC-Ascon-Hash256 is your only choice.
>>
>> If no, I think you can use any MAC, PRF, or KDF construction designed 
>> for (Turbo)SHAKE.
>
> As this is ADS-B which goes into aviation certification programs 
> around the world, some standard with standing will have to be 
> followed.  Based on other things in aviation, a function on SHAKE MAY 
> float.
>
>>
>> 3. *Do you need public-key cryptography such as ML-KEM, ML-DSA, 
>> SLH-DSA, FN-DSA, HQC-KEM, etc.?*
>>
>> If yes, you need SHAKE anyway. SHAKE already provides standardized 
>> modes for MACs, PRFs, and KDFs; the main missing piece is encryption.
>
> None of those stand a chance over the 1090ES channel.  Some other 
> channel would be need for the Signed Key Disclosure and cert 
> over-the-air distribution.  But that may be needed anyway because even 
> EdDSA hurts a lot over 1090.  This is covered in the draft.
>
> I am leaning heavily on some future Additional Algorithm like NOVA.
>
>>
>> 4. *Do you need 256-bit security as an option?*
>>
>> If yes, you cannot use Ascon.
>
> There is only room in the messages for a 196-bit key for the key 
> disclosure.  There is a way, using what I call "Enhanced mode", where 
> I create a new PPM message and add the 51 bits from the PPM message 
> with the 196 bits of the PO message where I COULD do a full 256-bit 
> key disclosure.  But that adds a new message every 5s to an already 
> over-crowded RF channel.  Adding a new message with that frequency 
> would need a lot of justification.  So I am designing for a 196-bit 
> PQC key size.
>
> This is covered in the draft and referenced papers.
>
> Yes, the messaging IS that constrained.  Both in packet size and 
> channel usage.
>
>>
>> ----
>>
>> />I also need to look toward PQC somehow. There is ASCON-pq80 in the 
>> proposal, but it is not in 232. /
>>
>> I would reserve the term PQC for asymmetric cryptography. 
>> Ascon-AEAD128 is quantum-resistant. Claims about practical quantum 
>> attacks against symmetric cryptography are a misconception.
>> https://datatracker.ietf.org/liaison/1942/
>>
>> That said, I would be hesitant to limit a new system to 128-bit keys. 
>> Many of my customers and several EU cybersecurity agencies are 
>> requiring/recommending 256-bit keys for new deployments (at least as 
>> on option), and even NIST and the UK NCSC are only stating that 
>> 128-bit security "can continue to be used". This is too uncertain a 
>> basis on which to design new systems expected to have a long lifetime.
>>
>> />With TESLA there are LOTS of keyed-MAC operations, and KMAC as a 
>> single/
>> />sponge operation has advantages of HMAC with 2 SHA operations.  An/
>> />ASCON-KMAC would be a good alternative, but NIST did not 
>> standardize one/
>> />(yet)./
>>
>> Yes, if you do not require a standardized construction, I think KMAC 
>> or any other MAC construction designed for (Turbo)SHAKE would work.
>> https://datatracker.ietf.org/doc/draft-ochkas-cose-ascon/
>> https://datatracker.ietf.org/doc/rfc9861/
>>
>> Otherwise, HMAC-Ascon-Hash256 and HKDF-Ascon-Hash256 appear to be the 
>> only options, but these are such Frankenstein constructions that I 
>> would prefer not to see them deployed.
>>
>> ----
>>
>> My current view is, unfortunately, that due to PQC and market demand 
>> for 256-bit, I see limited use for Ascon in our products. In deployed 
>> systems that already use AES, it is very difficult to justify a 
>> migration. In systems that use asymmetric cryptography, SHAKE is 
>> needed anyway. And for new systems, many customers and regulators 
>> expect 256-bit symmetric keys.
>>
>> Ascon is designed to minimize the hardware and code size of AEAD and 
>> hash functions, but the more important metric is the hardware and 
>> code size of the complete cryptographic suite, including asymmetric 
>> cryptography. Within just a few years, all systems will need to use 
>> quantum-resistant cryptography. Keccak appears to be the only 
>> realistic primitive that can serve as a common foundation for all 
>> major cryptographic functions. In that context, I believe NIST and/or 
>> CFRG should urgently specify encryption algorithms based on 
>> Keccak/(Turbo)SHAKE.
>>
>> Cheers,
>> John Preuß Mattsson
>>
>> *From: *Robert Moskowitz <rgm-sec=[e-mail]>
>> *Date: *Thursday, 6 August 2026 at 22:47
>> *To: *CFRG <[e-mail]>
>> *Subject: *[CFRG] Using ASCON particularly for a keyed MAC and PQC
>>
>> I come here for advise wrt my work to add authentication to ADS-B
>>
>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-moskowitz-ads-b-auth%2F&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C5bdf36d3b9e84f5a53db08def3fbfa87%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C639216460726710103%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=%2FYmQFBVj72BEEmlOVoROgRnPkbqH7CuNelcykpKR3YA%3D&reserved=0 
>> <https://datatracker.ietf.org/doc/draft-moskowitz-ads-b-auth/>
>>
>> ASCON (SP800-232) seems like it would be well suited for the constrained
>> systems used in avoinics and perhaps to better retro fit in old hardware.
>>
>> However:
>>
>> I need a KMAC operation and none is in 232.  One (or two?) were
>> proposed, but none included.
>>
>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Frweather.github.io%2Fascon-suite%2Findex.html&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C5bdf36d3b9e84f5a53db08def3fbfa87%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C639216460726747847%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=wzUdkif2aMIJBThtPKp0PlxiHtUang%2FUVAqPlXzBebs%3D&reserved=0 
>> <https://rweather.github.io/ascon-suite/index.html>
>>
>> Does provide a KMAC api, but in a recent exchange, Rhys indicated he
>> never updated this to the published standard.
>>
>> I also need to look toward PQC somehow.  There is ASCON-pq80 in the
>> proposal, but it is not in 232.  So again, I am looking at a "now what".
>>
>> With TESLA there are LOTS of keyed-MAC operations, and KMAC as a single
>> sponge operation has advantages of HMAC with 2 SHA operations.  An
>> ASCON-KMAC would be a good alternative, but NIST did not standardize one
>> (yet).
>>
>> So I invite advise!
>>
>> BTW, I am expanding on sec 3.3.3 in my draft.  I pulled what is their
>> from our whitepaper that did not go into the details needed for coding
>> TESLA.  I am fixing that now, and debating including or dropping ASCON.
>>
>> Thanks!
>>
>> Bob
>>
>>
>> _______________________________________________
>> CFRG mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]
>>
>> _______________________________________________
>> CFRG mailing list [e-mail]
>> To unsubscribe send an email [e-mail]
>
>
> _______________________________________________
> CFRG mailing list [e-mail]
> To unsubscribe send an email [e-mail]