Cryptography Notes

PKI/TLS

Version	Introduced	Deprecated
SSL 3	~1996	2015
TLS 1.0	1999	2018, 2020
TLS 1.1	2006	2020
TLS 1.2	2008	-
TLS 1.3	2018	-

The change from the name of SSL to TLS is merely political, and does not reflect any substantial architectual changes.

Support/Configuration

• Server TLS Config Generator
• Browser TLS Test
• Server TLS Test
• Browser TLS capabilities

Encoding

• ASN.1 is a description language for data structures
• BER is a binary format for encoding ASN.1 data structures
• DER is narrower subset of BER, establishes a singular method and order of encoding data
• PEM (Privacy-Enhanced Mail) is an 'ASCII-armored' format (using base64 encoding) commonly used for keys, certificates, etc. Has headers like -----BEGIN CERTIFICATE-----)
• StackOverflow disambiguation

OpenSSL

OpenSSL comprises of several 'commands', the most commonly used ones are listed below:

Command	Manual	Description	Superseded by
openssl genrsa	openssl-genrsa	Generate RSA private key	openssl genpkey
openssl rsa	openssl-rsa	RSA public/private key management	openssl pkey
openssl ec	openssl-ec	ECC key management	openssl pkey
openssl genpkey	openssl-genpkey
openssl req	openssl-req	Generate CSR (Certificate Signing Request)	-
openssl x509	openssl-x509	Certificate tools and signing	-

Generate 2048-bit RSA private key, save key to file output.key (output not encrypted by default).

openssl genrsa -out output.key 2048

or

openssl genpkey -algorithm RSA -out output.key -pkeyopt rsa_keygen_bits:2048

List supported elliptic curves

openssl ecparam -list_curves

Alternate names of NIST curves, by standards group. RFC 4492 Appendix A

NIST	P-256	P-384	P-521
ANSI X9.62	prime256v1	-	-
SEC2	secp256r1	secp384r1	secp521r1

The r in secp256r1 stands for 'random', while a 'k' would be for a variant using a 'Koblitz' curve.

https://crypto.stackexchange.com/questions/67457/elliptic-curve-ed25519-vs-ed448-differences

Generate P-384 private key

openssl genpkey -algorithm EC -out output.key -pkeyopt ec_paramgen_curve:P-384 -pkeyopt ec_param_enc:named_curve

Generate X25519 private key

openssl genpkey -algorithm X25519 -out output.key

Generate CSR, Certificate Signing Request (single domain/subject)

openssl req -new -subj "/CN=example.com" -key private.key -out req.csr

Generate CSR (multiple domains, SAN/subjectAltName)

openssl req -new -subj "/CN=example.com" -addext "subjectAltName = DNS:www.example.com,DNS:sub.example.com" -key private.key -out request.csr

Create self-signed certificate (no additional extensions, single domain)

openssl x509 -req -in req.csr -extfile /etc/ssl/openssl.cnf -extensions v3_ca -signkey private.key -out signed.crt

Create self-signed certificate (with SAN extensions)

Let's Encrypt

WireGuard

WireGuard is an encrypted tunnel protocol atop UDP. It uses a very opinionated choice of cryptographic tools, thus no need for cipher suite negotiation (like OpenVPN/TLS or IPsec). WireGuard is provided as a simple Linux kernel module, while wg-quick is provided as an example configuration frontend. systemd-networkd, NetworkManager, and other network configuration systems can also be used for persistent configuration.

Technical Notes:

• There is no notion of a server/client model for WireGuard, instead, merely configured peers.
• At least one side of a tunnel should have a known IP address (which is configured on the opposite side with the Endpoint setting, and PersistentKeepalive is recommended if the other side is variable/unknown).
• With wg-quick, DNS resolution is only done at initial configuration (such as if a domain name is used for the Endpoint setting). If the IP address of an Endpoint changes after config, a cron script would be needed to be configured to update the IP for the peer.
• The AllowedIPs attribute limits what traffic can be routed to a peer.
• wg-quick will automatically create routes to peers based upon each AllowedIPs setting, this can be disabled with Table=off (under the [Interface] section). Other network configuration frontends do not do this by default.
• Within a WireGuard interface, two endpoints CANNOT share the same network part of an address (AllowedIPs), they must be distinct. For example, you cannot have one side be 10.20.30.1/24 and the other as 10.20.30.2/24, instead, it should be like 10.20.30.1/24 and 10.20.31.1/24. You can also set single addresses as well (e.g. 192.168.23.45/32 or fd12:3456::1/128)
• WireGuard is strictly unicast. You can use multicast addresses across a tunnel, but there can only be one peer per interface configured to receive traffic at the same multicast address (following the same rule as above). In other words, you can use multicast-based routing protocols like Babel across WireGuard, but the tunnels must be strictly point-to-point (only one peer per each WireGuard interface).
• WireGuard itself does not establish routing between peers to a tunnel interface. You would need to enable forwarding on the interface to enable a midpoint to act as a router between peers, and likely make use of a routing protocol (e.g. Babel) for any multi-hop situations.

Sample wg-quick config of two peers