6 ms·

There is https://github.com/kriswebdev/cryptsetup-deluks https://github.com/kriswebdev/cryptsetup-deluks: "The DeLUKS header is designed to be indistinguishible

by rendx 6y ago

There is https://github.com/kriswebdev/cryptsetup-deluks https://github.com/kriswebdev/cryptsetup-deluks: "The DeLUKS header is designed to be indistinguishible from random data." And also volumes by the quite popular TrueCrypt and its successor VeraCrypt have random headers... https://www.raedts.biz/forensics/detecting-truecrypt-veracrypt-volumes/ https://www.raedts.biz/forensics/detecting-truecrypt-veracry... Looks like a nice enough project, but be careful with claims like "first".

notfed 6y ago
> DeLUKS Interesting, hadn't seen this project yet, or would have been more careful, thanks. A few thoughts: - The lack of a link to a white paper makes DeLUKS difficult to analyze, but it looks like they're hashing the password using PBKDF2-SHA1, which is quite outdated. (PUREE uses argon2id.) - The installation/usage seems slightly complex. I'd suggest people compare to the PUREE quick start instructions. > TrueCrypt/VeraCrypt As per your link: "When you create an encrypted volume using TrueCrypt or VeraCrypt it is stored as a file (container) on your hard drive.". And as per VeraCrypt's wikipedia page: "VeraCrypt supports plausible deniability[16] by allowing a single "hidden volume" to be created within another volume" I didn't read too much deeper, but the phrases "stored in a file" and "hidden volume within another volume" are red flags.
- yjftsjthsd-h 6y ago
  > the phrases "stored in a file" and "hidden volume within another volume" are red flags. Why? Files are lot easier than full partition encryption. And how else would you hide a volume with anything like plausible deniability?
  - capdeck 6y ago
    If entire disk appears to be empty - it is much more plausible to have an argument that this is indeed just an empty spare. If you have a "hidden" file -- that file can be found to begin with -- _something_ in the file system will be pointing at it. And then - a large file filled with random data - that's one hell of a red flag if I ever saw one.
    - frei 6y ago
      It's not an actual file, it's unmarked in the free space of the first volume. If you mount only the first volume, it will appear normal, and data loss will occur if more space is used. https://www.truecrypt71a.com/documentation/plausible-deniability/hidden-volume/ https://www.truecrypt71a.com/documentation/plausible-deniabi... Also, as jchw mentioned above, the headers are indistinguishable from random data already, and truecrypt supports full volume encryption already. This nesting feature is on top of the "volume looks like random data" feature.
- marcinzm 6y ago
  TrueCrypt can also do full disk encryption however full disk encryption is LESS safe than a hidden file/volume. The reason is that the lack of a non-encrypted volume on a disk implies there is an encrypted volume. The existence of a dummy non-encrypted volume does not. Plausible deniability keeps you safer especially in cases where not providing a decryption key results in indefinite jail time.
  - StavrosK 6y ago
    TrueCrypt can do full disk encryption with plausible deniability (a separate passphrase mounts a different encrypted section).
- jchw 6y ago
  TrueCrypt/VeraCrypt can do the same stuff but with physical drives, so yes, the claim of 'first' is inaccurate even with that technicality in mind. The reason why that's not the focus of TrueCrypt/VeraCrypt is because they also go significantly further. One problem with plausible deniability with this concept is that it's difficult and limiting to have to try to hide traces of access to an encrypted disk from a host OS that is stored on unencrypted media (and, obviously since it's the point of the whole project, even if it was encrypted, you could be compelled to decrypt it.) TrueCrypt/VeraCrypt FDE supports hiding an encrypted, bootable partition within the free space of another encrypted, bootable partition, in such a way that it is not generally possible to tell that there is a hidden partition, but you can boot into either depending on what password you enter. (Of course, the bootloader that allows you to enter the password is not encrypted, so for bootable partitions there is evidence that some encrypted partition exists, but this is unavoidable.)
  - notfed 6y ago
    I fully admit to prior ignorance of VeraCrypt's abilities. From what I read on their website, I don't disagree with you. I will add that the PUREE specification does support subvolumes: different passwords may unlock different regions of the disk. Yet, while the spec is quite simple, this feature isn't implemented yet, nor is the ability for a PUREE disk to be bootable. My hope is that, despite PUREE currently lacking these features in version 1.0.0, anyone who has been discouraged by the learning curve and installation overhead of the alternatives will find use in PUREE, given its simplicity, clearly strong security properties, and user-friendly interface.
    - cortesoft 6y ago
      I would be more careful about calling something 'the first ever' if you haven't actually researched the other solutions.
      - notfed 6y ago
        Duly noted, title has been changed.
- staticassertion 6y ago
  > PBKDF2-SHA1 What's the problem?
  - notfed 6y ago
    See https://en.wikipedia.org/wiki/PBKDF2#Alternatives_to_PBKDF2 https://en.wikipedia.org/wiki/PBKDF2#Alternatives_to_PBKDF2
  - simcop2387 6y ago
    No memory hardness and no data dependence. Along with that SHA1 is really simple to implement on ASICs, FPGA, GPUs and such. This means that you can do lots of tests in parallel trivially (not much ram needed for each test, and no branching). You can use lots of PBKDF2 rounds to help against this but it will always mean that the cost of attacking it will scale much lower than something like scrypt or the argon2 family. In this application I don't believe there's any specific attacks against SHA1 or PBKDF2 but they don't provide the additional security that more modern things provide.
    - staticassertion 6y ago
      Fair enough. I use a ton of rounds, but yeah that's fair.
chc4 6y ago
You can also simply have LUKS with a detached header - I know some people that have their header and boot partitions exclusively on a USB, so that it's required to be in possession of the USB key to unlock and boot your computer.
- comboy 6y ago
  Be careful with that solution, you then have to have a separate backup strategy for that USB data.
  - OJFord 6y ago
    Only if the computer has important (and not backed up/replicated) state.
  - xwdv 6y ago
    Throw it in an S3 bucket. Done.
  - dkdk8283 6y ago
    Exactly, and that backup strategy is likely to be the weak link.
- notfed 6y ago
  I called this out in the PUREE paper: > To be fair, some tools do support support completely-random-looking disk layouts, but in most cases, they either: > 1. Are key-based (e.g., require a 128-bit or 256-bit key) rather than password based, in which case, the key must stored elsewhere. (Where do you store the key?) > 2. Ask the user to store a (non-random-looking) disk-encryption header elsewhere (i.e., “detached header mode”). (Where do you store the header?)
  - tempay 6y ago
    > 1. Are key-based (e.g., require a 128-bit or 256-bit key) rather than password based, in which case, the key must stored elsewhere. (Where do you store the key?) Is there a reason why this is notably different? Why can't the password be hashed to get the fixed length key?

by rendx 6y ago

notfed 6y ago

> DeLUKS Interesting, hadn't seen this project yet, or would have been more careful, thanks. A few thoughts: - The lack of a link to a white paper makes DeLUKS difficult to analyze, but it looks like they're hashing the password using PBKDF2-SHA1, which is quite outdated. (PUREE uses argon2id.) - The installation/usage seems slightly complex. I'd suggest people compare to the PUREE quick start instructions. > TrueCrypt/VeraCrypt As per your link: "When you create an encrypted volume using TrueCrypt or VeraCrypt it is stored as a file (container) on your hard drive.". And as per VeraCrypt's wikipedia page: "VeraCrypt supports plausible deniability[16] by allowing a single "hidden volume" to be created within another volume" I didn't read too much deeper, but the phrases "stored in a file" and "hidden volume within another volume" are red flags.

yjftsjthsd-h 6y ago
> the phrases "stored in a file" and "hidden volume within another volume" are red flags. Why? Files are lot easier than full partition encryption. And how else would you hide a volume with anything like plausible deniability?
- capdeck 6y ago
  If entire disk appears to be empty - it is much more plausible to have an argument that this is indeed just an empty spare. If you have a "hidden" file -- that file can be found to begin with -- _something_ in the file system will be pointing at it. And then - a large file filled with random data - that's one hell of a red flag if I ever saw one.
  - frei 6y ago
    It's not an actual file, it's unmarked in the free space of the first volume. If you mount only the first volume, it will appear normal, and data loss will occur if more space is used. https://www.truecrypt71a.com/documentation/plausible-deniability/hidden-volume/ https://www.truecrypt71a.com/documentation/plausible-deniabi... Also, as jchw mentioned above, the headers are indistinguishable from random data already, and truecrypt supports full volume encryption already. This nesting feature is on top of the "volume looks like random data" feature.
marcinzm 6y ago
TrueCrypt can also do full disk encryption however full disk encryption is LESS safe than a hidden file/volume. The reason is that the lack of a non-encrypted volume on a disk implies there is an encrypted volume. The existence of a dummy non-encrypted volume does not. Plausible deniability keeps you safer especially in cases where not providing a decryption key results in indefinite jail time.
- StavrosK 6y ago
  TrueCrypt can do full disk encryption with plausible deniability (a separate passphrase mounts a different encrypted section).
jchw 6y ago
TrueCrypt/VeraCrypt can do the same stuff but with physical drives, so yes, the claim of 'first' is inaccurate even with that technicality in mind. The reason why that's not the focus of TrueCrypt/VeraCrypt is because they also go significantly further. One problem with plausible deniability with this concept is that it's difficult and limiting to have to try to hide traces of access to an encrypted disk from a host OS that is stored on unencrypted media (and, obviously since it's the point of the whole project, even if it was encrypted, you could be compelled to decrypt it.) TrueCrypt/VeraCrypt FDE supports hiding an encrypted, bootable partition within the free space of another encrypted, bootable partition, in such a way that it is not generally possible to tell that there is a hidden partition, but you can boot into either depending on what password you enter. (Of course, the bootloader that allows you to enter the password is not encrypted, so for bootable partitions there is evidence that some encrypted partition exists, but this is unavoidable.)
- notfed 6y ago
  I fully admit to prior ignorance of VeraCrypt's abilities. From what I read on their website, I don't disagree with you. I will add that the PUREE specification does support subvolumes: different passwords may unlock different regions of the disk. Yet, while the spec is quite simple, this feature isn't implemented yet, nor is the ability for a PUREE disk to be bootable. My hope is that, despite PUREE currently lacking these features in version 1.0.0, anyone who has been discouraged by the learning curve and installation overhead of the alternatives will find use in PUREE, given its simplicity, clearly strong security properties, and user-friendly interface.
  - cortesoft 6y ago
    I would be more careful about calling something 'the first ever' if you haven't actually researched the other solutions.
    - notfed 6y ago
      Duly noted, title has been changed.
staticassertion 6y ago
> PBKDF2-SHA1 What's the problem?
- notfed 6y ago
  See https://en.wikipedia.org/wiki/PBKDF2#Alternatives_to_PBKDF2 https://en.wikipedia.org/wiki/PBKDF2#Alternatives_to_PBKDF2
- simcop2387 6y ago
  No memory hardness and no data dependence. Along with that SHA1 is really simple to implement on ASICs, FPGA, GPUs and such. This means that you can do lots of tests in parallel trivially (not much ram needed for each test, and no branching). You can use lots of PBKDF2 rounds to help against this but it will always mean that the cost of attacking it will scale much lower than something like scrypt or the argon2 family. In this application I don't believe there's any specific attacks against SHA1 or PBKDF2 but they don't provide the additional security that more modern things provide.
  - staticassertion 6y ago
    Fair enough. I use a ton of rounds, but yeah that's fair.

chc4 6y ago

You can also simply have LUKS with a detached header - I know some people that have their header and boot partitions exclusively on a USB, so that it's required to be in possession of the USB key to unlock and boot your computer.

comboy 6y ago
Be careful with that solution, you then have to have a separate backup strategy for that USB data.
- OJFord 6y ago
  Only if the computer has important (and not backed up/replicated) state.
- xwdv 6y ago
  Throw it in an S3 bucket. Done.
- dkdk8283 6y ago
  Exactly, and that backup strategy is likely to be the weak link.
notfed 6y ago
I called this out in the PUREE paper: > To be fair, some tools do support support completely-random-looking disk layouts, but in most cases, they either: > 1. Are key-based (e.g., require a 128-bit or 256-bit key) rather than password based, in which case, the key must stored elsewhere. (Where do you store the key?) > 2. Ask the user to store a (non-random-looking) disk-encryption header elsewhere (i.e., “detached header mode”). (Where do you store the header?)
- tempay 6y ago
  > 1. Are key-based (e.g., require a 128-bit or 256-bit key) rather than password based, in which case, the key must stored elsewhere. (Where do you store the key?) Is there a reason why this is notably different? Why can't the password be hashed to get the fixed length key?