In one of the other posts in the DS forum someone had mentioned in order to satisfy Sony’s requirements (with regards to sending DSD data out through HDMI or I2S) that encryption had to be performed.
I’d like to learn more about this. Does anyone know about the encryption algorithms Sony mandates and keying mechanisms used? Any pointers would be appreciated.
The point is that you can’t have enough information to decrypt it and (at least in the United States) it’s against the law to divulge it or to reverse engineer it.
On SACDs the keys are encoded in the widths of the pits on the SACDs TOC. (Except for varying pit widths the DSD layers of an SACDs are just a DVD layer.) I seem to remember that it was some sort of public key encryption, but don’t quote me.
FWIW I don’t know exactly how the data will be encrypted coming from the new transport, but presumably PS Audio will tell me at some point so I can make an FPGA that can understand it 
[edit] I guess I could add that you could look up the datasheets for an HDMI support chip that handles DSD and you’d get an idea about how the HDMI hardware supports DSD encryption.
Tho I mentioned HDMI and PS Audio’s I2S link is over an HDMI cable and HDMI connectors it’s not HDMI and PS Audio will be inventing their own encryption to keep the raw bits from being exposed in the wild.
Thx Ted.
What makes this interesting is that Sony invented the encryption scheme without the need for the transport box to have any IP network-connectivity (which is unlike the DOCSIS cable modem boxes and Apple iPods).
If I had to conjecture, I would guess the following.
There is a strong pairing between the SCAD discs and the laser disc-drives. This could explain why the drive component can be obtainable only from a limited number of suppliers (probably in Japan) and that only a limited number of plants (two?) can manufacture SACD discs.
The SACD disc themselves probably have blocks of data (boot and authentication) that are encrypted using the private-key of Sony (multiple and probably hierarchically arranged). This would probably allow Sony to inject the public-key(s) into the crypto chip/module in the laser-drives at manufacturing. More importantly, it would allow Sony to create new keys for new discs while preserving backward compatibility (new discs works on old SACD-transports).
Instead of inventing your own encryption algorithm/protocol, would PS Audio consider using the new HDCP2.2 encryption (without the HDMI) that’s being used for 4K video?
For the new DS Transport, yes I understand that the “HDMI” is just cable for communications/connectors and that the DST is not using the actual HDMI protocol exchange.
Ted Smith saidFWIW I don’t know exactly how the data will be encrypted coming from the new transport, but presumably PS Audio will tell me at some point so I can make an FPGA that can understand it
Ted, that’s a startling comment to me. Paul has said recently that the new transport will be in Beta testing in June, but you don’t have encryption code yet? I’m pretty sure he also said it would be incorporated into the next FPGA update, which is being finalized right now, correct? While I have no clue how all this is done, I’m under the impression that how the code is compiled effects the sound quality, so shouldn’t the encryption be in the mix now?
They must have a lot of faith in me No, I don’t think the next release of the OS will have support for the new transport - there’s enough going into it already and if we had to make sure that the new transport worked with it we’d need to have the new transport almost done before we could release the next version of software. Having something for beta doesn’t require that it has been auditioned by Arnie, etc. so getting a version of the FPGA that supports the new transport isn’t a whole lot of work. (I.e. getting great sound is the biggest part of any FPGA development.)
pmotz saidTed Smith saidFWIW I don’t know exactly how the data will be encrypted coming from the new transport, but presumably PS Audio will tell me at some point so I can make an FPGA that can understand it
Ted, that’s a startling comment to me. Paul has said recently that the new transport will be in Beta testing in June, but you don’t have encryption code yet? I’m pretty sure he also said it would be incorporated into the next FPGA update, which is being finalized right now, correct? While I have no clue how all this is done, I’m under the impression that how the code is compiled effects the sound quality, so shouldn’t the encryption be in the mix now?
There’s a difference between the amount of work it takes to modify the FPGA and the amount of work it takes to modify, say C code in the control processor. Similarly there’s a difference between the amount of work that needs to be done / sample and the amount of work that needs to be done at setup. For example, negotiating a session key can be done in the high level code leaving something as simple as an XOR to be done per sample in the FPGA. I’m not implying that’s what would be done, but you get the idea. It’s not really a big thing from the FPGA’s perspective and hence there won’t be any audio sound quality issues.
Out of curiosity, will the DS still be able to understand unencrypted streams via its I2S inputs after this change has been implemented?
I’m sure as there are a good number of DSD downloads which are encrypted.
TarnishedEars said Out of curiosity, will the DS still be able to understand unencrypted streams via its I2S inputs after this change has been implemented?It already does: If you have unencrypted raw DSD or DoP on any input that current supports it it will continue to support it. We'll just be adding the ability to handshake with the new transport for "more features", not restricting anything that the DS currently does.
Elk said I'm sure as there are a good number of DSD downloads which are encrypted.Could you explain more about this? I have purchased many DSD files from several vendors and (as far as I can tell) never encountered any that are encrypted. How would one know? How would one play them back? Or maybe you are thinking of ISO images, which can be (I think) encrypted, although the few I have aren't.
I am sorry, this is a typo; encrypted should have been unencrypted.
