From d0af27e2631814478a48feb25f9be0d24124772f Mon Sep 17 00:00:00 2001 From: Logan007 Date: Fri, 4 Sep 2020 02:22:22 +0545 Subject: [PATCH 1/5] updated Crypto.md and added information to Building.md --- doc/Building.md | 24 +++++++++++++++++++++--- doc/Crypto.md | 14 +++++++------- 2 files changed, 28 insertions(+), 10 deletions(-) diff --git a/doc/Building.md b/doc/Building.md index 3194dde..a98aa2d 100644 --- a/doc/Building.md +++ b/doc/Building.md @@ -88,9 +88,27 @@ See `edge.exe --help` and `supernode.exe --help` for a list of supported options # General Building Options -## Low Memory Footprint +## Compiler Optimizations -Some parts of the code (well, one for now: Pearson hashing) offer an optional low memory footprint if compiled using with the macro `LOW_MEM_FOOTPRINT`. GCC will make it happen with `-DLOW_MEM_FOOTPRINT` eventually specified along with other options of choice during configuration: +The easiest way to boosting speed is by allowing the compiler to apply optimization to the code. To let the compiler know, the configuration process can take in the optionally specified compiler flag `-O3`: -`./configure CFLAGS="-O3 -march=native -DLOW_MEM_FOOTPRINT"` +`./configure CFLAGS="-O3"` +The `tools/n2n-benchmark` tool reports speed-ups of 200% or more! There is no known risk in terms of instable code or so. + +## Hardware Features + +Some parts of the code can be compiled to benefit from available hardware acceleration. It needs to be decided at compile-time. So, if compiling for a specific platform with known features (maybe the local one), it should be specified to the compiler, for example through the `-march=sandybridge` (you name it) or just `-march=native` for local use. + +So far, the following portions of n2n's code benefit from hardware acceleration: + +``` +AES: AES-NI +ChaCha20: SSE2, SSSE3 +SPECK: SSE4.2, AVX2, NEON +Pearson Hashing: AES-NI +``` + +The compilations flags could easily be combined: + +`./configure CFLAGS="-O3 -march=native"`. \ No newline at end of file diff --git a/doc/Crypto.md b/doc/Crypto.md index a66cb29..e561065 100644 --- a/doc/Crypto.md +++ b/doc/Crypto.md @@ -18,17 +18,17 @@ The following chart might help to make a quick comparison and decide what cipher | Cipher | Mode | Block Size | Key Size | IV length |Speed | Built-In | Origin | | :---: | :---:| :---: | :---: | :---: |:---: | :---: | --- | |Twofish | CTS | 128 bits | 256 bit | 128 bit | -..O | Y | Bruce Schneier | -|AES | CBC | 128 bits | 128, 192, 256 bit| 128 bit | O..+ | N | Joan Daemen, Vincent Rijmen, NSA-approved | +|AES | CTS | 128 bits | 128, 192, 256 bit| 128 bit | O..+ | N | Joan Daemen, Vincent Rijmen, NSA-approved | |ChaCha20| CTR | Stream | 256 bit | 128 bit | +..++| N | Daniel J. Bernstein | |SPECK | CTR | Stream | 256 bit | 128 bit | ++ | Y | NSA | The two block ciphers Twofish and AES are used in CTS mode. -Note that AES and ChaCha20 are available only if n2n is compiled with openSSL support. n2n will work well without them offering the respectively reduced choice of remaining built-in ciphers (Twofish, SPECK). +n2n has all four ciphers built-in as basic versions. Some of them optionally compile to faster versions by the means of available hardware support (AES-NI, SSE, AVX – please see the [Building document](./Building.md) for details. Also, AES and ChaCha20 might draw notable acceleration from compiling with openSSL 1.1 support. ### Twofish -This implementation prepends a 128 bit random value to the plain text. Its size is adjustable by changing the `TF_PREAMBLE_SIZE` definition found in `src/transform_tf.c`. It defaults to TF_BLOCK_SIZE (== 16). As CTS uses underlying CBC mode, this basically has the same effect as a respectively shorter IV. +This implementation prepends a 128 bit random value to the plain text. Its size is adjustable by changing the `TF_PREAMBLE_SIZE` definition found in `src/transform_tf.c`. It defaults to TF_BLOCK_SIZE (== 16). As CTS uses underlying CBC mode, this basically has the same effect as a respectively shorter IV. However, this flexibility does not come for free as an additional block needs to be encrypted. Twofish requires no padding as it employs a CBC/CTS scheme which can send out plaintext-length ciphertexts. The scheme however has a small flaw in handling messages shorter than one block, only low-level programmer might encounter this. @@ -38,13 +38,13 @@ On Intel CPUs, Twofish usually is the slowest of the ciphers present. However, o AES also prepends a random value to the plaintext. Its size is adjustable by changing the `AES_PREAMBLE_SIZE` definition found in `src/transform_aes.c`. It defaults to AES_BLOCK_SIZE (== 16). The AES scheme uses a CBC/CTS scheme which can send out plaintext-length ciphertexts as long as they are one block or more in length. -AES relies on openSSL's `evp_*` interface which also offers hardware acceleration where available (SSE, AES-NI, …). It however is slower than the following stream ciphers because the CBC mode cannot compete with the optimized stream ciphers. +Apart from n2n's plain C implementation, Intel's AES-NI is supported – again, please habe a look at the [Building document](./Building.md). In case of openSSL support its `evp_*` interface gets used which also offers hardware acceleration where available (SSE, AES-NI, …). It however is slower than the following stream ciphers because the CBC mode cannot compete with the optimized stream ciphers. ### ChaCha20 ChaCha20 was the first stream cipher supported by n2n. -It also relies on openSSL's `evp_*` interface. It does not use the Poly1305 message tag from the same author though. Whole packet's checksum will be handled in the header (see below). +In addition to the basic C implementation, a SSE version is offered. If compiled with openSSL support, ChaCha20 is provided via the `evp_*` interface. It is not used together with the Poly1305 message tag from the same author though. Whole packet's checksum will be handled in the header (see below). The random full 128-bit IV is transmitted in plain. @@ -66,7 +66,7 @@ Its initialization relies on seeding with a value as random as possible. Various For general purpose hashing, n2n employs Pearson hashing as it offers variable hash sizes and is said not to be too "collidy". However, this is not a cryptographically secure hashing function which by the way is not required here: The hashing is never applied in a way that the hash shall prove the knowledge of a secret without showing the secret. -_Pearson hashing is tweakable by making your own permutation of the 256 byte table._ +_Pearson hashing is tweakable by making your own permutation of the 256 byte table._ Here, the AES' s-box is used: Given appropriate hardware, a lookup could even be accelerated. _Pearson hashing allows verification of parts of the hash only – just in case performance requirements would urge to do so._ @@ -166,7 +166,7 @@ Thus, header encryption will only work with previously determined community name The whole packet including the eventually present payload is checksummed using a modified Person hashing. It might seem a little short compared to usual message tags of 96 up to 128 bit, especially when using a stream cipher which easily allows for bit-flips. So, the 16-bit checksum is filled up with 80 more bits to obtain a 96-bit pre-IV. This pre-IV gets encrypted using a single block-cipher step to get the pseudo-random looking IV. This way, the checksum resists targeted bit-flips (to header, payload, and IV) as any change to the whole 96-bit IV would render the header un-decryptable. -The single block-cipher step employs SPECK because it is fast, always present as built-in and it offers a 96-bit version. The key is derived from the header key – a hash of the hash. +The single block-cipher step employs SPECK because it is fast and it offers a 96-bit version. The key is derived from the header key – a hash of the hash. The checksum gets verified by the edges and the supernode. From 651c3933d82e9914a33bfd8c408878ad24117b74 Mon Sep 17 00:00:00 2001 From: Logan007 Date: Sun, 6 Sep 2020 15:13:08 +0545 Subject: [PATCH 2/5] updated Crypto.md and added information to Building.md --- doc/Building.md | 14 +++++++++++++- doc/Crypto.md | 2 +- 2 files changed, 14 insertions(+), 2 deletions(-) diff --git a/doc/Building.md b/doc/Building.md index a98aa2d..1ac2748 100644 --- a/doc/Building.md +++ b/doc/Building.md @@ -111,4 +111,16 @@ Pearson Hashing: AES-NI The compilations flags could easily be combined: -`./configure CFLAGS="-O3 -march=native"`. \ No newline at end of file +`./configure CFLAGS="-O3 -march=native"`. + +## OpenSSL Support + +Some ciphers' speed can take advantage of OpenSSL support which is disabled by default as the built-in ciphers already prove reasonably fast in most cases. OpenSSL support can be configured using + +`./configure --with-openssl` + +which then will include OpenSSL 1.0 or 1.1 if found on the system. This can be combined with the hardware support and compiler optimizations such as + +`./configure --with-openssl CFLAGS="-O3 -march=native"` + +Please do no forget to `make clean` after (re-)configuration and before building using `make`. \ No newline at end of file diff --git a/doc/Crypto.md b/doc/Crypto.md index e561065..de684d7 100644 --- a/doc/Crypto.md +++ b/doc/Crypto.md @@ -24,7 +24,7 @@ The following chart might help to make a quick comparison and decide what cipher The two block ciphers Twofish and AES are used in CTS mode. -n2n has all four ciphers built-in as basic versions. Some of them optionally compile to faster versions by the means of available hardware support (AES-NI, SSE, AVX – please see the [Building document](./Building.md) for details. Also, AES and ChaCha20 might draw notable acceleration from compiling with openSSL 1.1 support. +n2n has all four ciphers built-in as basic versions. Some of them optionally compile to faster versions by the means of available hardware support (AES-NI, SSE, AVX – please see the [Building document](./Building.md) for details. Depending on your platform, AES and ChaCha20 might also draw notable acceleration from optionally compiling with openSSL 1.1 support. ### Twofish From 8033ea300f7ededa50f3372a2df46d5643258152 Mon Sep 17 00:00:00 2001 From: Logan007 Date: Sun, 6 Sep 2020 15:17:52 +0545 Subject: [PATCH 3/5] updated Crypto.md and added information to Building.md --- doc/Building.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/Building.md b/doc/Building.md index 1ac2748..026776d 100644 --- a/doc/Building.md +++ b/doc/Building.md @@ -123,4 +123,4 @@ which then will include OpenSSL 1.0 or 1.1 if found on the system. This can be c `./configure --with-openssl CFLAGS="-O3 -march=native"` -Please do no forget to `make clean` after (re-)configuration and before building using `make`. \ No newline at end of file +Please do no forget to `make clean` after (re-)configuration and before building (again) using `make`. \ No newline at end of file From 645cfaa681461c4f684daea3916fb8a34c8898e9 Mon Sep 17 00:00:00 2001 From: Logan007 Date: Thu, 10 Sep 2020 13:53:47 +0545 Subject: [PATCH 4/5] updated Crypto.md and added information to Building.md --- doc/Building.md | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-) diff --git a/doc/Building.md b/doc/Building.md index 026776d..f6ce979 100644 --- a/doc/Building.md +++ b/doc/Building.md @@ -123,4 +123,16 @@ which then will include OpenSSL 1.0 or 1.1 if found on the system. This can be c `./configure --with-openssl CFLAGS="-O3 -march=native"` -Please do no forget to `make clean` after (re-)configuration and before building (again) using `make`. \ No newline at end of file +Please do no forget to `make clean` after (re-)configuration and before building (again) using `make`. + +## ZSTD Compression Support + +In addition to the built-in LZO1x for payload compression (`-z1` at the edge's commandline), n2n optionally supports [ZSTD](https://github.com/facebook/zstd). As of 2020, it is considered cutting edge and [praised](https://en.wikipedia.org/wiki/Zstandard) for reaching the currently technologically possible Pareto frontier in terms of CPU power versus compression ratio. ZSTD support can be configured using + +`./configure -- with-zstd` + +which then will include ZSTD if found on the system. It will be available via `-z2` at the edges. Of course, it can be combined with the other features mentioned above: + +`./configure --with-openssl --with-zstd CFLAGS="-O3 -march=native"` + +Again, please do no forget to `make clean` after (re-)configuration and before building (again) using `make` – can't reiterate often enough. From 733c7c5c9d35d9fc42db26fe12d4e3e51f440f9c Mon Sep 17 00:00:00 2001 From: Logan007 Date: Thu, 10 Sep 2020 13:56:06 +0545 Subject: [PATCH 5/5] updated Crypto.md and added information to Building.md --- doc/Building.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/doc/Building.md b/doc/Building.md index f6ce979..b9625a0 100644 --- a/doc/Building.md +++ b/doc/Building.md @@ -129,10 +129,10 @@ Please do no forget to `make clean` after (re-)configuration and before building In addition to the built-in LZO1x for payload compression (`-z1` at the edge's commandline), n2n optionally supports [ZSTD](https://github.com/facebook/zstd). As of 2020, it is considered cutting edge and [praised](https://en.wikipedia.org/wiki/Zstandard) for reaching the currently technologically possible Pareto frontier in terms of CPU power versus compression ratio. ZSTD support can be configured using -`./configure -- with-zstd` +`./configure --with-zstd` which then will include ZSTD if found on the system. It will be available via `-z2` at the edges. Of course, it can be combined with the other features mentioned above: -`./configure --with-openssl --with-zstd CFLAGS="-O3 -march=native"` +`./configure --with-zstd --with-openssl CFLAGS="-O3 -march=native"` -Again, please do no forget to `make clean` after (re-)configuration and before building (again) using `make` – can't reiterate often enough. +Again, this cannot be reiterated often enough, please do no forget to `make clean` after (re-)configuration and before building (again) using `make`.