I haven't found information about building this library for the ARM platform. How can I do it?

Debian release version 1.16 seems to error out if there is not enough memory available to decrypt a file. From what I understand, it should be possible to do the decryption, albeit slower.

The scrypt-kdf.h header does not wrap the function using extern "C", which leads to linking issues "undefined reference" in C++ applications. A workaround is to wrap the #include <scrypt-kdf.h> line inside extern "C" as explained by #224, which is a bit annoying.

It would be better to do this directly inside the scrypt-kdf.h file instead.

Seems like the paragraph about "Using scrypt as a KDF" on the website was written before libscrypt-kdf: It suggests the header is crypto_scrypt.h and the function crypto_scrypt(). I believe this should be scrypt-kdf.h and scrypt_kdf() respectively?

I'm using 6.0.1 running on the docker image node:0.12.12-wheezy (node 12.12 on debian wheezy). This setup worked before the update to 6 and the API change, and it works still now running on OSX, but it fails in this container.

take a look at the lib/crypto/crypto_enc.h header

That should be lib/crypto/crypto_scrypt.h, I think?

Install 1.2.1 on linux mint 19.1 fails on "checking for library containing AES_encrypt".

~/download/scrypt-1.2.1$ ./configure
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking for style of include used by make... GNU
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking whether gcc understands -c and -o together... yes
checking dependency style of gcc... gcc3
checking for gcc option to accept ISO C99... none needed
checking for ranlib... ranlib
checking for ar... ar
checking the archiver (ar) interface... ar
checking whether to enable maintainer-specific portions of Makefiles... no
checking for library containing clock_gettime... none required
checking for clock_gettime... yes
checking for library containing AES_encrypt... no
configure: error: function AES_ENCRYPT not found

So crypto_scrypt() is careful to always use uint8_t, whereas test/main.c uses char.

I can sprinkle a bunch of (uint_t*) in test/main.c, but then strlen() isn't happy with the result. Technically, char isn't guaranteed to be uint8_t, so I'm not certain about the most portable way to fix this. I suppose we could add the string lengths (hard-coded) into static struct scrypt_test, but that feels like a hack.

td@gin: ~/src/scrypt/test (compile-tests)
$ clang --version
Ubuntu clang version 3.4-1ubuntu3 (tags/RELEASE_34/final) (based on LLVM 3.4)
Target: x86_64-pc-linux-gnu
Thread model: posix
td@gin: ~/src/scrypt/test (compile-tests)
$ CC=clang bmake
clang -O2 -Wno-error -I .. -DCONFIG_H_FILE=\"config_freebsd.h\" -I ../libcperciva/alg -I ../libcperciva/cpusupport -I ../lib/crypto -I ../libcperciva/util -I . -D CPUSUPPORT_CONFIG_FILE=\"cpusupport-config.h\"  -Wall -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wreturn-type -Wcast-qual -Wpointer-arith -Wwrite-strings -Wswitch -Wshadow -Werror   -c main.c
main.c:35:17: error: passing 'const char *' to parameter of type
      'const uint8_t *' (aka 'const unsigned char *') converts between pointers
      to integer types with different sign [-Werror,-Wpointer-sign]
                crypto_scrypt(test->passwd, strlen(test->passwd),
                              ^~~~~~~~~~~~
../lib/crypto/crypto_scrypt.h:44:34: note: passing argument to parameter here
int crypto_scrypt(const uint8_t *, size_t, const uint8_t *, size_t, uint64_t,
                                 ^
main.c:36:7: error: passing 'const char *' to parameter of type
      'const uint8_t *' (aka 'const unsigned char *') converts between pointers
      to integer types with different sign [-Werror,-Wpointer-sign]
                    test->salt, strlen(test->salt),
                    ^~~~~~~~~~
../lib/crypto/crypto_scrypt.h:44:59: note: passing argument to parameter here
int crypto_scrypt(const uint8_t *, size_t, const uint8_t *, size_t, uint64_t,
                                                          ^
main.c:37:34: error: passing 'char [64]' to parameter of type 'uint8_t *'
      (aka 'unsigned char *') converts between pointers to integer types with
      different sign [-Werror,-Wpointer-sign]
                    test->N, test->r, test->p, kbuf, 64);
                                               ^~~~
../lib/crypto/crypto_scrypt.h:45:34: note: passing argument to parameter here
    uint32_t, uint32_t, uint8_t *, size_t);
                                 ^
3 errors generated.
*** Error code 1

Stop.
bmake: stopped in /home/td/src/scrypt/test

"common wisdom" (such as https://godoc.org/golang.org/x/crypto/scrypt) says:

The recommended parameters for interactive logins as of 2009 are N=16384, r=8, p=1.
They should be increased as memory latency and CPU parallelism increases.

Since it's been 6 years, it would be helpful to make a new recommendation (which I'll then put on the website, of course). I mean, non-cryptographers won't have any clue whether they should double N, r, or p, or all of them, or...?

the "usage" doesn't give any hint that there's more options available.

How can I specify the passphrase with an automated script? Assume I have an ENVAR set $SCRYPT_PASSPHRASE.

Tried:

scrypt enc -P foo.tar foo.tar.scrypt | echo $SCRYPT_PASSPHRASE

OpenSSL is required for the build of scrypt, configure should check for its availability to avoid build errors such as:

libcperciva/crypto/crypto_aes.c:6:10: fatal error: 'openssl/aes.h' file not found
#include <openssl/aes.h>

After building scrypt, what header file do I have to include to use scrypt for hashing?

Hi,

Trying to update scrypt from git source and compile, but it's failing:

ibcperciva/crypto/crypto_entropy.o: In function `cpusupport_x86_rdrand':
./libcperciva/cpusupport/cpusupport.h:107: undefined reference to `cpusupport_x86_rdrand_present_1'
libcperciva/crypto/crypto_entropy.o: In function `update_from_rdrand':
libcperciva/crypto/crypto_entropy.c:48: undefined reference to `generate_seed_rdrand'
libcperciva/crypto/crypto_entropy.o: In function `cpusupport_x86_rdrand':
./libcperciva/cpusupport/cpusupport.h:107: undefined reference to `cpusupport_x86_rdrand_init_1'
./libcperciva/cpusupport/cpusupport.h:107: undefined reference to `cpusupport_x86_rdrand_detect_1'
./libcperciva/cpusupport/cpusupport.h:107: undefined reference to `cpusupport_x86_rdrand_present_1'
./libcperciva/cpusupport/cpusupport.h:107: undefined reference to `cpusupport_x86_rdrand_init_1'
./libcperciva/cpusupport/cpusupport.h:107: undefined reference to `cpusupport_x86_rdrand_present_1'
libcperciva/crypto/crypto_entropy.o: In function `update_from_rdrand':
libcperciva/crypto/crypto_entropy.c:48: undefined reference to `generate_seed_rdrand'
libcperciva/crypto/crypto_entropy.o: In function `cpusupport_x86_rdrand':
./libcperciva/cpusupport/cpusupport.h:107: undefined reference to `cpusupport_x86_rdrand_init_1'
./libcperciva/cpusupport/cpusupport.h:107: undefined reference to `cpusupport_x86_rdrand_detect_1'
clang: error: linker command failed with exit code 1 (use -v to see invocation)
*** Error 1 in . (Makefile:673 'scrypt')
*** Error 1 in /home/sean/bin/scrypt (Makefile:468 'all')

config output: https://ptpb.pw/OqQB

(This question applies both to scrypt enc / scrypt dec utility, but also to the scrypt algorithm.)

I've made a small experiment with strace and I've seen that scrypt enc does not use mlock to lock its memory into RAM and not risk spilling it to swap.

Therefore I wanted to ask:

• is scrypt enc using another protection to prevent swap leakage, especially for the password and derived key?
• (this applies mostly to scrypt algorithm) what is the impact (in terms of password guessing) if the "temporary derivation memory" (i.e. the one governed by the N parameter) is leaked to (unencrypted) swap and then recovered by an attacker, can he use that to deduce the password?

Hi,

If I strip the first 16-bytes from an encrypted file, i.e. magic string + parameters, the remaining bytes should be indistinguishable from random data, is that correct?

If I don't control control the parameters (version <= 1.3.0), the missing 16-bytes should be easily brute-forced using the header checksum?

Thanks,
Mikael

Hi,
I am thinking about using scryptenc_buf/scryptdec_buf to store my app's
private keys on the device. There are "KeyStore" mechanisms available on
both on Android[1] and iOS[2] etc but they are different beasts with the
need for device specific solutions for each.

It would be ideal to use NaCl[3] for the pk crypto and then use
scryptenc_buf/scryptdec_buf to store the private key on the device.

The same solution could then be used on all type of devices with all the
benefits which comes with NaCl and scrypt.

The native "KeyStore" mechanisms in iOS and Android comes with their own
pros of course.

Is this a lame idea? Anyone?

Cheers
/Joakim

[1] https://developer.android.com/training/articles/keystore.html
[2] https://developer.apple.com/library/content/documentation/Security/Conceptual/keychainServConcepts/iPhoneTasks/iPhoneTasks.html
[3] https://nacl.cr.yp.to/box.html

Hey guys,

What's up with GPG keys for Scrypt on your official website here: https://www.tarsnap.com/scrypt.html ?

gpg2 --verify scrypt-sigs-1.2.1.asc scrypt-1.2.1.tgz 
gpg: not a detached signature

gpg2 --verify tarsnap-signing-key-2017.asc scrypt-1.2.1.tgz 
gpg: verify signatures failed: Unexpected error

When I type

$ scrypt enc -M 1073741824 -t 500 secret.txt encrypted.txt.scrypt

it takes about 2-3 minutes instead of 500 seconds on my computer.

I consider this a bug.

I am using Ubutnu, version of the scrypt utility is 1.2.0-1.

$ sudo dpkg --list 'scrypt*'
...
ii  scrypt         1.2.0-1      amd64        File encryption utility using scr

$ uname -a
Linux computer 4.4.0-128-generic #154-Ubuntu SMP Fri May 25 14:15:18 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

I tested decryption too, the time is not correct (less than 500 seconds).

$ scrypt dec encrypted.txt.scrypt decrypted.txt -t 500

Thanks for a very nice library and support for it.

I'm using the scrypt 1.2.1 tarball. I'm working on Fedora 28 x86_64. I configure with:

$ PKG_CONFIG_PATH=/usr/local/lib64/pkgconfig/ ./configure
configure: loading site script /usr/local/share/config.site
checking for a BSD-compatible install... /usr/local/bin/install -c
checking whether build environment is sane... yes
...

And build with the same:

$ PKG_CONFIG_PATH=/usr/local/lib64/pkgconfig/ make -j 3
( export CC="gcc"; export CFLAGS="-g -O2 -Wall"; command -p sh ./libcperciva/cpusupport/Build/cpusupport.sh "$PATH") > cpusupport-config.h.tmp && command -p mv cpusupport-config.h.tmp cpusupport-config.h
Checking if compiler supports X86 CPUID feature... yes
Checking if compiler supports X86 SSE2 feature... yes
Checking if compiler supports X86 AESNI feature... yes, via -maes
...

When I attempt to run the self tests it results in:

$ make test
make  all-am
make[1]: Entering directory '/home/scrypt-1.2.1'
make[1]: Leaving directory '/home/scrypt-1.2.1'
./tests/test_scrypt.sh .
System scrypt not found.
Running tests
-------------
  01-known-values... ./tests/test_scrypt: error while loading shared libraries: libcrypto.so.1.0.0: cannot open shared object file: No such file or directory
FAILED!
make: *** [Makefile:1212: test] Error 127

libcrypto.so.1.0.0 is present:

$ find /usr/local -name 'libcrypto.so.1.0.0'
/usr/local/lib64/libcrypto.so.1.0.0

Autotools is supposed to configure these things but it takes a little extra work. (It would be nice if Autotools did its job without pushing the work onto the package maintainer. Don't hold your breath...).

It might be a good idea if scrypt either statically linked to the libraries it requires or used rpaths to locate the libraries it compiled and linked against.

According to the Coreutils folks, rpaths are the way to go. Also see FAIL: test-rwlock1 on 32-bit ARM on the Coreutils mailing list. It shows a set of configure options that would avoid the problems. I tried to manually add the options but configure failed to configure things. Also see Breaking the links: Exploiting the linker.

If you want to statically link to avoid the failed self tests, then consider using -l:libcrypto.a. The colon tell the linker to find that exact filename, so the linker won't use a shared object that can be subverted later through injections.

Here is config.log: config.log.zip

We currently ignore RLIMIT_DATA if we HAVE_MMAP:
2b478e7

This breaks the memory-detection on OpenBSD. I added some zzz lines, and compiled with -DDEBUG, and we see:

openbsd-64$ ulimit -d 123456
openbsd-64$ ./scrypt dec -v foo.enc foo                                        
Please enter passphrase: 
zzz             RLIMIT_DATA:    126418944
zzz                     (the above line is for debugging only
zzz             RLIMIT_RSS:     2055184384
Memory limits are:
        usermem:        18446744073709551615
        memsize:        18446744073709551615
        sysinfo:        18446744073709551615
        rlimit:         2055184384
        sysconf:        2130640896
zzz smallest:           2055184384
zzz after frac:         1027592192
zzz after specified:    1027592192
Allowing up to 1027592192 memory to be used
Clock resolution is 0.01
17408 salsa20/8 cores performed in 0.010059 seconds
Parameters used: N = 131072; r = 8; p = 4;
    This requires at least 134 MB bytes of memory (1.0 GB available),
    and will take approximately 1.2 seconds (limit: 300.0 seconds).
scrypt: ../main.c, 252
scrypt: Error computing derived key: Cannot allocate memory
openbsd-64$ 

TL;DR: scrypt thinks it has enough memory available, but it doesn't.

Have tried changing the node/npm version still getting the same error, this was installing properly on local environment, but not on Azure web app.

Please help.

[email protected] preinstall D:\home\site\wwwroot\node_modules\scrypt
node node-scrypt-preinstall.js

[email protected] install D:\home\site\wwwroot\node_modules\scrypt
node-gyp rebuild

D:\home\site\wwwroot\node_modules\scrypt>if not defined npm_config_node_gyp (node "D:\Program Files (x86)\npm\5.6.0\node_modules\npm\node_modules\npm-lifecycle\node-gyp-bin\....\node_modules\node-gyp\bin\node-gyp.js" rebuild ) else (node "D:\Program Files (x86)\npm\5.6.0\node_modules\npm\node_modules\node-gyp\bin\node-gyp.js" rebuild )
Warning: Missing input files:
D:\home\site\wwwroot\node_modules\scrypt\build..\scrypt\win\include\config.h
Building the projects in this solution one at a time. To enable parallel build, please add the "/m" switch.
D:\home\site\wwwroot\node_modules\scrypt\build\copied_files.vcxproj(20,3): error MSB4019: The imported project "D:\Microsoft.Cpp.Default.props" was not found. Confirm that the path in the declaration is correct, and that the file exists on disk.
D:\home\site\wwwroot\node_modules\scrypt\build\scrypt_wrapper.vcxproj(20,3): error MSB4019: The imported project "D:\Microsoft.Cpp.Default.props" was not found. Confirm that the path in the declaration is correct, and that the file exists on disk.
gyp ERR! build error
gyp ERR! stack Error: D:\Program Files (x86)\MSBuild\14.0\bin\msbuild.exe failed with exit code: 1
gyp ERR! stack at ChildProcess.onExit (D:\Program Files (x86)\npm\5.6.0\node_modules\npm\node_modules\node-gyp\lib\build.js:258:23)
gyp ERR! stack at emitTwo (events.js:126:13)
gyp ERR! stack at ChildProcess.emit (events.js:214:7)
gyp ERR! stack at Process.ChildProcess._handle.onexit (internal/child_process.js:198:12)
gyp ERR! System Windows_NT 10.0.14393
gyp ERR! command "D:\Program Files (x86)\nodejs\8.11.1\node.exe" "D:\Program Files (x86)\npm\5.6.0\node_modules\npm\node_modules\node-gyp\bin\node-gyp.js" "rebuild"
gyp ERR! cwd D:\home\site\wwwroot\node_modules\scrypt
gyp ERR! node -v v8.11.1
gyp ERR! node-gyp -v v3.6.2
gyp ERR! not ok
�[37;40mnpm �[30;43mWARN [email protected] No repository field.

�[37;40mnpm �[31;40mERR! code ELIFECYCLE
�[37;40mnpm �[31;40mERR! errno 1
�[37;40mnpm �[31;40mERR! [email protected] install: node-gyp rebuild
�[37;40mnpm �[31;40mERR! Exit status 1
�[37;40mnpm �[31;40mERR!
�[37;40mnpm �[31;40mERR! Failed at the [email protected] install script.
�[37;40mnpm �[31;40mERR! This is probably not a problem with npm. There is likely additional logging output above.

�[37;40mnpm �[31;40mERR! A complete log of this run can be found in:
�[37;40mnpm �[31;40mERR! D:\local\Temp\monacositeextension\temp_logs\2018-05-16T10_51_59_087Z-debug.log

This is with version 1.2.1. A failed decryption creates an empty output file.

$ scrypt dec /dev/null foo-dec
Please enter passphrase: 
scrypt: Input is not valid scrypt-encrypted block
$ ls -l foo*
-rw-rw-r-- 1 barak barak 0 Feb 23 17:12 foo-dec

This also happens when decrypting a valid file with the wrong passphrase.

Currently building on macOS terminates with:

...
gcc  -I/opt/local/include  -L/opt/local/lib -o scrypt main.o libcperciva/alg/sha256.o libcperciva/cpusupport/cpusupport_x86_aesni.o libcperciva/cpusupport/cpusupport_x86_sse2.o libcperciva/crypto/crypto_aes.o libcperciva/crypto/crypto_aesctr.o libcperciva/crypto/crypto_entropy.
o libcperciva/util/asprintf.o libcperciva/util/entropy.o libcperciva/util/getopt.o libcperciva/util/humansize.o libcperciva/util/insecure_memzero.o libcperciva/util/readpass.o libcperciva/util/warnp.o lib/crypto/crypto_scrypt.o lib/crypto/crypto_scrypt_smix.o lib/scryptenc/scry
ptenc.o lib/scryptenc/scryptenc_cpuperf.o lib/util/memlimit.o libcperciva_aesni.a libscrypt_sse2.a -lcrypto
Undefined symbols for architecture x86_64:
  "_cpusupport_x86_rdrand_detect_1", referenced from:
      _cpusupport_x86_rdrand in crypto_entropy.o
  "_cpusupport_x86_rdrand_init_1", referenced from:
      _cpusupport_x86_rdrand in crypto_entropy.o
  "_cpusupport_x86_rdrand_present_1", referenced from:
      _cpusupport_x86_rdrand in crypto_entropy.o
  "_generate_seed_rdrand", referenced from:
      _update_from_rdrand in crypto_entropy.o
ld: symbol(s) not found for architecture x86_64

This is with version 1.0.2r_0 of OpenSSL installed via Macports on (obviously) x86-64. Bisecting leads us to commit 509f0fa. Are macOS builds officially supported? I've never had any problems with scrypt on macOS in the past. Some further OS info below...

$ uname -mnrsv
Darwin 17.7.0 Darwin Kernel Version 17.7.0: Wed Feb 27 00:43:23 PST 2019; root:xnu-4570.71.35~1/RELEASE_X86_64 x86_64
$ sysctl -a | grep '^machdep\.cpu\..*features'
machdep.cpu.features: FPU VME DE PSE TSC MSR PAE MCE CX8 APIC SEP MTRR PGE MCA CMOV PAT PSE36 CLFSH DS ACPI MMX FXSR SSE SSE2 SS HTT TM PBE SSE3 PCLMULQDQ DTES64 MON DSCPL VMX SMX EST TM2 SSSE3 FMA CX16 TPR PDCM SSE4.1 SSE4.2 x2APIC MOVBE POPCNT AES PCID XSAVE OSXSAVE SEGLIM64 TSCTMR AVX1.0 RDRAND F16C
machdep.cpu.leaf7_features: SMEP ERMS RDWRFSGS TSC_THREAD_OFFSET BMI1 HLE AVX2 BMI2 INVPCID RTM SMAP RDSEED ADX IPT SGX FPU_CSDS MPX CLFSOPT
machdep.cpu.extfeatures: SYSCALL XD 1GBPAGE EM64T LAHF LZCNT PREFETCHW RDTSCP TSCI

The recently-added CHECK_POSIX_SH [1] uses command -v. This is widely accepted as the proper answer to "how do I portably check if a command exists" [2], and has been part of our make test since 2016-04-23 [3].

However, -v only became mandatory in issue 7; previously, it was a [UP] User Portability Utilities option [4]. The debian posh shell does not support it, for example. Solaris is inconsistent between the shell built-in command, /usr/bin/command, the man-page, and /usr/xpg4/bin/command (the latter one is fully compatible with POSIX issue 7, as far as I can tell).

I'm still investigating, but thought that I should document the issue.

[1] abb7241
[2] https://stackoverflow.com/a/677212
[3] 4dc4eeb
[4] https://pubs.opengroup.org/onlinepubs/009695399/utilities/command.html

http://google-opensource.blogspot.ca/2015/03/farewell-to-google-code.html

Google Code is shutting down.  Please move the official libscrypt repository to 
a reliable location such as GitHub and update this issue with the new official 
repo.

Original issue reported on code.google.com by [email protected] on 24 Mar 2015 at 2:09

https://github.com/Tarsnap/scrypt/blob/master/FORMAT

With CTR mode and 128-bit block size, the file size limit is about 64 GB for the same IV.

Was the decision to use CTR done deliberately, because you reckoned that most people will encrypt less than 64 GB?

Just wondering, and should the scrypt command line tool warn before encrypting larger files than 64 GB?

scrypt enc --logN 20 -p 1 -r 8 -v -- test test.scrypt

Please enter passphrase:
Please confirm passphrase:
Parameters used: N = 1048576; r = 8; p = 1;
Decrypting this file requires at least 1.0 GB bytes of memory (1.1 GB available),
and will take approximately 0.3 seconds (limit: 5.0 seconds).

scrypt enc --logN 21 -p 1 -r 8 -v -- test test.scrypt

Please enter passphrase:
Please confirm passphrase:
scrypt: Warning: Explicit parameters might exceed memory limit

P.S. There is a typo in the man page for the verbose option --v (double-dash) not -v.

I literally want to be able to use this in a C++ project and I'm finding it very difficult.
I'm new to C++ and if this was documented that would be really nice! Thanks.

Hi,

I had a little scare yesterday trying to decrypt backups on my home server. Every attempt resulted in a "Decrypting file would require too much memory".

Here is the output from top:

last pid: 53207; load averages: 0.25, 0.18, 0.13 up 20+23:19:18 14:35:06
54 processes: 1 running, 53 sleeping
CPU: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle
Mem: 19M Active, 258M Inact, 23M Laundry, 14G Wired, 774M Free
ARC: 13G Total, 11G MFU, 664M MRU, 32K Anon, 70M Header, 477M Other
12G Compressed, 13G Uncompressed, 1.14:1 Ratio
Swap: 4096M Total, 85M Used, 4011M Free, 2% Inuse

ZFS ARC is using almost all available memory, but most of this memory should be available to other processes when needed.

I found the "force" option for decryption but if I encrypt a file under these conditions wouldn't scrypt pick less than ideal memory parameters?

Thanks,
Mikael

Hi,
I have batch script that used to call Scrypt in a pileline in this way:

1. { echo "$PASS" ; cat file_to_decrypt ; } | scrypt dec -P -
2. { echo "$PASS" ; cat file_to_encrypt ; } | scrypt enc -P -

With the new version of Scrypt I get the error:
scrypt: Cannot read both passphrase and input file from standard input

Is there an alternative way to pass the password, for example from an environment variable or from a file?
If not, is it possible enable the old way to pass the password?

It would be nice if there was a -v option that showed the parameters and/or memory/cpu settings chosen when scrypting a file.

Hello,

I'm attempting to install scrypt on my openbsd machine but it fails during autoreconf process.

git clone https://github.com/Tarsnap/scrypt
cd scrypt
autoreconf -i

Output:

aclocal:configure.ac:12: warning: macro `AM_PROG_AR' not found in library
configure.ac:12: error: possibly undefined macro: AM_PROG_AR
      If this token and others are legitimate, please use m4_pattern_allow.
      See the Autoconf documentation.
autoreconf-2.69: /usr/local/bin/autoconf-2.69 failed with exit status: 1

I have these installed: automake-1.9, autoconf-2.69 and libtool version 1.5.26. Do I need something more?

Any pointers would be greatly appreciated!

This issue was found by automated checks on the R-package scrypt which I maintain. That package is based on scrypt 1.1.6 but I believe the issue could still be present in the current version of scrypt. The offending block in _SHA256_Update() is:

/* Handle the case where we don't need to perform any transforms. */
if (len < 64 - r) {
    memcpy(&ctx->buf[r], src, len);
    return;
}

The function scryptenc_cpuperf() has the following call:

crypto_scrypt(NULL, 0, NULL, 0, 16, 1, 1, NULL, 0)

where the third argument represents the salt. crypto_scrypt() passes the salt to PBKDF2_SHA256() which passes to _HMAC_SHA256_Update(), to _SHA256_Update() which then goes by the name src.

Linux and glibc marked <sys/sysctrl.h> as deprecated, so we've been treated to warnings like:

/usr/include/aarch64-linux-gnu/sys/sysctl.h:21:2: warning: #warning "The <sys/sysctl.h> header is deprecated and will be removed." [-Wcpp]
   21 | #warning "The <sys/sysctl.h> header is deprecated and will be removed."
      |  ^~~~~~~

This is completely harmless for scrypt, as memlimit.c checks multiple methods of getting the available memory, and uses the lowest one. If autoconf's AC_CHECK_HEADER could take an extra parameter saying "only mark this header as avilable if it compiles without any warnings", I'd gladly enable that, but unfortunately there's no such option [1].

Incidently, the sysctl() function was removed in glibc 2.32 (2020-08-06). The binary symbol is still present, but will always return ENOSYS [2].

[1] https://www.gnu.org/software/autoconf/manual/autoconf-2.61/html_node/Generic-Headers.html
[2] https://sourceware.org/pipermail/libc-announce/2020/000029.html

I'm going to close this issue immediately; it's just here in case somebody wonders about these warnings and searches the github issues.

Hi,
i would like to use scrypt in a CICD pipeline. and the current mechanism would need stuff like expect. Is there a possibility, that a password can be used from the process environment or from a certain file which name can be shown via parameter to scrypt?

That would be really helpful.

lib/util/memlimit.c:78:14: error: cast from 'uint8_t *' (aka 'unsigned char *') 
to 'uint64_t *' (aka 'unsigned long long *') increases required alignment from 
1 to 8
      [-Werror,-Wcast-align]

Original issue reported on code.google.com by [email protected] on 2 May 2014 at 3:52

On OS X 10.10.5, _SC_PHYS_PAGES is defined to 200, but sysconf(_SC_PHYS_PAGES) returns -1 / EINVAL.

We should work around this bogosity in memlimit_sysconf. (And then merge to tarsnap.)

Hi,
I have written an implementation of Scrypt and added it to a C++ library I am writing:
https://github.com/Steppenwolfe65/CEX
Some of the highlights; uses 128/256 simd for xor's, the smix function is (optionally) multi-threaded, has sequential fallbacks, and simd and multi-threading capabilities are run-time checked/enabled automatically.
One problem I had was getting the salsa8 simd function to align with the sequential fallback version. I am guessing that integers are transposed somehow before they are added to simd integers, and I tried a few different things but could not get it to align with the sequential salsa function. Any help on this would be appreciated, code is in the cpp file:
https://github.com/Steppenwolfe65/CEX/blob/master/CEX/SCRYPT.cpp

Now for the question.. I am using the parameters of 16384, 8, 1 as defaults, but I would like to add an option whereby the user can set the parameters via an enumeration (ex. low/med/high security), any advice on what those parameters should be given the state of today's computing power (low-medium), vs the expectation of computing power in 10 years (high setting).

Thanks,
John

While I can't think of a scenario where an attacker would actually be able to exploit this, memcmp should never be used to compare message digests and should be replaced with a time-constant comparison function:
https://github.com/Tarsnap/scrypt/blob/master/lib/scryptenc/scryptenc.c#L312
Also lines 291, 449 and 742.

Apologies if there's a good reason for not doing this, I'm not much of a C interface programmer.

I'm currently writing a Haskell wrapper around libscrypt-kdf which calls out to scrypt_kdf. The library works great - but I was beating my head against a wall trying to figure out linking errors from binding to (what I thought was) the scrypt_kdf function. It was only after checking the library symbols, and reading the code that I realised that scrypt_kdf only exists for the purpose of the header, and my code had to bind to crypto_scrypt.

I assume this symbol is stable, and I could manually write a binding to it that wouldn't break on new versions of scrypt - but I wanted to use the API the "right" way, with the define. Luckily, Haskell has support for relying on C preprocessor directives, and my code can do that. But in general, I think that would be painful. Could scrypt_kdf be somehow promoted to being a proper symbol in libscrypt-kdf to simplify linking for FFIs in the future?

There is a lot of information about what scrypt parameters are recommended at a given time for a given level of security, but there is no easy way to specify these parameters in the command line. I can specify maxmem and/or maxtime, but I won't know how safe my data is going to be, because the values of N and p depend on the state of my machine and they even change from one invocation to another (which is very confusing, by the way). Moreover, decryption may happen on a completely different machine, so maxmem and maxtime have limited usefulness anyway.

It would be great if we could simply invoke scrypt like this:
scrypt enc -N1048576 -r8 -p1 secret_file secret_file.scrypt
Or perhaps this notation would be a bit more convenient:
scrypt enc -lgN 20 -r 8 -p 1 secret_file secret_file.scrypt

I am working on a C++ project that requires some hashing.

I included the scrypt header file in my C++ code as follows:

extern "C" { #include "scrypt-kdf.h" }

/* Parameters  controlling memory usage and cpu time --scrypt-kdf */
#define N 16384
#define r 8
#define p 1
#define OUTPUT_BUFLEN 64

I have a function declaration as follows:

int hashPassword(const char* password, const char* salt, uint8_t hashedPasswordOutput[]);

The function definition is as follows:

int hashPassword(const char* password, const char* salt, uint8_t hashedPasswordOutput[]) {
	int exitCode = scrypt_kdf((const uint8_t*)password, strlen(password),
		(const uint8_t*)salt, strlen(salt), N, r, p, hashedPasswordOutput, OUTPUT_BUFLEN);
	
        // Logging
	std::cout << "Password is: " << (const uint8_t*)password << "\n";
	std::cout << "Salt is: " << (const uint8_t*)salt << "\n";
	for (int i = 0; i < OUTPUT_BUFLEN; ++i)
	{
		std::cout << hashedPasswordOutput[i] << "\n";
	}
	std::cout << "Exit code is: " << exitCode << "\n";
	return exitCode;
}

The problem is I am getting some really weird hash. Output is:
HashedPasswordString is: 8���i��/��} Y��GWg�0GNEv��ԥP������ݺLJ5�y\j;ExqZRk�U��������`

See Screenshot below:

### More Details:
I am running the project on docker using the GCC:9.1.0 image.

How do I resolve this to get the right hash? Thanks.

I found this bug when I modified the original code to run on windows.
I have modified fopens to use binary mode in main.c .
Modified main.c is in the attachment.

Original issue reported on code.google.com by [email protected] on 4 Jan 2014 at 12:11

Attachments:

• main.c

It might be worth adding an option to autotools to create and install a libscrypt, along with the relevant headers. I see there's a few projects floating around that do this (including packages for Debian, Ubuntu, homebrew) from third-party.

I am working on a c++ project and included libscrypt-kdf but when linking it throws an error.

I included the header file as follows in my project:

#ifdef __cplusplus extern "C" { #endif #include <string.h> #include "scrypt-kdf.h" #ifdef __cplusplus } #endif

Here is also my hashPassword function:

`int hashPassword(const char* password, const char* salt, uint8_t hashedPasswordOutput[]) {
int exitCode = scrypt_kdf((const uint8_t*)password, strlen(password),
(const uint8_t*)salt, strlen(salt), N, r, p, hashedPasswordOutput, OUTPUT_BUFLEN);

return exitCode;

}`

And finally, here is the error being thrown:

/usr/bin/ld: CMakeFiles/hello_crow.dir/main.cpp.o: in function hashPassword(char const*, char const*, unsigned char*)':
main.cpp:(.text+0x1a0e): undefined reference to crypto_scrypt' collect2: error: ld returned 1 exit status make[2]: *** [CMakeFiles/hello_crow.dir/build.make:88: hello_crow] Error 1 make[1]: *** [CMakeFiles/Makefile2:73: CMakeFiles/hello_crow.dir/all] Error 2 make: *** [Makefile:84: all] Error 2

Here is a screenshot of the error:

Kindly help please. Thanks.

Hi,

The sse2 variant in lib/crypto/crypto_scrypt_smix_sse2.c defines integerify() with what looks like a clear typo:

        const uint32_t * X = (const void *)((uintptr_t)(B) + (2 * r - 1) * 64);
        return (((uint64_t)(X[13]) << 32) + X[0]);

Note the indexing of X[13] which it seems should be X[1] as the intent is to read a u64 from 2 u32's.

I believe the reason this has not been discovered in the wild yet is that the result of this function is always and-ed with (N - 1), and no caller ever passes an N > 2^32 (or if they do, they have not compared the sse2 vs general results).

This also suggests that if callers are willing to limit N beyond its current constraint of 'power of 2 >= 2' to include an upper limit of 2^32, that the return can be reduced to simply X[0] and the shift/add removed.

For any caller desiring interop between 32 and 64 bit platforms, the upper limit of N is in any case (2^32)/128.

It seems like the source code intends to cap memory usage at 50%, however on my system (debian using 1.16 svn 31) executing "scrypt enc -m 1 -t 10000 file" seems to max out at 25% of RAM (top shows 25% under VIRT column).

I did a quick test to comment out the line that limits maxmem to 0.5 and top now shows 50% of RAM used.

Is this behavior expected?

Some systems don't provide getconf. The CHECK_POSIX_SH macro fails on those systems:

It should, at least, behave like a standard macro and allow overriding the vaule from the command line.

IBM claims to operate a 65 qubit quantum computer.
How long would it take to crack a scrypt cipher with this quantum computer right now?
How about the 1000 qubit quantum computer promised by IBM in 2023?