In cases like below, we first write the secret data into variable k (in initialization list),
and after that we lock this memory location.
This means that for a short time the secret data is not protected.
For example if at exactly that time system would happen to swap the memory page with k,
it could land in swap space etc.
It would require a very bad luck, but maybe with ephemeral keys generated many times per minute eventually it could happen in practice sometimes.
For example in
|
unboxer(const box_public_key& pk, const box_secret_key& sk, const encoded_bytes& nonce_constant) : k(crypto_box_beforenm(pk.get().to_binary(), sk.get().to_binary())), n(nonce_constant, pk.get().to_binary() > sk.pk.get().to_binary()) { |
|
mlock(k); |
|
} |
unboxer(const box_public_key& pk, const box_secret_key& sk, const encoded_bytes& nonce_constant) : k(crypto_box_beforenm(pk.get().to_binary(), sk.get().to_binary())), n(nonce_constant, pk.get().to_binary() > sk.pk.get().to_binary()) {
mlock(k);
}
In cases like below, we first write the secret data into variable k (in initialization list),
and after that we lock this memory location.
This means that for a short time the secret data is not protected.
For example if at exactly that time system would happen to swap the memory page with k,
it could land in swap space etc.
It would require a very bad luck, but maybe with ephemeral keys generated many times per minute eventually it could happen in practice sometimes.
For example in
sodiumpp/sodiumpp/include/sodiumpp/sodiumpp.h
Lines 520 to 522 in b3aab63