From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from gandalf.ozlabs.org (mail.ozlabs.org [IPv6:2404:9400:2221:ea00::3]) by passt.top (Postfix) with ESMTPS id 850B75A026F for ; Thu, 28 Sep 2023 03:21:08 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gibson.dropbear.id.au; s=201602; t=1695864064; bh=t1e0efVTJyJ8bL23h9ydQFWaPuRUbWo4YA1NOA4GACM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=fQYVimCpNNXHR3Fd7Nluo8e3tiHYnfvB7TY5+3AkYTYwHafeKiKLNqU8Okp8v55Cv zbm7K7k0+CfQCdIncECNY3Km94Uthj27FeytKjJYBXdMGPnb98tNqh1Cnen+EHkJXn UnhmDvPdK6iLGZrBRRJH3Deow9k08OlZ7PClS5J4= Received: by gandalf.ozlabs.org (Postfix, from userid 1007) id 4RwwfS6QRsz4xQl; Thu, 28 Sep 2023 11:21:04 +1000 (AEST) Date: Thu, 28 Sep 2023 11:20:21 +1000 From: David Gibson To: Stefano Brivio Subject: Re: [PATCH 06/10] siphash: Use more hygienic state initialiser Message-ID: References: <20230922140630.3184256-1-david@gibson.dropbear.id.au> <20230922140630.3184256-7-david@gibson.dropbear.id.au> <20230927190450.6f827040@elisabeth> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="AfrP2Whq7mFJJLct" Content-Disposition: inline In-Reply-To: <20230927190450.6f827040@elisabeth> Message-ID-Hash: HFERDEOJJCF5NC33OND2G7NJ6KUHWUDD X-Message-ID-Hash: HFERDEOJJCF5NC33OND2G7NJ6KUHWUDD X-MailFrom: dgibson@gandalf.ozlabs.org X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: passt-dev@passt.top X-Mailman-Version: 3.3.8 Precedence: list List-Id: Development discussion and patches for passt Archived-At: Archived-At: List-Archive: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --AfrP2Whq7mFJJLct Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Sep 27, 2023 at 07:04:50PM +0200, Stefano Brivio wrote: > On Sat, 23 Sep 2023 00:06:26 +1000 > David Gibson wrote: >=20 > > The PREAMBLE macro sets up the SipHash initial internal state. It also > > defines that state as a variable, which isn't macro hygeinic. With > > previous changes simplifying this premable, it's now possible to replac= e it > > with a macro which simply expands to a C initialisedrfor that state. > >=20 > > Signed-off-by: David Gibson > > --- > > siphash.c | 29 ++++++++++++----------------- > > 1 file changed, 12 insertions(+), 17 deletions(-) > >=20 > > diff --git a/siphash.c b/siphash.c > > index 6932da2..21c560d 100644 > > --- a/siphash.c > > +++ b/siphash.c > > @@ -58,15 +58,12 @@ > > =20 > > #define ROTL(x, b) (uint64_t)(((x) << (b)) | ((x) >> (64 - (b)))) > > =20 > > -#define PREAMBLE \ > > - uint64_t v[4] =3D { 0x736f6d6570736575ULL, 0x646f72616e646f6dULL, \ > > - 0x6c7967656e657261ULL, 0x7465646279746573ULL }; \ > > - int __i; \ > > - \ > > - do { \ > > - for (__i =3D sizeof(v) / sizeof(v[0]) - 1; __i >=3D 0; __i--) \ > > - v[__i] ^=3D k[__i % 2]; \ > > - } while (0) > > +#define SIPHASH_INIT(k) { \ > > + 0x736f6d6570736575ULL ^ (k)[0], \ > > + 0x646f72616e646f6dULL ^ (k)[1], \ > > + 0x6c7967656e657261ULL ^ (k)[0], \ > > + 0x7465646279746573ULL ^ (k)[1] \ >=20 > I don't think it actually matters (given the rationale for the choice > of these constants given in the paper), but earlier this was equivalent > to: >=20 > 0x736f6d6570736575ULL ^ (k)[1], > 0x646f72616e646f6dULL ^ (k)[0], > 0x6c7967656e657261ULL ^ (k)[1], > 0x7465646279746573ULL ^ (k)[0] No... I don't think it was. We had: for (__i =3D sizeof(v) / sizeof(v[0]) - 1; __i >=3D 0; __i--) = =20 v[__i] ^=3D k[__i % 2]; So in the first iteration __i =3D=3D 3, so we get v[3] ^=3D k[1], and v[3] is 0x7465646279746573. > and it matched both reference implementations linked in the file > header. Again, I don't think that's correct. In https://github.com/veorq/SipHash.git we have: v3 ^=3D k1; v2 ^=3D k0; v1 ^=3D k1; v0 ^=3D k0; In both cases the order of operations is reversed, but since they're independent that doesn't matter. But the point is that the reference implementation has v0 <-> k0 and v3 <-> k1, rather than the other way around. > Anyway, the paper says: >=20 > ...where k0 and k1 are the little-endian 64-bit words encoding the key > k. >=20 > without giving an order, so I guess either interpretation is fine. Right, I also don't think it actually matters. --=20 David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson --AfrP2Whq7mFJJLct Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEO+dNsU4E3yXUXRK2zQJF27ox2GcFAmUU1KwACgkQzQJF27ox 2GcZJQ/+JgqzCRD8YlO12yh1KeMx3GLB4caEibX9AdsY2LGQZKfVI+IcgKAXNANG du7kFyl5xda/T0yI5jm0gszFxYY+NzYpOrcqvcskv4NSk+BYKsPnyLRRqBa8Mfx/ JLLDaKScSW2tjA3TzC2NWqc+IuesIpotl4JJS0gu7NX7YD+JTE37Am9OCqMdGe7I OUFb+dimKJmp27VTEWWYOrj8WkWNX7deKW1qVaD73XTpQydzGZCJXew0cnydmKCD m55/MbWlY5UZS8XwAxuX8j9nMM/ulo0OtL6p2u2RIaglDgdmbJ6Wfcbho0PsEf2v Q7B28BbIv7FjthJUW7wQp7062is1op3rh4tAs3lD7ytXwIT7pTq5DZWnOKsJpkLP DRAx4VfA2q2Fb/m8UAelHuy1bdTnGnT3rvsPaKaaaHqxQ7MRkil/3KpUvExZPQUR BVpffJvALxPqc8Sw8+DAHWMRJ6i4nDifUI62OQTymS4OJZ0In6EZRgmLF6BQFrc/ WXEs+Q07q1cgSKjHGtXqY381eB75ZDHBmfPGqfTEFz/0JXmVuytjOi6q1/D7LEE2 Rd7iRzs5E/X4fLmLBQP06lQGgaKNz8C/9f6Xo92CL65y2/qR2tiSjBA209NcfYAv 4woAzsqnpyPwC7pfuXVSGVJR+KyQyOpFkc6jzg72qoVQkg2scMs= =CQQX -----END PGP SIGNATURE----- --AfrP2Whq7mFJJLct--