Increase maximum value of the p cmdline parameter

[matjon]

The upper limit of the value of the -p cmdline parameter is 32, which is relatively low. Currently, hashing with logN=20, r=8 and p=32 takes around 90s on my slow CPU (Intel i3-7020U).

This is in contrast to the --logN parameter, which can be set up to 40, which corresponds to 1TB of RAM. Additionally, the program will automatically pick high values of p when given high values of the -t (maxtime) parameter.

So allow specifying higher values of the p parameter in cmdline.

[gperciva]

Hmm. Here's some related history, to save reviewers time digging it up themselves:

• Filippo Valsorda suggests leaving p at 1 in https://words.filippo.io/the-scrypt-parameters/; for most uses, it's probably better to increase logN or r. (With logN=20 and r=8, scrypt only requires 1 GB.)

• That said, the bounds in main.c are "somewhat arbitrary" ac00189 (merged in Manually specify scryptenc parameters #249).

• Also, as noted by @matjon, this implementation of scrypt will happily use much larger values of p:

$ ./scrypt enc -v -t 1000 config.h config.enc
Please enter passphrase: 
Please confirm passphrase: 
Parameters used: N = 524288; r = 8; p = 204;
    Decrypting this file requires at least 536 MB of memory (899 MB available),
    and will take approximately 996.0 seconds (limit: 1000.0 seconds).
^C

[cperciva]

Yeah, this is fine. Most people won't need values > 32, but it's ok to make them available.

@gperciva Can you kick the checks to run again so I can merge this?

[gperciva]

I put this PR into #385 so that the actions would run.

(According to my reading of the github docs, we're supposed to have an "Workflow(s) awaiting approval" visible to us admins, but we don't have one. I spent a while looking into this last Sep, but no success.)

[gperciva]

This was merged as #385.