Skip to content

PuTTY .ppk v3 support - #6003

Open
elipsion wants to merge 2 commits into
openwall:bleeding-jumbofrom
elipsion:bleeding-jumbo
Open

PuTTY .ppk v3 support#6003
elipsion wants to merge 2 commits into
openwall:bleeding-jumbofrom
elipsion:bleeding-jumbo

Conversation

@elipsion

Copy link
Copy Markdown
  • Extends putty2john with support for reading Argon fields
  • Extends putty_fmt_plug to consume Argon related data
  • Formatting with indent and astyle

@solardiz

Copy link
Copy Markdown
Member

Thank you!

We need sample input file(s) to test this with, and to be able to re-test it later. Can you please contribute some to https://github.com/openwall/john-samples/tree/main/PuTTY?

The format should start reporting tunable costs - algorithm and its parameters. Looks like up to 4 total in this case.

For hex parsing, we should probably use shared code from common.[ch]. Some other *2john programs depend on these files. In Makefile.in, we have:

../run/hccap2john@EXE_EXT@: hccap2john.o common.o jumbo.o
        $(LD) $(LDFLAGS) @PTHREAD_CFLAGS@ @PTHREAD_LIBS@ common.o hccap2john.o jumbo.o @OPENMP_CFLAGS@ -o $@

../run/putty2john@EXE_EXT@: putty2john.o jumbo.o
        $(LD) $(LDFLAGS) @PTHREAD_CFLAGS@ @PTHREAD_LIBS@ putty2john.o jumbo.o @OPENMP_CFLAGS@ -o $@

so this is where the extra dependency will go.

Please also add a doc/NEWS item to the end of the post-1.9.0 list, currently around line 490.

@elipsion

Copy link
Copy Markdown
Author

Thanks for the feedback! Addressed in this PR and john-samples#47

@solardiz solardiz left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you! This is moving in the right direction, but I think there are a few more things to fix here. Also, please roll all of the review feedback changes into your first commit (and force-push), so that we can preserve your commits as they are when merging this yet not have the PR-temporary review/change history stay in the project (such micro-history is of no long-term relevance).

Comment thread doc/NEWS Outdated
Comment thread src/putty2john.c
Comment thread src/putty_fmt_plug.c
#define FORMAT_TAG "$putty$"
#define FORMAT_TAG_LEN (sizeof(FORMAT_TAG)-1)
#define ALGORITHM_NAME "SHA1/AES 32/" ARCH_BITS_STR
#define ALGORITHM_NAME "SHA1/AES/Argon2 32/" ARCH_BITS_STR

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The "32/" part becomes wrong for Argon2, which can use more of the word width... or actually also SIMD. Need to check how we report this in other formats where Argon2 is also optional and do it consistently.

Should also list SHA256.

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I feel like this is above my pay grade. Tell me what to type and I'll drop the letters.

Comment thread src/putty_fmt_plug.c
{NULL}
{ "$putty$1*16*1*0*69396df4513221459e8302f2b84b56d1f078cce1*51*0000000b7373682d6564323535313900000020abed4c34945b8e98fad03669eba5911b5890e7070d5212547128c2b586c9cba5*48*878992fc0f3bd20a88d182bb9f765ceb259e1076da2c7d4a0987b95bc692c690886f2020b5959399550cb9224cc71f1a*ssh-ed25519*aes256-cbc*ed25519-key-20170722", "openwall" },
{ "$putty$1*16*1*0*d931af6335088577da918d60a77f3c097d76620a*104*0000001365636473612d736861322d6e69737470323536000000086e6973747032353600000041046bb900eb809a5be6ec1bda5aac286ac9a2e0c7e0bfab317623ccf9b8b47baaedc0a2498287df6cb3a07165461b40ac1dba2f492be96ec841bfcbf93df9d31a43*48*ba7ba53ca50e05e15ba4ea19f2c6891298af84bf7280ea4bdcb7fa0611a9816a5966f972cd4a1eee37a42ac69489601c*ecdsa-sha2-nistp256*aes256-cbc*ecdsa-key-20170722", "openwall" },
/* PuTTYgen 0.83-1 from June, 2026 *//* It uses weaker-than-normal parameters to not overwhelm the test suite */

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great, but we also need to be able to request realistic benchmark if possible. What are the normal parameters?

We may also want to have 2+ test vectors per KDF type, so that things such as salt switching are tested. Those extra tests may in fact use weaker settings.

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The standard options are argon2id-8192-13-1 which (at least on my machine) takes several minutes to establish a performance baseline before starting useful hashing operations.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, that's probably because this format also supports the faster varieties, for which we need high keys per crypt. And it does not "establish a performance baseline", but rather tests many of the key indices for proper operation. However, I am puzzled - you seem to also have a test vector with "8192131" at the end, doesn't it cause the same problem?

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My bad, it was left in when collecting the timing info.

brick:/mnt/c/Users/elips/source/john# time run/john hashes.txt
Using default input encoding: UTF-8
Loaded 10 password hashes with 8 different salts (1.3x same-salt boost) (PuTTY, Private Key (RSA/DSA/ECDSA/ED25519) [SHA1/AES/Argon2 32/64])
Loaded hashes with cost 1 (type [0:none 1:Argon2d 2:Argon2i 3:Argon2id]) varying from 1 to 3
Loaded hashes with cost 2 (t) varying from 1 to 13
Loaded hashes with cost 3 (m) varying from 8 to 8192
Cost 4 (p) is 1 for all loaded hashes
Will run 14 OpenMP threads
Note: Passwords longer than 10 [worst case UTF-8] to 32 [ASCII] rejected
Proceeding with single, rules:Single
Press Ctrl-C to abort, or send SIGUSR1 to john process for status
openwall         (openwall)
openwall         (openwall)
openwall         (openwall)
openwall         (openwall)
openwall         (openwall)
openwall         (openwall)
openwall         (openwall)
openwall         (openwall)
openwall         (openwall)
openwall         (openwall)
10g 0:00:00:00 DONE 1/3 (2026-08-13 07:17) 62.50g/s 700.0p/s 700.0c/s 875.0C/s openwall..openwall123
Use the "--show" option to display all of the cracked passwords reliably
Session completed
real    0m 13.58s
user    0m 28.14s
sys     0m 35.61s

This is the timing with that vector in place:

brick:/mnt/c/Users/elips/source/john# time run/john hashes.txt
Using default input encoding: UTF-8
Loaded 10 password hashes with 8 different salts (1.3x same-salt boost) (PuTTY, Private Key (RSA/DSA/ECDSA/ED25519) [SHA1/AES/Argon2 32/64])
Loaded hashes with cost 1 (type [0:none 1:Argon2d 2:Argon2i 3:Argon2id]) varying from 1 to 3
Loaded hashes with cost 2 (t) varying from 1 to 13
Loaded hashes with cost 3 (m) varying from 8 to 8192
Cost 4 (p) is 1 for all loaded hashes
Will run 14 OpenMP threads
Note: Passwords longer than 10 [worst case UTF-8] to 32 [ASCII] rejected
Proceeding with single, rules:Single
Press Ctrl-C to abort, or send SIGUSR1 to john process for status
openwall         (openwall)
openwall         (openwall)
openwall         (openwall)
openwall         (openwall)
openwall         (openwall)
openwall         (openwall)
openwall         (openwall)
openwall         (openwall)
openwall         (openwall)
openwall         (openwall)
10g 0:00:00:00 DONE 1/3 (2026-08-13 07:21) 45.45g/s 509.1p/s 509.1c/s 636.4C/s openwall..openwall123
Use the "--show" option to display all of the cracked passwords reliably
Session completed
real    3m 42.44s
user    44m 21.71s
sys     3m 29.30s
brick:/mnt/c/Users/elips/source/john#

Comment thread src/putty_fmt_plug.c Outdated
@solardiz

Copy link
Copy Markdown
Member

please roll all of the review feedback changes into your first commit (and force-push), so that we can preserve your commits as they are when merging this yet not have the PR-temporary review/change history stay in the project (such micro-history is of no long-term relevance).

Actually, given that you also reformatted the code I understand it may be significant effort for you to merge changes into the earlier commit. Nevermind. We can accept not so clean commits history this time.

@solardiz

Copy link
Copy Markdown
Member

@elipsion Are you going to address my feedback here, or should we merge this as-is and then fix it? Also, there's a merge conflict here for doc/NEWS with another PR we merged first (since that one became fully ready first).

@elipsion

elipsion commented Jul 21, 2026

Copy link
Copy Markdown
Author

Sorry for leaving you hanging. I vent on vacation and promptly forgot about this.

Will give it a shot when I'm back.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants