-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Input text size #16
Comments
https://github.com/DominicTobias/SecurePad/blob/master/PluginDefinition.cpp#L147 and https://github.com/DominicTobias/SecurePad/blob/master/PluginDefinition.cpp#L214 need to be checked. Probably there for the null at the end of the character buffer used to transfer the input text from the editor. Probably it is not necessary for the encryption. |
I found something that may explain it. Quoting:
If this is the case, then it could be a case of stripping off the padding bytes before encoding. |
Hi there!
(Obs.: the following is relative to v2.4.)
I noticed that the text length used for encoding seems to admit some extra information.
For example:
Input string:
borbatonborbatozborbacaxborbafit
Key:
pwalsk
Result:
CC707A518AE12AB48DA543A8DEBE2A221ECD8B302B015B13255EBB9FFDBBA192A95AEE18A5D46C6A
This result seems to be produced when the final multiplied text length is 80. The text length is 80 because 1 is added to the original length 32 resulting in 33, which rounds up to 40 when searching for the next multiple of 8. That then is double to become 80.
If 1 was not added, then 32 being already a multiple of 8 would make the length of 32 * 2 = 64. In this case, the result is:
Result:
CC707A518AE12AB48DA543A8DEBE2A221ECD8B302B015B13255EBB9FFDBBA192
This result ,when decoded and read back to 32 positions, already contains the original information:
borbatonborbatozborbacaxborbafit
. The extra information at the end of the string (which comes out as garbled text) seems to be the original extra 16 bytes (80 - 64). It could then be encoded more economically considering size 64 instead of 80, also avoiding including the extra information in the encoding.It could also potentially increase decoding compatibility with other Blowfish implementations. For instance, when decoding this result in sladex, some extra garbled characters appear in the end.
Is there any specific reason for the +1 increase in the encoding buffer (
PluginDefinition.cpp
line 147)?Thank you,
The text was updated successfully, but these errors were encountered: