Dfyjkt

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.

The picture is also generated by a chaotic attractor which is sensitive to initial values, so each picture generated is different. These pictures are an example:

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

Your most recent edit indicates that your pictures are procedurally-generated, so your key size will therefore be bounded by the amount of state required to generate an image. Yours seem to be parameterized by four floats for the initial conditions (and fixed output image size, camera location, point light location, convergence conditions, etc).

Those 128-bits of state will then be transformed into an image by an algorithm that depends solely on your provided state, so your image "key" cannot contain more than 128 bits of information. In fact, I think that entire classes of initial values produce identical outputs (e.g. when all four floats are extremely small), so your image "key" size will be strictly less than 128-bits.

There's really no benefit to touching the 128 bits of state by turning it into an image (and then somehow back) if you only reduce the size of the key by doing so.

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.

I can tell from the images that your key size is significantly less than the size of the images (because otherwise most of them would look like random coloured static).

Your key size is less than or equal to the base 2 logarithm of the total number of different images your chaotic attractor program can generate.*

That's another way of saying your key size is less than or equal to (probably less than) the amount of bits it takes to specify all of the inputs to your chaotic attractor program.

If you hash the image and use the hash as a crypto key, your key size is equal to or less than the size of the hash.

*That's your exact key size if your encryption algorithm is something like "XOR each bit of the image with the corresponding bit of the plaintext" (don't use that algorithm for important secrets, BTW, because parts of the message covered by the grey areas in your images could be super easy to decrypt).

tl;dr- You're proposing a key-stretching algorithm that turns 128 bits of input into a much larger key. This isn't as good as simply using a much larger key of the same size, though it's not necessarily as weak as the 128 bits of input. That said, your bitmap looks very ordered, which strongly suggests that it's far weaker than a randomly generated bitmap.

According to @Blender's answer, you're just using 128 bits to generate the picture. I'm guessing that you want the picture itself to count as a key larger than the 128 bits that you put into the algorithm that generated it. And it might.

Specifically, what you're trying to do is create a key-stretching algorithm that attempts to stretch 128 bits of input into a much larger key. This isn't necessarily fruitless, but there're things to be aware of:

1. A key-stretching algorithm can be vulnerable to brute-force of the input. For example, even if someone couldn't reverse-engineer the picture-generation algorithm, they could try all $2^128$ possible inputs to generate all possible $2^128$ possible pictures, then try each. To guard against this, you'd need to ensure that the picture-generation algorithm is too expensive for such an attack to be feasible.




2. Your picture looks far from random at local scales. This is, anyone looking at a few pixels of it can probably guess the neighboring pixels with better-than-random odds of success. This means that the algorithm isn't pseudo-random, even against an attacker who can't reverse-engineer the picture-generation algorithm.




3. Your picture looks far from random at the global scale. This is, the displayed shapes have global geometry, plus the images waste pixels on a well-behaved background. This significantly weakens the pseudo-randomness again, potentially suggesting that it might be easy to fully break.




4. There's no real advantage in a key-stretching algorithm producing a picture as opposed to any other representation of the same data. Granted, the stretched key does look pretty as a picture, but that prettiness merely reflects its weakness vs. a randomly generated bitmap.

This website seems to generate random black-and-white bitmaps with specified dimensions. For example, here's a $250 times 250$-pixel bitmap:
                              .
This bitmap is (supposed to be) random in that an attacker looking at any combination of its pixels shouldn't have better-than-even odds of guessing what another pixel might be.

How much entropy?

Unfortunately this site doesn't have MathJax enabled, so it's hard to answer your question directly without it looking weird. Here I'll write a response as-though MathJax were available.

The set of randomly generated RGB images of a given length-and-width contains$$left(n_textRed , n_textGreen , n_textBlueright)^n_textwidth , n_textheight , textmembers
,,$$where:

• $n_textRed$ is the number of possible values for a pixel's "red" dimension;




• $n_textGreen$ is the number of possible values for a pixel's "green" dimension;




• $n_textBlue$ is the number of possible values for a pixel's "blue" dimension;




• $n_textwidth$ is the number of pixels in the width; and




• $n_textlength$ is the number of pixels in the length.

Then since entropy is the $log_2left(n_textmembersright) ,$ this'd be$$
beginalign
left[ textentropy right]
& ~=~ log_2left(
left( n_textRed , n_textGreen , n_textBlue right)
^n_textwidth , n_textheight
right) [5px]
& ~=~ n_textwidth , n_textheight , log_2left(n_textRed , n_textGreen , n_textBlueright)
,.endalign
$$

In the case of a black-and-white image:

• $n_textRed=2 ,$ since there're two possible values for the red channel;




• $n_textGreen=n_textBlue=1 ,$ since the values of the green and blue channels is defined to equal the red channel (such that all pixels are either black or white;

so the entropy'd be$$
left[ textentropy right]
~=~ n_textwidth , n_textheight , log_2left(2 times 1 times 1right)
~=~ n_textwidth , n_textheight
,.
$$