hpenc solves the problem that there is no simple tool to quickly
transfer data with encryption and authentication:
-* openssl enc -- uses single CPU, no authentication
-* GnuPG -- complex key generation/management, relatively slow
-* OpenSSH -- uses single CPU, not very fast
+* openssl enc -- non-parallelized, no authentication
+* GnuPG -- non-parallelized, complex key generation/management
+* age -- non-parallelized
+* OpenSSH -- non-parallelized, not very fast
Why gohpenc was written? hpenc has some problems: it does not work on
aarch64 and sparc64 architectures under FreeBSD (as seen in the port's
Makefile) and produces incompatible output (unauthenticated after 8192
blocks) between FreeBSD and HardenedBSD systems somehow. Instead of
painful debugging I decided to write something similar on the Go
-language, widening supported platforms.
+language, widening supported platforms. But with loose of compatibility
+with hpenc.
-gohpenc is incompatible with hpenc and much simpler:
+Also hpenc won't fail if transmission was truncated (in valid block
+bounds).
-* it uses only ChaCha20-Poly1305 algorithm
-* no random data generation mode
-* no metadata in output stream and no structure validation. Only blocks
- authentication
-* simpler key derivation -- new key for each block
+It uses ChaCha20-Poly1305, parallelized AEAD encryption of blocks.
-But it still satisfies most of hpenc aims:
+ $ key=`gohpenc -psk`
+ $ echo "message to be transmitted" | gohpenc -k $key > encrypted
+ $ gohpenc -d -k $key < encrypted
-* Very simple key management -- single pre-shared key
-* Parallelizeable -- each block is encrypted in different thread, so all
- your CPUs could be utilized
-* Very fast -- ChaCha20-Poly1305 is fast even on relatively low-end
- devices like mobile devices. Despite gohpenc is written on Go, its
- dependent libraries contain assembly-optimized code
-* Built-in authentication and integrity check with small data overhead
+Blocksize can be specified with -b option (in KiBs). By default it uses
+1MiB blocks. By default all CPUs are used, that can be overriden with -c
+option. If you have got 8 CPUs, then you require (8+1)*1MiB=9MiB of
+memory for buffers allocation.
-Usage is very simple:
-
- $ gohpenc -psk
- DTGZI5R2HS4YEDSIO56AFKPONE6KJE3Q2QETODDOH3O6UYFPROHQ
- $ echo "message to be transmitted" | gohpenc -k DTGZI5R2HS4YEDSIO56AFKPONE6KJE3Q2QETODDOH3O6UYFPROHQ > encrypted
- $ gohpenc -k DTGZI5R2HS4YEDSIO56AFKPONE6KJE3Q2QETODDOH3O6UYFPROHQ -d < encrypted
-
-How encryption/authentication is performed:
-
-* First 32 bytes of the stream contain random data -- salt
-* BLAKE2X is initialized: unknown length, PSK key as a MAC key. It
- creates XOF that will be used as a KDF
-* Salt is fed into that XOF
-* All data is processed block by block
-* New key is derived for each block by reading it from the XOF
-* ChaCha20-Poly1305 algorithm is initialized with that key
-* 32-bit big-endian value with the length of the block is outputted,
- then an encrypted and authenticated block goes further, with
- authenticated data containing that 32-bit length value
-
- /----------BLOCK-------------\ /----------BLOCK------------\
-+------+-----+------------+----------+-----+------------+----------+----
-| SALT | LEN | CIPHERTEXT | AUTH TAG | LEN | CIPHERTEXT | AUTH TAG | ...
-+------+-----+------------+----------+-----+------------+----------+----
-
-gohpenc preallocates memory for one block for each thread and one block
-for buffered reading from stdin. If you want to process data with 1 MiB
-blocks in 4 threads, then you have to have at least 5 MiBs of free
-memory. Moreover you have at least 1 MiB of free memory on the
-decrypting side.
+There is random number generation mode (-r option), that just generates
+random key and encrypt dummy data in the buffers.
gohpenc is free software: see the file COPYING for copying conditions.