Sign In
Create Account
Follow Us on Twitter
Subscribe on Youtube
Say you are developing a program that transmits files or messages. You want to verify the transmission with Checksum. How would you do it? How does CRC/Checksum even work? Is it accurate for verifying files?
5 replies to this topic
Back to top|
|
|
#2
Posted 31 August 2009 - 07:27 PM
dargueta
-
- Moderators
-
- 4,720 posts
Writes binary right handed and hex left handed
Yes, but there are more secure algorithms for verifying data integrity. CRC is not really secure at all. You're better off using MD5, SHA1 or SHA2 if security is a bigger issue than just "oh, did we flip a bit or two here?".
Computing a CRC Checksum
Computing a CRC Checksum
sudo rm -rf /
#3
Posted 01 September 2009 - 06:18 AM
WingedPanther
-
- Moderators
-
- 16,831 posts
A spammer's worst nightmare
CRC is just a hash. If the file encountered an error during transmission, it will almost certainly have the CRC value change. There are a LOT of programs that will compute various hashes of files for you, including some hex editors.
The CRC is not a security thing, just helps insure the file wasn't corrupted during download.
The CRC is not a security thing, just helps insure the file wasn't corrupted during download.
#4
Posted 01 September 2009 - 06:24 AM
dargueta
-
- Moderators
-
- 4,720 posts
Writes binary right handed and hex left handed
Well, they use hashes on Linux DEB hosts to ensure that you're not downloading some modified binary with malicious code in it. I'd say that's security.
sudo rm -rf /
#5
Guest_h4x_*
Posted 04 September 2009 - 05:55 AM
Guest_h4x_*
Guest_h4x_*
-
- Guests
ok, lets take 4 bytes of hash.
how much data it can contain?
more than 4 bytes? i dont think so.
i dont really know why people use hashes, but i cant imagine packing 2 bytes into 1.
Compression in other hand is diffrent story, but thats not hashing, simply changing representation of data to occupy less space.
how much data it can contain?
more than 4 bytes? i dont think so.
i dont really know why people use hashes, but i cant imagine packing 2 bytes into 1.
Compression in other hand is diffrent story, but thats not hashing, simply changing representation of data to occupy less space.
#6
Posted 04 September 2009 - 08:29 AM
WingedPanther
-
- Moderators
-
- 16,831 posts
A spammer's worst nightmare
@h4x: you have it completely backwards and upside down.
Hash: take a file/string and transform it into a fixed number of characters. Two different strings can have the same transformed string.
Compression: take a file/string and transform it into a different file/string. The algorithm is designed to try to make the resulting string shorter than the original string, but this is not guaranteed. In lossless compression, two different source strings cannot result in the same result string. In lossy compression, two similar source strings can result in the same result string.
A good hash will produce wildly different results with a slightly different source. This is useful for detecting minor alterations to the source string.
Hash: take a file/string and transform it into a fixed number of characters. Two different strings can have the same transformed string.
Compression: take a file/string and transform it into a different file/string. The algorithm is designed to try to make the resulting string shorter than the original string, but this is not guaranteed. In lossless compression, two different source strings cannot result in the same result string. In lossy compression, two similar source strings can result in the same result string.
A good hash will produce wildly different results with a slightly different source. This is useful for detecting minor alterations to the source string.
