Skip to content

LockHTML v1.3.0

Choose a tag to compare

View all tags
@drsamonline drsamonline released this 20 Oct 14:04
· 39 commits to main since this release
v1.3.0
56034be

LockHTML v1.3.0

Lock a file to a person, not a password. X25519 recipient mode.

Highlights

  • 🔑 Recipient mode (X25519) — lock a file to someone's public key so only the holder of the matching private key can open it. No shared secret is ever exchanged.
  • 🧬 Hybrid encryption, done properly: a fresh ephemeral keypair per file, the ECDH shared secret fed through HKDF-SHA256, then AES-256-GCM. Because the secret is already 256 bits of entropy, no slow KDF is applied on top.
  • ➕ Two factors if you want them — layer a PIN (and a keyfile pepper) on top of the recipient key.
  • 🗂️ Works with the streaming container too, so a multi-gigabyte file can be sent to one specific person.
  • 🖥️ GUI support — a recipient public-key field on the lock tab, and a private-key prompt on unlock.
  • 🔒 The decoy PIN is rejected in recipient mode rather than silently ignored.

Usage

lockhtml keygen --type x25519 -o alice.pem   # writes alice.pem (keep) + alice.pub (hand out)
lockhtml lock report.html --to alice.pub
lockhtml unlock report.locked.html --key alice.pem

# two factors, and for large files
lockhtml lock big.mp4 --to alice.pub --pin 4821 --stream

Live GUI

👉 https://drsamonline.github.io/lockhtml/

Verification

58 unit tests, plus a real headless-Chrome end-to-end run of 25 checks covering the embedded container, the streaming container and recipient mode — including wrong key, missing key, PIN-required, tampered sidecar and truncated container. Files locked by the browser are decrypted by the Python core and vice versa (6 cross-implementation checks). All of it runs in CI.

Security note

Recipient mode moves the secret, not the trust: whoever holds the private key can open every file locked to it, and a leaked private key cannot be revoked — rotate it. See SECURITY.md and the self-audit in docs/AUDIT.md.

Assets 5
Loading