Re: [openpgp] [RFC4880bis PATCH] Clarify CRC-24 C example implementation

"brian m. carlson" <sandals@crustytoothpaste.net> Thu, 18 March 2021 22:39 UTC

Return-Path: <sandals@crustytoothpaste.net>
X-Original-To: openpgp@ietfa.amsl.com
Delivered-To: openpgp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A2B23A0C98 for <openpgp@ietfa.amsl.com>; Thu, 18 Mar 2021 15:39:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (3072-bit key) header.d=crustytoothpaste.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MXoRANoHLc7b for <openpgp@ietfa.amsl.com>; Thu, 18 Mar 2021 15:39:21 -0700 (PDT)
Received: from injection.crustytoothpaste.net (injection.crustytoothpaste.net [192.241.140.119]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63A4D3A0C93 for <openpgp@ietf.org>; Thu, 18 Mar 2021 15:39:21 -0700 (PDT)
Received: from camp.crustytoothpaste.net (unknown [IPv6:2001:470:b978:101:7d4e:cde:7c41:71c2]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by injection.crustytoothpaste.net (Postfix) with ESMTPSA id 4CB8F6046C for <openpgp@ietf.org>; Thu, 18 Mar 2021 22:38:48 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crustytoothpaste.net; s=default; t=1616107128; bh=rYSXBFmnW1K+xhAQNaK/WIbPHXxVwbtsDc+tU1roiz4=; h=Date:From:To:Subject:References:Content-Type:Content-Disposition: In-Reply-To:From:Reply-To:Subject:Date:To:CC:Resent-Date: Resent-From:Resent-To:Resent-Cc:In-Reply-To:References: Content-Type:Content-Disposition; b=NtF9j8WiaIGririFq+isCe0mH3XzvZCENb9Drunq23MM/2mOf8kDaDzs/4ILJY7du 07BGgkRs9pGY+yE6xQ24FUv7IuaZRciZxFbJt0tFzhuipyjq459cphilYPxBYlpS+E asyBw/caCzoKYJVwbJJxJSu89RhnOlZjp6CXeAhoMZkcxycTNaNFNrJlBH7mAA3FdS c5zLv+CinfRX6PAP0kK1gARiotHs6L6Biy8TnXajlPzR61Hi1YLLvFzOHaPKRixLOF u7jMyymxC0ZFGpxuc2KLIYi2DryMrtikGDZk8y0xhtP5I9Yb2jf+Nn9Q5WjvgYc4u/ y0BKf6iEjGU7JhHd5EIBtkh+Qs2qAQiIAkMeFASpf+RJ1IOv3+OaI2/VpYSArv18Xb nYLofWluaTu/wOnKycO8LUgI8Y993QQPvQDgQ9BLtEYywr7O8RHF27ESO2qP6Dm2ze BwOMZVBSdLhixh6zFBWjNuRbOPz81DPrLLVEmMPzyl3vYj66mEo
Date: Thu, 18 Mar 2021 22:38:41 +0000
From: "brian m. carlson" <sandals@crustytoothpaste.net>
To: openpgp@ietf.org
Message-ID: <YFPWcTDig8jChiry@camp.crustytoothpaste.net>
References: <20210317145508.136021-1-dkg@fifthhorseman.net> <871rcd7rdh.fsf@fifthhorseman.net> <25e8d5713bcccb7b86e0f9ce75dafba80fb41530.camel@16bits.net>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="HtaVIoq7tbFMB1PI"
Content-Disposition: inline
In-Reply-To: <25e8d5713bcccb7b86e0f9ce75dafba80fb41530.camel@16bits.net>
User-Agent: Mutt/2.0.5 (2021-01-21)
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/YI6JB-vxvOxh1Zz_cVpaxjqevwA>
Subject: Re: [openpgp] [RFC4880bis PATCH] Clarify CRC-24 C example implementation
X-BeenThere: openpgp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <openpgp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/openpgp>, <mailto:openpgp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/openpgp/>
List-Post: <mailto:openpgp@ietf.org>
List-Help: <mailto:openpgp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/openpgp>, <mailto:openpgp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Mar 2021 22:39:23 -0000

On 2021-03-18 at 01:33:54, Ángel wrote:
> On 2021-03-17 at 11:05 -0400, Daniel Kahn Gillmor wrote:
> > On Wed 2021-03-17 10:55:08 -0400, Daniel Kahn Gillmor wrote:
> > > The mismatch between the variable in the sample CRC-24 generation
> > > code
> > > and the definition of the generator in the paragraph above has been
> > > a
> > > source of confusion for over 20 years.
> > 
> > I recorded this proposed minor cleanup as MR 39:
> > https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/39
> > 
> >         --dkg
> 
> What about using, instead of the 'long' type, which may mean quite
> dfferent things, the uint_least32_t type defined in ISO C 7.18 ?

My preference here is uint32_t, since as a practical matter all modern
architectures offer that and implement it reasonably efficiently, and it
is much more commonly used.  More recent languages like Rust and Go just
assume everyone has such a type, and in the unlikely event someone uses
a system that doesn't have it, they'll clearly know how to adjust.

However, I'm also fine with uint_least32_t or unsigned long.  The
important thing is that we produce something that is (a) correct so that
it produces the right results, (b) conformant so that compilers don't
break it in the name of better optimizations during undefined behavior,
and (c) as simple and easy to understand as possible.  Any option which
meets those requirements is satisfactory to me.
-- 
brian m. carlson (he/him or they/them)
Houston, Texas, US