Re: [liberationtech] LUKS "Self-Destruct" feature introduced in Kali Linux
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2014.01.31 11.31, Amin Sabeti wrote: > In the Iran case, I think using TrueCrypt would be better because > hiding files is more important than destroying it. For instance, it > would be not practical to destroy files when the authorities > confiscate your laptop. Be aware that even if Truecrypt gets everything right (something the forthcoming audit will hopefully reveal), the list of requirements for using deniable volumes correctly in a manner that does not reveal their existence is quite long, even just look at what's present in their documentation. If you're going to rely on this for opsec, please carefully evaluate whether you are up to dealing with this level of effort. An incompletely hidden volume that shows clear intent may raise more flags than a simple encrypted volume. Likewise, if you're using tools that support data "deniability" features and believe you may be questioned, please evaluate carefully what you'll do if accused of having hidden a non-existent hidden volume. Developers of such tools, consider carefully whether by adding features like this you're actually improving security outcomes for your users; consider talking to them about it, maybe. E. - -- Ideas are my favorite toys. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) iF4EAREIAAYFAlLrkN4ACgkQQwkE2RkM0wrRPAD9GvR+jLaFhResDvsW/ZziLw0W vz6BuDgRR3nK3olL81MA/iwfQ4TGPV9HxdJKWFy9AtEE7eFZjTnEgvabkzJzG9mq =easI -END PGP SIGNATURE- -- 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 compa...@stanford.edu.
Re: [liberationtech] LUKS "Self-Destruct" feature introduced in Kali Linux
Kali is a pentesting Linux distro. I would suggest that this is more a method for keeping client data relatively safe, as opposed to smuggling state secrets out of a country. This is not intended to be used as a secure transport distro and its being read into too much. The functionality exists because some may find it useful on assignments to China, for instance. If you have serious documentation transportation to do, and you want to use Kali to transport your data, then you are doing it wrong. On 31 Jan 2014 21:32, "Amin Sabeti" wrote: > In the Iran case, I think using TrueCrypt would be better because hiding > files is more important than destroying it. For instance, it would be not > practical to destroy files when the authorities confiscate your laptop. > > > On 30 January 2014 20:54, Sean Lynch wrote: > >> >> On Thu, Jan 30, 2014 at 1:00 AM, Maxim Kammerer wrote: >> >>> >>> 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. >>> >> >> I don't think even this is useful. It'd be as easy or easier to go get >> the separately transmitted key than to get you to reveal it, and the same >> tactics that would get you to reveal the key could also get you to reveal >> its location or the identity of whoever has the key. >> >> In the more likely scenario, it's unlikely the bad guys are going to make >> any distinction between your refusing to reveal the key and your being >> unable to reveal the key. It's not like they're going to say "Damn, we've >> lost. Well, just let them go, then!" >> >> The only real protection from being compelled to reveal a key is for the >> bad guys not to know the encrypted data even exists. >> >> -- >> 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 >> compa...@stanford.edu. >> > > > -- > 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 > compa...@stanford.edu. > -- 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 compa...@stanford.edu.
Re: [liberationtech] LUKS "Self-Destruct" feature introduced in Kali Linux
In the Iran case, I think using TrueCrypt would be better because hiding files is more important than destroying it. For instance, it would be not practical to destroy files when the authorities confiscate your laptop. On 30 January 2014 20:54, Sean Lynch wrote: > > On Thu, Jan 30, 2014 at 1:00 AM, Maxim Kammerer wrote: > >> >> 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. >> > > I don't think even this is useful. It'd be as easy or easier to go get the > separately transmitted key than to get you to reveal it, and the same > tactics that would get you to reveal the key could also get you to reveal > its location or the identity of whoever has the key. > > In the more likely scenario, it's unlikely the bad guys are going to make > any distinction between your refusing to reveal the key and your being > unable to reveal the key. It's not like they're going to say "Damn, we've > lost. Well, just let them go, then!" > > The only real protection from being compelled to reveal a key is for the > bad guys not to know the encrypted data even exists. > > -- > 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 > compa...@stanford.edu. > -- 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 compa...@stanford.edu.
Re: [liberationtech] LUKS "Self-Destruct" feature introduced in Kali Linux
On Thu, Jan 30, 2014 at 1:00 AM, Maxim Kammerer wrote: > > 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. > I don't think even this is useful. It'd be as easy or easier to go get the separately transmitted key than to get you to reveal it, and the same tactics that would get you to reveal the key could also get you to reveal its location or the identity of whoever has the key. In the more likely scenario, it's unlikely the bad guys are going to make any distinction between your refusing to reveal the key and your being unable to reveal the key. It's not like they're going to say "Damn, we've lost. Well, just let them go, then!" The only real protection from being compelled to reveal a key is for the bad guys not to know the encrypted data even exists. -- 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 compa...@stanford.edu.
Re: [liberationtech] LUKS "Self-Destruct" feature introduced in Kali Linux
well, encryption software are already hard to use "Greenwald struggled with the software for a while, but then gave up and blew off Snowden. Snowden then got in touch with Laura Poitras, who was already an expert on encryption" http://www.dailykos.com/story/2013/08/28/1233355/-Can-anyone-help-me-set-up-PGP-encrypted-E-mail-It-s-the-mark-of-an-investigative-reporter How much would your not-so-technically-complicated solution cripple usability? You might argue that if you're encrypted ur data + afraid of being coerced to reveal the key, then ur a sufficiently high target to take the extra hassle... On Thu, Jan 30, 2014 at 3:25 AM, Charles Haynes wrote: > Yes it's useful but it's maybe more complicated than necessary. You > encrypt the information and make sure the decryption key is sent to a safe > destination via a different route. While in transit you cannot be compelled > to give up encryption keys because you do not have them (unlike a TrueCrypt > hidden volume.) When you arrive safely at your destination you retrieve the > decryption key and restore your data (unlike a self-destruct.) > > -- Charles > > -- > 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 > compa...@stanford.edu. > -- 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 compa...@stanford.edu.
Re: [liberationtech] LUKS "Self-Destruct" feature introduced in Kali Linux
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 wrote: > On Sat, Jan 18, 2014 at 5:02 AM, Pranesh Prakash > 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 > compa...@stanford.edu. -- 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 compa...@stanford.edu.
Re: [liberationtech] LUKS "Self-Destruct" feature introduced in Kali Linux
On Sat, Jan 18, 2014 at 5:02 AM, Pranesh Prakash 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 compa...@stanford.edu.
Re: [liberationtech] LUKS "Self-Destruct" feature introduced in Kali Linux
Yes it's useful but it's maybe more complicated than necessary. You encrypt the information and make sure the decryption key is sent to a safe destination via a different route. While in transit you cannot be compelled to give up encryption keys because you do not have them (unlike a TrueCrypt hidden volume.) When you arrive safely at your destination you retrieve the decryption key and restore your data (unlike a self-destruct.) -- Charles -- 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 compa...@stanford.edu.
[liberationtech] LUKS "Self-Destruct" feature introduced in Kali Linux
This might be of interest to some on this list: http://www.kali.org/how-to/nuke-kali-linux-luks/ The LUKS encrypted partition self-destructs if a specific "nuke password" is used. > Our main purpose for introducing this feature in Kali Linux is to simplify > the process of securely traveling with confidential client information. While > “LUKS Nuking” your drive will result in an inaccessible disk, it is possible > to backup your keyslots beforehand and restore them after the fact. What this > allows us to do is to “brick” our sensitive laptops before any travel, > separate ourselves from the restoration keys (which we encrypt), and then > “restore” them to the machines once back in a safe location. This way, if our > hardware is lost or otherwise accessed midway through our travels, no one is > able to restore the data on it, including ourselves. This above description seems to me to be an extreme case of 2FA. Is it actually useful? By contrast, Guardian Project's ChatSecure has a simple self-destruct button and TrueCrypt allows for hidden volumes that can be accessed through a different password. -- Pranesh Prakash Policy Director, Centre for Internet and Society T: +91 80 40926283 | W: http://cis-india.org --- Access to Knowledge Fellow, Information Society Project, Yale Law School M: +1 520 314 7147 | W: http://yaleisp.org PGP ID: 0x1D5C5F07 | Twitter: https://twitter.com/pranesh_prakash -- 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 compa...@stanford.edu.
