A File Checksum Shell Menu Extension DLL

Introduction

A File Checksum is used to verify the integrity of a file. Checksums can detect both transmission errors and tampering. To detect transmission errors, we would use a CRC (cyclic redundancy check) [1]. To detect tampering, we generally choose a cryptographic Hash due to the desirable property of Collision Resistance [2].

This article presents two Shell Extension DLLs which can be used to create file checksums and verify file checksums. The article is based on Michael Dunn's Guide to Writing Shell Extensions, Part I [4], Tom Archer's Using the Clipboard, Part I: Transferring Simple Text [5], and Crypto++. This article will discuss the following topics:

• Shell Extension DLL Usage
  • Windows Vista and User Account Control
  • Visual C++ Runtime
  • Checksum Creation
  • Checksum Verification
• Compiling and Integrating Crypto++
• Windows Clipboard APIs
• Creating a Shell Context Menu Extension DLL
  • Composition
• Crypto++ ChannelSwitch Class
• Command Line Debugging
  • Attaching to Explorer
  • Frozen Explorer or Debugger
  • Loaded Modules
  • Breakpoints
• Managing an Unstable Windows Explorer
• Character Set Considerations
• Create and Verify Routines
  • Initialize
  • Create InvokeCommand
  • Verify InvokeCommand
• Miscellaneous
• Visual Studio 2005 and Platform SDK

Microsoft offers a command line file checksum tool published under Knowledge Base article Q841290, Availability and Description of the File Checksum Integrity Verifier Utility [6]. The Microsoft tool supports MD5 and SHA1.

Shell Extension DLL Usage

Should the reader desire to use the Extension DLLs, he or she should download and install as described below. Once the DLLs are registered, they are available as Context Menus when one right clicks a file (or multiple files) in Windows Explorer.

• Download the DLL
  • CtxCreateHashDll.zip
  • CtxVerifyHashDll.zip
• Unpack to C:\Windows\System\
• Register the DLL
  • regsvr32.exe C:\Windows\System\CtxCreateHash.Dll
  • regsvr32.exe C:\Windows\System\CtxVerifyHash.Dll

Windows Vista and User Account Control

To manually run regsvr32.exe under Vista with User Account Control enabled, navigate to the Command Prompt from the Start menu. Right click the Command Prompt and chose Run As Administrator as shown in Figure 1.

Figure 1: Run As Administrator

Neglecting to run regsvr32 with elevated privileges will usually result in the error, "DllRegisterServer failed with error code 0x80070005," while success is the familiar succeeded shown below.

Figure 2: DllRegisterServer Success

Visual C++ Runtime

The latest versions of the compiled DLLs are built and linked with Visual Studio 2008. If required, download the Microsoft Visual C++ 2008 Redistributable Package. A classic example of requiring the package is regsvr32 failing to register the DLLs with the error, "This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem"

Checksum Creation

After selecting a files or files, if the user selects Create Checksum, the following hashes are created and placed on the clipboard:

• MD5
• RIPE MD-128, RIPE MD-160, RIPE MD-256, RIPE MD-320
• SHA-1, SHA-224, SHA-256, SHA-384, SHA-512
• Whirlpool

A Message Box is then displayed with the digest of the hashed file or files. A truncated version is displayed to keep the message box size manageable.

Figure 3: Truncated Message Box

The full checksums are placed on the Windows Clipboard for pasting. Pasting into Notepad from the clipboard reveals the full text.

Figure 4: Clipboard Text

Checksum Verification

Verifying a file's checksum is equally trivial. Navigate to the web page or document where the checksum resides, highlight, and copy to the clipboard.

Figure 5: Copy Checksums to the Clipboard

Navigate to the files, select, right click, and chose Verify Checksum.

Figure 6: Verify Checksums

Supported verification algorithms are:

• CRC32
• MD2, MD4, MD5
• RIPE MD-128, RIPE MD-160, RIPE MD-256, RIPE MD-320
• SHA-1, SHA-224, SHA-256, SHA-384, SHA-512
• Whirlpool

A message box will be presented similar to below. The message box will group files in two categories: verified and unverified. A verified file will display the message "Verified Checksum" with a digest of the checksum. An unverified file will under the heading "Unverified Checksum"

Figure 7: Verify Checksum Message Box

When verifying, the DLL searches for matching hash values in order from strongest to weakest (SHA-512 to CRC32). The match algorithm terminates on a first match, so only the strongest hash is displayed.

Compiling and Integrating Crypto++

The samples provided use various Crypto++ Symmetric Ciphers. Crypto++ can be downloaded from Wei Dai's Crypto++ page. For compilation and integration issues, visit Integrating Crypto++ into the Microsoft Visual C++ Environment. This article is based upon basic assumptions presented in the previously mentioned article. For those who are interested in other C++ Cryptographic libraries, please see Peter Gutmann's Cryptlib or Victor Shoup's NTL.

Windows Clipboard APIs

Please see Tom Archer's Using the Clipboard, Part I: Transferring Simple Text for an in depth discussion on the subject. Sample 1 demonstrates enumerating the Clipboard's data formats. Sample 2 demonstrates reading text from the Clipboard. Finally, sample 3 demonstrates writing Unicode text to the Clipboard.

Figure 8: Writing Clipboard Text

Creating a Shell Context Menu Extension DLL

Creating a shell context menu is based extensively on Michael Dunn's Guide to Writing Shell Extensions, Part I. Please refer to Michael's article for the discussion. Michael's techniques works well for inserting a single menu item, or multiple menu items for Windows 2000.

Composition

Unlike Michael's article, we will have to use a slightly different technique when we call InsertMenu on Windows XP, Server 2003, and Vista. This is due to Composition. Composition is a technique that Windows XP and above use to group context menu items together. In Figure 9 we see two examples of composition. Adobe is providing two DLLs which are grouped together, and the checksum DLLs are being grouped together.

Figure 9: Composition

For a discussion of Composition, see Raymond Chen's series on The Old New Thing. The two chapters of interest are Chapter 10: Composite Extensions - Groundwork and Chapter 11: Composite Extensions - Composition. Keep in mind that Chen's sample code is presented from the shell's perspective rather than our perspective. Due to the side effects of composition in Windows XP, Server 2003, and Vista, we must insert menu items as follows:

InsertMenu( hmenu, uMenuIndex, MF_STRING | MF_BYPOSITION,
  uidFirstCmd+1, _T("Create Checksums") );

// Return that we consumed two IDs rather than 1.
// This is because we skipped ID 0 (uidFirstCmd), and
// added ID 1 (uidFirstCmd+1)
//
// This means we must handle Command 1 in InvokeCommand(),
// rather than Command 0
return MAKE_HRESULT( SEVERITY_SUCCESS, FACILITY_NULL, 2 );

If we added two menu items, our routine would be as follows:

InsertMenu( hmenu, uMenuIndex, MF_STRING | MF_BYPOSITION,
  uidFirstCmd+1, _T("Item 1") );
InsertMenu( hmenu, uMenuIndex, MF_STRING | MF_BYPOSITION,
  uidFirstCmd+2, _T("Item 2") );

// Return that we consumed three IDs rather than one or two.
// This is because we skipped ID 0 (uidFirstCmd), and
// added ID 1 (uidFirstCmd+1) and added ID 2 (uidFirstCmd+2)
//
// This means we must handle Command 1 and Command 2
// in InvokeCommand(), rather than Command 0
return MAKE_HRESULT( SEVERITY_SUCCESS, FACILITY_NULL, 3 ); 

The shell's algorithm which determines what items should be composted (and how they are arranged) is not available. But it appears that it depends on:

• Registry string name of the DLL
• Number of leading characters which match in a string compare

It appears the algorithm resides somewhere in the Shell's Shell32!_imp__DSA_InsertItem function. The rule of thumb observed is if two or more characters match in the registry string, the items will be composted.

Crypto++ ChannelSwitch Class

Retrieving from the disk multiple times can become a bottleneck for performance. This is especially true if we are reading the same file continuously. To overcome the multiple disk read issue, one can use the Crypto++ ChannelSwitch class. The ChannelSwitch class allows a user to stream data to multiple HashFilter based objects after a single disk read. More correctly, one can push data to any BufferedTransformation derived object. This is trivial when performing string (in memory) based operations; however disk based operations tax response times. One would not want to read a 1 MB file 6 times to send it to 6 different consumer objects. Though one could author code to perform the buffering and delegation, the simplest solution is the ChannelSwitch.

Figure 10: ChannelSwitch Overview

ChannelSwitch offers AddDefaultRoute(BufferedTransformation& destination) function to add a destination. HashFilter derives from BufferedTransformation:

Figure 11: HashFilter Inheritance

The abbreviated use of the ChannelSwitch object in the Create Checksum Shell Extension DLL is depicted below.

Figure 12: CreateChecksum DLL ChannelSwitch

An abridged use of the ChannelSwitch object in the Verify Checksum Shell Extension DLL is depicted below.

Figure 13: VerifyChecksum DLL ChannelSwitch

The code to accomplish multiple hashing based on a ChannelSwitch is shown below. Two hashes are created: MD5 and SHA-1. Wei provides the sample code in test.cpp of the Crypto++ library.

#include "channels.h"   // ChannelSwitch
#include "filters.h"    // HashFilter
#include "hex.h"        // HexEncoder
#include "md5.h"        // MD5
#include "sha.h"        // SHA-1, SHA-256, SHA-512
int main( )
{
    MD5 hashMD5;
    SHA1 hashSHA1;

    HashFilter filterMD5(hashMD5);    
    HashFilter filterSHA1(hashSHA1);

    std::auto_ptr<ChannelSwitch> channel(new ChannelSwitch );

    channel->AddDefaultRoute(filterMD5);
    channel->AddDefaultRoute(filterSHA1);
    ...
} 

Earlier, fciv.exe (KB 841290) was mentioned which creates and verifies MD5 and SHA-1 checksums. By changing the StringSource to a FileSource, the reader could have a new and improved fciv.exe less the XML encoding.

The output of the Sample 4 (using MD5, SHA-1, RIPEMD-160, and SHA-256) is shown below.

Figure 14: Sample 4

Command Line Debugging

If debugging using Visual Studio is too difficult or inconvenient, cdb.exe can be used. It is the command line equivalent of WinDbg. CDB can be downloaded from Microsoft in the Debugging Tools for Windows package. Some of the more useful commands for this exercise are shown below.

Attaching to Explorer

To attach to Windows Explorer, issue cdb -pid < pid>, where pid is the process identification number of Explorer. Once attached, Explorer will be suspended since the debugger is awaiting input. Enter g to run.

Figure 15: Attach To Explorer

When Explorer is running, enter CTRL-C to break back into the debugger. Once finished in the debugger, press g again. Finally, ALT-Tab does work with Explorer suspended. It will be useful in getting the debugger window forward when Explorer cannot repaint (and is hiding a view).

Frozen Explorer or Debugger

This section is reiterated from above since it is so important. If Explorer is frozen when attempting to work on the desktop, type g in the debugger. If the debugger is not the windows with focus, use ALT-Tab to bring the debugger forward. Finally, if you cannot enter commands into the debugger, enter CTRL-C to break.

Loaded Modules

Once attached to Explorer, we need to know if our DLL is loaded so we can determine the breakpoint location and set the breakpoint. We can issue a load (ld) specify a full path name, of right click a file to coax Explorer into loading it.

Breakpoints

Issuing x ctx*!*hash* will display symbol locations the two DLLs. The final expression (*hash*) refines the results. This is too much information, since Crypto++ is full of symbols such as these.

To further refine the location search, issue x ctx*!*querycontextmenu. Now that the location is known, issue the breakpoint. Exercise Explorer. bl lists breakpoints. When the breakpoint fires, enter p once to step out of DebugBreak() and into the function. To step into a function, enter t.

Figure 16: Locating Functions of Interest

Managing an Unstable Windows Explorer

This portion of the article is again based on Michael Dunn's Guide to Writing Shell Extensions, Part I. Should the reader find the treatment too superficial, please refer the Michael's article. Michael details topics such as preparing the Windows environment for debugging Windows Explorer to allowing the Context Menu DLL to execute in light of Group Policy.

Before debugging, kill the Explorer process. When prompted for a Debug Executable, specify C:\Windows\Explorer.exe. When debugging begins, Visual Studio will start an instance of Explorer.

Figure 17: explorer.exe

Save your work frequently. Most problems only required restarting Explorer, or an occasional soft reboot. To restart Explorer, open Task Manager and End the Explorer process.

Figure 18: End Explorer Process

Next, switch to the Task tab, and click New Task.

Figure 19: New explorer.exe Task

If the reader builds the DLL, but the DLL cannot be opened to be written during linking, verify no instances of Explorer.exe are running. If no instances are present, restart Explorer.

Figure 20: Explorer Instances

Character Set Considerations

The Context Menu DLLs are written using wide characters since the NT family is dominating the landscape. The Crypto++ library is narrow, and the Windows API can be either.

Figure 21: Checksum DLL Design Overview

Data transfer with respect to Crypto++ is generally from Crypto++ to the DLL. To facilitate the transfer, the DLL calls StringWiden() on the narrow data from Crypto++.

The same is not true for the Windows API. If _UNICODE and UNICODE are defined, no conversion takes place. When using SBCS and MBCS, StringWiden() and StringNarrow() are employed when moving strings between Windows and the DLL.

The conversions will be handled by way of the standard c++ library's widen() and narrow(). Those using Visual C++ 7.0 and above have more flexibility in use of standard library conversion routines.

// Courtesy of Tom Widmer (VC++ MVP)
std::wstring StringWiden( const std::string& narrow ) { 
    std::wstring wide;
    wide.resize( narrow.length() );
    typedef std::ctype<wchar_t> CT;
    CT const& ct = std::_USE(std::locale(), CT);
    // Non Portable
    // Iterators should not be used as pointers (works in VC++ 6.0)
    // wideness( narrow.begin(), narrow.end(), wide.begin() );
    // Portable
    // ct.widen(&narrow[0], &narrow[0] + narrow.size(), &wide[0]);
    // Portable
    ct.widen(narrow.data(), narrow.data() + narrow.size(), wide.data());    
    return wide;
}

Create and Verify Routines

Sample 4 (Channel Switch) and Sample 5 (CtxTest) provides most of the code required for the DLL. This section will discuss the remaining items of interest. The create and verify routines share common code. This would include populating the list of files and the Fly By help.

Initialize

Initialize() has been expanded as follows. Notes that files is a vector of wide string. Once all of the files have been extracted, the vector is sorted based on name.

STDMETHODIMP CCreateHash::Initialize( LPCITEMIDLIST pidlFolder,
                                      LPDATAOBJECT pDataObj, HKEY hProgID )
{
    pidlFolder;     // Suppress Warning C4100
    hProgID;        // Suppress Warning C4100
    FORMATETC fmt = { CF_HDROP,NULL,DVASPECT_CONTENT,-1,TYMED_HGLOBAL };
    STGMEDIUM stg = { TYMED_HGLOBAL };
    HDROP     hDrop;
    ...
    // Sanity check - make sure there is at least one filename.
    UINT uNumFiles = DragQueryFile( hDrop,
                         static_cast<UINT>(-1), NULL, 0 );    
    if( 0 == uNumFiles )
        { return E_INVALIDARG; }
    HRESULT hr = S_OK;
    // The author has encountered situations where
    //   MAX_PATH was a bit too small...
    TCHAR file[ MAX_PATH * 2 + 1 ];
    // Loop through all the files that were selected.
    for(UINT i = 0; i < uNumFiles; i++)
    {
        DragQueryFile( static_cast<HDROP>( stg.hGlobal ),
                       i, file, MAX_PATH * 2 );
        // If the file name is a directory, silently skip
        //   We should not encounter this...
        if (::GetFileAttributes( file ) & FILE_ATTRIBUTE_DIRECTORY)
            { continue; }
        // Add the file name to the end of the list.
        #ifdef UNICODE
          files.push_back( file );
        #else
          files.push_back( StringWiden( file ) );
        #endif
    }
    std::sort( files.begin(), files.end() );
    return hr;
}

Create InvokeCommand

HRESULT CCreateHash::InvokeCommand ( LPCMINVOKECOMMANDINFO pCmdInfo )
{
   // If lpVerb really points to a std::string,
   //   ignore this function call and bail out.
   if ( 0 != HIWORD( pCmdInfo->lpVerb ) ) { return E_INVALIDARG; }

   unsigned int i = 0, j = 0;

   // Friendly Name: 'MD5'
   std::vector< std::wstring > hashnames;  
  
   // Hash: 47FD4214F5775826FB20FEC1091987A1 
   std::vector< std::wstring > hashvalues;

   std::wstring ClipboardText;
   std::wstring MsgBoxMessage;   

   MsgBoxMessage = L"The following was placed on the Windows Clipboard:\r\n\r\n";

   // We must look for Command 1 now
   switch( LOWORD( pCmdInfo->lpVerb ) )
   {
      case 1:
      {
         for( i = 0; i < files.size(); i++ )
         {
            CalculateFileHashes( files[ i ], hashnames, hashvalues );
            ClipboardText += FileName( files[ i ] ) + L"\r\n";
            MsgBoxMessage += FileName( files[ i ] ) + L"\r\n";
            for( j = 0; j < hashvalues.size(); j++ )
            {
               // Clipboard Text is easy...
               //   Just dump the information
               ClipboardText += hashnames[ j ] + L": " + hashvalues[ j ] + L"\r\n";

               ...

            } // End - Keep the Message Box size reasonable
         } // for( j = 0; j < hashnames.size(); j++ )
         // Pretty Print
         if( i + 1 < files.size() )
         {
            ClipboardText += L"\r\n";
            if( files.size() <= 2 )
            {
               MsgBoxMessage += L"\r\n"; 
         } // for( i = 0; i < files.size(); i++ )
         SetClipboardText( pCmdInfo->hwnd, ClipboardText );
         #ifdef _UNICODE
            MessageBox( pCmdInfo->hwnd, MsgBoxMessage.c_str(),
                        _T("File Checksum Results"), MB_ICONINFORMATION );
         #else
            MessageBox( pCmdInfo->hwnd, StringNarrow( MsgBoxMessage ).c_str(),
                        _T("File Checksum Results"), MB_ICONINFORMATION );
         #endif            
         return S_OK;
         break;
      }
      default:            
         break;
   }
   return E_INVALIDARG;
}

Verify InvokeCommand

Verify Checksum InvokeCommand() uses the same basic code and logic as Create Checksum. The difference in this code is the introduction of two additional vectors: vector< wstring > verifiedfiles and vector< wstring > unverifiedfiles for book keeping.

HRESULT CVerifyHash::InvokeCommand ( LPCMINVOKECOMMANDINFO pCmdInfo )
{
    unsigned int i = 0, j = 0;
    UINT style = MB_ICONINFORMATION;
    bool found = false;
    wstring ClipboardText;
    wstring MsgBoxMessage;
    vector< wstring > hashnames;
    vector< wstring > hashvalues;
    vector< wstring > verifiedfiles;
    vector< wstring > verifiedhashes;
    vector< wstring > unverifiedfiles;

    // If lpVerb really points to a std::string,
    //   ignore this function call and bail out.
    if ( 0 != HIWORD( pCmdInfo->lpVerb ) ) { return E_INVALIDARG; }

    HWND hwnd = pCmdInfo->hwnd;

    // If there is no text on the Clipboard,
    //   inform the user and bail out.
    if( false == GetClipboardText( ClipboardText ) )
    {
          MessageBox( hwnd, _T("There is not text on the Clipboard."),
                      _T("File Checksum Verifier"), MB_ICONWARNING );
        return S_OK;
    }
    // We must respond to Command 1 now.
    switch( LOWORD( pCmdInfo->lpVerb ) )
    {
        case 1:
        {
            for( i = 0; i < files.size(); i++ )
            {
                // Hash found on the Clipboard?
                found = false;
                CalculateFileHashes( files[ i ], hashnames, hashvalues );
                // Start at size(): this has the effect of 
                //   verifying strongest (SHA-256) to weakest (MD4)
                for( j = 0; j < hashvalues.size() ; j++ )
                {
                    if( true == Find( hashvalues[ j ], ClipboardText ) )
                    {
                        found = true;
                        verifiedfiles.push_back( files[ i ] );
                        // Concatenate 'MD5: ' and
                        //   '82A80BE6F1E0E7766FAC3CA661089EE4', etc
                        verifiedhashes.push_back( hashnames[ j ] + L": " +
                                                  Snip( hashvalues[ j ] ) );
                        j = hashvalues.size();  // Break the loop
                    }
                } // for( j = 0; j < hashvalues.size(); j++ )
                if( false == found )
                {
                    unverifiedfiles.push_back( files[ i ] );
                }
            } // for( i = 0; i < files.size(); i++ )

            ...

            return S_OK;
            break;
        }
        default:
            break;
    }
    return E_INVALIDARG;
}

This version of InvokeCommand() maintains parallel arrays for simplicity. The arrays are created for each file in the files vector. The arrays can be visualized as follows.

Figure 22: Hash Name - Hash Value Parallel Array

The arrays are created with CreateFileHashes(). The function prototype is below. Both Create and Verify use the function. Create simply dumps it to the Clipboard, while Verify walks the hashvalues vector (from strongest to weakest), searching for the hash value on the Clipboard.

bool CalculateFileHashes( const std::wstring& filename,
                          std::vector< std::wstring >& hashnames,
                          std::vector< std::wstring >& hashvalues )

InvokeCommand() is now presented below. Most of the logic is dominated by maintaining two strings - one for the Message Box, and the other for the Clipboard. Recall that the extra code for the Message Box is required to keep the size of the Message Box manageable.

Miscellaneous

When choosing a hash, one should choose at least a 160 bit hash. Note that hash length does not necessarily equate to strength. For example, RIPEMD-128 is as cryptographically strong as RIPEMD-256; RIPEMD-160 is as cryptographically strong as RIPEMD-320. RIPEMD-256 and RIPEMD-320 simply generate more entropy for a given Message M. The reader should refer to Optional Extensions to 256 and 320 Hash Results: RIPEMD-256 and RIPEMD-320 for details.

Taking from the NIST Website:

There are five (5) FIPS-approved algorithms for generating a condensed representation of a message (message digest): SHA-1, SHA-224, SHA-256, SHA-384, and SHA-512

March 15, 2006: The SHA-2 family of hash functions (i.e., SHA-224, SHA-256, SHA-384 and SHA-512) may be used by Federal agencies for all applications using secure hash algorithms. Federal agencies should stop using SHA-1 for digital signatures, digital time stamping and other applications that require collision resistance as soon as practical, and must use the SHA-2 family of hash functions for these applications after 2010. After 2010, Federal agencies may use SHA-1 only for the following applications: hash-based message authentication codes (HMACs); key derivation functions (KDFs); and random number generators (RNGs). Regardless of use, NIST encourages application and protocol designers to use the SHA-2 family of hash functions for all new applications and protocols.

Finally, taking from the RIPE MD website:

A 128-bit hash result does not offer sufficient protection anymore. A brute force collision search attack on a 128-bit hash result requires 2⁶⁴ or about 2 x 10¹⁹ evaluations of the function. In 1994 Paul van Oorschot and Mike Wiener showed that this brute-force job can be done in less than a month with a $10 million investment ("Parallel Collision Search with Applications to Hash Functions and Discrete Logarithms," 2nd ACM Conference on Computer and Communications Security, ACM Press, 1994, pp. 210-218). This cost is expected to halve every 18 months.

Visual Sudio 2005 and Platform SDK

Should the reader encounter the following issue during compilation:

error C2787: 'IContextMenu' : no GUID has been associated with this object

The reader can add the following to stdafx.h:

#ifndef IContextMenu
  struct __declspec(uuid("000214e4-0000-0000-c000-000000000046")) IContextMenu;
#endif

Doug Harrison, Microsoft MVP, has additional fixes outlined in Missing IContextMenu.

Summary

File checksums are an often overlooked Cryptographic tool. With these DLLs, one can easily incorporate the Checksum functionality into his or her documents or website.

Downloads

• Download Compiled Shell Extension Dll - Create Checksum - 112 Kb
• Download Compiled Shell Extension Dll - Verify Checksum - 97 Kb
• Download Microsoft Visual C++ 2008 Redistributable Package

• Download Source Code - Shell Extension Dll - Create Checksum - 21 Kb
• Download Source Code - Shell Extension Dll - Verify Checksum - 29 Kb

• Download Source Code - Sample 1 - Enumerating Clipboard Data - 3.3 Kb
• Download Source Code - Sample 2 - Retrieving Clipboard Text - 2.9 Kb
• Download Source Code - Sample 3 - Writing Clipboard Unicode Text - 3.2 Kb
• Download Source Code - Sample 4 - Hashing Using the ChannelSwitch Class - 5.7 Kb
• Download Source Code - Sample 5 - Sample Shell Extension Dll - 11.5 Kb

Acknowledgments

• Wei Dai for Crypto++ and his invaluable help on the Crypto++ mailing list
• Dr. Brooke Stephens who laid my Cryptographic foundations

Revisions

• 05.24.2008 Added Vista regsvr32.exe Error
• 05.24.2008 Tested Upgrade to Visual C++ 9.0 (VS2008)
• 03.07.2008 Added VS2008 regsvr32.exe Error
• 12.01.2007 Added Windows XP and Above Composting Issue
• 08.03.2007 Added note on IContextMenu and Visual Studio 2005
• 08.03.2007 Upgraded from Visual C++ 7.1 to Visual C++ 8.0
• 05.31.2007 Upgraded from Visual C++ 6.0 to Visual C++ 7.1
• 05.31.2007 Verified Compatibility with Crypto++ 5.5.1
• 05.31.2007 Removed HAVAL in CtxVerifyHash.dll
• 05.31.2007 Added Additional SHA-2 Hashes in CtxVerifyHash.dll
• 05.31.2007 Added Whirlpool (512) Hash in CtxVerifyHash.dll
• 01.09.2007 Added Reference to NIST Hash Choices
• 12.19.2006 Added Section Crypto++ String and File Hashing
• 12.17.2006 Added CRC32 to Verify Shell Extension DLL
• 12.16.2006 Update Article Graphics
• 12.15.2006 Updated ChannelSwitch
• 12.14.2006 Initial Release

Checksums

• CtxCreateHash.zip
  • MD5: D967CF24BEC8BF403B0F274B7908876E
  • RIPEMD-128: CF073CB397C912EE3395C63F5CCF93FE
  • RIPEMD-160: 324123B69596608381147F0F60C343B3F5C4B007
  • RIPEMD-256: 5A5A18771EAAF7A2E60C83D2FC8EC507389532A1E7F80FD2C38D5E949899A07F
  • RIPEMD-320: C8A01A5A8BA0323CEB25DA4FC45E155E47ACC5BFF7481AECF0C1E4250E5CF07DF7885A9CFD3D8E23
  • SHA-1: 53CFD2F493846CC49EC5209CA7E4C9939D371172
  • SHA-224: 70A8F1066BEAE431E4462E226A4293DB323A096EDE5163A47B83E64C
  • SHA-256: 75DA22C742752DBC73AB421F8A48BCCEC4BDF5486DFF16EB9395C6F499DF9221
• CtxCreateHashDll.zip
  • RIPEMD-128: ABEF419E395A7A21CE9D65A5419842D4
  • RIPEMD-160: 22EF853EAE308F7B07CA674CC50BE6D9929F3649
  • RIPEMD-256:
  • 19CC4D1BFD0B92B9E7D48CB7CE14C0C3F094E8E15EC8EB61C89632C5032D474C
  • RIPEMD-320: D06012A5A9EA47436AFD247B90D179081B64C62CEF3BA20DF35DB85021FFBB386BA7962A289BB224
• CtxVerifyHash.zip
  • SHA-1: B54562A1EC047F31C75027C396CE44DFE6F2020D
  • SHA-224: CB413BAD801E4C9F8043BAF294FA29F0616F449B42E453B9EE1E5941
  • SHA-256: D10E2C892487CC6A17D5C673DE52974F7F0DB701342DD46B1821FD479DBCEC4F
• CtxVerifyHashDll.zip
  • RIPEMD-256: 82BC7E086B8EDA7C1A8C5310F82F31DDEA13BF192482A6D1F362831E8FC2F23A
  • SHA-256: 1602BD0FF62E05F4B77428C5943FE37CB7CCE6367C5D79CCC004E125A2C6266A
• Sample1.zip   
  • CRC32: BD50E874
• Sample2.zip
  • MD5: 0CAE59412D3272C12A4985930F313DC1
• Sample3.zip
  • SHA-1: 68274EDD7A70792057A379048F1FBA6E58048F7E
• Sample4.zip
  • RIPEMD-160: 7434F4A3498A642A53FCC3AF6081718BE18FCE28
• Sample5.zip
  • SHA-256: 3DA6D8C6D29DE726B96838273C5E9D7C558F725BF6574345C054E7FD1325DF42