[Cryptography] Other obvious issues being ignored?

[Peter Fairbrother]

On 19/10/15 14:10, 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) 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?

While others have mentioned optimising compilers "optimising" away 
security measures, let's not forget object code authentication.

Most people don't compile their own code, they trust someone else to do 
it, and (maybe) check the signatures on the object code.

But does the object code match the source? The only way you can be sure 
is if the compiler can repeatedly produce the same object code - and 
today's compilers don't do that, for at least ten reasons which have 
nothing to do with security.



Jerry Leichter doubted that "having a whole separate language for 
writing security-related code is the right approach" - but I think 
eventually it must be.

Though even that would not wholly solve the silicon problem, where the 
processor changes the instructions..

No low-level optimising stuff like mallocs - the complier should 
allocate memory, and delete/release it, always, and in a secure manner, 
always, not the programmer. No user-generated buffers, so no buffer 
overflows even possible - you don't actually need user-generated 
fixed-size buffers. No undefined behaviour, ever.

No compiler options.

Actually, it makes for a fairly simple language, and a not-too-complex 
compiler.



-- Peter Fairbrother