Protecting Memory Secrets: Difference between revisions
Added Wren
EnigmaticC (talk | contribs) (How can your language protect in-memory secrets from eavesdropping) |
(Added Wren) |
||
Line 71:
See also [https://www.reddit.com/r/ProgrammingLanguages/comments/100tyxg/secrets_management_in_volatile_memory_best/ Reddit discussion of the issue]
=={{header|Wren}}==
{{libheader|Wren-crypto}}
Wren is designed to be an embedded scripting language - 'embedded' in the sense that it is embedded in another application, not used for scripting an embedded device though the latter may be possible if the device has sufficient memory available.
As such Wren code is effectively sandboxed and can only communicate with external processes (even just printing to the terminal) to the extent that the host allows it to do so.
It is written in C (as is the embedding API) and consequently most host applications are written in C/C++ though other powerful languages with a C FFI such as Rust or Go can be used instead.
Wren itself can be thought of as a sort of mini-Java in that it is deeply object oriented, managed by its VM, garbage collected and strings are immutable.
Given this state of affairs, I think in practice most host application developers would conclude that any secret should be handled entirely by the host where it can be cleaned up after use by zeroing memory in the usual fashion or, if it does need to be shared with Wren code, then it should be passed as a (possibly encrypted) list of bytes which the Wren code would need to zero out before it was eventually garbage collected.
Wren also has a tool (Wren-CLI) for running Wren scripts directly without a host which is the main focus for solving RC tasks. In reality, there is still a host (written in C) which uses the cross-platform library 'libuv' to implement IO functionality (both terminal and file) and provides Wren with the appropriate modules, though this is transparent to the user.
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="ecmascript">import "io" for Stdin
import "./crypto" for Sha256
// Ensure input is not echoed or buffered
Stdin.isRaw = true
// Obtain secret from terminal input as a byte list
System.print("Enter a secret word and press return:")
var bytes = []
while (true) {
var b = Stdin.readByte()
if (b == 13) break
bytes.add(b)
}
// Encrypt bytes and display on terminal
System.print(Sha256.digest(bytes))
// Zero out bytes
for (i in 0...bytes.count) bytes[i] = 0
// Check it worked
System.print(bytes)
// Make byte list eligible for GC
bytes = null
// Restore normal input before exit
Stdin.isRaw = false</syntaxhighlight>
{{out}}
This assumes the secret word entered is 'abc'.
<pre>
Enter a secret word and press return:
ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad
[0, 0, 0]
</pre>
| |||