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

[Robert Moskowitz <[e-mail]>]

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]