@ BF Skinner, Gabriel,
"FBI 'planted backdoor' in OpenBSD"
Just for arguments sake I'm going to play the "cough cough male bovine excrement cough cough" card on Mr Perry's claims.
But also assume that they are taken seriously (they have. to for credability reasons) and another much more indepth code audit takes place on the "giffted" IPSEC stack used on Open BSD.
A couple of questions arise,
1, Will anything be found?
2, Would a real back door be found?
To which the answers are "Yes" and "Probably not".
As you are probably both aware I have mentione three areas of attack that the likes of the NSA et al would be using these days,
1, Protocol issues.
2, Side channel issues.
3, 'Known Plain Text' issues.
There are enough of these that we know that you don't have to try very hard to find bugs in code to excersise them (think SSL for protocol, AES for side channel, MS format docs for known plain text). We also know that even where 'bugs' are known for compatability reasons they are darn difficult to resolve (think Wifi in it's various and still broken but in use forms). So I'm fairly confident that they are going to find quite a few things if the do an indepth right through the IPSEC audit (including finding protocol bugs in IPSEC).
Would they find a specificaly planted 'bug', the answer is 'probably not' for various reasons.
Firstly as I've mentioned several times before there are so many subtal ways of doing it that you are not likley to spot even a very small percentage. Especialy if the fundemental attack vector is unknown to you.
For instance getting access to the key can be done as I've indicated in the past using malloc and friends. A simple example being not using free, but this is fairly well known and memory leak tools will probably pick it up. You can also use malloc and free and then malloc again to get the same block of memory under the new pointer, this is less well known and as it is a correct 'valid usage' of malloc it is not something a tool is going to explicitly flag up though it would not be to hard to write a tool to show real memory reuse within a process.
But importantly there are many further variations that are very subtle and in many ways quite stable due to the use of kernel internals virtual memory manager and the MMU. Such tricks can be worked through automatic paging mechanisms, IPC and buffers etc.
It is the usage of memory paging at the hardware level that gives rise to the three academicaly known classes of "cache" attacks.
As we know "loop unrolling" was the first such attack against AES and demonstrated across the network within a few months of AES getting the stamp of approval. We also know that the NSA certifies AES for some Inline Media Encryptors (IME's) but with the caveat of "only with data at rest"... I've made both these points several times in the past.
The reason AES is susceptible to this is a failure to consider this attack vector during the selection process and this makes it a fundemental weakness just like many protocol errors.
BUT this is just one asspect of "getting the key" you don't have to leak the whole key to get the rest of it with a little work...
And this is the point all encryption systems leak information in one way or another, thus two further questions arise,
3, Can the leak be seen?
4, Is what is leaked usable by an attacker?
Now I can safely say that you can only see what you are looking for, unless your attention is drawn to it in some way. So leak finding is probabilistic in nature (as most things are).
Likewise even if you can see a leak can you recognise what is being leaked is harmfull, and the answer is no you cannot.
For instance black box testing can see 'noise' but you cannot tell if there is a real signal in the noise in some way this is part of the well known "Low probability of detect" radio systems that moved into digital watermarking etc.
If you look at the work of Adam Young and Moti Yung with Cryptovirology they show a way that public key systems can have information hidden in them that can be used to break the private key out. They likewise show how you can use PK systems to secure information leakage.
This means that you could put a backdoor into encryption systems whereby you leak the key but as it is encrypted via PK technology you are the only pearson who can make use of the leak...
Which as a consiquence means if PK is secure you cannot corelate any leaked information back to the key, thus black box testing won't help...