Veracrypt performance benchmark: Pi4 VS 8-year-old Intel

[pigod]

I had expected a better result from Pi4. Yes, I knew that the 8-year-old Intel CPU is a desktop CPU and Pi4 is a mobile CPU, but since a lot of time has been passed and ARM CPU's have improved, my expectation was a little bit high.

8-year-old Intel CPU
AES 3.9GB/s (hardware-accelerated AES yes)
Camelia 1.5GB/s
Twofish 887MB/s
AES(Twofish) 783MB/s
Kuznyechik(Serpent(Camelia) 332MB/s

Pi4
Twofish 194MB/s
AES 113 MB/s
Camelia 102MB/s
AES(Twofish) 71MB/s
Kuznyechik(Serpent(Camelia) 20MB/s

Overall, Intel seems to be about 10 times faster than Pi4 (for some reason, Twofish was relatively faster on Pi4). I thought Pi4 would support hardware processing of such a widely used encryption like AES, but a quick web search says that Broadcom did not support it to avoid the licence cost.

[jamesh]

Not sure it was licence cost, more likely die area. For the market the chip was designed for, hardware crypto was unnecessary.

[fruitoftheloom]

I had expected a better result from Pi4. Yes, I knew that the 8-year-old Intel CPU is a desktop CPU and Pi4 is a mobile CPU, but since a lot of time has been passed and ARM CPU's have improved, my expectation was a little bit high.

8-year-old Intel CPU
AES 3.9GB/s (hardware-accelerated AES yes)
Camelia 1.5GB/s
Twofish 887MB/s
AES(Twofish) 783MB/s
Kuznyechik(Serpent(Camelia) 332MB/s

Pi4
Twofish 194MB/s
AES 113 MB/s
Camelia 102MB/s
AES(Twofish) 71MB/s
Kuznyechik(Serpent(Camelia) 20MB/s

Overall, Intel seems to be about 10 times faster than Pi4 (for some reason, Twofish was relatively faster on Pi4). I thought Pi4 would support hardware processing of such a widely used encryption like AES, but a quick web search says that Broadcom did not support it to avoid the licence cost.

There have been various benchmarks and generally are fairly meaningless, there are so many variables that only comparing like for like makes sense in my opinion.

[spcharc]

The result looks good. I'm wondering what exactly that Intel CPU is?

[dp11]

Have you built these bench mark tests with gcc 10.2 and 64bit mode + NEON enabled?

[pigod]

The result looks good. I'm wondering what exactly that Intel CPU is?

E3-1230 V2, 4 cores, 8 threads.

[pigod]

Have you built these bench mark tests with gcc 10.2 and 64bit mode + NEON enabled?

I don't know. I used the official latest version of Veracrypt pre-built for Raspberry Pi on their homepage (https://www.veracrypt.fr/en/Downloads.html). It was listed as 32bit, and the Pi OS is 32bit, so I guess it probably was not built with the 64bit mode you say. Does using 64bit application for this kind of thing significantly improve the performance? I am planning to use 64bit Pi OS once it gets officially released, so if using 64bit would increase the performance it would be a good thing for me.

[cleverca22]

Have you built these bench mark tests with gcc 10.2 and 64bit mode + NEON enabled?

I don't know. I used the official latest version of Veracrypt pre-built for Raspberry Pi on their homepage. It was listed as 32bit, and the Pi OS is 32bit, so I guess it probably was not built with the 64bit mode you say. Does using 64bit application for this kind of thing significantly improve the performance? I am planning to use 64bit Pi OS once it gets officially released, so if using 64bit would increase the performance it would be a good thing for me.

a lot of stuff targeting the pi will build for armv6, so it works on even a pi1
that means ignoring all of the fancy features more modern arm cores added, and makes the performance suffer a lot

[pigod]

a lot of stuff targeting the pi will build for armv6, so it works on even a pi1
that means ignoring all of the fancy features more modern arm cores added, and makes the performance suffer a lot

The installer package has "armhf" in its name. I searched the web and that seems to mean "for arm processors (armv7+) that have hardware floating point support. "

[cleverca22]

The installer package has "armhf" in its name. I searched the web and that seems to mean "for arm processors (armv7+) that have hardware floating point support. "

pi4 still has extra features that a base armv7 wont have
and 64bit also helps as well

[Kendek]

Cryptsetup benchmark results in 64-bit and NEON (where possible) mode:

Code: Select all

#            Algorithm |       Key |      Encryption |      Decryption
xchacha12,aes-adiantum        256b       216,2 MiB/s       216,7 MiB/s
xchacha20,aes-adiantum        256b       176,0 MiB/s       177,0 MiB/s
               aes-cbc        128b        25,3 MiB/s        82,4 MiB/s
           serpent-cbc        128b        38,2 MiB/s        39,0 MiB/s
           twofish-cbc        128b        59,8 MiB/s        60,6 MiB/s
          camellia-cbc        128b        59,2 MiB/s        60,2 MiB/s
               aes-cbc        256b        18,5 MiB/s        62,3 MiB/s
           serpent-cbc        256b        38,1 MiB/s        38,9 MiB/s
           twofish-cbc        256b        59,3 MiB/s        60,5 MiB/s
          camellia-cbc        256b        47,8 MiB/s        48,9 MiB/s
               aes-xts        256b        90,3 MiB/s        80,0 MiB/s
           serpent-xts        256b        41,2 MiB/s        41,5 MiB/s
           twofish-xts        256b        67,2 MiB/s        66,7 MiB/s
               aes-xts        512b        70,2 MiB/s        61,3 MiB/s
           serpent-xts        512b        41,4 MiB/s        41,5 MiB/s
           twofish-xts        512b        66,9 MiB/s        66,5 MiB/s

The newer and ARM-optimized Adiantum is the best choice on Pi, since there is no hardware AES acceleration. You can use it with cryptsetup and fscrypt. If you are also interested in VPN, consider WireGuard.

[spcharc]

The result looks good. I'm wondering what exactly that Intel CPU is?

E3-1230 V2, 4 cores, 8 threads.

Thanks for the info.

Seems it's faster than my i7 laptop CPU. No wonder it looks like 10x faster than pi4

[ejolson]

Cryptsetup benchmark results in 64-bit and NEON (where possible) mode:

Code: Select all

#            Algorithm |       Key |      Encryption |      Decryption
xchacha12,aes-adiantum        256b       216,2 MiB/s       216,7 MiB/s
xchacha20,aes-adiantum        256b       176,0 MiB/s       177,0 MiB/s
               aes-cbc        128b        25,3 MiB/s        82,4 MiB/s
           serpent-cbc        128b        38,2 MiB/s        39,0 MiB/s
           twofish-cbc        128b        59,8 MiB/s        60,6 MiB/s
          camellia-cbc        128b        59,2 MiB/s        60,2 MiB/s
               aes-cbc        256b        18,5 MiB/s        62,3 MiB/s
           serpent-cbc        256b        38,1 MiB/s        38,9 MiB/s
           twofish-cbc        256b        59,3 MiB/s        60,5 MiB/s
          camellia-cbc        256b        47,8 MiB/s        48,9 MiB/s
               aes-xts        256b        90,3 MiB/s        80,0 MiB/s
           serpent-xts        256b        41,2 MiB/s        41,5 MiB/s
           twofish-xts        256b        67,2 MiB/s        66,7 MiB/s
               aes-xts        512b        70,2 MiB/s        61,3 MiB/s
           serpent-xts        512b        41,4 MiB/s        41,5 MiB/s
           twofish-xts        512b        66,9 MiB/s        66,5 MiB/s

The newer and ARM-optimized Adiantum is the best choice on Pi, since there is no hardware AES acceleration. You can use it with cryptsetup and fscrypt. If you are also interested in VPN, consider WireGuard.

What operating system are you running on the 4B that has all these ciphers enabled? The reason I ask is because in

viewtopic.php?p=1679772#p1679772

I wanted to use twofish for cryptsetup but it didn't seem to be enabled in the default kernels included with either the 32-bit or 64-bit versions of Raspberry Pi OS.

[Kendek]

What operating system are you running on the 4B that has all these ciphers enabled? The reason I ask is because in

viewtopic.php?p=1679772#p1679772

I wanted to use twofish for cryptsetup but it didn't seem to be enabled in the default kernels included with either the 32-bit or 64-bit versions of Raspberry Pi OS.

Nothing special (Ubuntu from base tar.gz), but I've enabled some additional features (bcm2711_defconfig) and recompiled the official kernel.

[pigod]

Cryptsetup benchmark results in 64-bit and NEON (where possible) mode:

Code: Select all

#            Algorithm |       Key |      Encryption |      Decryption
xchacha12,aes-adiantum        256b       216,2 MiB/s       216,7 MiB/s
xchacha20,aes-adiantum        256b       176,0 MiB/s       177,0 MiB/s

Thanks for your sharing your result. I installed Ubuntu 20.04 (64-bit version) and tested this command `cryptsetup benchmark -c xchacha12,aes-adiantum -s 256 && cryptsetup benchmark -c aes-xts-plain64 -s 512` as shown on https://www.reddit.com/r/crypto/comment ... _kernel_5/

In my case, xchacha12,aes-adiantum got 138.7 and 165.9. Aes-xts got 62.7 and 56.3. Was your Pi overclocked? Mine is not overclocked, and there is no fan. Idle temperature is almost 70, and when I ran the benchmark, the temperature did not pass 80, but close to it, so it is possible that made it slow.

I ran VeraCrypt (ARM64) benchmark with 50MB buffer size on the same condition (i.e., hot), and I got 156/179 for TwoFish, and 147/144 for AES. One thing to mention is that selecting TwoFish algorithm when creating a volume failed on the Raspberry Pi OS, but succeeded on Ubuntu ARM64.

So, in my case VeraCrypt TwoFish and cryptosetup xchacha12 seem to be of about the same performance (TwoFish was slightly faster on my Pi). Do you still think the latter is better than the former (in terms of performance and security)? Not a rhetorical question, but a genuine question.

Also, I am not sure why cryptosetup AES is so much slower than VeraCrypt AES. As said above, it was 62.7/56.3 versus 147/144.

[Kendek]

In my case, xchacha12,aes-adiantum got 138.7 and 165.9. Aes-xts got 62.7 and 56.3. Was your Pi overclocked? Mine is not overclocked, and there is no fan. Idle temperature is almost 70, and when I ran the benchmark, the temperature did not pass 80, but close to it, so it is possible that made it slow.

Adiantum uses the CPU, so the benchmark results may vary, depending on the load. But yeah, my Pi is slightly overclocked and undervoltaged:
arm_freq=1600
over_voltage_delta=-5000

So, in my case VeraCrypt TwoFish and cryptosetup xchacha12 seem to be of about the same performance (TwoFish was slightly faster on my Pi). Do you still think the latter is better than the former (in terms of performance and security)? Not a rhetorical question, but a genuine question.

I think Adiantum is secure and the most optimized solution for ARM.

[ejolson]

In my case, xchacha12,aes-adiantum got 138.7 and 165.9. Aes-xts got 62.7 and 56.3. Was your Pi overclocked? Mine is not overclocked, and there is no fan. Idle temperature is almost 70, and when I ran the benchmark, the temperature did not pass 80, but close to it, so it is possible that made it slow.

Adiantum uses the CPU, so the benchmark results may vary, depending on the load. But yeah, my Pi is slightly overclocked and undervoltaged:
arm_freq=1600
over_voltage_delta=-5000

So, in my case VeraCrypt TwoFish and cryptosetup xchacha12 seem to be of about the same performance (TwoFish was slightly faster on my Pi). Do you still think the latter is better than the former (in terms of performance and security)? Not a rhetorical question, but a genuine question.

I think Adiantum is secure and the most optimized solution for ARM.

For those who are listening and could do something about it, it would be really nice if the kernels for the official Raspberry Pi OS supported Adiantum as it's almost as lively as the cha cha--truly an unexpected property for a fern.

[bensimmo]

I had expected a better result from Pi4. Yes, I knew that the 8-year-old Intel CPU is a desktop CPU and Pi4 is a mobile CPU, but since a lot of time has been passed and ARM CPU's have improved, my expectation was a little bit high.

8-year-old Intel CPU
AES 3.9GB/s (hardware-accelerated AES yes)
Camelia 1.5GB/s
Twofish 887MB/s
AES(Twofish) 783MB/s
Kuznyechik(Serpent(Camelia) 332MB/s

Pi4
Twofish 194MB/s
AES 113 MB/s
Camelia 102MB/s
AES(Twofish) 71MB/s
Kuznyechik(Serpent(Camelia) 20MB/s

Overall, Intel seems to be about 10 times faster than Pi4 (for some reason, Twofish was relatively faster on Pi4). I thought Pi4 would support hardware processing of such a widely used encryption like AES, but a quick web search says that Broadcom did not support it to avoid the licence cost.

Don't forget the Pi4 uses a 2016 ARM, so only five years newer than your Sandy Bridge Xeon (assuming original, Xeon has stupid version numbering),
so not 8 years.

Also given the Pi processor will have been for a media player, set top box at the time, I doubt server encryption security was high on the list .

Fast forward to 2020, security at a higher importance as connections start to demand it.

Maybe something like the BCM58732 would fit the bill, sounds expensive from the specs compared to the Pi setup.

[chwe]

Don't forget the Pi4 uses a 2016 ARM, so only five years newer than your Sandy Bridge Xeon (assuming original, Xeon has stupid version numbering),
so not 8 years.

Also given the Pi processor will have been for a media player, set top box at the time, I doubt server encryption security was high on the list .

Fast forward to 2020, security at a higher importance as connections start to demand it.

it's not a CPU age issue ARMv8 CPUs of the same generation with cryptoextensions will perform a way better. Just for a quick one with data collected under 'kinda similar' conditions (I like to get the data from one spot, otherwise you've no idea what you really compare, so all this data comes from https://github.com/ThomasKaiser/sbc-ben ... Results.md). Further the BCM2711 is not a 4 years old SoC design (the arm cores design was released 2015 if I got that right, but the overall SoC first showed up 2019 with the RPi, likely that broadcom released kinda similar stuff earlier under a different SoC name earlier - I've no idea about the broadcom SoC lineup as far as I know raspberries always (at least for the more recent iterations) had slightly customized SoCs or at least they got their own number.

Code: Select all

Board 			Clockspeed 	Kernel 	Distro 			7-zip 	AES-128 (16 byte) 	AES-256 (16 KB)
Raspberry Pi 4 B 	1500 MHz 	5.4 	Raspbian Buster arm64 	5080 	38070 			30170
Raspberry Pi 4 B 	1500 MHz 	4.19 	Raspbian Buster 	5500 	62350 			64860
Rock64 			1300 MHz 	4.18 	Bionic arm64 		3530 	116100 			605250
Rock64 			1300 MHz 	4.18 	Stretch arm64 		3560 	89070 			603800
RockPro64 		1800/1400 MHz 	4.18 	Stretch arm64 		6300 	237700 			1021500
Tinkerboard 		1730 MHz 	4.14 	Stretch armhf 		5350 	63150 			66600
x5-Z8300 		1420 MHz 	4.9 	Stretch amd64 		3900 	101580 			178010

comparing the rpi to a 8y old server CPU might not be that fair due to server CPUs focused on crypto a way earlier. But here are some other SoCs which might be closer to the RPi usecase.

- Rock64 is a rk3328 with a quadcore a53 SoC (according to your definition that's a ~8y old arm CPU, the built in SoC is from somewhere 2016 or so). With a weaker CPU and slower clockspeed it still outperforms the RPi by a large margin
- RockPro64 is a rk3399 with 2x a72 4x a53 core setup (also from 2016, in a lot of use-cases it performs 'kinda similar' to the 4x a72 rpi setup, except for crypto where it's just a beast compared to the Pi4)
- Z8300 is a dirtcheap atom from 2015 which also targets consumer market (I think the cheapest device with that SoC I bought was a 7'' tablet for something like 40$), it has intels AES-NI and without surprise it manages to beat the RPi in crypto as well.
-and for the last one the tinkerboard with a rk3288 (4x a17 from 2014, 32bit obviously without cryptoextensions cause it's a armV7) which performs kinda similar to the RPi in terms of AES

if we now look at 7zip score, it's not that the Pi4 underperforms here (it manages to beat some of the competitors and is even close to the rk3399). But this is not a "arm vs amd64" or "the chipdesign is old" problem. It's simply "has cryptoextensions or not issue", SoCs having it integrated will outperform the RPi in that even if they are overall slower (e.g. rk3328). Whenever this affects your use-case is then up to you to test. As long as encryption (and the increased CPU usage due to it) is not the bottleneck of your application it doesn't really matter. If it is the bottleneck you either have to accept it or go for another board/SoC.

This was/is a broadcom/RPT decision, broadcom for being one of the few chipmakers not opting for crypto extensions in their 'tv box/consumer grade stuff' SoC - rk3328 is a 'tv box' SoC too but has it (the only others I'm aware of are older amlogic SoCs but they added it to their newer SoCs) and RPT for opting for such an SoC. I might be wrong here but I would assume that you may have some impact on chipdesign given the tight connection between RPT and broadcom especially when you can assume that you can sell a couple million SoCs with every raspberry pi release. This topic came also up with the Pi3 as being the 'first' ARMv8 RPi (or was the Pi2 update with 64bit SoC earlier? I don't remember), but it seems that this was not of high priority for RPT. I think this was not that much of an issue during VC4 times where for a lot of use-cases the whole system was anyway bottlenecked by the single USB2 connection but now with a proper GbE as well as decent USB3 things might look different.

Maybe something like the BCM58732 would fit the bill, sounds expensive from the specs compared to the Pi setup.

just by a quick look, this SoC addresses a complete different audience compared to BCM2711, likely for headless only stuff. Maybe newer broadcom 'consumer SoC' will have them as well or already have it.. Their website summarizing their SoC lineup is just to painful (for me) to check that.

[bensimmo]

The Xeon is not exactly a desktop targeted CPU
The broadcom packaged processors and bits can be used for other things, hence I picked one that seemed to be more server oriented, looks like it has crypto stuff too.
It may also be the first I found in a search that looked nice that still used the old A72 setup.

If you look back, mainly as I cannot find, the A72 or similar quad core setups were used for other things (set top boxes iirc) by broadcom.
The Pi4 no doubt used the VC4, Core setup and whatever and repacked nicely for them
But that's for the RPT team to know about.

but the parts are there for RPT to stick together and bring out next month if they wish, because it's that easy
oh and keep a Xeon beating price of $35.


By age, I was meaning when the main design of the processor was done, the core design A72...
a bit like moving from a Core i5-1234 to a core i5-4234, they may bring them out later, but they are still an older core design.


If they ever add encryption part in future revisions, I'm sure many would benefit.
MythicBeasts?

[ejolson]

By age, I was meaning when the main design of the processor was done, the core design A72...

That's right, but to be fair to ARM and the Cortex-A72 you need to compare the five-year-old versions of that core which included the AES instructions. Those instructions do allow the A72 to serve https requests at gigabit speeds.

Back on the topic of encrypted storage, in my opinion Adiantum is likely to be more secure than AES anyway. Since one is not bound by compatibility with TLS in web browsers, it would be very nice to enable Adiantum in the Raspberry Pi OS kernel.

[chwe]

The Xeon is not exactly a desktop targeted CPU

I know

comparing the rpi to a 8y old server CPU might not be that fair due to server CPUs focused on crypto a way earlier.

The broadcom packaged processors and bits can be used for other things, hence I picked one that seemed to be more server oriented, looks like it has crypto stuff too.
It may also be the first I found in a search that looked nice that still used the old A72 setup.

a next major SoC iteration of the RPi doesn't have to stick to a A72 design.. Something like A75 being armv8.2-a could even have more hardware accelerated crypto optionally..

but the parts are there for RPT to stick together and bring out next month if they wish, because it's that easy
oh and keep a Xeon beating price of $35.

By age, I was meaning when the main design of the processor was done, the core design A72...
a bit like moving from a Core i. 5-1234 to a core i5-4234, they may bring them out later, but they are still an older core design.

doesn't do it yet, won't do it in the future.. different price class, different use case.. but a 4 years old rk3328 based on a 8 years old a-53 arm design already outperforms the RPi when it comes to crypto and those boards are in the same pricerange (starting from something like 20-25$ for 1GB ram up to 50-60$ for 4GB ram variants - you always get some dirt cheap TV boxes with the same SoC and in most cases it's even save to wipe and reflash the eMMC on it cause rockchip is 'kinda failsave' here but I would not recommend it if you don't have at least a bit experience in the more low level stuff of arm boards) as you can see.. that's not a price point question that's a does broadcom offer it on their VC based arm SoCs offer it or not.

MythicBeasts?

referring to rk3399? nope writing 90% of my forum posts here and there from a rk3399 based laptop, all my git repositories are locally hosed on such a SBC on a small NVME ssd (native not with some clunky usb sata bridge) it has more than enough CPU power to provide a nice webinterface too. The couple RPis I still have are used mostly for camera related stuff (they do well there) and one IoT application on a RPi B1 for some plant sensors.

Back on the topic of encrypted storage, in my opinion Adiantum is likely to be more secure than AES anyway.

for devices able to provide >50MB/s google requires to use AES, I don't think they would do that if they consider AES as not save enough.. But of course due to the chips limitation I would give CONFIG_CRYPTO_ADIANTUM a proper yes in kernelconfig.

[ejolson]

Back on the topic of encrypted storage, in my opinion Adiantum is likely to be more secure than AES anyway.

for devices able to provide >50MB/s google requires to use AES, I don't think they would do that if they consider AES as not save enough.. But of course due to the chips limitation I would give CONFIG_CRYPTO_ADIANTUM a proper yes in kernelconfig.

My understanding is that Google created Adiantum by doing standard stuff to turn the ChaCha stream cypher into a block cypher. That standard stuff looks fine to me and since most casinos are closed on account of the epidemic, gambling with Adiantum seems like a reasonable bet.

https://security.googleblog.com/2019/02 ... n-for.html

On the other hand, even though the standard curve has an interesting history, AES currently passes as best industry practice and enjoys super fast hardware acceleration in everything except the Raspberry Pi and a number of cheap mobile devices sold on the Indian subcontinent. To avoid the possibility of messing up encryption everywhere, it is understandable that Google would conservatively stick with AES for devices that support it well.

I just made a request in the Buster bug report thread

viewtopic.php?p=1734790#p1734790

to enable Adiantum in the default kernel for Raspberry Pi OS. I wonder if anyone will listen.