[baiqian]

I find there is a tool called mxfcrypt that do encrypt and decrypt mxf file,
but now I want to do encrypt and make mxf at one time.
I had looked at src in short times,but I did not find a visible way to do that.
so , I need some tips,thanks !

[Matt Beard]

This is an area where a little work is required in the library to make it easier.

At the moment I would recommend that you build a new class that is derived from EssenceSource and does the encrypting work.

This new class would take a pointer to the plantext source as a parameter to its constructor. And this new encrypting-source is what you use to build a BodyStream for the file.

Each call to GetEssenceData() would pull a new chunk of data from the plaintext source (using its GetEssenceData method), encrypt it and then pass the result out.

If a call is made to GetEssenceDataSize() one of two things needs to happen - either the size needs to be calculated from a call to the plaintext GettEssenceDataSize (plus the encryption overhead), or the chunk actually needs to be encrypted and stored, passing out the size. The next call to GetEssenceData can return this stored version.

Does this help?

[baiqian]

I also think it is a better idea!

[tbegin]

Hello

what is the format of the input key file to encrypt?

Thibault

[Matt Beard]

The format is 32 hex digits (a 128-bit number in hex)

The filename is also a 128-bit number as hex digits in the format:

xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

An easy way to generate these files id using the MXFGUI program that is in the Win32 binaries file in the latest release (0.6.0-Beta)

[tbegin]

Are MXFCrypt resulting mxf files really MXF specifications compliant?

Thibault

[tbegin]

Why is it the key filename that is used and not the key?
What is the aim difference between the key and its filename?

[Matt Beard]

This is to do with the way that dCinema do thier key transfer.

Each compressed file contains a 128-bit GUID that is carried in the encrypted file to identify the key. This is publicly visible.

This 128-bit GUID is used to "look-up" the decode key. The decode key is secret and is transmitted to the decoder via a seperate channel and stored in a secure database.

Some of the current dCinema software tools allow the keys to be extracted into files with the filename derived from the 128-bit key identifier (the GUID).

MXFCrypt builds a matching filename from the publicly visible GUID in the encrypted file, then tries to locate a key file holding the matching secret key.

Is this at all clear?

[tbegin]

Ok that is clear for the key. Thanks.

Is MXFCrypt used in commercial tools or is it experimental?
Is MXFCrypt really compliant to D-Cinema S423M Specifications?
Are the Universal keys of encrypted essences packets replaced or is there a KLV sublayer as described in DCinema specifications?
What are the D-Cinema tools you speak about? Do you work on one?

Thibault

[Matt Beard]

It should be complient with the latest version (but it is not yet finalized!)

There is some MXFLib code being used for real in digital cinema products, but I am not able to say more

[tbegin]

How the current available MXFCrypt component deals with triplets?:

as DC spec:
KLV => K’L’V’
with V’ = KL E(V)
then
KLV => K’L’ KL E(V)

Or
KLV => KL E(V)

Or
KLV => KL' E(V)

Or
KLV => K'L' E(V)

[Matt Beard]

It should be exactly the same as the DC spec where:

KLV -> K'L'V'

Where: V' is a variable length pack containing the K and L values from the original KLV as well as the encrypted V. It also contains a number of other items such as the Context ID and the valeu of Plaintext Offset. It also optionally contains hashing values.

[tbegin]

When I read a MXf decrypted file (result of mxfcrypt used as file descrambler) with metaglue mxffixer, I have a structural error: "Metadata in partition at 0xffffffffffffffff contains no Preface set". This error seems to be the cause of rejection by our video server. What this error means and how can I fix it?

thanks for your help

thibault

[andreybl]

IMHO, the GCWriter::AddSystemData is the right place to start with the encryption.

Actually, I was investigating the the mxfcrypt.cpp for the right entry point for the MPEG-Encryption. Then I saw the discussion about MPEG->EncryptedMXF here. The suggestion is to use the EssenceSource for the encryption. Well, I've got a couple of discrepancies with my previouse experience with MXFLib:

1) actual job for creation and writing of the KLV is done in GCWriter::AddSystemData. Shouldn't encryption be done somewhere in this method? Otherwise I'm expected to make setting of K and other thing somewhere in the EssenceSource. IMHO, the EssenceSouce should only know the source, and nothing extra from the MXF.
As I see, the CGWriter do not expect any KL from the EssenceSource. Neither can he recognize, whether the passed essence is encrypted or not.

2) Why is advice given to make encryption with EssenceSource, if the encryption is done with Encrypt_GCReadHandler? I would expect some kind of "reuse".

thank you for clarifications.

Matt Beard wrote:

This is an area where a little work is required in the library to make it easier.

At the moment I would recommend that you build a new class that is derived from EssenceSource and does the encrypting work.

This new class would take a pointer to the plantext source as a parameter to its constructor. And this new encrypting-source is what you use to build a BodyStream for the file.

Each call to GetEssenceData() would pull a new chunk of data from the plaintext source (using its GetEssenceData method), encrypt it and then pass the result out.

If a call is made to GetEssenceDataSize() one of two things needs to happen - either the size needs to be calculated from a call to the plaintext GettEssenceDataSize (plus the encryption overhead), or the chunk actually needs to be encrypted and stored, passing out the size. The next call to GetEssenceData can return this stored version.

Does this help?

[Matt Beard]

tbegin wrote:

When I read a MXf decrypted file (result of mxfcrypt used as file descrambler) with metaglue mxffixer, I have a structural error: "Metadata in partition at 0xffffffffffffffff contains no Preface set". This error seems to be the cause of rejection by our video server. What this error means and how can I fix it?

thanks for your help

thibault

Can you send me a small decrypted MXF file that shows this error? It would also help to have a copy of the encrypted file and the key file.

What version of the software are you using?