现代加密库无法对字符进行操作。所有现代密码都被定义为对字节进行操作（有些被定义为对位进行操作，但大多数库会假设字节是数据的最小单位）。如果您的库接受字符串，那么它们将被转换为其中的字节。请注意，egstd:string不必包含字符串，它也可以包含字节字符串（也称为八位字节字符串）。

另一方面，大多数加密库使用全范围的密钥空间。这意味着构成密钥的字节可以具有任何值。因此，只要您的 base 64 编码密钥具有有效的密钥大小，它就可以被接受。在这种情况下，唯一的问题是 base64 将包含完全随机密钥熵的 3/4。因此，如果您有 192 位 AES 密钥，它将被转换为 AES 256 位密钥。在这种情况下，您不应要求 256 位安全性，因为您的方案中可能的密钥数量仍然是 2^192。

如果加密库本身对 base64 进行解码，那么您的密钥首先会 1:1 转换为 base64，然后再次转换回原始密钥。显然在这种情况下 base64 并没有什么不同。您会期望从 base64 或十六进制转换为该库提供了详细的文档。

Synercoding.Encryption 的可用信息似乎很少 - 这不是一个好兆头。

如果密钥不是密钥而是输入 PBKDF2 的密码，那么您只需为其提供足够的熵。如果将其直接输入 PBKDF2 或者首先将其编码为 base64 没有区别。

对于基于密码的函数 PBKDF2 来说已经足够有趣了，它也被定义为对字节进行操作。因此，API 还应指定字符编码。通常它与 ASCII 兼容，因此 base 64 可能会起作用。它甚至可以用作 PBKDF2 实现之间的某种兼容层。

只要在使用前将密钥转换回二进制格式，base-64 编码造成的比特稀释就会被撤消。

但是，如果您在应用程序中传递密钥，请注意您的操作方式。擦除文本缓冲区，最小化方法和应用程序之间的传输等。

由于所有体面的加密算法都被定义为对位或字节序列进行操作，因此您的“加密库”只有两种可能性：

• 要么在内部将字符串转换回字节；
• 或者它使用一些基于字符的自定义算法。

在第一种情况下，库有一个草率的 API；它不应该被人为地限制在字符串中。在第二种情况下，情况更糟：定制的、自制的算法总是很弱。

无论如何，最重要的不是库而是算法。该库负责正确实现算法，但安全性来自底层算法及其使用方式（密码算法的组装通常称为协议）。如果你的图书馆所做的只是被称为“它做了一些加密”，那么就没有办法对你的问题给出任何重要的答案。如果您的库没有指定它实现的协议，作为一个定义良好且经过研究的标准，那么您可以执行的唯一明智的操作就是摆脱该库，并找到一个更好的库。