Your Universal Remote Control Center
RemoteCentral.com
Custom Installers' Lounge Forum - View Post
Up level
Up level
The following page was printed from RemoteCentral.com:

Login:
Pass:
 
 

Original thread:
Post 34 made on Saturday June 12, 2010 at 19:43
crosen
Senior Member
Joined:
Posts:
April 2009
1,262
On June 12, 2010 at 19:02, Audible Solutions said...
You don't understand. I know you think you do. You've been told 3 times yet you still confuse the HDCP authentication with the encrypted data of the high speed data stream.

Hmm, well even after reading this post, I still think I do and that everyone is misunderstanding me, but let's see if we can't straighten this out.

To begin, all of my points have been on the high speed (TMDS) data.  This is where the encryption is applied.  I imagine we can all agree on that.

The OP complained of sparkles, and this means an issue with the high speed data.  I imagine we can agree on that, as well.

My point is that the high speed data must be retransmitted "from scratch" because it is sent with an entirely new key for encryption.

My point has nothing to do with the low speed data.  I do not intend to make any claim about whether it is passed through or retransmitted.  It's not that I am confusing this low speed and high speed data, it's that the low speed data has nothing to do with my point.

High speed data also includes the audio data stream. This data does not require authentication.

I did not know that this doesn't require authentication.

EDIT: Actually, I'm not sure what this means. I initially thought you meant that the audio portion of this does not required authentication, but that doesn't really make sense. If you're saying that there is no authentication performed directly on the TMDS lines because the authentication is already done before the stream starts out of band on the low speed lines, then of course I know that.

However, as I've said, I don't believe my point has anything to do with authentication.  The audio data is still sent encrypted over the high speed TMDS stream.  That's what I care about.

No data is sent till source and sink communicate and authenticate each other. This is done via low speed data or DDC channel. The AVR has nothing to do here but pass this signal on to the sink.

That's fine.  Again, I am referring to the high speed (TMDS) data.

At the point that source authenticates that the sink is valid the high speed data is sent. If not no data is sent and there's a black screen. It is this data that the AVR is decoding. Even here, it is only the audio portion that it will touch. The audio has its own header and the AVR is parsing the data stream for this header and only stripping out these bits from the data. All the rest is passed on. It may be buffered, parsed and then pushed out. But it's not being retransmitted as you imagine.

This is the crux of the issue. Let's look at this video data. When it arrives at the AVR, it is encrypted using the keys of the BD player and AVR, right? When it is sent from the AVR to the display, it is encrypted using the keys of the AVR and the display, right? It may be the same underlying data, but it is encrypted with different keys. That means it is not bit for bit the same when it is on the line. That is why I assert that it is being retransmitted.

Sorry to be daft, but I still do not see what I am missing.  If you could specifically address the last few sentences (in bold), that would help.

Last edited by crosen on June 12, 2010 20:29.
If it's not simple, it's not sufficiently advanced.


Hosting Services by ipHouse