go-encryptions logo go-encryptions
LICENSE=BSD-3-ClauseCGO_ENABLED=0
Fork me on GitHub

go-encryptions

Pure-Go encryption primitives — the AEAD modes and disk-encryption crypto the standard library leaves out, with no cgo and no golang.org/x/crypto dependency.

Documentation GitHub
stdlib crypto only no x/crypto standard cipher.AEAD interfaces
zsh
$ go get github.com/go-encryptions/ccm@latest
$ go get github.com/go-encryptions/zfscrypt@latest
$ go get github.com/go-encryptions/xts@latest
$ go get github.com/go-encryptions/unixcrypt@latest
One organisation, 4 repositories
ccmzfscryptxtsunixcrypt

A small family of pure-Go encryption building blocks that sit just below application code: cipher modes and key-derivation paths that the Go standard library does not ship, exposed through the same crypto/cipher interfaces you already use. The first piece, ccm, supplies the AES-CCM AEAD that crypto/cipher omits; the second, zfscrypt, builds on it to decrypt OpenZFS native-encrypted datasets.

Everything compiles and runs anywhere Go does, using only crypto/aes, crypto/cipher and the rest of the standard crypto tree — no C bindings, no third-party crypto dependency. Implementations follow their reference specifications (RFC 3610 / NIST SP 800-38C for CCM; the OpenZFS on-disk crypto layout for zfscrypt) and ship with Go test suites.

Repositories

ccm libaead

AES-CCM AEAD (NewCCM / Seal / Open)

Pure-Go CCM (Counter with CBC-MAC) per RFC 3610 and NIST SP 800-38C — the AEAD mode the standard library's crypto/cipher does not provide (it only ships GCM). Wraps any 128-bit cipher.Block as a standard cipher.AEAD, with configurable tag (4..16) and nonce (7..13) sizes. No cgo, no golang.org/x/crypto.

zfscrypt libdisk

OpenZFS native-encryption crypto (read path)

Pure-Go implementation of the cryptographic half of OpenZFS dataset-level (native) encryption: PBKDF2 wrapping-key derivation, master-key unwrap, HKDF-SHA512 per-block key derivation, and AES-CCM/GCM block decryption. Covers AES-128/192/256 in CCM (via ccm) and GCM (stdlib). Read path only today — enough to pull files out of an encrypted root.

xts libdisk

XTS-AES, four blocks at a time (AES-NI / ARMv8 AES)

Pure-Go XTS-AES (IEEE P1619, NIST SP 800-38E) — the sector-level mode LUKS, FileVault 2, BitLocker and dm-crypt use. A drop-in replacement for <code>golang.org/x/crypto/xts</code>, byte-identical output, same API; the difference is that it pipelines four AES blocks and folds the tweak XOR into the round pipeline instead of driving <code>cipher.Block</code> one 16-byte block at a time. Assembly on amd64 and arm64; riscv64, loong64, ppc64le and s390x fall back to the same per-block algorithm, so behaviour is identical everywhere and only the speed differs.

unixcrypt libpassword

crypt(3) / MCF: $1$, $5$, $6$, $2a$..$2y$

Pure-Go crypt(3)/MCF password hashes: MD5-crypt, SHA-256-crypt and SHA-512-crypt per Drepper's specification, and bcrypt over the pure-Go blowfish primitive. Nothing links libc's own <code>crypt(3)</code>, so it cross-compiles and gives identical output on every Go target, big-endian s390x included. Validated against real <code>openssl passwd</code> and the canonical OpenBSD <code>bcrypt.c</code> vectors. Extracted from go-puppet/puppet's <code>pw_hash()</code> so that go-puppet and go-ansible/template share one implementation rather than each having their own.

Every module is pure Go with CGO_ENABLED=0 and depends only on the standard crypto packages (no golang.org/x/crypto). Algorithms follow their reference specifications and expose the idiomatic cipher.AEAD / hash interfaces so they drop into existing code.