Protecting Memory Secrets: Difference between revisions
m
→{{header|Wren}}: Changed to Wren S/H
m (→{{header|Julia}}: ccall edit) |
m (→{{header|Wren}}: Changed to Wren S/H) |
||
| (2 intermediate revisions by one other user not shown) | |||
Line 72:
See also [https://www.reddit.com/r/ProgrammingLanguages/comments/100tyxg/secrets_management_in_volatile_memory_best/ Reddit discussion of the issue]
=={{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.
=={{header|Julia}}==
Line 153 ⟶ 171:
The tool is a work in progress and would need considerable hardening to handle secrets in a secure fashion. Perhaps the nearest one could get to the task as described would be the following though note that, to display anything to the terminal, Wren first converts it to a string and as these are immutable there is no way to remove them from memory before the GC frees them. To avoid this, we therefore display the bytes entered after encryption by SHA-256 so that only the hash will remain in memory.
<syntaxhighlight lang="
import "./crypto" for Sha256
| |||