CHK wishlist

[encode]

Actually I really frequently use the CHK to check file integrity, integrity of decompressed files, for file comparison, etc. The tool is not popular but it can be, I guess.

First of all, what can be added in next version (CHK v1.03):

* MUCH faster processing. I'm not satisfied with current CHK speed. I have much faster than overage PC (4.6 GHz CPU, no HHDs, all disks are SSD that provides actual 500+ MB of read and write) and even on my PC, I should wait for ENWIK9 processing - no way! Main thing that will be improved is SHA1 computation - I collected a few ideas for speed improvements. BTW, Matt, check out OpenSSL's SHA1 implementation, especially SHA1's Round1 and Round3. And, probably, I'll remove compression Ratio estimation.

* Most likely I should add MD5 computation - it's too popular to ignore. SHA2 is not that popular and slower - thus can be ignored, I guess. As soon as SHA3 will be approved (March 2012 or later, candidates are known already), I'll add it! Probably I should add a hash selection (CRC or MD5 or SHA1 - for speed), or, all hashes at the same time in different columns.

* "Type" column. So you will able to sort out EXEs and compressed files as example.

* "Check For Updates". (Menu "Help->Check For Updates")

* Some GUI improvements, like better icons etc.

Anyway, do you have any ideas? Looks like CHK's layout and logic are quite unique, other hash calculators or duplicate file finders looks much different. Some ideas that floating around are : File Signing, some basic Encryption capabilities, some basic Compression capabilities, File Transfer capabilities (EMail, File Copy), ...

[m^2]

2 thoughths: -I don't find it useful unless it's a command line tool. -directory mode should output 1 checksum for the entire directory. For sure, taking into account not only file contents, but also names. And optionally a selection of other parameters. ADDED: I don't know what's up, for some time my posts end up stripped of newlines.

[Black_Fox]

I would find it useful to be able to move and possibly show/hide columns. Currently filename and filepath are on opposite ends of window and not really reachable "together" if needed. Additionally, some programs allow to select hashes which will be applied on currently selected file(s) and also to hash strings instead of files.

[encode]

... Currently filename and filepath are on opposite ends of window and not really reachable "together" if needed.

Check out this screenshot:

[Black_Fox]

Nice wallpaper, but still the Name column is at far left and Path column at far right. I understand what you're trying to show, but after adding some more hashes window will not even fit on FullHD monitor
Let's not propose any specific usecases anymore. Will it be possible to just rearrange columns arbitrarily, maybe even show/hide columns just as in Win7's Explorer?

[encode]

FullHD (1080p) is not a high resolution these days. The screenshot above is in QuadHD (1440p).

Okay, I'll take into account your suggestion! The reason I did not yet added this thing is that it may slow down the program - i.e. instead of dealing with column simply by its index I must check each time for column's caption...

[Black_Fox]

Ah, 30" LCD Didn't realize first time. Also there is 4K coming behind the corner.

How about caching column indices/indexes in variables and modifying them only when column order changes? That way you could have columns[sha1][elem_num].

[chornobyl]

1 fixed width font for hashes
2 uppercase/lowercase hash switch

[FatBit]

Good morning Mr. Encode,

my recommendations for your newer CHK are:

* Ability to work from NO rewritable medium (CDROM)
* Without any installation, only copy.
* Only one (exe) file, at least small number of files
* Command line interface + optional GUI
* Possibility of user's choose of the hash algorithm (like program Easy Hash)
* Simple adding of other hash libraries
* Ability to compute and to check file consistency for structure (many folders with ### k files)
* Compression ratio estimation is nice, but should be optional for computing

Sincerely yours,

FatBit

[encode]

* Ability to work from NO rewritable medium (CDROM)
* Without any installation, only copy.
* Only one (exe) file, at least small number of files
* Possibility of user's choose of the hash algorithm (like program Easy Hash)
FatBit

These are done already. CHK is just one EXE and need no installation, can run from any place. CHK did not create any temp or config files. CHK did not touch the Windows Registry.
In next version you will able to choose hash functions.

[encode]

Some SHA1 timings on ENWIK9 (including I/O):

CHK 1.01 - 18 sec (VCL-based SHA1)
CHK 1.02 - 17 sec (RFC SHA1 + CRC + Compression Ratio Estimator)
CHK 1.03 - 6 sec (Speed optimized SHA1)

About three times faster!

Tested CHK with bundled CRC16, CRC32, MD4, MD5 and SHA1. Not really liked what I've got.

For sure I should keep CRC - as super fast checksum and SHA1 as fast enough and secure enough hash.

MD5 is really popular, but deprecated since it is broken and two different strings sharing the same MD5 are found.

Check out two different files with the same MD5 hashes, and think once again about use or not this message digest:

[encode]

Added SHA-256!

Okay the hash sets that can be added are:

Mini:
SHA-1
SHA-256

Midi:
CRC
SHA-1
SHA-256

Maxi:
CRC
MD5
SHA-1
SHA-256

As with archivers/compressor you can select Fast (but not that secure) to Secure (but not that fast) hash.

Some timings:

ENWIK9:
CRC -> 3 sec
SHA-1 -> 6 sec
SHA-256 -> 10 sec

8 GB DVD image:
CRC -> 26 sec
SHA-1 -> 56 sec
SHA-256 -> 90 sec

Actually Borland C++ is a really stupid compiler. My Visual C++ and Intel C++ compiles are somewhat faster. Anyway... it is still faster than many GUI hash calculators I tested so far.

Currently have no luck with MD5 - my implementations works not correctly, plus it is slower than my SHA-1. Anyway, my implementations of SHA-1/SHA-256 are clean and small, unlike all implementations I read so far (RFC, OpenSSL, Crypto++, etc.)

SHA-1 source is 1.85 KB, SHA-256 is 2.71 KB.


Added list view. For quick file browsing.

I have an idea about "Verify" command. Select file, press "Verify", paste a checksum into window displayed, press OK and you're done!

Currently CHK will verify files only if you sort files by hash.

Thinking about "do I need "Type" column?"

[osmanturan]

Borland C++ and Delphi compilers produce really inefficient code. It looks like you focused on speed optimization now. So, do you ever consider to write a DLL for better speed? I mean, just group your algorithms in a different DLL and compile it with GCC or IC.

[encode]

DLL is a bad idea. But statically linked library is a good idea indeed

BWT, nice glasses!

[encode]

[Black_Fox]

Nice and promising!

[Fallon]

Hi. Saw an earlier version and will again have a look later.
Meanwhile.. two good hash freebies for stand alone file integrity verification [among the bad]:

Nirsoft's HashMyFiles.
http://www.nirsoft.net/utils/hash_my_files.html

MD5summer.
http://www.md5summer.org/
It follows a sort of standard in the way it checks and is compatible with others that do (or did) the same.
Missing: drag and drop.

MD5summer with other icon [hack]:
https://sites.google.com/site/fallon...edirects=0&d=1

[encode]

Check out design prototypes:

1. Aero
2. Original (Round error sign)
3. Original (Triangle error sign)

What you'd prefer? IMO number three is the most interesting.

[przemoc]

I would say triangle error sign from 1 and round ok sign from 2/3 look the best.
Triangle error sign from 3 is too washed-out for my taste.

[encode]

New prototypes - 4...9

[encode]

and 10's

[encode]

Take into account that "Error icon" usually should not appear.

[Fallon]

Check out design prototypes:

1. Aero
2. Original (Round error sign)
3. Original (Triangle error sign)

What you'd prefer? IMO number three is the most interesting.

Seven has uniformity of style. Buy you can enjoy your pick. All will do.

[przemoc]

Actually 9 is now better than my mix (shown by 4), because of less standing out round ok sign (compared to triangle error sign, after all ok is ok, so there is no need to emphasize it).

Seven has uniformity of style. Buy you can enjoy your pick. All will do.

Sure 7 is uniform, but almost look like combobox that I can check myself, thus it is UX fail. 10 is better here, but I don't like upside-down page icon.

IMO now the real contenders are only 9 and 10 (assuming a fixed page icon, i.e. upside-up or taken from 9), but it's your program, encode, so do as you feel is right (and provide options to change the default icon set :>).

[encode]

Okay I will use program myself during development and will check usability of each variant myself.

Anyway, what I've got now:

"Verify" command added (check out screenshot). If checksum match, the OK sign will appear, or else a error message will be shown.

Now, if you change the checksum type, CHK will recalculate checksums for all files in the list. Useful.

"Copy info" command copies a string with followed layout:

cryptopp561.zip (SHA-1: 31DBB456C21F50865218C57B7EAF4C955A222BA1)

If SHA-1 was chosen. Fell free to suggest preferred layout.

[przemoc]

"Verify" command added (check out screenshot). If checksum match, the OK sign will appear, or else a error message will be shown.

And what with verifying more than one file? Dialogs are nuisance, but if you have to use them, make them more self-contained and as low in number as possible. So there should be filename shown somewhere (on the left, possibly), thus giving you also an idea how to deal with more than one file to verify - selecting more than one file, RBM, verify would give only one dialog with list of filenames followed by textbox for hash input. It's also unclear how you deal with different hashes here. In dialog box there could be radiobuttons at the top for each possible hash (using comboboxes here, i.e. supporting verifying more than one hash, would rather clatter the UI).

Now, if you change the checksum type, CHK will recalculate checksums for all files in the list. Useful.

Useful for some, burden for others. Add option whether hash should be (re)calced automatically [turning it on by default, as you think it is good] and if it is turned off then Rehash top-level menu command (no submenus!) should be available in the main window.

"Copy info" command copies a string with followed layout:

cryptopp561.zip (SHA-1: 31DBB456C21F50865218C57B7EAF4C955A222BA1)

If SHA-1 was chosen.

This information layout isn't good for more than one hash, thus it should have its own option too. There are 3 useful possibilities:

1.
file1 (hash1: ..., hash2: ..., ....)
file2 (hash1: ..., hash2: ..., ....)
...

2.
file1 (hash1: ...)
file1 (hash2: ...)
...
file2 (hash1: ...)
...

3.
file1
hash1: ...
hash2: ...
...

file2
hash1: ...
hash2: ...
...

...

For one file and one hash 1 & 2 are obviously equivalent.
1 is compact and its main merit, but I haven't seen it used in the wild.
2 is more readable.
3 is the most readable one.

Another option is whether file size should be provided in such info too (layout stays the same, size is just like hash0, preceding other ones)

Apart from this, support for copying of particular hashes alone is a must (like Copy SHA-1, etc.), possibly with keyboard shortcuts (maybe similar to HashMyFiles?). What has to be considered here is whether to show in context menu hashes not chosen in options, i.e. whether to support ad-hoc hashing. IMO you should avoid it, as copy suggest you can do it immediately, otherwise user will be (legitimately) irritated.

EDIT
I'm not on Windows now, so cannot check, but does CHK supports checking hashes against common files storing them? Like .sfv (for CRC32), md5sums, sha1sums, sha256sums, etc.

Support for auto-checking CRC32 of files having them in name (in square brackets at the end of file name, before extension) would be useful too. Same goes for possibility of fixing such CRC32 in file name (if it is wrong) or just adding it (in case if there is none yet).

[Black_Fox]

Check out design prototypes:

What you'd prefer?

I like 4 and 10 the best, final choice depends on how critical the error is. I read yellow exclamation mark as "warning", cross on red circle as "error".

[encode]

Tested CHK during a few weeks and made some changes. Somehow I don't like the hash selection a la SHA-1 OR SHA-256 OR ... It is much better if you will able to activate or deactivate each has calculation independently - thus you can compute many hashes simultaneously - check out the "menu.png"!

Now, in Validate window prompt you may enter any hash - CHK will check all available hashes for selected file and if one will match - file verified!

Just purchased new icons, hence check out new design prototypes - 11 to 14:

What do you think?

[Black_Fox]

11 is the current overall winner for me. The separately switchable hashes are also a good idea in my opinion
As przemoc asked before: Will CHK work with hashlists? "Like .sfv (for CRC32), md5sums, sha1sums, sha256sums, etc."

[encode]

I'm not planning hash lists yet. CHK is not about mass file checking and such. It's more about single or just a few files signing and checking. For mass file checking CHK must have a scanner-like interface. Instead, I'm focusing on PGP/security like features like file signing, at least looking to this side.
The main goal is to check files for correct decompression, other features are just useful additions.