<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div dir="auto" class=""><br class=""><blockquote type="cite" class=""><div dir="ltr" class=""><div dir="ltr" class=""><div dir="ltr" class=""><div dir="ltr" class=""><div dir="ltr" class=""><div dir="ltr" class=""><div dir="ltr" class=""><div dir="ltr" class=""><div class="gmail_default" style="font-size:small">Traditionally, a digest converts a sequence of bits to a fixed length output</div><div class="gmail_default" style="font-size:small"><br class=""></div><div class="gmail_default" style="font-size:small">M(d) -> 256 bits</div><div class="gmail_default" style="font-size:small"><br class=""></div><div class="gmail_default" style="font-size:small">We can now detect a single bit of corruption in the data file. Great! But that doesn't give us any information if the data is corrupted. We don't know where the corruption occurred. That is fine for little files but what about when we are dealing with 1TB archives?</div><div class="gmail_default" style="font-size:small"><br class=""></div><div class="gmail_default" style="font-size:small">A better approach would be to split the data up into chunks and construct a digest (Merkle tree??) over the chunks. But how big should the chunks actually be? There is clearly a tradeoff here which we traditionally just skate over entirely because we have this 'any fault will destroy our crypto' approach….</div></div></div></div></div></div></div></div></div></blockquote>Sounds an awful lot like what rsync does….<div class=""><br class=""></div><div class=""> -- Jerry</div><div class=""><br class=""></div></div></body></html>