Re: Digest for ciphermodes-forum@list.nist.gov - 1 update in 1 topic

[Tushar Patel]

I took a look at the "Proposal of Requirements for an Accordion Mode" and noticed some ambiguity.

Pre-cursors.

I read the 3 reference papers and noticed that the full version of paper[19] has the proof, though, it applies; in correctness a standardization should be open and not based on pre-published paper as this sets in a pre-bias and curtails innovation.

1. In Section 2.2, the method does not clarify the exact semantics of the Random Permutation when "b=1", from a simple justification, using an approved SP800-90 random method, the theoretical probability of a 1 or 0 is at 50% for each, hence any variation comes from b=1, here the permutation operator and it's inverse require some clarifications as it is ambiguous; this is more so in an implementation that is not based on the mentioned paper. Also, symbols cannot be searched in documents, hence, it a bit confusing, by convention, usually, NIST specifications, provide all the symbol definitions in the glossary.

2. Another ambiguity in section 2.2 s do you want a theoretical proof or the actual program and results? we have a few days to complete as May 1st is the submission deadline, and it would be a close call to complete these plus the presentations, also, for the theoretical results, they are already there in S. Halevi and P. Rogaway's full paper, hence, not sure what the ask is. 

Finally, you mention a tweak size in bits, however, it is known that most disk or storage encryption work in powers of two and most blocks ciphers will be multiple of 128-bits (unless we are considering moving away from binary system/hex radix operations), hence, given this, the best approach would be to define a) The standard for tweaks to be multiples of 128-bits (applies to 256-bits blocks also)  and b) implementations can define their padding requirements, this also in consistent with VIL-SPRP that defines tweak blocks as it already is limited to a minimum of two cipher blocks. (atnaCM  has already factored this in its implementation  and specification) and b) the HW complexity relating to variable-bit support otherwise would be too complex (if you try parallel implementations, in practical reality, it will only achieving pipelining in key-schedules and AES 126-bit or Rijndael-256 block stages.) , using suggestion a. just above allows much better design (we can present some highlights without discussing implementation details of atnaCM if there is interest and other can do the same too within this short 15 day May 1st window.)

Tushar Patel.

On Wed, Apr 10, 2024 at 6:25 PM <ciphermo...@list.nist.gov> wrote:

ciphermo...@list.nist.gov

Google Groups

Topic digest
View all topics

• NIST workshop discussion draft on accordion mode requirements - 1 Update

NIST workshop discussion draft on accordion mode requirements

"Dworkin, Morris J. (Fed)" <morris....@nist.gov>: Apr 10 07:40PM NIST’s Proposal of Requirements for an Accordion Mode has been posted on the NIST website in the form of a “Discussion Draft for the NIST Accordion Mode Workshop 2024” at https://csrc.nist.gov/pubs/other/2024/04/10/proposal-of-requirements-for-an-accordion-mode-dis/iprd .   Morris Dworkin On behalf of the NIST Cipher Modes Team.

Back to top

You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to ciphermodes-fo...@list.nist.gov.