So I was reading this article about Signal-creator Moxie Marlinspike’s new project, Confer , which claims to be a verifiably E2E encrypted LLM chat service. There are a couple of short blog articles that give the gist of it, and some github repos including this one that includes scripts for producing the VM that will run your particular LLM session. But if I’m following this all correctly, it implies that every chat session (or perhaps every logged-in user) would have their own VM running their own LLM to ensure that the chain of trust is complete. This seems impossible from a scalability perspective, as even small LLMs require huge quantities of RAM and compute. Did I miss something fundamental here?
On the topic of private LLM chat bots, what is your opinion on Lumo? https://lumo.proton.me/about
I think it’s a pragmatic approach to a difficult problem. You’re still trusting that Proton is doing what they claim to be doing by not logging any of the data, and it lacks the verifiable trust chain of the VM that this Conifer system has (which theoretically would let you audit the code to confirm that there is no logging going on, and then check the crypto hash of the VM running your LLM conversation to confirm that it is in fact running that code), but if you trust Proton this step isn’t as important. Otherwise the approaches look fairly the same.Proton is using PGP for the inflight encryption to the LLM while Conifer is using… maybe PGP too, I’m not sure, but a similar approach. And as others have said here, LLMs are stateless so if you can trust that the platform isn’t logging the requests, there should be no record of your discussions.
Just use Ollama if you have enough power to run a model.
The blog article you link I think implies you do not have your own VM. LLMs are stateless, the previous conversation is fed in as part of the prompt.
You send your message, which is E2E encrypted. The LLM runs in an environment where it can decrypt your message and run in through the LLM, then send a response to you. Then it gets the next user’s message and replies to them.
The key part is that the LLM is running inside an encrypted environment not accessible to the host system, so no one can watch as it decrypts your message.
That’s what I get from reading your links.
deleted by creator
Ok, I interpreted it to mean that the VMs were being created as-needed and was keyed to your key specifically (which would be the most secure scenario, I think) and couldn’t figure out what that could possibly work economically. But it makes more sense if just a separately encrypted host is decrypting your request and encrypting your reply along with everyone else’s.
They think they can get security by using a proprietary chip to hide from the rest of the computer. This is a blantant lie.
Not really a lie, it just highly relies on the guarantees these chips can provide. In the past there have been multiple issues with the design or implementation of these things: https://sgx.fail/ https://tee.fail/
The only guarantee: backdoored by design, proprietary.
Possibly oversimplifying and didn’t have a proper read yet: If you trust the hardware and supply-chain security of Intel but not the operational security of Cloudflare or AWS, this would allow you to exchange messages with the LLM without TLS-encryption-stripping infrastructure operators being able to read the messages in cleartext.
This is a form of Confidential Computing based on Trusted Execution Environments. IMO the real compelling use of TEEs is Verifiable Computing. If you have three servers all with chips and TEEs from different vendors, you can run the same execution on all of them and compare results, which should always agree. You will be safe from the compromise of any single one of them. For Confidential Computing, any single one being compromised means the communication is compromised. The random nature of LLM applications makes Verifiable Computing non-trivial and I’m not sure what the state-of-art is there.
And yes it does look like it has overhead.
This seems impossible from a scalability perspective, as even small LLMs require huge quantities of RAM and compute. Did I miss something fundamental here?
Well isn’t it the other way around? If the per-user resources are high, the additional sublinear overhead of isolating gets relatively smaller. It costs more to run 1000 VMs with 32MB RAM each vs 2 VMs with 16GB RAM each.
However I guess this might get in the way of batching and sharing resources between users? Is this mentioned?
I wonder if we can really trust the TEEs. Isn’t it their hardware where they are quite free to do what they want? Also it looks very vulnerable to the side-channel attacks.
The random nature of LLM applications makes Verifiable Computing non-trivial and I’m not sure what the state-of-art is there.
Running inference is only pseudorandom, the output is then treated as a distribution and a pseudorandom selection is made according to the distribution. The heavy compute parts are all deterministic, the bit at the end that adds chatbot flavor is only pseudorandom.
As long as they share entropy sources, given the same seed they will always produce the same output. This is a trick that’s exploited in image generation applications, using cached execution keyed on the seed means that alterations only need to be calculated at the part of the pipeline that needs to be changed (saving all of the previous steps).
LLMs don’t have to be random AFAIK: if you turn down the temperature parameter and send the same seed every time you get the same result
https://dylancastillo.co/posts/seed-temperature-llms.html
for most people this isn’t exactly what you want because “temperature” is sometimes short-handed as “creativity”. it controls how out of left field the result can be
The articles are light on detail but the code’s all there. The approach makes sense if the VMs are not cryptographically signed with the user’s key, but are just signed against another key to verify authenticity. I read it as if each VM was created on the fly for a user and signed with that users’s key, but that seems unlikely after re reading it.
in TEE environment
Moxie loves these closed-source hardware enclaves. Signal servers and MobileCoin rely on this too, if I’m not mistaken.
In my opinion this not the right way to go about these things, but then again I’m not a renowned cryptohead like Moxie.For both MobileCoin and Signal the TEE are not relied upon for the security of the general application but only for some convenience feature that are required for mass adoption but that you can go without using them.
Also, while TEE are not bulletproof, in such a server situation, it means that getting user data means much more invasive compromise than just querying the database. It’s an imperfect solution, but an improvement nonetheless.
off topic, but of all the fix-worthy things, that’s what needed his attention?
What other cryptographic practical applications are more worthy of his attention right now?
you should let go of the imprinted idea that in order to criticise something you hafta offer a better, fully fleshed out alternative; you are allowed to say X is shitty on its own.
coming from the guy who improved and converted the utterly cumbersome PGP stack to a usable thing with TextSecure/RedPhone (those got later merged into Signal), yeah, this shit is underwhelming, to say the least.
I’m gonna go out on a limb and state that securing the pipe between you and the word-guessing program isn’t currently high on anyone’s list.
offer a better, fully fleshed out alternative
is a bit of straw man. Offering a rough list of alternatives for discussion would be sufficient response to the question.
you are allowed to say X is shitty on its own
while true, this ignores that your original statement was challenging this choice over other possibilities. So yes, you can just say it’s a shitty choice, but you (colloquially, at least) implied there exist better choices in your opinion. So it is reasonable to ask what those might be.
I ain’t gotta offer nothing, my take is that securing the pipe to the stochastic parrot is a shit waste of time and effort, especially when it’s coming from techno jesus.
if he’s bored, there’s list of shit to implement in signal longer than m- err, it’s long. and what ain’t on it is more AI and/or crypto wallets. fuckin GRR Martin clone over here…
So he switched from crypto to LLMs now?
This is still crypto, yo
He, more than others, has earned rights to move freely between technology industries without scrutiny.
Trust, but verify.
Like this time when they didn’t release the Signal server code for more than a year only to suddenly include a cryptocurrency that basically had a non-existent userbase but that Moxie was a chairman(?) of and nobody really knew whether or rather how much he was financially invested in. Good times /s
