Timeline for Encrypting random IV in CTR mode (no nonce!)
Current License: CC BY-SA 4.0
12 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Aug 12, 2023 at 7:30 | comment | added | fgrieu♦ | @ManRow: there's no doubt that assuming a good TRNG, your proposed technique reduces the possibility of exploitable counter overlap compared to CTR in whatever variant of IV initialization and strategy for long plaintext, often in a significant proportion. My point is that exploitable counter overlap in CTR with sound split of IV and counter part practically only occurs when we do not use a good TRNG. A point could be made that assuming a good TRNG, your proposed technique's main practical advantage is that it helps against key leak by side channel. | |
| Aug 12, 2023 at 7:25 | comment | added | ManRow | @fgrieu But yes -- given what I'm proposing, the title would more accurately be "no counter-section" then, instead of "no-nonce" (as the "nonce" part is what gets expanded to the full block size, whereas the "counter" part, in turn, is removed!) | |
| Aug 12, 2023 at 5:46 | comment | added | ManRow | @fgrieu Traditional CTR does do such a "nonce/counter" separation -- e.g, for 128-bit ciphers, dedicating 96-bits for the nonce, and 32-bits for the counter. But, my focus was to simply let the "nonce" space expand to use the full 128-bits (without thus having to "dedicate" any space to a "counter" section), which would enable encrypting even more messages before worrying about nonce-repeats as well. However, this would bring up the issue of "partial overlaps", for which I was proposing the solution of "IV as key" above... | |
| Aug 12, 2023 at 5:31 | comment | added | ManRow | @fgrieu "I see no reason why such mishap would be much less likely when generating the question's K' than when generating a traditional random IV." -- well, the idea is to enable simple, random 128-bit IV's for CTR mode that only get incremented without dividing anything into any "special nonce/counter" pairs or sections, but while still avoiding the partial overlap problem. | |
| Aug 10, 2023 at 16:21 | history | edited | fgrieu♦ | CC BY-SA 4.0 |
Link to details in comment
|
| Aug 10, 2023 at 16:18 | comment | added | fgrieu♦ | With strategy A there are $n=2^{32}$ IV generations, and the probability that any two distinctly generated collide is $p=2^{-96}$, leading to about $p\,n(n-1)/2≈2^{-33}$ of colliding counter. With strategy B there are $n=2^{16}$ IV generations, and if another IV is within $2^{16}-1$ of another there will be a collision. Thus the probability that any two distinctly generated IV values cause a collision is $p=(2^{17}-1)/2^{96}≈2^{-79}$, and now probability of colliding counter is $≈p\,n(n-1)/2≈2^{-48}$. That probability is decreased by $≈2^{15}$ in strategy B. @MaartenBodewes | |
| Aug 10, 2023 at 16:04 | comment | added | fgrieu♦ | @MaartenBodewes: I'm comparing strategy A of generating a new uniformly random IV when we reach the 64 GiB limit, to strategy B of keeping on incrementing the whole counter, at equal total amount of data encrypted, and equal amount of IV generation for other causes than exceeding the 64 GiB limit (e.g. different encryption units, resets). The strategy B strictly decreases the probability that there is counter reuse, assuming that the 64GiB limit is exceeded at least once, and there's not so much data that counter reuse is certain. I'll illustrate with $2^{16}$×4 PiB (4 PiB=$2^{48}$ blocks). | |
| Aug 10, 2023 at 14:08 | comment | added | Maarten Bodewes♦ | "Exceeding the 64 GiB limit per message instead of generating a new IV is safe: it only decreases this probability." You'd still use a single other IV value, right? And compared to smaller messages there is still a higher chance. I don't get that part, could you explain? | |
| Aug 10, 2023 at 12:01 | history | edited | fgrieu♦ | CC BY-SA 4.0 |
Polish
|
| Aug 10, 2023 at 10:30 | history | edited | fgrieu♦ | CC BY-SA 4.0 |
Polish
|
| Aug 10, 2023 at 10:24 | history | edited | fgrieu♦ | CC BY-SA 4.0 |
Polish
|
| Aug 10, 2023 at 10:15 | history | answered | fgrieu♦ | CC BY-SA 4.0 |
