Comments re SHA256/384/512 in XP SP3

[David Roberts Member Find all posts View Profile Close David Roberts]

Hi Rick.

Nice library.

It is very much an enthusiasts library. What I have tried to do in both the AES128' and SHA256' threads is to present source code, warts and all, for enthusiasts to kick around and, hopefully, get back to me with better ways on both coding and features. I am mindful, however, that most folk would rather watch paint dry than get involved in crypto work but, notwithstanding that, they may have a need for some crypto stuff so the dlls that I have knocked out have been designed to be one-liners with the minimum number of parameters and rarely used or best avoided ones as optional.

I ran your library on a 100MB file and found that the AES256 encryption/decryption took about 45 seconds whereas my AuthEnc2.dll took about 10 seconds and that included a SHA512 authentication. I cannot tell from your assembly what you are using exactly. I looked at CAPICOM a liitle while ago and found that memory usage was such that I coudn't test a 100MB file with 2GB of RAM on board. I saw from Task Manager that my memory usage did not jump up to the roof with your library any more than it does with mine. If anything your set up is leaner than mine but at our levels it is not worth bothering with as stack usage and so on will differ and be significant on low memory usage overall. It would be interesting to see how your library behaved with hashing a 100MB file but I couldn't see a CRCAPI_HASH_FILE and haven't had time to write some stuff to try.

Maybe I wasn't using CAPICOM correctly because I see that you are using Base64 suggesting that you are using CAPICOM. I also see that you have SHA224 and CR6 neither of which are in the CryptoAPI.

For messages which are not large the difference between COM and raw API may not add to much and may be tolerable for small projects with large files but it may bite with large projects and large files.

[Rick Kelly Member Find all posts View Profile Close Rick Kelly]

I'm not surprise at your results - I basically wrote self-contained wrapper functions that do not use the crcapi.dll library in it's most optimum way. I rarely encrypt/decrypt large files in my projects and when I originally wrote the code was leary of using optimized MMX when my clients at the time were a mix of older cpu's and even still on W95/98. It might be time to rewrite the encrypt/decrypt core routines.

The CRCAPI.DLL source is 95% of what the original source for PW32CAPI I posted a link to. The MS CAPI api's are not used and only basic W32 api's for memory and file management are used.

There is a wrapper function in the sample for hashing files.

FUNCTION CRCAPI_FILE_HASH (BYVAL dwAlgorithm AS LONG, _
                           BYREF sFile AS ASCIIZ * %MAX_PATH, _
                           BYVAL dwReturnHexHash AS LONG, _
                           BYREF sHash AS STRING, _
                           BYREF dwError AS LONG) AS LONG

Set dwReturnHexHash to %TRUE and the results are returned as a hex string in sHash.

 
DIM sHash       AS LOCAL STRING
DIM dwError     AS LOCAL LONG
 
   CRCAPI_FILE_HASH (%CALG_SHA_256, _
                     "100mbfile.xxx",
                     %TRUE,
                     sHash,
                     dwError)
 
   MSGBOX "File hash is " + sHash

Rick

[David Roberts Member Find all posts View Profile Close David Roberts]

Thanks Rick. I didn't spot that wrapper.

We have a different story with Hashing. Your code is crunching a 100MB file at about 10% faster than mine. However, when we are looking at a handful of seconds to do a job then 10% is neither here nor there and, of course, mine is PB save for the little hex string test.

Great stuff.

[David Roberts Member Find all posts View Profile Close David Roberts]

Rick, where the devil did you get %CALG_TWOFISH_128/192/256 from? Google came up with nothing and I couldn't find them at MSDN and they are not in the Windows Server 2008 WinCrypt.h.

I've just been reading that TwoFish is "somewhat faster" than AES at the 256 bit level. With your library a 100MB file was encrypted/decrypted in just over 11 seconds. That is an enormous drop on your AES implementation and only marginally slower with my library. If it is suffering in the same way as the AES then in my current environment it will leave the AES standing.

It might be time to rewrite the encrypt/decrypt core routines.

I'll second that unless you can put me onto the ALG_SID_ values and they are lurking in the CryptoAPI.