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

[Tushar Patel]

Please consider the cases of  

1. IPsec, ESP framing 

2. MACSec

2. There are some more issues that impact this understanding and have factored solutions into some of my work ( not public at least for now) 

4. The last item is that science and technology should not place restrictive upper limits, they can instead set a minimum threshold over which implementations can exceed, this way, there is constant room for improvement. 

5. Though, we have to support it for some foreseeable time, TLS is more of a cybersecurity protocol these days than real cryptographic security ( both are essential), however, multicast, VxLAN , SNMPv3/DNSSec over TLS, PKI/X.509 etc., and path to path mtu ( IPsec ( the bit based more fragments and MACSec ( the lack of jumbo frame, also) are a cummulative  nightmare.

6. The right solution cryptographically must be PRF-PRP based and not either PRF or PRP

7. Considering the backup of a massively distributed data center we are just growing storage exponentially even though the mean failure ratio is rarely over 3 or 4 consecutive at the most worst case ( used to be 2 disks in 10 years, haven’t verified the latest numbers) while creating an artificial market for bandwidth based IOPS cost generation, also, as we get to 8k mainstream lossless/low jitter video, huge AI globally backed training sets, it will be messy, here, we can all be better engineers and prevent making digital dinosaurs of ourselves. As to the revenue loss, money would just translate from IOPS and other bandwidth/storage costs to new equipment and innovative solutions, though we will have pitfalls. Estimating a good chunk of the current 200B+ US$ for the next few years globally until QC would be wasted if we don’t act fast.

Finally, I think we are stiffling solutions with both the ANNSI and maybe NIST restrictions where alternatively, we can work together with them to address their concerns. I had several goes with GCM at the accreditation labs and after working with solutions for a few years, I can say they are not unfounded, however most people do not have the resources or time to reach beyond the safe limit line which is working to all our benefits, however, it is a doomed if we do or don’t on the issue.

Sincerely,

Tushar 

On Thu, Feb 6, 2025 at 6:21 PM <ciphermo...@list.nist.gov> wrote:

ciphermo...@list.nist.gov

Google Groups

Topic digest
View all topics

• Planned revision of NIST SP 800-38D - 1 Update

Planned revision of NIST SP 800-38D

John Preuß Mattsson <john.m...@gmail.com>: Feb 06 03:10AM -0800 Hi Morris,   I did some further thinking on distinguishing attacks on block ciphers in counter mode and how they are related to plaintext-recovery attacks.   I could not find any results for how small fraction of a bit an attacker can actually recover from a PRP in counter mode, so I calculated a formula for that and published on IACR ePrint, see Section 4 of [1].   As far as I can see, the entropy loss of a pseudorandom permutation (PRP) in counter mode, which corresponds to the amount of information an attacker can theoretically recover is σ^2 / 2^b / ln 4 where σ is the number of encrypted blocks and b is the block size.   When σ = 2^(b/2), an attacker can theoretically recover up to ≈ 1 / ln 4 ≈ 0.721 bits of plaintext. When b = 128 and σ ≤ 2^35 as required for AES-GCM in QUIC, an attacker can theoretically recover up to ≈ 1 / 2^58.47 bits of the plaintext.   The limits in TLS 1.3, DTLS 1.3, and QUIC appear to be far stricter than necessary. There is no universally agreed-upon threshold for how much information an attacker must recover for it to constitute a meaningful attack. However, protecting against the recovery of 1 / 2^58.47 bits, a practically negligible fraction, seems overly cautious and unlikely to be a realistic threat.   I agree with the conclusion in NIST IR 8459 that the key must be changed well before encrypting 2^(b/2) blocks of data. I recommend that NIST aligns with ANSSI [2] by requiring that the maximum number of encrypted blocks under the same key must not exceed 2^(b/2 - 5). This appears to be a well-thought-out and balanced requirement, effectively limiting the amount of plaintext an attacker could recover to ≈ 1 / 2^10.47 ≈ 0.0007 bits. For global companies it is very important with alignment between NIST, ANSSI, BSI, Swedish NCSA etc. I do not think NIST should align with (D)TLS 1.3 and QUIC.   We are planning to include the above in in our official comments on SP 800-38D that NIST has requested by March 14 [3].   Cheers, John Preuß Mattsson Expert, Cryptographic Algorithms and Security Protocols, Ericsson   [1] https://eprint.iacr.org/2024/1111.pdf [2] https://cyber.gouv.fr/sites/default/files/2021/03/anssi-guide-mecanismes_crypto-2.04.pdf [3] https://csrc.nist.gov/News/2025/pre-draft-call-for-comments-on-gcm-and-gmac On Monday, January 27, 2025 at 4:56:01 PM UTC+1 Dworkin, Morris J. (Fed) wrote:

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.