J.M. Porup:
> On Wed, Jun 29, 2016 at 02:30:34PM -0700, flux wrote:
>> My thoughts were more along the lines of mitigative travel protection 
>> crossing borders and such. Like, you can boot to decryption but if the 
>> device is seized, no valid decryption can actually be performed. But as you 
>> say, depending on your situation that could be disadvantageous. I 
>> additionally just enjoy the idea of separating keys from locks regardless of 
>> the encrypted state of those keys.
> 
> FWIW, I support this feature request as well. Search the archives for
> previous discussion early 2015 (Caspar Bowden indicated his support for
> the feature, before he passed.)
> 
> Overreliance on a boot nuke feature would, as pointed out, be unwise.
> But as a journalist, I can easily imagine a scenario where I am crossing
> a border, am asked/ordered to decrypt my laptop, and I prefer to nuke
> the hard drive rather than comply.
> 
> Sure, border officials might image the disk first, but how many laptop
> users have such a feature?
> 
> I think of it like TLS. Arguing that X.509 certificate infrastructure is
> broken and not (very) trustworthy doesn't mean we should insist Qubes
> return to a non-HTTPS website. It's a layer of protection, one of many.
> 
> So I support this feature request, while noting the priority is low.
> 
> jmp
> 

But tell me: why/when exactly would you use such a feature?  Surely when
entering the US you would have to be crazy to use this unless you are
afraid your passphrase is too weak/compromised and you took no other
precautions.  You could be charged with a crime simply for destroying
the data, whereas you have a 5th amendment right not to hand over the
passphrase!

You could also, before traveling, XOR your LUKS header with some known,
memorable data (perhaps the output of iterated SHA256 on a separate
passphrase).  Bring along a live CD/USB and un-do it once you're past
the border.

Or change your passphrase to a very long random string you give to a
friend/family member, whom you only call and direct to read the
passphrase (which you subsequently change) after crossing the border
without interception.

Or do something similar but with a webserver or email/IRC/Slack bot:
give it your temporary password, and have it provide the password if you
request it soon after expected arrival, or shred the password if you
don't request it in time.

There are surely a million other, better ways to avoid compelled data
decryption at borders.  Anyway I don't have a problem with this feature.
 I just still don't understand why...

Andrew

-- 
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 [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/f449098b-165e-ee17-c8b3-10b1f5012892%40riseup.net.
For more options, visit https://groups.google.com/d/optout.

Reply via email to