Need less revealing *2john "hashes" for cryptocoin wallets & encrypted archives

As discussed in #3130:

Ideally, we'd add a way to crack more of these things without such exposures, or mitigating the exposures at least partially. Password recovery for cryptocoin wallets is in demand and a lot of (most?) people who forgot their wallet passwords are not tech-savvy enough to use/tune JtR well, so I wish it were possible for more capable users of JtR to provide this as a service without such risks. (And right now it's risks even to whoever provides the service - they'd be suspected of theft even if they don't steal anything but someone else does, via whatever other means.)

When we use CBC padding to verify successful guesses, perhaps we only need two last blocks? Maybe we could encode only those two, and only decrypt the last one? That would also speed things up a little bit. Now, whether two last blocks of a private key are (enough to recover) the whole key or not will vary (what key size, public key cryptosystem, randomness) - we'd need to also look into this.

For formats where the CBC padding check wouldn't have been the only one, perhaps the corresponding *2john tool should estimate the chance of false positives resulting from making that check the only one - e.g., with 6+ bytes of padding the chance is probably low enough, and with 8+ negligible. The *2john tools can know this and report on it, or choose to output different things (and print different messages accordingly) depending on it.

Start by reviewing the discussion in #3130 and the relevant *2john tools that emit encrypted-wallet and archive data. Examine their current CBC-padding validation and output messages; done means defining and implementing a less revealing output approach while accounting for false-positive risk.