4.0.0 Backwards Compatibility?

[ThatOneGuy]

How backwards compatible is it? My previous version was 3.1.0 and a file created last week with that version won't decrypt with 4.0.0. I was using the maximum password length told me to back in 2019 so maybe 4.0.0 is using a shorter password limit due to some technical change?

[paulej]

It is written to be fully backward-compatible and it has been tested pretty extensively. So, this is troubling that an older file fails to decrypt.

Are you using a password or a key file? Are you using any non-ASCII characters?

What is the precise version and platform you are using (e.g., v3.10, Linux GUI or command-line)?

If you can send me an email (or post here) an example with a password that's not your actual password, I'm happy to dig into it to figure out what the issue is.

[paulej]

I found a bug with handling legacy key files. I am hoping that's what you encountered, because this is an easy fix. We will be preparing 4.0.1 ASAP to address this.

As a workaround for the moment, you can open the key file in vim, copy the text and paste it when prompted for a password or use it via the -p argument.

If you want to know the technical problem, it was a failure to remove the byte-order-mark (BOM) from the legacy key file before consuming it.

[paulej]

Version 4.0.1 of the Linux CLI and GUI builds has been posted. That fixed the legacy key file issue I observed.

Other platforms will follow, but they take a little longer for code signing.

[ThatOneGuy]

I'm on windows x64 using the gui. But I will wait for that to be available and see if that fixes my issue. Thanks for the fast response.

I made a randomly generated password in keepass and it does have characters such as 侺. When I generated the password I selected all the character options. If you had to drop support for that, it would suck for me, but I can redo the files using new password rules if needed.

[paulej]

Ok, so you're right-clicking on a file and select the "AES Encrypt" option or "AES Decrypt" option from the context menu? Is that correct?

If so, would you mind generating one of those kinds of complicated passwords and posting it here? I'll do some testing to see if I can replicate it.

I just posted the new 4.0.1 version, but that isn't going to address the Windows GUI issue. My guess is there is an error in the character conversion logic. I'll see if I can replicate it, but please post some "ugly" generated passwords (or a few) that I can test with.

[paulej]

Just to give a status update, I've spent several hours trying to produce this bug. I tried all kinds of Unicode character sequences thinking that might be the issue. I was able to create a bug when trying to decrypt an old Win 3.10 file and this happens when I use precisely 1024 characters. And, it happens even if I use a string of digits (i.e., just plain ASCII).

Can you confirm your password is exactly 1024 characters in length? It might be this same issue I'm seeing.

The new code removed those limits. The limits in the new code are 4096, though some command-line processors might impose varying limits.

Anyway, I suspect we're hitting a bug in the legacy code that just didn't manifest itself until the length of the input field was increased. I will work to try to identify the precise issue. One way or the other, I'll find it. But, if you can confirm your password length is 1024, at least that might hint that it's the same issue I came upon.

Assuming your password is >= 1024 characters, try using just the first 1023 characters and see if that works. That did work for me. What is happening is that since the buffer in the old code was 1024 characters long, Windows would discard any extra characters and only use the first 1023 (leaving room for a NULL string terminator). Since the password length was increased in the new code to 4096, the new code tries using all 1024 characters.

[ThatOneGuy]

Looks like you nailed it. Deleting the last character of the password lets me decrypt. Thank you!

[paulej]

Ah, good! I spent hours trying all sorts of things and this was the one issue I found.

Boundary conditions can be such a pain. I re-read the Windows API documentation, and I still find it ambiguous on this point. I will make changes, though, to avoid this. I think in the current 4.x release, I just moved to problem to 4096 characters. I'll remove this artificial restriction, as it's not necessary. However, Windows will still impose a limit of 32767 characters, as that is the default input length.

Anyway, I can't correct that bug in the legacy code, but at least I understand the issue. I appreciate you "testing the limits"

[ThatOneGuy]

And I appreciate you being so responsive. I'd hate to see a program I use so much for security get abandoned like some in the past.