HashSlinger

[netmaestro]

Even if you find hashing a bore, this is fun to play with. Enjoy and pls report bugs: http://lloydsplace.com/HashSlinger.exe

It uses all my and wilbert's latest codes from T&T.

[wilbert]

It looks great Netmaestro
I like the way things look. The realtime change when typing is fun to see and the progress indicator is very original.
You could consider adding HMAC support but I don't know if that is used a lot or not.

[netmaestro]

Thanks wilbert! I like to be original when it comes to gui stuff. The code for this gui could be made crossplatform without difficulty but one would have to settle for an "ordinary" progress bar. (ugh!) This one relies on gdiplus, unavailable from MacOS. I don't know, is there an equivalent on Mac? It's a remarkable library, quick as a wink and always reliable. I'd love to pore over the asm code those guys wrote! It'd take me ten years to understand it but I'd be happy trying. (I'm never more depressed than when I understand everything I'm looking at- if that seems strange to you then I can recommend some nice artsy courses available at your nearest uni not you wilbert- I know better, you've got the same bug as me )

[wilbert]

I don't know what GDI+ functionality you are using Netmaestro.
OS X has a lot of graphical functions.

[Helle]

Hello netmaestro,
please check the computing of files. I get other results (see my new 32-bit-version).
Helle

[netmaestro]

Thanks for letting me know. I found anomalies in the 512/384 version results and when I ran tests not using hashslinger all came out right. Hashslinger does the same IncludeFile "sha512.pbi" that my test program does and so that was a bit confusing. I had Includefile sha256.pbi and then sha512.pbi so I switched the order just for fun and that fixed it. Subsequent tests on the 256/224 version results revealed no errors. I don't understand why this fixes it as the only globals used in either program are for the prototypes and they are all different.

Anyway, I uploaded the fixed version, could you see if it works now? Meanwhile I'll try to find out why putting the 512 include first made a difference

Thanks again for your help.

[netmaestro]

Here's the test I'm using to try and track this down:

Code: Select all

;IncludeFile "sha256.pbi"
IncludeFile "sha512.pbi"

file$ = GetTemporaryDirectory()+"test.bin"

If CreateFile(0, file$)
  *mem = AllocateMemory(1024*1024)
  FillMemory(*mem, 1024*1024,'a')
  WriteData(0, *mem, 1024*1024)
  CloseFile(0)
EndIf

result$ = sha512filefingerprint(file$)

Debug result$

correct$ = "f083039442f4a8cee2985641fa49cada4ca54d9bf3de03f9ef9f1f726dbb655d2a844aa1014e54fd239a5b3f37ae46d64744fee51ab2d7f5fe9b209e90b5ad52"

If result$ = correct$
  Debug "Passed"
Else
  Debug "Failed"
EndIf

If the sha256 include is uncommented, not only are the results wrong but they are different every time. Note that no sha256 hashes are being run first, just the include is placed first. And there's no code outside of procedures except that for defining the structures and prototype. Removing the prototype didn't help.

[netmaestro]

Found it. Both programs were using a structure called UINT8_BUFFER, but they are different sizes in each program. When I initially put HashSlinger together, the compiler complained of a structure already defined. So I encased the structure definitions in a CompilerIf block to only declare them if they were not already defined. I didn't stop to notice the buffers were not the same size. The sha256 UINT8_BUFFER is smaller by half and so if it appeared in the code first, that's the one that got used. This made sha512 fail because the buffer was too small and the reading went on into another buffer. The purifier was happy because all the writing took place inside properly allocated memory. Changing the order fixed everything because the buffer defined by sha512 was large enough for either program and the sha256 program never read past halfway, so no errors there.

[Helle]

Yepp, now is conformity ! I made tests with files up to 4.6GB.
Helle