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 <nolo...@gmail.com> >>> wrote: >>> > >>> > On Sat, May 20, 2023 at 3:00 PM Tom <thoma...@gmail.com> 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.
