[Matt Beard]

andreybl wrote:

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.

1) The EssenceSource is the entity that "knows" about the essence, as such it is the only object that knows what specific wrapping should be used for this essence. It can be queried for items such as the GCEssenceType and the GCElementType (for building a standard GC key) or for an override key if required. This allows an EssenceSource to supply encrypted data and have it correctly KLVWrapped by the GCWriter without the GCWriter having to be encryption-aware.

2) The current mxfrcrypt example application shows one way of producing an encrypted MXF file - it takes a plaintext file and encrypts each essence KLV. It writes these encrypted KLVs using the "raw" AddEssenceData method which adds an entire KLVObject to the output stream, rather than the other methods which each build a new KLV. This makes sense for this application as it is already reading a KLVObject.

The method that I am recommending is to write an "intermediate" EssenceSource (a sort of EssenceSource filter similar to a DirectShow filter). This would read plaintext data from an existing EssenceSource, encrypt it and then pass the encrypted data out as its output. About 99% of the work can be done by code re-use by having an internal KLVEObject. However, I notice now that a small modification would currently be required to the library code to enable the (currently commented out) WriteHandler code in KLVObject.

The small modification has been added to the short-term to-do list (but you could do this yourself quite easily) and the whole method has been added to the release 1.0 suggested features list.

[andreybl]

Hi, Matt.

I have a question about the mxfcrypt tool.

Short: according to my investigation, the IndexTable is lost after the encryption.

Detailed:
I've done the following steps, which are better to be described as the *.bat sequence:

Code:

mxfwrap.exe -a2 -f -ii2 original.mpg path.a\original.mxf
mxfdump.exe path.a\original.mxf >path.a\1.dump
C:\workspace-mxf\mxflib\mxfcrypt.exe -k=C:\workspace-mxf\mxflib\encryption.key path.a\original.mxf path.a\test_encrypted.mxf
mxfdump.exe path.a\test_encrypted.mxf >path.a\2.enc.dump
C:\workspace-mxf\mxflib\mxfcrypt.exe -d -k=C:\workspace-mxf\mxflib\encryption.key path.a\test_encrypted.mxf path.a\test_decrypted.mxf
mxfdump.exe path.a\test_decrypted.mxf >path.a\3.decr.dump

The comparison of the 1.dump and 3.decr.dump shows differences between them. The most important one is the absence of the IndexTable in the 3.decr.dump. There are also other differences between 1.dump and 3.decr.dump, which _may_ be important.

The bottom line is, that I would like to do mpeg->mxf->encrypted.mxf->decrypted.mxf processing, whereas decrypted.mxf should be readable by a mxf-Reader. But it seems so, as if some info is gone lost during encryption.

Thank you for support.

[Matt Beard]

The current release version does remove the index table, however if you check out the CVS version it correctly modifies the index table to index the encrypted essence, then again during decrypt to index the plaintext.

[andreybl]

Matt Beard wrote:

... however if you check out the CVS version ...

Which version und which files exactly do you mean? Neither the last version of the mxfcrypt.cpp (e.g. version 1.9) does not contain any calls to ReWritePartitionWithIndex, nor the previous versions. Which CVS Tag do I use best?

[Matt Beard]

The latest CVS version of mxfcrypt.cpp is 1.11 which contains calls at lines 343 and 350 to WritePartitionWithIndex()

You will also need the up to date mxflib library files.

Note: Due to the recent server problems at SourceForge the ViewCVS server is not up to date with the CVS repository so you will have to actually do a checkout or update to see the latest files.

[andreybl]

Matt Beard wrote:

The latest CVS version of mxfcrypt.cpp is 1.11 which contains calls at lines 343 and 350 to WritePartitionWithIndex()
...

Hallo. I've checked the latest version out, but the mxfcrypt seems not to be of the version 1.11. It is still 1.9. You mentioned, that the CVSBrowser doesn't use the up-to-date state of the CVS. As far as I understand, the actual CVS doesn't contain the latest version of mxflib either.

Maybe you could put the latest version onto the web? Thank you for the further tips, Andrej.

[Matt Beard]

From the SourceForge Site-Status page:

Quote:

( 2006-04-06 13:04:54 - Project CVS Service ) As result of the 2006-03-30 CVS outage, and previous CVS outages, some CVS repositories do not exist on the anonymous/ViewCVS CVS hosts. This will result in proxy errors and other various unusual results when trying to access those hosts. Once we get the CVS services into better order, we'll start the synchronization processes again and these problems will go away. Our primary concern right now is for the security and reliability of developer CVS access, after which we'll restore anonymous access.

( 2006-04-14 11:18:04 - Project CVS Service ) As of 2006-04-14 we have an estimate on when the replacement CVS hardware for the new infrastructure will arrive. As soon as we get in into our hands, we'll actively work on it, with a goal of having it online by the end of the month of April. This is a best guess, and may not get hit due to the aggressive timeline we have placed on this project. However, be assured that recovery of this service in full is our highest priority. The sync process between developer and anonymous CVS (ViewCVS, etc.) is disabled now until the new infrastructure is in place, to ensure we have maximum coverage for the small number of data corruption issues that have been detected. We understand this is sub-optimal, but strongly believe that the protection of the data is paramount.

It looks like non-developer CVS access is a bit broken!!

I will zip up a copy of the CVS (as visible to developers) and add it as a file release.

This should be there some time this afternoon.

[Matt Beard]

I have posted Windows and Unix source sets on the Source Forge downloads page:

http://sourceforge.net/project/showfiles.php?group_id=65032

NOTE: The Source Forge server seems to be struggling a little at the moment, so expect to see a few error pages!!