Hacker News Reader

Comment by orf | Hacker News Reader

Let’s assume we don’t want to make memory constrained devices keep large video files buffered in memory and constantly re-download them over the network?

View on HN

For the View Once media, have it buffered in memory and be done with it. Delete from the server once it's inaccessible (or keep it a few days it need be... for reporting reasons).

For the non-private media, just write it to storage straight away.

You're still susceptible to me owning a second device that can take photos. If it can be displayed, it can be copied.

encrypt with in-memory nonce

Still hit the issue with large media that doesn't fit in memory and your gain is still minor (resist a compromised filesystem.. maybe.. if they didn't compromise the binary too)

How does that hit an issue with large media that doesn't fit in memory? The encrypted media is on flash. The key is in memory. The key is small.

I have 1gb of ram. I want to watch a 4gb video file that's encrypted, starting at 0:32 and I want to jump back to that timecode a few times.

You can't check chapter markers or frame counts because they are encrypted.You can't usually partially decrypt a file either.

If use use AES-CTR you can decrypt any arbitrary 16-byte block of data from the file as long as you know its offset from the beginning. You don't need to know any other data of the file. As long as you don't need to insert or shift parts of the file without re-encrypting, this works fine. And you have to be OK with the file being padded at the end to a multiple of 16 bytes long.

Every time you want to read some data off flash, you read it then immediately decrypt it. Any time you want to write data to flash, you decrypt it first. Checking chapter markers or frame counts will be the same as before as long as you decrypt those bytes immediately after reading them from flash.

How does that prevent me from lifting it right off the framebuffer?

Reply on news.ycombinator.com