![]() ![]() Overall, Intel seems to be about 10 times faster than Pi4 (for some reason, Twofish was relatively faster on 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.ĪES 3.9GB/s (hardware-accelerated AES yes) 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.Īlso, I am not sure why cryptosetup AES is so much slower than VeraCrypt AES. So, in my case VeraCrypt TwoFish and cryptosetup xchacha12 seem to be of about the same performance (TwoFish was slightly faster on my Pi). One thing to mention is that selecting TwoFish algorithm when creating a volume failed on the Raspberry Pi OS, but succeeded on Ubuntu ARM64. ![]() 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. 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. Was your Pi overclocked? Mine is not overclocked, and there is no fan. In my case, xchacha12,aes-adiantum got 138.7 and 165.9. ![]() 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. 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. What operating system are you running on the 4B that has all these ciphers enabled? The reason I ask is because in If you are also interested in VPN, consider WireGuard. You can use it with cryptsetup and fscrypt. 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. If encryption is compromised, so is your data.Code: Select all # Algorithm | Key | Encryption | Decryption ![]() HDD offer the better security when encrypted, but vulnerable to data recovery tools. How does one interpret these facts from a Op-sec pov? On one hand SSD are vulnerable when encrypted due to wear leveling, yet against data recovery tools difficult to retrieve data from. (Pg 101/102 Conclusion) "From the results obtained, this study concludes that data deleted on Hard Disk Drives can completely be retrieved, and data deleted on Solid-State Drives cannot be completely retrieved using Autopsy forensic tool, whereas sometimes it can be retrieved using ProDiscover Basic forensic tool". The Trim function, and self-corrosion properties of the SSD play a large role in the prevention of data recovery. But after reading "Comparing SSD Forensics with HDD Forensics" analysis paper from 2020 ( ) SSD are superior in thwarting forensic efforts for several reason. I was, considering replacing it with a HDD. Even tho Trim can be disabled the wear leveling is compromising enough. After further research it seems using VC on a SSD won't "ensure" the level of security I desire for several reasons.Īs you know Veracrypt recommends not using SSD due to wear leveling and the Trim operation. My goal was to use a VM and place it in the hidden VC container. I have a SSD and wanted to use Veracrypt for plausible deniability and protection against any & all level attacks e.g. ![]()
0 Comments
Leave a Reply. |