[Cryptography] Other obvious issues being ignored?

[Arnold Reinhold]

On Mon, 19 Oct 2015 Thierry Moreau wrote:

> The recent realization that public key cryptosystems having common 
> parameters (DH) may be vulnerable from the very fact that they rely on 
> common parameters is puzzling to me.
> 
> In hindsight, the question would have been (highly) relevant ever since 
> the practitioner had a choice between such cryptosystems and 
> cryptosystems having entity-specific parameters (RSA, Rabin-Williams), 
> the latter being vulnerable to flaws or trapdoors in the parameter 
> generation implementation for each entity.
> 
> Moreover, the basic finding in the "Imperfect forward secrecy" 
> publication (https://weakdh.org/imperfect-forward-secrecy-ccs15.pdf <https://weakdh.org/imperfect-forward-secrecy-ccs15.pdf>) was 
> within the reach of skilled mathematicians ever since the number field 
> sieve algorithm could be explained in a university classroom.
> 
> It's a shame that this old issue has been ignored until now!
> 
> What other "obvious" questions are we ignoring?
> 
> - Thierry Moreau

Excellent question. Heere is my list of issues are the cryptographic community knows about, but keeps ignoring:

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. 

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.

3. Embedded systems often have no way to receive security updates.

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. 

5. Designing cryptographic hashes for best performance on hardware.

6. Failure to explain the provenance constants used in cryptographic algorithms, preferably using “nothing up my sleeve” numbers.

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.

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. 

Arnold Reinhold


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20151020/e07d6629/attachment.html>