On Tue, Sep 7, 2021 at 7:45 AM Tom <thoma...@gmail.com> wrote:
>
> I can create HMACs of files using pipelines via filesources but... I can't seem to figure out to verify the HMAC without throwing the file into a string in memory.
>
> like this:
>
> StringSource(plain + mac, true, new HashVerificationFilter(hmac, NULL, flags) ); // StringSource
>
> Is there a way to use a FileSource without loading the file fully into memory?
>
> I think its possible but do I append the hmac if I use a file?
Yeah, that's a problem. We should have some documentation covering it.
I think you need a custom source that takes two sources - the existing
HMAC wrapped in a StringSource and the FileSource. The custom source
then pumps the data to the attached filter.
Another option is a HashVerificationFilter that takes two sources. It
could be tricky since the source is expected to pump its data. I did
not test this option.
Attached is an example. It uses a hash rather than HMAC to simplify the code.
The example has a bug, though. HashVerificationFilter is failing...
However, when I looked at the information provided in this link: https://www.cryptopp.com/wiki/HashVerificationFilter#String_and_File_Sources, it appears that the method suggested to avoid memory usage doesn't actually achieve that goal, as the line FileSource fs("zero.dat", true); in the verification step is performing as intended.
Unfortunately, I am unable to use FileSource fs("zero.dat", false, new HashVerificationFilter(sha256, new StringSink(digest))); or FileSource fs("zero.dat", true... either, because it's unclear how to associate the digest with the input file.
When dealing with the `SignatureVerificationFilter`, similar issues arise due to the requirement of having the "tag" at either the beginning or end of the initial part of the pipeline. Adding the "tag" to the filename within a pipeline that starts with `FileSource` does not resolve this problem. Consequently, `FileSource` may attempt to load an incorrect file or, when using an `ifstream`, cause a compile-time type mismatch.
While attaching the "tag" to a file that already has it may seem logically sound, this approach can disrupt the functionality of certain files. For example, executable files cannot have the "tag" prepended, and appending the "tag" can lead to extraction tools generating errors about extra data, especially in the case of archives. Furthermore, this method renders simple hash checks invalid, especially if the hash was generated before the "tag" was added, as the file's content has been altered.