Update Center

Public keys

The keys have two separate roles: release-signing keys establish software authenticity, while the Ed25519 server identity key authenticates optional key-exchange sessions. Each role has a private key and a public verification key. Signing releases does not require access to this distribution server.

Release key — SLH-DSA-SHA2-128s

The private release-signing key signs manifests, bundles, reports and key sets. It is intended to be kept offline, separately from this server. The server stores a public copy for verification; routers carry an initial public trust anchor at /etc/gadnet/release-public-key-slhdsa.pem and can learn successor keys through verified key sets. A correctly verifying router rejects an altered update without a valid trusted signature. This protection does not rule out defects in correctly signed software or attacks through other components.

SLH-DSA-SHA2-128s is a hash-based post-quantum signature algorithm specified in NIST FIPS 205. Its security depends on the construction, parameters and underlying hash functions; it is not a guarantee against every implementation flaw or future attack.

Public verification copy used by this server: release-public-key-slhdsa.pem

Published key set

Routers learn a new signing key from this document, which is itself signed with a key they already trust. That makes key rotation a routine background step rather than a new image for every device, and a compromised server still cannot introduce a key of its own.

Sequence 2, generated 2026-09-25 17:46 (UTC).

Fingerprint (SHA-256) Status Valid
52db 3adc d469 d1af ce92 5d73 793f 58c6 50af 5ee0 43e3 2c9d 3396 fbd3 f80a 99ea current 2026-09-25 – 2028-09-24
66b2 74b0 ca6b 3153 c6dd 1496 ad29 5114 5925 b13c c5b4 14ad 857f 24cb b3c4 1431 retired 2026-09-22 – 2028-09-21

A retired or revoked key is not accepted for verification, even if its listed validity end date is still in the future. Current and next keys must also satisfy the router’s validity checks.

Normal rotation requires no action. If the router missed the transition, confirm the new key under Settings → System updates → Release signing key only after checking its fingerprint through an independently trusted channel, for example an existing verified contact with GADNET support. This table alone is insufficient: a compromised server could replace it too. Until confirmed, do not approve the key.

Machine-readable version and its detached signature (served to GADNET routers only):

The release-key fingerprint is SHA-256 of its DER SubjectPublicKeyInfo representation. To compute it from a public PEM file, use OpenSSL 3.5 or newer with SLH-DSA support. Computing a fingerprint alone does not establish trust in the file.

openssl pkey -pubin -in release-public-key-slhdsa.pem -outform DER | openssl dgst -sha256

Transport identity key — Ed25519

This Ed25519 key signs only the key-exchange transcript. A client that pins an independently verified copy can detect a substituted server even when it has a trusted TLS certificate, for example a corporate proxy trusted by the device. First-use trust must be established separately; reading the key from the same untrusted server is insufficient. GADNET routers do not use this exchange or pin this key.

Public key (base64url)
cLYPHokx5Q_rOiSqMPBK4cxs9xXyKh1IBmq-mX4Y2R4
Fingerprint (SHA-256 of raw public-key bytes)
70b6 0f1e 8931 e50f eb3a 24aa 30f0 4ae1 cc6c f715 f22a 1d48 066a be99 7e18 d91e

Stealing the identity key permits impersonation in new exchanges but does not enable forging release signatures. Past sessions remain protected by ephemeral key exchange under its cryptographic assumptions, provided their session secrets were not exposed. This does not cover compromise of a running session.

Application-level key exchange: integration details

This is the server’s application-level protocol over HTTPS, not a description of the TLS handshake. Current GADNET routers do not use it. A client must verify the transcript signature against a trusted server identity, derive session keys and authenticate subsequent requests. A key-exchange session does not replace the device certificate required for protected release downloads.

Suite: X25519MLKEM768 — X25519 combined with ML-KEM-768 (FIPS 203). The application derives keys from x25519_shared || mlkem_shared. Under the security assumptions of the construction and correct implementation, the classical component protects if ML-KEM fails, and ML-KEM protects session secrets against future quantum decryption of recorded traffic. The Ed25519 identity signature remains classical.

Handshake endpoint: POST https://updates.gadnet.pl/api/v1/kex/init

{
  "version": 1,
  "x25519_public": "<32 bytes, base64url>",
  "mlkem768_public": "<PEM SubjectPublicKeyInfo, base64url>"
}

The reply carries the server’s ephemeral X25519 public key, the ML-KEM ciphertext, a session id, expiry time and an Ed25519 signature over the transcript hash. After verifying that signature, both sides derive session keys using HKDF-SHA-384 with x25519_shared || mlkem_shared and the transcript hash as salt. Clients must also check the selected suite and session expiry. The example above shows only the initial request, not a complete download client.