6

The scrypt command line utility (see http://www.tarsnap.com/scrypt.html) is actually just a demonstration of the script password hashing algorithm.

However, for simple command line encryption of files, it seems to me that it could be one of the most secure. All symmetric encryption utilities (gpg, openssl, ccrypt) depend almost totally on the security of the password, the underlying file encryption is almost irrelevant.

As far as I can tell the scrypt demo uses ssl for the actual encryption, can anyone confirm this by the way?

So, it seems to me that scrypt is probably a good choice for an easy to use command line file encryption tool. Am I right?

  • If you use a salt, it is as good as any other means of generating a key. – Natanael Oct 8 '15 at 15:27
1

Background: Tarsnap's scrypt command uses AES encryption implemented by their own libcperciva. The scrypt algorithm is used as a key derivation function.

The good: The scrypt algorithm is one of, if not the most cryptographically secure key derivation function that we know of. This means that during a password brute-force attack, calculating the key from the possible passwords will be very costly. scrypt also uses a 32-byte salt when creating the key. From scryptenc.c:

crypto_entropy_read(salt, 32)

This offers protection against rainbow tables.

The unusual: scrypt AES implementation is via their own libcperciva. This is a custom implementation written by, and named for, Colin Percival, the founder of Tarsnap and author of the scrypt algorithm. While homegrown encryption implementations are generally considered less secure, an scrypt implementation by its author, a rather famous author, may be a counterexample. So you need to compare the advantages the author brings to the implementation to the fact that the library is not commonly used (ie: it has low Github statistics, a lack of visibility in OpenHUB, and only 1K hits in Google).

Summary: It is clear that using the scrypt algorithm with a strong salt as a key derivation function is a cryptographically secure strategy. There is some risk from using the homegrown AES implementation though that is somewhat mitigated by the skill of its author. You are left with three options that all seem reasonable choices:

  1. If you want a command line AES encryption tool that uses the scrypt function for key derivation, you may consider writing your own using a well-tested AES implemenation.

  2. You can use bcrypt key stretching algorithm, making it more secure by increasing the length of the random password that you use. This means there's more for you to remember, but it provides a known and measurable amount of security (compared to the unknowns of libcperciva).

  3. You can trust Colin Percival's implementation and use it as-is. I wouldn't dream of suggesting this for most people but we're not talking about most people.

Note: Thanks to @StephenTouset for pointing out Colin Percival's notoriety.

  • 2
    Colin Percival is probably one of the few people on this planet actually qualified to write his own implementations of ciphers. He wrote and designed scrypt, which as you note is one of the strongest PBKDFs we have (until the Argon2 spec is finalized, at least). He authored and runs the tarsnap encrypted backup service. He was the FreeBSD security officer. He even won the damn Putnam. – Stephen Touset Oct 9 '15 at 19:41
  • 1
    Thanks @StephenTouset. I updated the answer based on your comment. – Neil Smithline Oct 12 '15 at 18:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.