On 20.09.2013 18:28, Steve Crocker wrote:
Are we conflating back doors in implementations with back doors in
protocol specifications? It's certainly a conceptual possibility for
there to be a back door in a protocol specification, but I don't
recall ever hearing about one.
Of course backdoors in specifications are more subtle than in
implementations. Instead of thinking about "backdoors" just think about
how you could weaken a specification from a security point of view that
is allows interception.
There are obviously a number of ways you could weaken security
intentionally in the standardization process:
* Choose smaller key size
* Pick algorithms that are weaker than others
* Prefer an protocol architecture that allows intermediaries to inspect
traffic
* Design lawful intercept into the architecture
* Intentionally avoid the standardization of end-to-end security mechanisms
* Prefer performance over privacy in protocol designs
* Make it very hard to change identifiers
* Design protocols, which make user control an out-of-band feature.
* Choose poor defaults with respect to security and privacy in protocols
* Design protocols that allow correlation and fingerprinting
* Delay the work on secure protocol versions and ship the plaintext
versions much earlier than
* Prevent certain security standardization from happening.
The last two items are probably most difficult to spot but most effective.
Do any of these things sound familiar to you?
Ciao
Hannes