#nsa forces Torvalds' hand? #linux

12.14: intro:
see NSA backdoors all encryption software

12.12: news.cyb/sec/linux/nsa forces Torvalds' hand?:
rt.com:

. MIT-educated cryptographer and Linux developer
Theodore Ts'o stated publically that
he was happy with his decision to resist
earlier pleads from Intel engineers
to have that operating system commit entirely to
RDRAND [intel's on-chip routine] for encryption:
"Relying solely on the hardware random number generator
which is using an implementation sealed inside a chip
which is impossible to audit
is a BAD idea" . Now just three months later,
FreeBSD is rescinding their reliance on Intel and Via’s RNGs.
[by contrast:]
When a petition began circulating in mid-Sept
imploring Linux to stop relying on RDRAND,
one of the OS’s leading developers, Linus Torvalds,
called those who made those pleads "Ignorant" .

co.slashdot# melikamp (631205) on September 19, 08:29AM :

In reality, slipping a backdoor into Linux
is much easier: just code it into
a proprietary wireless firmware blob
which is already a part of the
(non-free) kernel distributed at linux.org.
The mal-firmware can then spy and report
directly from the network card,
or use DMA to elevate itself to ring 0 on the main CPU.
What makes this scenario most FUN is
the sheer likelihood of such a backdoor
being in place RIGHT NOW,
within the official Linux git repo,
since no approval or knowledge by Linus
would be required to slip it in.

co.slashdot#eer (526805) on September 19, 07:25AM:

Begin your concerns with the device drivers
from who knows where that are put into place
by your motherboard BIOS or EFI boot systems.
Conventional operating systems
are entirely dependent on them,
and they're completely beyond your ability to
inspect or trust.
And the Open Source variations have the same issue
as the operating systems - large, monolithic
blocks of code impenetrable to analysis.
. You fear what you know about.
Fear, instead, what you don't.

Ken Thompson 1984:

. for the untraceable trojan,
we first compile the modified source
with the normal C compiler
to produce a bugged binary.
We install this binary as the official C.
We can now remove the bugs
from the source of the compiler
and the new binary will reinsert the bugs
whenever it is compiled.
You can't trust code
that you did not totally create yourself.
No amount of source-level verification or scrutiny
will protect you from using untrusted code.
. I could have trojan'd any program-handling program
not just a compiler: an assembler, a loader,
or even hardware microcode.
As the level of program gets lower,
these bugs will be harder to detect.
A well installed microcode bug
will be almost impossible to detect.

. you may find trojans by exhaustive inspection
of the resulting binaries,
and you can do that with microcode;
but if a government wants to insert a trojan,
they need only ask the chip maker
to insert the trojan in the built-in microcode,
and then they can use patches to the microcode
to protect their own computers from prying eyes .