SCRYPT(1)

πŸ“¦
version 1.3.3 Β· 4 versions
, in debian trixie, ubuntu noble, ubuntu questing, ubuntu resolute, ubuntu stonking

πŸ’– SCRYPT(1) πŸ’–

okay bestie, sit down, we're doing crypto and we're doing it correctly. this is scrypt, a general commands manual page, and it's literally the moment your files get a glow-up (or a glow-down, if you're decrypting). it encrypts and decrypts files. no cap.


✨ NAME ✨

scrypt β€” encrypt and decrypt files πŸŽ€


🌸 SYNOPSIS 🌸

scrypt {enc | dec | info} [-f] [--logN value] [-M maxmem]
       [-m maxmemfrac] [-P] [-p value] [--passphrase method:arg]
       [-r value] [-t maxtime] [-v] infile [outfile]
scrypt --version

πŸ¦‹ DESCRIPTION πŸ¦‹

scrypt enc encrypts infile and writes the result to outfile if you specified one, or to the standard output otherwise. it will ask you for a passphrase β€” twice, because it wants to make sure you actually meant it πŸ’… β€” and that passphrase is used to generate a derived encryption key.

scrypt dec decrypts infile and writes the result to outfile if you specified one, or to the standard output otherwise. now it only asks once, because you just need to hand over the passphrase you used at encryption time so it can generate that same derived encryption key.

scrypt info is the nosy bestie of the group: it tells you all about the encryption parameters used for infile πŸ”

Unless you say otherwise via --passphrase, scrypt reads passphrases from its controlling terminal, or β€” if that doesn't work out β€” from stdin. and the prompts? those only get printed when scrypt is reading passphrases from some terminal. so if it's not on a terminal, it's not gonna say anything, it's just gonna vibe.


✨ OPTIONS ✨

  • -f β€” force the operation to proceed even if it's anticipated to need an excessive amount of memory or CPU time. also: don't print any warnings about exceeding any memory or CPU time limits. it's giving "I know what I'm doing, mind your business" πŸ’…
  • --logN value β€” sets the work parameter N to 2^value. heads up though: if --logN is set, -r and -p must also be set. and if you're giving such explicit parameters, the resource limits set by -M, -m, and -t are not enforced. (yes really, they just don't apply.)
  • -M maxmem β€” use at most maxmem bytes of RAM to compute the derived encryption key. budget girlie.
  • -m maxmemfrac β€” use at most the fraction maxmemfrac of the available RAM to compute the derived encryption key. the maximum possible value for maxmemfrac is 0.5. that's the ceiling bestie, don't fight it.
  • -P β€” deprecated synonym for --passphrase dev:stdin-once. it's old, it's tired, but it still works.
  • -p value β€” sets the work parameter p to value. if -p is set, --logN and -r must also be set. and again β€” if such explicit parameters are given, the resource limits set by -M, -m, and -t are not enforced.
  • --passphrase method:arg β€” read the passphrase using the specified method. here's the menu, pick your fighter:
    • dev:tty-stdin β€” attempt to read the passphrase from /dev/tty; if that fails, read it from stdin. this is the default behaviour, so this is the one you're already living in πŸ’–
    • dev:stdin-once β€” attempt to read the passphrase from stdin, and do so only once even when encrypting. this cannot be used if infile is also stdin (aka '-'). nope, not allowed, they can't both have the mic.
    • dev:tty-once β€” attempt to read the passphrase from /dev/tty, and do so only once even when encrypting.
    • env:VAR β€” read the passphrase from the environment variable specified by VAR.
⚠️ storing a passphrase in an environment variable may be a security risk. only use this option if you are certain that you know what you are doing. fr fr, be careful.
  • file:FILENAME β€” read the passphrase from the file specified by FILENAME.
⚠️ storing a passphrase in a file may be a security risk. only use this option if you are certain that you know what you are doing. same energy, same warning, same please-be-safe.
  • -r value β€” sets the work parameter r to value. if -r is set, --logN and -p must also be set. and yes, one more time for the people in the back: if such explicit parameters are given, the resource limits set by -M, -m, and -t are not enforced.
  • -t maxtime β€” use at most maxtime seconds of CPU time to compute the derived encryption key. time is money and also time is CPU.
  • -v β€” print encryption parameters (N, r, p) and memory/cpu limits. the receipts, basically 🧾
  • --version β€” print version of scrypt, and exit. short, sweet, iconic.

and now the important part, so listen up πŸ‘‘

In scrypt enc, the memory and CPU time limits are enforced by picking appropriate parameters to the scrypt key derivation function.

In scrypt dec, the memory and CPU time limits are enforced by exiting with an error if decrypting the file would require too much memory or CPU time. it will not just power through. it will stop you. for your own good.


πŸ’€ EXIT STATUS πŸ’€

the scrypt utility exits 0 on success, and >0 if an error occurs.

😭 okay so this next bit is important: if the input encrypted file is corrupted, scrypt dec may produce output prior to determining that the input was corrupt and exiting with a non-zero status. so bestie, please direct the output to a safe location and check the exit status of scrypt before using the decrypted data. do not trust the vibes alone on this one.

🌈 ALGORITHM PARAMETERS 🌈

the scrypt algorithm has three tuneable work parameters: N, r, p.

when decrypting, scrypt will always use the values specified by the encryption header. it's not guessing, it's reading the receipt.

when encrypting, scrypt will choose appropriate values based on your system's speed and memory (influenced by -M, -m, and/or -t), unless you specify explicit parameters via --logN, -p, -r.


πŸ“š SEE ALSO πŸ“š

  • Colin Percival, Stronger Key Derivation via Sequential Memory-Hard Functions, BSDCan'09, May 2009.
  • Colin Percival and Simon Josefsson, The scrypt Password-Based Key Derivation Function, IETF RFC 7914, August 2016.

πŸ•°οΈ HISTORY πŸ•°οΈ

the scrypt utility was written in May 2009 by Colin Percival as a demonstration of the scrypt key derivation function.

the scrypt key derivation function was invented in March 2009 by Colin Percival in order to allow key files from the Tarsnap backup system to be passphrase protected. so like, the whole thing exists because of a backup system needing a glow-up. we love an origin story πŸ’œ


and that's the whole page bestie!! this one's from Debian, dated @DATE@, and it's page SCRYPT(1) of the manual πŸ’…βœ¨ go encrypt something, check your exit status, and stay safe out there 🫢

πŸ“¦ where this page comes from