6

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?

Artjom B.
  • 61,146
  • 24
  • 125
  • 222
SteB
  • 1,999
  • 4
  • 32
  • 57

2 Answers2

9

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.

Sean B. Durkin
  • 12,659
  • 1
  • 36
  • 65
  • Thanks for the reminder to salt, I always salt when hashing, but I so rarely do ciphering I over-looked it! Would you do this as: Result := Cipher.EncryptString(my_salt + 'Test string');? – SteB Dec 10 '12 at 08:36
  • Yes on conditions: (1) my_salt is a nonce (per message emitted); (2) my_salt has at least 64 bits of entropy (more the better); (3) You need to transport my_salt on a side channel; and (4) don't use ECB. Although you can do it safely this way, the more traditional technique is to salt the IV instead. – Sean B. Durkin Dec 10 '12 at 10:11
  • Thanks for this great answer, the default cipher mode is CBC (I need to read up on the different modes). How do I tell how much entropy my salt has? I assume the IV is key passed to InitStr? If either of these answers are complex, I'll open another question. – SteB Dec 10 '12 at 10:37
  • If your PRGN is good, and is based on a 64 bit seed, you can get 64 bits of entropy just by generating a random 8 bytes. The in-built Delphi PRGN will never have more than 32 bits of entropy. The IV is completely different from the key. I don't have the code open at the moment, but I recall there is a method called SetIV() to set it. Of course if you call this, you cant then call InitStr(), because that will trash the IV. – Sean B. Durkin Dec 10 '12 at 11:46
0

You should specify the type of attack on your encryption; suppose known-plaintext attack is used, and intruder uses precomputed hash values to find key string - then there should be no difference between the hash algorithms used, any hash algorithm will require nearly the same time to find key string.

kludg
  • 27,213
  • 5
  • 67
  • 118