brendan.h...@gmail.com:
Other discussions involved performing the
encryption inside the VMs, but as I mentioned earlier, if the content in
the VM that is being manipulated is untrustworthy...then is the VM's
internal encryption really trustworthy?
This is a good point which I hadn't thought
Use this one instead, previous one had a missing newline:
https://pastebin.com/JMtuns8g
Brendan
--
You received this message because you are subscribed to the Google Groups
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to
On Thursday, December 19, 2019 at 12:09:26 PM UTC-5, Brendan Hoar wrote:
>
> This script shows the approach I take for an ephemerally keyed lvm pool:
>
> https://pastebin.com/LDKKwsWW
>
>
And of course, since I was in a hurry, I see typos and better possible
edits in the explanatory text it
This script shows the approach I take for an ephemerally keyed lvm pool:
https://pastebin.com/LDKKwsWW
Assuming you want a windows standalone work VM and one or more whonix
disposable VMs, you just need to change the two variables in the script and
launch it in dom0.
Be sure you know what
On Wednesday, December 18, 2019 at 10:04:40 AM UTC-5, steve.coleman wrote:
>
> On 2019-12-15 22:04, brend...@gmail.com wrote:
> My suggestion is, rather than the time consuming wiping of bits after
> the fact would be to instead create an encrypted volume/partiton/pool
> when launching a
On Monday, December 16, 2019 at 5:33:52 PM UTC-5, Claudia wrote:
>
> brend...@gmail.com :
> > Disposable VMs were not developed with anti-forensics in mind (e.g. no
> protection in jurisdictions where you can be forced to hand over your drive
> password
> Never thought about it, but that makes
brendan.h...@gmail.com:
Disposable VMs were not developed with anti-forensics in mind (e.g. no
protection in jurisdictions where you can be forced to hand over your drive
password
Never thought about it, but that makes sense. I can see how it would be
easy to confuse "non-persistence of
As to the first question: with qubes 4.0 it is a bit difficult to effectively
wipe free space in the default thin pool.
One can create a thin volume and write to it until the thin pool reaches some
saturation level (99.5%), then hit that volume with blkdiscard before invoking
lvremove. Because
Disposable VMs were not developed with anti-forensics in mind (e.g. no
protection in jurisdictions where you can be forced to hand over your drive
password).
That being said...
In 4.0 (updated) qubes now calls blkdiscard on volumes being removed before
invoking lvremove. If you happen to use
josefh.maier via qubes-users:
Hello list,
I heard that a Qubes-user was forced to hand over the Qubes-password, and that
a forensic examiner was able to restore artifacts of a deleted disposeable form
the harddisk...
Is this story possible? And what's the best aprroach to wipe diskspace used
On Thu, 12 Dec 2019 16:58:41 +0100
"josefh.maier via qubes-users" wrote:
> Hello list,
>
> I heard that a Qubes-user was forced to hand over the Qubes-password,
> and that a forensic examiner was able to restore artifacts of a
> deleted disposeable form the harddisk...
>
> Is this story
Hello list,
I heard that a Qubes-user was forced to hand over the Qubes-password, and that
a forensic examiner was able to restore artifacts of a deleted disposeable form
the harddisk...
Is this story possible? And what's the best aprroach to wipe diskspace used
before by a disposable VM
12 matches
Mail list logo
