Warning Users Against the Use of Gocryptfs

So the individual behind the 'gocryptfs' fs encryption tool for UNIX systems (that means Linux / BSD here), refuses to replace Scrypt with Argon2id.

Already opened up two issues about this on their GitHub (not going to open up another one). Published a study outlining the issues with Scrypt in a nutshell.

Issues

1. Scrypt is a memory-hard hash algorithm. You use it to hash passwords typically. Its purpose is to make brute forcing passwords more costly for the attacker by forcing them to utilize a bunch of memory / time for each password guess attempt.

2. Scrypt is vulnerable to cache timing attacks. This is not a theoretical attack as it has been pulled off in the wild with success.

3. Argon2id is designed to address all of those issues

4. Considering how Scrypt is used in the grand scheme of things for 'gocryptfs', this struck me as an imperative change that needed to be made imminently given the various means of compromise that would involve an attacker being able nestle deep enough within a Unix system to disturb the cache during a Scrypt operation, allowing for the subsequent extraction of information (the PBKDF2 secret).

Original Developer Refuses to Fix it

He closed the issue. So in my opinion, gocryptfs should be considered vulnerable until otherwise patched.

If there is a known attack against an implementation that can be exploited, then that's what it is - period. If you as a developer refuse to incorporate a drop-in replacement that's demonstrably better in all facets that mitigates the entire problem then.. we have to question the intentions of the original developer.

LibreCryptography

Warning Users Against the Use of Gocryptfs

So the individual behind the 'gocryptfs' fs encryption tool for UNIX systems (that means Linux / BSD here), refuses to replace Scrypt with Argon2id.

Already opened up two issues about this on their GitHub (not going to open up another one). Published a study outlining the issues with Scrypt in a nutshell.

Issues

1. Scrypt is a memory-hard hash algorithm. You use it to hash passwords typically. Its purpose is to make brute forcing passwords more costly for the attacker by forcing them to utilize a bunch of memory / time for each password guess attempt.

2. Scrypt is vulnerable to cache timing attacks. This is not a theoretical attack as it has been pulled off in the wild with success.

3. Argon2id is designed to address all of those issues

4. Considering how Scrypt is used in the grand scheme of things for 'gocryptfs', this struck me as an imperative change that needed to be made imminently given the various means of compromise that would involve an attacker being able nestle deep enough within a Unix system to disturb the cache during a Scrypt operation, allowing for the subsequent extraction of information (the PBKDF2 secret).

Original Developer Refuses to Fix it

He closed the issue. So in my opinion, gocryptfs should be considered vulnerable until otherwise patched.

If there is a known attack against an implementation that can be exploited, then that's what it is - period. If you as a developer refuse to incorporate a drop-in replacement that's demonstrably better in all facets that mitigates the entire problem then.. we have to question the intentions of the original developer.

hottg.com/librecryptography/190

56 viewsNov 4, 2020 at 16:19