update ssh2john to support all algs from openssh about john HOT 3 OPEN

Thank you @noraj! Is this something you'd like to work on? We'd appreciate a pull request. (Assuming that your analysis here is correct. I did not verify.)

from john.

@solardiz What would you expect? ssh2john supporting all possibilities supported by john only or all possibilities supported by ssh-keygen?

Also, in the light of #4564 and #5255 and many others, wouldn't it be good to separate all the tools from /run in a different repository? It would allow faster release for those tools than JtR slow lifecycle. Also both code are completely independent.

I don't think I'm able to PR, I dont't understand what combination of key size, key type, encryption type, etc. would lead to a hash type and why. Having blocksize in the dict seems useless. It sounds like a partial re-write of the tool would be beneficial. I'm also extremely bad at C so it's hard for me to understand what exactly john is supporting.

from john.

What would you expect? ssh2john supporting all possibilities supported by john only or all possibilities supported by ssh-keygen?

Perhaps first make ssh2john support everything in john. As to the rest, it can also be added - with a separate commit/PR, and perhaps printing a warning that it "may not yet be supported by john" or such.

wouldn't it be good to separate all the tools from /run in a different repository?

This was suggested and I thought of it, and my current opinion is that no - it's better to keep them in here. We do need to release more often and to clean things up, but a separate repo and having to make separate releases isn't the way there.

It sounds like a partial re-write of the tool would be beneficial.

I agree. Perhaps we could get rid of our own numeric cipher types and include the info in "hashes" with less re-processing. However, I have no idea who would do that and when. So adding support for what's missing first is reasonable.

from john.