error decrypting private key

[Luci2015]

last version I tested (2.6.0) still uses an outdated cryptography module causing an error on attempt to decrypt private keys encrypted with openssl versions higher than 1.1
I do remember having a side test with the latest available module, some time last year, and I was able to decrypt so wondering when UST will pack it as well.

[vossenv]

I believe we can update this now that we have dropped PEX. See:

#484

[adorton-adobe]

Seems like a reasonable update. @Luci2015 when I push the change to v2, can you build the binary and tell me if that solves the problem? I don't have a good way to test it right now.

[adorton-adobe]

I've bumped the version to 3.9.7, the latest release.

[Luci2015]

I can try to build it for a Mac or Linux by the end of the week or just run it from source with the dependencies from the setup file.

[adorton-adobe]

Testing from source would be good, but I don't think we can consider it fixed without a test of the build. I'll see if I can replicate the issue to see if the fix is going to work.

[Luci2015]

I've build a binary for Win, enventually, and it does not seem to be working. Still getting the same error as before.
I used openssl v. 1.1.1d to encrypt.
Can you please have a test on your end as well?
I don't remember if pycryptodome was used at that time or something else. Need to dig in the archives to see what I did back then..

[Luci2015]

the standalone function works OK with decrypt if the right data is being used as input.
gave it a quick look and I think the error lies here:

• line 42 in here expects that data be the result of file.read()
• while line 32 in here inserts the file path instead of the data

[vossen-adobe]

Not sure how that slipped through - it was introduced in february. I've added a quick PR to resolve. You can also now use UST to do the encryption instead of openSSL and it should with

user-sync.exe encrypt

This will give you an appropriately encrypted cert which is guaranteed to work correctly.

[Luci2015]

Thanks! In the use-case I have I'm should not generate the pair, rather decrypt an existing one.
I'll do another .exe build over the next few days and test this fix.
Thanks again!