Stories
Slash Boxes
Comments

SoylentNews is people

posted by martyb on Sunday April 19 2015, @02:19PM   Printer-friendly
from the when-does-a-video-stream-become-a-river? dept.

Ars Technica reports that Netflix is about to encrypt all its video streams with HTTPS. The feature will be rolled out in the coming year. This comes after one failed attempt six months ago.

Netflix's entry into the HTTPS party comes as privacy and security advocates are calling on all websites to encrypt all their traffic. The rationale behind the request is that continuous and complete HTTPS protection thwarts state-sponsored attacks that countries like the US and China launch from the Internet backbone. Web encryption is also useful against man-in-the-middle attacks that hijack huge chunks of Internet traffic. In both cases, HTTPS prevents the attacker from surreptitiously injecting malicious packets into the targeted data stream.

According to El Reg, this change will increase costs considerably for Netflix:

Netflix has battled with the overheads HTTPS incurs; Watson estimated a capacity hit between 30 to 53 percent thanks to encryption computational overheads and a lack of optimisations to avoid data copies to and from user space.

Such a hit would cost Netflix potentially hundreds of millions of dollars a year.

Tweaks could cut that overhead by a third while speculative advancements in the next several years could crush it by up to 80 percent.

Do we really need encrypted video streams?

This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 2) by doublerot13 on Sunday April 19 2015, @02:30PM

    by doublerot13 (4497) on Sunday April 19 2015, @02:30PM (#172830)

    AES instructions on right there on the chip now a days. Why does the CPU hit have to be so dramatic?

    • (Score: 0) by Anonymous Coward on Sunday April 19 2015, @02:57PM

      by Anonymous Coward on Sunday April 19 2015, @02:57PM (#172840)

      Maybe it's a DRM abstraction thing?

    • (Score: 4, Funny) by Anonymous Coward on Sunday April 19 2015, @03:02PM

      by Anonymous Coward on Sunday April 19 2015, @03:02PM (#172842)

      Look, he believes brogrammers take advantage of hardware features!

    • (Score: 4, Interesting) by tynin on Sunday April 19 2015, @03:05PM

      by tynin (2013) on Sunday April 19 2015, @03:05PM (#172843) Journal

      I suspect it is because it will be encrypted, it won't be cacheable in any meaningful sense. All the work that the cache would have saved handling tons of concurrent users doing largely similar actions is likely right in that 30 to 53 percent number.

      • (Score: 2) by frojack on Sunday April 19 2015, @10:51PM

        by frojack (1554) on Sunday April 19 2015, @10:51PM (#172959) Journal

        But Netflix has their own servers parked on the head end controllers of most big ISPs, don't they?
        If So caching has already been pushed far down the tree.

        And given that, they have a lot more engines doing the stream encryption very close to the customer.

        Also, a question: Is AES efficient at encrypting long running streaming video? I was under the impression there were other ciphers that were better for that.

        --
        No, you are mistaken. I've always had this sig.
        • (Score: 3, Interesting) by tempest on Monday April 20 2015, @02:23PM

          by tempest (3050) on Monday April 20 2015, @02:23PM (#173129)

          In TLS1.2 we're basically down to Camellia and AES (forgetting Ghost and Koren oddballs). Chacha20 would probably be the best option considering the range of devices connecting (Roku/PS3/phones/TV embedded/etc) which don't have AES acceleration, but is still in the process of being adapted. I think they'll be using special hardware for acceleration regardless.

          • (Score: 3, Informative) by frojack on Monday April 20 2015, @09:49PM

            by frojack (1554) on Monday April 20 2015, @09:49PM (#173298) Journal

            That fits with what I was remembering.

            You might start with AES-128 or something for session initiation, but once you start a data stream you quickly switch to some more efficient cipher to handle the speed.

            --
            No, you are mistaken. I've always had this sig.
    • (Score: 3, Interesting) by Immerman on Sunday April 19 2015, @03:06PM

      by Immerman (3985) on Sunday April 19 2015, @03:06PM (#172844)

      Perhaps because it's a lot more computationally expensive to use those instructions than to stream raw data straight off the hard drive to the network card? Which, assuming good CPU throttling, will translate directly to higher power consumption. And that's assuming the CPUs aren't stripped down models that would need to be upgraded for real-time encryption to begin with.

      Plus there's the caching issue - without encryption if two people in a city are watching the same thing at about the same time Netflix's servers can potentially send the data across the country only once, and the local streaming media cache can feed the data to the second and subsequent viewers. With encryption every viewer has to get the data directly from the Netflix servers.

      • (Score: 5, Interesting) by tnt118 on Sunday April 19 2015, @05:45PM

        by tnt118 (3925) on Sunday April 19 2015, @05:45PM (#172886)

        I've always wondered if there was a viable model for a movie or show "starting" every 10 minutes, and users jump in on one of those streams to save bandwidth costs.

        --
        I think I like it here.
        • (Score: 2) by AnonTechie on Sunday April 19 2015, @08:38PM

          by AnonTechie (2275) on Sunday April 19 2015, @08:38PM (#172924) Journal

          Thats an interesting idea.

          --
          Albert Einstein - "Only two things are infinite, the universe and human stupidity, and I'm not sure about the former."
          • (Score: 2) by nightsky30 on Wednesday April 22 2015, @08:57PM

            by nightsky30 (1818) on Wednesday April 22 2015, @08:57PM (#174108)

            If they don't add commercials in between, that would be great. Otherwise it would be too much like TV. It also kind of kills the instant factor, unless the multicast is optional. Say they have listings. If a show starts in 5 mins, ok. I'd wait for it. But if nobody is watching what I'd like to watch, let me start one right now. I'd hate to see listings of a show that is 3 hours long but only half way through, and has 0 viewers and no way to start a fresh show.

        • (Score: 2) by linuxrocks123 on Monday April 20 2015, @07:00AM

          by linuxrocks123 (2557) on Monday April 20 2015, @07:00AM (#173052) Journal

          This is how in-flight movies work.

        • (Score: 2) by gnuman on Monday April 20 2015, @04:50PM

          by gnuman (5013) on Monday April 20 2015, @04:50PM (#173182)

          I've always wondered if there was a viable model for a movie or show "starting" every 10 minutes, and users jump in on one of those streams to save bandwidth costs.

          What do you think that multicast thing was for?

                http://en.wikipedia.org/wiki/Multicast [wikipedia.org]

      • (Score: 2) by Wootery on Wednesday April 22 2015, @11:08PM

        by Wootery (2341) on Wednesday April 22 2015, @11:08PM (#174154)

        The caching question seems like the elephant in the room.

        Was Netflix previously using ordinary HTTP to deliver video content? If so, that would presumably have enabled caching by ISPs. I imagine some folks will not be happy about the increase in traffic if caching is no longer possible.

        Steam moved to HTTP (away from their old proprietary protocol) for downloads [steampowered.com] in order to enable caching.

    • (Score: 2) by Jeremiah Cornelius on Sunday April 19 2015, @05:43PM

      by Jeremiah Cornelius (2785) on Sunday April 19 2015, @05:43PM (#172885) Journal

      The AES encrypting of the HTTP stream is not the hit.

      There's a LOT of compute used in session-key generation - occurring late in the hand-shake phase of the protocol. A few of these? no problem. Ten million? Ouch.

      AFTER you have keys, "magic" instructions can use them to make the overhead almost transparent.

      --
      You're betting on the pantomime horse...
      • (Score: 1) by KiloByte on Monday April 20 2015, @12:48AM

        by KiloByte (375) on Monday April 20 2015, @12:48AM (#172980)

        When the streams are something as big as high-resolution videos, once-per-stream handshakes are not going to drag you down.

        --
        Ceterum censeo systemd esse delendam.
  • (Score: 0) by Anonymous Coward on Sunday April 19 2015, @02:32PM

    by Anonymous Coward on Sunday April 19 2015, @02:32PM (#172832)

    No!

    Any more questions?

    • (Score: 5, Insightful) by khchung on Sunday April 19 2015, @03:21PM

      by khchung (457) on Sunday April 19 2015, @03:21PM (#172848)

      WRONG! The answer is YES.

      Not to protect the video streams, but to add more encrypted traffic to the network, eventually to the point where the really sensitive encrypted packets will no longer stand out.

      By encrypting video streams, Netflix made their sensitive traffic that actually needed protection safer.

      • (Score: 4, Interesting) by kadal on Sunday April 19 2015, @04:19PM

        by kadal (4731) on Sunday April 19 2015, @04:19PM (#172861)

        But, is it easy or hard to tell which packets are from Netflix? It won't help much if it's easy to filter out.

        • (Score: 2) by khchung on Monday April 20 2015, @06:03AM

          by khchung (457) on Monday April 20 2015, @06:03AM (#173032)

          Did you notice I said "*their* sensitive traffic"?

          It won't help *your* traffic to your bank, but any sensitive data packets (such as containing personal information) that you use to communicate with Netflix will now be mixed with all the video packets and much harder to isolate.

          • (Score: 2) by quadrox on Monday April 20 2015, @10:12AM

            by quadrox (315) on Monday April 20 2015, @10:12AM (#173091)

            I'm pretty sure that the destination/origin host for anything pertaining to your account or other sensitive matters is quite different from the host containing the actual videos. Thus it would be extremely easy to filter out all video traffic.

            Or am I wrong about that?

      • (Score: 0) by Anonymous Coward on Sunday April 19 2015, @04:22PM

        by Anonymous Coward on Sunday April 19 2015, @04:22PM (#172863)

        Not to protect the video streams, but to add more encrypted traffic to the network, eventually to the point where the really sensitive encrypted packets will no longer stand out.

        By encrypting video streams, Netflix made their sensitive traffic that actually needed protection safer.

        Not really, netflix do not offer VPNs do they? If you have access to any router along the path, you know the endpoints and can safely discern the encrypted data is comprised of a video stream.

      • (Score: 2, Interesting) by Anonymous Coward on Sunday April 19 2015, @05:47PM

        by Anonymous Coward on Sunday April 19 2015, @05:47PM (#172888)

        Not really since the SSL handshake takes place clear-text, so that entire flow can be setup to be automatically ignored by the spooks. I.e., SSL cert CN=netfix.com, then ignore.

        If they created a Tor hidden service, and setup their client to tunnel through Tor, they would achieve the goal you state (and would destroy Tor with the extra traffic, in the process, unless they sponsored a huge expansion of Tor entry and intermediate nodes)

        Also, a nit with the summary,

        Web encryption is also useful against man-in-the-middle attacks that hijack huge chunks of Internet traffic.

        It absolutely doesn't help in a MiM, since state actors responsible for these attacks, at scale, have access to trusted CA root/intermediate certificates. Due to the flawed trust model of SSL/TLS certificate signing, there is nothing to prevent the US, Israel, China, Russia, UK, etc. from creating a MiM that is undetectable by most users. The only thing that sort of protects against this is extensions like certpatrol, but then there is so much turnover in certs, that even running certpatrol, you may decide incorrectly that the new cert is OK.

        • (Score: 2, Interesting) by Anonymous Coward on Sunday April 19 2015, @09:03PM

          by Anonymous Coward on Sunday April 19 2015, @09:03PM (#172932)

          What if Netflix leveraged their enormous traffic and DRM/encryption experience, as well as paid subscription model, to begin offering some secure message service in addition to video using indistinguishable SSL connections? A trickle of encrypted info in a river of encrypted video, all coming from the same source, would pose a quandary for would-be eavesdroppers, as long as the service provides client-side encryption and provides no point in the middle where data is in the clear. Under a paid model, Netflix has no need to mine the data, so they're not in the same boat as Facebook or Google in terms of the profitability of not providing such client-side encryption. There's certainly a market for secure encryption, and Netflix is one of the few players who really could have the volume of encrypted traffic to provide the haystack.

          • (Score: 1, Insightful) by Anonymous Coward on Monday April 20 2015, @04:16AM

            by Anonymous Coward on Monday April 20 2015, @04:16AM (#173010)

            Would you really trust a US corporation that must comply with US laws (even the secret/illegal ones) with your private communications? Even if encryption took place on your client, Netflix and US LEOs would have the metadata about who connected to who, for how long, how often, etc.

            • (Score: 0) by Anonymous Coward on Tuesday April 21 2015, @02:49AM

              by Anonymous Coward on Tuesday April 21 2015, @02:49AM (#173371)

              Someone's going to have that metadata anyway. There are few situations in which no one has it. Would I rather have the US have it than the EU or RU or CN? Doesn't really matter: six of one half - a dozen of the other. The geographic location of corporate HQ isn't going to change that. As long as the message is encrypted client-side, that's the important part.

  • (Score: 3, Interesting) by bziman on Sunday April 19 2015, @02:37PM

    by bziman (3577) on Sunday April 19 2015, @02:37PM (#172834)

    Can we please just use multicast for live streaming?

    It could also be used for streaming popular non-live content to ISP cache servers at release... and there are probably nearly as many of those as there are simultaneous viewers.

    But that would require infrastructure investments, and ISPs have demonstrated their unwillingness to invest in anything but profits.

    • (Score: 4, Informative) by Anonymous Coward on Sunday April 19 2015, @02:59PM

      by Anonymous Coward on Sunday April 19 2015, @02:59PM (#172841)

      Netflix is not a live streaming service.

    • (Score: 2, Interesting) by nitehawk214 on Sunday April 19 2015, @06:34PM

      by nitehawk214 (1304) on Sunday April 19 2015, @06:34PM (#172894)

      A) Figure out how to get the entire internet over to IP6 so this can be supported
      B) Netflix is on-demand. Nobody is watching the same part of the same show at the same time, so this does not do any good here.

      --
      "Don't you ever miss the days when you used to be nostalgic?" -Loiosh
      • (Score: 2) by kaszz on Monday April 20 2015, @12:31AM

        by kaszz (4211) on Monday April 20 2015, @12:31AM (#172975) Journal

        1) Multicast works within IPv4
        2) People can join streams that starts every 5 seconds or so.

  • (Score: 0) by Anonymous Coward on Sunday April 19 2015, @02:50PM

    by Anonymous Coward on Sunday April 19 2015, @02:50PM (#172836)

    They just need signatures to prevent spoofing. That's a much smaller hit in terms of CPU cycles.

  • (Score: 2) by Grishnakh on Sunday April 19 2015, @02:51PM

    by Grishnakh (2831) on Sunday April 19 2015, @02:51PM (#172837)

    Why on earth do they want to encrypt Netflix movie streams? What is there to protect here? What is a man-in-the-middle attack going to do to someone watching a Netflix movie, show them a commercial or something?

    • (Score: 1, Insightful) by Anonymous Coward on Sunday April 19 2015, @02:55PM

      by Anonymous Coward on Sunday April 19 2015, @02:55PM (#172839)

      In both cases, HTTPS prevents the attacker from surreptitiously injecting malicious packets into the targeted data stream.

      • (Score: 1, Interesting) by Anonymous Coward on Sunday April 19 2015, @03:11PM

        by Anonymous Coward on Sunday April 19 2015, @03:11PM (#172847)

        yes, and what the hell is a malicious package in a video stream supposed to do? other than fightclub inspired people injecting porn into family movies...
        it's a video stream. the only thing you can do to it is corrupt it.

        • (Score: 2) by mhajicek on Sunday April 19 2015, @04:17PM

          by mhajicek (51) on Sunday April 19 2015, @04:17PM (#172860)

          They're packing hay around the needle.

          --
          The spacelike surfaces of time foliations can have a cusp at the surface of discontinuity. - P. Hajicek
        • (Score: 4, Insightful) by Anonymous Coward on Sunday April 19 2015, @04:39PM

          by Anonymous Coward on Sunday April 19 2015, @04:39PM (#172868)

          > yes, and what the hell is a malicious package in a video stream supposed to do?

          Exploit bugs in the player software. Perhaps there are edge cases in the decoder that a specially crafted mpeg packet can use to do stack smashing, etc.

          Besides, maybe I don't want anyone figuring out what shows I am watching. [wikipedia.org] I can totally see Comcast snooping that and use it to profile their ISP customers as a way to extract revenue from cord-cutters.

  • (Score: 2) by Leebert on Sunday April 19 2015, @04:09PM

    by Leebert (3511) on Sunday April 19 2015, @04:09PM (#172859)

    Another important consideration is the impact on battery life. More CPU to decrypt = some measurable (even if negligible) increase in the power consumed to view the stream.

    • (Score: 0) by Anonymous Coward on Monday April 20 2015, @08:56AM

      by Anonymous Coward on Monday April 20 2015, @08:56AM (#173075)

      Well, that could easily be counteracted by dropping DRM. After all, DRM also is just an encryption of the content. Add one encryption, remove another, and your device won't have to do any more work.

  • (Score: 2, Informative) by Anonymous Coward on Sunday April 19 2015, @04:35PM

    by Anonymous Coward on Sunday April 19 2015, @04:35PM (#172866)

    I remember this hitting hitting bsdtalk a while ago talking about all of the problems that they were encountering along the way. It's a bit egotistical for FreeBSD but that's what Netflix uses for their CND but he makes some great points about what is coming for the future from a web standpoint.

    https://archive.org/details/bsdtalk249 [archive.org]

    • (Score: 3, Interesting) by Yog-Yogguth on Tuesday April 21 2015, @03:34AM

      by Yog-Yogguth (1862) Subscriber Badge on Tuesday April 21 2015, @03:34AM (#173379) Journal

      Thank you for posting that, very informative. And I didn't know about bsdtalk (blog [blogspot.com], downloads/torrents at IA [archive.org])

      For anyone who doesn't listen to it the direct reason (but not entirely verbatim quote) from the audio (slightly rephrased/edited because he corrects himself) is:

      “…as part of the HTML5 standardization process Google is really pushing to have no mixed-mode objects within HTML5 and what means is that if we want to encrypt [our control channel], which we do, we need to also SSL encrypt our…” “…we also need to encrypt our data channel” —Netflix representative

      They're aiming to publish papers on all of this next year so anyone else can do it the same way they've done. There's a lot more detail in the audio.

      Snowden etc. and Google's reactions (encrypting everything) are also mentioned. Maybe it means is that some companies are starting to realize they're not in control of their own assets like capital and infrastructure unless they encrypt everything. Google and Netflix are among the first because they have more/enough people able to make the realization and whip the management into line. At the opposite end are companies like Sony who exist completely at the mercy of others, who are not actually in control of their own capital and infrastructure etc., and who still don't learn any of the lessons no matter how many times they're hit. If shareholders and investors were more clued in to that (and they will be sooner or later) then Sony (and nearly all other companies) would have junk status or be bankrupt.

      I don't think SSL/TLS is a silver bullet but granted it's one of the few bullets available “immediately”. One would think the big companies should look into becoming their own CA's as an additional fairly easy step before they start fixing other flaws and weaknesses. At some point down the line they might also try to regain trust in their own equipment: 100% open hardware, processors, fabrication, the lot, it's an enormous challenge. They didn't start this war but if they want to win it that's what needs to happen.

      --
      Bite harder Ouroboros, bite! tails.boum.org/ linux USB CD secure desktop IRC *crypt tor (not endorsements (XKeyScore))
  • (Score: 5, Informative) by subs on Sunday April 19 2015, @05:46PM

    by subs (4485) on Sunday April 19 2015, @05:46PM (#172887)

    AFAIK, Netflix already uses DRM of some sort, which almost invariably means that the streams are already encrypted. This really appears to be more about privacy protection, where each user session is unique and non-correlatable to some user preferences. For me personally, I don't see the utility in this, but I guess some paranoid Netflix user might want to make sure nobody can know that they watched "Fluffy bunnies" at 2am in the morning.

    • (Score: 0) by Anonymous Coward on Sunday April 19 2015, @09:07PM

      by Anonymous Coward on Sunday April 19 2015, @09:07PM (#172933)

      HTTP2 standards don't require encryption, but all current implementations of HTTP2 do, which makes it a de facto requirement. Netflix probably expects that future protocols will de facto require encryption and they're future-proofing for the death of HTTP.

      • (Score: 2) by subs on Monday April 20 2015, @12:39AM

        by subs (4485) on Monday April 20 2015, @12:39AM (#172977)

        HTTP isn't going anywhere any time soon, so I don't think that's much of a concern - I'm positive it's here to stay for at least another 20 years. Plus, worst case they could use their own custom protocol if, for whatever bizarre reason application stacks somehow stopped supporting HTTP.

  • (Score: 1) by purpleland on Sunday April 19 2015, @08:00PM

    by purpleland (5193) on Sunday April 19 2015, @08:00PM (#172910)

    Anyone know much about nginx - their HTTPD server? I recently discovered it then started reading about it, and have been pretty impressed about their architecture (event driven, asynchronous). If I'm not mistaken it inspired some aspects of Apache 2.4. I also see similarities in the architecture of node.js.

    If you're designing the next generation of highly scalable systems, this seems to be the approach to adopt - a shift away from the more traditional thread based mindset.

  • (Score: 4, Informative) by VortexCortex on Sunday April 19 2015, @08:05PM

    by VortexCortex (4067) on Sunday April 19 2015, @08:05PM (#172913)

    A video (and most other content) can be identified even while encrypted by the traffic signature it generates, the size of the download alone is enough to identify most videos when cross referenced with the availability / popularity matrix. As is common knowledge round these parts, the PKI Certificate Authority system is completely broken. Any CA can be compelled to generate a false cert for use by state actors, and furthermore, the security of the OSs that generate the certs are laughably insecure. Yes even GNU+Linux or BSD boxen have exploits that any skiddie with ~US$3k can purchase on the exploit market and they come pre-configured to deploy via popular exploit toolkits. This is how the NSA gets its exploits too. [theatlantic.com] Furthermore, today's SSL means that 3rd party collocation servers must be trusted to provide the "secure" handshake because encryption must be applied atop content at the point of delivery from the cache -- It's not like Netflix will be hosting all the content in house and applying the TLS on their systems prior to transit -- Current Crypto doesn't work that way, but a custom cipher could pre-authenticate a signed stream of data and allow caches to transmit that, but that's not "SSL" or "HTTPS".

    What is needed is authentication to ensure no one has injected malicious exploits into the video stream that target the video app or codex. The problem is that SSL doesn't work well with caching; Thus, invoking ye ol' Mixed Content warning (secured page/app/metadata requesting unsecured assets/content). One solution is to digitally sign the content. I have long proposed a modification to HTML to allow secured pages to provide an attribute for Hashed Message Authentication Codes. The secured page would have something like:
    <img src="..." key="YW9ldXN0bmgK" hmac="SHA-512;Base64=OGEwYTY1MDliOTYyNDM2N2EwMjU1ODViZTc1MTc1NmMyMDk1YWYzYgo=">
    The browser user agent / application can then pull in the secured (uncatchable) page and then verify additional unsecured content has not been tampered with by testing: Hash[type].HMAC( key, src_data ) == hmac;

    However current methods of signing require the entire video/content stream to be fed to the hashing system. Authenticated Encryption is the new hotness in cryptography which crypto folk are competing for standardization of. Authenticated encryption systems provide tamper proof encryption; Traditional stream ciphers are weak against tampering of blocks such that when the modified stream is decrypted you get "gibberish" in the modified bytes and they are then treated as valid bytes. This is a problem due to Chosen plaintext attacks and other forms of cryptanalysis. Say we know there's an exploit where a frame byte-length is a signed value but not expected to become negative. We only need to flip one bit of the length value to generate a negative value. This often allows one to overwrite memory structures with the payload data. If we know what the video is, then we can select the frames that happens to have the bytes that match some opcode we want positioned in memory and flip the bits of the TLS stream required to perform exploit. Authenticated Encryption prevents such attack by ensuring that the data sent was the data received.

    However, most authenticated encryption schemes still have the property that the entire encrypted content must be fed through prior to authentication. A work around is to break the data into smaller chunks which are then authenticated individually. Rekeying the cipher of most authenticated encryption suites is a significant performance penalty. Long before mainstream crypto academics were aware of or working to solve this problem I came up with a simple solution: Use a hashing algorithm as the cipher. A random initialization vector precedes the cipher stream (possibly signed, or transmitted via public key crypto). This I.V. is HMAC'd with a key and key stretched to generate the passphrase. The first block of data is enciphered using HMAC( key, IV ) as the passphrase. The plaintext of Block0 is fed into a clone of the hashing function that was created prior to finalizing the hash. Then the next HMAC is computed, HMAC(key, IV + Block0), where "+" indicates concatenation, and this output is used to encipher Block1. Block2 is enciphered with HMAC( key, IV + Block0 + Block1 ), and so on.

    This is a form of cipher block chaining which requires all prior blocks to be unmodified or the result is complete gibberish. Although each block is HMAC'd with all prior blocks, the cloning of the hash data structure avoids having to re-hash every prior block each time, so it runs in O(1) constant time. When decrypting, each prior decrypted block's plaintext must remain unaltered or the invalid HMAC will not work. This alone doesn't create the authenticated encryption. One more modification does: Each N blocks of data (prearranged via protocol) include a hash of the HMAC that is expected for the next block in the series (auth_bits). The decrypting end can then verify that the entire series of blocks up to that point matches HASH( HMAC( key, IV + Block0 ... BlockN ) ) == auth_bits, and the auth_bits are not included in the decrypted data stream (they're ignored as auth overhead). This allows the stream to be authenticated every n blockbytes with very little overhead (one extra hash finalization round).

    I built a flexible cypher system that utilizes only the HMAC (and stretching of it via hashing it again) to XOR, roll and mix bits as block-cipher. This turns a single "one-way" hash into a two way authenticated cipher and can be upgraded by dropping in any hashing algorithm. My first version used MD4, but I have dropped in all the hashes up to the current SHA3 family to "upgrade" the cipher over the years. The new authenticated encryption systems are still trying to solve the problem without including overhead (or with as little as possible), but the per-authenticated segment overhead is fundamentally unavoidable if strong authentication is desired. 8 to 16 bytes overhead per ~8k seems more than acceptable overhead to me, even when ciphering file system data blocks. My crypto system can also be used with a no-op cipher to provide authenticated and non-encrypted blocks, such that the per-connection HMAC stream can be transmitted in parallel to play well with caching systems while allowing the stream to be authenticated in chunks (prior to sending them into a most likely vulnerable codec).

    Modern encryption suites are not well suited to todays demands for authenticated data streams. The "common wisdom" of "don't roll your own cipher" merely creates a single point of failure in adoption of standardized crypto suites. Don't roll your own if you're not a cryptographer, otherwise constructing ciphers for your applications from tested crypto primitives is the way to go, especially if you don't want to have to trust the horribly broken CA system. I deploy secure pages with JS on them which can perform authentication of external resources (fetched by XMLHTTPRequest so I can get at them before the browser's image/audio/video codecs do). That means I can deploy my systems right now without waiting on design-by-committee bureaucracy of a "Standard Committee" (an oxymoron). Also, be sure to notify the authorities (NSA and BIS if you're a USA-ian) of the source code prior to publishing your open source crypto systems such that they can be accessed internationally; In the US, You may be exempted from notification and source publication if the ciphers are only used for user authentication and/or content protection as long as your product does not permit "general purpose" encryption. Running afoul of export restrictions is enough to scare most projects into not creating new crypto, thus making the single points of failure that much more valuable. Consider the manpower to analyze and design a custom crack for your custom encryption a great boon to your security, even if it's weaker cryptographically than industry standards. The more ciphers we create, the less popular each is and thus less likely they'll have a crack for the one you're using -- besides, it keeps some spooks employed trying to keep up with us.

    The mixed content / caching issue can be solved if the presentation layer (HTML on the web) is not forced to remain ignorant of the security layer. Already the HTTP layer is aware of the security layer, see also the "secure" cookie parameter that only transmits a cookie if HTTPS is present. The HTML key/salt + HMAC properties could likewise exist in the HTTP layer, but this would mean slower adoption since servers upgrade slower than web site code and browser features.

    TL;DR: The primary TLS bottleneck is in the public key crypto "authenticated" key exchange. Encryption of video and images isn't very valuable, what we need is authenticated data; And we can get that a number of ways via simple modification to clients (include a stream of HMACs). The future will be authenticated encryption, but I can assure you it will be implemented in a broken and retarding manner, just like all web security to date (see: multiple SSL protocol (re)negotiation hacks where a MITM simply tells one end to use a weaker/broken cipher). If your new stream cipher doesn't have built in cheap in-stream rekeying, then you're doing it wrong.

    • (Score: 0) by Anonymous Coward on Sunday April 19 2015, @11:48PM

      by Anonymous Coward on Sunday April 19 2015, @11:48PM (#172968)

      > A video (and most other content) can be identified even while encrypted by the traffic signature it generates

      One pause/rewind/fastforward and that's out.

      > Any CA can be compelled to generate a false cert for use by state actors,

      State actors aren't the threat in this scenario. It is your ISP and anyone operating the intermediary hops.

    • (Score: 2) by Yog-Yogguth on Tuesday April 21 2015, @03:39AM

      by Yog-Yogguth (1862) Subscriber Badge on Tuesday April 21 2015, @03:39AM (#173381) Journal

      Have a listen to the great audio an AC posted [soylentnews.org]. They're not mixing objects. Lots of detail in the audio (and more to come in a year: papers) that would interest you (too much work to transcribe and the questions are intelligible to me).

      --
      Bite harder Ouroboros, bite! tails.boum.org/ linux USB CD secure desktop IRC *crypt tor (not endorsements (XKeyScore))
  • (Score: 0) by Anonymous Coward on Monday April 20 2015, @03:00PM

    by Anonymous Coward on Monday April 20 2015, @03:00PM (#173143)

    On the one hand I applaud them for protecting customer privacy (from everyone but themselves...). On the other, the protection against injection could be handled by signatures, this would save Netflix a lot of money (signatures need only be calculated once per packet, not once per packet per stream).

    If you ask me, the fact that they are willing to swallow this cost likely means that they are just trying to keep competitors from that juicy information about who watches what, protecting everything except that could be done in a way that only cost the customers (verifying signatures) not themselves.