Sim, nos kernels recentes, os pedidos dmcrypt podem ser paralelizados. Os patches de paralelização foram integrados em 4.0 , de relance (4.0 dm-crypt.c inclui kthread.h , versões anteriores não) . As versões mais antigas tinham uma única fila de trabalho para solicitações dmcrypt, então blocos diferentes não podiam ser criptografados ou descriptografados em paralelo (mesmo em dispositivos diferentes, até onde eu sei).
No entanto, a paralelização nem sempre é uma vitória. Demora algum tempo para despachar solicitações para uma CPU diferente e coletar resultados, portanto, é uma vitória apenas se houver solicitações suficientes em paralelo e você não estiver aguardando em um único bloco por vez. Normalmente, você ganharia se tivesse vários aplicativos acessando arquivos diferentes, mas não tanto (ou possivelmente até perder um pouco) ao trabalhar com um único arquivo grande.
Se você deseja um melhor desempenho de criptografia, obtenha algo baseado em um processador ARMv8, com aceleração AES, ou seja, na prática, uma CPU de 64 bits. A aceleração de criptografia de hardware faz uma diferença real, muito mais do que a paralelização ocorre na melhor das hipóteses, e ajuda em todas as cargas de trabalho, desde que o tempo de CPU seja o gargalo. Observe que nem todas as CPUs baseadas em ARMv8 têm aceleração de criptografia de hardware (às vezes, é deixado de fora para evitar a execução de regulamentos de exportação / importação de criptografia). Mas, mesmo sem criptografia de hardware, a execução no modo de 64 bits pode ser uma aceleração mensurável.
Acontece que o Pi 3 não tem extensões criptografadas. O Banana Pi M64 pode ser bom para você, já que tem extensões de criptografia (se eu não me confundir com o SoC muito semelhante nomes). O subsistema SATA do Pi M64 está no topo do USB 2 (como o M3), e isso não é tão rápido quanto as versões com um controlador SATA nativo, então um Raspberry Pi 3 pode ser tão bom se a E / S acabar ser o gargalo porque a criptografia não satura a CPU de qualquer maneira.