• CPU
• Motherboard
• BIOS
• Storage device
• Storage controller
• Network interface
• Operating system

If any of the above is compromised, you are no better off than with a hardware based router.

If you by hardware router mean a device that truly forwards packets in hardware without involving any sort of CPU, then your best guarantee is the economical one. It is cheaper for the vendor to manufacture hardware without snooping capabilities than with.

Hi.

the Nyquist limit of the audio sampling hardware of a cell phone over instruction rate of a modern CPU is a pretty small fraction.

The "audio" in question is most likely all below 24 kHz, that being the Nyquist limit for the 48 kHz sampling hardware, unless it happens that some phones can actually sample faster, and have microphones that can respond to higher frequencies.

The instruction rate of the CPUs in question is many times that frequency.

It doesn't sound likely.

Using multiple cores turns out to help the attack (by shifting down the signal frequencies).

Say what? Through what mechanism would multiple cores shift down the frequency? And what about parallel instruction streams contributing to noise?

TEMPEST was a details-secret government requirement meant to defeat means of eavesdropping on classified computer data from its electromagnetic emissions. I guess they need to include audio too.

My impression is that the noise comes from the power supply, not the CPU. I can certainly hear it with some computers, and it is related to work on the video card in my experience. I'm astonished that you can actually pull data from that, and in fact I'd like to see independent confirmation before I believe it.

Aren't those the type-of calling of sizeof and therefore needs parenthesis?

To me even asking that question is indication, that you should include parenthesis. If the author or any of the readers are unsure if parenthesis is required or not, it is better to use parenthesis more often than strictly required. In other words, you can omit the parenthesis only if you know for sure, it will work and that everybody who will read it, also understand the rules.

the IV is not considered secret.

Of course not. After all, most cipher modes sent the IV directly on the wire. However it is only sent once the data has been encrypted. If the adversary knew the IV before you encrypted the data, the adversary could influence the content of the data based on her knowledge about the IV, and break the encryption that way. If you are using a cipher mode, which requires the IV to be random, then you must choose a random IV after the data to be encrypted has been set in stone, and no sooner than that. SSL was broken due to encrypting data in CBC mode, where the data was not yet known, when the IV was chosen.

As long as keys are never re-used it doesn't matter if the IV is predictable or not.

That depends a lot on the mode. CBC mode is vulnerable to plenty of attacks, if the IV is predictable. And what predictability means in this context has taken some people by surprise. If the end of the stream of data is not set in stone once you start encrypting, does that mean the IV is predictable? The way CBC has been used in SSL did have a weakness because of that. The cipher blocks sent across the network are used as IV for successive blocks. But once you have sent a cipher block, it is no longer unpredictable. And if the adversary can influence the next data block once he has seen the previous cipher block, CBC can be exploited.

This is the same tradeoff as when using block ciphers in counter mode.

It is true that counter mode is one of those modes, that do not require unpredictable IVs. In fact you can just use a counter to generate your IV. But if you do not choose IVs carefully, counter mode is one of the weakest modes, you can choose. If you ever reuse an IV, you have effectively reduced the encryption to a multi-time pad. CBC mode with a constant IV would be more secure than that.

The thing is, that counter mode is actually a stream cipher, which operates by generating a stream of bits, which is XORed with the message. All ciphers constructed in this way are vulnerable, if the IV is reused. That is exactly the problem with WEP.

I have seen at least one published article recommending the use of counter mode for storage encryption. It did not explicitly say you should use the sector number as IV, but it was hinting, that's what you were expected to do. Additionally using sector number as IV has been common practice in storage encryptions. Any storage encryption following that practice would be broken if an adversary was able to get the data which has existed at one logical sector number at two different points in time. Ways that could happen includes:

• Wear levelling on a flash/SSD medium.
• Remapped sectors on a harddrive.
• Access to earlier versions due to slight difference in alignment of write head.
• Encrypted data stored on an untrusted host or accessed over an untrusted communication path.
• Adversary with physical access to copy the encrypted media more than once.

Funny, I had the same reaction when I read it. He seemed like a salesman for Google or something.

Dear Prince Bernard, If you're talking about my bank account, you're barking up the wrong tree :)

Fair use cases are very fact specific. If you start monkeying with the facts, Judge Chin might not feel the same way about it.

I don't know but please hire me as your lawyer when you do.

Thatswhatappealscourtsarefor