[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 17 Oct 2014 22:21:13 +0200 (CEST)
From: Dhiru Kholia <dhiru.kholia@...il.com>
To: john-users@...ts.openwall.com
Subject: Re: Some format ssh and ssh-ng issues/questions
On Fri, 17 Oct 2014, Frank Dittrich wrote:
Hi!
> 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
> sshng2john.py, 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 sshng2john.py extract some information from the
> private key file which ssh2john ignores? Or does ssh2john extract
> more information from the private key file than sshng2john.py? (When
> I ran ssh2john and sshng2john.py on the same input file, the hash
> representation generated by ssh2john is longer than the sshng2john.py
> one.)
See "../run/ssh2sshng.py" 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 sshng2john.py 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
way.
> 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?
http://www.tedunangst.com/flak/post/new-openssh-key-format-and-bcrypt-pbkdf
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 $ ./sshng2john.py 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 sshng2john.py 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 sshng2john.py but I need another
rainy weekend. Thanks for the extensive testing, Frank!
Dhiru
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.
