181 reputation
6
bio website
location
age 44
visits member for 3 years, 3 months
seen Jan 3 at 20:47

Jul
11
awarded  Nice Question
Mar
3
awarded  Popular Question
Aug
17
awarded  Scholar
Aug
17
accepted Is calculating a hash code for a large file in parallel less secure than doing it sequentially?
Aug
11
awarded  Editor
Aug
11
revised Is calculating a hash code for a large file in parallel less secure than doing it sequentially?
added 125 characters in body
Aug
11
comment Is calculating a hash code for a large file in parallel less secure than doing it sequentially?
So, perhaps my question reduces to: Is it easier to find a collision given a long input data size (e.g., tens of gigabytes) or a short input data size (e.g., 1 MB), discounting the fact that it takes longer to hash the longer input.
Aug
11
comment Is calculating a hash code for a large file in parallel less secure than doing it sequentially?
I know that - that is what I was showing using the 512/512 syntax (512-bit hash with 512-bit state). My point is that if I use 1024-bit hashes with 1024-bit state for the (parallel processed) blocks and a 512-bit hash (perhaps also with 1024-bit state) for the final hash of hashes, I may actually get a stronger hash than a 512-bit hash with 512-bit state performed serially for the entire file. Or, maybe I am wrong.
Aug
11
comment Is calculating a hash code for a large file in parallel less secure than doing it sequentially?
The same applies to Skein, which is actually quite fast in its Skein-1024/1024 implementation on 64-bit (x86) hardware. One could come up with a Method 3 that after a parallel calculation of a Skein-1024/1024 value, would fold the value so as to create a 512-bit hash that is no less secure than a sequential Skein-512/512 hash (i.e., that only used 512 bits of state in its calculation). Although, it is not clear to me how such a folding would be performed, other than perhaps through truncation of either the most or least significant 512 bits.
Aug
11
comment Is calculating a hash code for a large file in parallel less secure than doing it sequentially?
I am not sure I understood your explanation with regard to the difference in strength between the two methods. One thing is clear though, it may make sense, if space is not an issue, to do a SHA-512 (which is more expensive) on blocks in parallel, so that any bits lost due to the parallelism and blocking are subtracted from a much larger bit depth (512 vs 256) vs. doing a SHA-256 serially.
Aug
11
comment Is calculating a hash code for a large file in parallel less secure than doing it sequentially?
The thing is that with Method 2 we can have a collision in the final hash, without having collisions at the intermediate hashes. Also, if we break a large file into 1 MB chunks, we have the possibility of a collision on one of the chunks, but which does not lead to a collision of the final hash. This is why it's not at all clear if any hash strength is lost with Method 2.
Aug
11
awarded  Supporter
Aug
10
comment Is calculating a hash code for a large file in parallel less secure than doing it sequentially?
Yes, all cryptographic hash functions break the message into chunks. However, state is carried over from one chunk into the next (i.e., the hash of each subsequent chunk is dependent on all preceeding chunks). Method 2 keeps the chunks independent, until the final hash, thus my question about whether it is deficient as compared to Method 1.
Aug
10
comment Is calculating a hash code for a large file in parallel less secure than doing it sequentially?
No, as far as I can tell, it is not. See my first comment.
Aug
10
awarded  Student
Aug
10
comment Is calculating a hash code for a large file in parallel less secure than doing it sequentially?
The paper doesn't seem to mention whether this tree hashing method, which is similar to a Merkle Tree, is more or less secure than the sequential method, which is the crux of my question.
Aug
10
asked Is calculating a hash code for a large file in parallel less secure than doing it sequentially?