beaconcrypt 0.3.7

Cryptographic transport for C2 channels
Documentation
1
2
3
4
5
6
7
8
9
10
11
<!-- SPDX-License-Identifier: 0BSD -->

# Why this library exists
Most current C2 mechanisms seem to only use classical cryptography. Indeed, --at least in the mythic space--a lot of them use some sort of AES-CBC + HMAC construction, with per-beacon or per-server implementation. This project aims to provide a simple API to the crypto operations we care about, while raising the bar for security. This means using post-quantum safe (PQ) cryptography, on top of a well understood and audited library (libsodium). This protocol uses the signal protocol's `PQXDH` key exchange mechanism and `symmetric ratchet` key rotation. The signal protocol has been extensively studied by cryptographers and has been [proven](https://cryspen.com/post/pqxdh/) [to](https://eprint.iacr.org/2016/1013) [provide](https://eprint.iacr.org/2018/1037) very strong security properties. However, some of those properties do not apply to our usage, see the threat model, and so this library doesn't implement the mechanisms that provide them. Therefore, this protocol cannot claim to inherit the signal protocol's rich history of security analysis until an audit is performed.

The [U.S. government mandates](https://www.whitehouse.gov/wp-content/uploads/2026/06/eo-14412.pdf) a 2030 transition to PQC for key establishment systems, and 2031 for digital signatures for high-value federal systems. [NSA](https://media.defense.gov/2022/Sep/07/2003071836/-1/-1/1/CSI_CNSA_2.0_FAQ_.PDF) wants all NSS to use pure PQC by 2035, however they also expect all new deployments to use PQC starting in 2027. [ANSSI](https://cyber.gouv.fr/enjeux-technologiques/cryptographie-post-quantique/faq-pqc/) says they will not certify products that only use classical cryptography starting in 2027. [A joint statement by 21 european countries](https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Crypto/PQC-joint-statement-2025.pdf?__blob=publicationFile&v=3) recommends the transition to PQC by 20230 at the latest for sensitive systems.

# Known gaps
The protocol is not PQ-safe against an active quantum adversary, as they would break the classical signatures and MitM the key exchange to obtain the initial shared secret. Fixing this would require using a PQ-safe signature scheme, almost certainly ML-DSA. Unfortunately, ML-DSA doesn't seem to be on libsodium's roadmap so this is likely not going to be a near-term fix. It would also be possible to use some other library's implementation if necessary.

More subtly, beaconcrypt would be broken by an adversary who MitM's the staged beacon's distribution and replaces the hardcoded server key with its own. This enables the attacker to later MitM the beacon's registration process. This attacker doesn't require a quantum computer.