Ascon (cipher): Difference between revisions

From testwiki
Jump to navigation Jump to search
imported>Frap
m Hyphen to dash for ranges
 
(No difference)

Latest revision as of 10:53, 27 November 2024

Template:Short description Template:Other uses Template:Infobox encryption method

Ascon is a family of lightweight authenticated ciphers that had been selected by US National Institute of Standards and Technology (NIST) for future standardization of the lightweight cryptography.Template:Sfn

History

Ascon was developed in 2014 by a team of researchers from Graz University of Technology, Infineon Technologies, Lamarr Security Research, and Radboud University.Template:Sfn The cipher family was chosen as a finalist of the CAESAR CompetitionTemplate:Sfn in February 2019.

NIST had announced its decision on February 7, 2023Template:Sfn with the following intermediate steps that would lead to the eventual standardization:Template:Sfn

  • Publication of NIST IR 8454 describing the process of evaluation and selection that was used;
  • Preparation of a new draft for public comments;
  • Public workshop to be held on June 21–22, 2023.

Design

The design is based on a sponge construction along the lines of SpongeWrap and MonkeyDuplex. This design makes it easy to reuse Ascon in multiple ways (as a cipher, hash, or a MAC).Template:Sfn As of February 2023, the Ascon suite contained seven ciphers,Template:Sfn including:Template:Sfn

  • Ascon-128 and Ascon-128a authenticated ciphers;
  • Ascon-Hash cryptographic hash;
  • Ascon-Xof extendable-output function;
  • Ascon-80pq cipher with an "increased" 160-bit key.

The main components have been borrowed from other designs:Template:Sfn

  • substitution layer utilizes a modified S-box from the Template:Mvar function of Keccak;
  • permutation layer functions are similar to the Σ of SHA-2.

Parameterization

The ciphers are parameterizable by the key length k (up to 128 bits), "rate" (block size) r, and two numbers of rounds a, b. All algorithms support authenticated encryption with plaintext P and additional authenticated data A (that remains unencrypted). The encryption input also includes a public nonce N, the output - authentication tag T, size of the ciphertext C is the same as that of P. The decryption uses N, A, C, and T as inputs and produces either P or signals verification failure if the message has been altered. Nonce and tag have the same size as the key K (k bits).Template:Sfn

In the CAESAR submission, two sets of parameters were recommended:Template:Sfn

Suggested parameters, bits
Name k r a b
Ascon-128 128 64 12 6
Ascon-128a 128 128 12 8

Padding

The data in both A and P is padded with a single bit with the value of 1 and a number of zeros to the nearest multiple of Template:Mvar bits. As an exception, if A is an empty string, there is no padding at all.Template:Sfn

State

The state consists of 320 bits, so the capacity c=320r.Template:Sfn The state is initialized by an initialization vector IV (constant for each cipher type, e.g., hex 80400c0600000000 for Ascon-128) concatenated with K and N.Template:Sfn

Transformation

The initial state is transformed by applying Template:Mvar times the transformation function Template:Mvar (pa). On encryption, each word of A || P is XORed into the state and the Template:Mvar is applied Template:Mvar times (pb). The ciphertext C is contained in the first Template:Mvar bits of the result of the XOR. Decryption is near-identical to encryption.Template:Sfn The final stage that produces the tag T consists of another application of pa; the special values are XORed into the last Template:Mvar bits after the initialization, the end of A, and before the finalization.Template:Sfn

Transformation Template:Mvar consists of three layers:

Test vectors

Hash values of an empty string (i.e., a zero-length input text) for both the XOF and non-XOF variants.[1]

Template:Color
0x 7346bc14f036e87ae03d0997913088f5f68411434b3cf8b54fa796a80d251f91
Template:Color
0x aecd027026d0675f9de7a8ad8ccf512db64b1edcf0b20c388a0c7cc617aaa2c4
Template:Color
0x 5d4cbde6350ea4c174bd65b5b332f8408f99740b81aa02735eaefbcf0ba0339e
Template:Color
0x 7c10dffd6bb03be262d72fbe1b0f530013c6c4eadaabde278d6f29d579e3908d

Even a small change in the message will (with overwhelming probability) result in a different hash, due to the avalanche effect.

Template:Color
0x 3375fb43372c49cbd48ac5bb6774e7cf5702f537b2cf854628edae1bd280059e
Template:Color
0x c9744340ed476ac235dd979d12f5010a7523146ee90b57ccc4faeb864efcd048

See also

References

Template:Reflist

Sources

Template:Cryptography navbox


Template:Cryptography-stub