Gocryptfs: Reverse-engineering the password is IN the encrypted directory.

[madbolter]

I haven't bothered installing and trying gocryptfs because every walkthrough shows the same problem, and it's a deal-breaker for anybody wanting to sync the encrypted directory to cloud-storage (such as BackBlaze). I quote from just one walkthrough, this one is HowToGeek from just days ago:

"The “gocryptfs.diriv” is a short binary file, while “gocryptfs.conf” contains settings and information you should keep safe.

"If you upload your encrypted data to the cloud or back it up to small, transportable media, don’t include this file. If, however, you back up to local media that remains under your control, you can include this file.

"With sufficient time and effort, it might be possible to extract your password from the “encrypted key” and “salt” entries, as shown below:"

And then the walkthrough proceeds to explain how to do that very thing!

Can you confirm or deny that those critical files are always placed in the encrypted directory itself? In what follows, I'm going to assume that every walkthrough is correct and that these files are always placed in the encrypted directory.

So, the question is very simple: Why aren't those critical files stored someplace like /etc/gocryptfs?!?

As the situation stands now, the encrypted directory cannot just be synced in-toto with a cloud-storage location, because the directory contains the very files that enable decrypting the encrypted files! And many of these easy cloud-sync services do not allow "excluding" things, or if they do, it's much more complicated and unreliable to do so. What we want is to just sync the entire directory to a service like BackBlaze.

Bottom line is that including the very files that allow "reverse-engineering" the files in the encrypted directory itself makes it a non-starter to use gocryptfs for whole directories, unless you want to jump through hoops and hope that whatever you do to exclude them doesn't inadvertently, even once, happen to include them! Because there's no good reason to put these files anywhere but a location like /etc/gocryptfs, those files need to be placed in a genuinely secure directory on the host system rather than in the encrypted directory itself.

[madbolter]

True dat.

But, that's not really answering the question of the issue.

Why included the encrypted password and the salt in the same directory as
what is being encrypted by it? There's no upside, and it is most certainly
NOT "practically impossible" with those two data points to reverse engineer
what the password is. Difficult, yes. And password length/complexity is not
the issue, as you imply. Obviously longer and more complex passwords are
better, which we do use.

But let's say that I'm fanatical about security. Let's say that I store
FERPA-protected data. Let's say that I don't think it's a good idea to hand
anybody both parts of a salted password. The question remains:

WHY would you ever WANT to have that information as part of the encrypted
directory when it's trivial to put it into a different directory, like
/etc/gocryptfs?
Can you tell me a single downside to that other than
programmatic convenience (which isn't a very moving argument)?

On Wed, Sep 2, 2020 at 5:38 PM Leif-E. K. [e-mail] wrote:

With sufficient time you'll be also able to decrypt AES, theoretically.
Practically: Impossible.
The whole strength of any crypto depends on the weakest link in the whole
chain. If your password is the weakest link you have to worry, but with
that not the best encryption can help you.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/rfjakob/gocryptfs/issues/500#issuecomment-686107524,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AGUUMQZX2PB45X4BWWF3LSTSD3JQ5ANCNFSM4QT6EJBQ
.

--
Richard Jensen, Ph.D.
President, Conclusive Systems LLC
www.conclusivesystems.com
[email protected]
866-234-8164 (office)
303-525-7101 (mobile)

[LicoMonch]

o0

Where is the issue here?

I can't see anything other than moaning and trolling.

You read an walkthrough .. wow, good boy .. now that you have questions, go to the man page. Think about possible best practices and try that thing called "internet" to search for them.

After that -> strengthen your brain cells by thinking about how to make your backup secure. Should be easy now.
If not, maybe "World-Class Academic Solutions" should be reworded into "unsure how to solve problems, because we deny thinking about it".

[madbolter]

Ah, I see that you devolve to insults instead of answering a reasonable
question.

We're done, and I'll be sure to tell everybody I work with professionally
about what this experience was like.

All you had to say was, "We think that this is plenty secure, and we don't
think it's enough of a concern to change where the files reside." But,
dumping straight into a spew of sarcasm and insults shows all a serious
person needs to know about the devs here.

Later.

On Thu, Sep 3, 2020 at 1:43 AM LicoMonch [e-mail] wrote:

o0

Where is the issue here?

I can't see anything other than moaning and trolling.

You read an walkthrough .. wow, good boy .. now that you have questions,
go to the man page. Think about possible best practices and try that thing
called "internet" to search for them.

After that -> strengthen your brain cells by thinking about how to make
your backup secure. Should be easy now.
If not, maybe "World-Class Academic Solutions" should be reworded into
"unsure how to solve problems, because we deny thinking about it".

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/rfjakob/gocryptfs/issues/500#issuecomment-686316368,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AGUUMQ5K6P5BBOX2BREDUPTSD5CKPANCNFSM4QT6EJBQ
.

--
Richard Jensen, Ph.D.
President, Conclusive Systems LLC
www.conclusivesystems.com
[email protected]
866-234-8164 (office)
303-525-7101 (mobile)

[LicoMonch]

Sorry, that was indeed a bit harsh .. but really, did you read what you wrote?

To freely quote you: "We don't want to save the conf in the encrypted directory!"

RTFM ->

   -config string
       Use specified config file instead of CIPHERDIR/gocryptfs.conf.

So mount gocryptfs with -config /etc/gocryptfs/my-only-offline-safed-gocryptfs.conf
Please tell me, that this isn't to hard for you ..

[madbolter]

Not "a bit harsh." A bit more than just a bit.

So, why didn't you just initially respond by explaining that the file
location is easily changed? Then I would have been impressed both that the
devs thought that one through and by how graciously you responded.

Your actual response apparently presumes that somebody in the initial stage
of checking out alternatives to cryfs is going to (and I quote) "RTFM"
(perhaps "a bit harsh" as well, no?).

Instead, I checked out how people are using your alternative and looked
through some walkthroughs. We are an Ubuntu shop, and the first thing we
always do is see how hard it's likely to be to get something working under
Ubuntu. So, I almost never "RTFM" until I've first seen a bit of an
overview of how people are using something and what it's going to be like
in Ubuntu. Once I have a sense of whether or not there are glaring problems
of some sort, I might proceed with more effort. That is why I didn't start
by reading "TFM."

And every walkthrough of the few I looked at makes some issue about the
location of the config files. So, I guess that none of them read "TFM"
either. So, given that this issue comes up repeatedly, you could perhaps
make it prominent in your description that "The default location of the
config files being in the encrypted directory has been raised as a possible
concern, but we actually have a simple setting to put the config files
wherever you wish...."

For people like me (and for, apparently, others that share the concern),
that concern can indeed make such a package into a non-starter. And "Well,
AES can be cracked" is not an argument in favor of having no way to put the
config files elsewhere.

Given all of the above, perhaps the file location issue is not as clear as
you think, and perhaps it's a reasonable concern after all. It's certainly
one that you could have responded to in seconds by just saying, "If that's
a concern for you, there's a setting to address it. Here it is." Or, if you
didn't want to exert even a shred of effort, you could have even emailed a
one-liner: "In the manual, you can find the setting to change the config
file location." Simple. Done.

Had you simply responded decently from the start. I would have then just
removed my "issue" or even "resolved it" with a comment something like I've
said in other contexts: "Ah, silly me...."

I don't mind owning an oversight or reasonable but false presumptions. In
the resolution of the issue, I would probably have quoted the manual line
you cited. And then, anybody else concerned as I was would be able to see
the issue and its "resolution" if they searched through the issues (as I
did). The whole thing could have been resolved so quickly, easily, and
decently.

But no. You berate me for even being concerned in the first place,
literally going straight to questioning the basic competency of not just me
but our company. Yet, clearly, some programmer associated with your project
recognized that it could be a concern and already addressed that concern!
So, if it's a concern worth addressing in code, then why berate somebody
for seeing it as a concern?

If your responses emerged from my failure to "RTFM," then why head down the
tangent of claiming that it shouldn't even be a concern? Just cite your
"FM" and be done with it.

No part of this exchange with you makes any sense to me, but, fortunately,
I don't need to make sense of it. You've answered my initial concern;
you've just done so in a way that raises so many other, and deeper, ones
that I have no interest in proceeding any further.

So, sometime later today I'll delete that issue, and then I'll just be done
with you and the package. We part ways.

On Thu, Sep 3, 2020 at 2:09 AM LicoMonch [e-mail] wrote:

Sorry, that was indeed a bit harsh .. but really, did you read what you
wrote?

To freely quote you: "We don't want to save the conf in the encrypted
directory!"

RTFM ->

-config string
Use specified config file instead of CIPHERDIR/gocryptfs.conf.

So mount gocryptfs with -config
/etc/gocryptfs/my-only-offline-safed-gocryptfs.conf
Please tell me, that this isn't to hard for you ..

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/rfjakob/gocryptfs/issues/500#issuecomment-686328985,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AGUUMQ2EVPGL3RWYXQFBX6TSD5FLXANCNFSM4QT6EJBQ
.

--
Richard Jensen, Ph.D.
President, Conclusive Systems LLC
www.conclusivesystems.com
[email protected]
866-234-8164 (office)
303-525-7101 (mobile)

[LicoMonch]

1. This here is an issue tracker for development, not a discussion forum.
2. All your question were already answered by your very 1st post itself.
3. You did not read all the docs!
4. Instead of thinking about your problem for yourself, you blame the code/the dev for things, you don't like.

Sorry, but I did not read your reply at a whole .. the few sentences I read, already showed me, that I should have followed my first thought about that issue: Don' feed the troll!

[Nodens-]

@madbolter
First of all LicoMonch is not a developer or a contributor to gocryptfs so he can't include anything in documentation. They're a github user, like I am too. You must obviously be new on github but repository owners and contributors are clearly marked as such, on their posts, at the same bar with the name and commented time, on the right side. You can also mouseover a username to see any pertaining info. It is also REALLY poor form to threaten to badmouth a project because you got a rude reply from a github user on the issue tracker.

Secondly, your use case is not the default use case and it makes sense to include that file per encrypted dir. Why? Because:
a) It simplifies management of multiple encrypted dir mountpoints.
b) It's NOT really insecure. The article/guide you mentioned does NOT actually tell you how to decrypt from that file. It tells you that it's THEORETICALLY possible, given enough time (all forms of encryption are theoretically possible to decrypt "given enough time"--but if that time is 10bil years with current processing power it's virtually impossible), to brute force or dictionary attack it, and the author just displays what's inside in a sample file. This means if your passwords have any semblance of following security standards it's virtually impossible. If your password is "password" it can be attacked easily anyhow.

Thirdly, the option to store the file wherever you want is actually present and is documented. If you want to do something that doesn't fit the default use case you must always consult the documentation to see if your use case is feasible with a certain piece of software.

Lastly, a friendly advice. While looking at "guides" to see how a piece of software is used on a certain platform, is fine, it's also a VERY good idea NOT to jump to conclusions without reading the documentation EXTENSIVELY, yourself. As you see, very clearly, in this case, the guide's author has really NO idea what they're talking about and they clearly have not read the documentation either. Guides such as these make for very poor source of information that almost always contradicts the reality of things. Most of them are copy/pasted, plagiarized, from site to site too. It's fine for a complete newbie to get their bearings on how to set something up but in no case, whatsoever, should be taken as anything more than that.

gocryptfs is extensively documented. For all questions refer to documentation and if something is actually missing you can ask here. Open an issue with "DOCUMENTATION" tag and I'm sure @rfjakob will cover it.

[madbolter]

You are correct that this is my first foray into Github public. We use
Github extensively, but always privately within our company. I am not
familiar with how these "responses" work or that, apparently, the entire
Github community can join in on a "discussion." I thought a Dev had
responded, and then I thought that another Dev had continued. My mistake.

Regarding: "It is also REALLY poor form to threaten to badmouth a project
because you got a rude reply from a github user on the issue tracker."

"Badmouth" is overkill. We occasionally get into discussions with our
customers about how we do things, as it's a big, sharing community. We
share ideas and approaches. And the "user community" that surrounds a
particular package (including the Devs themselves) speaks to whether a
package or library is "well-supported". I said that I would "share my
experience" with this "community," and I will. Frankly, this "community"
comes off like some Steam-game fanbois who will not tolerate anything "bad"
being even suggested about their favorite game, so if you make the mistake
of posting to a game's Steam forum anything other than bowing down and
worshiping at the feet of the Devs, the fanbois brutalize you. Just not
worth it. You quickly learn about a "community," and, yes, my first foray
into this one was less than "welcoming."

The people responding on this thread apparently are quick to rebuke
ignorance but will not rebuke outrageous, completely inappropriate
responses.

Ignorance? How dare I? Yes, I use encryption; I don't develop encryption
algorithms. Our company develops AI not encryption. I could read up on
salted passwords to see how in-theory crackable they are. I don't have
time, so I asked a question and posed a point that (even after all this) I
still believe is valid. You say, "It simplifies management of multiple
encrypted dir mountpoints." The obvious alternative to this would be to put
config files in some directory like /etc/gocryptfs and relativize the
filenames to distinguish between mountpoints. That should be the default.
There is no additional "simplicity" to put such files in the encrypted
directory itself, and I would never put out into the wild the very
information that could in-principle be used to decrypt the data.
Vulnerabilities in algorithms are discovered all the time! I don't need to
be a salted-password expert to suggest that it's not a good idea
in-principle to put any of the decryption information in with the data
itself! And that point about newly-discovered vulnerabilities in algorithms
should be all I need to say on this point. It's trivially easy to
better-secure the config files, and saying that my idea is "non-standard"
is not an adequate response. Those config files should not be with the
data, as putting them there is depending entirely upon the (countless times
proven to be false) belief that algorithms themselves are absolutely solid!

For the record, our passwords are 40-character random passwords. Pretty
secure as far as passwords go. But the point is that I go out of my way to
give hackers/crackers as little to work with as humanly possible, because
algorithms are not themselves as impervious as everybody wishes they were.
If it's made by people, it can be broken by people. Period. So, we don't
give nefarious types ANY help.

Regarding not jumping to conclusions, well, we all jump to conclusions at
all times! We all work from limited information, because none of us has the
time to do the in-depth research across the wide range of subjects that all
come together in these complex systems. I didn't read the documentation at
that early point in my assessment, because I "jumped to a conclusion" just
enough to ask a question and make a point (that I still stand by now) that
it's not a solid practice to put the salted password information in with
the encrypted data. Instead of an answer, I got dog-piled with completely
inappropriate messages except for yours, Nodens. And even yours rebukes me
rather than the other ridiculous responses. Even your "friendly advice" is
a rebuke that in effect says, "Don't you dare ask a question or make a
point until you are confident that you understand the ins and outs of the
thing you're asking about." Okay, I've learned my lesson. I will NEVER deal
with the gocryptfs "community" again, because I can't imagine when I'd ever
feel confident enough that I had surpassed ignorance on all relevant points.

If this is "community," you can have it. Closing this issue.

On Thu, Sep 3, 2020 at 5:00 AM Nodens- [e-mail] wrote:

@madbolter https://github.com/madbolter
First of all LicoMonch is not a developer or a contributor to gocryptfs so
he can't include anything in documentation. They're a github user, like I
am too. You must obviously be new on github but repository owners and
contributors are clearly marked as such, on their posts, at the same bar
with the name and commented time, on the right side. You can also mouseover
a username to see any pertaining info. It is also REALLY poor form to
threaten to badmouth a project because you got a rude reply from a github
user on the issue tracker.

Secondly, your use case is not the default use case and it makes sense to
include that file per encrypted dir. Why? Because:
a) It simplifies management of multiple encrypted dir mountpoints.
b) It's NOT really insecure. The article/guide you mentioned does NOT
actually tell you how to decrypt from that file. It tells you that it's
THEORETICALLY possible, given enough time (all forms of encryption are
theoretically possible to decrypt "given enough time"--but if that time is
10bil years with current processing power it's virtually impossible), to
brute force or dictionary attack it, and the author just displays what's
inside in a sample file. This means if your passwords have any semblance of
following security standards it's virtually impossible. If your password is
"password" it can be attacked easily anyhow.

Thirdly, the option to store the file wherever you want is actually
present and is documented. If you want to do something that doesn't fit the
default use case you must always consult the documentation to see if your
use case is feasible with a certain piece of software.

Lastly, a friendly advice. While looking at "guides" to see how a piece of
software is used on a certain platform, is fine, it's also a VERY good idea
NOT to jump to conclusions without reading the documentation EXTENSIVELY,
yourself. As you see, very clearly, in this case, the guide's author has
really NO idea what they're talking about and they clearly have not read
the documentation either. Guides such as these make for very poor source of
information that almost always contradicts the reality of things. Most of
them are copy/pasted, plagiarized, from site to site too. It's fine for a
complete newbie to get their bearings on how to set something up but in no
case, whatsoever, should be taken as anything more than that.

gocryptfs is extensively documented. For all questions refer to
documentation and if something is actually missing you can ask here. Open
an issue with "DOCUMENTATION" tag and I'm sure @rfjakob
https://github.com/rfjakob will cover it.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/rfjakob/gocryptfs/issues/500#issuecomment-686412976,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AGUUMQ3N6P6IGRTJ5HDKJHTSD5ZNLANCNFSM4QT6EJBQ
.

--
Richard Jensen, Ph.D.
President, Conclusive Systems LLC
www.conclusivesystems.com
[email protected]
866-234-8164 (office)
303-525-7101 (mobile)

[Nodens-]

@madbolter It was not my intention, whatsoever, to "rebuke" you. And of course I found absolutely no reason to occupy my time with the rude response that you initially got. It is not my place to do so either. I replied to you in order to help you and make you understand that you were not talking to the developer (rfjakob) as it was obvious that that was what you thought. I also went the extra mile to help you understand how to spot these things.

Also, for the record, this is NOT a "community". This is an Issue Tracker for a particular project's PUBLIC repository. What this means is that anyone with a registered github account can comment on these. This is standard on every public open source software's bug tracker no matter if it's on github or a dedicated one somewhere else. Also a lot of us have the project on "WATCH" for many reasons but mainly for keeping an eye on possible bugs and development as we are users of the software. Hence we get email notifications on posts. This is why I saw this issue in the first place and decided to try to help you understand the situation.
Lastly I personally have no problem with ignorance and I will always try to direct someone to proper information. Should that direction not be followed though, I have no inclination to keep answering questions about topics that are already covered in said pointed documentation.

Now, let's get back on topic please.
`a) It simplifies management of multiple encrypted dir mountpoints.

Meaning portability. You may have hundreds of encrypted dirs that are regularly archived locally or moved between systems. Storing configuration by default in /etc complicates things. A LOT. Also mountpoints can change so, no, you can't use mount names to distinguish unless you have a very specific use case/implementation. You could argue the use of a UUID but that adds further complexity for no apparent reason. You don't add complexity where it's not needed. More so with the excuse of covering a single use case that's.. already covered.

Secondly you seem to completely ignored what I told you in b). It is not actually unsafe. You are not handing anything out. And if you're actually using an untrusted cloud storage for archival/backup reasons ( I use google drive myself for some things) and your paranoid level (not implying mental illness, it's standard terminology in security) is high (eg assuming Google may get attacked or prove to be a really bad actor or something), then your specific, non-default use case is covered by the option to save the config file wherever you want (including /etc.. you can make for example systemd units for your mounts that save each mount's config to it's own dir under /etc/gocryptfs..everything is possible and you can adapt the software to your use case).
But you must understand that you can't insist that for your specific use case, to make the default VERY inconvenient and complex for the majority of other use cases specially when there's zero justification to do so.

I hope this clarifies things so we can finally move on.

[madbolter]

Thank you for your thoughtful reply, Nodens. I much appreciate your
clarifications, and you make a better case than I originally contemplated.
I have to process that more.

We are on the same page about what "level of paranoia" means; ours is very,
very high! I have a fundamental distrust of blithe confidence in
algorithms, however "secure" they seem (right up until the moment a
vulnerability is discovered). I remain unconvinced that nothing is being
given away by the config files. However....

I agree that the ability to store the configs to a chosen directory
satisfies our use-case and the highest level of paranoia, so there's no
point in continuing that side of the debate. I'm not convinced by your
anti-UUID argument, as that approach has become industry-standard across
the virtualization community, and it is not "a LOT" more complicated; it's
actually profoundly flexible. However, that side of the discussion has
really been rendered academic because we can get the configs out of the
encrypted directory, which is really the point for us.

Basically the "debate" comes down to some really fine points of priority.
The gocryptfs devs chose a particular set of priorities, and you make a
solid case in support of that set of priorities. I'm not as convinced
about that, but I AM convinced by your arguments that they didn't "do
wrong" in their choices. You like that set of priorites better than I do,
which is fine. No point in debating fine points that don't make a
difference for our particular use-case.

Ultimately, a productive argument and learning experience for me. Thank you
for elevating things!

On Fri, Sep 4, 2020 at 9:58 AM Nodens- [e-mail] wrote:

@madbolter https://github.com/madbolter It was not my intention,
whatsoever, to "rebuke" you. And of course I found absolutely no reason to
occupy my time with the rude response that you initially got. It is not my
place to do so either. I replied to you in order to help you and make you
understand that you were not talking to the developer (rfjakob) as it was
obvious that that was what you thought. I also went the extra mile to help
you understand how to spot these things.

Also, for the record, this is NOT a "community". This is an Issue Tracker
for a particular project's PUBLIC repository. What this means is that
anyone with a registered github account can comment on these. This is
standard on every public open source software's bug tracker no matter if
it's on github or a dedicated one somewhere else. Also a lot of us have the
project on "WATCH" for many reasons but mainly for keeping an eye on
possible bugs and development as we are users of the software. Hence we get
email notifications on posts. This is why I saw this issue in the first
place and decided to try to help you understand the situation.
Lastly I personally have no problem with ignorance and I will always try
to direct someone to proper information. Should that direction not be
followed though, I have no inclination to keep answering questions about
topics that are already covered in said pointed documentation.

Now, let's get back on topic please.
``a) It simplifies management of multiple encrypted dir mountpoints.

Meaning portability. You may have hundreds of encrypted dirs that are
regularly archived locally or moved between systems. Storing configuration
by default in /etc complicates things. A LOT. Also mountpoints can change
so, no, you can't use mount names to distinguish unless you have a very
specific use case/implementation. You could argue the use of a UUID but
that adds further complexity for no apparent reason. You don't add
complexity where it's not needed. More so with the excuse of covering a
single use case that's.. already covered.

Secondly you seemed to completely ignored what I told you in b). It is not
actually unsafe. You are not handing anything out. And if you're actually
using an untrusted cloud storage for archival/backup reasons ( I use google
drive myself for some things) and your paranoid level (not implying mental
illness, it's standard terminology in security) is high (eg assuming Google
may get attacked or prove to be a really bad actor or something), then your
specific, non-default use case is covered by the option to save the config
file wherever you want. But you must understand that you can't insist that
for your specific use case, to make the default VERY inconvenient and
complex for the majority of other use cases.

I hope this clarifies things so we can finally move on.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/rfjakob/gocryptfs/issues/500#issuecomment-687237636,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AGUUMQZIJMNPYQO3YBN2J23SEEFB3ANCNFSM4QT6EJBQ
.

--
Richard Jensen, Ph.D.
President, Conclusive Systems LLC
www.conclusivesystems.com
[email protected]
866-234-8164 (office)
303-525-7101 (mobile)

[Nodens-]

You may be interested in checking out the security audit gocryptfs has been through here:
https://defuse.ca/audits/gocryptfs.htm

Regarding additional complexity, the point is that it doesn't make sense to cause the majority of users to have to write scripts to copy the config file from /etc when they need to move the ciphertext and/or handle additional problems that may arise with regards to portability. Specially when very easy solutions exist for achieving what you want for the edge case.

Here's an example of a simple systemd unit to achieve what you want:
```[Unit]
Description=gocryptfs mydata mount
Requires=local-fs.target
After=local-fs.target

[Service]
Type=forking
User=user
Group=group
ExecStart=/usr/local/bin/gocryptfs -config /etc/gocryptfs/mydata.conf /mydata/.cipher /mydata/plain
ExecStop=/bin/fusermount -zu /mydata/plain
Restart=on-failure
RestartSec=5

[Nodens-]

And here is the threat model: https://nuetzlich.net/gocryptfs/threat_model/

[madbolter]

Heh... now you're wanting to get deep into the weeds, and, as I say, it's
almost certainly an academic point because gocryptfs allows the config to
be in a designated directory.

I did find the information you provided to be extremely interesting
reading, although you'll probably be dismayed to know that I find gocryptfs
less impressive after reading through that information. Moreover, the
threat model gocryptfs recently provided has not been reviewed by audit and
does not resolve every point raised by the audit. Indeed, it's somewhat
troubling that the most recent audit is more than three years ago. Lots
changes on this front in more than three years, and gocryptfs itself has
changed a lot (presumably for the better).

The threat model I envision is basically the "Dropbox" one from the audit
(which is some variant of the three audited threat models and is basically
"Dragon" in gocryptfs's thread model). In that scenario, the attacker has
at least read access to both the ciphertext and the config (as you state is
preferable and that I dispute).

At this point, we really are deep in the weeds, and I do not consider
myself either an expert or that I will ever become an expert. So, I must
rely upon the opinions of authorities. Of course, the problem with that is
that the debate then turns into opposing citations/interpretations of
"authorities," with each side asserting that its "authority" is "better,"
and then engaging in the war of interpretations. Be it computer science or
politics, such debates are invariably fruitless. So, I am wary of being
drawn into such a "discussion" that is unlikely to produce
properly-convincing evidence on either side. But... well, I'll plunge into
the abyss.

Given that we're into the "academic" aspect of our discussion now, I assert
that including the config (containing the salt and the salted password) by
default alongside the encrypted data is a bad idea. I take you to be
asserting that there's no (appreciable) danger. And I from the start
asserted that the threat model I have in mind is BackBlaze/DropBox/"Dragon"
where the attacker has at least read access to the ciphertext and the
config. I take you to be asserting that having the salted password
alongside the salt itself available to the Dragon attacker is no
(appreciable) danger. I dispute this, although, again, the point is
academic, since gocryptfs makes it easily possible to not include the
config with the ciphertext.

But to that academic point....

First, to be crystal clear, the gocryptfs default IS to include the
encrypted password (key) and the salt in the config file that is included
with the ciphertext in the threat environment. So, the average user is more
than merely encouraged to use this default storage practice, and that fact
is really what motivates me at all to continue this discussion.

Now, (at least) two theoretical questions emerge: 1) Is the salting
algorithm also available to the attacker? 2) With the key/salt/algorithm
available, how difficult is it (both in theory and in practice) for the
attacker to reverse engineer the plain-text password and thereby be able to
decrypt data at will?

In the case of gocryptfs, the answer to (1) is: Yes. So, the question
emerging in (2) is where the rubber meets the road. And I assert that if
the answer to (1) is No, then the answer to (2) becomes some variant of:
"harder." The issue revolves around how difficult it is to engineer a
fairly comprehensive set of lookup tables (for simplicity I call "lookup
tables" any of the numerous variants, including "rainbow tables") based
upon the known salting algorithm. And note that the creation of the tables
and the following brute-forcing attack can be done on the attacker's
hardware of choice, so there can be no imposed slow-downs or
forced-timeouts. The attacker has everything needed to write everything in
the desired environment and then go hog-wild with as much horsepower as is
available.

Now, as you rightly note, the more pathetic your original password, the
easier everything becomes for the attacker, because salting a password of
"1" is theoretically going to fall to a brute-force attack faster than,
say, "3sdO3$1**d4CX#^qq!3M9zZ%(qXl@" and so on. But the whole game we are
facing here revolves around how much "extra" protection the salting process
provides, as well as whether having access to the salting algorithm and the
salt make the creation of a useful lookup table (actually just a
brute-force attack in real-time) easier.

The received wisdom is that salting, being a one-way hash, is extremely
secure. That wisdom further states that if the salt is randomly-generated,
then the salted password is much more secure. However, the flies in the
ointment start to appear.

Back to (1), gocryptfs makes its source code available, including the
salting algorithm. Further, the scrypt salting algorithm is open-source. So
all parts of the hashing process are published and accessible to the
attacker. Now another question emerges: Is the random salt derived from a
CSPRNG or from a weak merely pseudo-random number generator? A weak
pseudo-random method is "deterministic" and can be reverse-engineered if
the attacker has access to a fairly small subset of generated salts (such
as an attacker with Dragon access to, say, DropBox volumes would have).

At this point you might slip into an argument like, "A lock on a door makes
it more secure than just leaving the door hanging open. Adding a deadbolt
makes it more secure. If you start debating the quality of deadbolt, I'll
say that the more important question then revolves around the nature of the
door and the door-frame." And so on. All such arguments are variants of
asking the implied question: "Really? Just how secure do you really need it
to be, given that you've got a decent password?"

But I take any such argument to be a punt, because, holding a "decent
password" to be a constant, there are demonstrably better and worse ways to
secure both the password and the data the password protects. And for
sensitive data protected by federal laws (and reporting requirements),
"good enough" really needs to equate to "the best available at any given
moment," which is why my level of paranoia is high.

So, since we're engaging in the "academic" set of questions, questions
like, "Is the random salt derived from a CSPRNG or from a weak pseudo-random
number generator?" are not akin to discussing "good" and "better"
deadbolts. We are talking about an attacker who has access to all the
pieces of the puzzle and has some significant hardware (like a small
cryptocurrency farm) and doesn't mind if the process churns for a month or
a year or more. That sensitive data isn't going anywhere (it's on a backup
cloud volume, so likely sitting there for years at a time), so time is not
of the essence, as long as "time" isn't "many years" or more. Even a few
months of banging away on the problem isn't an issue here for Dragon.

So, back to the CSPRNG question. Gocryptfs uses scrypt for salting. But
scrypt supports both modes of random-number-generation. I have looked quite
a bit, but without digging into gocryptfs's code, it remains an open
question in my mind whether or not gocryptfs's implementation of salt rises
to an acceptable standard of randomness. This is not clarified anywhere
that I can find (unlike our fabled attacker, I don't have months/years of
time to throw at this project). So, I'm already troubled in a small way.
One thing is clear at a glance, however, and that is that gocryptfs isn't
using the most desireable salt approach, which is to generate salts that
are at least the same byte-length as the resulting hash will be.

But the real fly in the ointment is bigger and more intrusive than just
this point.

The whole purpose for salting a password is to make it hard (extremely
difficult) for an attacker to either use a pre-existing lookup-table or to
in timely fashion generate a new one (or engage in lengthy, real-time
brute-forcing). However, when you hand the attacker the salt itself along
with the salted password, you make the job much easier (less
time-consuming). Now the attacker merely needs to include the salt along
with the known salting algorithm into the process to generate hashes
(salted passwords including the known salt) in a brute-force comparison.
Yes, the more processing power the attacker can throw at the project, the
faster it goes, particularly if the attacker has even a small
cryptocurrency mining setup.

Now your point about solid passwords is most pressing! But it is even more
pressing in the Dragon case because the attacker has both the password and
the salt used to generate it! Take away the salt and knowledge of the
algorithm, and now the attacker is at a very significant disadvantage. Even
a relatively pitiful password is much more secure, because the attacker has
no means by which to "filter out" the salt itself in generated hashes for
comparison purposes. The brute-force problem is exponentially harder (more
time consuming) because now the attacker has to try "adding in" random
salts to random-hashed passwords to try to discover a match. As you say,
"effectively impossible." But it is no longer "effectively impossible" when
you allow the attacker to use the known algorithm and the known salt to
create hashed passwords to brute-force with, thereby "filtering out" the
whole point to the salt in the first place.

What I'm saying in the above paragraph is apparently widely known, and
there are basically countless articles (I've found many) that highly
recommend against storing an encrypted password with its salt or revealing
the salt to anybody. Here is just one that provides a nice explanation of
why to not store a salt and its generated password together for our
purposes (the Dragon scenario):

https://security.stackexchange.com/questions/17421/how-to-store-salt

The back-and-forth is very instructive, as it demonstrates the
inconsistencies that emerge when "comparing" different threat scenarios as
though they are the same and then specifying an "acceptable protocol" for
all scenarios. To whit....

In the case of database storage of salt+password for the purpose of
real-time authentication of users, keeping the two together is almost a
requirement, and breaking them apart to be separately stored is so
impractical as to be an almost worthless "protocol." But the attacker has
to first gain access to the database in order to get a password and its
salt, and such attackers are invariably not seeking just one password! They
are looking to gain sweeping access to multiple (all of them) user
accounts. So, storing a password with its (presumably random and
unique-per-user) salt is a non-threat, because no attacker is going to
bother spending months or years or more to crack a single salted password!
For that use case, storing the password with the salt is both an
inconsequentially tiny and virtually necessary risk.

However, the threat scenario is exactly reversed (as "Polynomial" well
articulates) in the case of a cloud-store of encrypted data protected by a
single salted password! In that case, the attacker by definition only needs
to crack a single password to get at the gold, and the presumption is that
a pile of encrypted files is the gold worth devoting some serious
processing time to.

Moreover, unlike the database-compromise case, the Dragon attacker HAS time
(almost certainly without discovery) to engage in the cracking process. The
database attacker will almost certainly be discovered in pretty short
order, so such an attacker lacks the time to brute-force a pile of
passwords before those passwords and their salt will be changed. But the
Dragon has time, and such an attacker is brute-forcing just one password to
get the gold.

That is why "Polynomial" correctly notes that the salt should not be stored
with the password and should not be made public. The people saying that the
two can go together and that a particular salt can even be made public are
the ones envisioning the database scenario. "Polynomial" is correctly
noting that if the attacker is granted time, having both the one password
and its salt can enable the creation of a "custom rainbow table," which I
refer to as just brute-forcing-in-place, because all the attacker is going
to do is use the known algorithm to hash some password with its salt,
instantly compare the resulting hash against the hashed password, and when
there's no match, just store that failed password so as to not try it
again, and then move onto the next one until a match occurs.

Now you are again saying, "But if it's a good, secure password, such a
process is still virtually impossible to result in success." Ah, that is
somewhat theoretically true, but now the Devil really is in the details!
How long do you think it would take a present-day supercomputer to crack a
40-character, random password by this method? Yeah, I'll agree: A LONG
time! Years? Hundreds of years? It really depends upon a LOT of factors!
But here's the catch: Even "many years" is an unsatisfactory answer. That's
because that estimate is based upon the HOPE that the brute-force attempt
doesn't just get lucky on the very first attempt. Now we're into an odds
game.

If you flip a known-fair coin fairly 10 times and it comes up heads all ten
times, most people will start betting more and more money on the
"increasing certainty" that the next flip will result in tails (after all,
it just MUST start a string of tails "any time now" in order to "even out"
the string of heads). The well-known gambler's fallacy. However, something
much like the thinking involved in the gambler's fallacy is used when
referring to some theorized cracking-time for a
particular-length/complexity of password based upon some theory about how
that password was hashed. Sure, with present supercomputers, some
particular brute-force crack against some particular encryption algorithm
might theoretically take 10,000 years. But it also might take one second.
Somebody wins the lottery, even though the mathematical odds are hugely
against any particular person winning it.

The POINT to salting a password (even a super-secure password) just is to
push that theorized time "way, way out there," thereby radically decreasing
the odds of a successful brute-force crack of it. But when you give the
attacker any significant length of time (a year or two?), and you publish
the salt along with the password, especially when the attacker knows
exactly what salting algorithm to use, you've just eliminated the point to
the salt! That is why in a database attack, it is "secure enough" to salt a
password with a random, unique salt and keep that alongside the salted
password: The attacker has neither the time nor the motivation to
brute-force attack just one out of hundreds of thousands of passwords. And
the attacker doesn't know in advance what algorithm was used to take a salt
and produce a hash with it, so "filtering out" the salt is non-trivial. But
in the Dragon attack, the attacker has significant time to brute-force, the
attacker is highly motivated to work on just one password, and the attacker
has all the pieces of the puzzle with which to craft a solid brute-force
attack.

With encrypted/salted passwords, your only protection is, literally, just
time and hope that the attacker doesn't have significant processing
resources to throw at the problem. But nowadays, the processing part of the
equation is unknown. There are lots of regular people with amazingly
powerful cryptocurrency-mining farms in their basements. The
crypto-cracking processing power of these little farms makes the
supercomputers of even five or ten years ago look almost lame. And AMD just
keeps churning out new processing power that happens to serve graphics
applications and as an aside are even better than Nvidia to serve
cryptocurrency processing. Who knows (and I do mean, literally, who KNOWS)
what sort of horsepower will be available to the "average person" in the
next five years? So, that odds game that the "hopeful one" depends upon for
"security" is nothing but a function of time (the Dragon attacker probably
has a good deal of it) and the processing power that one HOPES doesn't
reduce the needed time for a crack down to what is actually doable.

So the question remains: WHY give the attacker ANY advantages in that odds
game? It appears to me undeniable that including the salt along with the
salted password and then handing them both, along with the salting
algorithm, to the attacker is significantly reducing the "time" part of the
equation, which is the VERY part of the equation you are banking on when
you encrypt data in the first place! And in the Dragon scenario, the
attacker HAS time, certainly months and probably years. Is it enough? Well,
who knows?

The overarching point is that we want to employ every possible means to
deny an attacker ANY advantages. We want to employ every possible means to
extend even the theoretical time a brute-force crack can take, thereby
upping the odds that no particular iteration will be successful. There is
no "perfection" to be had here under the best of circumstances, so why
would we knowingly settle for far less than the best possible practices if
the data really, really needs to be kept secure?

So, in summary, there are a couple of problems (not "massive" but
"troubling enough" to me) with including the password with the salt
alongside the encrypted data. I continue to believe that it is not good
practice for gocryptfs to store the salt and the salted password with the
encrypted data, precisely because the Dragon scenario involves the target
case for users of gocryptfs (the very scenario that recommends gocryptfs
over its competitors!), and that is precisely the scenario when that
storage practice gives the theorized attacker the most possible advantages.

There is always a trade-off between convenience and security. For most
people, the default storage practice is "secure enough," given the likely
minimal consequences of having their password cracked and the odds against
it. But in cases where that data must be as secure as possible, the
practice gives the attacker advantages that I have no interest in providing.

Fortunately, gocryptfs provides a means to separate the config from the
data. Thus, the point about the config storage practice really is academic.

On Fri, Sep 4, 2020 at 12:53 PM Nodens- [e-mail] wrote:

And here is the threat model:
https://nuetzlich.net/gocryptfs/threat_model/

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/rfjakob/gocryptfs/issues/500#issuecomment-687322225,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AGUUMQZNFBVQJRRK3OY4N43SEEZQ3ANCNFSM4QT6EJBQ
.

--
Richard Jensen, Ph.D.
President, Conclusive Systems LLC
www.conclusivesystems.com
[email protected]
866-234-8164 (office)
303-525-7101 (mobile)

[Nodens-]

You seem to be confused on a couple of points and drawing some conclusions on false basis. I'll clarify as simple as I can.

a) The point of a salt is just one. To stop lookup table attacks (eg rainbow tables that you mentioned). It has nothing to do with pushing computational time.

b) A lookup table only has meaning if it can be used to immediately match hashes to pre-computed password hashes. Because doing a lookup operation is cheap (an operation that completes in seconds). Computing hashes is not.

c) It does not matter at all how the salt is created AS LONG as the salt result is never the same. To further clarify this point. If gocryptfs used the same salt for every encrypted dir on every system it would be a problem because an attacker would be able to create a lookup table for ALL gocryptfs users, rendering the existence of the salt pointless. As long as the salt is different every time, a lookup table can not be created. The salt value, by definition, is not secret and does not need to be secret. This is standard practice and a scientific fact. Read here: https://en.wikipedia.org/wiki/Rainbow_table#Defense_against_rainbow_tables

d) You did not really understand the caveat Polynomial is mentioning in that particular link. He's talking about something else entirely that does not apply at all to this case. To oversimplify he's talking about salt reuse. In his example his mentioning an attacker quietly getting a salt that's used on every account hash, precomputing a rainbow table and then using that to crack account hashes using that particular salt. This has no application here at all. In gocryptfs whether you have the salt or not you just have to compute the hashes and that's about it.

Specifically. If an attacker has your particular salt, there's NOTHING they can do with it. Creating a lookup table just for you is pointless. The point of a lookup table is to be reused so the costly calculation happens only once and then you just lookup hashes. Calculate it once and use it everywhere. Creating a lookup table for your particular salt is effectively just calculating the hashes for the target only which literally means just brute forcing. It's not a lookup table anymore. It becomes a lookup table if the calculated hashes can be saved and by reused for lookups for another target which is simply impossible (because said other target will have hashes computed with a different salt). So the attacker does not have ANY advantages which is the point I was trying to get across from the get go. Which is also why I said that the author of that article back then doesn't really know what they're talking about and that this is a common trend in online "guides". Another trend is that they know what they're talking about but they're on-purpose being controversially fearmongering so that the article gets viral for ad revenue.

To answer your other question about how long it would take to brute force a random 40 char password composed of alphanumerics and symbols, it's multitudes beyond the estimated death of the universe with current computational power (GPU accelerated farms). A single overclocked Geforce 1080 computes about 430 khashes per second (oclhashcat benchmark).
There are online calculators for that. With our current 17042497.3khs computational speed (the current recorded max on GPU farms -- which is a lot) a 13 char password of the same characteristics would take 62894702 millenia, 4 centuries, 9 years, 2 weeks, 1 day and 19 hours. That time grows exponentially with each character added. In the unlikely scenario that we'll manage to multiply that computational power exponentially in the next few years, to the point that this becomes an actual problem, even theoretically, you can be assured that more complex algorithms will surface as well and you will have to re-evaluate your encryption needs at that point. For now and the foreseeable future all is well.

[madbolter]

I think that you missed every point of my argument. Of course, I could be
confused, as you say. I don't think so, but that's just what a confused
person would think.

So, let's take this step by step and see where what should start as
agreement goes astray. I'll start by asking a question.

Would you agree that the algorithm that combines a salt and a password to
produce a hashed password is deterministic? In other words, by using an
algorithm to combine a salt and a password into a hashed password, will the
algorithm always produce the same hashed password if the salt and the
original password are the same?

I believe that you are going to agree that the result is deterministic,
because if it were not, then it would be impossible to repeat that
algorithm process using the salt and a user-entered password to generate a
hashed password to compare for authentication purposes. So, I believe that
you will agree that the algorithm that produces a hashed password will
always produce the same hash, given the same original password and the same
salt.

But let's start by seeing if we're on the same page about that basic point.

On Sat, Sep 5, 2020 at 5:45 AM Nodens- [e-mail] wrote:

You seem to be confused on a couple of points and drawing some conclusions
on false basis. I'll clarify as simple as I can.

a) The point of a salt is just one. To stop lookup table attacks (eg
rainbow tables that you mentioned). It has nothing to do with pushing
computational time.

b) A lookup table only has meaning if it can be used to immediately match
hashes to pre-computed password hashes. Because doing a lookup operation is
cheap (an operation that completes in seconds). Computing hashes is not.

c) It does not matter at all how the salt is created AS LONG as the salt
result is never the same. To further clarify this point. If gocryptfs used
the same salt for every encrypted dir on every system it would be a problem
because an attacker would be able to create a lookup table for ALL
gocryptfs users, rendering the existence of the salt pointless. As long as
the salt is different every time, a lookup table can not be created. The
salt value, by definition, is not secret and does not need to be secret.
This is standard practice and a scientific fact. Read here:
https://en.wikipedia.org/wiki/Rainbow_table#Defense_against_rainbow_tables

d) You did not really understand the caveat Polynomial is mentioning in
that particular link. He's talking about something else entirely that does
not apply at all to this case. To oversimplify he's talking about salt
reuse. In his example his mentioning an attacker quietly getting a salt
that's used on every account hash, precomputing a rainbow table and then
using that to crack account hashes using that particular salt. This has no
application here at all. In gocryptfs whether you have the salt or not you
just have to compute the hashes and that's about it.

Specifically. If an attacker has your particular salt, there's NOTHING
they can do with it. Creating a lookup table just for you is pointless. The
point of a lookup table is to be reused so the costly calculation happens
only once and then you just lookup hashes. Calculate it once and use it
everywhere. Creating a lookup table for your particular salt is effectively
just calculating the hashes for the target only which literally means just
brute forcing. It's not a lookup table anymore. It becomes a lookup table
if the calculated hashes can be saved and by reused for lookups for another
target which is simply impossible (because said other target will have
hashes computed with a different salt). So the attacker does not have ANY
advantages which is the point I was trying to get across from the get go.
Which is also why I said that the author of that article back then doesn't
really know what they're talking about and that this is a common trend in
online "guides". Another trend is that they know what they're talking about
but they're on-purpose being controversially fearmongering so that the
article gets viral for ad revenue.

To answer your other question about how long it would take to brute force
a random 40 char password composed of alphanumerics and symbols, it's
multitudes beyond the estimated death of the universe with current
computational power (GPU accelerated farms). A single overclocked Geforce
1080 computes about 430 khashes per second (oclhashcat benchmark).
There are online calculators for that. With our current 17042497.3khs
computational speed (the current recorded max on GPU farms -- which is a
lot) a 13 char password of the same characteristics would take 62894702
millenia, 4 centuries, 9 years, 2 weeks, 1 day and 19 hours. That time
grows exponentially with each character added. In the unlikely scenario
that we'll manage to multiply that computational power exponentially in the
next few years, to the point that this becomes an actual problem, even
theoretically, you can be assured that more complex algorithms will surface
as well and you will have to re-evaluate your encryption needs at that
point. For now and the foreseeable future all is well.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/rfjakob/gocryptfs/issues/500#issuecomment-687597925,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AGUUMQ75BZN622XRJQGIIWLSEIQFDANCNFSM4QT6EJBQ
.

--
Richard Jensen, Ph.D.
President, Conclusive Systems LLC
www.conclusivesystems.com
[email protected]
866-234-8164 (office)
303-525-7101 (mobile)