Announcement of NIST public workshop in June 2024

[Dworkin, Morris J. (Fed)]

Please see NIST’s announcement for the “Accordion Cipher Mode Workshop 2024” at

https://csrc.nist.gov/Events/2024/accordion-cipher-mode-workshop-2024 .

 

Morris Dworkin

On behalf of the NIST Cipher Modes Team

 

[Tushar Patel]

We here at ATNA-CIPHER, LLC. are working on a cipher-mode and would like to submit the cipher-mode for evaluation for the accordion mode.

It has the following

1. It defines Coeval Authenticated Encryption (CAE) as a new form of Authenticated Encryption and complies as CAEAD over AEAD based on its properties.

2. It is a CTR-mode, wide-block tweakable cipher-mode and design to support block sizes larger than 128-bits.

I am attaching a design summary of features and the Mode of Operations is previously published at atnacipher.com (and attached).

Please advise if this might fit the definitions for the accordion mode and  it does involve a PCT patent and guidance and clarification from NIST relating to patents and protected works patents might be  helpful.

Thx.,

Tushar J. Patel

Lead-Architect: ATNA-CIPHER,  LLC.

[Tushar Patel]

Attachments

[Arne Padmos]

> Please advise if this might fit the definitions for the accordion mode

Hard to tell without a detailed technical specification (which is a big red flag in itself). However, going by the mention that a "32-byte tag is necessary for decryption" and the statement that the mode is CTR-based, my guess would be no.

Note that the panel at the Third NIST Workshop on Block Cipher Modes of Operation 2023 already included a sketch of the interface of an accordion mode by Rogaway:

https://csrc.nist.gov/csrc/media/Presentations/2023/panel-lessons-learned/images-media/sess-4-panel-bcm-workshop-2023.pdf#page=23

Also, the announcement is very clear in describing an accordion mode as 'a tweakable, variable-input-length-strong pseudorandom permutation'.

> it does involve a PCT patent and guidance and clarification from NIST relating to patents and protected works patents might be helpful

Luckily NIST has provided a detailed description of how they handle the issue of intellectual property in NIST IR 7977, including this note:

"While developing its cryptographic standards and guidelines for non-national security systems, NIST has noted a strong preference among its users for solutions that are unencumbered by royalty-bearing patented technologies."

Of course, patents are great if they hamper adoption of insecure modes of operation (e.g. see https://eprint.iacr.org/2019/311), but less great if they lead to compatibility problems (e.g. see PGP 2 vs 3+).

Op zaterdag 30 maart 2024 om 02:31:45 UTC+1 schreef Tushar Patel:

[Arne Padmos]

Hi Tushar,

In response to your off-list message asking for further clarification to my comments, see the points below (the other messages you posted to the forum do not appear related to the technical points raised).

From your initial description, it seems like a separate tag is needed for decryption. Regarding the statement that the "MAC is 32, 24 and 16 to be exact", is length-preserving encryption for things like full-disk encryption also supported? If so, how do bit flips propagate upon encryption and decryption? Said differently, does redundancy in plaintext anywhere in the input enable integrity control? (While XTS is tweakable -- although only with a tweak of 128 bits -- it doesn't provide this property as the propagation of changes is limited to individual blocks. As emphasised in the feedback provided in the review of SP 800-38E, XTS also has the footgun of using equal subkeys. Other XTS implementation errors that have been observed in the wild include reuse of tweaks and the use of primitive elements not equal to 0...10. Although AES-KW does provide full propagation, it isn't tweakable, isn't length preserving, is quite inefficient, and is limited in the integrity guarantees it provides due to a maximum specified padding length of eight 0xA6 bytes. NIST IR 8459 highlights some of these issues as well as other real-world problems, plus providing useful background references.)

As to my reference to counter mode: this was in relation to the mode appearing to generate an IV and keystream separate from plaintext processing, as a single-pass mode doesn't provide nonce-misuse resistance (e.g. see https://doi.org/10.1049/ise2.12110, "NMRE [...] inherently requires off‐line, two‐pass computation"). Of course, there are modes like GCM-SIV that use CTR mode internally.

Based on a very very cursory glance, multiple ideas appearing in the WO2023150248A1 patent seem to already be in use elsewhere to work around issues with existing modes of operation. What is surprising is that the patent seems to have zero inline references to related work. Some previously published techniques that have also been applied in practice that may be prior work to things described in the patent:

- Amazon has published an instantiation of the CES-GCM mode that uses HMAC-SHA256 to derive an AES-256 key from a 256-bit secret and a 128-bit nonce, with a 96-bit IV for GCM generated separately (https://doi.org/10.3390/cryptography3030023), later adding key commitment as well (see https://aws.amazon.com/blogs/security/improved-client-side-encryption-explicit-keyids-and-key-commitment/ and https://eprint.iacr.org/2020/1153.pdf).

- In their feedback on the FIPS-197 review, Microsoft has noted that they forbid random IV generation for AES-GCM. The presentation from Amazon at last year's modes workshop goes into the CES-GCM approach sketched above as well as the alternative approach of prefixing a monotonic counter with a device ID. (The aspect of domain separation in the time dimension described in the patent doesn't seem much different from domain separation in the space dimension, let alone approaches such as TOTP described in RFC 6238 back in 2011.)

- The use of key trees in DUKPT to enable forward security on payment terminals while allowing efficient decryption on the HSM/server side without keeping state like in the much less well-known Racal UKPT. For more details on DUKPT, see section 2.2 of https://doi.org/10.1007/978-3-642-17373-8_15 and/or the companion slides at https://thomaspeyrin.github.io/web/assets/docs/slides/Brier-Peyrin-ASIACRYPT2010_slides.pdf#page=15, and some related tooling available at https://github.com/openemv/dukpt.

This may be my personal bias speaking, but I think that a patented mode lacking a complete public description doesn't deserve further time and energy from the community, especially when the entity promulgating such a mode is spreading FUD about "hurdled chaos" resulting from AES-128 being broken by a quantum computer, while looking to achieve "cyber infrastructure unicorn status" (both quotes from the ATNA Cipher-Mode Business Plan Summary document).

Regards,
Arne

Op dinsdag 2 april 2024 om 17:52:03 UTC+2 schreef Arne Padmos:

[Tushar Patel]

Hi Arne,

I read the Accodion mode requirement and a 10 minute presentation does not require a full implementation.

1. (AP)From your initial description, it seems like a separate tag is needed for decryption. Regarding the statement that the "MAC is 32, 24 and 16 to be exact", is length-preserving encryption for things like full-disk encryption also supported?...

[TJP] -  These are some basic notes from the Mode Of Operations Abstract Section 4. (Note: The reference to non-secure hash is a CTR block style mask, however, it is random bit based e-mask, FDT is 64-bit or 128 bit., Mask is 16, 24 or 32 ( I can very support shorter sizes, however, in correctness of the 64-bit deprecation, the minimum I have designed in is 128-bits.

ATNA by design has the added benefit that encryption data elements >= 16 can benefit from the size-preserving properties of ATNA if implementation retain the integrity tag (or FDT at least) and hence, available at decryption. Methods also support the use of fixed elements to simplify such retention. Implementations can store individual MACs in case such storage is efficient or store the cumulative final MAC. The MAC is also a tokenized or pseudonym representation (non-secure hash) of the data. One application is to store this in a permanent store archive and pass it for decryption on or off the permanent store (HSM.) This is different than CTR which is not coeval authenticated and requires HMAC/CMAC for non-coeval authentication.

**Comparative to AES-FF1 and AES-FF2, there is not format preserving, however, size preserving (>= 16), however, the output is a unique token (32-bytes) that must be available when decrypting. Please note that ATNA does address the issue requiring minimum entropy in the data fields (e.g., AES-FF1 would leak data on data elements < 1,000,000 in entropy.) This is essential for database type applications where the column records of a fixed size. The 32-byte tag is necessary for decryption. There is no secrecy required for the tag.

Note: Though not exact format preserving, it is easy to map combinations of 16-byte fields for format preservations.

Disk encryption takes many forms, nothing stops an implementation from reserving some bytes of a sector, set of blocks, files, directories, etc. for a tag. From what designs say you have to perform a FIPS integrity check anyway, hence, the tag serves it's purpose accordingly.

I hope you don't expect me to make the mistake of AES-KW or XTS in a next gen cipher, by the way, my past experience involves working with some of the best mentors who are both leading edge developers and pioneers in these areas.

   

2. (AP)As to my reference to counter mode: this was in relation to the mode appearing to generate an IV and keystream separate from plaintext processing, as a single-pass mode doesn't provide nonce-misuse resistance (e.g. see https://doi.org/10.1049/ise2.12110, "NMRE [...] inherently requires off‐line, two‐pass computation"). Of course, there are modes like GCM-SIV that use CTR mode internally.

[TJP] - We have addressed this in a very novel way, again, the design has an embedded FIPS check that prevents nonce misuse and leads to failed encryption, that essentially is the purpose of Coeval Authenticated Encryption. We support speculative decryption (integrity and encryption in same pass optionbally) and is one pass decryption.

 

3a (AP) - Amazon has published an instantiation of the CES-GCM mode that uses HMAC-SHA256 to derive an AES-256 key from a 256-bit secret and a 128-bit nonce, with a 96-bit IV for GCM generated separately (https://doi.org/10.3390/cryptography3030023), later adding key commitment as well (see https://aws.amazon.com/blogs/security/improved-client-side-encryption-explicit-keyids-and-key-commitment/ and https://eprint.iacr.org/2020/1153.pdf).

[TJP]  - PLease refer to my previous patent work   11088838

3b. (AP) - In their feedback on the FIPS-197 review, Microsoft has noted that they forbid random IV generation for AES-GCM. The presentation from Amazon at last year's modes workshop goes into the CES-GCM approach sketched above as well as the alternative approach of prefixing a monotonic counter with a device ID. (The aspect of domain separation in the time dimension described in the patent doesn't seem much different from domain separation in the space dimension, let alone approaches such as TOTP described in RFC 6238 back in 2011.)

TJP]   - There are many ways to solve problems, my approach has some unique elements and does not mandate the use a monotonic CTR or a device id, though you could use them, we have a much different and alternate approach.

3c. (AP) - The use of key trees in DUKPT to enable forward security on payment terminals while allowing efficient decryption on the HSM/server side without keeping state like in the much less well-known Racal UKPT. For more details on DUKPT, see section 2.2 of https://doi.org/10.1007/978-3-642-17373-8_15 and/or the companion slides at https://thomaspeyrin.github.io/web/assets/docs/slides/Brier-Peyrin-ASIACRYPT2010_slides.pdf#page=15, and some related tooling available at https://github.com/openemv/dukpt.

[TJP]  Key Trees are fundamental in ciphering, the atnaCM approach is much different than the usual key tree and suppports specialized  pre-processing and auto-keying, from your experience you may have faced the issues when refreshing keys (hurdled chaos) in the multi-channel pipe and we are attempting designs to address that challenge for the 1,2 Billion Pkts/sec (or more) market .

Thank you for your clear indication, however, here is my stance 

his may be my personal bias speaking, but I think that a patented mode lacking a complete public description doesn't deserve further time and energy from the community, especially when the entity promulgating such a mode is spreading FUD about "hurdled chaos" resulting from AES-128 being broken by a quantum computer, while looking to achieve "cyber infrastructure unicorn status" (both quotes from the ATNA Cipher-Mode Business Plan Summary document).

1. I have passed every single FIPS-CC and UCAPL (now DoD in APL) certification covering almost all of such systems, however, it is when you have a closed mind audience, there is not much we developers can do, personally, you can ask any one who has worked with me, if I have tried to sell grease.

2. My original questions was a precursor to releasing specifications.

3. The FUD is from NIST regarding 128-bit AES and this is the experts viewpoint not mine, isn't that why Accordion considers Rijndael-256 as a fute path.

4. If you look at the Market potential of the atnaCM cipher-mode possible with Cisco, Juniper, Broadcom, Hitachi, HP, Arista and others, what would you expect to achieve. By the way, if you every read my DoD I2O submission, you would have known my take in it, more of an Manager/Architect/Security Advisor/Lead doing good work. By the way, if you read the return of the AES cipher published by NIST a few years ago, you wouldn't doubt unicorn status in a capitalist country.

Just my two cents and really not sure who's wasting who's time.

Thanks,

Tushar

--
To unsubscribe from this group, send email to ciphermodes-fo...@list.nist.gov
 
View this message at https://list.nist.gov/ciphermodes-forum
To unsubscribe from this topic, visit https://groups.google.com/a/list.nist.gov/d/topic/ciphermodes-forum/2n3Kz6l85sE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ciphermodes-fo...@list.nist.gov.