It can work with:
https://gist.github.com/thomasb9511/f570ecad82055b34a27ec9e706f596c9
But it sidesteps the pipeline for verification.
On Sunday, May 21, 2023 at 7:28:44 AM UTC-4 Tom wrote:
> 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.
> On Sunday, May 21, 2023 at 12:56:43 AM UTC-4 Tom wrote:
>
>> Okay.
>>
>> 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.
>> On Saturday, May 20, 2023 at 6:48:40 PM UTC-4 Jeffrey Walton wrote:
>>
>>> On Sat, May 20, 2023 at 4:45 PM Jeffrey Walton
>>> wrote:
>>> >
>>> > On Sat, May 20, 2023 at 3:00 PM Tom wrote:
>>> > >
>>> > > calling `FileSource fs("zero.dat", true);` seems to allocate the
>>> memory.
>>> >
>>> > Try the overload which takes a std::istream reference:
>>> > https://www.cryptopp.com/wiki/FileSource
>>>
>>> I took another look... The issue is you passed 'true' for 'pumpAll'.
>>> That reads the entire file, and puts it in an output buffer for the
>>> next filter.
>>>
>>> Use 'false' instead, and then call 'PumpAll()' manually. Something
>>> like the example. Something like this should suffice:
>>>
>>> FileSource fs("zero.dat", false, new Filter(..., new Sink(...)));
>>> fs.PumpAll();
>>>
>>> It should pump in 4k blocks.
>>>
>>> Jeff
>>>
>>
--
You received this message because you are subscribed to the Google Groups
"Crypto++ Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to cryptopp-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/cryptopp-users/16098bdd-0361-4b54-9860-c39b8c6147d4n%40googlegroups.com.