Posted on Sep 23, 2017
How long do you predict before sharing hash sums alongside file attachments become a norm?
3.63K
13
17
1
1
0
I share md5 hash sums with my music downloads. They should be at least sha256 now that I think about it. Luckily, I can easily do this is Linux with md5sum, etc..
Cyber
Cybersecurity
Informational Security
Information Technology
Linux
Posted 7 y ago
Responses: 5
1
1
0
Well md5 is weak from a security stand-point and maybe over-strength from an error detection stand-point .
For security you want sha256, sha384, sha512 or sha3(keccak). However merely having the hash sitting next to the real thing might not provide that much protection from tampering. If an attacker can alter the file, then he can surely alter the hash to match. You need a digital signature backed by a public-key cryptography as well.
From an error detection stand-point a 32bit crc will only match one in 4 billion from accidental changes. There are also standards for a 64 bit crc. A 64bit crc should protect against all accidental errors to a very high degree of probability, but for many file formats an attacker could create a substitute file that collides.
So longer time frames I think that having digital signatures that use secure hash functions will become more and more of a norm. In many cases they will be embedded into the file itself, but ways to exist along-side or wrapping particular files should also become more common.
For security you want sha256, sha384, sha512 or sha3(keccak). However merely having the hash sitting next to the real thing might not provide that much protection from tampering. If an attacker can alter the file, then he can surely alter the hash to match. You need a digital signature backed by a public-key cryptography as well.
From an error detection stand-point a 32bit crc will only match one in 4 billion from accidental changes. There are also standards for a 64 bit crc. A 64bit crc should protect against all accidental errors to a very high degree of probability, but for many file formats an attacker could create a substitute file that collides.
So longer time frames I think that having digital signatures that use secure hash functions will become more and more of a norm. In many cases they will be embedded into the file itself, but ways to exist along-side or wrapping particular files should also become more common.
(1)
(0)
Maj (Join to see)
Hashing is only really useful to check man in the middle attacks. If someone has the ability to change the file on the server they probably have the ability to change bit of text as well
(0)
(0)
SPC(P) (Join to see)
Maj (Join to see) -
Yes and if they can change the file with a man-in-the-middle(mitm) then they can also change the hash to match with the same attack. So hashes are again useless, unless signed. To detect tampering the hashes either must be signed, or be transmitted via another more secure channel... If the channel used to transmit the file is mitm compromised, then your whole channel is compromised and you can't trust any of it.
It's part of why ftp and http are frowned on, and https is recommended. It might prevent a mitm attacks.
If you are using https(or similar) then you at least have security that protects the integrity of the file from mitm attacks. It might not close other holes that allows an attacker to change the files more directly. So if you really care about the file not being tampered with then you need to have the file signed with a key that the webserver doesn't have access to.
https might also not prevent all mitm attacks, especially since your security might rest on the security of the weakest CA that your machine is configured to trust.
Unsigned hashes are almost completely useless from a security stand-point for the purposes of detecting tampering.
Yes and if they can change the file with a man-in-the-middle(mitm) then they can also change the hash to match with the same attack. So hashes are again useless, unless signed. To detect tampering the hashes either must be signed, or be transmitted via another more secure channel... If the channel used to transmit the file is mitm compromised, then your whole channel is compromised and you can't trust any of it.
It's part of why ftp and http are frowned on, and https is recommended. It might prevent a mitm attacks.
If you are using https(or similar) then you at least have security that protects the integrity of the file from mitm attacks. It might not close other holes that allows an attacker to change the files more directly. So if you really care about the file not being tampered with then you need to have the file signed with a key that the webserver doesn't have access to.
https might also not prevent all mitm attacks, especially since your security might rest on the security of the weakest CA that your machine is configured to trust.
Unsigned hashes are almost completely useless from a security stand-point for the purposes of detecting tampering.
(0)
(0)
SGT (Join to see)
Great points from both. However, the bigger picture is its an effort that can be improved with time, as cybersecurity overall strives to do daily. If changing text becomes a worry, use a third-party to validate or require a two-step verification process. Many Linux distros already have this function.
Don't look at just what's in front of you now. Look up and around.
Maj (Join to see)
Don't look at just what's in front of you now. Look up and around.
Maj (Join to see)
(0)
(0)
SPC(P) (Join to see)
SGT (Join to see) -
[[the bigger picture is its an effort that can be improved with time,]]
Can be, but it seems people made the same mistakes over and over.
I'm reminded of a book of the 1990s Applied Cryptography by Bruce Schneier .. I still should have the first edition with the blue cover in my personal library.... Anyway the fundamentals of how to use hashes in secure protocols has been known in the open literature for over 2 decades.
It's quite an interesting book, I'd suggest more people in the DoD read it or similar and at least be on top of their game circa 1995. Hint public-key cryptography and good hashes mixed properly have excellent properties.
[[ If changing text becomes a worry, use a third-party to validate or require a two-step verification process. Many Linux distros already have this function.]] https://www.gnupg.org/
Or like I mentioned turning on https instead of using http is by far a more effective solution then using unsigned hashes. apache has had ssl/tls support for quite sometime. https://letsencrypt.org/ makes it cheaper for many.
You are correct there exists many better answers.
Sure and many distributions can sign their .rpm or .deb files and they sign their repository meta-data ... hmm I remember pgp(pretty good privacy) was around in the 1990s as well.
The various crypto primitives can do an excellent job if and only if they are used correctly. *if* *and* *only* *if* . A lot of them have brittle edges that if used incorrectly will cut you. The LT's profile says he has affiliation with the NSA and he has trained in "Network Warfare" and "Cyber Network Exploitation" so he should know that sometimes the best way to exploit a home-brew security system to look how people are doing things wrong that makes them feel comfortable, but in reality does little to no actual good; That can be your way in.
[[the bigger picture is its an effort ]] From a security point-of-view using unsigned hashes along side the data you are trying to keep tamper proof is largely ineffective... There have been known better methods since the 1990s... OK SSL had some real crap, that's why you should be using tls1.2 or tls1.3 if at all possible.
[[the bigger picture is its an effort that can be improved with time,]]
Can be, but it seems people made the same mistakes over and over.
I'm reminded of a book of the 1990s Applied Cryptography by Bruce Schneier .. I still should have the first edition with the blue cover in my personal library.... Anyway the fundamentals of how to use hashes in secure protocols has been known in the open literature for over 2 decades.
It's quite an interesting book, I'd suggest more people in the DoD read it or similar and at least be on top of their game circa 1995. Hint public-key cryptography and good hashes mixed properly have excellent properties.
[[ If changing text becomes a worry, use a third-party to validate or require a two-step verification process. Many Linux distros already have this function.]] https://www.gnupg.org/
Or like I mentioned turning on https instead of using http is by far a more effective solution then using unsigned hashes. apache has had ssl/tls support for quite sometime. https://letsencrypt.org/ makes it cheaper for many.
You are correct there exists many better answers.
Sure and many distributions can sign their .rpm or .deb files and they sign their repository meta-data ... hmm I remember pgp(pretty good privacy) was around in the 1990s as well.
The various crypto primitives can do an excellent job if and only if they are used correctly. *if* *and* *only* *if* . A lot of them have brittle edges that if used incorrectly will cut you. The LT's profile says he has affiliation with the NSA and he has trained in "Network Warfare" and "Cyber Network Exploitation" so he should know that sometimes the best way to exploit a home-brew security system to look how people are doing things wrong that makes them feel comfortable, but in reality does little to no actual good; That can be your way in.
[[the bigger picture is its an effort ]] From a security point-of-view using unsigned hashes along side the data you are trying to keep tamper proof is largely ineffective... There have been known better methods since the 1990s... OK SSL had some real crap, that's why you should be using tls1.2 or tls1.3 if at all possible.
GnuPG is a complete and free implementation of the OpenPGP standard asdefined by RFC4880 (also known as PGP). GnuPG allows to encrypt andsign your data and communication, features a versatile key managementsystem as well as access modules for all kinds of public keydirectories. GnuPG, also known as GPG, is a command line tool withfeatures for easy integration with other applications. A wealth offrontend applications and libraries are...
(0)
(0)
1
1
0
I don’t necessarily share any files except through my Google Drive so maybe I should start doing it myself as it will show proof of file integrity.
(1)
(0)
0
0
0
PO3 Phyllis Maynard
"sharing hash sum along a file attachment", what is that exactly. I am like one of the other responders, I use Google Drive, Dropbox, and Messenger Share.
Although I have a technology background and I am really technology saavy. There are many concepts I don't know about because technology concepts grow and change, it seems like overnight.
Although I have a technology background and I am really technology saavy. There are many concepts I don't know about because technology concepts grow and change, it seems like overnight.
(0)
(0)
Read This Next
Continue with Facebook 
Continue with Google