Draft SP 800-232: Ascon-Based Lightweight Cryptography Standards for Constrained Devices

[Sonmez Turan, Meltem (Fed)]

Dear LWC-forum members,

The initial public draft of Special Publication (SP) 800-232, Ascon-Based Lightweight Cryptography Standards for Constrained Devices: Authenticated Encryption, Hash, and Extendable Output Functions, is now available for public comment.

This draft standard introduces a new Ascon-based family of symmetric-key cryptographic primitives that provides robust security, efficiency, and flexibility. With its compact state and range of cryptographic functions, it is ideal for resource-constrained environments, such as Internet of Things (IoT) devices, embedded systems, and low-power sensors. This standard includes multiple algorithms to meet a wide range of symmetric cryptographic needs, including the Authenticated Encryption with Associated Data (AEAD) scheme Ascon-AEAD128, the hash function Ascon-Hash256, and the Extendable Output Functions (XOFs) Ascon-XOF128 and Ascon-CXOF128.

The public comment period is open through February 7, 2025. Send comments to SP800-232...@list.nist.gov.

Best,

NIST Lightweight Cryptography Team

[Rhys Weatherley]

Congratulations on this milestone!

A cursory reading of the draft shows the following changes:

* The suite of core algorithms has been reduced to four: ASCON-AEAD128,
ASCON-Hash256, Ascon-XOF128, and ASCON-CXOF128.
* Little-endian representation of words instead of the original big-endian.
* Changed round constants and initialization vectors.
* Extension of the ASCON permutation to 16 rounds for future use.
* A new customizable XOF function, ASCON-CXOF128.

I don't have a problem with these at the moment, but will probably have lots of questions as I try to implement it.

Is there a reference implementation and a set of KAT vectors available?

Once again, congratulations.

Cheers,

Rhys.

[Ross, Noah G. (Fed)]

Hello, I am part of the CAVP team at NIST and have been working on completing our implementation. While I do not have an exact estimate, I am hoping that it should be done relatively soon so that there is plenty of time to look at it while SP 800-232 is still within the draft period. Once it is finished, test vectors and intermediate steps will be posted to the CSRC website.

[Anjan Roy]

Thank you very much NIST for Ascon draft standard document. 

Hopefully I'll also prepare my implementation of Ascon cipher suite to match this draft standard in coming weeks. 

Kind regards,

Anjan Roy 

--
To unsubscribe from this group, send email to lwc-forum+...@list.nist.gov
Visit this group at https://groups.google.com/a/list.nist.gov/d/forum/lwc-forum
To unsubscribe from this group and stop receiving emails from it, send an email to lwc-forum+...@list.nist.gov.

[Martin Schläffer]

Hi all,

The Ascon team has already updated many of its implementations at: https://github.com/ascon/ascon-c

More details and first test vectors for Ascon-AEAD128, Ascon-Hash256 and Ascon-XOF128 can be found there.

Kind regards,

the Ascon team

[Bishwajit Chakraborty]

Hi all, 

It's good to see that after a long wait the public draft of the LwC standard is out. I  believe  that this next few months untill the comments deadline will be very fruitful for the LwC community. I  would like to congratulate the NIST team and the ASCON team once again. 

Having said that, I have an initial comment. It's good to see that NIST has kept the name ASCON which is highly appreciated given the popularity of the name and it also respect the designer's choice of naming. One small thing is that NIST has now renamed the ASCON128a as ASCON128. This is what confuses me. Since there is already an ASCON128 and a long track of research has been done and will be done in the future on both the versions,  I am a bit confused or say reluctant about how to refer them without creating a confusion for any casual reader.

Once again I congratulate both the NIST team and the ASCON team. 

Regards 

Bishwajit 

--

[Martin Schläffer]

Hi Bishwajit,

NIST has not renamed "Ascon-128a" to "Ascon-128".

NIST has introduced a new name, exactly to avoid this confusion: "Ascon-AEAD128"

The same holds for all other functions in the draft standard.

Kind regards,

Martin

[Bishwajit Chakraborty]

Hi Martin, 

Thanks for pointing that out. I totally missed that. 

Best

Bishwajit 

[Damian Vizár]

Hi all,

It is great to see the Ascon standard drafted!

It would be interesting to also formalize the Ascon PRF in a follow-up standard, possibly with other constructions (a permutation-based DRBG?), for a cipher suite reusing the same primitive.   

Best regards,

Damian

[Friedrich Wiemer]

Yes! I would like to repeat my request for a deterministic MAC construction. This would come in handy for use cases in the automotive domain, e.g. for protecting in-vehicle-communication.

Best regards,
Friedrich

--
Dr. Friedrich Wiemer,
orcid.org/0000-0003-2998-6777

[Lahlou, Laaziz]

Hi all,

Congratulations !

I would like to bring to your attention this published crypto-system: A versatile chaotic cryptosystem with a novel substitution-permutation scheme for internet-of-drones photography | Nonlinear Dynamics that might be interesting to the audience as well.

All the best,

Laaziz Lahlou, Ph.D.

[Mark Wagner]

Greetings everyone!

I realize that Martin Schlaffer commented above that the Ascon Team has already updated their test vectors for the new Ascon IPD, but I was wondering what the ETA might be for NIST-generated test vectors that I could use to verify my implementation. Perhaps Noah Ross could provide us with an update?

Best,

Mark Wagner

[Anjan Roy]

Dear NIST LwC community,

Good day. I hope you are doing well.

Just reporting, I've been working on updating my fully `constexpr` (well it's a C++ lingo, it means, you should be able to evaluate the function i.e. produce the output, given all inputs are known at program compile-time) C++ header-only implementation of Ascon cipher suite (which lives and evolves @ https://github.com/itzmeanjan/ascon) and all the KAT files produced by the Ascon team (🙏 thanks for those ), living @ https://github.com/ascon/ascon-c, are passing ✅ when tested against my implementation 💪.

The PR is still open @ https://github.com/itzmeanjan/ascon/pull/26, as I'm still finalizing it. In the meantime, if you have any feedback, I'd love to know those.

Thanks and kind regards,

Anjan Roy

[Bart Mennink]

Dear all,

It is nice to see that the draft Ascon standard got out!

Independently, Charlotte and I have been working on a systemization of knowledge on the generic security of the Ascon modes. The work considers the authenticated encryption and hashing modes, as well as the mode underlying Ascon-PRF. The work appeared on ePrint today [1].

Relatedly, note that the draft standard mentions in Table 9 that the Ascon-Hash256 mode guarantees 128 bits of preimage resistance, and that Ascon-XOF128 and Ascon-CXOF128 guarantee min(L,128) bits of preimage resistance. As a matter of fact, generically, these modes achieve 192 and min(L,192) bits of generic preimage resistance, in light of [2]. See also Section 8 of our SoK [1].

[1] Charlotte Lefevre, Bart Mennink: SoK: Security of the Ascon Modes. Cryptology ePrint Archive, Report 2024/1969, 2024. https://eprint.iacr.org/2024/1969
[2] Charlotte Lefevre, Bart Mennink: Tight Preimage Resistance of the Sponge Construction. CRYPTO (4) 2022: 185-204. https://doi.org/10.1007/978-3-031-15985-5_7

Kind regards,
Charlotte Lefevre and Bart Mennink.

[John Mattsson]

Dear LWC-forum members,

 

Thanks to the NIST Lightweight Cryptography Team for this well-written and open-access specification! We welcome NIST’s plans to standardize Ascon-based cryptography. We hope to see much more permutation-based cryptography standardized and used in the future.

 

The comments we provided to NIST on the Initial Public Draft of SP 800-232 can be found here:

https://emanjon.github.io/NIST-comments/2025%20-%20SP%20800-232.pdf

 

Our primary concerns with the initial public draft are the absence of an Ascon-based Key Derivation Function (KDF) and the proposed constraints for truncated tags. We would prefer that NIST publish Ascon-AEAD128 alongside an Ascon-based KDF that can be used to key it. Additionally, we believe SP 800-232 should not be published with the currently suggested constraints for truncated tags. These constraints should be significantly revised.

 

Cheers,
John Preuß Mattsson,

Expert Cryptographic Algorithms and Security Protocols, Ericsson

[Arne Padmos]

Hi John,

Thanks for sharing. I submitted the comments given at the end of this
mail, which also raise the importance of having Ascon-based KDF
functionality. I'd like to highlight a couple of additional insights
along with some related musings. Note that the draft standard references
SP 800-133 Rev. 2. Following the rabbit hole of SP 800-133 Rev. 2 -> SP
800-108 -> SP 800-108r1 -> SP 800-108r1-upd1 -> FIPS 198-1 -> FIPS 180-3
-> FIPS 180-4 (2012) -> FIPS 180-4 (2015) -> FIPS 202, one initially
gets the idea that HMAC using Ascon might be approved but is then faced
with the statement that no hashes except for SHA-1 and the SHA-2 and
SHA-3 families may be used. Specifically: 'Either [FIPS 180-4 (2015)] or
[FIPS 202] must be implemented wherever a secure hash algorithm is
required for Federal applications, including as a component within other
cryptographic algorithms and protocols.'

For simplicity's sake, let's assume that the 'Applicability' clauses in
FIPS 180-4 (2015) and FIPS 202 will be updated to include a note that
Ascon-Hash256 is also permitted where a hash function is needed. Note
that NIST has decided to revise FIPS 180-4 (2015) and has proposed
revising FIPS 202, so such a change is likely, but at a minimum I expect
an equivalent informative note to be published. However, FIPS 198-1 will
be converted to SP 800-224, the initial public draft of which only lists
the SHA-2 and SHA-3 families as approved for use with HMAC.

For now, while FIPS 198-1 makes one explicit reference to FIPS 180-3
when discussing approved cryptographic hash functions, FIPS 198-1
contains multiple notes like 'the HMAC algorithm is specified for an
arbitrary Approved iterative cryptographic hash function' and 'HMAC can
be used with any iterative Approved cryptographic hash function', with
one source for 'Other Approved Security Functions' stated as
cryptographic algorithms 'adopted in a FIPS or NIST Recommendation'.
While NIST SP 800-232 ipd doesn't include 'Recommendation' in the title,
the ipd does define the term 'approved' as 'An algorithm or technique
that is either specified or adopted in a FIPS publication or NIST
Special Publication in the Computer Security SP 800 series (i.e.,
FIPS-approved or NIST-recommended).'. As such, we can interpret NIST SP
800-232 as being a NIST Recommendation.

In summary, once Ascon-Hash256 is allowed for use as a hash function and
until FIPS 198-1 is retracted (that is, if Ascon-Hash256 isn't added to
the final version of SP 800-224), one NIST-approved KDF that'll be
available is HMAC-Ascon-Hash256 using one of the constructions described
in sections 4.1, 4.2, and 4.3 of SP 800-108r1-upd1. For key derivation
requiring at most 256 bits of output, a single HMAC call will suffice in
the case of HMAC-Ascon-Hash256 following the construction from section
4.1 and/or 4.2. One solution that is in line 'to the letter' with both
sections 4.1 and 4.2 of SP 800-108r1-upd1 comes down to K = HMAC(Input
key, the single bit '1' || Label as bitstring || the octet 0x00
(optional if Label and Context are of equal length, have length
explicitly encoded, and/or are of constant length) || Context as
bitstring || a bit string of length 9 encoding output key size (from 0x1
to 0x100).

Note that 'alternative orders for the input data fields may be used for
different KDFs' as long as 'the length for each data field and their
order shall be defined unambiguously'. SP 800-108r1-upd1 also states
that 'one or more of these fixed input data fields may be omitted unless
required for certain purposes, as discussed in Section 6.5 and Section
6.6'. This means that you can go wild in the formatting of input to
HMAC-Ascon-Hash256, as long as the the 'shall' requirement of key
separation (cf. section 6.5) is met, with the recommendation ('should')
to also achieve context binding (cf. section 6.6). SP 800-133 Rev. 2 –
which is directly cited in the Ascon standard – notes that a key can be
'derived using a KDF and a (different) preexisting key as specified in
SP 800-108', i.e. HMAC-Ascon-Hash256 can be applied in a manner
appropriate to the context of use as long as, for the specific
application, there is both a one-to-one mapping of the input fields to
the bitstring entering the KDF and the fields selected provide key
separation.

Now, while HMAC is a good insurance policy as illustrated by HMAC-MD5,
it's not very lightweight. For HMAC, it's a bit unclear which value to
use for the block size parameter 'B' in FIPS 198-1. In SP 800-224 ipd,
the rate of the SHA-3 hash functions is used a 'B', but using a 64-bit
block size as in Ascon-Hash256 doesn't match with the HMAC algorithm
specified in table 1 of FIPS 198-1. For the HMAC algorithm to make
sense, 'B' needs to be at least as large as the hash output, i.e. 32
bytes in the case of HMAC-Ascon-Hash256. Ignoring both the possibility
of precomputed states and the additional memory costs and whatnot for
the storage of intermediates, HMAC-Ascon-Hash256 with a 'B' parameter of
32 bytes will require at least 20 to 22 calls to Ascon-p[12] (for input
less than or equal to 256 bits and 128-bit to 256-bit output), with an
extra call for every additional 64 bits of MAC input. Ascon-Hash256 in
secret prefix mode would require at least 5 to 9 calls to Ascon-p[12]
(for 128-bit input and 128-bit output to 256-bit input and 256-bit
output), with an extra call for every additional 64 bits of MAC input.

Of course, we could just say 'use Ascon-PRF for key derivation'.
However, as you note, a KDF based on Ascon-Hash256 and/or the XOFs
provides stronger guarantees than Ascon-PRF and Ascon-MAC. For my use
cases, I don't see a need for Ascon-PRF, but I agree that it could be
standardised in a separate SP in case there is sufficient demand and if
the performance benefits are convincingly demonstrated. A key argument
for not including Ascon-PRF, Ascon-PRFshort, and/or Ascon-MAC in SP
800-232 is that this would lead to more delays. According to the initial
project timeline, the plan was to have standards within two to four
years after the start of public analysis (planned around the beginning
of 2019). We are now at six years and we don't have a final standard
yet. This shouldn't be taken as criticism of the great work that the LWC
team has done. The requirements for the LWC project were much less clear
than for the AES competition, and as a result there's been various
twists and turns, changes in direction, etc. etc. Even so, at this
point, I don't think that we need to introduce more potential causes of
delay. Another reason is that during the LWC project the answer to 'How
does CSD develop standards?' has always been 'international
competitions' (later changed to 'international "competitions"'),
'adoption of existing standards', 'open call for proposals', and
'development of new algorithms'. Adopting
https://eprint.iacr.org/2021/1574 as an SP isn't on that list, as there
isn't (yet) an open call for proposals for Ascon-based modes like there
is for block ciphers.

Where does that leave us? I think that the cleanest solution would be to
flag Ascon-Hash256 with a prefixed key as an approved MAC, as this is
the algorithm specified in the international standard ISO/IEC
29192-6:2019, namely Tsudik's keymode (cf. 'adoption of existing
standards' above). Specifically, Tsudik's keymode is the 'secret prefix'
approach described in Tsudik's 1992 paper
(https://dl.acm.org/doi/pdf/10.1145/141809.141812), i.e. H(K||M). ISO
29192-6 restricts the use of Tsudik's keymode to the three hash
functions specified in ISO/IEC 29192-5:2016, namely the PHOTON family,
the SPONGENT family, and Lesamnta-LW. However, there is no reason that
Tsudik's keymode using Ascon-Hash256 couldn't be approved, as
Ascon-Hash256 meets the requirements given in annex C of ISO/IEC
29192-6:2019, namely 'collision-resistant and resistant to
length-extension attacks'. This assumes that a requirement is introduced
that the input key length is fixed (or at least, is constrained in such
a way that the requirement of key separation described in section 6.5 of
SP 800-108r1-upd1 is met). Additionally, for key derivation, the message
part of prefix-keyed Ascon-Hash256, i.e. the M in H(K||M), would have to
meet the requirements given in SP 800-108r1-upd1.

Approving prefix-keyed Ascon-Hash256 for deriving a 256-bit value to be
used directly as key material (as K and K' or two Ks) or as input for
further key derivation nicely aligns with NIST's previous decision to
change the variable-length shared secret of the third-round
CRYSTALS-Kyber to a fixed-length shared secret key of 32 bytes for all
ML-KEM security levels standardised in FIPS 203. SP 800-232 could
contain similar language to the 'Approved usage of the shared secret
key' paragraph in section 3.3 of FIPS 203. Discussions around NIST's
accordion mode effort have also noted a strong preference for 256-bit
keys (cf. NIST IR 8537). For performance reasons and to align with other
NIST standards like SP 800-107 Rev. 1 (at the 'human interface' level),
K should be mapped to the first 128 bits squeezed and K' to the last 128
bits, with the leftmost bits of the printed keyed hash mapping to K and
the rightmost bits mapping to K'. Ideally the ordering of these 256 bits
should directly translate into the ordering of the state of
Ascon-AEAD128 (which going by figure 5 and algorithm 3 from SP 800-232
ipd seems to be the case, although it's not explicitly described in
appendix A).

Cheers,
Arne

PS. To be fully aligned with ISO/IEC 29192-6:2019, MAC tags should be
truncated by taking the least significant bits of the keyed hash output.
This already seems to be the case for the tag Ascon-AEAD128, where
section '4.2.1. Truncation' of SP 800-232 ipd describes that the
leftmost lambda bits of the tag are taken, i.e. T[0:lambda-1]. However,
from appendix A it is unclear how the full 256-bit output would be
printed and whether this would be in byte-wise little-endian format, so
that at least at the byte level the leftmost pair of hexadecimal
characters can be taken. This allows hash/tag truncation to remain
little-endian while (mostly) aligning with the 'human interface' of
big-endian publications like SP 800-107 Rev. 1 and RFC 4868 that take
the leftmost bits of the string. (Going by the display format of the
pyascon reference implementation for the output of Ascon-XOF128, it
appears that the output is formatted as a string representing a byte
array of 8-bit integers represented in hexadecimal, with the bytes on
the left being those squeezed first and the bytes on the right being
those squeezed last. This appears to correspond to the middle
representation of figure 10 of SP 800-232 ipd (i.e. 'Word value (byte
sequence)'). It would make a useful canonical display format that
uniquely describes hash, XOF, and AEAD output (provided that byte-length
output is requested from the XOF and that byte-length plaintext input is
provided to the AEAD). Although it might need a warning related to
arbitrary bit-length inputs/outputs sometimes mapping into the same hex
string / byte array, even if they have different specified output bit
lengths. Note that the pyascon reference implementation only supports
byte arrays. The ascon-c implementations also seem to be byte-oriented,
and I can't find any bit-length known-answer tests.)

---

Dear NIST LWC team,

Thank you again for the great work in organising the lightweight crypto
competition (aka "competition" or competition-like process) as well as
the subsequent standards drafting process. Please find couple of
comments below on the initial public draft of SP 800-232, focussed
around the topics identified in the draft as having changed from the
Ascon v1.2 spec.

Regards,
Arne


I think it's good to have a new IV format and to have Ascon-p defined up
to 16 rounds for potential functionality extensions. In NIST's last LWC
presentation, the additional functionalities are flagged as 'PRF, MAC,
KDF, DRBG etc.'. I understand that SP 800-232 won't contain a specific
list of functionality to be standardised in the future, but it would be
useful to get some idea of what's on the backlog and how the
standardisation of that functionality will be approached. For example,
for the SP 800-38 series there is an open continuing call for proposals
and there is also the accordion mode effort currently ongoing (note that
some of the suggested modes are instantiable with Ascon-XOF128).

As also noted in my comments on the the decision proposal to revise SP
800-185, a two-pass mode for key wrapping and some way to support
sessions would be interesting avenues for further exploration. In the
meantime, one thing that should be included in SP 800-232 is a note that
keys can be derived using Ascon-based hash and XOF variants. The SP
800-232 initial public draft makes reference to SP 800-133 Rev. 2, which
references the withdrawn SP 800-108 for approved methods for symmetric
key derivation from a pre-existing key. The updated SP 800-108r1-upd1
specifies different KDFs using CMAC as a PRF as well as a KDF using KMAC
and a KDF using HMAC. As is, implementations of Ascon-AEAD128 might be
hampered by having to implement HMAC for key derivation, let alone the
overhead of CMAC or KMAC.

Relatedly, while I understand not wanting to spend large parts of the
encoding space of IVs for user customisation, I still think that some
kind of 'private IV space' would be useful – such as by making the upper
4 bits of 'v' configurable or by reserving another subset of the unique
algorithm identifier for tailored variants (e.g. 0x80 to 0xFF). This can
help reduce computational overhead and reduce the need for separate key
derivation, storage, etc. etc. for situations like bi-directional
channels. Also, this can make domain separation explicit between
standard and tailored implementations. For example, implementations that
decide to include zero padding and/or that make use of bit-interleaved
input for better performance on 32-bit microcontrollers. Where needed,
it would also allow implementers to clearly separate the output for
different tag lengths, as well as allowing a distinction between raw and
hashed customisation strings.

The switch from big-endian to little-endian is a logical one. Appendix A
on implementation considerations and endianness is a great addition
providing relevant background information. It might be helpful to more
clearly highlight how multi-word values are read from or written to
memory, such as a 128-bit key or a precomputed state. For figure 10, it
could be useful to specify that the byte values correspond to memory
address offsets. Additionally, consider including references to
implementation optimisation techniques like bit interleaving and state
precomputation. Also, the standard should clarify how multi-word strings
like hash and XOF outputs are to be printed such that a single canonical
display format can be put in place. Even if it's not a full KAT suite,
having at least a modicum of test vectors included in the standard –
e.g. in a new appendix C – would help to make all of this more concrete
for implementers.

It is wonderful to see that the XOFs are included in the draft standard.
I do find it somewhat baffling that the hash variant is also included.
The distinction between the hash versus XOFs is an artificial one.
Adding the hash means more variants without good reason. Note that the
Ascon-AEAD128 variant used with longer and shorter tags also doesn't get
different IVs. If the problem is that previous NIST publications make
reference to a hash as a function with a fixed output, then
Ascon-Hash256 could simply be defined as a synonym of Ascon-XOF128 with
a fixed output length in a given context, just like how Ascon-AEAD128
with different tag lengths is disambiguated through the use of different
keys. Some guidance can be included to append the output length where
explicit domain separation is necessary. (While reference could also be
made to Ascon-CXOF128, as it's currently defined, Ascon-CXOF128 is less
efficient than it could be for customisation strings less than or equal
to 6 bytes. Also, the implementation complexity of Ascon-CXOF128 may by
greater than simply xoring a domain separation bit to the state or
prepending/appending a fixed-length string to the message. See how the
Ascon-CXOF128 variant remains 'to be implemented' in the pyascon
reference implementation.)

SP 800-232 ipd notes that 'the supported security strength [of
Ascon-XOF128] is up to 128 bits' with 'Ascon-Hash256 [...] offering a
security strength of 128 bits', but it doesn't mention that the mode of
Ascon-Hash and Ascon-(C)XOF provides 192-bit preimage resistance (for
output sizes greater than or equal to 192 bits) as detailed by Lefevre
and Mennink in 'SoK: Security of the Ascon Modes'
(https://eprint.iacr.org/2024/1969.pdf#subsection.8.3). It would be
useful to understand the concrete security of Ascon-XOF128, especially
because of the decision to go for the XOF variant with the larger
security margin. Provided that the concrete security level is
sufficient, the 'Preimage' column in table 9 can be updated with the
values '192', 'min(L,192)', and 'min(L,192)'. If insufficient
information is available to determine concrete security levels, then the
caption of table 9 should be changed to 'Target security strengths'.

Nonce-masking is a very useful feature. The related warning regarding
context commitment is appropriate, but it should be accompanied by a
note that the context commitment of Ascon-AEAD128 is limited to a 64-bit
security level. A higher level of 96 bits can be achieved through
tailored zero padding with 64 zero bits, while a 128-bit security level
can only be achieved using the Ascon-128 variant with 128-bit zero
padding combined with fixing half of the nonce to zero or adding an
initial key derivation step. More details can be found in 'Committing
security of Ascon' by Naito et al.
(https://doi.org/10.46586/tosc.v2023.i4.420-451).

There is a clear demand for 64-bit tags, even with all of the pitfalls
involved. As to the limitations on the maximum number of decryption
failures, it might be useful to make it very concrete what these
limitations mean for tags of length 64, 96, and 128 bits. Also, the
requirement to update the key once 'the total number of input data
blocks or the number of decryption failures reach their respective
limits' is clear. However, how will the part of 'or if the nonce
uniqueness requirement is violated' be enforced? Are implementations
supposed to keep a tally of all nonces that have been generated?

---