If it really does exist, the backdoor can simply be inserted during the last-minute compile before release. It would be invisible in the code repository, the vast majority of internal developers at Microsoft won't even see anything unusual. Also, I heard anecdotes that Microsoft already allowed governments to audit the source code of Windows under NDA on multiple occasions in the past.
But if you cannot guarantee the correspondence between source and binary releases, such a review only helps a little. Reproducible build is crucial for auditability.
> I heard anecdotes that Microsoft already allowed governments to audit the source code of Windows under NDA on multiple occasions in the past.
I can confirm that back in the Windows 2000 days, MS let a major global bank have access to the Windows 2000 source code to aid them in coding some low level bespoke software.
Back then, if you were a gold customer, you could pretty much get anything out of MS under an NDA.
'MS let a major global bank have access to the Windows 2000 source code to aid them in coding some low level bespoke software.'
Examples of this are comparatively well known but it seems to me it's really not relevant here. In those instances it's extremely unlikely that said institutions would have access to even the majority of the source code let alone all of it.
All they need are API hooks and or various security code that's relevant for their purposes, etc. If I were the Microsoft person responsible for interfacing with these banks, I'd do what I've done with unrelated stuff, which is to tell them just sufficient to do the job (that's to say only on a need-to-know basis).
And that's why modern compilers won't have that. It was exactly so the same source, even compiled a second later, it will generate different binary file.
I hate it. It was so easy in DOS era - same source, same binary file, easy peasy.
The major variables in modern compilers are just automatic timestamps, exploit mitigation random seeds, and toolchain versions, it is possible to make them immutable. The problem can be fixed, and there are already major projects to address it. Do you know that 90% of the Debian packages are already reproducible [0]?
That’s true. But that may also be a plausible deniability thing - you create a place to hide binary modifications by making sure no two builds are exactly the same.
It could be chalked to some lack of care; however, up until 2000 or so, non reproducible builds were considered a bug in at least two places I worked in. The fact that it has become so hard to make builds reproducible could be Increased “entropy” (because no one cares To fix it) - but it could also be orchestrated by someone with a vested interest.
E.g. - suppose you are a three letter agency, and want to implement a “reflections on trusting trust” attack. Non reproducible builds become a pre-requisite.
This is correct. Back at least in the Vista days each public release had to be passed to the NSA to validate the encryption algorithms and implementation. I’d imagine they poked around a few other parts of the OS
The NSA has a dual mandate - to improve security for the US government (and by extension, US businesses to an extent), and to peek into communications outside the US.
They have been pretty negligent about the first (or even malicious about it - e.g. the dual drbg case), letting the second take over - but officially they still have the first mandate.
In fact, DES was considerably strengthened in its day by the NSA review - at that time for reasons not understood by industry or academia. It was later discovered that the change required by the NSA made DES much more resistant to differential cryptanalysis, a technique that was (re)discovered by academic cryptographers much later.
Every “conspiracy” I’ve heard about the NSA and friends turned out to be true, most with definite proof from the Snowden releases.
> Every “conspiracy” I’ve heard about the NSA and friends turned out to be true
And therefore every next thing anyone on the Internet concocted has to be true as well?
I get what you're saying though, and I'm well aware of the dual mandate. But you haven't given me anymore reason to believe this particular one, and I find it strange because I've never heard of any company in any country having to give their software to an intelligence agency before being allowed to release only the modified version. Implanting backdoors is not unheard of, but after they had great success with the clipper chip it's usually done without the company in question knowing about it.
You say the excuse was to validate some implementation, but in that case Microsoft wouldn't need to publish any modified versions, the nsa would just point out "this contains too strong crypto, can't export this" or "you made a mistake in algo X allowing attack Y". Not "please substitute this dll with our version and better not tell your customers!".
You are reading too much into cududa’s comment and mine, quite a bit of things neither of us said.
Cududa mentioned Microsoft let the NSA review it - that it was procedure, not that it was law. Furthermore, no one claimed that NSA recommendations or replacement DLLs had to be used by law - though that makes little difference. I mentioned that this would be in line with well known history of DES development. That’s basically all we said about it.
I have no idea what you are referring to with the Clipper chip. But RSA, NIST and others were definitely aware they were peddling NSA recommendations With the dual-drbg fiasco.
But if you cannot guarantee the correspondence between source and binary releases, such a review only helps a little. Reproducible build is crucial for auditability.