8 ms·

Show HN: Puree – Password-based Uniform-Random-Equivalent Encryption

190 points by notfed 6y ago

notfed 6y ago
PUREE stands for "Password-based Uniform-Random-Equivalent Encryption". PUREE lets you perform password-based full-disk encryption securely, and in a way that ensures the disk is 100% indistinguishable from random. And as far as I know, this is the first tool to do so. It also comes with a very simple-to-use command-line tool for encrypting disks. (Currently only supported by Linux.) After putting much love into this project, I've finally released version 1.0.0. All PUREE designs and software are hereby released as public domain. All feedback greatly appreciated.
- dang 6y ago
  (originally posted to https://news.ycombinator.com/item?id=23436038 https://news.ycombinator.com/item?id=23436038 but was lonely there so we moved it hither)
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).
- 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?
p4bl0 6y ago
I like that the quick start guide uses /dev/sdz in the examples, so that copy-pasting will generally not work and you don't risk wiping a disk that actually exists.
- numpad0 6y ago
  I’ve seen some mad man on Twitter talking this fun fact that 27th disk on Linux becomes /dev/sdaa and Debian Installer gets pikachu’d at grub-installer step just by having it So there are exceptions and you said “will generally not work”, damn you nailed it
  - p4bl0 6y ago
    Get pikachu'd ?
    - K2L8M11N2 6y ago
      https://knowyourmeme.com/memes/surprised-pikachu https://knowyourmeme.com/memes/surprised-pikachu
    - Etheryte 6y ago
      The "surprised Pikachu" [1] meme is essentially the progression of some initial scenario, followed by the most reasonable and likely outcome, followed by a surprised Pikachu face. It's commonly used to for example sarcastically highlight that something that was overlooked should be common sense. [1] https://knowyourmeme.com/memes/surprised-pikachu https://knowyourmeme.com/memes/surprised-pikachu
      - p4bl0 6y ago
        Ha! I know the meme but didn't make the connection. Thanks!
13415 6y ago
I really like this, especially the part that allows subvolumes and multiple password slots. One thing I didn't really understand or maybe simply missed in the paper is how data integrity is handled. Okay, so the header can be duplicated. What about bit-flips in individual blocks? How large are the blocks, does this affect other blocks, and how can intact blocks be recovered? How does this work in block devices like this? What errors will occur in Linux when a block is bad? Is that a file system issue on top of it, so e.g. if I format it with Ext4 I can use fsck to "fix" errors?
- notfed 6y ago
  > especially the part that allows subvolumes and multiple password slots Admittedly backup headers are not yet implemented. (I had to release an MVP at some point.) > how [is] data integrity is handled? (Beware though that this is still MVP, and the code doesn't actually write a backup header yet. If enough people are enthusiastic about PUREE, I promise to do so.) Every part of the header is encrypted+authenticated. If any part of the header has a bit-flip, the message-authentication code will fail to decrypt the header. PUREE can't tell whether this happened or you're just providing the wrong password. If corruption does occur, you'd need to hint to PUREE to read a backup header---by default, one will be at the final 1MiB of the device. (But again I stress, not implemented yet.) > How large are the blocks, does this affect other blocks, and how can intact blocks be recovered? PUREE just handles the header. After that, it hands control to the next stage, which according to the spec, can really be anything. The implementation, as it is now, only has four possible encryption modes, and each just hands things off to Linux dm-crypt subsystem. You'd have to read about that in dm-crypt.
  - WhatIsDukkha 6y ago
    This touches on one of the great problems of encrypted disks. Anything on the volume is almost by definition important. But a single bit flip and it can be complete garbage. It would be lovely if someone, far more clever then me, layered fountain codes https://en.wikipedia.org/wiki/Fountain_code https://en.wikipedia.org/wiki/Fountain_code at a tasteful spot.
GekkePrutser 6y ago
Interesting, but only useful in a specific situation (decryption coercion). And probably not that effective in such situations. Obligatory XKCD: https://xkcd.com/538/ https://xkcd.com/538/ Obviously it ignores habeas corpus but of course, so have most governments, even the more 'evolved' ones. For most situations, denial of encryption is not necessary. I can see the point for data drives. But in a laptop/PC scenario, there must be a way to actually boot the thing. If there's a way to boot it, it can be detected by trying to boot it ;) There must be something machine-readable that asks for the password. You can store that part on a separate USB but even the possession of that is an indication that you use encryption. And to mention the obvious: Who carries around drives with random data on them? Storage devices that are unformatted are normally filled with zeroes. Sure, it could have been wiped with random data, but it is still a very suspicious situation. It's a nice project for this niche usecase but for encrypting my boot drives I'm perfectly happy with LUKS as it is. In most cases denying the existence of encryption is not needed.
- OJFord 6y ago
  My paper on a scheme that makes the drive, including header, indistinguishable from one that's been zeroed out should be ready by April.
  - cyberbanjo 6y ago
    That sounds interesting, how do you do that?
    - m3kw9 6y ago
      It was a joke
    - steelframe 6y ago
      Per-volume zero-based one-time pad (PVZBOTP). It's a common technique used by almost all Fortune 500 organizations these days. The tl;dr is that you generate an encrypted volume that, when XOR'd with a volume consisting entirely of zeroes, produces the original plaintext volume.
akkishore 6y ago
From the white paper: "If additional shadow headers are used, their suggested locations are (where possible) at the sectors starting at offsets 128MiB, 128GiB, and 128TiB" Is such repetition of header (in a supposedly random-wiped disk) not suggestive of existence of a PUREE partition? This can be figured by scanning the entire disk.
- notfed 6y ago
  Each header is individually encrypted with a different salt/nonce, so there won't be any detectable repetition.
fortran77 6y ago
PGP Disk also had "deniable encryption". So this is certainly not "first" https://en.wikipedia.org/wiki/Deniable_encryption https://en.wikipedia.org/wiki/Deniable_encryption Also see the Wikipedia chart for "Hidden Containers" https://en.wikipedia.org/wiki/Comparison_of_disk_encryption_software#Features https://en.wikipedia.org/wiki/Comparison_of_disk_encryption_...
phkamp 6y ago
"Denial of encryption" is no different from "Denial of having password", and leads you straight into XKCD 538. If the adversary does not belive you, their best bet is to keep torturing you, until they get their way. What you want is "Proof of inability to decrypt" so that the adversary has nothing to gain by waterboarding you. See also: https://papers.freebsd.org/2004/phk-gbde/ https://papers.freebsd.org/2004/phk-gbde/
- adrianmonk 6y ago
  I think there are some situations where there might be a difference: ones where the adversary does not know for sure whether the data exists. For example, suppose you work in the IT department of a law firm, something fishy is going on and you want to be a whistle blower, and you need a way to exfiltrate some evidence. You are getting rid of some obsolete laptops, and standard procedure is to wipe the drives before selling them. Management has its suspicions about you because you've been asking too many questions. So they get another IT person to check the drives you were supposed to wipe. If the drives have the data on them with a LUKS header, you've been caught (or at least they think you were too lazy to wipe the drives). If it's indistinguishable from random data, then you've given them no reason to suspect you.
  - marcinzm 6y ago
    Sure in that scenario but I feel that's an edge case scenario. More commonly a machine you use is acquired by an adversary. Thus the machine is expected to have a working installed OS on it. If that laptop lacks an un-encrypted partition then the adversary will assume it is encrypted. They don't need to mathematically prove it.
  - na85 6y ago
    If I suspected an employee was up to something and they wanted to dispose of old laptops, I would send another employee to physically destroy the drives with a drill or a saw.
  - phkamp 6y ago
    This scenario suffers from what I call "IT-Dude-Syndrome". IT-Dude-Syndrome is when IT-people come up with scenarios which hinge on "IT-Dude" being smarter than everybody else in the whole world. First, if you're suspected of anything in a law firm, you're out until the issue is resolved, you don't get to "destroy old laptops" or anything of that sort. In a high-security operation you don't even get to touch a laptop, and you will be handed a loaner-phone, while your own phone is turned off, signed, sealed and stored in a safe until the matter is resolved. Second, if "standard procedure" in that law firm is to "wipe the drives before selling them", that law firm is not following best, or even minimum, security practices for the business they are in, and that is what the whistle-blower should report to the relevant authority. Third and most significant, IT-dude is smarter than the obviously junior IT-dude called in to "check the drives" IT-dude "were supposed to wipe" ? You know what, he's not. In such scenario you can be damn sure, that whoever is called in to check is several levels smarter than IT-dude. And you know what super-IT-Dude will do when she see the disks full of high entropy data ? She will point to the final step in the official procedure for wiping disks, which is to write all zeros to the entire media to prove that there is nothing hidden. She will write in the report that IT-dude did not follow a trivial procedure to the letter, and point out that the most likely, in fact the only credible, explanation for skipping a trivial step in the procedure, was that IT dude were trying to exfiltrate data.
deleted 6y ago
[deleted]
modeless 6y ago
> Since it has long been common practice to wipe disks by overwriting with random data Is it really that common of a practice to leave your entire disk full of random data? I would expect that it's more common for disks to be full of zeros, or non-encrypted leftovers, than random data.
- ciarannolan 6y ago
  It's pretty uncommon for technically inclined folks to just abandon a disk with unencrypted data. And from what I remember reading long ago, several writes of random data is more secure than several (or one) writes of zeros.
  - e12e 6y ago
    Depends on the disk (magnetic hard drive, density, type of storage (eg smr), flash/SSD etc). AFAIK for a recent (say, 2010 and later) drive - there's little to indicate random/"smart" patterns are better than just a single pass off all zeroes. Even if you consider an adversary with the capability to analyze drive with magnetic force microscopy. https://www.howtogeek.com/115573/htg-explains-why-you-only-have-to-wipe-a-disk-once-to-erase-it/ https://www.howtogeek.com/115573/htg-explains-why-you-only-h... https://www.sans.org/blog/overwriting-hard-drive-data/ https://www.sans.org/blog/overwriting-hard-drive-data/ "Data Reconstruction from a Hard Disk Drive using Magnetic Force Microscopy", 2013 Author(s): Kanekal, Vasu https://escholarship.org/uc/item/26g4p84b https://escholarship.org/uc/item/26g4p84b A quick skims seems to indicate the NSA recommends degaussuing and destruction: https://www.nsa.gov/resources/everyone/media-destruction/ https://www.nsa.gov/resources/everyone/media-destruction/ Nist 800-80: https://www.nist.gov/publications/guidelines-media-sanitization-0 https://www.nist.gov/publications/guidelines-media-sanitizat... Refers to: https://cmrr.ucsd.edu/resources/secure-erase.html https://cmrr.ucsd.edu/resources/secure-erase.html Who's readme: https://cmrr.ucsd.edu/_files/hdd-erase-readme.txt https://cmrr.ucsd.edu/_files/hdd-erase-readme.txt And q'n'a indicate that single pass sata secure erase is generally considered sufficient - it typically does a single pass, but should also write over all bad blocks etc. See also: https://ata.wiki.kernel.org/index.php/ATA_Secure_Erase https://ata.wiki.kernel.org/index.php/ATA_Secure_Erase
  - 6y ago
noodlesUK 6y ago
As much as this is a cool project, I feel like a significant use case for disk encryption is for boot disks on PCs. It’s gonna be pretty obvious that a machine is encrypted if it has a boot loader and early stage OS that prompts for a password. Plausible deniability of spare drives though, this is very cool
est 6y ago
I am wondering if this could be applied to network streams as well. How could we make protocol handshake invisible? AEAD?
bawolff 6y ago
From the article: > Clearly, it is trivial to detect that a disk is encrypted with LUKS. In fact, this isn't just a problem with LUKS; but also with most password-based disk encryption solutions. This isn't surprising: it turns out to be a difficult problem to solve. Is it though? The reason people add metadata headers is because they provide features, such as allowing different parameters without the user having to know them, allowing autodetection that encryption is in use when you plug in a portable drive, etc. Puree trades-off these features for instead having deniable encryption. However for most users, deniable encryption is pretty useless, and those other features are very useful. Hence why most disk encryption solutions go with non-deniability.
linuxhansl 6y ago
Apologies if I missed something... You can do this with cryptsetup open ... --type plain
- notfed 6y ago
  This will simply hash your password a single time. LUKS and PUREE use password-key derivation.
ComodoHacker 6y ago
In the white paper I can't find a comparison with or even mention of TrueCrypt disk/container format, which also offers plausible deniability. Does PUREE improves over it on something, or just cleanly redesigns and reimplements to be surely free of potential backdoors?
melicerte 6y ago
Puree , in french , means smashed potatoes. Just saying

190 points by notfed 6y ago

PUREE stands for "Password-based Uniform-Random-Equivalent Encryption". PUREE lets you perform password-based full-disk encryption securely, and in a way that ensures the disk is 100% indistinguishable from random. And as far as I know, this is the first tool to do so. It also comes with a very simple-to-use command-line tool for encrypting disks. (Currently only supported by Linux.) After putting much love into this project, I've finally released version 1.0.0. All PUREE designs and software are hereby released as public domain. All feedback greatly appreciated.

dang 6y ago
(originally posted to https://news.ycombinator.com/item?id=23436038 https://news.ycombinator.com/item?id=23436038 but was lonely there so we moved it hither)

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).
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?

p4bl0 6y ago

I like that the quick start guide uses /dev/sdz in the examples, so that copy-pasting will generally not work and you don't risk wiping a disk that actually exists.

numpad0 6y ago
I’ve seen some mad man on Twitter talking this fun fact that 27th disk on Linux becomes /dev/sdaa and Debian Installer gets pikachu’d at grub-installer step just by having it So there are exceptions and you said “will generally not work”, damn you nailed it
- p4bl0 6y ago
  Get pikachu'd ?
  - K2L8M11N2 6y ago
    https://knowyourmeme.com/memes/surprised-pikachu https://knowyourmeme.com/memes/surprised-pikachu
  - Etheryte 6y ago
    The "surprised Pikachu" [1] meme is essentially the progression of some initial scenario, followed by the most reasonable and likely outcome, followed by a surprised Pikachu face. It's commonly used to for example sarcastically highlight that something that was overlooked should be common sense. [1] https://knowyourmeme.com/memes/surprised-pikachu https://knowyourmeme.com/memes/surprised-pikachu
    - p4bl0 6y ago
      Ha! I know the meme but didn't make the connection. Thanks!

13415 6y ago

I really like this, especially the part that allows subvolumes and multiple password slots. One thing I didn't really understand or maybe simply missed in the paper is how data integrity is handled. Okay, so the header can be duplicated. What about bit-flips in individual blocks? How large are the blocks, does this affect other blocks, and how can intact blocks be recovered? How does this work in block devices like this? What errors will occur in Linux when a block is bad? Is that a file system issue on top of it, so e.g. if I format it with Ext4 I can use fsck to "fix" errors?

notfed 6y ago
> especially the part that allows subvolumes and multiple password slots Admittedly backup headers are not yet implemented. (I had to release an MVP at some point.) > how [is] data integrity is handled? (Beware though that this is still MVP, and the code doesn't actually write a backup header yet. If enough people are enthusiastic about PUREE, I promise to do so.) Every part of the header is encrypted+authenticated. If any part of the header has a bit-flip, the message-authentication code will fail to decrypt the header. PUREE can't tell whether this happened or you're just providing the wrong password. If corruption does occur, you'd need to hint to PUREE to read a backup header---by default, one will be at the final 1MiB of the device. (But again I stress, not implemented yet.) > How large are the blocks, does this affect other blocks, and how can intact blocks be recovered? PUREE just handles the header. After that, it hands control to the next stage, which according to the spec, can really be anything. The implementation, as it is now, only has four possible encryption modes, and each just hands things off to Linux dm-crypt subsystem. You'd have to read about that in dm-crypt.
- WhatIsDukkha 6y ago
  This touches on one of the great problems of encrypted disks. Anything on the volume is almost by definition important. But a single bit flip and it can be complete garbage. It would be lovely if someone, far more clever then me, layered fountain codes https://en.wikipedia.org/wiki/Fountain_code https://en.wikipedia.org/wiki/Fountain_code at a tasteful spot.

GekkePrutser 6y ago

Interesting, but only useful in a specific situation (decryption coercion). And probably not that effective in such situations. Obligatory XKCD: https://xkcd.com/538/ https://xkcd.com/538/ Obviously it ignores habeas corpus but of course, so have most governments, even the more 'evolved' ones. For most situations, denial of encryption is not necessary. I can see the point for data drives. But in a laptop/PC scenario, there must be a way to actually boot the thing. If there's a way to boot it, it can be detected by trying to boot it ;) There must be something machine-readable that asks for the password. You can store that part on a separate USB but even the possession of that is an indication that you use encryption. And to mention the obvious: Who carries around drives with random data on them? Storage devices that are unformatted are normally filled with zeroes. Sure, it could have been wiped with random data, but it is still a very suspicious situation. It's a nice project for this niche usecase but for encrypting my boot drives I'm perfectly happy with LUKS as it is. In most cases denying the existence of encryption is not needed.

OJFord 6y ago
My paper on a scheme that makes the drive, including header, indistinguishable from one that's been zeroed out should be ready by April.
- cyberbanjo 6y ago
  That sounds interesting, how do you do that?
  - m3kw9 6y ago
    It was a joke
  - steelframe 6y ago
    Per-volume zero-based one-time pad (PVZBOTP). It's a common technique used by almost all Fortune 500 organizations these days. The tl;dr is that you generate an encrypted volume that, when XOR'd with a volume consisting entirely of zeroes, produces the original plaintext volume.

akkishore 6y ago

From the white paper: "If additional shadow headers are used, their suggested locations are (where possible) at the sectors starting at offsets 128MiB, 128GiB, and 128TiB" Is such repetition of header (in a supposedly random-wiped disk) not suggestive of existence of a PUREE partition? This can be figured by scanning the entire disk.

notfed 6y ago
Each header is individually encrypted with a different salt/nonce, so there won't be any detectable repetition.

fortran77 6y ago

PGP Disk also had "deniable encryption". So this is certainly not "first" https://en.wikipedia.org/wiki/Deniable_encryption https://en.wikipedia.org/wiki/Deniable_encryption Also see the Wikipedia chart for "Hidden Containers" https://en.wikipedia.org/wiki/Comparison_of_disk_encryption_software#Features https://en.wikipedia.org/wiki/Comparison_of_disk_encryption_...

phkamp 6y ago

"Denial of encryption" is no different from "Denial of having password", and leads you straight into XKCD 538. If the adversary does not belive you, their best bet is to keep torturing you, until they get their way. What you want is "Proof of inability to decrypt" so that the adversary has nothing to gain by waterboarding you. See also: https://papers.freebsd.org/2004/phk-gbde/ https://papers.freebsd.org/2004/phk-gbde/

adrianmonk 6y ago
I think there are some situations where there might be a difference: ones where the adversary does not know for sure whether the data exists. For example, suppose you work in the IT department of a law firm, something fishy is going on and you want to be a whistle blower, and you need a way to exfiltrate some evidence. You are getting rid of some obsolete laptops, and standard procedure is to wipe the drives before selling them. Management has its suspicions about you because you've been asking too many questions. So they get another IT person to check the drives you were supposed to wipe. If the drives have the data on them with a LUKS header, you've been caught (or at least they think you were too lazy to wipe the drives). If it's indistinguishable from random data, then you've given them no reason to suspect you.
- marcinzm 6y ago
  Sure in that scenario but I feel that's an edge case scenario. More commonly a machine you use is acquired by an adversary. Thus the machine is expected to have a working installed OS on it. If that laptop lacks an un-encrypted partition then the adversary will assume it is encrypted. They don't need to mathematically prove it.
- na85 6y ago
  If I suspected an employee was up to something and they wanted to dispose of old laptops, I would send another employee to physically destroy the drives with a drill or a saw.
- phkamp 6y ago
  This scenario suffers from what I call "IT-Dude-Syndrome". IT-Dude-Syndrome is when IT-people come up with scenarios which hinge on "IT-Dude" being smarter than everybody else in the whole world. First, if you're suspected of anything in a law firm, you're out until the issue is resolved, you don't get to "destroy old laptops" or anything of that sort. In a high-security operation you don't even get to touch a laptop, and you will be handed a loaner-phone, while your own phone is turned off, signed, sealed and stored in a safe until the matter is resolved. Second, if "standard procedure" in that law firm is to "wipe the drives before selling them", that law firm is not following best, or even minimum, security practices for the business they are in, and that is what the whistle-blower should report to the relevant authority. Third and most significant, IT-dude is smarter than the obviously junior IT-dude called in to "check the drives" IT-dude "were supposed to wipe" ? You know what, he's not. In such scenario you can be damn sure, that whoever is called in to check is several levels smarter than IT-dude. And you know what super-IT-Dude will do when she see the disks full of high entropy data ? She will point to the final step in the official procedure for wiping disks, which is to write all zeros to the entire media to prove that there is nothing hidden. She will write in the report that IT-dude did not follow a trivial procedure to the letter, and point out that the most likely, in fact the only credible, explanation for skipping a trivial step in the procedure, was that IT dude were trying to exfiltrate data.

deleted 6y ago

[deleted]

modeless 6y ago

> Since it has long been common practice to wipe disks by overwriting with random data Is it really that common of a practice to leave your entire disk full of random data? I would expect that it's more common for disks to be full of zeros, or non-encrypted leftovers, than random data.

ciarannolan 6y ago
It's pretty uncommon for technically inclined folks to just abandon a disk with unencrypted data. And from what I remember reading long ago, several writes of random data is more secure than several (or one) writes of zeros.
- e12e 6y ago
  Depends on the disk (magnetic hard drive, density, type of storage (eg smr), flash/SSD etc). AFAIK for a recent (say, 2010 and later) drive - there's little to indicate random/"smart" patterns are better than just a single pass off all zeroes. Even if you consider an adversary with the capability to analyze drive with magnetic force microscopy. https://www.howtogeek.com/115573/htg-explains-why-you-only-have-to-wipe-a-disk-once-to-erase-it/ https://www.howtogeek.com/115573/htg-explains-why-you-only-h... https://www.sans.org/blog/overwriting-hard-drive-data/ https://www.sans.org/blog/overwriting-hard-drive-data/ "Data Reconstruction from a Hard Disk Drive using Magnetic Force Microscopy", 2013 Author(s): Kanekal, Vasu https://escholarship.org/uc/item/26g4p84b https://escholarship.org/uc/item/26g4p84b A quick skims seems to indicate the NSA recommends degaussuing and destruction: https://www.nsa.gov/resources/everyone/media-destruction/ https://www.nsa.gov/resources/everyone/media-destruction/ Nist 800-80: https://www.nist.gov/publications/guidelines-media-sanitization-0 https://www.nist.gov/publications/guidelines-media-sanitizat... Refers to: https://cmrr.ucsd.edu/resources/secure-erase.html https://cmrr.ucsd.edu/resources/secure-erase.html Who's readme: https://cmrr.ucsd.edu/_files/hdd-erase-readme.txt https://cmrr.ucsd.edu/_files/hdd-erase-readme.txt And q'n'a indicate that single pass sata secure erase is generally considered sufficient - it typically does a single pass, but should also write over all bad blocks etc. See also: https://ata.wiki.kernel.org/index.php/ATA_Secure_Erase https://ata.wiki.kernel.org/index.php/ATA_Secure_Erase
- 6y ago

noodlesUK 6y ago

As much as this is a cool project, I feel like a significant use case for disk encryption is for boot disks on PCs. It’s gonna be pretty obvious that a machine is encrypted if it has a boot loader and early stage OS that prompts for a password. Plausible deniability of spare drives though, this is very cool

est 6y ago

I am wondering if this could be applied to network streams as well. How could we make protocol handshake invisible? AEAD?

bawolff 6y ago

From the article: > Clearly, it is trivial to detect that a disk is encrypted with LUKS. In fact, this isn't just a problem with LUKS; but also with most password-based disk encryption solutions. This isn't surprising: it turns out to be a difficult problem to solve. Is it though? The reason people add metadata headers is because they provide features, such as allowing different parameters without the user having to know them, allowing autodetection that encryption is in use when you plug in a portable drive, etc. Puree trades-off these features for instead having deniable encryption. However for most users, deniable encryption is pretty useless, and those other features are very useful. Hence why most disk encryption solutions go with non-deniability.

linuxhansl 6y ago

Apologies if I missed something... You can do this with cryptsetup open ... --type plain

notfed 6y ago
This will simply hash your password a single time. LUKS and PUREE use password-key derivation.

ComodoHacker 6y ago

In the white paper I can't find a comparison with or even mention of TrueCrypt disk/container format, which also offers plausible deniability. Does PUREE improves over it on something, or just cleanly redesigns and reimplements to be surely free of potential backdoors?

melicerte 6y ago

Puree , in french , means smashed potatoes. Just saying