Security-first Rust laboratory for finite-field Laplace-Cauchy diffusion and symmetric-primitive research.
Exact arithmetic, reproducible constants, adversarial cryptanalysis, and small audited milestones—with no production security claim.

Implementation Plan | Release Plan | Testing Policy | Threat Model | Security Claims | Security

Laplace Cipher Lab

laplace-cipher-lab is a standalone, research-only workspace for testing whether finite-field matrices derived from the Laplace kernel can form a useful diffusion layer in a conventional nonlinear symmetric construction.

The project does not treat inverse Laplace transformation as a hard problem. The proposed research direction uses exact GF(2^8) arithmetic, independently generated asymmetric Cauchy matrices, an established nonlinear layer, a public 512-bit permutation, and eventually a tweakable block cipher. Authenticated encryption is deliberately deferred until the primitive has substantial cryptanalysis.

EXPERIMENTAL CRYPTOGRAPHY — DO NOT USE TO PROTECT REAL DATA.

No crate in this repository provides confidentiality, integrity, post-quantum security, or production readiness. The current milestone is a repository and policy scaffold; it implements no cipher.

Current Status

Version 0.1.0 is the pre-pentest repository-foundation candidate. It provides:

• a Rust 1.97.1, edition 2024 workspace;
• no_std, safe-Rust component boundaries;
• no third-party crate dependencies;
• an automated 500-line source-file limit;
• mandatory automated, independent, adversarial, and real-environment testing;
• explicit no-publish enforcement for every package;
• security, contribution, release, and pentest policies;
• a granular implementation and version plan through a serious 1.0.0 gate.

There is intentionally no encryption or decryption function yet.

Research Question

The central hypothesis is whether the finite-field analogue of

L{e^(-at)}(s) = 1 / (s + a)

can yield a useful Cauchy diffusion surface:

M[i,j] = inverse(x[i] + y[j]) in GF(2^8)
D(X)   = L * X * transpose(R)

where L and R are independently generated, verified, asymmetric MDS matrices. This is a diffusion mechanism, not the source of secrecy. Secrecy would require keyed nonlinear rounds and years of credible analysis.

Workspace Boundaries

Crate	Responsibility	Runtime profile
laplace-cipher-lab	Research facade only	no_std
lcl-field	Exact finite-field arithmetic	no_std, no allocation
lcl-matrix	Cauchy matrix generation and verification	no_std core
lcl-constants	Suite identifiers and frozen generated constants	no_std
lcl-state	Fixed 512-bit state and normative encoding	no_std
lcl-sbox	Algebraic nonlinear layer and inverse	no_std
lcl-permutation	Public round function and permutation	no_std
lcl-cipher	Future tweakable block-cipher boundary	no_std
lcl-kat	Known-answer and conformance runner	host-side std
lcl-analysis	Cryptanalytic tooling	host-side std

Future functionality starts in a focused crate. The facade remains wiring and documentation rather than an implementation home. Non-generated Rust files must remain under 500 lines and should be reviewed for a split near 300 lines.

Dependency And Publication Policy

The workspace has no third-party dependencies, including development and build dependencies. Workspace crates may depend only on first-party path crates. The local gate requires the frozen, all-features Cargo dependency closure to equal the classified workspace member set; Cargo.lock and cargo-deny add independent enforcement.

Every package contains:

publish = false

The lab has no crates.io publication path. GitHub tags and source archives may record research milestones only. Extraction into another project requires a separately reviewed, frozen suite and does not change this repository's no-publish rule.

Platform Direction

Portable core crates are designed without OS APIs, allocation, floating-point arithmetic, or architecture-native encoding. CI is structured for Linux, Windows, macOS, FreeBSD, Android, iOS, WebAssembly, and embedded no_std targets. Aesynx is a future integration target: core architecture must avoid assuming Unix, std, a global allocator, threads, or a particular endianness.

Platform support means compile and conformance evidence at the release gates; it does not imply equal side-channel evidence on every target.

Development

Use the pinned stable toolchain:

rustup toolchain install 1.97.1 --component clippy,rustfmt
scripts/checks.sh

Install ripgrep for the repository policy gate. The audit tools are also required by the release gate:

cargo install --locked ripgrep --version 15.2.0
cargo install --locked cargo-deny --version 0.20.2
cargo install --locked cargo-audit --version 0.22.2
cargo deny check
cargo audit

The networked release check additionally verifies that the Rust and security tool pins are still current. CodeQL uses GitHub's default setup; this repository does not add an advanced CodeQL workflow.

Documentation

• Implementation Plan defines architecture, verification layers, and research sequencing.
• Release Plan splits work into independently reviewable, pentested milestones.
• Testing Policy requires tests for every behavior and real-environment evidence for every platform or integration claim.
• Original Research Discussion preserves the complete design conversation and alternatives.
• Threat Model records adversaries and trust boundaries.
• Security Claims states what the project does and does not claim.
• Release Runbook defines pentest, remediation, CodeQL, and local tag handling.

License

Licensed under either of:

• Apache License, Version 2.0 (LICENSE-APACHE); or
• MIT License (LICENSE-MIT).

at your option.