Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Terje Mathisen <terje.mathisen@tmsw.no>
Newsgroups: comp.arch
Subject: Re: Byte Addressability And Beyond
Date: Tue, 4 Jun 2024 11:09:16 +0200
Organization: A noiseless patient Spider
Lines: 57
Message-ID: <v3mljt$c63k$1@dont-email.me>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Tue, 04 Jun 2024 11:09:17 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="e45d74333c127ce2b4dec02c1d921f24";
	logging-data="399476"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18gekmA0+o/oMz07wzBDwHdA8BbFDZGjLmDaG701NAQHQ=="
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Firefox/91.0 SeaMonkey/2.53.18.2
Cancel-Lock: sha1:dfgD8rxnW9E25ANH5YhCv9sIN8E=
In-Reply-To: <v3klhp$3ugeh$1@dont-email.me>
Bytes: 3956

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.

Terje

-- 
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"