Gnoppix 26.8 (Member) and Gnoppix Add Messenger

Announcements
1

Lot of things happen on the Linux Front, mostly I spend the time fixing small issues on Gnoppix Linux in AI cases, i spend most time on module testing, Kimi … model optimizations, and we have a unsloth package. Since still no one submit a bug :squinting_face_with_tongue: I imagine everything is good as it is. I’m on writing documentation how you can finetuine local ai with gnoppix. how to run a 800B model on a 1070 with 8GB ram and and and … as I said a lot of AI which is properly for the most of you uninteresting. If you want try, just install gnoppix-unsloth start it, load a model, unsloth promise the model is 2.5 times faster, start hermes with. For myself, i LOVE IT. I can easly run 30B models on my laptop GPU 16GB. with 110 Token/Sec.

unsloth start hermes.

Here is the updated article, integrating your new text into the introduction while maintaining the strong first-person perspective throughout:

I am still highly motivated, even after 12 months of messenger delopment. When I go to bed, I dream of possible logarithms and their implementations. It is so much fun to learn and build something this robust. The most frequently asked question I received was: Why not open source? The short and simple answer is, it is open source, naturally only freely available to individuals. I don’t want anyone profiting from it. However, there must be the possibility to view the code and not just receive empty promises. That’s why the BSL (Business Software License). My project originated for the sheer fun of it, to show the EU my special finger (with all their surveillance) and to see what’s possible these days without immediately charging users $5 or even $10 and thus creating a money-making business, even though there’s a strong demand for it :slight_smile: Quite the opposite: decentralization and P2P (peer-to-peer). So, do it yourself. Pay attention to the license; individuals can use the code freely.

I have been chatting with other cryptography researchers, sharing thoughts on concepts like SNARKs, which has led to my following detailed roadmap:

1. Protocol-Level Hardening (Deployable Now)

Area Research Angle
Forward Secrecy + PQC Hybrid Combine classical ECDH (X25519) + PQC KEM (ML-KEM-768) in both directions. Signal’s PQXDH is my baseline; I plan to go further with a multi-KEM combiner (X-Wing, Tang et al.) so any single KEM break doesn’t compromise session keys.
Key Compromise Impersonation (KCI) Most PQC KEMs lack KCI resistance by default. I will use authenticated KEMs (e.g., FrodoKEM-Auth) or add explicit MAC binding identities to the ciphertext.
Replay/Reordering Resistance PQC ciphertexts are large, making it tempting to skip sequence numbers. I will avoid this by using implicit sequence binding (AEAD nonce = hash(epoch, seq)) to prevent rollbacks even if the state is cloned.
Post-Compromise Security (PCS) Double Ratchet with PQC: each ratchet step uses a PQC KEM (not just symmetric). This is costly but provably recovers from full state compromise (See ACM CCS '23 “PQ-Ratchet” and Eurocrypt '24 “Updatable PQC”).

2. Implementation & Side-Channel Hardening

Threat Vector Mitigation Strategy
Timing/EM/Power on PQC ops Masking + Shuffling for NTT/NTT⁻¹ (Kyber/Saber). Constant-time is table stakes; I will require higher-order masking (2nd/3rd order) for hardware deployments (See CHES '22 “High-Order Masking of Kyber”).
Fault Injection Redundant computation (dual-rail NTT) + verifiable KEM (ciphertext includes NIZK of well-formedness).
Memory Scraping Zeroize secret-dependent buffers immediately (Rust zeroize, C explicit_bzero). I plan to use enclaves (SGX/SEV/TDX) for long-term key storage, ensuring end-to-end attestation verification.
Supply Chain Reproducible builds + SBOM + SLSA Level 3 for every cryptographic dependency. I must pin exact commit hashes, not just semver.

3. Architectural / Systemic Enhancements

Concept Rationale & Application
Threshold / Multi-Party PQC Split the long-term identity key across n devices (e.g., 3-of-5) so the compromise of ≤2 devices does not equal identity theft. I plan to utilize FROST (Schnorr) + threshold ML-DSA (NIST PQC standardization track).
Hardware-Bound Keys I will ensure PQC private keys never leave the hardware (TPM 2.0 / Secure Enclave). TPM 2.0 supports ECDAA + PQC via vendor extensions. For my Add Messenger project: TPM-sealed identity + passphrase-unlock (passphrase decrypts TPM policy, TPM releases key).
Forward-Secure Key Evolution Rotate long-term identity keys periodically (e.g., yearly) with verifiable key rotation transcripts (Merkle tree of rotations, published to a transparency log). A compromise today should not decrypt 5-year-old traffic.
Anonymous Credentials / ZK-Proofs Allow users to prove “I’m a valid Add user” without revealing identity using BBS+ signatures (post-quantum variants exist) or lattice-based ZK (e.g., Lattice-based ZK-SNARKs from Eurocrypt '24).

4. Emerging / Speculative (PhD Thesis Territory)

Research Frontier Key Papers & Terms
Oblivious PQC / Blind KEM Client encrypts to server’s public key without learning which key (multi-server, metadata privacy). Reference: CRYPTO '23 “Blind Kyber”.
Quantum-Secure Channels QKD + PQC hybrid where a future quantum computer cannot retroactively break past sessions, requiring a quantum channel + computational PQC. Reference: Nature Physics '24 “Everlasting security from QKD+PQC”.
Isogeny-Based PQC After the SIKE break, SQIsign (signatures) and CSIDH (KEM) are still studied for smaller keys and different math. High risk, high reward.
Lattice Trapdoors I might explore using GPV trapdoors for fine-grained access control to derive per-policy keys from a master key. Reference: STOC '24 “Lattice-based ABE with short keys”.
Post-Quantum Secure MPC Multi-Party Computation protocols where all cryptography is PQC. Reference: CCS '24 “PQ-MPC with active security”.

5. Concrete “Next Steps” for Add Messenger

(Architecture: Rust core, Electron UI, P2P)

  1. Audit my current PQC integration to determine the exact KEM in use (e.g., ML-KEM-768, Classic McEliece) and its hybrid status with X25519.

  2. Add explicit KCI binding using the following construction:

    \\text{ciphertext} = \\text{KEM.encaps}(pk) \\parallel \\text{MAC}(k, \\text{"KCI"} \\parallel identity_A \\parallel identity_B)

  3. Implement threshold identity to split the master key via FROST across my users’ devices (phone, laptop, hardware key).

  4. Hardware-back the long-term key via TPM 2.0 (TPM2_Create + TPM2_Unseal), gated by a strict passphrase policy.

  5. Publish a key rotation transparency log that is append-only (Merkle tree) to bootstrap nodes or a separate log server.

  6. Conduct side-channel testing by running dudect or nanobench on my KEM/DEM code paths in CI.

Download: https://pro.gnoppix.org/iso/gnoppix_26_8_xfce.iso (membership required)
Gnoppix Messenger: Pub: GitHub - gnoppix/add: Add is a decentralized, post-quantum encrypted messagener -- no phone, no email, no PII no company in between. · GitHub
Intern: https://github.com/gnoppix/Add-intern