additional security (II)
If I understand tarsnap from previous posts correctly, there seem to be various keys, e.g. for sending data, for deleting data, for listing data. Coming back to my previous suggestion to bring the security level more in accordance with the philosophy adhered to by the Qubes-OS designers at qubes-os.org, i.e.: 'do not leave your secret passphrases/-words on a net-connected computer of VM', I would suggest to look into the possibility of a command line option which would allow users to paste the required part of the key file in the terminal when needed. If that would be possible, I could store my keyfile (or -files, as I think them keys would preferably be stored in separate files) on a 'Vault-VM' which has no physical connection to the internet as it is 'perfectly isolated' using Intel's VT-d and VT-x processor features and thanks to Qubes-OS's design (and hopefully implementation). Then, when invoking tarsnap with the --paste-keys (or whatever) option, I could be queried for the appropriate key (for writing, reading, deleting) whenever needed and copy/paste it from the Vault-VM into the VM's terminal running tarsnap at that moment. The (part of the) keyfile would then only reside in RAM during the time that tarsnap is running (and does it really need to stay there all the time?), making it more difficult for hackers to catch it. Impossible? Or even nonsense talk? I'm not such a 'code reader' that I can easily find this myself in 'the source code', and maybe someone has enough knowledge of the inner workings to find it easy to answer this question. And please, after Snowden's publications, don't call me 'truly paranoid' anymore. 'Truly realistic' would be more appropriate ;-) .
Re: additional security (II)
mån 2014-03-31 klockan 08:05 + skrev tarsnap: ... The (part of the) keyfile would then only reside in RAM during the time that tarsnap is running (and does it really need to stay there all the time?), making it more difficult for hackers to catch it. Couldn't you just as easily solve that part yourself by at the backup moment copy your tarsnap key to a tmpfs mount? To be on the safe side it probably wouldn't hurt to disable swap, or go with an encrypted swap. // Andreas signature.asc Description: This is a digitally signed message part
Re: additional security (II)
On Mon, 31 Mar 2014 10:32:28 +0200 Andreas Olsson andr...@arrakis.se wrote: mån 2014-03-31 klockan 08:05 + skrev tarsnap: ... The (part of the) keyfile would then only reside in RAM during the time that tarsnap is running (and does it really need to stay there all the time?), making it more difficult for hackers to catch it. Couldn't you just as easily solve that part yourself by at the backup moment copy your tarsnap key to a tmpfs mount? To be on the safe side it probably wouldn't hurt to disable swap, or go with an encrypted swap. // Andreas Yes I could even copy it to tarsnap's regular keyfile directory on the VM of which I'm managing the backup and remove it afterwards, but what I was aiming at was to not at all have it on any file system (or am I technically wrong in that RAM is a file system also?) that is part of a net-connected VM. You are right though that having it temporarily on a net-connected file system will lower the exposure but I really would like to go that one step further, if possible. thanks
Re: additional security (II)
Why? Tarsnap makes it hard to store nothing, but easy to store just a key that allow only making backups. So if the NSA breaches your computer, they can learn enough to make backups in your name. They cannot read your existing backups (or even the backups they made). It leaves you open to a DoS, I suppose. An attacker can spend your money. Arnt
Re: additional security (II)
On Mon, 31 Mar 2014 12:08:45 +0200 Arnt Gulbrandsen a...@gulbrandsen.priv.no wrote: Why? Tarsnap makes it hard to store nothing, but easy to store just a key that allow only making backups. So if the NSA breaches your computer, they can learn enough to make backups in your name. They cannot read your existing backups (or even the backups they made). It leaves you open to a DoS, I suppose. An attacker can spend your money. Arnt This is new to me. Is the same keyfile not also used to restore (i.e. read) my backups? In that case I think 'our friends' (NSA and such) do have a way of reading my backups, or am I wrong? Or do you mean that I can separate the restore key from the keyfile and store it somewhere else for later use? That would be a solution too. But I've tried to read the keyfile, and all I saw was one sequence of ASCII characters, no separate sections. Or is that because I didn't do any restore yet? I must admit, I do not really know a lot of the inner workings of tarsnap, so please forgive me if I'm talking nonsense (again?). thanks
Re: additional security (II)
mån 2014-03-31 klockan 12:13 + skrev tarsnap: ... Or do you mean that I can separate the restore key from the keyfile and store it somewhere else for later use? http://www.tarsnap.com/man-tarsnap-keymgmt.1.html // Andreas signature.asc Description: This is a digitally signed message part
