Encryption/decryption support

I would like to query if mrtix3 is capable of encrypting/decryption DICOM tags conformant with the DICOM standard http://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.12.html#sect_C.


I’m afraid we don’t have the capability to decrypt DICOM data, unfortunately. I’ve had brief look into it, and it doesn’t look trivial – though it could of course be done given sufficient time and motivation.

If you have example data that I could have a quick look at, I might be able to get a better idea of how much work would be involved. I have a feeling the openSSL library might provide the required functionality. But it would still be a low priority issue for us. Happy to help anyone interested in implementing this, though!

All the best,

My intention was to encrypt DICOM and test by using some software to decrypt. I, unfortunately, don’t have any encrypted DICOM that would be trust-worthy for testing decryption.

The big problem is that it seems that encryption does not seem to be implemented anywhere, but am wondering whether anyone is aware of some software or PACS system that does encryption or decryption according to standard.

OK, I see what you mean. I’m afraid I’m not aware of any implementation that would support encryption, sorry.

I might however ask what you’re hoping to achieve here? If you’re interested in secure archival and/or transmission of your data, I would suggest standard generic solutions to encryption would be a much more appropriate and future-proof solution to the problem. For example, 7-zip archives can be encrypted and password protected using AES-256 – and it’s open source.

Personally, I think the problem of encryption should be considered separate and independent of DICOM as a storage format – trying to tie the two together into a single specification is in my opinion asking for trouble. Indeed, I suspect this is the main reason for the lack of adoption of encryption in DICOM implementations: with DICOM being a standard, the encryption algorithm mandated in the specification will eventually become obsolete, rendering efforts to implement and maintain it a waste of time. If any flaws in the encryption technique become known, the encryption immediately ceases to be effective, and at that point there’s no standard-compliant alternative. Besides, most of us software developers working in medical imaging aren’t knowledgeable enough about encryption for our implementation to be trusted – best to leave the encryption side of things to dedicated tools maintained by the relevant experts in the field…

What I was hoping to achieve is a way to ensure encryption of important data in the DICOM file when storing in an Orthanc server, without having such server be able to decrypt the encrypted data.

I fully agree with your argument.