Re: [ftpext] draft-ietf-ftpext2-hash command name and default algorithm

Richard Koenning <> Tue, 18 January 2011 19:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7B0AD3A7030 for <>; Tue, 18 Jan 2011 11:12:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id UWhfonw2xDOz for <>; Tue, 18 Jan 2011 11:12:19 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 07E5C3A7023 for <>; Tue, 18 Jan 2011 11:12:18 -0800 (PST)
DomainKey-Signature: s=s1536a;; c=nofws; q=dns; h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV: Received:Message-ID:Date:From:Reply-To:Organization: User-Agent:X-Accept-Language:MIME-Version:To:Subject: References:In-Reply-To:Content-Type: Content-Transfer-Encoding; b=bGHfJSCm8yQvMrHZTrXH7Ooml5bDw7IMsjY7l8d2vKLpPp/3Eme54usp tHJc6a3DdmDQ5Byh5wZZyQjpkhJK32DBZ9gemz6lPeEg7ANifTBB9EulO uqCFmTMAydAL+6WnxN9WGn3qebELCO1yN/rGo0MUkrDZekl/KTz+St4ZO eBWM3z0By/fH0Ztky5j/eRE4MtGIXdM9b/OAwakGpTckrhP8v0QOHhXo+ T+zhd52VVWo4w76TdqZ3sxXtchJcG;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;;; q=dns/txt; s=s1536b; t=1295378097; x=1326914097; h=message-id:date:from:reply-to:mime-version:to:subject: references:in-reply-to:content-transfer-encoding; z=Message-ID:=20<>|Date:=20 Tue,=2018=20Jan=202011=2020:14:54=20+0100|From:=20Richard =20Koenning=20<>|Reply-To:|MIME-Version:=201.0 |To:=20""=20<>|Subject:=20R e:=20[ftpext]=20draft-ietf-ftpext2-hash=20command=20name =20and=20default=20algorithm|References:=20<F15941D3C8A2D 54D92B341C20CACDF2311976FECC9@exchange>=09<20110117175600>=09<F15941D3C8A2D54D92B341C20 CACDF2311976FF0A8@exchange>=09<alpine.DEB.2.00.1101181545>=09<F15941D3C8A2D54D92B341C20CACDF2 311979DC5FE@exchange>=20<alpine.DEB.2.00.1101181656420.98>|In-Reply-To:=20<alpine.DEB.2.00.11011816>|Content-Transfer-Encoding:=20quo ted-printable; bh=gdb/1BspEe63/S4OM6tLzCQBvbx8+uTuCPIdlm0985E=; b=GMCbSOL9eRcz4oBjrHr0ZqST0NCN7pIhVRqYEaPMRMpFoyqb1VIlbRzP m/PYKMdXX/gP5IgKvVaG8Eddj7MKai5NZQK5y7eVasmx2pGpj9kOUG+8P fv9p+oFLNMemygePjy3yQCB4dqQeO26JE20q/Bk/Hr6e1RZVVvV3eMbgQ WWLwDsRVnFv9QA8ZBxrmqvUPJrwRzXAfSWjq3/qJ9SyuRN4ElGDKXjkme B7CfS2NnkAoMA4YV2ErckOqZTMcmp;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.60,339,1291590000"; d="scan'208";a="66360206"
Received: from ([]) by with ESMTP; 18 Jan 2011 20:14:55 +0100
X-IronPort-AV: E=Sophos;i="4.60,339,1291590000"; d="scan'208";a="107123086"
Received: from (HELO []) ([]) by with ESMTP; 18 Jan 2011 20:14:55 +0100
Message-ID: <>
Date: Tue, 18 Jan 2011 20:14:54 +0100
From: Richard Koenning <>
Organization: Fujitsu Technology Solutions GmbH
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: de, de-nds, en, en-US, it
MIME-Version: 1.0
To: "" <>
References: <F15941D3C8A2D54D92B341C20CACDF2311976FECC9@exchange> <> <F15941D3C8A2D54D92B341C20CACDF2311976FF0A8@exchange> <> <F15941D3C8A2D54D92B341C20CACDF2311979DC5FE@exchange> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Subject: Re: [ftpext] draft-ietf-ftpext2-hash command name and default algorithm
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 18 Jan 2011 19:12:20 -0000

Daniel Stenberg wrote:

> On Tue, 18 Jan 2011, Robert Oslin wrote:
>>>>I personally think CRC32 is too weak for multi-gigabyte files.
>>Do you mean that CRC32 is weak period?
> CRC32 uses 32 bits to indicate a checksum for the data. I claim it gets weaker 
> the more data to try to check with it. Having a CRC32 field for a sufficiently 
> small amount of data will be fine IMO - but that's not what we design for 
> here.

 From the draft it is still unclear to me whether the hash shall be used 
only for detecting "normal" transmission problems or also for detecting 
active attacks on the data channel.

For the latter CRC32 is out of discussion not only for the size of the 
hash value but for its linear properties: it is even easy to change the 
data while keeping the CRC unchanged.
Regarding MD5: Since long time cryptologists warn against using MD5 for 
new protocols/applications. As an application of this policy there are 
no newer TLS cipher suites using MD5.
Regarding SHA1: Despite showing some weakness too it is imho still in 
wide usage e.g. in the TLS area. On the other hand the search for new 
long-term hash functions is still ongoing 
( Therefore it seems 
to me still acceptable to use SHA1 as default hash function.

When the hash function is only used for detecting transmission errors 
than the collision probability is one of the main points, this 
probability is approximately the inverse of the square root of the hash 
value space. So with CRC32 one has to expect collisions already with a 
set of some ten thousand files. With MD5 the corresponding number has 19 
figures, which probably suffices already for most applications.

Dr. Richard W. Könning
Fujitsu Technology Solutions GmbH