News for hackers. Stuff that matters.
Re:NUMA Siloing in the FreeBSD Network Stack [pdf] by mlyle on Monday September 23, 2019 @01:00AM (#21046031)
Easy enough to make the content authenticate itself, instead of repeating cryptographic work for each viewer.

E.g. every 64k block contains a SHA256 hash of the next 64k block. When a user seeks, you provide the hash of the first block they'll be receiving over a trusted channel. (It already can exist at start of stream RSA signed or whatever).

But that's probably a pain when you have so many different devices to support.

(It also makes it harder to figure out what content people are watching... Though I think they use variable bitrate encoding which will fall to traffic analysis).

Re:NUMA Siloing in the FreeBSD Network Stack [pdf] by im3w1l on Monday September 23, 2019 @05:14AM (#21047205)
This exists in a more advanced form already

https://wicg.github.io/webpackage/draft-yasskin-http-origin-...

Re:NUMA Siloing in the FreeBSD Network Stack [pdf] by mlyle on Monday September 23, 2019 @12:17PM (#21050317)
No... it's not the same as signed HTTP exchanges, which you'd generally use inside TLS, and involves signing all of the data in an exchange. It wouldn't work very well for streaming, either.

The important feature of the scheme that I mentioned is that there's no per-client encryption needed, except maybe a small operation on each client seek in the stream. In general, you just serve the file, and the file contents are self-authenticating against tampering.

You might use signed HTTP exchanges to push the first hash in the chain on a seek, I guess. Or just run it over TLS. Or just have a 64k block pre-signed at the beginning stream with the hashes of 2k chosen seek points that the client can store.