Home/ Questions/Q 8978821
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-15T19:42:02+00:00

I’m using the DCPcrypt library in Delphi 2007 for encrypting text for an in-house

  • 0

I’m using the DCPcrypt library in Delphi 2007 for encrypting text for an in-house app.

I’m currently using the following code (not my actual key):

  Cipher := TDCP_rijndael.Create(nil);
  try
    Cipher.InitStr('5t@ck0v3rf10w', TDCP_md5);
    Result := Cipher.EncryptString('Test string');
  finally
    Cipher.Burn;
    Cipher.Free;
  end;

The comment for InitStr is:

Do key setup based on a hash of the key string

Will exchanging the MD5 algorithm for, say, SHA2-256 or SHA2-512 make any theoretical or actual difference to the strength of the encryption?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    The direct answer to your question is ‘No’ – it won’t make any appreciable difference to cryptographic strength. Yes, MD5 is broken, but really it’s weakness does not make any difference in this particular application. AES has key sizes of 128, 192 and 256 bits. All you are doing here is creating a string pseudonym for a key (being either 16 bytes, 24 bytes or 32 bytes). When cryptographic experts say that a hash function is broken, what they mean by this is that given a known hash output, it is feasible to compute a message different from the original message, which also hashes to the same output. In other words, in order for the cryptographic strength or weakness of the hash function to have any meaning, the binary key must already be known to the malicious party, which means that it is only relevant when your security is already completely defeated.

    The strength of the hashing algorithm is COMPLETELY irrelevant to the strength of the asymmetric cipher.

    However…

    However, of a much more serious concern is the lack of salting in your code. Unless you plan to manually salt your message (unlikely), your communications are very vulnerable to replay attack. This will be infinity worse if you use ECB mode, but without salting, it is a major security issue for any mode. ‘Salting’ means injecting a sufficiently large non-predictable non-repeating value in either the IV or at the head of the message before encryption.

    This highlights a huge problem with DCPCrypt. Most users of DCPcrypt will not know enough about cryptography to appreciate the importance of proper salting, and will use the crypto component in exactly the way you have. When you use DCPcrypt in this way (which is very natural), DCPcrypt does NOT salt. In fact, it sets the IV to zero. And it gets worse… If you have chosen a key-streaming type of chaining mode (which is very popular), and your IV is habitually zero, your security will be completely and utterly broken if a single plaintext message is known or guessed, (OR even just a fragment of the message is guessed). DCPcrypt does offer an alternative way to initialize a binary key (not from string), together with allowing the user to set the IV (you must generate a random IV yourself). The next problem is that the whole IV management gets a bit complicated.

    Disclosure

    I am the author of TurboPower LockBox 3. Dave Barton’s DCPcrypt, an admirable and comprehensive engineering work, was one of my inspirations for writing LockBox 3.

    • 0