This is not an issue per say, more of a question that requires expertise in this library to answer.
I am interested in modifying the sha2 hasher (in particular, for sha256) such that, after some number of bytes have already been added (via .update()), I could save the state of the hasher (for sha256, of course, this is just the 32 bytes of state), then create a new hasher object later with the same starting state.
The use case is a situation where the chunks of data become available on a variable timeline (could be seconds, days, or hours in between arrivals), and rather than perform one big hash operation at the end (once all data has arrived), I would prefer to amortize these operations across the individual arrival events.
It is not feasible to keep this state in memory between arrivals, it would need to be saved to a backing store.
I've already drilled down into the code and understand where the state is kept. Still, it isn't clear to me what would be the path of least resistance to plumb the state back up through the VariableOutputCore, CtVariableCoreWrapper, and CoreCrapper. Maybe a new set of traits would make sense?
I have no issue doing the work and would publish it for anyone else interested, but I am hoping for some informed guidance.
Hello,
This is not an issue per say, more of a question that requires expertise in this library to answer.
I am interested in modifying the sha2 hasher (in particular, for sha256) such that, after some number of bytes have already been added (via .update()), I could save the state of the hasher (for sha256, of course, this is just the 32 bytes of state), then create a new hasher object later with the same starting state.
The use case is a situation where the chunks of data become available on a variable timeline (could be seconds, days, or hours in between arrivals), and rather than perform one big hash operation at the end (once all data has arrived), I would prefer to amortize these operations across the individual arrival events.
It is not feasible to keep this state in memory between arrivals, it would need to be saved to a backing store.
I've already drilled down into the code and understand where the state is kept. Still, it isn't clear to me what would be the path of least resistance to plumb the state back up through the VariableOutputCore, CtVariableCoreWrapper, and CoreCrapper. Maybe a new set of traits would make sense?
I have no issue doing the work and would publish it for anyone else interested, but I am hoping for some informed guidance.
Thanks very much in advance.
Sincerely, Bill