Deniable encryption to combat forced key disclosure

[tonyin...@tutanota.com]

I've tried to search this topic but not come to any clear answers.

Are there any plans to implement this for Qubes?

Usecase: If you are unexpectedly legally or extra-legally coerced to decrypt your laptop.

This project looks very intriguing. However currently I have a system of plausible deniability, but as far as I'm aware this is limited on Qubes.

Could you tell me if the following is possible technically/whether it is planned? In order of most desired to least:

1) Deniable FDE
e.g. TrueCrypt/VeraCrypt-style hidden OS. I'm also not sure if these deniable encryption tools currently work with Qubes as is?

2) Deniable encrypted partitions

3) Deniable encrypted VMs

Thanks for your assistance!

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Yes, we currently have an open issue on this:

https://github.com/QubesOS/qubes-issues/issues/921

There have also been several threads on this in the past. Here is one of the most recent ones:

https://groups.google.com/d/topic/qubes-users/1Qu0v2b7-bg/discussion

Here's an older thread on the topic:

https://groups.google.com/d/msg/qubes-users/tKOVanAupFE/jkOYaN44zksJ

And here are some others:

https://groups.google.com/forum/#!searchin/qubes-devel/deniable$20encryption
https://groups.google.com/forum/#!searchin/qubes-users/deniable$20encryption

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJYEYZqAAoJENtN07w5UDAwyZsQAINL6XujNUKF/iMU6N1YHfcd
aNqfkbab7R9LrjEML5Ph9F63eYEzyydR/ta8ZTQo4J5PwJklvDuVUBWPamjou/MD
7v6rT8J31NAC4S6DhVopQ2tI9ZSMiJDXIl8CP9kJCfxC8bb9QJD0lc1K6yKGl1mD
u4quAH+0rBKN+iPvuFgeRPrgWcMyqyELcNAfqRlf50FRFVvkKcbdGmHX3cznJPsD
l9zUUXJnoxE9yFVoKCiU6A/hk+pYO2pUm4ktOph8i+naf62sLmDaMuvuUs5pq6kk
Q0NrfarGr7Mgz1/cSGfO0J84Sh//9BbWTp3DBqTnt8rqJX06Zft5FiEwqWFRLMuX
bNPRoW1V3BQbeHS5ipgXIbP64bYdZPMC020l1+KIEzX1LzsxDdPELizqqqdg0A5y
WqpXpWfS6Jm3DftjR5E1+Rr8g/iUFNkP5jP8kVSaFGA/bHcC8ya7vzuwh2K2yq7j
OmK6OztA6zDeB9rvlhXNUaMSCfuRTKP27mebxSgrlwB0pd9ACIOEwhz/b1EFiVdJ
SUp4DCkByjIR5+HKwGyqVaeDbY20NsvG5523kn7i12UgcVml0Ai8Oz/B8Ln53ZfO
uo9ERnEPDPv/4Bz3eeTp4MwHIOw9QbvVrYesSF+hMjP1e/aBtZarrSRhbfeRtJqq
/mOPRoM6KzxZVfJbHWzi
=gFA9
-----END PGP SIGNATURE-----

[entr0py]

Andrew David Wong:

> On 2016-10-26 16:19, tonyin...@tutanota.com wrote:
>> I've tried to search this topic but not come to any clear answers.
>
>> Are there any plans to implement this for Qubes?
>
>> Usecase: If you are unexpectedly legally or extra-legally coerced to decrypt your laptop.
>
>> This project looks very intriguing. However currently I have a system of plausible deniability, but as far as I'm aware this is limited on Qubes.
>
>> Could you tell me if the following is possible technically/whether it is planned? In order of most desired to least:
>
>> 1) Deniable FDE
>> e.g. TrueCrypt/VeraCrypt-style hidden OS. I'm also not sure if these deniable encryption tools currently work with Qubes as is?
>
>> 2) Deniable encrypted partitions
>
>> 3) Deniable encrypted VMs
>
>> Thanks for your assistance!
>
>
> Yes, we currently have an open issue on this:
>
> https://github.com/QubesOS/qubes-issues/issues/921
>
> There have also been several threads on this in the past. Here is one of the most recent ones:
>
> https://groups.google.com/d/topic/qubes-users/1Qu0v2b7-bg/discussion
>
> Here's an older thread on the topic:
>
> https://groups.google.com/d/msg/qubes-users/tKOVanAupFE/jkOYaN44zksJ
>
> And here are some others:
>
> https://groups.google.com/forum/#!searchin/qubes-devel/deniable$20encryption
> https://groups.google.com/forum/#!searchin/qubes-users/deniable$20encryption
>
>

I will cough up my passphrase at the mere *suggestion* of torture. I would probably give up my passphrase if a scary person were to just ask nicely for it.

If Qubes were to incorporate any deniability features, I (and anybody who dislikes being tortured) would require a means to show absolutely that such features were not enabled. These are dangerous features because the moment they are incorporated we would all be using them, whether we are or not.

https://defuse.ca/truecrypt-plausible-deniability-useless-by-game-theory.htm

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 2016-10-26 21:45, Andrew David Wong wrote:
> On 2016-10-26 16:19, tonyin...@tutanota.com wrote:
>> I've tried to search this topic but not come to any clear answers.
>
>> Are there any plans to implement this for Qubes?
>
>> Usecase: If you are unexpectedly legally or extra-legally coerced to decrypt your laptop.
>
>> This project looks very intriguing. However currently I have a system of plausible deniability, but as far as I'm aware this is limited on Qubes.
>
>> Could you tell me if the following is possible technically/whether it is planned? In order of most desired to least:
>
>> 1) Deniable FDE
>> e.g. TrueCrypt/VeraCrypt-style hidden OS. I'm also not sure if these deniable encryption tools currently work with Qubes as is?
>
>> 2) Deniable encrypted partitions
>
>> 3) Deniable encrypted VMs
>
>> Thanks for your assistance!
>
>
> Yes, we currently have an open issue on this:
>
> https://github.com/QubesOS/qubes-issues/issues/921
>

On second read, I think I see that you're asking about something different. Truecrypt-style hidden containers aren't really the same as having a "nuke" passphrase (though either one might achieve the same goal in certain coercive situations).

Tracking as a new issue:

https://github.com/QubesOS/qubes-issues/issues/2402

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJYEkACAAoJENtN07w5UDAw2ZkQAIRRbK1rUGya56Y9vUYeG9py
Tp/I1QVwbbzzSzheOwuQsLm3MwUtJwxrS6/837l3FciYdbBid2R1ItKmvclJX815
+AifxgBbTH9hTPNLH+aIp0qoIN3XczyxS8NcShQ+JsyfzVE5etjxqJgYLULB5oe2
iiE0fd5wxas2op01/DR1TVuvuqLTsdTaOt6CYHVj4drxe7mR9ZQ+OfBpLAIoLRGX
cmfwCjyZcEmfu65ZmOIzlByZ466kxp821Ek8inIriy1KweNl5NqS6x/fmQp9CV5U
brxvK2Gio0BwHPG58BqyRmWDYuSrmoSPuwyVo2MStSzp7B8hXjFrWNER8wnuRFIh
G6ikODZ2DnSGDXmh4TpXxgKrUyvtyYcoAA+Pnr4gBXU2SqE2dhv1U4Np2ymjDNBp
RgXaeR8j6hBmHZtNMDOpQuT469CGNPJBoWmP9c1fDZVjDjg/iyqwj61wcjyeocRh
9LdWrEoRgghHppNcNqcm/aEVWpVDnBR+VqItHMiKRsRqn9YCS5vqgmCMcUPiPQMK
JPZV1WTHIcLNCia2mK3ecIqHoyRLHlckkzGtTIzfn2Ji2l4WxbS8NeKVWA5DZL5z
/fgthYzj/szcnU6eM/5Hg+VEDtKTKIj/hqc76gPQQczmdw8hSWJEot9yEhnQWOrp
YZNEz8HmkimeORzV7RwT
=aq8x
-----END PGP SIGNATURE-----

[Peter Todd]

Note that there's no way to prove that an encrypted partition doesn't contain
hidden data. See for example my old prototype, stegbak, for Steganographic
Backups:

https://github.com/petertodd/stegbak

I forget if I actually implemented the following or not, but the ideal
implementation has three steps:

1. Fill partition with random looking "marker" data with a specific HMAC tag
computed with H(block-# | key).

2. Format the prepared partition w/ an encrypted file system and fill with data
you're willing to disclose.

3. Scan through partition and overwrite untouched blocks - identified by a
valid HMAC tag - with authenticated encrypted data.

To extract, just scan the partition again and extract/decrypt the blocks that
pass the authentication step.

This is indistinguishable from an encrypted partition that has been previously
filled with encrypted data and then reformatted. One exception is SSD's w/ TRIM
enabled that erase unused blocks, but Qubes OS has that disabled by default.

--
https://petertodd.org 'peter'[:-1]@petertodd.org