Encryption lengths are getting long so you’d think it was high time.
that’s unrelated - AES-256 for example can be executed just fine on either a 32- or 64-bit machine. in theory there’s nothing stopping you from running it on an 8-bit or 16-bit CPU (although other considerations related to the size of AES’s lookup tables make this unlikely). from some random googling, here is an implementation of Chacha20, another 256-bit encryption algorithm, for 8-bit microcontrollers.
when we talk about 32 vs 64-bit CPUs, in general we’re only talking about the address space - the size of a pointer determines how much RAM the computer is able to use. 32-bit machines were typically limited to 4GB (though PAE helped kick that can down the road)
CPU registers can also be sized independently of the address space - for example AVX-512 CPUs have a register that is 512 bits wide even though the CPU is still “64-bit”.
that’s unrelated - AES-256 for example can be executed just fine on either a 32- or 64-bit machine. in theory there’s nothing stopping you from running it on an 8-bit or 16-bit CPU (although other considerations related to the size of AES’s lookup tables make this unlikely). from some random googling, here is an implementation of Chacha20, another 256-bit encryption algorithm, for 8-bit microcontrollers.
I started out programming a 6502a in 1980, 680X0 a little later in 87, so I get that bit, but it’s easier doing operations on a larger register. I remember writing code for 8 bit multiplication of 32 bit floating points.
I enjoyed and understood the rest of your prose though. Didn’t do much/any programming/low level after say 2005, and regret it now. Trying to re-learn but things have moved on so much.
I take that there isn’t much motivation in moving to 128 because it’s big enough; it’s only 8 cycles (?) to fill a 512 (that can’t be right?).
that’s unrelated - AES-256 for example can be executed just fine on either a 32- or 64-bit machine. in theory there’s nothing stopping you from running it on an 8-bit or 16-bit CPU (although other considerations related to the size of AES’s lookup tables make this unlikely). from some random googling, here is an implementation of Chacha20, another 256-bit encryption algorithm, for 8-bit microcontrollers.
when we talk about 32 vs 64-bit CPUs, in general we’re only talking about the address space - the size of a pointer determines how much RAM the computer is able to use. 32-bit machines were typically limited to 4GB (though PAE helped kick that can down the road)
CPU registers can also be sized independently of the address space - for example AVX-512 CPUs have a register that is 512 bits wide even though the CPU is still “64-bit”.
I started out programming a 6502a in 1980, 680X0 a little later in 87, so I get that bit, but it’s easier doing operations on a larger register. I remember writing code for 8 bit multiplication of 32 bit floating points.
I enjoyed and understood the rest of your prose though. Didn’t do much/any programming/low level after say 2005, and regret it now. Trying to re-learn but things have moved on so much.
I take that there isn’t much motivation in moving to 128 because it’s big enough; it’s only 8 cycles (?) to fill a 512 (that can’t be right?).
8 cycles would be an eternity on a modern CPU, they can achieve multiple register sized loads per cycle.
If we do see a CPU with 128 bit addresses anytime soon, it’ll be something like CHERI, where the extra bits are used for flags.