Re: Content-Integrity header

On Wed, Jul 11, 2012 at 4:36 PM, Ludin, Stephen <sludin@akamai.com> wrote:
> On 7/10/12 10:04 PM, "Yutaka OIWA" <y.oiwa@aist.go.jp> wrote:
>>To this extent, re-requesting the broken chunk is personally out of
>>my interest.  This may need discussion, because it may affect
>>the design of inter-chunk chaining of integrity signatures.
>
> This was where I started when I began looking into corruption issues in
> downloaded objects.  What we discovered is that in a large enough sample
> size, such as what we see at Akamai, random bit shifting that manages to
> still get by the TCP chucksum happens regularly enough this feature is of
> high interest.  I actually see this as relatively useless for content
> forgery cases because, as mentioned elsewhere in this thread, the forger
> would probably simply change the digest to match the forgery.  The
> digesting feature in general is an act-of-nature (or act of bad hardware /
> software) detection mechanism, and building in an efficient recover
> mechanism seem to be a reasonable step.

We had a bad NIC on a router or fileserver (can't remember which) at
Sun once that produced lots of errors, most of which were caught by
checksums, but occasionally there were two bits flipped at just the
right distance from each other that all checksums in the stack checked
out.  This ended up manifesting itself as a corrupted SCCS file.
Scary!

Nico
--

Received on Wednesday, 11 July 2012 21:56:20 UTC