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

Ángel <angel@16bits.net> Thu, 18 March 2021 23:08 UTC

Return-Path: <angel@16bits.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 4CA7E3A0D69 for <openpgp@ietfa.amsl.com>; Thu, 18 Mar 2021 16:08:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 8hxfKe3Mk1Ws for <openpgp@ietfa.amsl.com>; Thu, 18 Mar 2021 16:08:05 -0700 (PDT)
Received: from mail.direccionemail.com (mail.direccionemail.com [199.195.249.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 544B03A0D64 for <openpgp@ietf.org>; Thu, 18 Mar 2021 16:08:05 -0700 (PDT)
Message-ID: <60773433fb4dfae65a59c089c22e24c37e7913cf.camel@16bits.net>
From: Ángel <angel@16bits.net>
To: openpgp@ietf.org
Date: Fri, 19 Mar 2021 00:08:02 +0100
In-Reply-To: <87k0q4rgml.fsf@wheatstone.g10code.de>
References: <20210317145508.136021-1-dkg@fifthhorseman.net> <871rcd7rdh.fsf@fifthhorseman.net> <25e8d5713bcccb7b86e0f9ce75dafba80fb41530.camel@16bits.net> <87sg4t5fz8.fsf@fifthhorseman.net> <87k0q4rgml.fsf@wheatstone.g10code.de>
Content-Type: text/plain; charset="ISO-8859-15"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/NLDbICF0jnfWtyMSCM9JWijg22I>
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 23:08:07 -0000

> (technically the CRC-24 accumulator just needs 25 bits -- one to test
> for overflow -- but we don't need to cut it so fine :P)

I don't think you would find many platforms with a uint_least25_t type. ;-)
I generally prefer explicit sizes when the number of bits matter, but
you are right: a long is more idiomatic. I don't mind either way.


On 2021-03-18 at 09:49 +0100, Werner Koch wrote:
> Anyway, I am in favor of applying Hal Finney's old suggestion (patch
> 39, attached).


As the goal is to provide clear code, that ORed 0x1000000 may still be
a bit surprising (albeit less than when it was included in the
constant). I think it would be clearer to use

                   if (crc & 0x1000000) {
                       crc = (crc ^ CRC24_POLY) & 0xffffff;
                   }


or, following more closely hal's second suggestion:
                   if (crc & 0x1000000) {
                       crc &= 0xffffff; /* Clear bit 25 to avoid overflow */
                       crc ^= CRC24_POLY;
                   }




Best regards