Solar Designer

I tentatively labeled this issue "enhancement", but for that we need to describe the desired behavior - I guess it'd be consistent rejection of any over-long inputs? As it is,...

Thanks, @exploide. This is a nasty issue. I added `print(kdf_params)` into `pem2john.py`, and here's what I see for your key above: ``` OrderedDict([('salt', b'\x0e\x8c:\x1c\xdd\xbcw\x90'), ('iteration_count', 2048), ('key_length', None), ('prf', OrderedDict([('algorithm',...

@exploide This is your opportunity to become familiar with the C and maybe the OpenCL code base, so that you'd be able to contribute more in the future. ;-)

@reinistihovs No, and no. You want to contribute a fix? Initially, and that's pretty easy, we need JtR to correctly refuse to process the unsupported inputs. Adding the support would...

@reinistihovs Hey, that's interesting. I thought it'd require a bit more than that - e.g., also updating the hash size somewhere. Have you got the OpenCL format to work as...

@reinistihovs OK, we'll take this from here. Your success so far is encouraging.

> is the first step implementing a check in JtR and refuse to process if it's sha256? Yes. You can do it in two ways/steps: 1. Minimal initial: Have `pem2john.py`...

> Is the encoding for output that is not `sha1` already implemented? No, but it should be the same as for `sha1` except that it'd need to indicate that it's...

> Is `640` the expected ciphertext length for sha1? If yes, I would love to know why. No, there isn't an "expected ciphertext length for sha1". 640 is a possible...

The recent PR said it "partially fixes" this issue, but GitHub doesn't parse the word "partially", so it closed the issue. I'll reopen for us to remember to fix the...