This commit does multiple things at once to improve the user experience:
* Always start with an upper case letter, no mixing
* Hide deprecated `keygen` command, it still works if called
* Extend and rework some documentation textx
* Drop false `log_level` text, it contains a logic error
* Wrap all documentation at 80 chars
Signed-off-by: Paul Spooren <mail@aparcar.org>
If two instances start up at the same time, they end up with different
keys on both ends. Test this with different delays of 2 (working), 1
(flaky) and 0 (broken) seconds.
Signed-off-by: Paul Spooren <mail@aparcar.org>
Readability of public/secret keys can be checked by simply loading the
key and thereby also checking that it's actually valid.
A user should either define `key_out` or a valid WireGuard peer (made of
`device` and `peer`). If neither is defined, let the user know that this
function will never do any good.
Signed-off-by: Paul Spooren <mail@aparcar.org>
The incredible helpful error message would never reach the enduser.
Attach it to upper layer print to help users fix the issues.
Signed-off-by: Paul Spooren <mail@aparcar.org>
The previous `gen-config` output contained no comments and was partly
misleading, i.e. the `pre_shared_key` is actually a path and not the
key itself. Mark things that are optional.
To keep things in sync, add a test that verifies that the configuration
is actually valid.
While at it, use 127.0.0.1 as peer address instead a fictitious domain
which would break the tests.
Signed-off-by: Paul Spooren <mail@aparcar.org>
We already use Dependabot for cargo updates, use it for GitHub action
updates, too. Right now we see warnings every now and then because Node
wants another upgrade or some checkout stuff is about to be deprecated.
Signed-off-by: Paul Spooren <mail@aparcar.org>
Instead of using a static one, generate it via clap_mangen. To generate
the manpage run `rosenpass --generate-manpage <folder>`.
Right now clap does not support flattening of generated manpages,
meaning that each subcommand is explained in its own file. To add extra
sections to the main file `rosenpass.1`, it's rewritten after the
initial creation.
Once clap support flattened Man pages, the `generate_to` call can be
removed and all subcommand are added to the `rosenpass.1` file.
This implementation allows downstream manpage generation to stay
unchanged even after switching from multiple manpages to a flattened
one.
Signed-off-by: Paul Spooren <mail@aparcar.org>
This splits the complexity of the `flake.nix` into multiple files. At
cross-compiled and static builds at the benefit of simpler nix
expressions and generally better cross compilation compatibility.
the same time, naersk is removed; causing much slower builds for cross-
compiled packages.
This partially addresses the points mentioned in #412.
No magic here, this is likely a copy&paste error. Problem is that one
workflow being called "QC" (regressions.yml) cancels out the other "QC"
(qc.yaml).
Signed-off-by: Paul Spooren <mail@aparcar.org>
Those are seconds not ms, also it's BEGIN not BEG.
While over there, drop the unused variable `RETRANSMIT_ABORT` which was
never used anywhere in the code and drop an outdated TODO comment.
Signed-off-by: Paul Spooren <mail@aparcar.org>
While at it, fix the label handling and fix a typo in continue_if, where
a `break` falsely replaced a `continue`
Signed-off-by: Paul Spooren <mail@aparcar.org>
The RTX_BUFFER_SIZE function is nowhere used in the code and when
dropping it, usize_max (const version of max()) becomes obsolete, too.
Signed-off-by: Paul Spooren <mail@aparcar.org>
Drop the unused `dur` function, it's nowhere found in the code.
Document both Timebase and Timebase::now()
Add tests
Signed-off-by: Paul Spooren <mail@aparcar.org>
Trigger the internal assert of owned.rs instead of writing our own. To
correctly test it use `should_panic` macro.
Signed-off-by: Paul Spooren <mail@aparcar.org>
The [api] section is newly added and causes existing installation to
break since they lack the configuration options. Instead, use a serde
default function.
Signed-off-by: Paul Spooren <mail@aparcar.org>
Co-authored-by: Karolin Varner <karo@cupdev.net>
Merge pull request #376 from pqcfox/feat/netlink-broker-cli
Add broker support to Rosenpass using `MioBrokerClient` (backport of dev/broker-architecture)
This commit resolves multiple issues with the PSK broker integration.
- The manual testing procedure never actually utilized the brokers
due to the use of the outfile option, this led to issues with the
broker being hidden.
- The manual testing procedure omitted checking whether a PSK was
actually sent to WireGuard entirely. This was fixed by writing an
entirely new manual integration testing shell-script that can serve
as a blueprint for future integration tests.
- Many parts of the PSK broker code did not report (log) errors
accurately; added error logging
- BrokerServer set message.payload.return_code to the msg_type value,
this led to crashes
- The PSK broker commands all omitted to set the memfd policy, this led
to immediate crashes once secrets where actually allocated
- The MioBrokerClient IO state machine was broken and the design was
too obtuse to debug. The state machine returned the length prefix as
a message instead of actually interpreting it as a state machine.
Seems the code was integrated but never actually tested. This was
fixed by rewriting the entire state machine code using the new
LengthPrefixEncoder/Decoder facilities. A write-buffer that was not
being flushed is now handled by flushing the buffer in blocking-io
mode.
doc: Add documentation for new methods and arguments
fix: Require new psk_broker_spawn flag to use broker without extra parameters, to make all-features cargo test pass
fix: Fix MioBrokerClient buffer size to allow room for length prefix
fix: Fix remaining issue with panic
Masking the file descriptors (by replaying them with a file descriptor pointing towards /dev/null)
mitigates use after free (on file descriptor) attacks. In case some
piece of code still holds a reference to the file descriptor, that
file descriptor now merely holds a reference to /dev/null.
Otherwise, the file descriptor might be reused and the reference
could now mistakenly point to all sorts of – potentially more harmful – files, such as memfd_secret
file descriptors, storing our secret keys.
This way CliArgs::run has access to all command line parameters.
Avoided mutating the CliArgs (or rather CliCommand) structure here,
because doing so is simply bad style. There is no good reasoning for
why this function should mutate CliCommand, except for a bit of
convenience.
- Policy is now set in main.rs, not cli.rs.
- Feature is called experiment_memfd_secret, not enable_memfd_alloc
This also fixes the last remaining warnings.
Libcrux is a library for formally verified implementations of
cryptographic primitives. It uses multiple back ends; one of which is
libjade. A cryptographic library written in the jasmin assembly
language for high assurance cryptographic implementations.
To use compile with the experiment_libcrux feature enabled:
cargo build --features experiment_libcrux
The script can be used to simulate setups of different sizes. A short
description is added to the `misc/` folder for further information.
This can be used for both benchmarking but also hunting down bugs which
may occur with larger setups.
Signed-off-by: Paul Spooren <mail@aparcar.org>
Improve memfd-secret guard page allocation by using combination of mmap to map allocation area, and nest memfd-secret mapping and meta information with different permissions within the area
Implemented in quininer/memsec#18
Co-authored-by: Prabhpreet Dua <615318+prabhpreet@users.noreply.github.com>
Co-authored-by: Karolin Varner <karo@cupdev.net>
Implements:
- An additional allocator to use memfd_secret(2) and guard pages using mmap(2), implemented in quininer/memsec#16
- An allocator that abstracts away underlying allocators, and uses specified allocator set by rosenpass_secret_memory::policy functions (or a function that sets rosenpass_secret_memory::alloc::ALLOC_INIT
- Updates to tests- integration, fuzz, bench: some tests use procspawn to spawn multiple processes with different allocator policies
The later edits where unfortunately incomplete. They lacked
modeling of multi-session, multi-user settings and they generally
rendered the models less trustworthy from my perspective.
These edits are still interesting as a starting point for analyzing
identity hiding and stealth, but they are not high-quality enough to be
present in main.
Right now a warning message is logged if no Wireguard peer is defined.
This is misleading in cases where the outfile is used instead.
Signed-off-by: Paul Spooren <mail@aparcar.org>
Dynamically dispatch WireguardBrokerMio trait in AppServer. Also allows for mio event registration and poll processing, logic from dev/broker-architecture branch
Co-authored-by: Prabhpreet Dua <615318+prabhpreet@users.noreply.github.com>
Co-authored-by: Karolin Varner <karo@cupdev.net>
* wireguard-broker: merge from dev/broker-architecture
* use zerocopy instead of lenses
* Require use_broker feature flag to comile broker binaries
* Remove PhantomData from BrokerServer & BrokerClient
* Modify mio client rx to be non-recursive, add integration test
Co-authored-by: Karolin Varner <karo@cupdev.net>
Co-authored-by: Prabhpreet Dua <615318+prabhpreet@users.noreply.github.com>
* deps,fuzz: update to liboqs 0.9.1
The release updates the Classic McEliece to NIST PQC Round 4 version
Updates breaking fuzz tests as well
Signed-off-by:
Paul Spooren <mail@aparcar.org>
Prabhpreet Dua <615318+prabhpreet@users.noreply.github.com>
* Update secret key length for McEliece KEM update
* Update to specifying key lengths of Kyber and McEliece through constants
---------
Co-authored-by: Paul Spooren <mail@aparcar.org>
- Fix std log import (remove the asterisk)
- Add sort to dependencies field to make script output deterministic
- Remove whitespace error at EOF
- Add nushell to the default devShell, so that the script can be ran
from the devShell
When creating secret keys or use the out file feature, the material
shouldn't be readble to everyone by default.
Fix: #260
Signed-off-by: Paul Spooren <mail@aparcar.org>
The compare function should do a little-endian comparision, therefore
copy the code from quinier/memsec and don't revert the loop, tada, le.
Signed-off-by: Paul Spooren <mail@aparcar.org>
seperate files for responder and initiator tests
test file that shows other participants leaking info has an effect
general code clean up
performance improvement: initiator and responder tests now run in ~10s
Somehow in the past while splitting into many crates, we broke the bench
setup. This commit both fixes it, and adds a CI job that ensures it is
still working to avoid such silent failure in the future. The benchmarks
are not actually run, they would take forever on the slow GitHub Actions
runners, but they are at least compiled.
The new secret memory pool was causing CI failures in the fuzzing code,
due to the fuzzer compiling its binaries with memory sanitizer support.
https://doc.rust-lang.org/beta/unstable-book/compiler-flags/sanitizer.html
Using lazy_static was – intentionally – introducing a memory leak, but the
LeakSanitizer detected this and raised an error.
Now by using thread_local we are calling the destructors and so – while still being a
memory leak in practice – the LeakSanitizer no longer detects this behaviour as an error.
Alternatively we could have used a known-leaks list with the leak-sanitizer, but this would have increased the complexity of the build setup.
Finally, this was likely triggered with the migration to memsec, because libsodium circumvents the malloc/free calls,
relying on direct calls to MMAP.
Added INITIATOR_TEST and RESPONDER_TEST macros to the identity hiding
mpv file that can be used to selectively test the anonymity of the
initiator or the responder.
Changed identity hiding test to work as a two stage process where
participants with fresh secure secret keys communicate with each other
and other compromised participants. Then the attacker is asked to
identify the difference between two of the secure participants as on of
them acts as a responder.
This script makes it possible to check formatting of rust code found in the various markdown files in the repo. It is also added as a job to the QC CI workflow.
- Use a new nomenclature for these functions based on the idea of a hash
domain (as in domain separation); this makes much more sence
- Remove the ciphers::hash export; we did not even export a hash
function in the purest sence of the word. This gets us around the
difficulty of figuring out what we should call the underlying
primitive
This finishes the last step of removing sodium.rs from the rosenpass crate
itself and also removes the NOTHING and NONCE0 constants.
Hashing functions now use destination parameters;
rosenpass_constant_time::xor now does too.
When fuzzing we are interested in what happens inside the target function
not necessarily what it returns. Functions returning errors with bogus
input in generally desired behaviour.
These targets can be used with rust nightly and cargo-fuzz to fuzz
several bits of Rosenpass's API. Fuzzing is an automated way of
exploring code paths that may not be hit in unit tests or normal
operation. For example the `handle_msg` target exposed the DoS condition
fixed in 0.2.1.
The other targets focus on the FFI with libsodium and liboqs.
Co-authored-by: Karolin Varner <karo@cupdev.net>
The change to a multi crate cargo workspace makes `cargo release` behave differently. Now it prefixes the release tags (e.g. `v0.2.0`) with the package name, so for example `rosenpass-v0.2.0`. This change adds the
Otherwise, omitting `extra_params` in the configuration file will result in a `WireGuard` configuration object of `None`, even though not specifying `extra_params` is sane.
This commit ensures that the call to `StaticKEM::keygen` has a stack of
8MiB.
Especially on Darwin system, this commit is necessary in order to
prevent a stack overflow, as this system only provides stack sizes of
roughly 500KB which is way to small for a Classic McEliece key.
Fixes#118
This commit clarifies the assumptions about the server/responder in the
`rp.1` manual page, by specifying an IP and open UDP ports that the rest
of this tutorial is going to assume.
Reported-by: Robert Clausecker <fuzxxl@gmail.com>
Fixes#116
This commit re-introduces a static and pre-compiled version of the
manual page back into the source code, in case that an installed version
cannot be found on the host system.
If currently no IP address, only on IPv6 is listen by default. This commit would make it listen dual-stack - i.e. IPv4 and IPv6 - by default.
Signed-off-by: Marek Küthe <m.k@mk16.de>
This resolves an error with the darwin based builds, where the install
fails. Pinpointing the macos version will prevent random failrue in
the future --- now we have to opt-in to potential breaking changes when
a new macos release is added to the GitHub Actions runners.
relevant error message:
```console
...
---- Reminders -----------------------------------------------------------------
[ 1 ]
Nix won't work in active shell sessions until you restart them.
Could not set environment: 150: Operation not permitted while System Integrity Protection is engaged
Error: Process completed with exit code 150.
```
fixes#100
This commit adds two new jobs. One checks that `cargo test` runs
through, and second one checking that `cargo test` inside the nix
devshell runs through as well.
fixes#98
The use of a fakecmake in the main step of the Rosenpass build removed real CMake from the devShell, essentially breaking cargo build from within it. This commit fixes that, by explicitly placing the real CMake in the devShell's nativeBuildInputs.
After establishing a session in responder role, the peer
should abort ongoing handshakes in initiator role.
Also adds an extra wait period before creating an
initiation if peer had been the initiator in the previous
handshake. This makes sure that unless there are huge latencies,
there are no concurrent handshakes in the first place.
Fixes: #43
When rosenpass is started, we either know no peer address or we know a
hostname. How to contact this hostname may not be entirely clear because
we now have multiple sockets we could send on and DNS may return
multiple addresses.
To robustly handle host path discovery, we try each
socket-ip-combination in a round robin fashion; the struct stores the
offset of the last used combination internally and and will continue
with the next combination on every call.
The previous commit still introduces breaking changes;
this means we are now developing a 1.x.x version instead
of a 0.x.x version. We will create a 0.x.x development branch
where we might backport some of the features we are introducing now
- adds TOML based configuation files
- with example configuratios in config-examples
- reimplments arcane CLI argument parser as automaton
- adds a new CLI focused arround configuration files
- moves all file utility stuff from `main.rs` to `util.rs`
- moves all AppServer stuff to dedicated `app_server.rs`
- add mio for multi-listen-socket support (should fix#27)
- consistency: rename private to secret
Due to https://github.com/open-quantum-safe/liboqs-rust/issues/202 it is not
yet possible to build the static Rosenpass version for `i686`. The CI actions
which fail for this reason have been excluded for now. Further on, some
the workflow names have been shortened for better overview.
Now that fenix + naersk are used, we don't have the problem of hour-long
builds of a `pkgsStatic.rustc` running in qemu-aarch64. Thus, we can now
finally add these without a big penalty in CI runtime. In addition to
that, the i686 target is added as well.
**Making a new Release of Rosenpass — Cooking Recipe**
If you have to change a file, do what it takes to get the change as commit on the main branch, then **start from step 0**.
If any other issue occurs
0. Make sure you are in the root directory of the project
-`cd "$(git rev-parse --show-toplevel)"`
1. Make sure you locally checked out the head of the main branch
-`git stash --include-untracked && git checkout main && git pull`
2. Make sure all tests pass
-`cargo test --workspace --all-features`
3. Make sure the current version in `rosenpass/Cargo.toml` matches that in the [last release on GitHub](https://github.com/rosenpass/rosenpass/releases)
- Only normal releases count, release candidates and draft releases can be ignored
4. Pick the kind of release that you want to make (`major`, `minor`, `patch`, `rc`, ...)
- See `cargo release --help` for more information on the available release types
- Pick `rc` if in doubt
5. Try to release a new version
-`cargo release rc --package rosenpass`
- An issue was reported? Go fix it, start again with step 0!
6. Actually make the release
-`cargo release rc --package rosenpass --execute`
- Tentatively wait for any interactions, such as entering ssh keys etc.
- You may be asked for your ssh key multiple times!
**Frequently Asked Questions (FAQ)**
- You have untracked files, which `cargo release` complains about?
-`git stash --include-untracked`
- You cannot push to crates.io because you are not logged in?
- Follow the steps displayed in [`cargo login`](https://doc.rust-lang.org/cargo/commands/cargo-login.html)
- How is the release page added to [GitHub Releases](https://github.com/rosenpass/rosenpass/releases) itself?
- Our CI Pipeline will create the release, once `cargo release` pushed the new version tag to the repo. The new release should pop up almost immediately in [GitHub Releases](https://github.com/rosenpass/rosenpass/releases) after the [Actions/Release](https://github.com/rosenpass/rosenpass/actions/workflows/release.yaml) pipeline started.
- No new release pops up in the `Release` sidebar element on the [main page](https://github.com/rosenpass/rosenpass)
- Did you push a `rc` release? This view only shows non-draft release, but `rc` releases are considered as draft. See [Releases](https://github.com/rosenpass/rosenpass/releases) page to see all (including draft!) releases.
- The release page was created on GitHub, but there are no assets/artifacts other than the source code tar ball/zip?
- The artifacts are generated and pushed automatically to the release, but this takes some time (a couple of minutes). You can check the respective CI pipeline: [Actions/Release](https://github.com/rosenpass/rosenpass/actions/workflows/release.yaml), which should start immediately after `cargo release` pushed the new release tag to the repo. The release artifacts only are added later to the release, once all jobs in bespoke pipeline finished.
- How are the release artifacts generated, and what are they?
- The release artifacts are built using one Nix derivation per platform, `nix build .#release-package`. It contains both statically linked versions of `rosenpass` itself and OCI container images.
@@ -23,3 +23,7 @@ inside `papers/`. The PDF files will be located directly in `papers/`.
The version info is using gitinfo2. To use the setup one has to run the `papers/tex/gitinfo2.sh` script. In local copies it's also possible to add this as a post-checkout or post-commit hook to keep it automatically up to date.
The version information in the footer automatically includes a “draft”. This can be removed by tagging a release version using `\jobname-release`, e.h. `whitepaper-release` for the `whitepaper.md` file.
## Licensing of assets
The text files and graphics in this folder (i.e. whitepaper.md, the SVG, PDF, and PNG files in the graphics/ folder) are released under the CC BY-SA 4.0 license.
- Benjamin Lipp = Max Planck Institute for Security and Privacy (MPI-SP)
- Karolin Varner = Rosenpass e.V., Max Planck Institute for Security and Privacy (MPI-SP)
- Benjamin Lipp = Rosenpass e.V., Max Planck Institute for Security and Privacy (MPI-SP)
- Wanja Zaeske
- Lisa Schmidt = {Scientific Illustrator – \\url{mullana.de}}
- Prabhpreet Dua
abstract: |
Rosenpass is used to create post-quantum-secure VPNs. Rosenpass computes a shared key, WireGuard (WG) [@wg] uses the shared key to establish a secure connection. Rosenpass can also be used without WireGuard, deriving post-quantum-secure symmetric keys for some other application. The Rosenpass protocol builds on “Post-quantum WireGuard” (PQWG) [@pqwg] and improves it by using a cookie mechanism to provide security against state disruption attacks.
Rosenpass is used to create post-quantum-secure VPNs. Rosenpass computes a shared key, WireGuard (WG) [@wg] uses the shared key to establish a secure connection. Rosenpass can also be used without WireGuard, deriving post-quantum-secure symmetric keys for another application. The Rosenpass protocol builds on “Post-quantum WireGuard” (PQWG) [@pqwg] and improves it by using a cookie mechanism to provide security against state disruption attacks.
The WireGuard implementation enjoys great trust from the cryptography community and has excellent performance characteristics. To preserve these features, the Rosenpass application runs side-by-side with WireGuard and supplies a new post-quantum-secure pre-shared key (PSK) every two minutes. WireGuard itself still performs the pre-quantum-secure key exchange and transfers any transport data with no involvement from Rosenpass at all.
The Rosenpass project consists of a protocol description, an implementation written in Rust, and a symbolic analysis of the protocol’s security using ProVerif [@proverif]. We are working on a cryptographic security proof using CryptoVerif [@cryptoverif].
This document is a guide to engineers and researchers implementing the protocol; a scientific paper discussing the security properties of Rosenpass is work in progress.
This document is a guide for engineers and researchers implementing the protocol; a scientific paper discussing the security properties of Rosenpass is work in progress.
---
\enlargethispage{5mm}
@@ -33,7 +34,7 @@ abstract: |
Rosenpass inherits most security properties from Post-Quantum WireGuard (PQWG). The security properties mentioned here are covered by the symbolic analysis in the Rosenpass repository.
## Secrecy
Three key encapsulations using the keypairs `sski`/`spki`, `sskr`/`spkr`, and `eski`/`epki` provide secrecy (see Section \ref{variables} for an introduction of the variables). Their respective ciphertexts are called `scti`, `sctr`, and `ectr` and the resulting keys are called `spti`, `sptr`, `epti`. A single secure encapsulation is sufficient to provide secrecy. We use two different KEMs (Key Encapsulation Methods; see section \ref{skem}): Kyber and Classic McEliece.
Three key encapsulations using the keypairs `sski`/`spki`, `sskr`/`spkr`, and `eski`/`epki` provide secrecy (see Section \ref{variables} for an introduction of the variables). Their respective ciphertexts are called `scti`, `sctr`, and `ectr` and the resulting keys are called `spti`, `sptr`, `epti`. A single secure encapsulation is sufficient to provide secrecy. We use two different KEMs (Key Encapsulation Mechanisms; see section \ref{skem}): Kyber and Classic McEliece.
## Authenticity
@@ -169,7 +170,7 @@ Rosenpass uses a cryptographic hash function for multiple purposes:
* Computing the cookie to guard against denial of service attacks. This is a feature adopted from WireGuard, but not yet included in the implementation of Rosenpass.
* Computing the peer ID
* Key derivation during and after the handshake
* Computing the additional data for the biscuit encryption, to prove some privacy for its contents
* Computing the additional data for the biscuit encryption, to provide some privacy for its contents
Using one hash function for multiple purposes can cause real-world security issues and even key recovery attacks [@oraclecloning]. We choose a tree-based domain separation scheme based on a keyed hash function – the previously introduced primitive `hash`– to make sure all our hash function calls can be seen as distinct.
@@ -218,6 +219,7 @@ The server needs to store the following variables:
*`spkm`
*`biscuit_key`– Randomly chosen key used to encrypt biscuits
*`biscuit_ctr`– Retransmission protection for biscuits
*`cookie_secret`- A randomized cookie secret to derive cookies sent to peer when under load. This secret changes every 120 seconds
Not mandated per se, but required in practice:
@@ -237,12 +239,13 @@ For each peer, the server stores:
The initiator stores the following local state for each ongoing handshake:
* A reference to the peer structure
* A state indicator to keep track of the message expected from the responder next
* A state indicator to keep track of the next message expected from the responder
*`sidi`– Initiator session ID
*`sidr`– Responder session ID
*`ck`– The chaining key
*`eski`– The initiator's ephemeral secret key
*`epki`– The initiator's ephemeral public key
*`cookie_value`- Cookie value sent by an initiator peer under load, used to compute cookie field in outgoing handshake to peer under load. This value expires 120 seconds from when a peer sends this value using the CookieReply message
The responder stores no state. While the responder has access to all of the above variables except for `eski`, the responder discards them after generating the RespHello message. Instead, the responder state is contained inside a cookie called a biscuit. This value is returned to the responder inside the InitConf packet. The biscuit consists of:
@@ -380,9 +383,18 @@ fn load_biscuit(nct) {
"biscuit additional data",
spkr, sidi, sidr);
let pt : Biscuit = XAEAD::dec(k, n, ct, ad);
// Find the peer and apply retransmission protection
lookup_peer(pt.peerid);
assert(pt.biscuit_no <= peer.biscuit_used);
// In December 2024, the InitConf retransmission mechanisim was redesigned
// in a backwards-compatible way. See the changelog.
//
// -- 2024-11-30, Karolin Varner
if (protocol_version!(< "0.3.0")) {
// Ensure that the biscuit is used only once
assert(pt.biscuit_no <= peer.biscuit_used);
}
// Restore the chaining key
ck ← pt.ck;
@@ -428,11 +440,161 @@ The responder code handling InitConf needs to deal with the biscuits and package
ICR5 and ICR6 perform biscuit replay protection using the biscuit number. This is not handled in `load_biscuit()` itself because there is the case that `biscuit_no = biscuit_used` which needs to be dealt with for retransmission handling.
### Denial of Service Mitigation and Cookies
Rosenpass derives its cookie-based DoS mitigation technique for a responder when receiving InitHello messages from Wireguard [@wg].
When the responder is under load, it may choose to not process further InitHello handshake messages, but instead to respond with a cookie reply message (see Figure \ref{img:MessageTypes}).
The sender of the exchange then uses this cookie in order to resend the message and have it accepted the following time by the reciever.
For an initiator, Rosenpass ignores all messages when under load.
#### Cookie Reply Message
The cookie reply message is sent by the responder on receiving an InitHello message when under load. It consists of the `sidi` of the initiator, a random 24-byte bitstring `nonce` and encrypting `cookie_value` into a `cookie_encrypted` reply field which consists of the following:
where `cookie_secret` is a secret variable that changes every two minutes to a random value. `initiator_host_info` is used to identify the initiator host, and is implementation-specific for the client. This paramaters used to identify the host must be carefully chosen to ensure there is a unique mapping, especially when using IPv4 and IPv6 addresses to identify the host (such as taking care of IPv6 link-local addresses). `cookie_value` is a truncated 16 byte value from the above hash operation. `mac_peer` is the `mac` field of the peer's handshake message to which message is the reply.
#### Envelope `mac` Field
Similar to `mac.1` in Wireguard handshake messages, the `mac` field of a Rosenpass envelope from a handshake packet sender's point of view consists of the following:
```pseudorust
mac = lhash("mac", spkt, MAC_WIRE_DATA)[0..16]
```
where `MAC_WIRE_DATA` represents all bytes of msg prior to `mac` field in the envelope.
If a client receives an invalid `mac` value for any message, it will discard the message.
#### Envelope cookie field
The initiator, on receiving a CookieReply message, decrypts `cookie_encrypted` and stores the `cookie_value` for the session into `peer[sid].cookie_value` for a limited time (120 seconds). This value is then used to set `cookie` field set for subsequent messages and retransmissions to the responder as follows:
```pseudorust
if (peer.cookie_value.is_none() || seconds_since_update(peer[sid].cookie_value) >= 120) {
Here, `seconds_since_update(peer.cookie_value)` is the amount of time in seconds ellapsed since last cookie was received, and `COOKIE_WIRE_DATA` are the message contents of all bytes of the retransmitted message prior to the `cookie` field.
The inititator can use an invalid value for the `cookie` value, when the responder is not under load, and the responder must ignore this value.
However, when the responder is under load, it may reject InitHello messages with the invalid `cookie` value, and issue a cookie reply message.
### Conditions to trigger DoS Mechanism
This whitepaper does not mandate any specific mechanism to detect responder contention (also mentioned as the under load condition) that would trigger use of the cookie mechanism.
For the reference implemenation, Rosenpass has derived inspiration from the linux implementation of Wireguard. This implementation suggests that the reciever keep track of the number of messages it is processing at a given time.
On receiving an incoming message, if the length of the message queue to be processed exceeds a threshold `MAX_QUEUED_INCOMING_HANDSHAKES_THRESHOLD`, the client is considered under load and its state is stored as under load. In addition, the timestamp of this instant when the client was last under load is stored. When recieving subsequent messages, if the client is still in an under load state, the client will check if the time ellpased since the client was last under load has exceeded `LAST_UNDER_LOAD_WINDOW` seconds. If this is the case, the client will update its state to normal operation, and process the message in a normal fashion.
Currently, the following constants are derived from the Linux kernel implementation of Wireguard:
```pseudorust
MAX_QUEUED_INCOMING_HANDSHAKES_THRESHOLD = 4096
LAST_UNDER_LOAD_WINDOW = 1 //seconds
```
## Dealing with Packet Loss
The initiator deals with packet loss by storing the messages it sends to the responder and retransmitting them in randomized, exponentially increasing intervals until they get a response. Receiving RespHello terminates retransmission of InitHello. A Data or EmptyData message serves as acknowledgement of receiving InitConf and terminates its retransmission.
The responder does not need to do anything special to handle RespHello retransmission – if the RespHello package is lost, the initiator retransmits InitHello and the responder can generate another RespHello package from that. InitConf retransmission needs to be handled specifically in the responder code because accepting an InitConf retransmission would reset the live session including the nonce counter, which would cause nonce reuse. Implementations must detect the case that `biscuit_no = biscuit_used` in ICR5, skip execution of ICR6 and ICR7, and just transmit another EmptyData package to confirm that the initiator can stop transmitting InitConf.
The responder uses less complex form of the same mechanism: The responder never retransmits RespHello, instead the responder generates a new RespHello message if InitHello is retransmitted. Responder confirmation messages of completed handshake (EmptyData) messages are retransmitted by storing the most recent InitConf messages (or their hashes) and caching the associated EmptyData messages. Through this cache, InitConf retransmission is detected and the associated EmptyData message is retransmitted.
### Interaction with cookie reply system
The cookie reply system does not interfere with the retransmission logic discussed above.
When the initator is under load, it will ignore processing any incoming messages.
When a responder is under load and it receives an InitHello handshake message, the InitHello message will be discarded and a cookie reply message is sent. The initiator, then on the reciept of the cookie reply message, will store a decrypted `cookie_value` to set the `cookie` field to subsequently sent messages. As per the retransmission mechanism above, the initiator will send a retransmitted InitHello message with a valid `cookie` value appended. On receiving the retransmitted handshake message, the responder will validate the `cookie` value and resume with the handshake process.
When the responder is under load and it recieves an InitConf message, the message will be directly processed without checking the validity of the cookie field.
We redesign the InitConf retransmission mechanism to use a hash table. This avoids the need for the InitConf handling code to account for InitConf retransmission specifically and moves the retransmission logic into less-sensitive code.
Previously, we would specifically account for InitConf retransmission in the InitConf handling code by checking the biscuit number: If the biscuit number was higher than any previously seen biscuit number, then this must be a new key-exchange being completed; if the biscuit number was exactly the highest seen biscuit number, then the InitConf message is interpreted as an InitConf retransmission; in this case, an entirely new EmptyData (responder confirmation) message was generated as confirmation that InitConf has been received and that the initiator can now cease opportunistic retransmission of InitConf.
This mechanism was a bit brittle; even leading to a very minor but still relevant security issue, necessitating the release of Rosenpass maintenance version 0.2.2 with a [fix for the problem](https://github.com/rosenpass/rosenpass/pull/329). We had processed the InitConf message, correctly identifying that InitConf was a retransmission, but we failed to pass this information on to the rest of the code base, leading to double emission of the same "hey, we have a new cryptographic session key" even if the `outfile` option was used to integrate Rosenpass into some external application. If this event was used anywhere to reset a nonce, then this could have led to a nonce-misuse, although for the use with WireGuard this is not an issue.
By removing all retransmission handling code from the cryptographic protocol, we are taking structural measures to exclude the possibilities of similar issues.
- In section "Dealing With Package Loss" we replace
\begin{quote}
The responder does not need to do anything special to handle RespHello retransmission – if the RespHello package is lost, the initiator retransmits InitHello and the responder can generate another RespHello package from that. InitConf retransmission needs to be handled specifically in the responder code because accepting an InitConf retransmission would reset the live session including the nonce counter, which would cause nonce reuse. Implementations must detect the case that `biscuit_no = biscuit_used` in ICR5, skip execution of ICR6 and ICR7, and just transmit another EmptyData package to confirm that the initiator can stop transmitting InitConf.
\end{quote}
by
\begin{quote}
The responder uses less complex form of the same mechanism: The responder never retransmits RespHello, instead the responder generates a new RespHello message if InitHello is retransmitted. Responder confirmation messages of completed handshake (EmptyData) messages are retransmitted by storing the most recent InitConf messages (or their hashes) and caching the associated EmptyData messages. Through this cache, InitConf retransmission is detected and the associated EmptyData message is retransmitted.
\end{quote}
- In function `load_biscuit` we replace
``` {=tex}
\begin{quote}
\begin{minted}{pseudorust}
assert(pt.biscuit_no <= peer.biscuit_used);
\end{minted}
\end{quote}
```
by
``` {=tex}
\begin{quote}
\begin{minted}{pseudorust}
// In December 2024, the InitConf retransmission mechanisim was redesigned
// in a backwards-compatible way. See the changelog.
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.