Quote:
Originally Posted by danmartinj
1. Is Null Encryption enabled by default in the Linux Kernel?
|
Well, lets see:
Code:
user@test:~$ cd $(mktemp -d)
user@test:/tmp/tmp.5DGoQZ$ wget -q -O - https://www.kernel.org/pub/linux/kernel/v4.x/linux-4.4.tar.xz | tar -xJ
user@test:/tmp/tmp.5DGoQZ$ cd linux-4.4
user@test:/tmp/tmp.5DGoQZ$/linux-4.4$ make defconfig
HOSTCC scripts/basic/fixdep
HOSTCC scripts/kconfig/conf.o
SHIPPED scripts/kconfig/zconf.tab.c
SHIPPED scripts/kconfig/zconf.lex.c
SHIPPED scripts/kconfig/zconf.hash.c
HOSTCC scripts/kconfig/zconf.tab.o
HOSTLD scripts/kconfig/conf
*** Default configuration is based on 'i386_defconfig'
#
# configuration written to .config
#
user@test:/tmp/tmp.5DGoQZ$/linux-4.4$ grep CONFIG_CRYPTO_NULL < .config
CONFIG_CRYPTO_NULL=y
CONFIG_CRYPTO_NULL2=y
user@test:/tmp/tmp.5DGoQZ$/linux-4.4$
So yes, the kernel default settings do seem to include NULL crypto support, but I'm not entirely convinced that's what you were asking about. The question is probably whether a particular distribution comes with a kernel with CRYPTO_NULL support, and that's an entirely different matter.
One could argue that using NULL encryption (which means you're not actually encrypting anything) is completely pointless outside of a lab/test setup, and could potentially be dangerous if accidentally enabled in a production environment. For those reasons, I wouldn't be at all surprised if I were to find that some distribution maintainers had chosen to disable NULL support in the kernel.
Anyway, running
zcat /proc/config.gz | grep CRYPTO_NULL on the system in question should tell you. Unless they've disabled proc support for config.gz as well, that is.
Quote:
Originally Posted by danmartinj
2. What are specific requirements for using it?
|
None, really. Kernel support for a certain encryption protocol means one can make use of system calls to perform encryption and decryption, but there's nothing preventing a userspace application from implementing any protocol it wants.
IPsec support does not reside entirely in kernel space. For instance, the IKE process responsible for negotiating Phase1 Security Associations, which includes selecting a set of mutually supported encryption protocols, is not part of the kernel. Instead, you need to install and run a userspace program like StrongSwan's
charon daemon to accept or initiate IPsec connections/tunnels. Whether or not the IKE daemon will allow NULL encryption is a matter of configuration.
Having said that, most IPsec software on the Linux platform depend on crypto support in the kernel. Disable NULL support, or any of the other protocols, and it's unlikely that the software will be able to work around it.
Quote:
Originally Posted by danmartinj
3. If possible, are there any howtos or examples using it?
|
Take a look at the StrongSwan documentation, specifically the man page for ipsec.conf. The "ike" setting determines the protocols used for Phase1, while the "esp" setting does the same for Phase2.
By the way,
here's a list of the supported encryption suites in StrongSwan. As you can see, "null" is indeed supported.
