Festplattenverschlüsslung auf schwächeren Systemen

[Alica_384]

Hi mal wieder,

ich bin gerade in der Phase in der ich sämtliche IT-Systeme optimieren möchte. Nun möchte ich mehrere Festplatten auf einem Leistungsschwachen ARM System (2x1.2 GHz Overclocked) verschlüsseln. Auf dem System läuft eine auf Debian basierte Linux Distribution mit dem 3.4 Kernel. Der CPU unterstützt leider kein AES-NI.

Im Benchmark bekommen ich folgende Werte:
# Algorithm | Key | Encryption | Decryption
aes-cbc 128b 18.8 MiB/s 20.1 MiB/s
serpent-cbc 128b 14.0 MiB/s 15.4 MiB/s
twofish-cbc 128b 22.2 MiB/s 24.3 MiB/s
aes-cbc 256b 14.9 MiB/s 15.5 MiB/s
serpent-cbc 256b 14.0 MiB/s 15.4 MiB/s
twofish-cbc 256b 22.2 MiB/s 24.2 MiB/s
aes-xts 256b 19.7 MiB/s 19.7 MiB/s
serpent-xts 256b 14.5 MiB/s 15.2 MiB/s
twofish-xts 256b 23.3 MiB/s 23.7 MiB/s
aes-xts 512b 15.3 MiB/s 15.3 MiB/s
serpent-xts 512b 14.5 MiB/s 15.1 MiB/s
twofish-xts 512b 23.3 MiB/s 23.6 MiB/s


Die Geschwindigkeiten sind leider viel zu langsam, ich bräuchte zumindest 40MiB/s RW. Bei dem Benchmark wird seltsamer weise auch nur 1 Kern belastet.

Gibt es evtl. Performance Tweaks oder andere Lösungen, die Verschlüsslung kann ruhig auch ein wenig schwächer sein solange es kein einfaches DES ist.

 

[HominiLupus]

Nutze ein Programm bzw. Kernelmodule oder was auch immer das alle Kerne ausnutzt. dann gehts.
Probiere bzw. kompiliere mit einem Desktop Debian ohne AES-NI und dann mach das Gleiche für die ARM Kiste.

 

[Bagbag]

Im Benchmark

Welcher Benchmark?

 

[repicajo]

Welcher Benchmark?

Das sieht sehr stark nach "cryptsetup benchmark" aus. Bei mir nutzt er da auch nur einen Kern.

 

[Alica_384]

ja, das ist "cryptsetup benchmark", sry habe vergessen das zu erwähnen.

 

[Bagbag]

Also, meine Recherche hat ergeben, dass LUKS pro block device ein Thread nutzt. Wenn du also auf 2 Festplatten zeitgleich zugreifst (vorausgesetzt, sie laufen nicht als RAID), sollte es insgesamt doppelt so schnell sein.

 

[Sensei21]

Ist http://cateee.net/lkddb/web-lkddb/CRYPTO_PCRYPT.html CONFIG_CRYPTO_PCRYPT in den Kernel einkompiliert oder per Modul geladen ?

für ARM64 gibt es meines Wissens beschleunigte bzw. optimierte Verschlüsselung,

für ARM dürften sich auch einige Patchsets finden


z.B.: (für 3.5 Kernel)

https://patchwork.kernel.org/patch/1282381/ Patchwork [1/1] arm/crypto: Add optimized AES and SHA1 routines

Add assembler versions of AES and SHA1 for ARM platforms. This has provided
up to a 50% improvement in IPsec/TCP throughout for tunnels using AES128/SHA1.

Platform CPU SPeed Endian Before (bps) After (bps) Improvement

IXP425 533 MHz big 11217042 15566294 ~38%
KS8695 166 MHz little 3828549 5795373 ~51%

Signed-off-by: David McCullough <ucdevel@gmail.com>

irgendwo wie ja wohl ein gepatcher Kernel sein, der dies bereits nutzt ...


ferner gibt es meines Wissens noch ARM NEON AES Module die auch schneller sein sollten ...

z.B.:

https://github.com/CyanogenMod/andr...mmit/75dd533eb28595ce31237289c9157dffae5ab165 ARM: add support for bit sliced AES using NEON instructions

ARM: add support for bit sliced AES using NEON instructions
Bit sliced AES gives around 45% speedup on Cortex-A15 for encryption
and around 25% for decryption. This implementation of the AES algorithm
does not rely on any lookup tables so it is believed to be invulnerable
to cache timing attacks.

This algorithm processes up to 8 blocks in parallel in constant time. This
means that it is not usable by chaining modes that are strictly sequential
in nature, such as CBC encryption. CBC decryption, however, can benefit from
this implementation and runs about 25% faster. The other chaining modes
implemented in this module, XTS and CTR, can execute fully in parallel in
both directions.

 

[chithanh]

Anstatt die ARM-CPU damit auszulasten, könntest du auch Festplatten oder SSDs verwenden, die Verschlüsselung mittels ATA-Passwort unterstützen.