On Tue, Aug 13, 2013 <various_people> wrote:
VPS, containers, dedicated, encrypted disk, whatever... it's all the same, the filesystem and bits on disk, particular when running, are exposed to whoever is holding the box. Since it's not your box in your DC where you stand guard 24x7, nor have you audited Tor against remote exploit, all bets regarding the Tor keys are void.
That said, reasonable gains to the limit of what tpo could do: I've suggested that the controller be enhanced so that you can add/drop/mod the controller access token and Tor keys directly to a Tor in standby mode without ever requiring disk. Some modes of node deployment/use are disposable anyway so just autogenerate them and never write them out in that case.
It's better than most people's weak passphrase on a disk based Tor key (not yet possible either) or cryptdisk would be. And better than FS mounted ramdisk too. Yet there's still dump memory or cold boot, but it's harder and not immediately obvious as being necessary to do.
privatecore.com? Userland requires cleartext. At the app level you could have the equivalent of the user kernel doing encryption within its malloc(3/9), as with zeroing/randomizing today. And if the hypervisor is doing it above and for the user kernel, then the whole per VM space under that is internally accesible. Depending on what parts of the system are exploited you could get some protection against trolling the ram of other containers through non-zeroed ram and top level dumb dma/cold dumps, excluding the encryption buffers. But that's probably it. And it won't be fast. They don't have publicly posted whitepapers. Its software and could be reimplemented by opensource projects.
Ultimately, if you don't own the entire physical and logical path to your app, you can't trust it.