Intel and AMD processors can have new microcode loaded to them, and this
is usually done by the BIOS. Presumably there is some asymmetric crypto
involved with the processor doing the signature validation.
A major power that makes a good fraction of the world's laptops and
desktops (and hence
Matt's blog post [1] gets to the heart of the matter of what we can trust.
I may have missed the discussion, but I ran across Netronome's 'SSL
Inspector' appliance [2] today and with the recent discussion on this list
regarding malicious hardware, I find this appliance appalling.
Basically a cor
Charles McElwain <[EMAIL PROTECTED]> writes:
> Follow-ups on this line of research will be interesting for the
> evaluation of any impact of quantum computers on cryptography, and
> even generally, since the decoherence behavior would tend to make
> quantum computers approximate improving classica
John Denker <[EMAIL PROTECTED]> writes:
> This is an important discussion
>
> The threats are real, and we need to defend against them.
I'm not sure how to feasibly defend against such things. It would seem
to require complete control over the entire design and supply chain,
which involves so m
In case you missed this, since it appeared in the quantum physics
section; but is relevant to quantum cryptography (or, cryptography on
quantum computers.)
The argument here is that Shor's factoring algorithm is dependent on
the Quantum Fourier Transform, which is sensitive to errors in
quant
Ed Gerck <[EMAIL PROTECTED]> writes:
> Perry E. Metzger wrote:
>> No. It really does not. Shannon's tenth theorem is about correcting
>> lossy channels with statistically random noise. This is about making
>> sure something bad doesn't happen to your computer like having someone
>> transmit blocks
Perry E. Metzger wrote:
No. It really does not. Shannon's tenth theorem is about correcting
lossy channels with statistically random noise. This is about making
sure something bad doesn't happen to your computer like having someone
transmit blocks of your hard drive out on the network. I assure y
Ed Gerck <[EMAIL PROTECTED]> writes:
> Perry E. Metzger wrote:
>> Ed Gerck <[EMAIL PROTECTED]> writes:
>>> Each chip does not have to be 100% independent, and does not have to
>>> be used 100% of the time.
>>>
>>> Assuming a random selection of both outputs and chips for testing, and
>>> a finite
This is an important discussion
The threats are real, and we need to defend against them.
We need to consider the _whole_ problem, top to bottom. The
layers that could be subverted include, at a minimum:
-- The cpu chip itself (which set off the current flurry of
interest).
-- The boot rom
Perry E. Metzger wrote:
Ed Gerck <[EMAIL PROTECTED]> writes:
Each chip does not have to be 100% independent, and does not have to
be used 100% of the time.
Assuming a random selection of both outputs and chips for testing, and
a finite set of possible outputs, it is possible to calculate what
s
On Mon, 28 Apr 2008, Ed Gerck wrote:
| Leichter, Jerry wrote:
| > I suspect the only heavy-weight defense is the same one we use against
| > the "Trusting Trust" hook-in-the-compiler attack: Cross-compile on
| > as many compilers from as many sources as you can, on the assumption
| > that not all
Ed Gerck <[EMAIL PROTECTED]> writes:
> Each chip does not have to be 100% independent, and does not have to
> be used 100% of the time.
>
> Assuming a random selection of both outputs and chips for testing, and
> a finite set of possible outputs, it is possible to calculate what
> sampling ratio w
Leichter, Jerry wrote:
I suspect the only heavy-weight defense is the same one we use against
the "Trusting Trust" hook-in-the-compiler attack: Cross-compile on
as many compilers from as many sources as you can, on the assumption
that not all compilers contain the same "hook".
...
Of course, y
On Sat, 26 Apr 2008, Karsten Nohl wrote:
| Assuming that hardware backdoors can be build, the interesting
| question becomes how to defeat against them. Even after a particular
| triggering string is identified, it is not clear whether software can
| be used to detect malicious programs. It almost
>>Adding a backdoor to chips is a different story, though, since that would
require cutting a second set of masks.
>>I am assuming that there must be no backdoor in the legitimately produced
chips since the client would detect
>>it as a slight violation of some of their timing simulations. The
15 matches
Mail list logo
