
Show HN: Puree – Password-based Uniform-Random-Equivalent Encryption - notfed
http://puree.cc/
======
rendx
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-
veracry...](https://www.raedts.biz/forensics/detecting-truecrypt-veracrypt-
volumes/)

Looks like a nice enough project, but be careful with claims like "first".

~~~
notfed
> 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.

~~~
staticassertion
> PBKDF2-SHA1

What's the problem?

~~~
simcop2387
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
Fair enough. I use a ton of rounds, but yeah that's fair.

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

~~~
numpad0
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
Get _pikachu 'd_ ?

~~~
Etheryte
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
Ha! I know the meme but didn't make the connection. Thanks!

------
notfed
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
(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)

------
fortran77
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_...](https://en.wikipedia.org/wiki/Comparison_of_disk_encryption_software#Features)

------
13415
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
> 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
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.

~~~
fwip
Can any class of "data with ECC" be made indistinguishable from random data,
excepting obscurity?

~~~
dfox
It can: you can just apply encryption after the FEC/ECC. This is done for
example in GSM and I believe in many other radio systems. Of course there is
one huge caveat: it inherently means that you are doing MAC-then-Encrypt which
is generally disliked as error-prone.

~~~
fwip
Right, if you get a bitflip error in the encrypted data, decrypting it isn't
going to yield something that the error-correcting-codes work on, right? It'll
potentially ruin all your data, not just the single affected bit. I guess if
GSM is doing it it must be useful, I need to read up on that.

~~~
dfox
Stream cipher preserves bit-flips between ciphertext and plaintext, which is
useful property for this application.

And many “military/diplomatic” ciphersystems used in second half of 20th
century have various interesting properties wrt. error correction or non-
propagation. My suspicion is that these properties are built by doing MAC-
then-FEC-then-Encrypt and in some cases even by relying on limited error
propagation of CBC mode. If you think about it, for these applications
reliability is more interesting than strict authentication as the ciphertext
of diplomatic “cable” or similar thing is sent through somewhat noisy channels
and often was manually handled by fallible human radio operators while active
MitM was not exactly feasible attack.

~~~
fwip
Thank you for all this explanation, I appreciate it. :)

------
GekkePrutser
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
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
That sounds interesting, how do you do that?

~~~
steelframe
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.

~~~
dpc_pw
probably the best joke in HN today :)

------
bawolff
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.

------
modeless
> 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
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
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-h...](https://www.howtogeek.com/115573/htg-explains-why-you-only-have-to-
wipe-a-disk-once-to-erase-it/)

[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-
sanitizat...](https://www.nist.gov/publications/guidelines-media-
sanitization-0)

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)

------
phkamp
"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
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.

~~~
phkamp
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.

------
akkishore
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
Each header is individually encrypted with a different salt/nonce, so there
won't be any detectable repetition.

------
noodlesUK
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

------
ComodoHacker
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?

------
est
I am wondering if this could be applied to network streams as well.

How could we make protocol handshake invisible? AEAD?

------
linuxhansl
Apologies if I missed something...

You can do this with

    
    
      cryptsetup open ... --type plain

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

------
melicerte
Puree , in french , means smashed potatoes. Just saying

