Path: ...!news.mixmin.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Michael S <already5chosen@yahoo.com>
Newsgroups: comp.arch
Subject: Re: Byte Addressability And Beyond
Date: Tue, 4 Jun 2024 12:11:33 +0300
Organization: A noiseless patient Spider
Lines: 42
Message-ID: <20240604121133.0000499b@yahoo.com>
References: <v0s17o$2okf4$2@dont-email.me>
	<v31c4r$3u28v$1@dont-email.me>
	<v327n3$1use$1@gal.iecc.com>
	<BM25O.40665$HBac.4762@fx15.iad>
	<v32lpv$1u25$1@gal.iecc.com>
	<v33bqg$9cst$11@dont-email.me>
	<v34v62$ln01$1@dont-email.me>
	<v36bva$10k3v$2@dont-email.me>
	<2024May29.090435@mips.complang.tuwien.ac.at>
	<v38opv$1gsj2$3@dont-email.me>
	<v38rkd$1ha8a$1@dont-email.me>
	<jwvttifrysb.fsf-monnier+comp.arch@gnu.org>
	<f90b6e03c727b0f209d64484ec097298@www.novabbs.org>
	<v3jtd8$3qduu$2@dont-email.me>
	<20240603132227.00004e0f@yahoo.com>
	<v3mko3$c1kq$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Injection-Date: Tue, 04 Jun 2024 11:11:20 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="f25b49b872d8aef0e7d27ed388edfd45";
	logging-data="367462"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/GKMPwCm+0YkmkXZcYGNkr46wT89xLxCA="
Cancel-Lock: sha1:G0HS5+jzVagH+IcWKBOToQ4xc+A=
X-Newsreader: Claws Mail 3.19.1 (GTK+ 2.24.33; x86_64-w64-mingw32)
Bytes: 3185

On Tue, 4 Jun 2024 10:54:27 +0200
Terje Mathisen <terje.mathisen@tmsw.no> wrote:

> Michael S wrote:
> > On Mon, 3 Jun 2024 08:03:53 -0000 (UTC)
> > Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> >  =20
> >> On Thu, 30 May 2024 18:31:46 +0000, MitchAlsup1 wrote:
> >> =20
> >>> 30 years ago you could say the same thing about encryption. =20
> >>
> >> I don=C3=A2=E2=82=AC=E2=84=A2t think newer CPUs have been optimized fo=
r encryption.
> >> Instead, we see newer encryption algorithms (or ways of using
> >> them) that work better on current CPUs. =20
> >=20
> > I think moderate efficiency on CPU, not too low, but not high
> > either, is a requirement for (symmetric-key) cipher. Esp. when the
> > key is 128-bit or shorter. =20
>=20
> That's correct:
>=20
> CPU efficiency, primarily on the reference 32-bit platform
> (PentiumPro 200 MHz) but also on an 8-bit "smart card" implementation
> was one of the key requirements for the AES competition.
>=20
> When a group of four programmers (including me) spent a week on
> CERN's candidate, we were able to triple the speed, bringing it into
> parity with the eventual winner. All the finalists were more or less
> the same speed at this point, i.e. able to do full duplex 100 Mbit/s
> Ethernet traffic (so around 20 MB/s) on a single thread/core.
>=20
> Terje
>=20

My point was that for symmetric cipher intended for use with "short"
keys, at least during a phase of standardization, exceptionally high
efficiency on existing CPUs would be considered a defect rather than
advantage.=20
Not necessarily so for "long" keys, where unbreakability by brute force
is taken for granted.