[liberationtech] Cryptography super-group creates unbreakable encryption

[Fabio Pietrosanti (naif)]

On 2/20/13 12:49 PM, Joseph Lorenzo Hall wrote:
> Another aspect of this discussion I'm a bit surprised that no one has yet raised is the simple truth that no amount of testing and source code review can (or should) anoint a tool as secure.
>
> Even with formally provably secure software, OS, hardware, etc. it is still a very hard problem to make sure the code you fuzzed, reviewed, tested, statically analyzed, etc. ends up being the code you run.

On that topic imho is useful to make some specific security consideration.

While you can't really prove that crypto is secure, you can prove that a
piece of software does satisfy certain security requirements in a
specific threat model [1] .

I've been working for a "Common Criteria" [2] certification
documentation/analysis for a secure telephony product and had to write a
TOE (Target of Evaluation) detailing all the security functionality
requiring to satisfy CC requirements for evaluation.

I was shocked by the amount of details that you have to consider while
formally describing a piece of security technology use in a specific
context, where "no details can be left behind" and "everything that
related to security" will be methodologically tested.

In such context, the "source code analysis" for example is not required
to evaluate the security of a product up to EAL2, while for EAL4 [3]
this became part of the methodology requirements.

This is to say that the "source code analysis" is part of this process,
and even if we all know that "open code" is better than "closed code"
,in CC security procedures (considered by all
governments/military/security industry the "best of"), this is not the
most important.

The Security Design, Security Requirements, Methodological Evaluation
Procedures to check those security requirements could be even more
important.

If we take "security as a science", then we can elaborate, peer review,
model all the security risks and functionality, identifying proper use,
lacking features.

The problem is that it take a huge amount of time to have such a
structured approach, both for the manufacturer and for the auditor. :\

-naif

[1]
https://developer.apple.com/library/mac/documentation/security/Conceptual/Security_Overview/ThreatModeling/ThreatModeling.html
[2] http://en.wikipedia.org/wiki/Common_Criteria
[3] http://en.wikipedia.org/wiki/Evaluation_Assurance_Level