Cyptmon wrote: > Yes, I saw that we could use the Update method and then call final, > but I was wondering about the implementation of the SignMessage > method, does it hash the data we pass to it in blocks of 512 bits and > finally compute the signature on the resulting hash? > > And If I do something like this > > RSASS< PKCS1v15, SHA >::Signer signer( keys ); > Signer.SignMessage and pass the hash that I generated using the update > method, will it not internally try to hash the data that I pass to it > and then sign it? > > I am very confused and I am sure these questions might sound silly, > but thanks for your help
I am likely still not answering your question(s), but I will mention that the essence of [cryptographic] hashing is that your ENTIRE message feeds into the resulting digest... which sort of dictates that, as each chunk is processed, a running "partial result" (if you will) is used as input to the next chunk. Also probably not what you are looking for, but each hash algo has its own internal processing size, based on the size of the required digest (128 bits for MD5, 160 for SHA-1, and 256 for SHA2-256). This is NOT particularly related to the external chunk size that is handed to each low-level invocation of Update. For instance, I often use 16KB as the file read buffer size when hashing an entire file - a nice one-size-fits-all number, and Update doesn't really care if I use that, or 1MB, or 512 bits at a time. > On Oct 21, 4:19 pm, Robert Roessler <[EMAIL PROTECTED]> wrote: >> Cyptmon wrote: >>> Is there a way to calculate the message digest using a chained >>> approach, wherein, I calculate the hash of data 512 bits at a time, >>> use this hash as an IV for the next round and finally get the hash of >>> the large chunk of data. At any time I do not want to be working on >>> more than 512 bits of data. Can I get this digest and then sign it >>> and subsequently verify it ? Or do we always have to pass the entire >>> data to the Signer class? >> Well, sure, you could repeatedly just call the Update method of a >> HashTransformation-derived object with the next 64 bytes of your data, >> and then whatever "change" is left over the last time. >> >> Then call the Final method, passing a pointer to where you want the >> computed digest to be stored. >> >> But this *is* something of a manual method, and Crypto++ is typically >> used at a higher level. ;) Robert Roessler [EMAIL PROTECTED] http://www.rftp.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the "Crypto++ Users" Google Group. To unsubscribe, send an email to [EMAIL PROTECTED] More information about Crypto++ and this group is available at http://www.cryptopp.com. -~----------~----~----~----~------~----~------~--~---
