Stream: implementers
Topic: Attachment hash
Jeremy Chapman (Sep 18 2019 at 16:04):
The documentation for a Attachment.hash specifically states the has is SHA1. It's interesting because it doesn't seem to include any extensibility mechanism for future, or other current hash algorithms.
Nick Radov (Sep 18 2019 at 16:14):
Yes that seems like a problem. Should we add a new coded element to indicate the hashing algorithm used? SHA-1 is now regarded as vulnerable and is falling out of use. (Although this particular case is intended more to protect against accidental data corruption rather than intentional attacks.)
Lloyd McKenzie (Sep 18 2019 at 16:29):
We don't care that it's vulnerable. The intention isn't to secure the information, it's to check if the data has changed.
Lloyd McKenzie (Sep 18 2019 at 16:30):
If you wanted to secure it, you'd use a different element (probably DigitalSignature)
Grahame Grieve (Sep 18 2019 at 17:40):
it's a trip wire for not using it for crypto stuff
John Moehrke (Sep 20 2019 at 11:31):
Lloyd and Grahame nailed it. For more discussion of why it is NOT a cryptographic signature see my write up for the exact same need in XDS with the exact same solution, and where new people end up with a misunderstanding of the purpose of the hash -- https://healthcaresecprivacy.blogspot.com/2019/06/xds-sha-1-is-still-okay.html
I welcome suggestions on ways to improve the description of these elements (in both IHE and HL7). They clearly need clarification.
Michael Lawley (Sep 20 2019 at 11:33):
The pain is when you already have a (different) hash that you want to use rather than being forced to compute a new one.
John Moehrke (Sep 20 2019 at 11:39):
understood. You are free to add an extension for your custom hash.. but now you put a burden on the recipients that they also have have your hash. So we picked one for this need. And aligning it with XDS allows intermediaries between the technology to not need to re-calculate a hash (which would be a failure-mode). Most important is that there is no value to the need for a different hash.
Grahame Grieve (Sep 20 2019 at 12:22):
you have to compute your own surely?
Michael Lawley (Sep 22 2019 at 01:50):
In our case, low level code has already computed and checked a (SHA256) hash, so we're happy with the integrity of the file. We don't want to have to re-process the file at this point in the handling to compute another hash. Instead we use an extension.
To @John Moehrke s point about putting a burden on recipients, the use case for us is that clients have a manifest from a trusted source that lists the SHA256 hash, and they wish to know that it corresponds with the hash of the input to a function that resulted in a derived artifact. i.e., we're saying here is f(X) for that "X" over there (URL) and it had this hash when we used it to compute f(X).
Last updated: Apr 12 2022 at 19:14 UTC
