The AI guessing portion is currently playing on ultra-easy mode because there are only a few useful LLMs to compare to, and none of those have given serious thought to strongly securing their tech demosolution communications channel yet.
This is important work though, since someday someone might use an AI for something important and actually want to prevent eavesdropping.
I’m being a little unfair, but it’s early days and let’s try not take ourselves too seriously just yet. If I’m trusting one of these LLMs with something deeply sensitive, it’s not eavesdropping that’s going to get me into deep shit, it’s the LLM’s hallucinations.
This is important research, though. Someday the AI will get good, and I’ll want to chat with it securely.
Thankfully, I suspect mitigation will be quite straightforward. Carefully designed small random changes to token handling should throw this approach way off, while not even being noticed by end users.
The habit of sending tokens right as they generate is a dumb sales gimmick that needs to go away anyway. So if security folks manage to kill it, good riddance.
Someday the AI will get good, and I’ll want to chat with it securely.
GPT4 is pretty good now. I’m not convinced it will be secure until we can run it locally on our own hardware.
As soon as we can run it locally, I plan to do so. Even if it means using a GPT4 quality LLM when far better exists if I use a cloud service.
The habit of sending tokens right as they generate is a dumb sales gimmick
Seems like it would be trivial to just place tokens in a buffer on the server and send output to the client in say 1KB chunks (a TCP packet can’t be much bigger than that anyway, and it needs a bit of space for routing metadata).
And if the entire output is less than 1KB… pad it out to that length. Pretty standard to do that anywhere you care about security… e.g. if you were to dump the password table databases… they’re all 256 bits. That’s obviously not the real length - most will be shorter, some will be longer. Whatever they are it’s cryptographically expanded (or shortened) to 256.
Interesting stuff, but probably not huge news.
The AI guessing portion is currently playing on ultra-easy mode because there are only a few useful LLMs to compare to, and none of those have given serious thought to strongly securing their
tech demosolution communications channel yet.This is important work though, since someday someone might use an AI for something important and actually want to prevent eavesdropping.
I’m being a little unfair, but it’s early days and let’s try not take ourselves too seriously just yet. If I’m trusting one of these LLMs with something deeply sensitive, it’s not eavesdropping that’s going to get me into deep shit, it’s the LLM’s hallucinations.
This is important research, though. Someday the AI will get good, and I’ll want to chat with it securely.
Thankfully, I suspect mitigation will be quite straightforward. Carefully designed small random changes to token handling should throw this approach way off, while not even being noticed by end users.
The habit of sending tokens right as they generate is a dumb sales gimmick that needs to go away anyway. So if security folks manage to kill it, good riddance.
GPT4 is pretty good now. I’m not convinced it will be secure until we can run it locally on our own hardware.
As soon as we can run it locally, I plan to do so. Even if it means using a GPT4 quality LLM when far better exists if I use a cloud service.
Seems like it would be trivial to just place tokens in a buffer on the server and send output to the client in say 1KB chunks (a TCP packet can’t be much bigger than that anyway, and it needs a bit of space for routing metadata).
And if the entire output is less than 1KB… pad it out to that length. Pretty standard to do that anywhere you care about security… e.g. if you were to dump the password table databases… they’re all 256 bits. That’s obviously not the real length - most will be shorter, some will be longer. Whatever they are it’s cryptographically expanded (or shortened) to 256.