Author Topic: DCPCrypt flawed?  (Read 373 times)


  • New Member
  • *
  • Posts: 13
DCPCrypt flawed?
« on: September 04, 2020, 03:02:00 am »
Hey i am writing a program that needs encryption. I am using the DCPCrypt library and was looking through the documentation included with it and noticed a slight problem. It says that if you use the UpdateStr/UpdateStream function of a cipher then it hashes the key that you give it and uses the hash to encrypt the contents that you give it. This seems like a good idea at first but is actually flawed(if i am not mistaken). The thing is a hash is always the same length. So if someone were to try and crack what ever i encrypted and they know that i used a specific hash to encrypt the contents, then they could crack it easier because they the length of the key.

Maybe i am understanding it wrong. If i am, please clear things up for me. And if i am right, tell me how i can encrypt the contents without dcpcrypt hashing the key for me.


  • New Member
  • *
  • Posts: 37
Re: DCPCrypt flawed?
« Reply #1 on: September 04, 2020, 07:56:55 am »
A given cipher API's key length is fixed. If you are using AES-128, the key length is 128 bits. If AES-256, the key length is 256 bits.

When the API allows you to supply an arbitrary string or byte array as the key, the API has to convert the supplied key into the correct length, like 128 bits for AES-128. This is done by hashing.
« Last Edit: September 04, 2020, 07:59:40 am by PierceNg »


  • Hero Member
  • *****
  • Posts: 10600
Re: DCPCrypt flawed?
« Reply #2 on: September 04, 2020, 08:07:30 am »
The length of the hash is not important. It is a one-way hash which means that the encrypted content can in practice never be retrieved from the hash itself.
(As long the hash is a secure hash) See
Note there exist hashes that are proven to be insecure, like MD5. So never use those for secure hashing. See wikipedia.

This differs from decrypting. While the content can in practice never be retrieved, attacks are geared towards  hash collisions which can be used to impersonate or replace the content with malicious content. You need not know the original content for that. A famous example is the US/UK/Israeli attack on Iran's nuclear infrastructure, where part of the attack was a hash collision that further compromised the Siemens systems. So never assume it is only theory! (what many do...) E,g, for the MD5 hash it is quite easy to find collisions, even on consumer hardware.

For completeness, note there are hashes that are designed to retrieve content and provide error correction abilities, like CRC32. These are two-way hashes and not suitable for cryptography. An example for that is ZIP where by means of CRC32 damaged zip  archives can be restored to a certain extend.

Second: note that full encryption like RSA is not hashing and is a two way process.

DCPCrypt is flawed in many ways (has problems with some standards) , but not here.
I would use one of forum user Xor-El's solutions for secure hashing: these are standards compliant, so will operate in conjunction with software written in other languages.
« Last Edit: September 04, 2020, 12:49:12 pm by Thaddy »


TinyPortal © 2005-2018