On 8/21/16, Toralf Förster wrote:
> I'm pretty convinced that this is an easy method to ensure an attacker
> even with physical access to a server (eg. while changing a defect
> hard disk) can't achieve the secret key.
rm the key/salt doesn't wipe the underlying data.
Wipe the files or the non sw
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 08/21/2016 06:35 PM, Tom van der Woerdt wrote:
> Side-note wrt your setup :
>
> You're storing the keys on the disk, and while they're removed
> immediately after, that potentially leaves them on the physical storage.
> Since you're already passi
Happy to hear you resolved the problem :-)
Side-note wrt your setup :
You're storing the keys on the disk, and while they're removed
immediately after, that potentially leaves them on the physical storage.
Since you're already passing them through ssh, consider just having ssh
do the stdin bit :
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 08/21/2016 03:23 PM, Tom van der Woerdt wrote:
> Did this work prior to adding encryption, or could that be a red
> herring?
It was the attempt to encrypt the Tor directory using the ext4 method
- - GRSecurity is fine (works since 2 years like a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 08/21/2016 03:23 PM, Tom van der Woerdt wrote:
> what it fails on with strace? Is tor actually running as the 'tor' user?
> Do you have any special security configuration like sandboxing set up?
>
> Tom
Well, whilst disabling the SandBox at least
Op 21/08/16 om 15:14 schreef Toralf Förster:
> Hi,
>
> I made the following steps to have /var/lib/tor encrypted under an ext4fs
> under a stable Gentoo Linux:
>
> at a local system:
> head -c 16 /dev/random | xxd -p > ~/tmp-salt.txt; echo 0x`cat
> ~/tmp-salt.txt` > ~/.cryptoSalt; rm ~/tm
