diff --git a/doc/rp.1 b/doc/rp.1 index 6810336..c07f6a3 100644 --- a/doc/rp.1 +++ b/doc/rp.1 @@ -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 diff --git a/readme.md b/readme.md index b90aa21..ffe2880 100644 --- a/readme.md +++ b/readme.md @@ -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) diff --git a/src/app_server.rs b/src/app_server.rs index 57951af..a3cd96c 100644 --- a/src/app_server.rs +++ b/src/app_server.rs @@ -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()), } } diff --git a/src/cli.rs b/src/cli.rs index 51313a3..96b9420 100644 --- a/src/cli.rs +++ b/src/cli.rs @@ -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, - /// Forecefully overwrite public- & secret-key file + /// Forcefully overwrite public- & secret-key file #[clap(short, long)] force: bool, }, diff --git a/src/labeled_prf.rs b/src/labeled_prf.rs index c583aa8..7f3d775 100644 --- a/src/labeled_prf.rs +++ b/src/labeled_prf.rs @@ -10,7 +10,7 @@ pub fn protocol() -> Result { 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 { diff --git a/src/protocol.rs b/src/protocol.rs index b7de3d0..fc41846 100644 --- a/src/protocol.rs +++ b/src/protocol.rs @@ -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 { let mut msg = tx_buf.envelope::>()?; // Envelope::::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 { 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 diff --git a/src/util.rs b/src/util.rs index 66991d4..024ecbc7 100644 --- a/src/util.rs +++ b/src/util.rs @@ -200,7 +200,7 @@ impl LoadValueB64 for Secret { // 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)?)