mjhjmtu

I'm working on a cryptosystem that uses colour pictures as keys for encryption. I'm trying to guess what is the key size of my cryptosystem in order to find the feasibility of a brute force attack. My cryptosystem uses RGB pictures of any size M x N.

I haven't found a paper that tries to do the same calculation yet. Any idea on what the key size is?

A picture is far too large to use as an encryption key directly, you'll want to run it through a KDF first.

It also depends entirely on the picture whether it will have enough entropy to be useful. You could have a 1000x1000 image that's solid white, but it would be useless as a key as it contains no entropy. Pictures from cameras tend to have a fair amount of entropy in the lower bits, so that could be ok, but your users would need to understand that not just any picture is a good key.

Pictures as keys is in general not a great idea. Pictures are usually taken to be shared, and keys are something you don't want to show to everyone. Using a picture as a key also sounds to me like it could be relying on security through obscurity (i.e. you just use an image from the thousands you have on your computer, but that's effectively very low entropy, probably under 20 bits unless you have an insane number of pictures).

Feel free to continue developing this for the sake of learning, but until you have a much better grasp of cryptography it's better to leave this sort of thing to the experts (see Why shouldn't we roll our own?).

Any cryptosystem should have keys with keysizes at the 128, 192, and 256 bit-of-entropy security levels.

So the question comes back to you: where are these images coming from and how much entropy do they contain? If they are completely random bit streams that are being interpreted as an image, then (ignoring entropy loss from lossy compression codecs), you get log_base2(256x256x256) = 24 bits of entropy per pixel, so you'd need 6 / 8 / 11 pixels respectively for the 128 / 192 / 256 bit security strengths.

If you're not generating completely random images and instead allowing people to use, like, photos, then I have no idea how you'd even begin estimating the amount of entropy in one of those.

Bottom line: using images as key material seems like a really odd thing to do and conflicts with the common practice that key material be completely random data from a cryptographic-strength RNG.

Also, from the information in your question, I'm not convinced that brute-force is the attack you need to worry about; I'd be more concerned with the "get access to their laptop and try every image on their hard drive" attack.

There are a lot of problems with this approach even before looking at the entropy involved.

Even though there is no background included, there are probably issues below that will trip you up.

1. How does the user provide the image to the system in a rigorous way?


2. Using a url to retrieve the image requires (secure dns/network/pki and probably cache).


3. Does the user need to warrant that the image is the same? (a lot of encoding change can be made in an image before it looks different to the user).


4. What if the user has eyesight issues/monochrome monitor?


5. What if system has a compromised display subsystem (to grab image or alter image).


6. Maybe all you need is a secure hash of the image anyway.

I think for encryption AES is recommended 16, 24 or 32 bytes key length (probably 32 bytes is the best option). However this depends a bit on the library you choose, but you can start by using that lengths in your research and keep us up to date on your research.