HashFile V1.09

[David Roberts]

In V1.05 a feature was added whereby pressing Enter when the cursor is in the HMAC shared key text box for both 'Text string' and 'Hex string' would have the entry obscured.

A binary key is preferable to text string pass-phrases but they are nothing like as convenient so a 'half way' house has been available where we can use a pass-phrase and then hash it with the resulting hash value becoming our shared key. We had then a way to hash text as a by-product of this latter feature even though HashFile is intended for, obviously, hashing files.

However, this by-product was limited to single lines so Pasting a multi-line Copy will see second and subsequent lines, if any, being clipped.

The HMAC text box has been extended to allow multi-line entries when 'Text string' mode is chosen. It was felt undesirable to allow the text box to dominate so only three lines are shown but horizontal and vertical scroll bars are available.

The procedure for hashing text is the same as hashing a pass-phrase: Enter the text, click on the '<H' button and then click on the '<C' button to place the hash value onto the clipboard; although for pass-phrases we need only save on their first outing.

A by-product of this feature is that we can now use multi-line pass-phrases.

Of course, HashFile does not see this as a by-product - it could not care less whether data entered in 'Text string' mode is a pass-phrase being hashed or text in its own right being hashed.

We have now lost the facility to obscure data entered via the Enter key in 'Text string' mode. Rather than have two methods, one for 'Text string' and one for 'Hex string', the Enter key has been replaced by the Escape key for obscuring when the cursor is in the shared key text box.

That is it - no big shakes really so only a revision to V1.09 has been given.

It should be noted that for Windows 95/98/Me the maximum text length that a multi-line text box can accommodate is 64KB whereas for NT/2000/XP, and probably Vista, it is -1 which I read as the lesser of available RAM and 4GB. For more than 64Kb and Windows 95/98/Me the solution is to simply save the text to file and then hash the file.

[David Roberts]

You may be tempted to paste a great wedge of text into the above extension as a pass-phrase. That is fine and not a bad idea.

However, it is possible that the resulting hash value for a given file is the same when we hash that very same text to be used as our shared key.

All the algorithms implemented work on 64 byte blocks. If a key exceeds 64 bytes then, in accordance with the HMAC protocol, it is hashed by the algorithm about to be used on the given file. So, with 40KB, say, of text and SHA1 then a 160 bit binary key is created. On the other hand if we hashed the text via the '<H' button since the result would be less than or equal to 64 bytes no further processing would be involved. Both approaches then will produce the same binary key and thus the same hash value for a given file.

In practice, with such text sizes it is better to hash the text ourselves otherwise the text will be hashed on each and every hashing session. This can be corrected programmatically but it is not worth the hassle.

This is another good reason to hash text strings and share a hex string.

[David Roberts]

A Drag and Drop facility has been added to the above.

With HMAC selected, simply drag and drop a file onto HashFile's dialog. Its contents will populate the HMAC shared key text box. In 'Text string' mode whilst any type of file may be dropped it may be preferable to use only text files from a readability point if nothing else. No check is made on the validity in 'Hex string' mode as this is taken care of by HashFile anyway.

It may be worth noting that dragging and dropping was found acceptable when the text box was in an obscured state even though the flags ES_READONLY and ES_PASSWORD are used. Editing and Pasting are, of course, not possible with such an obscured state. This behaviour is blocked as it is not desirable in this case.

[John Gleason]

Hey there Dave, it's possible this may be a Win98SE quirk or something, but it won't save the hash to a file unless I change the drive to save it to a couple times first. Copying and pasting it elsewhere is no big deal of course. Also on exit, when the message box warning to clear the cache came up, the program stopped responding and I had to force it closed. These are just a couple minor issues but I thought you might like to know.

[David Roberts]

Hi John

That message box should close after three seconds and uses code the Windows Compiler forum was looking at Jan 2007. I reckoned that it would work on 9x and XP.

I have uploaded HashFile98.zip which will unzip to HashFile98.exe to replace HashFile.exe. The 98 version uses a standard MessageBox.

> it won't save the hash to a file unless I change the drive to save it to a couple times first.

That I don't understand - I'm just using SaveFileDialog from ComDlg32.inc ( 1 Nov 2006 ).

Added: HashFile98 has been removed. HashFile now checks the OS - a standard Messagebox is used when OS is Win9x/Me and a timed Messagebox otherwise.

[David Roberts]

I knocked the 98 version out quickly as I didn't want one of my apps failing to respond.

What I will do is an OS check in HashFile but before doing that can anyone else confirm John's experience?

[John Gleason]

Thanks Dave, I checked it out. There was no problem on exit after a couple hash creations, the message box was fine. And it does save consistently, but it first takes a couple directory changes to do so (I originally thought it needed drive changes).

[David Roberts]

Hi John

> There was no problem on exit after a couple hash creations, the message box was fine.

HashFile or HashFile98?

[Michael Mattias]

The GetOpenFilename function will change the current directory as the user browses unless you use the OFN_NOCHANGEDIR flag in the OPENFILENAME structure.

But I generally avoid having to worry about doing a CHDRIVE/CHDIR by always using fully-qualified file names in my OPENs and/or saves.

[David Roberts]

From Platform SDK

OFN_NOCHANGEDIR

Restores the current directory to its original value if the user changed the directory while searching for files.

Windows NT 4.0/2000/XP: This flag is ineffective for GetOpenFileName.

[Michael Mattias]

I guess that's why I always use fully-qualified filennames.

I must have been doing this stuff too long. I have everything on automatic pilot (code libraries) and tend to forget why I did everything the way I did.

[David Roberts]

And I've been away from '98 long enough for my grey matter to forget '98 protocol.

EG hashfile.exe.sg0

Isn't that first period causing you a problem John on '98? It would be very easy for me to change that to hashfile_exe.sg0.

[David Roberts]

Noticed that HashFile98 had 7 views. All it did was remove the timed Messagebox so, perhaps, others had problems?

OK.

Version 1.10 has been uploaded.

If '<C' is used at least once then an information message box is displayed reminding us that the clipboard requires to be cleared; introduced in version 1.08.

9x/Me kernel

Message box needs to be acknowledged before HashFile closes.

Hash value file names are offered to be saved in the form similar to filename_ext.sg0

Non-9x/Me kernel

Message box is displayed for three seconds before HashFile closes.

Hash value file names are offered to be saved in the form similar to filename.ext.sg0

[John Gleason]

> HashFile or HashFile98?
I used HashFile98 that second try.

>Isn't that first period causing you a problem John on '98? It would be very easy for me to change that to hashfile_exe.sg0.
I thought that might be the problem originally, so I tried renaming, and even tried a few of the old xxxxxxxx.xxx styles, but no joy.

If the problem is a win98 thing, hey fugitaboudit I have a couple work-arounds.

[David Roberts]

HashFile98 was a temporary fix and has now been dumped. I didn't want to update, as and when, two apps.

> If the problem is a win98 thing, hey fugitaboudit I have a couple work-arounds.

I suppose it must be but I don't know what.

Anyway, if anyone has a similar problem don't 'phone me, phone John Gleason.

HashFile had been dormant for a while and the Hash Text idea sneaked up on me. That begged for a Drag and Drop. If a bunch of hash values are put into one folder then a Drag and Drop on the second text box would be handy. If we are going to two then may as well go the whole hog on three. That is next - what a PIA.

[John Gleason]

Indeed, if anyone has a similar problem, I'll phone you. :yahootongue:

[David Roberts]

OK, we now have Drag and Drop on all text boxes.

The HMAC shared key text box behaviour is as above.

Dropping onto the first text box sees a path dropped.

Dropping onto the second text box with 'Hash value' not selected, with the 'Straight comparison' button displayed, sees a path dropped.

With 'Hash value' selected and 'Read/Screen' mode the dropped file's contents are inserted and 'Read/File' mode sees a path dropped.

That is it, I'm out of here now unless someone spots a bug.

Version 1.11 uploaded.

[John Gleason]

>OK, we now have Drag and Drop on all text boxes.

Coowool, I did miss that function, but didn't really want to say too much. Ya know, bite the hand that feeds and all.

[David Roberts]

Thanks, John.

[David Roberts]

This is purely cosmetic and has been bugging me for a while. The second text box entitled '2nd File/Hash' should have been intelligent enough to show either '2nd File' or 'Hash' - the second navigation button knew what day it was.

This has allowed removal of some of the space at the bottom left of the form giving a better centre of gravity.

V 1.12 uploaded