Encrypted root on an old Celeron 1200... slow...

Message

eccerr0r · Post by **eccerr0r** » Mon Aug 22, 2022 2:40 pm

I had this old Celeron 1200 that I was using for its ISA slot and due to not having SSE2 was not worth to keep updating to latest (the Gentoo install is old enough to still have a copy of Firefox that works! Not that I use it...) It's using a 3.5 kernel too! I had dumped this system on a 3 disk SCSI RAID5. The SCSI disks, though LVD, I don't have any cables to get more than ~40MHz on, cable is similar to standard UDMA cables and I have an active terminator on it. At U160 speeds it errors quite often unfortunately with my AHA29160. At U80 speeds, RAID5 sync speeds are even throttled due to bandwidth issues...

Anyway, for S&G's I wanted to update my custom initramfs to also deal with encrypted root. So now trying to build root on cryptfs on MDRAID5. So far I got the system dumped on it but...

holy crap this is slow.

When I was doing the volume wipe (for plausible deniability) it was writing a whopping 5MB/sec. Wow. Slow. As I didn't really need plausible deniability I just cancelled it and did without.

Next I need to hack up my initramfs to set up this beast, ask password, etc. though this 5MB/sec is going to be an issue. Normally it can deal with 50MB/sec to PATA disks so encryption is using a significant amount of cpu... or is this even normal?

(These old machines - the Celeron 1.2GHz and the Via C3 Nehemiah 1GHz... are just pitiful, can't do anything else when copying stuff from and to disks... any encryption or compression from gzip, ssh, or cryptoloop will bottleneck!!!)

Goverp · Post by **Goverp** » Mon Aug 22, 2022 6:27 pm

AFAIR, DMA was a kernel driver option. I vaguely remember if you're not using DMA I/O it goes one byte at a time or thereabouts.

Post by **NeddySeagoon** » Mon Aug 22, 2022 6:52 pm

Goverp,

DMA was an optional extra with ye olde PATA drivers.
As you say, PIO mode is one byte at a time with the CPU dying all the byte shifting.

With real 8 bit SCSI, DMA, overlapping commands on the bus, IRQs, and all those other good things that SCSI always did that were dropped when Compaq took a SCSI subset and called it IDE were always there.
It is 3 drives on the same SCSI bus though so they have to share SCSI bus bandwidth.

mike155 · Post by **mike155** » Mon Aug 22, 2022 6:58 pm

Does 'top' reveal what makes your computer slow? Is it I/O wait? Or the encryption/decryption process?

eccerr0r · Post by **eccerr0r** » Mon Aug 22, 2022 7:26 pm

Yes, CPU is pegged as it tries to write encrypted data to the disks. It's also using KMS and can see redraw is slower than normal as I switch between VTs.

Not unexpected though seems maybe a little slow.

Normally the Celeron can get 40MB/sec through mdraid to the SCSI disks, though the individual disks can also sustain at least 40MB/sec. But once cryptsetup to the disks it seems to drop down to 5MB/sec. This is a bit slow as there's no network involved unlike the Via C3 Nehemiah. Though I can get 50MB/sec through UDMA66 to the IDE disks on the Nehemiah, trying to ssh/scp to the disks it drops down to 6MB/sec or so through the network (GbE). CPU is pegged.

Anyway, it seems the ABI for cryptsetup changed. Seems I get different behavior with the 3.5.7 kernel and the 5.15.59 kernel I was testing on a VM with cryptsetup, as well as still different behavior with the old SysRescue CD when it still was using Gentoo (think it's a 4.x kernel) ...

ponder ponder...

mike155 · Post by **mike155** » Mon Aug 22, 2022 9:45 pm

Please post the output of

Code: Select all

cryptsetup benchmark

Don't worry - it runs in memory - and won't destroy your data.

Results on my desktop machine (a fast AMD Ryzen 7 5700G CPU)

Code: Select all

# Tests are approximate using memory only (no storage IO).
PBKDF2-sha1      3163125 iterations per second for 256-bit key
PBKDF2-sha256    5637505 iterations per second for 256-bit key
PBKDF2-sha512    2614902 iterations per second for 256-bit key
PBKDF2-ripemd160  960234 iterations per second for 256-bit key
PBKDF2-whirlpool  868026 iterations per second for 256-bit key
argon2i      14 iterations, 1048576 memory, 4 parallel threads (CPUs) for 256-bit key (requested 2000 ms time)
argon2id     14 iterations, 1048576 memory, 4 parallel threads (CPUs) for 256-bit key (requested 2000 ms time)
#     Algorithm |       Key |      Encryption |      Decryption
        aes-cbc        128b      1474.7 MiB/s      6021.6 MiB/s
    serpent-cbc        128b       142.3 MiB/s      1015.3 MiB/s
    twofish-cbc        128b       276.7 MiB/s       514.0 MiB/s
        aes-cbc        256b      1113.4 MiB/s      4893.7 MiB/s
    serpent-cbc        256b       141.6 MiB/s      1014.7 MiB/s
    twofish-cbc        256b       279.4 MiB/s       516.8 MiB/s
        aes-xts        256b      5147.0 MiB/s      5141.5 MiB/s
    serpent-xts        256b       850.8 MiB/s       838.2 MiB/s
    twofish-xts        256b       475.1 MiB/s       470.3 MiB/s
        aes-xts        512b      4264.1 MiB/s      4283.3 MiB/s
    serpent-xts        512b       849.1 MiB/s       831.6 MiB/s
    twofish-xts        512b       473.3 MiB/s       471.6 MiB/s

Results on my Internet gateway (a slow Intel Celeron N2930 CPU):

Code: Select all

# Tests are approximate using memory only (no storage IO).
PBKDF2-sha1       414129 iterations per second for 256-bit key
PBKDF2-sha256     523764 iterations per second for 256-bit key
PBKDF2-sha512     344926 iterations per second for 256-bit key
PBKDF2-ripemd160  286183 iterations per second for 256-bit key
PBKDF2-whirlpool  179550 iterations per second for 256-bit key
argon2i       4 iterations, 484395 memory, 4 parallel threads (CPUs) for 256-bit key (requested 2000 ms time)
argon2id      4 iterations, 487877 memory, 4 parallel threads (CPUs) for 256-bit key (requested 2000 ms time)
#     Algorithm |       Key |      Encryption |      Decryption
        aes-cbc        128b        71.9 MiB/s        81.6 MiB/s
    serpent-cbc        128b        37.0 MiB/s        90.7 MiB/s
    twofish-cbc        128b        82.5 MiB/s        83.3 MiB/s
        aes-cbc        256b        56.1 MiB/s        63.0 MiB/s
    serpent-cbc        256b        37.0 MiB/s        90.8 MiB/s
    twofish-cbc        256b        82.5 MiB/s        83.3 MiB/s
        aes-xts        256b        82.0 MiB/s        79.0 MiB/s
    serpent-xts        256b        84.2 MiB/s        84.0 MiB/s
    twofish-xts        256b        77.6 MiB/s        77.7 MiB/s
        aes-xts        512b        61.9 MiB/s        61.3 MiB/s
    serpent-xts        512b        84.3 MiB/s        83.9 MiB/s
    twofish-xts        512b        77.4 MiB/s        77.5 MiB/s

eccerr0r · Post by **eccerr0r** » Tue Aug 23, 2022 1:09 am

hmm. I guess my custom kernel might not be completely compiled right, but sysrescuecd for this Celeron 1200 (Tualatin Core):

Code: Select all

# Tests are approximate using memory only (no storage IO).
PBKDF2-sha1       112798 iterations per second for 256-bit key
PBKDF2-sha256     140034 iterations per second for 256-bit key
PBKDF2-sha512      45957 iterations per second for 256-bit key
PBKDF2-ripemd160   87849 iterations per second for 256-bit key
PBKDF2-whirlpool   34062 iterations per second for 256-bit key
#     Algorithm | Key |  Encryption |  Decryption
        aes-cbc   128b    28.1 MiB/s    28.0 MiB/s
    serpent-cbc   128b    16.5 MiB/s    14.4 MiB/s
    twofish-cbc   128b    25.9 MiB/s    30.9 MiB/s
        aes-cbc   256b    24.3 MiB/s    25.0 MiB/s
    serpent-cbc   256b    16.6 MiB/s    16.2 MiB/s
    twofish-cbc   256b    29.4 MiB/s    31.3 MiB/s
        aes-xts   256b    31.6 MiB/s    31.0 MiB/s
    serpent-xts   256b    17.5 MiB/s    15.9 MiB/s
    twofish-xts   256b    30.4 MiB/s    29.5 MiB/s
        aes-xts   512b    26.7 MiB/s    23.5 MiB/s
    serpent-xts   512b    17.5 MiB/s    11.7 MiB/s
    twofish-xts   512b    30.0 MiB/s    26.9 MiB/s

BTW this is PC133 SDRAM (3x512MB, Via shi^H^H^H^H chipset, memtest86+ reports a little higher than 300MB/sec bandwidth, which is higher than the "DDR" Via C3 Nehemiah at 290MB/sec...)

mike155 · Post by **mike155** » Tue Aug 23, 2022 9:35 am

So your CPU is really slow. But encryption speed is faster than 5 MB/s.

Please repeat this test under Gentoo and with your own kernel.

It could be that your system is misconfigured. For example, there's this issue, which makes CPUs run at only 20% of their maximum performance. That would reduce encryption speed to 5 MB/s.

Make sure that the kernel options below are enabled:

Code: Select all

CONFIG_CRYPTO
CONFIG_CRYPTO_CRYPTD
CONFIG_CRYPTO_SIMD
CONFIG_CRYPTO_SHA256
CONFIG_CRYPTO_CBC
CONFIG_CRYPTO_ECB
CONFIG_CRYPTO_XTS
CONFIG_CRYPTO_AES
CONFIG_CRYPTO_SERPENT
CONFIG_CRYPTO_SERPENT_SSE2_X86_64
CONFIG_CRYPTO_TWOFISH
CONFIG_CRYPTO_TWOFISH_COMMON
CONFIG_CRYPTO_TWOFISH_X86_64_3WAY

eccerr0r · Post by **eccerr0r** » Tue Aug 23, 2022 10:26 am

I think the speed I'm getting is probably close to where it should be based on how slow the CPU is. No AES-NI instructions, no SSE2 instructions, single core, no PNI/64-bit, only 1.2GHz,...

I suppose I always knew FDE was slow but didn't realize it was this slow on older hardware. Also have to figure that it needs to calculate parity for the RAID and this too needs to be part of the computation it needs to do before it goes to disk.

I think I'm done with this setup, my custom initramfs is now capable of booting at least this root-on-crypt-on-mdraid system... Seems that cryptsetup does its own 3 strikes you're out on password attempts, not sure if I should just let the initramfs drop to a shell or just hang when guesses are exhausted.

Now what would be nice is if I can get all my systems to use this same initramfs regardless of disk configuration, just to reduce number of different custom initramfs I have floating around, mainly for label based partition volume identification but also for these weird root disk configurations (root-on-crypt-on-mdraid and root-on-lvm-on-mdraid).
Maybe next would be root-on-crypt-on-lvm-on-mdraid ...

mike155 · Post by **mike155** » Tue Aug 23, 2022 10:42 am

You could increase the number of retries in /etc/conf.d/dmcrypt:

Code: Select all

# How long to wait for each timeout (in seconds).
dmcrypt_key_timeout=1

# Max number of checks to perform (see dmcrypt_key_timeout).
#dmcrypt_max_timeout=300

# Number of password retries.
dmcrypt_retries=5

eccerr0r · Post by **eccerr0r** » Tue Aug 23, 2022 12:11 pm

and allow the hacker to get more guesses? :D

Alas, at this point it would be a "evil maid" attack since they're obviously at the console (plugging at my initramfs) and there's no more security anymore...so basically it's just to frustrate any passerby hackers or frustrate myself when I leave caps lock on...

Post by **NeddySeagoon** » Tue Aug 23, 2022 12:35 pm

eccerr0r,

You can build the initrd with CFLAGS that has -march not set and -mtune=generic.
Then pass in parameters on the kernel command line.

If you really want a challenge, make the initrd code 32 bit, so it will run anywhere.
That will require 32 bit support in the kernel.

eccerr0r · Post by **eccerr0r** » Tue Aug 23, 2022 12:41 pm

Well, of course my initramfs contents is 32-bit, and I use the same initramfs where possible on my 64-bit machines because I was too lazy to pull a second set of binaries for it. (Main use for initramfs was for LABEL= for pointing at root.)

Incidentally kind of sad: the first set of binaries I used for my original initramfs took 2.4MB. The one I pulled a few days ago the image was almost 7MB. Talk about bloat... *sigh* Alas not apples to apples, this new initramfs has cryptsetup on it whereas originally it only had busybox, mdadm, and lvm...