[liberationtech] LUKS "Self-Destruct" feature introduced in Kali Linux
wasa bee
wasabee18 at gmail.com
Thu Jan 30 02:16:48 PST 2014
assuming credential info (IV, pwd-encrypted key,etc) is stored with no
recognizable format (not ASN1, no header), it should look indistinguishable
from other encrypted data on disk. So how feasible is it to brute-force the
location of the key + pwd? That must take time. What if cred data is
scattered over the disk rather than written as a continuous blob? How much
mitigation would that introduce?
I'm just wondering what kind of "hardening" could be used against
non-reliable erase features.
Note that if you use an SSD with block management and wear levelling done
in OS, you should be able to delete securely. The problem is mainly for MMC.
On Thu, Jan 30, 2014 at 9:00 AM, Maxim Kammerer <mk at dee.su> wrote:
> On Sat, Jan 18, 2014 at 5:02 AM, Pranesh Prakash <pranesh at cis-india.org>
> wrote:
> > This above description seems to me to be an extreme case of 2FA. Is it
> actually useful?
>
> As noted in Liberté Linux FAQ [1]:
> NOTE: Modern flash memory devices with wear leveling (as well as
> modern HDDs with automatic bad sectors remapping) cannot guarantee
> that the original OTFE header and its backup have been erased.
>
> Also, the developers implemented the functionality by finding some old
> cryptsetup patch and applying it.
>
> I can't think of a scenario where this functionality would be useful.
> Reminds me of Greenwald using his boyfriend as a data mule --
> simultaneously trusting and mistrusting cryptography due to lack of
> understanding of the concepts involved. If you want to move data
> safely, encrypt it with an automatically-generated password of
> sufficient entropy, and transmit the password separately -- there is no
> need to transmit the whole LUKS keyslot, which is large, and is just a
> technical detail.
>
> [1] http://dee.su/liberte-faq
>
> --
> Maxim Kammerer
> Liberté Linux: http://dee.su/liberte
> --
> Liberationtech is public & archives are searchable on Google. Violations
> of list guidelines will get you moderated:
> https://mailman.stanford.edu/mailman/listinfo/liberationtech.
> Unsubscribe, change to digest, or change password by emailing moderator at
> companys at stanford.edu.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.stanford.edu/pipermail/liberationtech/attachments/20140130/1715faf3/attachment.html>
More information about the liberationtech
mailing list