Re: Does there exist an utility to compare 2 files on 2 servers without downloading those?

On May 21, 11:00 am, John Reiser <jreise...@xxxxxxxxxxx> wrote:
David Schwartz wrote:
On May 19, 3:22 pm, Nate Eldredge <n...@xxxxxxxxxx> wrote:

A user should demand [at least] both the same length and the same hash.

1) For SHA-256, what is the estimated difficulty change in the
additional check against an actual attacker?

The 'net challenges David Schwartz to compose an understandable challenge..
In particular, the meaning of section 1) above is difficult to determine.
The conclusion "show that 2) + 3) is greater than 1)" depends greatly
on what is intended by 1).

You are suggesting that a SHA-256 hash match is not enough, one should
additionally check the length. Presumably, you think this has some
benefit, so I'm challenging you to estimate the amount of benefit.

For example, if you said, "there's an X% chance, under some realistic
circumstances, under which you could have a SHA-256 hash match without
an exact data match, while under those same circumstances, if you
compare the length as well, the chance drops to Y%." That would
satisfy my point 1.

At modest expense, a person acting alone can create an attack on sha-256
via pre-computed dictionary for files of 5 or fewer bytes.  You-know-who
has gone at least one byte farther.  After that, analysis adds a few bits,
and patient search perhaps adds a few more bits.  In parallel, other attacks
can work on creating collisions by appending 256 chosen bits (32 bytes)
to a particular subject file which is considered likely to be checked.
This last approach relates directly to item 1).

None of those "attacks" actually do anything though. They are only
attacks in your mind. What do you think they actually attack?

For example, I have a four byte file. You know its SHA-1 hash because
you intercepted my over-the-wire check. You can, by brute force,
figure out my file. But so what? SHA-1 is not an encryption scheme and
we're not using it as one. That won't help you tamper with the
checksum in any way.

[snip]

I agree. 2 and 3 are the easy parts. The problem is that your answer
to 1 will likely be of the opposite sign of what you expect. A bogus
match or mismatch will actually be more likely with the addition of
the length check simply because the greater amount of computation
increases the possibility of an incorrect result. Meanwhile, the
probability of a SHA-256 algorithmic failure, under any conceivable
attack scenario, will be many orders of magnitude less.

Let's try it this way: There are many, several well-documented cases
of computers making genuine computational errors. Therefore, the
probability of a computational error on a typical computer is
significantly less than 1 in the number of computations that have
taken place to date, which is approximately 10^23.

The probability of a SHA-256 algorithmic failure, collision, or other
problem (assuming no computational errors) under any conceivable
attack scenario depends upon what security parameters you actually
expect. For example, it's much less if the only conceivable attack is
where the attacker substitutes his own data which has to match the
hash of your data. It's much greater if an attacker can defeat the
system by choosing both inputs. Nonetheless, I defy you to demonstrate
that it is anywhere near as small as 10^23 under any realistic
scenario.

DS
.