Hacker News Reader

Comment by londons_explore | Hacker News Reader

> They thought the camera’s file system was unencrypted, when it was encrypted.

Willing to bet plenty of hn readers are unaware of encryption going on at lower layers of the tech stack than they're aware of.

For example most hard drives encrypt all data, even when not commanded to, as a way to do 'data whitening' (ie making sure there are even numbers of 0's and 1's in the data stream and not some pattern which might throw off tracking.)

The encryption key is simply stored elsewhere in the drive - or nvram or in the firmware.

But it means if you extract the physical magnetic surface and read it with the right microscope, you might well find the data encrypted with no available key.

View on HN

Scrambling and encryption are two different things. Scrambling is very easy to do at line rates. Encryption not so much.

Ethernet is a good example. It has the same problem where long strings of 0's or 1's can cause clock recovery problems. The solution as clock rates have increased is to just run all the data through a scrambler driven by a simple Linear Feedback Shifter.

If you're talking about SED feature, no, it isn't widespread since it's regarded as an "enterprise" feature and only available in minority of drives (regardless of HDD or SSD). Client or OEM variants of same drives (otherwise identical) lack SED option most of the time and doesn't encrypt data by default.

The hardware is still there - they don't make a new asic for the consumer version

doesn't mean it's active.

"Active" with those systems just means the encryption key is now user-supplied instead of being stored on the controller/drive. The actual encryption is always active; which makes sense, if anything it means you have one less configuration to test.

If I learned one thing about SSD firmwares/controllers it's to be sure of nothing. Especially when the market is flooded with cheap controllers that can barely keep up with line speeds I'm very much doubtful that they're unconditionally encrypting at rest data.

To my knowledge, encoding avoids runs to avoid desynchronization in a way that isn’t encrypted.

This is line coding, often used on wired connections. But reading a hard drive trace isn't quite a wired connection, so the trade-offs are different.

Most notably with line coding when using positive and negative voltages it is quite important for the average voltage to be zero to avoid building up a charge difference. Whitening can often be used if the downside to an imbalance or long runs is much lower. Notably in RF this is often about avoid harmonics with a little bit of symbol timing advantage thrown in.

Whitening doesn't really require encryption though. Weak cypher streams xored into the data work fine. Even a repeated 256 bit string is quite alright.

Whitening using any non trivial encryption key seems weird to me. AES with a key equal to the current offset in ECB mode already feels over-engineerd.

> Whitening using any non trivial encryption key seems weird to me.

It's because there was an era when drives were expected to be able to do 'hardware' encryption with a user provided key, so reusing that hardware to also do whitening even if the user didn't provide a key was very convenient.

Plus you get all the other benefits - ie. a single scsi command can 'secure erase' the whole disk in milliseconds by simply changing the stored key.

This used to be done, but since ~2000, disks were expected to support on-device encryption, and by making encryption always-on no encoding is needed.

Reply on news.ycombinator.com