Hacker News Reader

Comment by vorpalhex | Hacker News Reader

View once media is always susceptible to this problem. I can always put a capture card between my screen and the device or use a vm - or just take a picture using a second device.

Likewise touching file storage makes sense, the media files have to sit somewhere. Any vaguely modern android phone has full disk encryption, so it's only apps with global filesystem access that present a threat.

View on HN

That's not true. It's possible to manipulate file-like objects without ever touching the filesystem. BytesIO in Python for example ([0]).

I'm not an expert in Java Android, but I'm pretty certain there must be something like that.

[0]: https://docs.python.org/3/library/io.html

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?

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?

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.

> I can always put a capture card between my screen and the device or use a vm

Nope, look up HDCP. They could enforce that on desktop if they wanted to.

> or just take a picture using a second device.

Yes, but you will lose quality.

Reply on news.ycombinator.com