上下文
我最近参加了一场密码学讲座，我们讨论了内存中关键元素的持久性。通常，C/C++ 库 Libsodium 建议清除包含敏感信息的任何缓冲区，例如 secret ( ref )。我知道 GuardedString 由字节数组支持，文档建议一旦不再使用存储的 secret 就调用方法 dispose，该方法使用Arrays.fill.
问题
JVM 是否保证字节数组的值在被覆盖时消失，或者在某些条件下原始值保留在内存中？例如，未使用/未引用的String将保存在Java字符串池中，直到触发垃圾收集。对于其他类型(例如字节数组)是否存在类似的缓存或机制，这些机制可能会损害应从 GuardedString 处理的 secret ？ JVM 规范中有任何引用吗？
非常感谢!
最佳答案
在 Java 中，通常会使用 char[] 数组而不是 String，因为这允许手动将数组中的数据归零。
但是即使这样，数据也可能不会按照 this answer 完全取消设置。 :
As noted in the comments, it's possible that arrays being moved by the garbage collector will leave stray copies of the data in memory. I believe this is implementation-specific - the garbage collector may clear all memory as it goes, to avoid this sort of thing. Even if it does, there's still the time during which the char[] contains the actual characters as an attack window.
如果编译器决定优化 memset，C/C++ 中也会存在类似问题。根据11.4. Specially Protect Secrets (Passwords and Keys) in User Memory :
A Bugtraq post by Andy Polyakov (November 7, 2002) reported that the C/C++ compilers gcc version 3 or higher, SGI MIPSpro, and the Microsoft compilers eliminated simple inlined calls to memset intended to overwrite secrets. This is allowed by the C and C++ standards. Other C/C++ compilers (such as gcc less than version 3) preserved the inlined call to memset at all optimization levels, showing that the issue is compiler-specific. Simply declaring that the destination data is volatile doesn’t help on all compilers; both the MIPSpro and Microsoft compilers ignored simple "volatilization". Simply "touching" the first byte of the secret data doesn’t help either; he found that the MIPSpro and GCC>=3 cleverly nullify only the first byte and leave the rest intact (which is actually quite clever - the problem is that the compiler’s cleverness is interfering with our goals).
关于java - GuardedString 和 JVM 的内存持久性，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/55503150/