bexelbie
commented
3 years ago @rfjakob has done an amazing job with Gocryptfs and it meets my needs effortlessly and I am proud to help package it for Fedora.
@Librechain you seem to have exposed a problem or your particular threat model. This doesn't, for example, impact my threat model. In situations such as this I would expect @rfjakob to accept patches, which he has offered to do. I would expect you, @Librechain , to do exactly what you promised to do, "I'll do all the heavy lifting if necessary. It won't take me (or you if you choose) any longer than 20-30 minutes, I imagine."
Please provide the patch you offered and not walls of text. Spreading FUD is not useful. If you have a threat model issue, state it as such. However, you offered a patch and now appear to be mad that everyone said, "please" instead of offering to do your work for you.
Librechain
lechner
LicoMonch
rfjakob
impredicative
Scrypt is Exploitable in a Practical Way Via Cache Timing Attacks
Just to give some background (sure you already know, but for the sake of any follow-up readers):
The paper goes on to outline the 'PRIME+PROBE' method, whcih the paper states is the "best technique to use against scrypt".
I won't waste too much time restating what is already contained in the paper, but in essence, an attacker is able to affect data in queued to be cached in a way that allows subsequent observations of said dat.
Specifically:
Insignificant Threshold For Would-Be Attackers
All that was written above possesses no significance without information on how viable such an attack would be.
Fortunately, the study outlines this for us as well.
It states:
The 'PRIME+PROBE' attack can be used at any time the attacker shares some level of processor cache with the victim.
Point one above is satisfied in an instance where the attacker is able to run another process on the same machine that the user is running scrypt on.
This can even occur if the attacker and victim are "working on separate virtual machines that are hosted on the same machine".
It is not necessary that the victim & attacker be on the same core of a multi-core processor either (as I know that must VM solutions involve dedicating some # of cores to the VM while running).
The above points are not exhaustive insofar as the attacker just needs to have figured out some means to put themselves in position to be sharing the machine's cache memory
Stanford Paper Outlines this Vulnerability in Scrypt That Allows For its Exploitation
Essentially what is stated in the passage above is that the PBKDF2 execution (within Scrypt is what is effectively compromised in this timing attack).
Both the Stanford study and the informational RFC (7914) are very clear in their documentation of the KDF's operation that a compromise of this portion of the Scrypt schme will allow an attacker to effectively compromise the entire algorithm:
Also, from the Stanford study:
This then leads us to:
At this point, we've now established that Scrypt can be exploited in a way that makes its inclusion in gocryptfs (beyond this point) questionable from many different perpsectives.
Addressing the Language Used in My Previous Issue
The apology that I made, remains. However, if this post is published, then I feel that those words will be justified, because one would have to stand in the face of well-established cryptanalysis, research and - to a fair extent, cryptographic principle itself in order to waive off the concerns that have been raised about Scrypt up to this point.
To be clear, that is not a threat, as this is now a matter of ethics at this point (and, no, that's not hyperbole).
Going Back to the Litecoin Miners That We Mentioned Earlier
If we're referring to an outputted hash from a successful Scrypt operation (that was not executed in a compromised environment), then sure, it is entirely implausible to suggest that even the entirety of the Litecoin network (hash rate-wise) would have the ability to brute force the password.
However, in lieu of what I've covered from the Stanford study regarding the trivial nature of the compromise of Scrypt's memory-hardness (which is supposed to be its key feature), we must now seriously consider the threat of this burgeoning network.
Why?
Per specifications, the output of the PBKDF2 function is piped into HMAC256 (via the two 32-bit output strings that would be created from the splitting of the 64-bit outputted by the PBKDF2 function).
This is critical to note because, when considering the information included above about timing attacks, it appears fair to assume that there is no 'random oracle' quality to the data extracted / observed by the attacker during the Scrypt hashing process
It Won't Be Litecoin - it Will Be BITCOIN Miners
Perhaps in hindsight my point about the Litecoin mining network was a bit irrational since they're mining Scrypt.
But by reducing the difficulty of 'cracking' the Scrypt to output to essentially brute forcing a PBKDF2(-SHA256) password (no salt) with default specified iterations, this seems like a job that would require trivial resource.
Available Commercial Hardware
Below is photo depicting Bitcoin mining hardware (top of the class, admittedly):
This picture above shows us that this miner is capable of providing >400TH(s).
As reference, this represents >4.1 x 1013 hash operations PER second.
This Machine Only Costs $2,500
That's 'Joe Blow can buy this' prices.
I'm sure either you or I could go ahead and purchase this machine right now if we really wanted / needed.
So could many other folks in this world fortunate enough to be normally functioning, responsible enough adult to maintain a stable job in a 1st-world economy for longer than... 6 months, perhaps.
Scrypt Vulnerability is Equivalent to a Vulnerability Overall for Gocryptfs
Going back to Gocryptfs, its worth considering the role that 'Scrypt' plays in the larger picture of the cryptographic scheme that Gocryptfs provides for users.
Scrypt is used as the KDF for the password that must be input into the program in order to mount a gocryptfs container.
Thus, it is no stretch in logic to say that this timing attack on the cache renders the entirety of the gocryptfs scheme extremely vulnerable.
This is amplified by the fact that gocryptfs as a program executes itself as a bash script, meaning that any attacker that has access to the bash_history of a user's machine will be able to find out the:
Location of the 'gocryptfs' container (which defeats the general practice of initializing a '.'-prefixed [hidden] file)
Parameters for the scrypt KDF
Whether or not there is a password file that's used
Concluding On Why Scrypt KDF Should Be Replaced
The solution is to replace it with Argon2 (which was literally designed to address all of the issues with Scrypt like the ones that I named above).
This write-up here does not outline the characteristics of Argon2 or what about its construction, specifically, makes it a better alterantive to Scrypt.
That will be appended in a subsequent entry to this 'issue' that I have pulled here in a few hours when I'm able to find a quick 30 minutes to break that down (for the edification of any that may stumble upon this issue at some point in the future out of curiosity for how the [hopeful] evolution past Scrypt for Gocryptfs occured)