Hashing a counter to prevent distinguishers in CTR mode












2












$begingroup$


Because a block cipher is a PRP and thus bijective, the fact that the input in CTR mode never repeats means that each block of keystream will be unique. This creates a distinguisher from random data following the birthday bound if enough data is encrypted even before the counter repeats, especially if the block size is too small. Stream ciphers like ChaCha20 avoid this issue by feeding a counter into a PRF instead of a PRP, meaning blocks of keystream will repeat according to the birthday bound.



Is it feasible to mitigate this problem with a PRP by feeding the nonce and counter through a very fast and deterministic hashing function first? Because the input to the block cipher is not secret in CTR mode, it would not need to be a secure hash function. All it would need to do is admit collisions due to the birthday bound, allowing for a repeating block in the keystream after roughly $2^{n/2}$ blocks.



Is this correct? If so, what is the fastest hash function which has the required properties?






ctr distinguisher







share|improve this question









$endgroup$








  • 2




    $begingroup$
    I think it would need to be a secure hash function, otherwise we could force it to generate identical key streams at will.
    $endgroup$
    – Ella Rose♦
    3 hours ago
















2












$begingroup$


Because a block cipher is a PRP and thus bijective, the fact that the input in CTR mode never repeats means that each block of keystream will be unique. This creates a distinguisher from random data following the birthday bound if enough data is encrypted even before the counter repeats, especially if the block size is too small. Stream ciphers like ChaCha20 avoid this issue by feeding a counter into a PRF instead of a PRP, meaning blocks of keystream will repeat according to the birthday bound.



Is it feasible to mitigate this problem with a PRP by feeding the nonce and counter through a very fast and deterministic hashing function first? Because the input to the block cipher is not secret in CTR mode, it would not need to be a secure hash function. All it would need to do is admit collisions due to the birthday bound, allowing for a repeating block in the keystream after roughly $2^{n/2}$ blocks.



Is this correct? If so, what is the fastest hash function which has the required properties?






ctr distinguisher







share|improve this question









$endgroup$








  • 2




    $begingroup$
    I think it would need to be a secure hash function, otherwise we could force it to generate identical key streams at will.
    $endgroup$
    – Ella Rose♦
    3 hours ago














2












2








2


2



$begingroup$


Because a block cipher is a PRP and thus bijective, the fact that the input in CTR mode never repeats means that each block of keystream will be unique. This creates a distinguisher from random data following the birthday bound if enough data is encrypted even before the counter repeats, especially if the block size is too small. Stream ciphers like ChaCha20 avoid this issue by feeding a counter into a PRF instead of a PRP, meaning blocks of keystream will repeat according to the birthday bound.



Is it feasible to mitigate this problem with a PRP by feeding the nonce and counter through a very fast and deterministic hashing function first? Because the input to the block cipher is not secret in CTR mode, it would not need to be a secure hash function. All it would need to do is admit collisions due to the birthday bound, allowing for a repeating block in the keystream after roughly $2^{n/2}$ blocks.



Is this correct? If so, what is the fastest hash function which has the required properties?






ctr distinguisher







share|improve this question









$endgroup$




Because a block cipher is a PRP and thus bijective, the fact that the input in CTR mode never repeats means that each block of keystream will be unique. This creates a distinguisher from random data following the birthday bound if enough data is encrypted even before the counter repeats, especially if the block size is too small. Stream ciphers like ChaCha20 avoid this issue by feeding a counter into a PRF instead of a PRP, meaning blocks of keystream will repeat according to the birthday bound.



Is it feasible to mitigate this problem with a PRP by feeding the nonce and counter through a very fast and deterministic hashing function first? Because the input to the block cipher is not secret in CTR mode, it would not need to be a secure hash function. All it would need to do is admit collisions due to the birthday bound, allowing for a repeating block in the keystream after roughly $2^{n/2}$ blocks.



Is this correct? If so, what is the fastest hash function which has the required properties?






ctr distinguisher




ctr distinguisher






share|improve this question













share|improve this question











share|improve this question




share|improve this question










asked 5 hours ago









forestforest

3,2611236




3,2611236








  • 2




    $begingroup$
    I think it would need to be a secure hash function, otherwise we could force it to generate identical key streams at will.
    $endgroup$
    – Ella Rose♦
    3 hours ago














  • 2




    $begingroup$
    I think it would need to be a secure hash function, otherwise we could force it to generate identical key streams at will.
    $endgroup$
    – Ella Rose♦
    3 hours ago








2




2




$begingroup$
I think it would need to be a secure hash function, otherwise we could force it to generate identical key streams at will.
$endgroup$
– Ella Rose♦
3 hours ago




$begingroup$
I think it would need to be a secure hash function, otherwise we could force it to generate identical key streams at will.
$endgroup$
– Ella Rose♦
3 hours ago










1 Answer
1






active

oldest

votes


















2












$begingroup$

I'm reading the question as generating a keystream per: $S_igets E_K(F(mathrm{IV},i))$ where $F$ is a public function built from a hash function, and a block cipher $E$ with secret key $K$, for incremental index $i$ starting from $0$ and public random $mathrm{IV}$, with $F$ having a sizable collision rate when $i$ varies.



That is quite insecure: the location of the collisions, that is values of $i$, $j$ with $ine j$ and $F(mathrm{IV},i)=F(mathrm{IV},j)$, can be found by an adversary from the public $mathrm{IV}$. And then knowledge that $K_i=K_j$ can be used to mount an attack allowing decryption of some plaintext fragment from partially known plaintext.






share|improve this answer











$endgroup$













  • $begingroup$
    Ah, it seems obvious now. Thanks!
    $endgroup$
    – forest
    2 hours ago











Your Answer





StackExchange.ifUsing("editor", function () {
return StackExchange.using("mathjaxEditing", function () {
StackExchange.MarkdownEditor.creationCallbacks.add(function (editor, postfix) {
StackExchange.mathjaxEditing.prepareWmdForMathJax(editor, postfix, [["$", "$"], ["\\(","\\)"]]);
});
});
}, "mathjax-editing");

StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "281"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
noCode: true, onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});














draft saved

draft discarded


















StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fcrypto.stackexchange.com%2fquestions%2f66836%2fhashing-a-counter-to-prevent-distinguishers-in-ctr-mode%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown

























1 Answer
1






active

oldest

votes








1 Answer
1






active

oldest

votes









active

oldest

votes






active

oldest

votes









2












$begingroup$

I'm reading the question as generating a keystream per: $S_igets E_K(F(mathrm{IV},i))$ where $F$ is a public function built from a hash function, and a block cipher $E$ with secret key $K$, for incremental index $i$ starting from $0$ and public random $mathrm{IV}$, with $F$ having a sizable collision rate when $i$ varies.



That is quite insecure: the location of the collisions, that is values of $i$, $j$ with $ine j$ and $F(mathrm{IV},i)=F(mathrm{IV},j)$, can be found by an adversary from the public $mathrm{IV}$. And then knowledge that $K_i=K_j$ can be used to mount an attack allowing decryption of some plaintext fragment from partially known plaintext.






share|improve this answer











$endgroup$













  • $begingroup$
    Ah, it seems obvious now. Thanks!
    $endgroup$
    – forest
    2 hours ago
















2












$begingroup$

I'm reading the question as generating a keystream per: $S_igets E_K(F(mathrm{IV},i))$ where $F$ is a public function built from a hash function, and a block cipher $E$ with secret key $K$, for incremental index $i$ starting from $0$ and public random $mathrm{IV}$, with $F$ having a sizable collision rate when $i$ varies.



That is quite insecure: the location of the collisions, that is values of $i$, $j$ with $ine j$ and $F(mathrm{IV},i)=F(mathrm{IV},j)$, can be found by an adversary from the public $mathrm{IV}$. And then knowledge that $K_i=K_j$ can be used to mount an attack allowing decryption of some plaintext fragment from partially known plaintext.






share|improve this answer











$endgroup$













  • $begingroup$
    Ah, it seems obvious now. Thanks!
    $endgroup$
    – forest
    2 hours ago














2












2








2





$begingroup$

I'm reading the question as generating a keystream per: $S_igets E_K(F(mathrm{IV},i))$ where $F$ is a public function built from a hash function, and a block cipher $E$ with secret key $K$, for incremental index $i$ starting from $0$ and public random $mathrm{IV}$, with $F$ having a sizable collision rate when $i$ varies.



That is quite insecure: the location of the collisions, that is values of $i$, $j$ with $ine j$ and $F(mathrm{IV},i)=F(mathrm{IV},j)$, can be found by an adversary from the public $mathrm{IV}$. And then knowledge that $K_i=K_j$ can be used to mount an attack allowing decryption of some plaintext fragment from partially known plaintext.






share|improve this answer











$endgroup$



I'm reading the question as generating a keystream per: $S_igets E_K(F(mathrm{IV},i))$ where $F$ is a public function built from a hash function, and a block cipher $E$ with secret key $K$, for incremental index $i$ starting from $0$ and public random $mathrm{IV}$, with $F$ having a sizable collision rate when $i$ varies.



That is quite insecure: the location of the collisions, that is values of $i$, $j$ with $ine j$ and $F(mathrm{IV},i)=F(mathrm{IV},j)$, can be found by an adversary from the public $mathrm{IV}$. And then knowledge that $K_i=K_j$ can be used to mount an attack allowing decryption of some plaintext fragment from partially known plaintext.







share|improve this answer














share|improve this answer



share|improve this answer








edited 2 hours ago

























answered 2 hours ago









fgrieufgrieu

78.8k7168335




78.8k7168335












  • $begingroup$
    Ah, it seems obvious now. Thanks!
    $endgroup$
    – forest
    2 hours ago


















  • $begingroup$
    Ah, it seems obvious now. Thanks!
    $endgroup$
    – forest
    2 hours ago
















$begingroup$
Ah, it seems obvious now. Thanks!
$endgroup$
– forest
2 hours ago




$begingroup$
Ah, it seems obvious now. Thanks!
$endgroup$
– forest
2 hours ago


















draft saved

draft discarded




















































Thanks for contributing an answer to Cryptography Stack Exchange!


  • Please be sure to answer the question. Provide details and share your research!

But avoid …



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


Use MathJax to format equations. MathJax reference.


To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fcrypto.stackexchange.com%2fquestions%2f66836%2fhashing-a-counter-to-prevent-distinguishers-in-ctr-mode%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







-

Popular posts from this blog

What are all the squawk codes?

Image
2 $begingroup$ I love aviation and I love learning new things about it. I was wondering if anyone knew all of the squawk codes and in particular what squawk 7500 means. squawk-codes share | improve this question edited 15 mins ago Jamiec ♦ 14.8k 4 60 91 asked 5 hours ago Zac Callaghan Zac Callaghan 11 2 New contributor Zac Callaghan is a new co
Read more

What are differences between VBoxVGA, VMSVGA and VBoxSVGA in VirtualBox?

Image
1 VirtualBox 6.0 provides a new setting called Graphics Controller. There are four options to choose from: None VBoxVGA VMSVGA VBoxSVGA In the user manual I have found this information: Graphics Controller: Specifies the graphics adapter type used by the guest VM. Note that you must install the Guest Additions on the guest VM to specify the VBoxSVGA or VMSVGA graphics controller. The following options are available: – VBoxSVGA: The default graphics controller for new VMs that use Linux or Windows 7 or later. This graphics controller improves performance and 3D support when compared to the legacy VBoxVGA option. – VBoxVGA: Use this graphics controller for legacy guest OSes. This is the default graphics controller for Windows versions before Windows 7. – VMSVGA: Use this graphics controller to emul
Read more

Hudsonelva

Image
Hudson elv Land   USA Område New York Sideelvar Mohawk Lengd 507 km Middelvassføring 606 m³/s Munning Upper New York Bay i Atlanterhavet Elvene Hudson og Mohawk med nedbørsområdet markert med gult. Wikimedia Commons: Hudson River Hudsonelva ( Hudson River ) mohikansk Muh-he-kun-ne-tuk ) er ei elv i USA. Ho renn hovudsakleg gjennom delstaten New York, men markerer også ein del av grensa mellom New York og New Jersey. Hudsonelva har namn etter Henry Hudson, ein engelskmann som utforska elva i 1609. Hudsonelva sett frå Bear Mountain Bridge. Kjelda til elva er Tear-of-the-Clouds-sjøen i Adirondackfjella. Ved Albany renn Mohawk-elva saman med henne, og deretter renn ho nesten rett sørover til ho munnar ut i Atlanterhavet mellom Manhattan i New York og New Jersey. Eriekanalen, som blei opna den 26 oktober 1825, bind saman Hudsonelva og Eriesjøen, slik at byane ved Dei store sjøane fekk vasstilgang til A
Read more