Egregoros

Signal feed

API Docs
Timeline

Post

Remote status

Context

2
Paco (2026: New) Hope

Paco (2026: New) Hope

@paco@infosec.exchange remote
Open link

This silly statement from #openai about #security drives me crazy. People talk about this all the time as if it means something.

‘files in ChatGPT as a whole are "encrypted by default at rest and in transit"’

What attack does that encryption at rest defeat? What hacker says “darn it! I would have gotten the data if it hadn’t been for that pesky encryption at rest?”

Think it over. Go ahead. I’ll wait.

Physical theft of hard drives/storage. That’s it. Encryption at rest at OpenAI, or any cloud, defeats the same singular attack that it defeats when you encrypt the hard drive on your laptop: if someone physically steals the device, they don’t get the data.

They can sell your data. They can store it (encrypted at rest) on a web site that has a vulnerability or incorrect security, and bad people can download the unencrypted data. They can share it with “partners” who misuse it. Encrypting at rest is NOT an important protection. Literally every other protection is more important.

https://www.darkreading.com/remote-workforce/chatgpt-health-security-safety-concerns

David Chisnall (*Now with 50% more sarcasm!*)

David Chisnall (*Now with 50% more sarcasm!*)

@david_chisnall@infosec.exchange remote
Open link

@paco Encrypted in transit and at rest is a baseline for cloud providers. It’s a necessary layer for any multitenancy offering to allow customers to build useful security on top (some argue that encrypted in use is also necessary). If that’s what they’re saying, that’s the same as saying ‘we use Azure and don’t configure any of the more expensive security options or build anything on top of that’.

Replying to @david_chisnall@infosec.exchange

Replies

6
Replying to @paco@infosec.exchange
David Chisnall (*Now with 50% more sarcasm!*)

David Chisnall (*Now with 50% more sarcasm!*)

@david_chisnall@infosec.exchange remote
Open link

@paco

If you move storage between tenants, you must clear it to prevent information leakage. Modern storage is quite hard to reliably erase and firmware bugs may make it possible to accidentally expose old versions. If you encrypt with a key that is at least unique to the tenant then anyone who tries to exploit this kind of thing gets data that looks random. In many cases, the encryption layer is hard to bypass, so you get some bytes that are encrypted with one AES key and decrypted with another, which is indistinguishable from random.

Replying to @david_chisnall@infosec.exchange
Replying to @feld@friedcheese.us
Replying to @vinoth@infosec.exchange
Replying to @feld@friedcheese.us
David Chisnall (*Now with 50% more sarcasm!*)

David Chisnall (*Now with 50% more sarcasm!*)

@david_chisnall@infosec.exchange remote
Open link

@feld @paco

The Morello cluster we set up at MS was exposed for GitHub Actions runners. We forwarded the GitHub web hook thing to an Azure message queue thing that the head node read. When it received one, it used an exciting pile of expect scripts to talk to the serial console on a node to boot one of the machines. The node then booted with a read-only NFS mount as the root filesystem, generated a random key, and used that for a GELI-encryped read-write filesystem on the (200GB) local SSD. The GitHub Actions runner (actually, the portable Go rewrite) then pulled the job to run. At the end, we rebooted the node and the next job would get a new key for disk encryption.

If a job left any important data on a node, the next user would get the encrypted data and, unless they deleted the GELI layer, would get it decrypted with a different key. We didn't need to bother scrubbing anything between uses.

Replying to @david_chisnall@infosec.exchange