Inspiration
In a typical LLM app, prompts pass through an application server before reaching the model, and what that server stores is a matter of trust. This project applies the mathematics this hackathon is about - secret sharing and authenticated encryption - to that pipeline, and just as carefully documents where the protection stops.
What it does
CryptoShare is a working local prototype of an LLM chat pipeline with separated storage:
- On the user's device: the prompt is encrypted with AES-256-GCM before anything leaves. The 256-bit master key is split with Shamir's Secret Sharing (2-of-3). The device is the trusted component: it holds the shares and sees plaintext.
- On the relay server (loopback, 127.0.0.1): only ciphertext, wrapped data keys, nonces, and at most one Shamir share are persisted. One share of a 2-of-3 split carries no information about the key, so the relay's storage alone cannot decrypt anything.
- At the hosted LLM (IBM watsonx.ai, ibm/granite-4-h-small): the client recovers the prompt locally from shares 1+2, sends it as an ordinary API request, and encrypts the response before storing it.
A built-in /inspector page dumps the actual database rows persisted during the demo run, so a reviewer can see that what the server stored for those runs is ciphertext, wrapped keys, nonces, and one share - not plaintext. This verifies what was persisted in the demo; it is not a proof about every possible server process or future version.
What it does NOT do (stated on purpose): the hosted model provider necessarily receives plaintext at inference time, and its logging and retention are outside this design. Secret sharing removes the need to trust our server's storage with the key; it does not remove the provider's inference-time exposure. The organizer lists FHE as an optional direction for that problem; it is future work here, not a solved part.
How it's built
- Python 3 client and loopback relay over HTTP; SQLite as the relay store, deliberately simple so the inspector view stays readable.
- The organizer explicitly permits this for the AI pipeline track: "Participants may use pre created cryptographic algorithm and secret sharing mechanisms such as SSS (Shamir's secret sharing)" (hackathon page, https://mathematics-systems-security.devpost.com/).
- AES-256-GCM from the
cryptographylibrary; Shamir's Secret Sharing frompycryptodome- both vetted, widely reviewed implementations. Security properties cited come from the published schemes, not from this project's own tests. - Concrete composition: pycryptodome's Shamir operates on 16-byte secrets, so the 32-byte master key is split as two independent 16-byte blocks (each block is Shamir-split 2-of-3) and recombined block-wise. Each message gets its own random data key (AES-256-GCM), wrapped under the master key, so stored blobs are independent.
- A web UI on the loopback machine walks the pipeline live: what stays on the device, what the relay persists, and the documented inference-exposure boundary.
Challenges
- Defining the trust boundary precisely: the model has to see the prompt to answer it, so the architecture encodes exactly where plaintext exists (the user's device, and the provider at inference time) instead of claiming "end-to-end encrypted AI".
- Key wrapping hierarchy: encrypting each message under its own data key, wrapped under the Shamir-protected master key, keeps any single stored share useless on its own.
- Making "the server stores only ciphertext" inspectable instead of asserted - hence the /inspector page over the actual demo database.
What the demo shows
- A genuine, running pipeline: encrypt, store, inspect, recover locally, real hosted-model call, encrypt the answer back.
- Persisted demo data visible as ciphertext rows in the inspector.
- The limitation section is part of the demo, not fine print.
Technical notes (what the build demonstrates)
- Shamir's Secret Sharing evaluates a random polynomial over a finite field; any k-1 shares give zero information about the secret.
- Authenticated encryption (AES-GCM) rejects tampered ciphertext instead of decrypting it wrong.
- The hard part of "private AI" is the inference step; today's honest answer is a documented trust boundary, not a buzzword.
What's next
- Splitting shares across genuinely independent holders (separate devices or services) - in this prototype all shares live on the user's device and only share 3 is sent to the relay.
- Exploring the organizer's optional FHE direction for the provider-side exposure.
