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

[John Mattsson <[e-mail]>]

These are the pre-standardized versions, not compatible with SP 800-232, should not be enabled in libraries by default, and should not be used.

Cheers,
John Preuß Mattsson

Sent from Commodore VIC-20
________________________________
From: Robert Moskowitz <rgm-sec=[e-mail]>
Sent: Friday, 07 August 2026 14:50:00
To: Robert Moskowitz <[e-mail]>; John Mattsson <[e-mail]>; CFRG <[e-mail]>
Subject: Re: [CFRG] Re: Using ASCON particularly for a keyed MAC and PQC

I remembered something I saw and checked....

WolfSSL claims full support for ASCON:

https://www.wolfssl.com/wolfssl-embraces-ascon-lightweight-cryptography/

ascon128v12: Ascon-128
ascon128av12: Ascon-128a
ascon80pqv12: Ascon-80pq
asconhashv12: Ascon-Hash
asconhashav12: Ascon-Hasha
asconxofv12: Ascon-Xof
asconxofav12: Ascon-Xofa
asconmacv12: Ascon-Mac
asconprfv12: Ascon-Prf
asconprfsv12: Ascon-PrfShort

So at least one commercial implementation.  Thus I will keep it in the draft so at least it is debated.

On 8/7/26 7:49 AM, Robert Moskowitz wrote:
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]><mailto:rgm-sec=[e-mail]>
Date: Thursday, 6 August 2026 at 22:47
To: CFRG <[e-mail]><mailto:[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]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>



_______________________________________________
CFRG mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>





_______________________________________________
CFRG mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>





_______________________________________________
CFRG mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>