Path: ...!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: Wed, 5 Jun 2024 16:49:05 +0300
Organization: A noiseless patient Spider
Lines: 93
Message-ID: <20240605164905.000054da@yahoo.com>
References: <v0s17o$2okf4$2@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>
	<k6k7O.8602$7jpd.5620@fx47.iad>
	<v3klhp$3ugeh$1@dont-email.me>
	<v3mljt$c63k$1@dont-email.me>
	<v3nf7j$gesm$1@dont-email.me>
	<v3padn$the9$1@dont-email.me>
	<v3pph1$1010d$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Injection-Date: Wed, 05 Jun 2024 15:48:53 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="af421c1bf631e23d6a62a4e576399d10";
	logging-data="966879"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX197FXWAEL7j5DHY9C3IqHsxto5FcpEyv5E="
Cancel-Lock: sha1:FpjGw0PBlN+IACJrO03ykvkbkgA=
X-Newsreader: Claws Mail 3.19.1 (GTK+ 2.24.33; x86_64-w64-mingw32)
Bytes: 5732

On Wed, 5 Jun 2024 13:34:25 -0000 (UTC)
"Stephen Fuld" <SFuld@alumni.cmu.edu.invalid> wrote:

> Terje Mathisen wrote:
> 
> > Stephen Fuld wrote:  
> > > Terje Mathisen wrote:
> > >   
> > > > Stephen Fuld wrote:  
> > > > > Scott Lurndal wrote:
> > > > >   
> > >>>>Michael S <already5chosen@yahoo.com> writes:  
> > > > > > > On Mon, 3 Jun 2024 08:03:53 -0000 (UTC)
> > >>>>>Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> > > > > > >   
> > > > > > > > On Thu, 30 May 2024 18:31:46 +0000, MitchAlsup1 wrote:
> > > > > > > > =20  
> > > > > > > > > 30 years ago you could say the same thing about
> > > > > > > > > encryption.  =20  
> > > > > > > > =20
> > > > > > > > I don=E2=80=99t think newer CPUs have been optimized
> > > > > > > > for  
> > > > > > encryption. Inst=  
> > > > > > > ead,  
> > > > > > > > we see newer encryption algorithms (or ways of using
> > > > > > > > them) that  
> > >>>>work >> better on current CPUs.=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.  
> > > > > > 
> > > > > > Most modern CPUs have instruction set support for symmetric
> > > > > > ciphers such as AES, SM2/SM3 as well as message digest/hash
> > > > > > (SHA1, SHA256 et al).
> > > > > > 
> > > > > > High throughput encryption has been done by hardware
> > > > > > accelerators for decades now (e.g. bbn or ncypher HSM boxes
> > > > > > sitting on a SCSI bus; now such HSM are an integral part of
> > > > > > many SoC).  
> > > > > 
> > > > > 
> > > > > Queston.  For a modern general purpose CPU, if you are
> > > > > including all the logic to implement encryption instructions,
> > > > > is it much more to include the control/sequencing logic to do
> > > > > it and not tie up the rest of the CPU logic to do the
> > > > > encryption?  Furthermore, an "inbuilt" accelerator could
> > > > > interface directly with the I/O hardware of the CPU (e.g.
> > > > > PCI), saving the "intermediate" step of writing the encrypted
> > > > > data to memory.  
> > > > 
> > > > That logic already exists, in the form of a single thread/core
> > > > dedicated to the job.
> > > > 
> > > > With 30-100 cores on a single die, it becomes very cheap to
> > > > dedicate one of them to babysit such a process, compared to the
> > > > cost of making a custom chunk of VLSI to do the same. This is
> > > > particularly true because the logic needed in the babysitting
> > > > process is mostly straight line, with a very limited number of
> > > > hard-to-predict branches.
> > > > 
> > > > I.e. h.264 CABAC decoding has three branches per bit decoded, at
> > > > least one of them impossible to predict or work around with
> > > > clever coding. Here it makes perfect sense to have a chunk of
> > > > hw to handle the heavy lifting. Monitoring block
> > > > encryption/decryption not so much.  
> > > 
> > > 
> > > I may be missing something, but while your proposal addresses the
> > > first part of my proposal, I think it doesn't adress the second.
> > > That is, for data coming from/going to some external source, you
> > > are still doing "unnecessary" memory traffic, which takes memory
> > > bandwidth and increases latency.  
> > 
> > Usually, when a CPU needs to work on something, it will need to get
> > the data into $L1 anyway? It is only when the work is simply to be a
> > pipeline that having a way to bypass the CPU completely really makes
> > a difference, right?  
> 
> Right.  But my point is that the CPU never really need to "work" on
> the encrypted data.  It it frequently only sent to, or received from
> the network or a storage device, hence the pipelined approach has
> advantages.
> 
> 
> 

The best, the most secure encryption is an end-to-end encryption.
Which means application-to-application.
It's not that other, "piece-wise" encryption types can't be used, but
if you are serious about privacy you should consider them insufficient.