Increase maximum supported password length

[solardiz]

Our maximum supported password length for any format is currently 125 (with some formats having lower limits for varying reasons). This may be insufficient for cryptocurrency wallet formats using lengthy generated seed phrases (sometimes along with a user-chosen portion), where most of the phrase would be known and only a small portion needing recovery (for full phrase recovery to be feasible).

hashcat's maximum is 256. And it's actually 256, not 255 - the code was adjusted to match what was previously announced: hashcat/hashcat@5da1e4b

Choosing exactly 256 as our maximum feels suboptimal as it means buffers of at least 257 where we need to include the trailing NUL. Yet we could choose this anyway to be same as hashcat with respect to this maximum. We could also choose 259 and buffers of size 260, or even 263/264, since 257 would probably occupy at least this much anyway.

We also need to recall why it ended up 125 rather than 127 now. Do we possibly use this extra room somewhere?

We also need to consider performance impact. Maybe arrays of the larger buffers would cause worse cache utilization, perhaps through impact on cache aliasing and thus requiring greater cache associativity for the same size to fit. Maybe a size that isn't close to a power of 2 would perform better, like IIRC some fast hash formats were previously found to perform best at 95 on older CPUs with 32-byte cache lines. Since 191/192 is too low (too little of an increase and way below hashcat's), maybe consider 319/320?

We still have this in dummy.c:

/* Max 125, but 95 typically produces fewer L1 data cache tag collisions */
#define PLAINTEXT_LENGTH                95
#define MAX_PLAINTEXT_LENGTH            (PLAINTEXT_BUFFER_SIZE - 3) // 125