gitea-mirror/rosenpass
1
0
Fork 0
mirror of https://github.com/rosenpass/rosenpass.git synced 2025-12-12 07:40:30 -08:00
Code Issues Packages Projects Releases Wiki Activity

fix: Typos in Rust code, readme and man pages

Browse Source
This commit is contained in:
Steffen Vogel
2023-05-31 11:39:11 +02:00
committed by Karolin Varner
parent 397a776c55
commit b958eacaae
7 changed files with 39 additions and 39 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
doc/rp.1
View File

@@ -41,7 +41,7 @@ operations, respectively.
.Bl -tag -width Ds
.It Ar genkey Ar PRIVATE_KEYS_DIR
Creates a new directory with appropriate permissions and generates all the
neccessary private keys required for a peer to participate in a rosenpass
necessary private keys required for a peer to participate in a rosenpass
connection.
.It Ar pubkey Ar PRIVATE_KEYS_DIR Ar PUBLIC_KEYS_DIR
Creates a fresh directory at

10
readme.md
View File

@@ -14,14 +14,14 @@ This repository contains
## Getting started
First, [install rosenpass](#Getting-Rosenpass). Then, check out the help funtions of `rp` & `rosenpass`:
First, [install rosenpass](#Getting-Rosenpass). Then, check out the help functions of `rp` & `rosenpass`:
```sh
rp help
rosenpass help
```
Follow [quickstart instructions](https://rosenpass.eu/#start) to get a VPN up and running.
Follow [quick start instructions](https://rosenpass.eu/#start) to get a VPN up and running.
## Software architecture
@@ -54,7 +54,7 @@ We are working on a cryptographic proof of security, but we already provide a sy
(manual) $ ./analyze.sh
```
The analysis is implemented according to modern software engineering principles: Using the C preprocessor, we where able to split the analysis into multiple files and uses some metaprogramming to avoid repetition.
The analysis is implemented according to modern software engineering principles: Using the C preprocessor, we where able to split the analysis into multiple files and uses some meta programming to avoid repetition.
The code uses a variety of optimizations to speed up analysis such as using secret functions to model trusted/malicious setup. We split the model into two separate entry points which can be analyzed in parallel. Each is much faster than both models combined.
A wrapper script provides instant feedback about which queries execute as expected in color: A red cross if a query fails and a green check if it succeeds.
@@ -62,12 +62,12 @@ A wrapper script provides instant feedback about which queries execute as expect
[^libsodium]: https://doc.libsodium.org/
[^wg]: https://www.wireguard.com/
[^pqwg]: https://eprint.iacr.org/2020/379
[^pqwg-statedis]: Unless supplied with a pre-shared-key, but this defeates the purpose of a key exchange protocol
[^pqwg-statedis]: Unless supplied with a pre-shared-key, but this defeats the purpose of a key exchange protocol
[^wg-statedis]: https://lists.zx2c4.com/pipermail/wireguard/2021-August/006916.htmlA
# Getting Rosenpass
Rosenpass is packaged for more and more distros, maybe also for the distro of your choice?
Rosenpass is packaged for more and more distributions, maybe also for the distribution of your choice?
[![Packaging status](https://repology.org/badge/vertical-allrepos/rosenpass.svg)](https://repology.org/project/rosenpass/versions)

20
src/app_server.rs
View File

@@ -353,13 +353,13 @@ impl AppServer {
// When no socket is specified, rosenpass should open one port on all
// available interfaces best-effort. Here are the cases how this can possibly go:
//
// Some operating systems (such as linux [^linux] and freebsd [^freebsd])
// Some operating systems (such as Linux [^linux] and FreeBSD [^freebsd])
// using IPv6 sockets to handle IPv4 connections; on these systems
// binding to the `[::]:0` address will typically open a dual-stack
// socket. Some other systems such as openbsd [^openbsd] do not support this feature.
// socket. Some other systems such as OpenBSD [^openbsd] do not support this feature.
//
// Dual-stack systems provide a flag to enable or disable this
// behavior – the IPV6_V6ONLY flag. Openbsd supports this flag
// behavior – the IPV6_V6ONLY flag. OpenBSD supports this flag
// read-only. MIO[^mio] provides a way to read this flag but not
// to write it.
//
@@ -372,7 +372,7 @@ impl AppServer {
// - One IPv4 socket and no IPv6 socket if opening the IPv6 socket fails
// - One dual-stack IPv6 socket and a redundant IPv4 socket if dual-stack sockets are
// supported but the operating system does not correctly report this (specifically,
// if the only_v6() call raises an errror)
// if the only_v6() call raises an error)
// - Rosenpass exits if no socket could be opened
//
// [^freebsd]: https://man.freebsd.org/cgi/man.cgi?query=ip6&sektion=4&manpath=FreeBSD+6.0-RELEASE
@@ -423,7 +423,7 @@ impl AppServer {
.register(socket, Token(i), Interest::READABLE)?;
}
// TODO use mio::net::UnixStream together with std::os::unix::net::UnixStream for linux
// TODO use mio::net::UnixStream together with std::os::unix::net::UnixStream for Linux
Ok(Self {
crypt: CryptoServer::new(sk, pk),
@@ -490,7 +490,7 @@ impl AppServer {
err.backtrace()
);
if tries_left > 0 {
error!("reinitializing networking in {sleep}! {tries_left} tries left.");
error!("re-initializing networking in {sleep}! {tries_left} tries left.");
std::thread::sleep(self.crypt.timebase.dur(sleep));
continue;
}
@@ -612,7 +612,7 @@ impl AppServer {
};
// this is intentionally writing to stdout instead of stderr, because
// it is meant to allow external detection of a succesful key-exchange
// it is meant to allow external detection of a successful key-exchange
println!(
"output-key peer {} key-file {of:?} {why}",
fmt_b64(&*peerid)
@@ -669,7 +669,7 @@ impl AppServer {
return Ok(None);
}
// NOTE when using mio::Poll, there are some finickies (taken from
// NOTE when using mio::Poll, there are some particularities (taken from
// https://docs.rs/mio/latest/mio/struct.Poll.html):
//
// - poll() might return readiness, even if nothing is ready
@@ -677,7 +677,7 @@ impl AppServer {
// - after receiving readiness for a source, it must be drained until a WouldBlock
// is received
//
// This would ususally require us to maintain the drainage status of each socket;
// This would usually require us to maintain the drainage status of each socket;
// a socket would only become drained when it returned WouldBlock and only
// non-drained when receiving a readiness event from mio for it. Then, only the
// ready sockets should be worked on, ideally without requiring an O(n) search
@@ -708,7 +708,7 @@ impl AppServer {
Err(e) if e.kind() == ErrorKind::WouldBlock => {
would_block_count += 1;
}
// TODO if one socket continuesly returns an error, then we never poll, thus we never wait for a timeout, thus we have a spin-lock
// TODO if one socket continuously returns an error, then we never poll, thus we never wait for a timeout, thus we have a spin-lock
Err(e) => return Err(e.into()),
}
}

4
src/cli.rs
View File

@@ -63,7 +63,7 @@ pub enum Cli {
GenConfig {
config_file: PathBuf,
/// Forecefully overwrite existing config file
/// Forcefully overwrite existing config file
#[clap(short, long)]
force: bool,
},
@@ -84,7 +84,7 @@ pub enum Cli {
#[clap(short, long)]
secret_key: Option<PathBuf>,
/// Forecefully overwrite public- & secret-key file
/// Forcefully overwrite public- & secret-key file
#[clap(short, long)]
force: bool,
},

2
src/labeled_prf.rs
View File

@@ -10,7 +10,7 @@ pub fn protocol() -> Result<PrfTree> {
PrfTree::zero().mix("Rosenpass v1 mceliece460896 Kyber512 ChaChaPoly1305 BLAKE2s".as_bytes())
}
// TODO Use labels that can serve as idents
// TODO Use labels that can serve as identifiers
macro_rules! prflabel {
($base:ident, $name:ident, $($lbl:expr),* ) => {
pub fn $name() -> Result<PrfTree> {

38
src/protocol.rs
View File

@@ -9,7 +9,7 @@
//! will eventually yield a [PollResult]. Said [PollResult] contains
//! prescriptive activities to be carried out. [CryptoServer::osk] can than
//! be used to extract the shared key for two peers, once a key-exchange was
//! succesfull.
//! successful.
//!
//! TODO explain briefly the role of epki
//!
@@ -115,7 +115,7 @@ pub const BISCUIT_EPOCH: Timing = 300.0;
// Retransmission pub constants; will retransmit for up to _ABORT ms; starting with a delay of
// _DELAY_BEG ms and increasing the delay exponentially by a factor of
// _DELAY_GROWTH up to _DELAY_END. An .secretadditional jitter factor of ±_DELAY_JITTER
// _DELAY_GROWTH up to _DELAY_END. An additional jitter factor of ±_DELAY_JITTER
// is added.
pub const RETRANSMIT_ABORT: Timing = 120.0;
pub const RETRANSMIT_DELAY_GROWTH: Timing = 2.0;
@@ -188,7 +188,7 @@ pub struct CryptoServer {
/// A Biscuit is like a fancy cookie. To avoid state disruption attacks,
/// the responder doesn't store state. Instead the state is stored in a
/// Biscuit, that is encrypted using the [BiscuitKey] which is only known to
/// the Respnder. Thus secrecy of the Responder state is not violated, still
/// the Responder. Thus secrecy of the Responder state is not violated, still
/// the responder can avoid storing this state.
#[derive(Debug)]
pub struct BiscuitKey {
@@ -287,24 +287,24 @@ pub struct Session {
pub ck: SecretPrfTreeBranch,
/// Key for Transmission ("transmission key mine")
pub txkm: SymKey,
/// Key for Receival ("transmission key theirs")
/// Key for Reception ("transmission key theirs")
pub txkt: SymKey,
/// Nonce for Transmission ("transmission nonce mine")
pub txnm: u64,
/// Nonce for Receival ("transmission nonce theirs")
/// Nonce for Reception ("transmission nonce theirs")
pub txnt: u64,
}
/// Lifecycle of a Secret
///
/// The order implies the readiness for usage of a secret, the highes/biggest
/// The order implies the readiness for usage of a secret, the highest/biggest
/// variant ([Lifecycle::Young]) is the most preferable one in a class of
/// equal-role secrets.
#[derive(Hash, PartialEq, Eq, PartialOrd, Ord, Debug)]
enum Lifecycle {
/// Not even generated
Void = 0,
/// Secret must be zeroized, disposal adviced
/// Secret must be zeroed, disposal advised
Dead,
/// Soon to be dead: the secret might be used for receiving
/// data, but must not be used for future sending
@@ -495,7 +495,7 @@ impl CryptoServer {
Ok(PeerPtr(peerno))
}
/// Register a new session (during a sucesfull handshake, persisting longer
/// Register a new session (during a successful handshake, persisting longer
/// than the handshake). Might return an error on session id collision
pub fn register_session(&mut self, id: SessionId, peer: PeerPtr) -> Result<()> {
match self.index.entry(IndexKey::Sid(id)) {
@@ -614,7 +614,7 @@ impl Session {
// BISCUIT KEY ///////////////////////////////////
/// Biscuit Keys are always randomized, so that even if through a bug some
/// secrete is encrypted with an unitialized [BiscuitKey], nobody instead of
/// secrete is encrypted with an initialized [BiscuitKey], nobody instead of
/// everybody may read the secret.
impl BiscuitKey {
// new creates a random value, that might be counterintuitive for a Default
@@ -733,7 +733,7 @@ impl CryptoServer {
/// Initiate a new handshake, put it to the `tx_buf` __and__ to the
/// retransmission storage
// NOTE retransmission? yes if initiator, no if responder
// TODO remove unecessary copying between global tx_buf and per-peer buf
// TODO remove unnecessary copying between global tx_buf and per-peer buf
// TODO move retransmission storage to io server
pub fn initiate_handshake(&mut self, peer: PeerPtr, tx_buf: &mut [u8]) -> Result<usize> {
let mut msg = tx_buf.envelope::<InitHello<()>>()?; // Envelope::<InitHello>::default(); // TODO
@@ -758,7 +758,7 @@ impl CryptoServer {
///
/// The response is only dependent on the incoming message, thus this
/// function is called regardless of whether the the the calling context is
/// an iniator, a responder or both. The flow of is as follows:
/// an initiator, a responder or both. The flow of is as follows:
///
/// 1. check incoming message for valid [MsgType]
/// 2. check that the seal is intact, e.g. that the message is
@@ -768,11 +768,11 @@ impl CryptoServer {
/// 4. if the protocol foresees a response to this message, generate one
/// 5. seal the response with cryptographic authentication
/// 6. if the response is a ResponseHello, store the sealed response for
/// further retransmision
/// 7. return some peerpointer if the exchange completed with this message
/// further retransmission
/// 7. return some peer pointer if the exchange completed with this message
/// 8. return the length of the response generated
///
/// This is the sequence of a succesful handshake:
/// This is the sequence of a successful handshake:
///
/// | time | Initiator | direction | Responder |
/// | --- | ---: | :---: | :--- |
@@ -782,7 +782,7 @@ impl CryptoServer {
/// | t3 | | <- | `EmptyData` |
pub fn handle_msg(&mut self, rx_buf: &[u8], tx_buf: &mut [u8]) -> Result<HandleMsgResult> {
let seal_broken = "Message seal broken!";
// lengt of the response. We assume no response, so None for now
// length of the response. We assume no response, so None for now
let mut len = 0;
let mut exchanged = false;
@@ -1296,7 +1296,7 @@ impl HandshakeState {
sodium_bigint_inc(&mut *srv.biscuit_ctr);
// The first bit of the nonce indicates which biscuit key was used
// TODO: This is premature optimiaztion. Remove!
// TODO: This is premature optimization. Remove!
let bk = srv.active_biscuit_key();
let mut n = XAEADNonce::random();
n[0] &= 0b0111_1111;
@@ -1320,7 +1320,7 @@ impl HandshakeState {
// The first bit of the biscuit indicates which biscuit key was used
let bk = BiscuitKeyPtr(((biscuit_ct[0] & 0b1000_0000) >> 7) as usize);
// Calculate addtional data fields
// Calculate additional data fields
let ad = lprf::biscuit_ad()?
.mix(srv.spkm.secret())?
.mix(sidi.as_slice())?
@@ -1648,7 +1648,7 @@ impl CryptoServer {
// TODO: Implementing RP should be possible without touching the live session stuff
// TODO: I fear that this may lead to race conditions; the acknowledgement may be
// sent on a different session than the incoming packet. This should be mitigated
// by the deliberate backoff in SessionPtr::retire_at as in practice only one
// by the deliberate back off in SessionPtr::retire_at as in practice only one
// handshake should be going on at a time.
// I think it may not be possible to formulate the protocol in such a way that
// we can be sure that the other party possesses a matching key; maybe we should
@@ -1673,7 +1673,7 @@ impl CryptoServer {
.session()
.get_mut(self)
.as_mut()
.context("Cannot send acknoledgement. No session.")?;
.context("Cannot send acknowledgement. No session.")?;
rc.sid_mut().copy_from_slice(&ses.sidt.value);
rc.ctr_mut().copy_from_slice(&ses.txnm.to_le_bytes());
ses.txnm += 1; // Increment nonce before encryption, just in case an error is raised

2
src/util.rs
View File

@@ -200,7 +200,7 @@ impl<const N: usize> LoadValueB64 for Secret<N> {
// in practice this is likely not a problem because the stack likely
// will be overwritten by something else soon but this is not exactly
// guaranteed. It would be possible to remedy this, but since the secret
// data will linger in the linux page cache anyways with the current
// data will linger in the Linux page cache anyways with the current
// implementation, going to great length to erase the secret here is
// not worth it right now.
b64_reader(&mut fopen_r(p)?)