At the moment, secret keys are in memory and derivatives thereof as well. It would be great to have a good way on how they can be wiped once they're no longer in use. One way is to store them as bigarray values (sic) to avoid the GC copying and moving them around.
We may want to think and address the "storing secret keys in memory (with a GC around)", as raised in https://discuss.ocaml.org/t/ann-mirage-crypto-0-11-3-with-more-speed-for-elliptic-curves-and-the-future-roadmap-of-mirage-crypto/14200/7 (e.g. rust has https://github.com/cesarb/clear_on_drop).
At the time being, it is as it is, the way forward may be to add OCaml runtime supprt for such values (read: bigarrays could when finalized (collected by the GC) use a hook to clean up memory, but there's issues in respect to (a) zarith / gmp usage of values (and derivatives), (b) in a quicker fashion than "waiting for the GC to collect", we may already know in the code that a certain secret key will no longer be needed.
At the moment, secret keys are in memory and derivatives thereof as well. It would be great to have a good way on how they can be wiped once they're no longer in use. One way is to store them as bigarray values (sic) to avoid the GC copying and moving them around.
We may want to think and address the "storing secret keys in memory (with a GC around)", as raised in https://discuss.ocaml.org/t/ann-mirage-crypto-0-11-3-with-more-speed-for-elliptic-curves-and-the-future-roadmap-of-mirage-crypto/14200/7 (e.g. rust has https://github.com/cesarb/clear_on_drop).
At the time being, it is as it is, the way forward may be to add OCaml runtime supprt for such values (read: bigarrays could when finalized (collected by the GC) use a hook to clean up memory, but there's issues in respect to (a) zarith / gmp usage of values (and derivatives), (b) in a quicker fashion than "waiting for the GC to collect", we may already know in the code that a certain secret key will no longer be needed.