Re: [ftpext] New Version Notification for draft-bryan-ftp-hash-05

[Anthony Bryan <[e-mail]>]

On Mon, Jul 12, 2010 at 5:59 AM, Iljitsch van Beijnum
<[e-mail]> wrote:
> A more efficient and less DoS-prone way to implement this would be for the client to tell the server the hash, and for the server to tell the client whether the file matches the hash.
>
> To optimize this, the hash wouldn't be a straigh hash over the entire file, but consist of three parts: the file length, a hash over a small part of the file (say, the first and last kilobyte) and finally a hash over the entire file. So if the length doesn't match, the file doesn't match the hash and there is no need to access the file. If the hash over the small part doesn't match, there is no match and hashing the entire file is avoided.

Iljitsch, interesting approach.

I believe one of the draft's earlier incarnations also had a CHKHSH
command which did just this.

unless I'm misunderstanding, this would be MORE indirect, unoptimized,
complex and DoSy than the current draft.

to be able to answer whether a hash is correct, the server still needs
to know the correct hash?
when you meet someone, do you ask "is your name Bob? no, how about
Jim? no, Ed?" or do you just come right out and ask "what's your
name?" which is simpler?

MirrorBrain is an example of a server, although HTTP not FTP, that is
a hash/mirror cache/provider: http://www.mirrorbrain.org/
it also might be worth examining what the other FTP servers that
implement the nonstandard hash commands do.

you mention partial file hashes, some of those nonstandard commands
like XCRC and XMD5 support it with a byte range.
do you think HASH should support partial file hashing?

> Nitpick: repeating the first part of the abstract in the introduction verbatim is a bit annoying.

sure, we'll work on that.

-- 
(( Anthony Bryan ... Metalink [ http://www.metalinker.org ]
  )) Easier, More Reliable, Self Healing Downloads