Scrypt KDF cipher (scrypt CLI) - known vulnerabilities and cryptanalysis?

Question

There is a scrypt cipher that is used for example by some cryptos like LItecoin for their mining algorithm.

I never heard of scrypt. I know eg SHA-256 which is well analyzed and considered as secure until now.

1. Any known cryptanalysis for scrypt / vulnerabilities?

2. is scrypt considered in the community as a secure (comparable to sha256) cipher?

3. How collision-resistant is it?

4. Is it easily breakable by quantum computing attacks?

Answer 1

scrypt

scrypt is actually a password-based key derivation function (PBKDF ^*) created by Colin Percival; Stronger Key Derivation via Sequential Memory-Hard Functions. We want slower PBKDF functions since it will slow the attack times. The below is from hashcat performance;

scrpyt                         1172.8 kH/s (16.61ms)
PBKDF2-HMAC-MD5               18059.2 kH/s (69.72ms)

It is slower and designed against large-scale custom hardware attacks (ASIC,FPGA, and GPU) by requiring a large amount of memory. Internally uses PBKDF2 and Salsa20/8.

1. Any known cryptanalysis for scrypt / vulnerabilities?

The attackers cannot reverse the scrypt to find a pre-image. The only meaningful way is the password cracking by trying all possible passwords up to some length, checking the common password list, and trying combinations, or various other methods. If you want to mitigate this, you need to use a password with good entropy. You can generate one using diceware ( also EFF has a nice diceware page) or Bip39 or some other system that generates password with good entropy.

is scrypt considered in the community as a secure (comparable to sha256) cipher?

SHA256 is not a cipher, it is a hash function. You can also use SHA256 for KDF however not advised. The KDFs are designed for these purposes. For hash functions, we consider the pre-image, secondary pre-image, and collision resistance. For KDF functions the collision resistance or the collision attacks are not related.

There are no attacks on scrypt except for the first item.

3. How collision-resistant is it?

Collisions are not related to password hashing, the pre-image is requried

4. Is it easily breakable by quantum computing attacks?

Hardly, since the number of q-bits will be much higher than AES. The main reason will be a large memory. If ever built, it will use Grover's algorithm.

scrypt CLI program.

In short, scrypt CLI program uses AES256-CTR for encryption and HMAC_SHA256 for integrity and authentication. Little details;

• AES with the key size 128 bits resisted attacks even after nearly 22 years and practically still secure [1] [2] but vulnerable to multi-target attacks. From the code, as we can see, they use a 32-byte key, i.e AES256. That is even secure against Grover's quantum search [3].
• CTR mode requires a nonce (number used once), and should not be repeated. Once reused, it will be vulnerable to the two-time pad.
• HMAC is Hash-based Message Authentication Code here initiated with SHA256. It's security proven by Bellare, Mihir (June 2006). New Proofs for NMAC and HMAC: Security without Collision-Resistance under the assumption that the compression function is PRF.

---

* : don't confuse with PBKDF1 in rfc 8018

Answer 2

As kelalaka has already explained, Scrypt is a password-based key derivation function, a function used to derive a keys from passwords. For this use case, different security requirements apply than for simple hash functions (e.g. SHA-256) or ciphers (e.g. AES). Collision-resistance and also pre-image attacks are practically irrelevant. Because all modern password hashing schemes execute thousands of hash functions in sequence, it is unlikely that the function is reversible or that two passwords produce the same hash value.

On the other hand, it always matters how fast an attacker can test out passwords. Scrypt was developed with the goal of preventing parallel attacks by millions of custom hardware (especially ASICs) - or more precisely: to increase their cost extremely. The scheme achieves this through memory-hardness: a large vector in memory is needed for execution - and memory for ASICs and GPUs is very expensive.

However, other attack options arise from this scenario that affect Scrypt.

1. Cache-timing attacks: As shown in the introduction of the password hashing scheme Catena, a cache-timing attack can be performed against Scrypt using a spy process. The vulnerability of Scrypt to this attack is undeniable, but the attack has many prerequisites (including running a spy process) and has presumably not yet mattered in practice.

2. Time-memory tradeoff: if it is possible to execute the function with more operations instead of the vector in memory, the function can run on custom hardware after all. In principle, this is possible with Scrypt, but at the price of a much higher execution time. Anthony Ferrara was able to show in his Blog that there are certain use cases where such time-memory tradeoffs can still be beneficial (certain Scrypt parameters and GPUs as custom hardware), but overall Scrypt is considered more resilient in this regard than Argon2i or Catena, for example.

Other weaknesses pointed out so far, such as the password remaining in memory during execution and the garbage collector attack (both also in the paper on the Catena implementation), are of minor relevance.

Overall, Scrypt is not considered ideal in my view, but still secure.