blocks|key|855132|text|type|unstyled|depth|inlineStyleRanges|entityRanges|data|entityMap^0^^$0|@$1|2|3|-4|4|5|6|B|7|@]|8|@]|9|$]]]|A|$]]

<blockquote>
<ol>
<li>Is there an official document that states, that using a random IV for a fixed key is a valid approach (not just a so answer :))</li>
</ol>
</blockquote>
The <a href="https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-38a.pdf" rel="nofollow noreferrer" title="Recommendation for Block Cipher Modes of Operation - 2001 Edition ">NIST 800-38a</a> states what you need and remember the problem occurs when $(key,IV)$ pair is reused, or more precisely say under the same key any $(IV||counter)$ combination. The latter can happen if random IV is used then under the same key, two messages collide in different positions.
Two approaches are given in 800-38a
<ol>
<li>Sequential generation</li>
</ol>
<blockquote>
In the first approach, for a given key, all plaintext messages are encrypted sequentially. Within the messages, the same fixed set of $m$ bits of the counter block is incremented by the standard incrementing function. The initial counter block for the initial plaintext message may be any string of $b$ bits. The initial counter block for any subsequent message can be obtained by applying the standard incrementing function to the fixed set of $m$ bits of the final counter block of the previous message. In effect, all of the plaintext messages that are ever encrypted under the given key are concatenated into a single message; consequently, the total number of plaintext blocks must not exceed $2^m$. Procedures should be established to ensure the maintenance of the state of the final counter block of the latest encrypted message and to ensure the proper
sequencing of the messages.
</blockquote>
In short, one continues where the counter left+1 not counter exceeding the $2^m$
<ol start="2">
<li>With Nonce</li>
</ol>
<blockquote>
A second approach to satisfying the uniqueness property across messages is to assign to each message a unique string of $b/2$ bits (rounding up, if $b$ is odd), in other words, a message nonce, and to incorporate the message nonce into every counter block for the message. The leading $b/2$ bits (rounding up, if $b$ is odd) of each counter block would be the message nonce, and the standard incrementing function would be applied to the remaining $m$ bits to provide an index to
the counter blocks for the message. Thus, if $N$ is the message nonce for a given message, then the $j$th counter block is given by $T_j = N || [j]_m$ , for $j = 1…n$. The number of blocks, $n$, in any message must satisfy $n &lt; 2^m$. A procedure should be established to ensure the uniqueness of the message nonces.
</blockquote>
In short, this is the nonce is incremented per message.
There is no mention of random generation in this document it is an old document too. In AES-GCM <a href="https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-38d.pdf" rel="nofollow noreferrer">NIST 800-38d</a>, it is either random nonce or incremental nonce with counter/LFSR is advised, remember AES-GCM uses CTR mode with a combination of a 92-bit nonce 32-bit counter. 92-bit nonces are safer to use in random than 64 bit IVs since the collision probability is low.
We simply approximate the collision probability by the square root for 50%. Therefore we can say 64-bit random nonces have 50% collision probability after $2^{32}$ unifrom random nonce generation. Actually, in the adversary sense, this is not negligible one must stop way earlier. In the case of 96-bit, one needs to generate uniform random $2^{48}$ nonces to hit 50% and the same adversary approach should be taken. To see more detail about the collision see <a href="https://crypto.stackexchange.com/a/39644/18298">Birthday problem for cryptographic hashing, 101.</a> by fgrieu.
<blockquote>
<ol start="2">
<li>If not, do you think, that this approach is valid?</li>
</ol>
</blockquote>
Since your key never changes there is a 50% collision probability after encrypting $2^{32}$ messages and you will hit the (key,IV) reuse problem, the more you encrypt the more you will have.
As I can see, your compatibility is CTR not how it is used. You can either use sequential IV as in GCM's suggestions that will enable you to encrypt up to $2^{64}$ messages under the key or remove the device identifier for the IV and use random generation under which you will get a collision with 50% probability after encrypting $2^{48}$ messages.
<blockquote>
The first statement would only be true, if just the IV changes for every encrypted 16-byte block. However the IV only changes on reboot and block counter overflow. One more note: there is a 10s delay after a reboot, so generating new 64-bit IV this way, it would take (2^32 * 10s) / ( 60 * 60 * 24 * 365)s = 1360 years to reach the 2^32 messages. But it would indeed be an option to increase the IV by 2 bytes by reducing the block counter to 2 bytes.
</blockquote>
<blockquote>
you said I get a 50% collision after 2^32 messages. Did you consider the 32-bit block counter?
</blockquote>
That is depending on how the counter is used there it is assumed that the nonce is used only once.
<blockquote>
The first statement would only be true, if just the IV changes for every encrypted 16-byte block. However the IV only changes on reboot and block counter overflow. One more note: there is a 10s delay after a reboot, so generating new 64-bit IV this way, it would take (2^32 * 10s) / ( 60 * 60 * 24 * 365)s = 1360 years to reach the 2^32 messages. But it would indeed be an option to increase the IV by 2 bytes by reducing the block counter to 2 bytes.
</blockquote>
<blockquote>
The message size is 1 to 3 blocks (16 bytes), there are different messages, but a lot of them repeat over and over.
</blockquote>
In this way, you can use the counter up to $2^{32}/3 \approx 2^{28}$ messages without changing the IV. One should note that to use this you need to store the last used position +1 on the system.
System failures
During the system failures, one may fail to store it correctly and this can cause reuse of the olf position. In this case, a new nonce generation is suggested and since this requires already a reboot then there is no problem here.

I want to use AES CTR with a random IV, as this would be the easiest way for me. I have a cryptographic module, that supports true random number generation. Due to compatibility, I must use AES CTR. The module also supports a monolithic counter, but its max value is quite low and might be too low for my use-case.
<a href="https://www.rfc-editor.org/rfc/rfc3686#section-3.1" rel="nofollow noreferrer">RFC 3686</a> states the following:
<a href="https://i.stack.imgur.com/9ZmLP.png" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/9ZmLP.png" alt="enter image description here" /></a>
I must ensure that the IV never repeats, which is not true for a random number, as it could repeat. My key does not change.
I found <a href="https://stackoverflow.com/questions/4608489/how-to-pick-an-appropriate-iv-initialization-vector-for-aes-ctr-nopadding">this thread</a> on so that states, that using a random number (128 bit in this case) is an easy way to do it, as collisions are very unlikely.
My counter block would consist of only 64 bits of random (IV), 32 bytes would be reserved for the block counter, and 32 bytes for a static device identifier (Nonce). The generation of a new random IV would only occur on device restart and block counter overflow, both events occur rather rarely. This minimizes the possibility of a collision drastically, however, a chance remains.
<a href="https://i.stack.imgur.com/WDPuk.png" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/WDPuk.png" alt="enter image description here" /></a>
My questions are:
<ol>
<li>Is there an official document that states, that using a random IV for a fixed key is a valid approach (not just a so answer :))</li>
<li>If not, do you think, that this approach is valid?</li>
</ol>
Thanks in advance and best regards

AES CTR: Random IV

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云AI代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

功能1上新10个字符

功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符。

功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符。

功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符

功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符

功能4上新

文章&问答评论现已支持表情

全新交互，全新视觉，新增快捷键、悬浮工具栏、高亮块等功能并同时优化现有功能，全面提升创作效率和体验

社区富文本编辑器全新改版！诚邀体验～ 

精选全网热门MCP server，让你的AI更好用 🚀

💥开发者 MCP广场重磅上线！

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

我想使用AES CTR与随机IV，因为这将是最简单的方式对我。我有一个密码模块，它支持真正的随机数生成。由于兼容性，我必须使用AES CTR。该模块还支持单片计数器，但是它的最大值很低，对于我的用例来说可能太低了。RFC 3686声明如下：📷我必须确保IV永远不会重复，这对于随机数是不正确的，因为它可以重复。My键不会改变。我在这条线上发现，使用随机数(在本例中为128位)是一种简单的方法，因为

问AES CTR:随机IV
EN

回答 1

Cryptography用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问AES CTR:随机IVEN