The character string being generated is formed from a VB application, which the VB programmer has used this page as the source for the compiled code.
>the cipher text length is ALWAYS a multiple of 8
Although he acknowledges that he hasn't initially padded the blocks out to be in exact 8 bytes blocks - using the same function to reverse the data out works; I wonder if perhaps we have inherited someone else's bugs by including this code?
>you are decoding the multi-byte characters into a single byte
When encoding these characters, some single-byte characters are transformed into multi-byte characters, as per the example below.
126 %7E \x7E 127 %7F \x7F 128 %u20AC \x80 129 %81 \x81 130 %u201A \x82 131 %u0192 \x83 132 %u201E \x84 133 %u2026 \x85 134 %u2020 \x86 135 %u2021 \x87
In the example here, the character is transformed as a single byte character, so surely it must go back to a single (not multi) byte character?
>eg %u0160 should be something like "\x00\xBF"
I am not sure I fully understand what you have written here, is this the information I should be looking at?
>correct first few characters then the encryption is running in ECB mode and so Crypt::CBC won't help you
Yes, your statement is correct - I tried the Crypt::CBC module, but the outcoming data looked nothing like the original string, whereas the Crypt::Blowfish module was giving me the majority of it, just causing problems in the trailing area.
Richard (still mostly confused ...!)
In reply to Re: Re: Blowfish decryption problem
by richard_mortimer
in thread Blowfish decryption problem
by richard_mortimer
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |