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

Olav Thon

Image
Olav Thon Fødd 29. juni 1923 Ål Yrke forretningsdrivande Olav Thon på Commons Olav Thon (fødd 29. juni 1923) er ein norsk, stort sett sjølvlært forretningsmann, fødd i Ål i Hallingdal, som har gjort store pengar på særleg kjøp, bygging og utvikling av fast eigedom, mellom anna kjøpesentre, hotell og restaurantar, i både Noreg og somme andre land. Han vart Ridder av 1. klasse av St. Olavs Orden i 2003, og er som ivrig friluftsmann æresmedlem i Den Norske Turistforening etter å ha ytt store økonomiske bidrag til foreininga sine hytter og ruter i fjellet. Han er kjend for alltid å gå med ei karakteristisk strikkelue. Olav Thon i samtale med Trond Helleland på sentralbanksjefens årstale i februar 2016 I ung alder reiste Olav Thon til Newcastle for å lære seg engelsk, og han var seinare ei tid i Sveits, der han gjorde forretningar i import og eksport. Deretter tok han til å kjøpe faste eigedomar i Noreg med stor økonomisk suksess, verksemda voks snøgt og v...
Read more

Waikiki

Image
Denne artikkelen kan ha godt av ein språkvask , som reinskar opp målføringa og/eller innfører same språkstilen overalt. Denne artikkelen kan ha godt av ei opprydding for å nå ein høgare standard og/eller for å verta i tråd med standardoppsettet. Sjå korleis du redigerer ei side og stilmanualen for hjelp. Waikiki Land   USA Stat Hawaii Stad Honolulu Wikimedia Commons: Waikiki Utsyn over Waikiki Waikīkī er ein bydel i Honolulu, sør på øya Oahu, som er ei av Hawaii-øyane. Waikīkīstranda er ein av dei meste berømte strendene i verda. Waikīkī strekkjer seg langs stillehavskysten og har ei rekkje velrenommerte hotell. Bydelen er Hawaii-turismens høyborg. På Waikīkī Beach står ei statue av den lokale sportsstjerna Duka Kahanamoku. Kjelder | Denne artikkelen bygger på «Waikiki» frå Wikipedia på bokmål, den 4. november 2018. Denne artikkelen manglar kjelder eller referansar . Hjelp Wikipedia med å finna truverdige kjelder...
Read more

Tårekanal

Image
Tåreapparatet ( a ) Tårekjertel ( b ) Øvre tårepunkt ( c ) Øvre tårekanalikkel ( d ) Tåresekk ( e ) Nedre tårepunkt ( f ) Nedre tårekanalikkel ( g ) Tårekanal Tårekanalen eller nase-tårekanalen (av latin ductus nasolacrimalis ) er ein ductus som frakter overflødige tårer frå tåresekken til nasehola. Opninga inn mot nedre nasegang er delvis tildekt av ei ufullstendig slimhinnefold kalla Hasners ventil. Overflødige tårer strøymer gjennom tårekanalen og trekker inn i nedre nasegang. Dette er grunnen til at ein kan få rennande nase når ein gret, og at ein somme gonger kan kjenne saltsmaken av tårer i munnen. Både tårekanalen og tåresekken er tekt med fleirlaga sylinderepitel som inneheld slimproduserande begerceller, og er begge omgjevne av bindevev. Dakryostenose (tårekanalstenose) er ei innsnevring av tårekanalen som fører til epifora, ei overflod av tårer. Medfødd dakryostenose kan føra til cystisk utviding av tårekanalen ved at det dannast ein dakryocystocele. Personar m...
Read more