Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - rubixcom

#1
Feature Requests / Re: Optional Image Encryption
January 24, 2014, 01:48:35 AM
Quote from: g3gg0 on January 23, 2014, 11:50:35 AM
so anyone - provide me a "uint32_t cr2_inject(char *cr2_filename, char *jpg_name)" and i will embed it ;)

Happy to give it a go :). But, being quite unfamiliar with CR2 file structure, ML source code and having not touched C++ in 13 years, it might take me some time.

I am guessing that to implement this properly, you'd need to:
1) Extract only the Huffman compressed DCT data from the source JPEG. The reason for this is to reduce the chance of anyone brute forcing the password until they detect any common JPEG structures or image sizes within the decrypted data. The obvious downside of stripping these headers would be that image parameters such as image size, colour format and etc would not be stored. The user would have to supply those while extracting the images. Also, a non-easily identifiable method of storing the Huffman tables would also have be devised.
2) Encrypt this data using the password supplied.
3) Extract raw sensor data from target CR2 as a bitmap (I image that there should be code for this at dcraw)
4) Store encrypted data inside the least significant bits of the pixels from the bitmap image decoded from the CR2 raw sensor data. The pixels that are modified would have to be dispersed throughout the image in a random fashion based on a part of the password. If sequential pixels are modified instead, an attacker may notice an increased amount of noise in the certain areas of the image.
5) Re-compress and save the CR2 file (I imagine ML would have some utilities for this) ensuring that the created/last updated timestamps are not updated.

The user must also be forced to give at least a 10 character password otherwise the whole thing is still quite vulnerable to brute force attacks.

This would need to be done properly as people tend to (perhaps foolishly) put a great deal of faith in encryption.

Thanks,
Alfred
#2
Feature Requests / Re: Optional Image Encryption
January 23, 2014, 08:26:58 AM
This is such a great feature. Can't wait to try it.  ;D

My 2 cents with regards to deniable encryption; storing sensitive/secret images inside least significant bits of raw sensor data part of a CR2 file seems like the best option to me.

So the scenario might be:
1) Photographer fills his card with CR2 images.
2) He/she enables "stealth mode" and provides a password.
3) Any photos taken from that point are shot as JPEGs only but are not actually saved as new files, instead they are stored within least significant bits of sensor data inside existing CR2 files. Which CR2 files are modified could be determined by the encryption algorithm or selected by the photographer. Image data would also have to be encrypted (or at last stripped of common headers/identifiers) before being stored so that the noise would appear random.
4) If the camera or memory card is taken away and inspected, all CR2 images simply appear to contain an amount of random noise as you would expect in a CR2 file.
5) Photographer gets home and copies the files to his PC where he uses a separate application to extract the images.

Since CR2 files are huge, it might even be possible to store a few different low res JPEGs inside to allow the photographer to reveal 1 or 2 sacrificial passwords if the interrogators become suspicious that stenography is used.

Also, if not possible to do this in real time, perhaps a script to hide secret images could be developed and run adhock from the ML menu.

And while on the subject of security; how about another script to fill unused space on the card with random noise so that deleted pictures cannot be extracted later with photo recovery software.

Thanks to all hard working devs,
Alfred
#3
Stupid question; how do I invoke the included scripts from the ML menu?

Many thanks,
Alfred
#4
Having a minimum aperture in Tv mode would be great too.

New to ML, but loving it already.

Thanks,
Alfred