您最近的编辑表明您的图片是程序生成的，因此您的密钥大小将受到生成图像所需的状态量的限制。对于初始条件（以及固定的输出图像大小、相机位置、点光源位置、收敛条件等），您的似乎由四个浮点参数化。

然后，这些 128 位状态将通过仅取决于您提供的状态的算法转换为图像，因此您的图像“密钥”不能包含超过 128 位的信息。事实上，我认为整个类的初始值都会产生相同的输出（例如，当所有四个浮点数都非常小时），所以你的图像“关键”大小将严格小于 128 位。

如果您只是通过这样做来减小密钥的大小，那么通过将其转换为图像（然后以某种方式返回）来触摸 128 位状态确实没有任何好处。

图片太大而无法直接用作加密密钥，您需要先通过KDF运行它。

这也完全取决于图片是否有足够的熵来发挥作用。你可以有一个纯白色的 1000x1000 图像，但它作为键是无用的，因为它不包含熵。来自相机的图片往往在低位有相当多的熵，所以这可能没问题，但您的用户需要了解，不仅仅是任何图片都是好的密钥。

图片作为键通常不是一个好主意。照片通常是为了分享而拍摄的，而钥匙是您不想向所有人展示的东西。在我看来，使用图片作为密钥也听起来像是依靠默默无闻的安全性（即，您只需使用计算机上数千个图像中的图像，但这实际上是非常低的熵，可能低于 20 位，除非您有疯狂的图片数量）。

为了学习，请随意继续开发它，但在您更好地掌握密码学之前，最好将这类事情留给专家（请参阅为什么我们不应该自己动手？）。

任何密码系统都应具有密钥大小为 128、192 和 256位熵安全级别的密钥。

所以问题又回到了你身上：这些图像来自哪里，它们包含多少熵？如果它们是被解释为图像的完全随机比特流，那么（忽略有损压缩编解码器的熵损失），你会得到log_base2(256x256x256) = 24 bits of entropy per pixel，所以你需要 6 / 8 / 11 像素分别用于 128 / 192 / 256 位安全性强项。

如果您没有生成完全随机的图像，而是允许人们使用照片，那么我不知道您甚至会如何开始估计其中之一的熵量。

底线：使用图像作为密钥材料似乎是一件非常奇怪的事情，并且与密钥材料是来自加密强度 RNG 的完全随机数据的常见做法相冲突。

另外，根据您问题中的信息，我不相信蛮力是您需要担心的攻击；我会更关心“访问他们的笔记本电脑并尝试他们硬盘上的每个图像”攻击。

我可以从图像中看出您的密钥大小明显小于图像的大小（因为否则它们中的大多数看起来像随机彩色静态）。

您的密钥大小小于或等于您的混沌吸引子程序可以生成的不同图像总数的以 2 为底的对数。*

这是另一种说法，您的密钥大小小于或等于（可能小于）指定混沌吸引子程序的所有输入所需的位数。

如果您散列图像并将散列用作加密密钥，则您的密钥大小等于或小于散列的大小。

*如果您的加密算法类似于“将图像的每一位与明文的相应位进行异或”，那么这就是您的确切密钥大小（不要将该算法用于重要的秘密，顺便说一句，因为部分消息被灰色覆盖图像中的区域可能非常容易解密）。