Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 17 Oct 2014 22:21:13 +0200 (CEST)
From: Dhiru Kholia <>
Subject: Re: Some format ssh and ssh-ng issues/questions

On Fri, 17 Oct 2014, Frank Dittrich wrote:


> According to doc/README.ssh, both formats (ssh and ssh-ng) support
> cracking passwords of ssh private key files.
> But for some reason, their corresponding converters, ssh2john and
>, produce different hashes.
> None of these 2 formats can process the other format's hashes.
> Why is this necessary? Can't both formats use the same canonical hash
> representation?  Does extract some information from the
> private key file which ssh2john ignores?  Or does ssh2john extract
> more information from the private key file than  (When
> I ran ssh2john and on the same input file, the hash
> representation generated by ssh2john is longer than the
> one.)

See "../run/" utility.

> While the ssh format does not emit false positives, sshng does.  Why
> that? If sshng currently produces just a view false positives, it
> should be able to easily process the complete logic for those
> candidates, without a significant drop in the c/s rate.

No one has observed such false positives, yet.

> If ssh-ng can't do that, because doesn't extract all the
> required information from the key file, isn't that an indication that
> ssh-ng needs to be fixed?

The new format has all the information to get rid of the false positives
*but* someone needs to write the required code.

I don't want to sine I am planning to rewrite "ssh-ng" in a much simpler

> Apparently, ssh-ng needs additional 20 seconds before the real cracking
> starts, because the status line reports just 10 seconds of run time.
> So, you'd need some longer sessions, before ssh-ng with the reported c/s
> rate of 4421K catches up with ssh (reported c/s rate 3051K).

> Apparently, cipher 2 has been added (just to ssh-ng) with this commit:
> commit da8f1dfcc35e41c52ff28428e9ffd6f65e34eafd
> How to I generate such a private key?

IIRC, this was linked from the original feature request ticket on GitHub.

Yes, "bcrypt pbkdf" is to be blamed for such speeds ;)

> (bleeding-jumbo)run $ file test-ecdsa
> test-ecdsa: PEM EC private key
> (bleeding-jumbo)run $ ./ test-ecdsa
> test-ecdsa is not a valid private key file
> (bleeding-jumbo)run $ ./ssh2john test-ecdsa
> *** Error in `./ssh2john': double free or corruption (fasttop):

> So, while just doesn't recognize this file as a valid
> private key file, ssh2john just crashes. May be escda isn't important
> enough to be supported, but at least ssh2john shouldn't crash.

Good catch. I will write a quick fix for this "ssh2john" crash.

I will try adding ecdsa support to but I need another
rainy weekend. Thanks for the extensive testing, Frank!


Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.