Show HN: Nix – open-source, zero-knowledge secret sharing

[ntempus]

Hello HN,

I built Nix because I needed a fast, secure way to share environment variables and API keys with my team without creating accounts or worrying about server logs.

The Problem: Most "pastebin" tools are either not encrypted, require a login, or are closed source (so you have to trust them blindly). I wanted something that did one thing well: encrypt data in the browser so the server never sees the key.

How it works:

Client Side Encryption: Nix uses the Web Crypto API (window.crypto) to encrypt your text or files with AES-256-GCM.

The URL Hash: The decryption key is part of the URL fragment (#key). Since fragments are never sent to the server, I literally cannot see your data even if I wanted to.

Ephemeral: You can set expiration times (5m, 1h, 24h) or "Burn on Read."

The Stack:

Next.js / React

Tailwind CSS

Web Crypto API (No external crypto libraries)

Repo: https://github.com/ntempus/nix

It’s free, no ads, and no tracking. I’d love to hear your feedback on the security implementation or the UX.

[mehackernewsacc]

First-glance feedback is that Nix (https://nixos.org/) is _way_ too established a technology to use its name in another software project, if only for SEO reasons, and I'd recommend coming up with a new moniker.

[Privavault]

Nice work on the zero-knowledge implementation. A few questions from someone working on encrypted document storage:

1. How are you handling key derivation? I see Argon2 mentioned - curious about your iteration counts and memory parameters for the tradeoff between security and UX.

2. For the encrypted link approach, are you storing any metadata server-side (file sizes, timestamps, IP addresses)? Even seemingly innocuous metadata can be surprisingly revealing.

3. What's your threat model around browser-based crypto? We've been wrestling with questions like service worker persistence, CSP headers, and whether users should trust browser storage for keys at all.

The time-limited secret sharing is a great feature. I've found that immigration lawyers and journalists are particularly interested in this kind of temporary, verifiable sharing - curious if you've had similar feedback.

[burnbox]

We built Burnbox (burnbox.au) with similar goals. To answer your questions for comparison:

1. Argon2id, 64MB memory, 3 iterations. Memory-hard beats iteration count.

2. Encrypted blob + padded filename (256 bytes fixed) + expiry timestamp. No IP logging—downloads proxy through Netlify so Supabase never sees user IPs.

3. Threat model documented at /security. Trust assumption is TLS + uncompromised JS delivery. Source hashes published for verification without self-hosting.

We've had interest from lawyers and incident response teams. Use cases at /use-cases.

[ntempus]

TL;DR: PBKDF2 (100k iters), Keys never hit server logs (URL fragments), Zero 3rd party scripts, Public repo for verification.

Thanks! I really appreciate the deep dive, always great to hear from someone else in the encrypted storage space.

To answer your points:

1. Key Derivation: I am currently using PBKDF2 (SHA-256 with 100,000 iterations) for the passphrase protection. I aimed for a balance that keeps decryption instant on mobile devices while remaining expensive for brute force. (I am looking at bumping the parameters in the next release to lean harder into security.)

2. Metadata & Logs: You're right, metadata is the silent killer. I strictly store:

Timestamps: Required for the auto-expiration (TTL).

Encrypted Blob: To allow retrieval.

Logs: I host on Vercel/Supabase, so standard access logs (IP/User-Agent) exist for abuse prevention. Crucially, while the random Secret IDs appear in URL paths in our logs, the decryption keys never do (they live strictly in the URL hash fragment or are derived locally). The database itself wipes the row completely upon expiration or "burn", leaving no trace of the relationship between the creator and the content.

3. Browser Threat Model: This is the elephant in the room for all web based apps. Our threat model assumes the user trusts the delivery mechanism (TLS + our server) to send uncompromised JavaScript. We mitigate XSS risks by having zero third party analytics/tracking scripts. However, for users who can't trust the "host", we made the repo public (including the SQL schema). I believe the only true solution for high threat models is "verify and self-host" so we made that as easy as possible.

Re: Lawyers/Journalists: That’s a great insight. I hadn't specifically targeted the legal/press crowd yet, but the "verifiable ephemeral" nature of the link seems to fit their workflow perfectly. I’ll definitely explore that angle further. Thanks for the tip!