Feature request: add crypto acceleration support

[M95D]

Lots of routers and other devices now have some form of crypto acceleration usually available with /dev/crypto.
Is it possible to add support for crypto acceleration and remove the software crypto library? It would make dropbear smaller and increase file transfer speed a lot, especially on low-power CPUs.
Thanks.

[mkj]

Is the a particular platform/acceleration you're interested in? There's a mention of AES for libtomcrypt libtom/libtomcrypt#557 (comment) , though acceleration might also be useful for ECC.

I don't know if /dev/crypto for AES/AES-GCM/SHA256 would be faster than chacha20-poly1305 in software.

[M95D]

I have a router with hardware AES, DES, DES3, SHA1, SHA256, MD5 and XOR. CPU is Marvell Armada XP.
The ideea was to make libtomcrypt optional and use the kernel instead. Speed was just a bonus.

[BrainSlayer]

@M95D you know that kernel crypto is way slower than userspace soft crypto? the problem is the userspace / kernel context switch. all data must be tranfered to the kernel space and back after encryption/decryption. in addition there is no real usefull api for kernel crypto which can be accessed from userspace, except for some custom hacks like OCF framework which is not part of the official kernel

[M95D]

For small blocks, yes.
As I said, the main advantage is size reduction, by removing the crypto library.

As I understand it (I might be very wrong) /dev/crypto requires opening that file and performing some ioctls to set up a session and send/receive data. There is no library or anything else other than a header file to import. This request was to ask if it was possible to use the kernel instead of a library, not about speed.

[BrainSlayer]

@M95D small blocks are the common use for ssh. and /dev/crypto is ocf framework. this is not part of the mainline kernel. its originally freebsd and available as third party patch

[M95D]

@BrainSlayer

• Small blocks are slower, but not that slow. And they are mostly console text. It doesn't matter even if it's extremely slow. A human can't type, nor read, as fast as the slowest kernel crypto out there. File transfers are (or should be) big blocks.
• How about the kernel's official AF_ALG? Any embedded dev can add that with just a menuconfig checkbox.
• I don't know anything about SSH internals, but maybe kernel TLS can be used to avoid at least 2 user-kernel moves (crypto to dropbear, dropbear to network)? Maybe allow removing some more dropbear code, too?
• You may argue that the reduction in dropbear size would be offset by a bigger increase in kernel size for crypto, because AFAIK the kernel can't have hardware crypto support without also having those exact same algos in software. So, the size increase may be true and significant, but on many machines the kernel already has crypto enabled for other purposes. An option to switch between crypto in a library and crypto in kernel (or both) would allow the devs to choose what's best for their specific systems.

Thank you.