Reverting ssh-keyparse about fgtk HOT 17 CLOSED

I've now (as of 9237ca7) added -d/--patch-key option, which you can use like this:

 ssh-keygen -t ed25519 -N '' -f test-key && ssh-keyparse -d <seed> test-key

...with base64-encoded (as is default) seed value.

Not sure if it's worth adding some --input-encoding option, as it's probably not that common to recover keys, and there're plenty of ways to recode stuff otherwise, e.g. python shell.

from fgtk.

Hey,

You probably mean "ssh-keyparse" not "ssh-keyphrase".

Few times (twice, I think?) I needed to recover key from such seed, just pasted bytes produced by --expand-seed option into existing ed25519 keyfile, which is obviously a bit more complicated than just one command to produce this seed, and I guess option can be added to the script to do that, just didn't bother with it before.

Essentially, what you can do is run ssh-keygen -N '' -t ed25519 -f newkey, grab base64 from there and decode it (e.g. print repr('...'.decode('base64')) in py2 console), spot obvious delimited blob of pseudorandom key in there, replace it with that --expand-seed output, encode thing back and put into file.

Again, obviously not that hard to code into script, might do if I'll have spare dozen minutes, thanks for reminder!

from fgtk.

Ah whoops, i type parse a lots so muscle memory took over ;)

I have tried looking into --expand-seed, but for some reason i cannot call it with the default base64 output, but if i call the cli using the --raw flag and echo that into --expand-seed it just fails, guess bash doesnt support that or something.

And the python print for the base64 decode returns is quite unreadable for humans with all those \charackters, for what delimiter should i look? PROTOCOL.key doesn't specify how they are concatenated/how one should parse them.

from fgtk.

I have tried looking into --expand-seed, but for some reason i cannot call it with the default base64 output, but if i call the cli using the --raw flag and echo that into --expand-seed it just fails, guess bash doesnt support that or something.

Yeah, it expects base64-encoded seed, not raw, as per option description:

-s 32-byte-ed25519-key-seed, --expand-seed 32-byte-ed25519-key-seed
  Derive expanded 64-byte key from specified
  base64-encoded 32-byte ed25519 seed value. "path"
  argument will be ignored if this option is specified.

But guess it's not very clear there either, esp. due to metavar arg.

from fgtk.

Whoops silly me, i took a closer look at the error and noticed an import was failing, i guess my mac's homebrew got a bit woozy.

the commands python2.6 and python3.6 could not find the argparse module, but only the 'normal' python could see the 'easy_install argparse' module

I'll let you know if i run into more issues reverse engineering this, thanks for all so far :)

from fgtk.

I'll let you know if i run into more issues reverse engineering this, thanks for all so far :)

I'm currently adding --patch-key operation there (will maybe hardcode key to patch as well), so maybe it'll be much easier soon.

python2.6

Yeah, it's for py2.7 (last python2) specifically I guess, py2.6 like 10 years out of date by now, maybe you should update it, if possible.

from fgtk.

PROTOCOL.key doesn't specify how they are concatenated/how one should parse them.
reverse engineering

Also, wrt format, maybe ssh_key_parse func in this script can be used as a spec, though as mentioned, maybe not worth bothering with either.

from fgtk.

Yea i just checked, the system default is Python 2.7.10

from fgtk.

Also, wrt format, maybe ssh_key_parse func in this script can be used as a spec, though as mentioned, maybe not worth bothering with either.

not sure i understand what you mean 🤔

from fgtk.

Yea i just checked, the system default is Python 2.7.10

To be fair, any python2 is deprecated and "out of date" as well, might also get around to updating the script to use py3 instead.

from fgtk.

not sure i understand what you mean 🤔

I mean, if key format is hard to read from PROTOCOL.key file, maybe would be easier to understand it from here: https://github.com/mk-fg/fgtk/blob/3da7f04/ssh-keyparse#L13-L117
But then again, maybe not...

from fgtk.

from here: https://github.com/mk-fg/fgtk/blob/3da7f04/ssh-keyparse#L13-L117

Actual binary-parsing bits: https://github.com/mk-fg/fgtk/blob/3da7f04/ssh-keyparse#L81-L115

from fgtk.

I had trouble finding the php equivalent of the struct.unpack('>II', key.read(8)), but i did manage to somewhat extract the values, although the large amounts of null chars in the binary surprise me: (seems a bit inefficient for parsers to work with?)

array(39) {
  [0]=>
  string(14) "openssh-key-v1"
  [1]=>
  string(0) ""
  [2]=>
  string(0) ""
  [3]=>
  string(0) ""
  [4]=>
  string(5) "�none"
  [5]=>
  string(0) ""
  [6]=>
  string(0) ""
  [7]=>
  string(5) "�none"
  [8]=>
  string(0) ""
  [9]=>
  string(0) ""
  [10]=>
  string(0) ""
  [11]=>
  string(0) ""
  [12]=>
  string(0) ""
  [13]=>
  string(0) ""
  [14]=>
  string(1) "�"
  [15]=>
  string(0) ""
  [16]=>
  string(0) ""
  [17]=>
  string(1) "3"
  [18]=>
  string(0) ""
  [19]=>
  string(0) ""
  [20]=>
  string(12) "�ssh-ed25519"
  [21]=>
  string(0) ""
  [22]=>
  string(0) ""
  [23]=>
  string(33) " �.u�:�d��o���6��Q\�`�Ǟ\��SJ�`�g"
  [24]=>
  string(0) ""
  [25]=>
  string(0) ""
  [26]=>
  string(9) "����-���-"
  [27]=>
  string(0) ""
  [28]=>
  string(0) ""
  [29]=>
  string(12) "�ssh-ed25519"
  [30]=>
  string(0) ""
  [31]=>
  string(0) ""
  [32]=>
  string(33) " �.u�:�d��o���6��Q\�`�Ǟ\��SJ�`�g"
  [33]=>
  string(0) ""
  [34]=>
  string(0) ""
  [35]=>
  string(65) "@h.��%`�R��<��sEI?q-��F$�K8���k͉�.u�:�d��o���6��Q\�`�Ǟ\��SJ�`�g"
  [36]=>
  string(0) ""
  [37]=>
  string(0) ""
  [38]=>
  string(14) "�comment�������"
}

from fgtk.

large amounts of null chars in the binary surprise me

Every string is length-prefixed there, e.g. 00 00 00 0e + "openssh-key-v1", hence plenty of zeroes for all kinds of small strings, not super-unusual and definitely simplier to have one-size-fits-all int there.
Less bugs in parsers that way too, which is good security-wise.

from fgtk.

Do you happen to know how the length-prefix is calculated? i see 2 whitespaces before long strings and 3+ before relatively short ones?

from fgtk.

Do you happen to know how the length-prefix is calculated?

Um, it's just length of string after that in bytes.

I.e. with this scheme, if you want to write string, you do it like this:

value = 'some string'
file.write(struct.pack('>I', len(value)) + value)

And then reading it back is done like here: https://github.com/mk-fg/fgtk/blob/3da7f04/ssh-keyparse#L66-L69
I.e. you read 4-byte length and then read however many bytes is specified there as string.

from fgtk.

Oh that is quite genius, I'm relatively new to binary-ish string formats ¯_(ツ)_/¯

Again thank you for your generous time! 🏅

from fgtk.