BIOCRYPT

We’re rethinking how people share files. Today, sending something private means trusting clouds, passwords, and middlemen. We asked: what if sharing was as simple as a fingerprint, but as private as a sealed envelope?

Here’s how it works. The moment you scan your finger, your personal keys come alive—unique to you, invisible to anyone else. When you choose a file to share, it’s sealed before it ever leaves your device. That sealed package is placed on a decentralized network, where it can’t be altered or taken down. To your friend, you don’t send the file—you send a tiny, encrypted key. Only their fingerprint can open it.

The result: a file sharing system that feels effortless, yet no one except sender and receiver can ever see the contents. No servers to hack, no passwords to steal, no middleman to trust. Just you, your fingerprint, and the person you choose. Private. Simple. Decentralized

We built a client-first, privacy-first file sharing system that never hands plaintext to anyone but the sender and receiver.

What we used :

Frontend: Next.js (UI, file picker, biometric prompts).

Backend: Python server that uses the @lighthouse Python SDK to upload/pin and retrieve files on IPFS/Lighthouse.

Cryptography: RSA for encrypting the small keys/metadata; symmetric encryption (local, per-file) for the large file payloads.

Main engineering pain: accessing fingerprint auth from the browser — getting biometric-protected crypto operations to run in a web context was the hardest part.

End-to-end flow (cause → effect)

Key material & biometrics (onboard): user opts in to biometrics; a cryptographic keypair is generated and bound to the user’s device. The private key is gated by the biometric unlock so the fingerprint unlocks key usage — the app never stores or transmits raw fingerprint data.

File encryption (before upload): when a user picks a file, the client creates a random symmetric key and encrypts the file locally (fast for big files). This keeps plaintext off the network.

Upload & pin (backend): the encrypted file blob is POSTed to our Python backend. The backend uses the @lighthouse SDK to pin the encrypted blob to IPFS and returns a CID. Pinning ensures availability without centralizing the content.

Envelope creation & delivery: the client assembles a tiny share envelope containing the CID and the symmetric key encrypted with the recipient’s public RSA key. That envelope is signed by the sender and delivered via our in-app messaging channel. Only someone with the matching private RSA key (unlocked by their biometric) can decrypt the symmetric key.

Open & decrypt (recipient): recipient unlocks their private key with fingerprint, decrypts the symmetric key, fetches the encrypted blob from IPFS using the CID, and decrypts locally to reveal the file.

Notable engineering choices & why

Hybrid encryption (symmetric file + asymmetric key): RSA for the small key and symmetric crypto for file content — this keeps uploads efficient while ensuring only the intended recipient can open the file.

Backend pinning via Lighthouse: avoids needing to run our own IPFS cluster while guaranteeing the CID persists — simplifies hackathon ops and keeps dev focus on UX and crypto.

Client-side encryption: the decisive privacy choice — because IPFS CIDs are public, encrypting before upload is the only way to make the network safe for private files.

What was hacky / clever (and worth calling out)

Browser → biometrics gap: accessing biometric-protected key operations in the browser is not straightforward. For the hackathon we bridged it by using the browser’s credential APIs (WebAuthn / platform authenticator pattern) to gate cryptographic operations rather than trying to read fingerprint data. This meant treating the platform authenticator as a seal: the app asks the authenticator to sign/decrypt, and the user completes the biometric prompt. That gave strong UX without exposing biometric data.

Streaming encrypt/decrypt for big files: instead of loading huge files into memory, we chunked and stream-encrypted during upload and stream-decrypted during download so the app stays responsive on mobile and desktop.

Tiny envelope design: we kept the share payload minimal (CID + encrypted symmetric key + signature). Small envelopes let us deliver shares over any channel (push, in-app inbox, QR code) without leaking file metadata.

Backend pinning proxy: rather than giving clients direct access credentials to Lighthouse, the backend acts as a controlled pinning proxy — simpler for rate limits and auditing during the hackathon.

The hard truth — limitations & tradeoffs

Biometrics in browser are gated, not readable. We can only ask the platform authenticator to perform cryptographic operations; we can’t extract raw biometric data — which is good for privacy, but it requires the device to support WebAuthn/platform authenticators.

You can’t truly delete an IPFS CID once pinned by third parties. Encrypted content reduces risk, but pinning permanence means revocation requires key rotation, re-encryption, or proxy-re-encryption schemes.

Metadata leakage: CIDs and upload timing are visible; we mitigated this by limiting envelope metadata and keeping filenames inside encrypted payloads only.

In one sentence (hackathon blurb)

We built a fingerprint-gated, client-encrypted file sharing flow: files are encrypted on device, pinned to IPFS via Lighthouse, and shared by sending a tiny, encrypted key that only the recipient’s biometric-protected key can unlock.