<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">On Mon, 19 Oct 2015 Thierry Moreau wrote:<br class=""><br class=""><blockquote type="cite" class="">The recent realization that public key cryptosystems having common <br class="">parameters (DH) may be vulnerable from the very fact that they rely on <br class="">common parameters is puzzling to me.<br class=""><br class="">In hindsight, the question would have been (highly) relevant ever since <br class="">the practitioner had a choice between such cryptosystems and <br class="">cryptosystems having entity-specific parameters (RSA, Rabin-Williams), <br class="">the latter being vulnerable to flaws or trapdoors in the parameter <br class="">generation implementation for each entity.<br class=""><br class="">Moreover, the basic finding in the "Imperfect forward secrecy" <br class="">publication (<a href="https://weakdh.org/imperfect-forward-secrecy-ccs15.pdf" class="">https://weakdh.org/imperfect-forward-secrecy-ccs15.pdf</a>) was <br class="">within the reach of skilled mathematicians ever since the number field <br class="">sieve algorithm could be explained in a university classroom.<br class=""><br class="">It's a shame that this old issue has been ignored until now!<br class=""><br class="">What other "obvious" questions are we ignoring?<br class=""><br class="">- Thierry Moreau</blockquote><br class=""><div class="">Excellent question. Heere is my list of issues are the cryptographic community knows about, but keeps ignoring:</div><div class=""><br class=""></div><div class="">1. Compilers that break security code in the name of optimization. The C community in particular insists that it is ok to delete potential overflows, even deleting assert checks, and to ignore zeroization of data that will not be used again. Rather than demanding change, security programmers resort to subterfuge to fool the compiler, but there is no guarantee that the tricks employed will still work in the next release of the compiler or when ta newt build is done with a different optimization setting. </div><div class=""><br class=""></div><div class="">2. Modern computers are too complex to be secure. It’s turtles (processors) all the way down. Few people even know how many processors are in their computer and peripherals they use, much less have any visibility into the code that executes on those processors. And the universal presence of user accessible I/O ports creates huge security holes.</div><div class=""><br class=""></div><div class="">3. Embedded systems often have no way to receive security updates.</div><div class=""><br class=""></div><div class="">4. There are no published standards (at least that I am aware of) that specify how to manage passwords. As a result organizations still do bonehead things like failing to use salt or keeping old password files on their network after they have upgraded security. </div><div class=""><br class=""></div><div class="">5. Designing cryptographic hashes for best performance on hardware.</div><div class=""><br class=""></div><div class="">6. Failure to explain the provenance constants used in cryptographic algorithms, preferably using “nothing up my sleeve” numbers.</div><div class=""><br class=""></div><div class="">7. Fuzzy goals for cryptography. We want to access our data any time we want, anywhere we want, on any platform we want and to share it with anyone we want but we want all of our data to be secure against the bad guys, who we can’t clearly define and don’t all agree on. And we don’t want to be inconvenienced in any way.</div><div class=""><br class=""></div><div class="">8. Ignoring physical security. The list here is endless, but my favorite at the moment is searching people when they leave a secure facility, but not when they enter. </div><div class=""><br class=""></div><div class="">Arnold Reinhold</div><div class=""><br class=""></div><div class=""><br class=""></div></body></html>