Enhance sftp protocol: get SHA hash of file

Ben Lindstrom mouring at offwriting.org
Thu Jun 30 16:55:36 EST 2011


Looking at the RFC that was posted in this thread.  It is best to implement that
as it is a bit more robust then mine.

Again mine was a proof of concept where the server can have a very simple
extended feature and the client does all the heavy lifting (e.g. like with our 
remote_glob() implementation).

And it mostly succeeded, and I'm sure it would be been better if the tests were
non-localhost. =)

At this moment I'm not inclined to breath life into my patch nor implement the
RFC.  Just isn't in my timeline for the next month or two.  However, implement
the server extension should be pretty much child's play.  The hard part is making
a get/put that groks and take effective advantage of it (or so my experience had
shown).

- Ben


On Jun 30, 2011, at 1:34 AM, Philipp Marek wrote:

>> A few years back I hacked in a simple "sumslist at eviladmin.org" protocol
>> based on the block size that sftp set for it's window, but instead of
>> SHA1 I was using MD5 at the time.  You could simply request a single
>> block or loop through and request a list of blocks.
> ...
>> I abandoned it for some reason.  I really wish I knew why.  I suspect it
>> had to do with the cost of doing the checksum list was approaching
>> the cost of actually downloading the file in the method I choice to
>> implement it.
> Well, I'd expect a simple command "manber-hashes START LENGTH " - perhaps 
> with an optional setting that defines the average block size - that streams 
> (start, length, manber-hash, MD5/SHA1) back to the client to be much more 
> useful; it would be much faster than transmitting the whole file and 
> wouldn't need that many query operations.
> 
> 
> In the file I referenced in the other mail I use the MD5, the previous-to-
> last manber hash and the last manber-hash (which has per definition N 
> rightmost bits zero) - that's a few bits more security than just using MD5 
> (where collisions can be created).
> Of course, using SHA1 might (at least for the moment ;) be enough.
> 
> Perhaps, to be on the safe side, another optional parameter could specify 
> "MD5+SHA1+SHA512+CRC32+..." to get all of these checksums ;)
> 
> 
> Regards,
> 
> Phil
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev



More information about the openssh-unix-dev mailing list