Last Updated: 2020-05-26 19:18:42 UTC
by Jim Clausing (Version: 1)
A couple weeks ago, Rob wrote a couple of nice diaries. In our private handlers slack channel I was joking after the first one about whether he was going to rewrite CyberChef in PowerShell. After the second I asked what about SHA3? So, he wrote another one (your welcome for the diary ideas, Rob). I was only half joking.
SHA2 (SHA256 --or more accurately SHA2-256-- being the most common version in use) was first adopted in 2001. SHA3 was adopted in 2015. Fortunately, because we've known about the weaknesses in MD5 and SHA1 for years, those have been phased out for integrity purposes over the last decade. And, fortunately, I'm not aware of any weakneses in SHA2, yet, but it is only a matter of time. Having said that, I still see a lot of malware or forensic reports that will include MD5 or SHA1, fortunately usually these days also with SHA256, but I don't believe that even VirusTotal is calculating SHA3 hashes for new samples. I understand the arguments that using both MD5 and SHA1 is probably sufficient for the moment for malware sample identification purposes, but the new standard has been out there for 5 years now and the hash that is being used is almost 20 years old. What is the hold up? In my own personal malware database, I added a column for SHA3 back when NIST first announced that they were going to have a competition to choose the new hash. Python has included SHA3 in hashlib since 3.6 and it was backported to 2.7-3.5 in pysha3. The Perl Digest::SHA3 module has been around since the standard was adopted. I added it to my sigs.py tool more than 3 years ago, more specifically, I use SHA3-384 (as did Jesse Kornblum's beta of sha3deep, though I don't see a final release of that). So, what is the hold up? Why aren't we using the current standard? I, for one, plan to include both SHA2-256 and SHA3-384 hashes in all of my reports going forward. Thoughts?
Jim Clausing, GIAC GSE #26
jclausing --at-- isc [dot] sans (dot) edu