Protecting Memory Secrets: Difference between revisions

=={{header|J}}==

Generally speaking, it's probably best to avoid using general purpose computers in contexts where we want to enforce the early expiration of secrets. In other words, custom {{wikipedia:Very_Large_Scale_Integration|VLSI}} or {{wikipedia:Field-programmable_gate_array|FPGA}} hardware would be more suitable for this requirement.

That said, expediency can often force suboptimal approaches. And, here, current implementations of J are probably less suited for this requirement than certain other languages.

Still... some tactics might prove useful here. (And the usefulness of these tactics could be better assessed if we had some mechanisms to concretely measure their effectiveness in specific examples.)

(1) Incorporating "input data" as "memory mapped files" would eliminate a variety of intermediate results, as this would eliminate J's normal "copy on write" or "copy on update" semantics.

(2) Another (often conflicting) approach would be to diffuse the "secret bits" throughout memory and rely on J's ability to proceed with regular access patterns as a veil over the secret part.

(3) As a variation on (2), adopting an ongoing stream of noise, to accompany the secrets, would offer both distraction and a statistical tendency to overwrite any lingering remnants of secrets.

(4) If the J engine (libj) is built with the compiler flag MEMAUDIT=4 (or some other value which has that bit set), then J will write garbage to memory when values are freed. (Ensuring that values are freed means tracking reference counts, though it's also worth noting that names can be discarded early using <code>erase</code>.)

Still, ... if timely expiration of secrets is critical, specialized hardware is probably the way to go.