C# AES算法（传递密钥长度）-AES传递密钥+；附加PIN码

在我的业务场景（基本上是一个云文件共享应用程序）中，我有以下情况：

用户将文件上载到文件夹

正在检查文件夹是否受PIN保护

1） 如果文件没有PIN保护，请使用存储在应用程序中的预定义密钥+存储在应用程序中的IV密钥对文件进行加密 数据库

2） 如果文件受PIN保护，请使用存储在数据库中的预定义pass key+PIN value+IV key对文件进行加密

问题是，当超过最大密钥大小（16、24、32字节）时，具有有限传递密钥长度的AES将获得无效密钥长度。我的主要问题是如何在保持安全的同时实现类似的目标

目前文件夹PIN码长度没有限制，但似乎我应该将其限制为AES密钥传递的最大长度。使用RijndaelManaged可能会有轻微的改进，我在传递密钥长度方面有更多的灵活性

如有任何建议，将不胜感激

---

注意：我认为代码不会给问题增加任何价值，但如果有人不同意，请告诉我，我会添加它。

我并不完全清楚您的情况，但一般来说，答案将是使用您拥有的任何内容作为“机密”，并对其进行哈希运算，以始终获得AES的相同密钥长度。假设您使用SHA256对秘密进行散列，那么无论您使用哪种数据生成密钥，您的应用程序都可以使用AES-256

---

同样，生成密钥的数据必须具有足够的熵，并且必须保密。特别是在使用密码时，您应该使用安全的密码来密钥派生方案，如PKCS#5，而不是自行构建某个密钥…

密钥派生函数将创建一个长度可控的密钥，如果派生密钥比需要的长，只需截断它即可

---

此外，加密IV不被视为机密，通常只是在加密数据之前加上。许多情况下，密钥派生盐以及迭代计数也会预先添加到加密数据中。对于良好的安全性，最好使用经过严格审查的方法。

谢谢您的回答！我想跳过任何类型的散列，因为考虑到PIN本身已经被散列（PBKDF2），这是第一道防线，我认为在这种情况下不需要散列。第二道防线是加密文件，其中一些文件使用passkey+PIN加密。通过这样做，我不必保存额外的哈希，我唯一要做的就是使用用户提供的passkey+PIN解密文件。pass键嵌入到应用程序中。我认为这是一种安全风险吗？谢谢！这正是我想听到的——截断是一件安全的事情！散列或密钥派生函数产生的一系列随机字节基本上都是随机的，没有一个比其他字节“更好”。所以只要选择任意范围，截断是一种简单的方法。