search

fruiz500 / PassLok-Privacy

PassLok privacy app
GNU General Public License v3.0
30 stars 8 forks source link

Version 2.3.2 NOT backwards/forward compatible: Decryption fails #19

Closed erreip closed 8 years ago

erreip commented 8 years ago

As of 2.3.2 any message encrypted to 'myself' using on the 'old' PassLok will not decrypt on the 2.3.2 version of the html package (and Android) and vice-versa...Same happens with any other Loks in my list, I can encrypt to my contacts but THEY cannot decrypt if i encrypted the message on the 2.3.2. version AND they are on an older version (and vice-versa)...

fruiz500 commented 8 years ago

Correct, version 2.3.2 output is not compatible with the output of previous versions, but it will be compatible with that of future versions. If you want to use its output in a previous version, you must change - characters to %, and vice-versa.

The reason is the following. The character % was used up to version 2.3.1 to separate parts of an encrypted message so they could be readily identified and separated out for decryption. In version 2.3.2, an option was added to encrypt directly into files (primarily for large items), but browsers interpret % characters in the encrypted strings as part of URI-encoded special characters, and therefore turn them into something else upon saving a file. The solution was to use a different character as a separator.

I thought of adding some code so that messages made by old versions would still be decryptable in 2.3.2 and beyond, but I didn't think the size of the current installed based justified this. Correct me if I'm wrong.

I hope it's not much of an inconvenience. In any case, users of previous versions can update to the new one, and old messages can be decrypted in the new version once % characters are changed to -

erreip commented 8 years ago

Understood. That makes a lot of sense, no need to trip up anything by using a previously established use of characters in URI codes Perhaps a 'What's new in for this update' blurb in the README.md document addressing this and/or any compatibility issues is warranted for this and future release. That is, unless I missed where you addressed this change. If its the latter, I sincerely apologize.

RE:

I thought of adding some code so that messages made by old versions would still be decryptable in 2.3.2 and beyond, but I didn't think the size of the current installed based justified this. Correct me if I'm wrong.

It may be worth adding the ability to process old versions' messages however, I would hold on that depending on feedback e.g. how many people are actually having that issue.

Regardless, I'm really liking this project and enjoy testing it (from a USER perspective as I'm not a coder) quite a bit.

Cheers,