I am writing software for the JVM (in Clojure) that performs a cryptographic operation. In particular, taking into account secret input, secret key, unclassified salt, unclassified personalization, he uses BLAKE2 to get 512 bits of key material. He then breaks this array into two 256-bit chunks using tools from the Arrays class. ( source )
The actual implementation of this operation is in libsodium , so it is implemented in C. I use caesium to access it, which is a wrapper over kalium , a library that uses jnr-ffi to invoke the base implementation of C.
Since all the buffers above have sensitive key material, I would like to make sure that they are cleared from memory. I'm not sure how to do this safely in the JVM (hell, I'm not even sure I know how to safely do this in C ). Given that the material is transferred from C const char * to the JVM byte[] , and then some of my operations create new JVM byte arrays, the key material will live in JVM byte arrays. This causes two problems:
- If I numbered a
byte[] , which subsequently did not touch any code, how can I be sure that byte[] was actually reset? I would suggest that the JVM is free to optimize this. - Even if I could guarantee that
byte[] is nullified, as I know, the JVM did not decide to copy this array (for example, in the context of the garbage collector) many times without nullifying the original location, therefore, in any case, leave the key material all over virtual memory?
I guess the answer will end up with โdo it in C and ASMโ or maybe even โdo it in HSMโ, but I would like to hear if there are any ways to fix this problem in JVM-land.
java security cryptography jvm clojure
lvh
source share