<div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace">I ran across this the other day when I was doing a QA of a vulnerability assessment report. The vulnerability report references vulnerabilities via MITRE's Common Weakness Enumeration's (CWE) project. The report uses both CWE IDs / CWE title, as well as the standard MITRE CWE descriptions. But sometimes those CWE descriptions lack clarity and could use a bit of improvement. That's where I hope this community can help.<br></div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">For "CWE-329: Not Using a Random IV with CBC Mode" (<a href="https://cwe.mitre.org/data/definitions/329.html">https://cwe.mitre.org/data/definitions/329.html</a>), the MITRE risk description states:</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace"><div name="oc_329_Description" id="gmail-oc_329_Description" class="expandblock"><div class="gmail-detail"><div class="gmail-indent" style="margin-left:40px">Not
 using a random initialization Vector (IV) with Cipher Block Chaining 
(CBC) Mode causes algorithms to be susceptible to <i>dictionary attacks</i>.</div><div class="gmail-indent"><br></div><div class="gmail-indent">[Emphasis mine.]</div><div class="gmail-indent"><br></div><div class="gmail-indent">And for the "Background Details" section, it states:</div><div class="gmail-indent"><div name="oc_329_Background_Details" id="gmail-oc_329_Background_Details" class="expandblock" style="margin-left:40px"><div class="gmail-detail"><div class="gmail-indent"><div id="gmail-Grouped">
            CBC is the most commonly used mode of operation for a block 
cipher. It solves electronic code book's dictionary problems by XORing 
the ciphertext with plaintext. If it used to encrypt multiple data 
streams, <i>dictionary attacks are possible, provided that the streams have
 a common beginning sequence</i>.
</div></div></div></div> </div></div></div></div><div><br></div><div><div style="font-family:monospace,monospace" class="gmail_default">[Again, emphasis mine.]</div><br></div><div><div style="font-family:monospace,monospace" class="gmail_default">So, after reading this, I am convinced that either I do not understand what cryptographers mean by a "dictionary attack" or MITRE doesn't.</div><div style="font-family:monospace,monospace" class="gmail_default"><br></div><div style="font-family:monospace,monospace" class="gmail_default">My understanding of "dictionary attack" pretty much agrees with the <a href="https://en.wikipedia.org/wiki/Dictionary_attack">Wikipedia definition</a> of it, which states:<br></div><div style="font-family:monospace,monospace;margin-left:40px" class="gmail_default">In <a href="https://en.wikipedia.org/wiki/Cryptanalysis" title="Cryptanalysis">cryptanalysis</a> and <a href="https://en.wikipedia.org/wiki/Computer_security" title="Computer security">computer security</a>, a <b>dictionary attack</b> is a form of <a href="https://en.wikipedia.org/wiki/Brute-force_attack" title="Brute-force attack">brute force attack</a> technique for defeating a <a href="https://en.wikipedia.org/wiki/Cipher" title="Cipher">cipher</a>
 or authentication mechanism by trying to determine its decryption key 
or passphrase by trying thousands or millions of likely possibilities, 
such as words in a dictionary or previously used passwords, often from 
lists obtained from past security breaches.
</div></div><div><div style="font-family:monospace,monospace" class="gmail_default"></div><div style="font-family:monospace,monospace" class="gmail_default">Now by this definition, if one is perhaps using CBC mode with a non-random IV and either an ASCII key or some password based derived key (say created by PBKDFv2), then standard password dictionary attacks could indeed be useful and a non-random IV may make this a bit simpler. But I am not seeing how a non-random IV used with CBC mode will aid in <b>dictionary attacks</b> for randomly generated secret keys.<br></div><div style="font-family:monospace,monospace" class="gmail_default"><br></div><div style="font-family:monospace,monospace" class="gmail_default">My intuition (which, again, may very well be wrong) is that the biggest weakness of non-random IVs is that it will make patterns more likely to emerge in the ciphertext (sort of devolving into a wonky ECB mode in the worst case), and that this would be especially true to those corresponding to the first plaintext block that is encrypted. So it would seem that rather than the concern being a "dictionary attack" (which again, seems very unlikely if one were actually generating and using a completely random secret key), the more relevant attacks for CBC mode and a non-random IV (not necessarily a fixed IV, but in practice that is what we usually see for non-random IV) would be things like various chosen plaintext attacks or various types of chosen ciphertext attacks or possibly even related-key attacks. (And a non-random IV may also simplify padding oracle attacks if an Encrypt-then-MAC approach is not also used to ensure authenticity.)<br></div><div style="font-family:monospace,monospace" class="gmail_default"><br></div><div style="font-family:monospace,monospace" class="gmail_default">Anyhow, long story short (okay, you're right, too late!) if I am confused after all these years of reading this mailing list, then surely my security colleagues are even more confused since they have very little cryptography background in comparison.<br></div><div style="font-family:monospace,monospace" class="gmail_default"><br></div><div style="font-family:monospace,monospace" class="gmail_default">So what I am hoping readers of this list might be able to do is to suggest <i><b>better</b></i> Risk Description and Background Details sections for <a href="https://cwe.mitre.org/data/definitions/329.html">CWE-329</a>. If anyone is willing to help with that, then I am willing to take on the fool's errand of trying to get MITRE to change it so it is more accurate and clear. I also am more than willing to give proper credit to whomever suggests some better verbiage. (After all, far be it from me to take the blame. :) If there are several better suggestions, I will simply let MITRE know all of the suggestions and who said what.</div><div style="font-family:monospace,monospace" class="gmail_default"><br></div><div style="font-family:monospace,monospace" class="gmail_default">So that is all. You can help out the security community by coming up with better descriptions for those 2 sections.</div><div style="font-family:monospace,monospace" class="gmail_default"><br></div><div style="font-family:monospace,monospace" class="gmail_default">Thanks in advance,</div><div style="font-family:monospace,monospace" class="gmail_default">-kevin<br></div><div style="font-family:monospace,monospace" class="gmail_default">--<br></div></div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>Blog: <a href="http://off-the-wall-security.blogspot.com/" target="_blank">http://off-the-wall-security.blogspot.com/</a>    | Twitter: @KevinWWall<br>NSA: All your crypto bit are belong to us.</div></div></div></div>