NIST Selects Ascon

[Sonmez Turan, Meltem (Fed)]

Dear forum members,

The NIST Lightweight Cryptography Team has reviewed the finalists based on their submission packages, status updates, third-party security analysis papers, and implementation and benchmarking results, as well as the feedback received during workshops and through the lwc-forum. The selection was challenging since most of the finalists exhibited performance advantages over NIST standards on various target platforms without introducing security concerns.

The team has decided to standardize the Ascon family for lightweight cryptography applications as it meets the needs of most use cases where lightweight cryptography is required.

Congratulations to the Ascon team! NIST thanks all of the finalist teams and the community members who provided feedback that contributed to the selection. 

NIST’s next steps will be to:

• Publish NIST IR 8454, which describes the details of the selection and the evaluation process
• Work with the Ascon designers to draft the new lightweight cryptography standard for public comments
• Host a virtual public workshop to further explain the selection process and to discuss various aspects of standardization (e.g., additional variants, functionalities, and parameter selections) as well as possible extensions to the scope of the lightweight cryptography project. The tentative dates for the workshop are June 21-22, 2023. More information will be provided in the upcoming weeks.

Thanks,

NIST Lightweight Cryptography Team

 

[Alex Max]

Hello everyone,

My congratulations to the Ascon team! Well done!

PS: Now it's time to break it :)

Best regards,

/Alexander

вт, 7 февр. 2023 г. в 15:51, 'Sonmez Turan, Meltem (Fed)' via lwc-forum <lwc-...@list.nist.gov>:

--
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.

[Arne Padmos]

Congratulations to the Ascon team as well as to NIST on completing their
tough deliberations. Looking forward to reading NISTIR 8454.

For those who haven't seen it yet, NIST also posted a news article with
some more details:
https://www.nist.gov/news-events/news/2023/02/nist-selects-lightweight-cryptography-algorithms-protect-small-devices

The news article contains the following gem: 'the newly selected
algorithms should be appropriate for most forms of tiny tech'.

It's great to see that NIST will be hosting another public workshop for
gathering further community input. I hope that the workshop will draw in
domain experts from the various fields where 'tiny tech' is actually
used.

On 2023-02-07 15:51, 'Sonmez Turan, Meltem (Fed)' via lwc-forum wrote:
> Dear forum members,
> The NIST Lightweight Cryptography Team has reviewed the finalists
> based on their submission packages, status updates, third-party
> security analysis papers, and implementation and benchmarking results,
> as well as the feedback received during workshops and through the
> lwc-forum. The selection was challenging since most of the finalists
> exhibited performance advantages over NIST standards on various target
> platforms without introducing security concerns.
> The team has decided to standardize the Ascon family for lightweight
> cryptography applications as it meets the needs of most use cases
> where lightweight cryptography is required.
> Congratulations to the Ascon team! NIST thanks all of the finalist
> teams and the community members who provided feedback that contributed
> to the selection.
> NIST's next steps will be to:
>

> * Publish NIST IR 8454, which describes the details of the

> selection and the evaluation process

> * Work with the Ascon designers to draft the new lightweight

> cryptography standard for public comments

> * Host a virtual public workshop to further explain the selection

[Robert Moskowitz]

We did get hash support into the LWC work.

But now, we need an EdDSA variant that uses ASCON rather than SHA512.  I
will be bringing this up in CFRG in the next few days.

[Arne Padmos]

Quoting from the NIST news article:
“The goal of this project is not to replace AES or our hash standards,” she said. “NIST still recommends their use on devices that don’t have the resource constraints that these new algorithms address. There are native instructions in many processors, which support fast, high-throughput implementations. In addition, these algorithms are included in many protocols and should continue to be supported for interoperability purposes.”

[Rhys Weatherley]

Congratulations to the ASCON team, and thanks to all of the submission groups.

I had a lot of fun implementing all of the algorithms in Round 2 and the Final Round and comparing their performance.  You can all be very proud of pushing cryptography research forward with so many new and varied designs.

Cheers,

Rhys.

https://github.com/rweather/ascon-suite

--

[John Mattsson]

Hi,

 

Ascon seems like a very good choice. Congratulations to the Ascon team!

 

I think ASCON will find its way into a large number of applications.

 

NIST Lightweight Cryptography Team wrote:
>discuss various aspects of standardization (e.g., additional variants, functionalities, and parameter selections)

 

Below are comments on the current ASCON 1.2 specification that I would like to see addressed already in the NIST draft specification:

 

• I would like to see 160-bit nonces as an option. This seems possible with 128-bit keys. Use of random nonces are common practice and increasing the nonce length increases the number of instantiations that can be allowed with a single key. The limited number of instantiations with random nonces is a big problem with AES-GCM.

 

• I would like to see shorter tags as an option. Either tag length as a variable or a smaller set of allowed tag lengths (e.g., 32, 64, 96, 128). 32-bit tags are standard in most radio link layers including 5G. 64-bit tags are very common in the Internet of things. 32 and 64-bit tags are also common for protection of audio frames (also in future proposals like IETF SFRAME).

 

• I would like to see zero tag length as an option. IND-CPA encryption has several use cases: Header encryption in DTLS 1.3 and QUIC, message_2 encryption in EDHOC, as well as in systems where integrity is provided by a signature. IETF COSE has decided to reintroduce IND-CPA encryption such as AES-CTR for this purpose.

 

• I strongly think NIST should standardize one of the variable-length hash-functions Ascon-Xof or Ascon-Xofa. I don't see any reason whatsoever to standardize one of the fixed-length hash function. Anybody wanting 256-bit digest can use the variable-length hash function with l = 256. Shorter digests will be needed. For SHA2, NIST has afterwards introduced two different variable-length hash functions based on the fixed-length hash function. SHA-256/t being simple truncation to t bits and the SHA-512/t which also changes some of the inner constants. Longer digests will also be needed for sure.

 

• I strongly think NIST should specify a keyed ASCON hash function that can be used as a MAC and KDF. That can likely be done much more optimal than with 2-pass HMAC and 4-pass HKDF. I think a keyed ASCON hash function should be available from the start and not years later.

 

Additional comments:

 

• I don’t see any strong need for the version with a 160-bit key. Even if a CRQC that can break RSA and ECC is hours is ever build, it seems completely unpractical for a huge cluster of such CRQCs to break ASCON with 128-bit keys. I assume that ASCON with a 128-bit key requires less gates than AES-128 and therefore falls slightly under the NIST PQC security level I. It is still unclear how NIST will define security levels in the future. One solution is to define level I as at least as hard as ASCON. I don’t think the choice of AES-128 or ASCON makes much of a practical difference.

 

• I agree with the earlier comment from Bob Moskowitz that NIST should specify the use of ASCON in Ed25519.

 

• Consider adding customization string and parallelization from the start like instead of adding it later like SP 800-185.

 

(I will likely submit an expanded version of the comments above as a position paper to the upcoming public workshop).

 

Cheers,
John

[Robert Moskowitz]

Of course not to replace, but to augment.  Again, if I have a device where I want to use ASCON for hashing, AND it needs digital signature, why do I have to carry the SHA code for the SHA512 operation in EdDSA25519.

I am particularly interested in this for Unmanned (uncrewed) Aviation Systems (UAS).

--
Robert Moskowitz
Owner
HTT Consulting
C:      248-219-2059
F:      248-968-2824
E:      r...@labs.htt-consult.com

There's no limit to what can be accomplished if it doesn't matter who gets the credit

[Robert Moskowitz]

Exactly my point and need.

See, for example, https://datatracker.ietf.org/doc/draft-ietf-drip-rid/

Where I am using EdDSA25519 in small unmanned aircraft.  There WILL be UA where LWC will be desired for secure Command and Control (C2).  Adding a EdDSA25519/Ascon suite to DRIP RID is attractive.

On 2/8/23 02:51, Friedrich Wiemer wrote:

That's not a contradiction to Roberts request, is it?
It well might be the case that resource constrained devices need to do EdDSA - in case they'll use Ascon for encryption it sounds beneficial to me if they can also use it for hashing in the asymmetric schemes.

It doesn't mean, EdDSA should solely support Ascon - SHA versions will stay for sure. 

On February 8, 2023 7:34:39 AM UTC, Arne Padmos <h...@arnepadmos.com> wrote:

-- 
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.

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

[Robert Moskowitz]

I did not work at all with Ascon because of some of the limitations below.  They really need to be addressed going forward.

On 2/8/23 04:00, 'John Mattsson' via lwc-forum wrote:

Hi,

 

Ascon seems like a very good choice. Congratulations to the Ascon team!

 

I think ASCON will find its way into a large number of applications.

 

NIST Lightweight Cryptography Team wrote:
>discuss various aspects of standardization (e.g., additional variants, functionalities, and parameter selections)

 

Below are comments on the current ASCON 1.2 specification that I would like to see addressed already in the NIST draft specification:

 

• I would like to see 160-bit nonces as an option. This seems possible with 128-bit keys. Use of random nonces are common practice and increasing the nonce length increases the number of instantiations that can be allowed with a single key. The limited number of instantiations with random nonces is a big problem with AES-GCM.

 

• I would like to see shorter tags as an option. Either tag length as a variable or a smaller set of allowed tag lengths (e.g., 32, 64, 96, 128). 32-bit tags are standard in most radio link layers including 5G. 64-bit tags are very common in the Internet of things. 32 and 64-bit tags are also common for protection of audio frames (also in future proposals like IETF SFRAME).

Yes.  I use different tag lengths depending on what I have room for and the risk model.

 

• I would like to see zero tag length as an option. IND-CPA encryption has several use cases: Header encryption in DTLS 1.3 and QUIC, message_2 encryption in EDHOC, as well as in systems where integrity is provided by a signature. IETF COSE has decided to reintroduce IND-CPA encryption such as AES-CTR for this purpose.

Interesting.  I use AES-CFB in

https://datatracker.ietf.org/doc/draft-moskowitz-drip-operator-privacy/

For encrypting a single or couple of fields within the data frame.  This is mandatory for some other stuff that I cannot discuss.  So a zero tag would allow use of Ascon here.

 

• I strongly think NIST should standardize one of the variable-length hash-functions Ascon-Xof or Ascon-Xofa. I don't see any reason whatsoever to standardize one of the fixed-length hash function. Anybody wanting 256-bit digest can use the variable-length hash function with l = 256. Shorter digests will be needed. For SHA2, NIST has afterwards introduced two different variable-length hash functions based on the fixed-length hash function. SHA-256/t being simple truncation to t bits and the SHA-512/t which also changes some of the inner constants. Longer digests will also be needed for sure.

Absolutely agree.  I need hashes of varying lengths.  8-byte in

https://datatracker.ietf.org/doc/draft-ietf-drip-auth/

Having two to select from makes me wonder why and which for what.

And agree that 256 should just be a use case of variable length.

 

• I strongly think NIST should specify a keyed ASCON hash function that can be used as a MAC and KDF. That can likely be done much more optimal than with 2-pass HMAC and 4-pass HKDF. I think a keyed ASCON hash function should be available from the start and not years later.

This is not even a debate point for me.  KMAC is mandatory in my use.  Ascon MUST provide same rather than an HMAC variant.  Same for a KDF.

 

Additional comments:

 

• I don’t see any strong need for the version with a 160-bit key. Even if a CRQC that can break RSA and ECC is hours is ever build, it seems completely unpractical for a huge cluster of such CRQCs to break ASCON with 128-bit keys. I assume that ASCON with a 128-bit key requires less gates than AES-128 and therefore falls slightly under the NIST PQC security level I. It is still unclear how NIST will define security levels in the future. One solution is to define level I as at least as hard as ASCON. I don’t think the choice of AES-128 or ASCON makes much of a practical difference.

PQC age?  Or as you indicate really worry about this.  I can see it and MAYBE having it.  Plus some military may be stuck on needing more that 128.

 

• I agree with the earlier comment from Bob Moskowitz that NIST should specify the use of ASCON in Ed25519.

 

• Consider adding customization string and parallelization from the start like instead of adding it later like SP 800-185.

800-185 has been so valuable to me, that why do we need two docs this time?  We learned our lesson, or I hope we have.

I use cSHAKE in

https://datatracker.ietf.org/doc/draft-ietf-drip-rid/ (in RFC editor queue for publication)

--

[Joan Daemen]

Many congratulations to the ASCON team for winning the NIST lightweight competition!

Although of course we would have liked to win ourselves, we think ASCON is an excellent scheme and congratulate NIST for choosing a permutation-based cipher!

Kind regards,

The Xoodyak team
Gilles, Joan, Michaël, Ronny, Seth and Silvia

--

[Rhys Weatherley]

On Wed, Feb 8, 2023 at 7:01 PM 'John Mattsson' via lwc-forum <lwc-...@list.nist.gov> wrote:

• I strongly think NIST should standardize one of the variable-length hash-functions Ascon-Xof or Ascon-Xofa. I don't see any reason whatsoever to standardize one of the fixed-length hash function. Anybody wanting 256-bit digest can use the variable-length hash function with l = 256. Shorter digests will be needed. For SHA2, NIST has afterwards introduced two different variable-length hash functions based on the fixed-length hash function. SHA-256/t being simple truncation to t bits and the SHA-512/t which also changes some of the inner constants. Longer digests will also be needed for sure.

ASCON's hashing mode already does this with the desired output length in bits (0 for arbitrary) in the domain separation value within the initial block.  ASCON-HASH is the special case where the desired output length is 256.  ASCON-XOF is the special case where the desired output length is 0.  So if "ASCON-XOF[n]" where "n" is the output length is standardised, then all of the other use cases flow directly from that.

 

 

• I strongly think NIST should specify a keyed ASCON hash function that can be used as a MAC and KDF. That can likely be done much more optimal than with 2-pass HMAC and 4-pass HKDF. I think a keyed ASCON hash function should be available from the start and not years later.

As an experiment, I made a variant of NIST's KMAC that uses ASCON-XOF as the underlying primitive instead of SHAKE:

https://rweather.github.io/ascon-suite/kmac.html

However, NIST's SHAKE-based KMAC can be complex with the domain separation and length prefixing/suffixing.  It would be simpler to just do this:

ASCON-KEYED(key, data, outlen) = ASCON-XOF[n](key || padding || data, outlen)

Can be used as both a MAC or a KDF depending upon the selected "outlen".

Cheers,

Rhys.

[Simon Hoerder]

Hi,

Congratulations to the Ascon team!

Personally I believe NIST should add Ascon as a XOF with Ascon-Hash as a special case. I also believe that NIST should be adding a XOF-based construction to the DRBGs in SP800-90A. (Not just Ascon-XOF but also SHAKE.)

Regarding the requests for an Ascon based MAC that have been made in this thread: Wouldn’t it be sufficient to use Ascon-AEAD with a 0-length plaintext and the message as additional data to be authenticated? Apologies if my question is a little naïve; it has been a while since I last looked at new symmetric constructions and I may very well be missing something obvious.
I can understand if you need Ascon-AEAD with 0-length plaintext to be added as MAC in a NIST standard but I’d rather not add a new, dedicated MAC mode of operation unless it provides an advantage that Ascon-AEAD can not. That advantage should then be clearly stated.

Best,
Simon
(Speaking only for myself)

[Robert Moskowitz]

In both the use of HMAC and explicitly in KMAC there is the inclusion of
a customization string.  There are many reasons to include this.  So how
would this be handled in your proposal?

Also I want explicit calls for implementors (and protocol designers) to
use.  I don't want to leave this to chance.  We had enough arguments
with HMAC about adding the string and how to truncate the hash to the
desired length,  I lived tooooo many of these debate threads with HMAC. 
KMAC just did it in the "best practice" way; done and finished.

And another thing that crept into a side discussion, is we need an OID
for use of Ascon-hash in X.509.  That will be a "simple" rfc; I will
have to shake the PKIX list about someone picking this up.

Also need to discuss in DNS-OPS if there is any Resource Records that
need updating.

Side thought:  Will NIST 'rebrand' Ascon as they did in AES and SHA3? 
What will be the protocol design / program library discuss be going forward?

Bob

[Gé Weijers]

On Thu, Feb 9, 2023 at 12:49 AM Simon Hoerder <si...@hoerder.net> wrote:

Regarding the requests for an Ascon based MAC that have been made in this thread: Wouldn’t it be sufficient to use Ascon-AEAD with a 0-length plaintext and the message as additional data to be authenticated? Apologies if my question is a little naïve; it has been a while since I last looked at new symmetric constructions and I may very well be missing something obvious.
I can understand if you need Ascon-AEAD with 0-length plaintext to be added as MAC in a NIST standard but I’d rather not add a new, dedicated MAC mode of operation unless it provides an advantage that Ascon-AEAD can not. That advantage should then be clearly stated.

 

Not an expert, but the AEAD mode needs a nonce, a regular MAC does not. The security guarantees don't apply if you pass the same nonce twice, so it does not work like a MAC. The Github repository published by the Ascon team contains a MAC (auth) algorithm, but I don't think it was part of the submission to NIST.

Gé

[Anjan Roy]

Hi NIST and LWC community,

Good day. First of all congratulations to the Ascon team !

It was great experience and learning opportunity for me getting a chance to implement all the ten finalist of NIST LWC as header-only, zero-dependency C++ libraries. More @ https://groups.google.com/a/list.nist.gov/g/lwc-forum/c/abb6cy7jP8s.

My plain C++ Ascon library implementation lives @ https://github.com/itzmeanjan/ascon.

You might notice, Ascon-XOF{A} is not yet implemented, but it's on my todo list. I welcome any suggestions or comments.

Thanks all. Regards

Anjan Roy

[D. J. Bernstein]

I received a question in my role as CAESAR secretary regarding CAESAR's
selection of Ascon for the final CAESAR portfolio in 2019. I'm answering
publicly in case other people are interested.

The CAESAR portfolio is organized into three use cases. Use case 1 is
"Lightweight applications (resource constrained environments)", which in
particular announced the following criteria:

* critical: fits into small hardware area and/or small code for 8-bit CPUs
* desirable: natural ability to protect against side-channel attacks
* desirable: hardware performance, especially energy/bit
* desirable: speed on 8-bit CPUs
* message sizes: usually short (can be under 16 bytes), sometimes longer

The CAESAR portfolio for use case 1 consists of Ascon as first choice
and ACORN as second choice.

The CAESAR rules required each submission to include "a prioritized list
of recommended parameter sets: a primary recommendation, a secondary
recommendation, etc." The Ascon submission to CAESAR provided two
parameter sets: Ascon-128 as primary, and Ascon-128a as secondary. Both
of these are in the CAESAR portfolio.

(In cases where the CAESAR portfolio includes fewer parameter sets,
those parameter sets are listed explicitly in the portfolio. For
example, the portfolio includes AEGIS-128 from the AEGIS submission.)

The Ascon submission to NIST includes more options than the Ascon
submission to CAESAR. For people who wish to understand the basis for
the CAESAR selection and the extent to which that basis applies to
further Ascon options, the following CAESAR rules are relevant:

* "selection decisions will be made on the basis of _published_
analyses";

* "the committee will not comment on the algorithms, except that for
each selected algorithm the committee will simply cite the
previously published analyses that led to the selection of the
algorithm".

The latter citations were sent to the crypto-competitions mailing list.
For example, the announcement email dated 15 Aug 2016 06:03:43 -0000
cited the following publications regarding Ascon:

https://competitions.cr.yp.to/round2/asconv11.pdf
https://competitions.cr.yp.to/round1/asconv1.pdf
https://eprint.iacr.org/2016/490
https://eprint.iacr.org/2016/188
https://eprint.iacr.org/2015/1200
https://eprint.iacr.org/2015/090
https://eprint.iacr.org/2015/034
https://eprint.iacr.org/2015/030
https://eprint.iacr.org/2014/373
https://cryptography.gmu.edu/athena/
https://eprint.iacr.org/2016/740
https://bench.cr.yp.to
https://eprint.iacr.org/2014/850
https://eprint.iacr.org/2014/792
https://aezoo.compute.dtu.dk/doku.php

All subsequent Ascon publications considered in CAESAR were on eprint
plus https://competitions.cr.yp.to/round3/asconv12.pdf. Obviously there
were also various publications regarding Ascon after CAESAR concluded.

---D. J. Bernstein

P.S. Personal note: Congratulations to the Ascon team!

[Arne Padmos]

Hi Dan,

Thank you for the quick response.

Do I understand your reply correctly that the CAESAR portfolio for use
case 1 should be read as 'Ascon-128 as primary, Ascon-128a as secondary,
and ACORN as tertiary recommendation', in line with the recommendations
of Ascon's designers provided in the v1.2 spec linked on CAESAR's page?
Or does the inclusion of both Ascon-128 and Ascon-128a only convey that
they are 'a member of the final portfolio', without any further 'other
designation provided by the committee' as to which one is preferred?
(Quoted text taken from the CAESAR rules.)

Of course, I understand that the CAESAR portfolio does not necessarily
provide any insights as to the appropriateness of parameter sets and
constructions published after the conclusion of the CAESAR competition.

Regards,
Arne

PS. My original question included a reference to the CAESAR FAQ, which
notes that 'the selection committee will issue a report that, for each
selected algorithm, cites the previously published analyses that led the
algorithm to be selected'. I wasn't able to find such a report for the
selection of the CAESAR finalists or the portfolio in a public archive,
but it's good to see the details shared here. Separately, although I do
understand some of the reasons for not publishing a detailed rationale
for the selection, I am not alone in appreciating a more in-depth look
at how published results are interpreted. Personally, such insights
would be useful for understanding various dynamics behind cryptographic
competitions and the extent to which these are applicable within an
educational context. (Note that there is surprisingly limited literature
available on the topic of adversarial engineering design competitions
compared to the widespread popularity of both hackathons and CTFs.)

[D. J. Bernstein]

Arne Padmos writes:
> Do I understand your reply correctly that the CAESAR portfolio for use case
> 1 should be read as 'Ascon-128 as primary, Ascon-128a as secondary, and
> ACORN as tertiary recommendation', in line with the recommendations of
> Ascon's designers provided in the v1.2 spec linked on CAESAR's page?

No. The CAESAR portfolio designates Ascon as "first choice for use case
1" and designates ACORN as "second choice for use case 1".

That version of Ascon, in compliance with the CAESAR requirement to

include "a prioritized list of recommended parameter sets: a primary

recommendation, a secondary recommendation, etc.", provided a list with
Ascon-128 as primary and Ascon-128a as secondary. The CAESAR portfolio
doesn't make designations specific to those parameter sets.

(One reason for competitions to require a prioritized list of parameter
sets is that efforts to compare performance of submissions often end up
covering only a limited number of parameter sets. Having a prioritized
list makes it more likely that measurements will be available for the
same parameter set across platforms.)

> Or does
> the inclusion of both Ascon-128 and Ascon-128a only convey that they are 'a
> member of the final portfolio', without any further 'other designation
> provided by the committee' as to which one is preferred?

https://competitions.cr.yp.to/caesar-submissions.html explicitly lists
all designations provided by the committee. For example, the final
CAESAR portfolio includes Ascon as "first choice for use case 1".

> PS. My original question included a reference to the CAESAR FAQ, which notes
> that 'the selection committee will issue a report that, for each selected
> algorithm, cites the previously published analyses that led the algorithm to
> be selected'. I wasn't able to find such a report for the selection of the
> CAESAR finalists or the portfolio in a public archive, but it's good to see
> the details shared here.

See the public crypto-competitions mailing list for the record of
citations and other committee announcements.

> (Note that there is
> surprisingly limited literature available on the topic of adversarial
> engineering design competitions compared to the widespread popularity of
> both hackathons and CTFs.)

You might find https://cr.yp.to/papers.html#competitions useful.

---D. J. Bernstein

[Arne Padmos]

Hi Dan,

> https://competitions.cr.yp.to/caesar-submissions.html explicitly lists
> all designations provided by the committee. For example, the final
> CAESAR portfolio includes Ascon as "first choice for use case 1".

So, where the Ascon specs submitted to the NIST LWC competition state

'the authenticated ciphers Ascon-128 and Ascon-128a, which have been
selected as primary choice for lightweight authenticated encryption in
the final portfolio of the CAESAR competition'
and
'both schemes are identical to the CAESAR candidates selected as primary
choices for lightweight use-cases in the final CAESAR portfolio'

the specs should actually state something more along the lines of 'The
Ascon family -- at the time only consisting of Ascon-128 and Ascon-128a
-- was selected over ACORN for lightweight applications. The CAESAR
committee has not provided any other designations, such as whether one
parameter set of Ascon is preferable over the other parameter set, or
whether both parameter sets are equally preferable.'?

Regards,
Arne

PS. On (cryptographic) competitions:

> You might find https://cr.yp.to/papers.html#competitions useful.

Thank you for sharing. I was aware of this paper and it was a valuable
read (although I hadn't read the reviewer comments until now). One thing
not included in your paper that you might find relevant is that there
are indications that GCHQ and NSA ran a competition around the end of
the 1960s or beginning of the 1970s to pick an algorithm for use in the
VINSON tactical radio (which could place it before the DES competition).
The Crypto Museum's page on SAVILLE includes the following snippet:

'At the time, two teams were formed to develop a new cryptographic
algorithm: one at the NSA and one at GCHQ. At GCHQ, WWII cryptanalist
Michael Crum was involved in the project. Both teams produced algorithms
which were then rigorously analysed by the other agency. In the end, the
GCHQ algorithm was accepted as the better one and became known as
SAVILLE. In most literature however, SAVILLE is commonly attributed to
the NSA.'

While this information doesn't really show up in other public documents
and isn't described in Dickie George's USENIX Security 2012 keynote,
there are some indicators that at least make this story plausible. The
Friedman papers show how BRUSA/UKUSA encouraged exchange of descriptions
of 'cryptologics' and their analysis back in the 1950s (e.g. see the
UKUSA C/S series, such as UKUSA C/S 651 'Comments on AFSAY D802'), as
well as various discussions on what algorithms/machines to use for NATO
communications (e.g. leading to TSEC/KL-7 devices -- aka AFSAM-7 --
using an ADONIS or POLLUX system).

Also, although most of pages 157 to 159 of 'American Cryptology during
the Cold War Book 3' discussing US collaboration with Great Britain is
blank, some hints remain. There is a description that 'collaboration
remained almost total' and 'the key decisions that kept the two
countries closely tied related generally to advances into new
technological realms'. The index on pages 453 to 494 of Book 4 shows
that page 158, which is completely blank in Book 3, includes a
discussion of at least the following topics: FLR-9 (project name),
Hagelin, Saville, and Vinson (communications device).

Other sources offering morsels of information are the report 'A major
COMSEC challenge: secure voice' in Cryptologic Spectrum of Fall 1974 and
the 'Coverterms' article in Cryptolog of April 1975. The former source
notes that the cryptoprinciple of NESTOR was developed in the 1950s, and
that VINSON offers 'improved security through the use of a new
cryptoprinciple; [redacted]'. The latter source notes that 'two-syllable
surnames are reserved for research and engineering projects, [redacted]'
(which seems to match the SAVILLE covername).

For general background information on this time period, see the Boak
lectures. Boak's volume 1 is an insightful read next to Anderson's 'Why
cryptosystems fail' paper. Boak's volume 2 illustrates a shift from a
vulnerability-centric perspective to threat-centric thinking -- where
threats are defined as 'demonstrated hostile capabilities, intentions,
and/or successes against U.S. communications'. Both volumes include
interesting stories related to implementation security, e.g. how in the
late 1950s an early model of the NESTOR/KY-8 tactical voice equipment
turned into a pumpkin due to the failure of a tiny component -- spitting
out repetitive keystream without any visible errors -- which 'triggered
a full-scale and continuing pre-occupation with the science of failure
analysis'. Another interesting story is how Bell Telephone engineers
discovered the TEMPEST problem in 1943, after which 'the whole problem
was plain forgotten' until in 1951 it was 'for all practical purposes,
rediscovered by CIA when they were toying with the same old 131-B2
mixer'.

Long story short, while there isn't yet a lot of information available
related to SAVILLE -- assuming that the competition as described
actually took place and if additional information becomes available in
the future -- it might provide an interesting complementary perspective
to the limited number of public cryptographic competitions. Concretely,
the SAVILLE case study might provide further ideas on how competitions
could be structured. Additionally, in case similar dynamics and pitfalls
have been observed, this would argue for their generalisability.

Of course, there are also more distant sources for potential insights
such as examples from the area of architectural competitions, as well as
the design competitions running until 1992 between Los Alamos and
Livermore for nuclear weapon designs as described by a 2015 report from
the National Academies of Sciences (besides this history the report also
includes controversial recommendations to resume such competitions). In
his Security Engineering book, Anderson provides the example of 'the
evaluation of nuclear command and control, where Sandia National
Laboratories and the NSA vied to find bugs in each others designs' and
the example of 'IBM, which maintained a leading position in cryptography
for years by having two teams, one in New York and the other in North
Carolina, who would try to break each others work' (unfortunately no
citations are provided for either example).

Besides case studies, another potential avenue is 'laboratory' studies
where students are engaged in an engineering design competition such as
Fulton et al.'s work presented at CCS 2022, Vorobeychik et al.'s Fireaxe
pilot competition from 2012, and MITRE's eCTF which launched in 2016.
However, note that none of these student competitions include both a
design and evaluation component combined with winnowing of candidates
over multiple rounds leading to outputs with relevance outside of the
lab or ivory tower. While the DESSEC workshop organised by I3P in 2010
explored the potential of engineering design competitions as a vehicle
for driving fundamental security research, in my view adversarial
engineering design competitions are better suited as vehicles for
assured technology transfer as they combine design research and
incentives design. Also, while Bishop described 'a design for a
collaborative make-the-flag exercises' in 2018, his paper discounts the
utility of an adversarial setup and the exercises provided as examples
remain mostly didactic.

In case anyone would like to perform such studies to get a better grasp
of competition dynamics, here are some initial random ideas to try, for
example as a capstone project at a university of applied sciences: how
might we trickle write-once-read-many technologies available to large
businesses (see NIST SP 1800-11 for more details) down to SMEs in a
usable package to enable ransomware-resilient backups; how might we turn
the principle of data diodes into a usable, rugged, and affordable
solution to enable sharing of monitoring data from industrial automation
and control systems, while shielding them from harm; how might we enable
safe changes to morphine pump dosage for palliative care without
requiring a nurse to travel to people's homes while they're in pain.
(Bonus points for thinking up other challenges which would naturally
require participants to exercise cryptography engineering skills in such
a way that current protocol standards and design principles could be
pitted against 'protocol design toolkits' such as Strobe and Cyclist.
Interestingly, NISTIR 7977 notes that usability is one of the principles
that guide NIST's cryptographic standards and guidelines development
processes, stating that standards and guidelines should be chosen to
minimise the demands on users and implementers as well as the adverse
consequences of human mistakes and equipment failures. However, I
haven't yet seen any study that asked a representative group of embedded
systems engineers to implement a prototype on a microcontroller based on
different cryptographic building blocks provided by any of the LWC
finalists, or even a lightweight think-aloud study with students
following an embedded software engineering degree to get some rough
ideas about the potential pitfalls of (not) making certain
parameters/modes/functionality available to embedded engineers.)