rust-lang / rust-lang/rfcs

Keeping Secrets in Rust

Open
#2,533 14 comments 13 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

T-lang T-libs
Dominant language
Markdown
Stars
6.6k
Forks
1.7k
Avg merge
16h 14m
Merged PRs (30d)
1

Description

Keeping secrets in Rust

In cryptographic code, it is important to keep some values secret and prevent attackers from knowing them.

Rust, as most programming languages, makes no guarantees about this - it only specifies the behavior of programs, not what an attacker can figure out about them. Because of that, compilers are allowed to optimize code in ways that leak secrets.

There are basically 2 kinds of secrecy we care about:

Side-Channel Security

Side-Channel Security is about preventing attackers from observing secret data through side-channels (for example, timing, cache effects, etc.).

Compilation to a concrete machine can introduce side-channels. For example, most common CPUs don't treat control flow as a secret, and leak it into the timing of operations, and the timing of other operations executing on the machine, in a fairly complex and hard-to-control but possible-to-observe way. (If this was a paper, I would cite 4 separate attacks here).

Because of that, a compiler that introduces a branch on a secret value would leak that secret into control-flow, and therefore, potentially to an attacker.

As any leak of secret data can lead to an attack, it is important to have a way of writing code that will not leak secrets through such channels.

XXX: come up with good examples of miscompilations here.

Forward Secrecy

Machines (and VMs, and processes, etc.) are sometimes completely compromised by attackers. While it would seem that after a machine is compromised, everything that machine ever touched is necessarily lost, that is in fact only necessarily true for things the machine currently touches.

Many impportant sessions are short-lived. For example, in TLS, the session key that is actually used to encrypt traffic only lives as long as a socket. Therefore, if we erase the session key after the socket is closed, an attacker who had compromised our machine can't use the key to decrypt yesterday's traffic. If the compromise is detected and rectified quickly, the attacker can only decrypt a small amount of data.

However, if we want to erase something, we need to erase it in a way that prevents an attacker who had compromised the machine from recovering it. For example, if temporary copies of the erased data are presesnt somewhere in memory, an attacker can use them.

Therefore, we need a scheme to erase everything derived from secret data.

Links to older discussions

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reading the linked discussions in #847, #1814, and #1853, followed by the referenced Rust security working group thread. The issue names no files, tests, or implementation entry point; a concrete design and scope would need to be decided before implementation, with completion defined by an accepted proposal.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
cryptography, security
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
20/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.