crates

crates copied to clipboard

//! Presently this crate favors a simple, no_std-friendly, safe i.e. //! forbid(unsafe_code)-based implementation and does not provide more advanced //! memory protection mechanisms e.g. ones based on mlock(2)/mprotect(2). //! We may explore more advanced protection mechanisms in the future.

There is a rust crate https://github.com/darfink/region-rs that acts as a safe cross-platform wrapper for mlock. Would you accept a PR to add optional mlock support for SecretVec and SecretString?

Potentially, however there are alternatives to consider, and the threat model that benefits from mlock() (attacker with access to swap and only swap, but somehow not /dev/mem, /dev/kmem, or a process's memory) is a somewhat dubious one and also one which can be mitigated with other strategies. Depending on the nature of the program, mlock() may also have unintended side effects as it works at a page-level granularity (this post is a fun read on that subject, and posits a probably unrealistic scenario of mlock misuse causing every logline to flow through swap accidentally).

Another alternative to consider is encrypting secrets in-place when they're not in use, decrypting them for access, then re-encrypting them when they're no longer borrowed. This approach likewise has some questionable parts, like "where do you store the key-encrypting-key (KEK)?" and under what threat model having encrypted secrets helps where an attacker can't access the KEK (which is mostly accidental exposure through exploitation of memory unsafety vulnerabilities).

It might be interesting to parameterize Secret<T> with pluggable strategies (e.g. as a generic parameter) to afford some choice as to what approach is used.

Related to that, sequoia-openpgp uses encrypted memory for storing secret keys link:

This implementation on the other hand, derives a sealing key from a large area of memory, the "pre-key", using a key derivation function. Now, any single bitflip in the readout of the pre-key will avalanche through all the bits in the sealing key, rendering it unusable with no indication of where the error occurred.

@tony-iqlusion @ordian Does this mean that the only implementing encryption like sequoia_openpgp does can solve the issue of secrets being read, without necessarily implementing mlock?

I think an approach like that which keeps secrets encrypted in memory and decrypts them on-the-fly in order to access them (re-encrypting them when done) is an interesting one, yes