Garbage at the end of file (wodCrypt)

Hi all,

I'm evaluating the Crypt component for my company. We currently
have a piece of software (which is old, we don't have any source
etc etc --don't you just love these situations ?) that
produces a file.

This file is Blowfish-encrypted, and we have the key.

I have tried the wodCrypt component to decrypt it. It works, BUT
at the end of file, I get:

ScrStart1=156999
ScrLength1=&#136;<t~¯ãBý

The very last line should be:

ScrLength1=458

Please note that the file is about 2KB, and everything else is
decrypted OK. The problem is just the last line.

For the test, I used the Delphi sample, right out of the
installation. I have made only one modification: In Button2Click instead of

inblob.text := memo2.text;

I have:

inblob.FromFile('c:myEncryptedFile.txt');

Maybe this has anything to do with EOF ? Is there a workaround ?

Thanks for your time,

Dimitris Andrakakis
inATES Development Team
ECDL Hellas S.A.

Dandraka,

garbage is normal. Each algorithm has its own block size (blowfish is I believe 8 bytes) and operates on such blocks. When original data is smaller (last block does not align to 8 bytes) it must add *some* padding. What was added by your previous software - noone can know.

When you decrypt, you get original file plus these few bytes (so it aligns to 8), and you can't avoid it.

In the future, when you encrypt, you can choose to use Null padding, or use our Optimized = True which writes exact data size prior to encryption.

Hope it helps.

Thank you for your quick reply !

It would be Ok if I got the right data plus some garbage. For example, the following would be perfectly acceptable:

(Original)
Somedata=1234

(Decrypted)
Somedata=1234 $&^ $^

The problem is that I get something like:

Somedata= $&^ $^

As I understand from your reply, if the before-encryption-data do not align with the 8-byte buffer, then the last 8 bytes I get from the decryption are garbage. Is that correct ? Would it make any difference if I knew what the old software is padding the buffer with ?

Thank you for your time,

Dimitris Andrakakis
inATES Development Team
ECDL Hellas S.A.

Dandraka,

I agree that if you don't receive '1234' but garbage instead that this sounds like a problem - but I don't have answer to why this happens. Do you have code from old decryption component? How does it decrypt it?

[:sad:]

Only thing I know is that it uses components from some Andrewsoft: http://andrewsoft.hypermart.net

No other info whatsoever.

Perhaps you're missing last few bytes from encrypted data? That could explain why you get garbage?