Slashdot Mirror
HDCP Encryption/Decryption Code Released
rtj writes "We have released an open-source (BSD licensed) implementation of the HDCP encryption/decryption algorithms. The code includes the block cipher, stream cipher, and hashing algorithms necessary to perform an HDCP handshake and to encrypt or decrypt video. The code passes the test vectors provided in the HDCP specification and can encrypt video at a rate of about 180 640x480 frames/second on a 2.33GHz Intel Xeon CPU. This isn't quite fast enough to decrypt 1080p content in real-time on a single core, but decryption can be parallelized across multiple cores. There are also many opportunities for further optimisation, such as using SSE instructions. We are releasing the code in hopes that others will further optimize it and use it in their HDCP-related projects."
Get it on a shirt, on Digg, and in sigs everywhere!
Living With a Nerd
So does this negate Intel's statement that you can only do this if you build a chip with the code in it?
HDCP is dead.
Netcraft confirms it!
I guess the next logical step would be a GPU implementation....
It just means you can't do it in realtime on a 2.5ghz core2... Nothing to stop you dumping the encrypted data somewhere and decrypting it later.
Also consider a 2.5GHz Core2 isn't all that modern, and it doesn't even specify wether this cpu is dual or quad core. With 6, 8 and even 12 core processors available, plus the possibility to parallelize over multiple processors 60fps is quite achievable today.
There is also the possibility of using a GPU to do this.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
Not quite.
They said decryption of 1080p is 7x slower than 640x480, not that decryption is slower than encryption. This makes sense as 1080p is approximately 7x more pixels than 640x480!
Those rates are for a single core. They say that decrypting 1080p is ~7x slower than 640x480, which correspond well to 1080p having 6.75x more pixels.
However, there's no reason for this to be restricted to run on a single core or a single machine. If somebody were to use this for distributing a real time stream (e.g, a sports broadcast) there's no particular reason to not just have each recipient of the stream do their share of the decryption.
Running the number, getting 60 frames of 1080p from the Core 2 requires 5.33 cores, which would correspond to three dual-core machines. This means you can't, with today's machines, just share it with your friend if you both have dual core Core2 machines - but with two friends it should work, assuming enough bandwidth available from each of the friends: 3Gbit/s for the full unencrypted stream, plus 1Gbit/s down for the stream to be decrypted, plus 1Gbit/s up for the part of the stream decrypted on that machine.
You'll also get real time decryption on a single Gulftown CPU: E.g, a Core i7-980X runs 3200MHz and has 6 cores.
Doubting the existence of evolution is like doubting the existence of China: It just shows that you're uninformed.
60fps, why? That is 2x real-time, or a bit more than 2x if the source is 24fps. Once they are able to break 30fps decrypting in real-time, this is golden. It's only the first step, but it's an important milestone.
Any bets on when we see this implemented in more full-featured software suites?
Never, as no software suites have any use at all for HDCP.
HDCP is used only for encrypting content as it travels across the cable to the display. Only devices connected to the display cable will ever see HDCP-protected content. Software players process the data before it is encrypted with HDCP.
The only thing this is good for is for wiretapping a display cable to capture uncompressed video, or for making a box that fools your paranoid computer into believing the display connection is protected.
if it was just you, it isn't now
*bana wah wah. wah. wowadah wowa da wah wah*
It pays to be obvious, especially if you have a reputation for being subtle.
There are already bootleg hardware HDCP strippers on the market. It used to be possible to shut down these devices by revoking their keys, but that's now gone out the window with the master-key leak. Expect the next generation of devices to let you upload new keys to them, or maybe generate new keys themselves.
Software decryption is kinda interesting but you're right, hardware is where it's at.
Blu-ray supports 720p at 59.94 fps. That's a greater amount of data than 1080p at 24 fps. 720p59.94 is also one of the Blu-ray 3D supported resolutions (i.e. doubling the differences with 1080p24 further).
Nice, a Braille reader for BluRay subtitles should now be technically possible. BluRays make decent eBooks with the right software.
(HDMI neglects to ship closed-captioning data so you *have* to capture/diff/ocr from HDMI rasters to extract the text).
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
When you watch a DVD or Bluray, the content is decrypted, then encrypted and decrypted again for HDCP.
A significant amount of energy is devoted to protecting the pre-internet business model.
This will only get worse over time, as media gets larger and media companies more aggressively cling to the old business model.
It took more than 100 years for the world to really adjust to the printing press. I assume at least the same time period for the Internet, before we can have our enlightenment period.
DRM must be really really costly. And the bad thing is we're all paying for it - the honest customers even more than the "pirates" against which it is supposed to protect.
When I see how much computing resources it takes just to en/decrypt a stream - OK it's a general purpose processor, not something dedicated - I am thinking of the cost of those resources in all the devices we have. After all your BluRay player has to read the BR disk, decrypt the content, then encrypt it again to an HDCP stream, which is sent over to say a TV, which then decrypts it again to make it a watchable image.
Now if only we wouldn't need that encryption.
BluRay itself is (all but) cracked, that's one decryption step that can be done away with.
HDCP transfer is now done with; that's another two steps of en- and decryption that can go.
That is at least three pieces of beefy hardware. That's three chips that won't come for a few pennies each. That's three chips that will be wasting significant amounts of energy.
Plus of course the huge upfront cost to develop all that: to develop the algorithms, set up the secure key supply, designing the dedicated de/encrypt chips and writing all the software around it to make it work.
And all of us are paying for it. It makes BR players and disks and HDCP compliant hardware more expensive than necessary, it even increases our power bills unnecessary. I really wonder when this madness can come to an end.
a raid 5.1 of 10k rpm sas drives say, 12 spindles, should be enough. maybe 4 500GB SSDs would be as well.
So no i don't have A disk that can do it, but you can do it with a few disks.
All of the above was encrypted with a Quad ROT-13 method. Unauthorized decryption is in violation of the DMCA.
I'd love to see a device that generates a new key every time it boots up. The ultimate unblockable device, no matter how many keys get revoked.
FC Closer
But ripping discs isn't really the target here. There are already tools available which can rip BluRay discs in software, without having to read a disc and play them over the wire in real time. More practically, this is targeted at streaming video sources such as video from your cable company, or perhaps for ripping from your cable company's DVR. Those streams are seldom (never?) higher than 1080i or 720p at standard frame rates, so 30fps in real time gets the job done.
I'm not saying 720p at 59.94 is worthless, but 30fps would support the majority of use cases.
You've got a disk which can store decompressed 1080p in real time?You've got a disk which can store decompressed 1080p in real time?
It's my understanding that many new-fangled media devices have "pause" buttons that would enable you to break the task into manageable chunks.
Dewey, what part of this looks like authorities should be involved?
China. Where's my pass-through video card I can put in my MCPC to overlay text and graphics on my TV? I want to feed my TIVO into my MCPC so I can control my own PIP and overlays. I couldn't care less about pirating the stuff myself. If I want a local copy of something, it's already out in the wild - I'll get it that way. I just want to be able to control my media and view what I want how I want.
--- Keep the choice with the user..
I don't have a DVR, but a common complaint about CableCard is that a) many cable companies charge $5/mo for the card (which is as much as it costs to rent some of their DVRs), and B) CableCard is only supported using certain PVR software under windows (encrypted things have to be stored encrypted on disk). I could be wrong, but I think only MS's software supports it.
Though, honestly, with netflix and hulu, I don't see a reason to store gigs and gigs of video like I used to.
-Bucky
"never pays for anything"
I pay for physical goods that aren't in infinite supply.
"and complaining when companies try and protect their revenue."
Sorry, but when it hurts legitimate customers in the process, it's not worth it. DRM, HDCP... it's all the same annoyance. Eventually (often extremely quickly) it will be bypassed by the pirates and it will only hurt the legitimate customers (some will either be angry and stop buying future media, and others may even turn to piracy because still want the media). In the end, their 'protection' only hurts themselves and actual customers, not pirates. So, yes, people are going to complain.
Filthy, filthy copyrapists!
Problem with this: Your other devices will eventually get restrictions on them that only allow a certain number of new devices to be connected to them before they fry. Every new key counts as a new device.