Package-Level Type Names (total 7, in which 5 are exported)
/* sort exporteds by: | */
CMAC implements the CMAC mode from NIST SP 800-38B.
It is optimized for use in Counter KDF (SP 800-108r1) and XAES-256-GCM
(https://c2sp.org/XAES-256-GCM), rather than for exposing it to applications
as a stand-alone MAC.baes.Blockk1[16]bytek2[16]byte(*CMAC) MAC(m []byte) [16]byte(*CMAC) deriveSubkeys()
func NewCMAC(b *aes.Block) *CMAC
CounterKDF implements a KDF in Counter Mode instantiated with CMAC-AES,
according to NIST SP 800-108 Revision 1 Update 1, Section 4.1.
It produces a 256-bit output, and accepts a 8-bit Label and a 96-bit Context.
It uses a counter of 16 bits placed before the fixed data. The fixed data is
the sequence Label || 0x00 || Context. The L field is omitted, since the
output key length is fixed.
It's optimized for use in XAES-256-GCM (https://c2sp.org/XAES-256-GCM),
rather than for exposing it to applications as a stand-alone KDF.macCMAC DeriveKey derives a key from the given label and context.
func NewCounterKDF(b *aes.Block) *CounterKDF
gGCMmaskuint64nextuint64prefixuint32readybool(*GCMWithXORCounterNonce) NonceSize() int(*GCMWithXORCounterNonce) Open(dst, nonce, ciphertext, data []byte) ([]byte, error)(*GCMWithXORCounterNonce) Overhead() int Seal implements the [cipher.AEAD] interface, checking that the nonce prefix
is stable and that the counter is strictly increasing.
It is not safe for concurrent use. SetNoncePrefixAndMask sets the fixed prefix and XOR mask for the nonces used
in Seal. It must be called before the first call to Seal.
The first 32 bits of nonce are used as the fixed prefix, and the last 64 bits
are used as the XOR mask.
Note that Seal expects the nonce to be already XOR'd with the mask. The mask
is provided here only to allow Seal to enforce that the counter is strictly
increasing.
*GCMWithXORCounterNonce : crypto/cipher.AEAD
func NewGCMForHPKE(cipher *aes.Block) (*GCMWithXORCounterNonce, error)
func NewGCMForQUIC(cipher *aes.Block, iv []byte) (*GCMWithXORCounterNonce, error)
func NewGCMForTLS13(cipher *aes.Block) (*GCMWithXORCounterNonce, error)
func NewGCMWithXORCounterNonce(cipher *aes.Block) (*GCMWithXORCounterNonce, error)
gcmFieldElement represents a value in GF(2¹²⁸). In order to reflect the GCM
standard and make binary.BigEndian suitable for marshaling these values, the
bits are stored in big endian order. For example:
the coefficient of x⁰ can be obtained by v.low >> 63.
the coefficient of x⁶³ can be obtained by v.low & 1.
the coefficient of x⁶⁴ can be obtained by v.high >> 63.
the coefficient of x¹²⁷ can be obtained by v.high & 1.highuint64lowuint64
func ghashAdd(x, y *gcmFieldElement) gcmFieldElement
func ghashDouble(x *gcmFieldElement) (double gcmFieldElement)
func ghashAdd(x, y *gcmFieldElement) gcmFieldElement
func ghashDouble(x *gcmFieldElement) (double gcmFieldElement)
func ghashMul(productTable *[16]gcmFieldElement, y *gcmFieldElement)
func ghashMul(productTable *[16]gcmFieldElement, y *gcmFieldElement)
func ghashUpdate(productTable *[16]gcmFieldElement, y *gcmFieldElement, data []byte)
func ghashUpdate(productTable *[16]gcmFieldElement, y *gcmFieldElement, data []byte)
func updateBlocks(productTable *[16]gcmFieldElement, y *gcmFieldElement, blocks []byte)
func updateBlocks(productTable *[16]gcmFieldElement, y *gcmFieldElement, blocks []byte)
Package-Level Functions (total 39, in which 12 are exported)
GHASH is exposed to allow crypto/cipher to implement non-AES GCM modes.
It is not allowed as a stand-alone operation in FIPS mode because it
is not ACVP tested.
NewCounterKDF creates a new CounterKDF with the given key.
NewGCMForHPKE returns a new AEAD that works like GCM, but enforces the
construction of nonces as specified in RFC 9180, Section 5.2.
This complies with FIPS 140-3 IG C.H Scenario 5.
NewGCMForQUIC returns a new AEAD that works like GCM, but enforces the
construction of nonces as specified in RFC 9001, Section 5.3.
Unlike in TLS 1.3, the QUIC nonce counter does not always start at zero, as
the packet number does not reset on key updates, so the XOR mask must be
provided explicitly instead of being learned on the first Seal call. Note
that the nonce passed to Seal must already be XOR'd with the IV, the IV is
provided here only to allow Seal to enforce that the counter is strictly
increasing.
This complies with FIPS 140-3 IG C.H Scenario 5.
NewGCMForSSH returns a new AEAD that works like GCM, but enforces the
construction of nonces as specified in RFC 5647.
This complies with FIPS 140-3 IG C.H Scenario 1.d.
NewGCMForTLS12 returns a new AEAD that works like GCM, but enforces the
construction of nonces as specified in RFC 5288, Section 3 and RFC 9325,
Section 7.2.1.
This complies with FIPS 140-3 IG C.H Scenario 1.a.
NewGCMForTLS13 returns a new AEAD that works like GCM, but enforces the
construction of nonces as specified in RFC 8446, Section 5.3.
This complies with FIPS 140-3 IG C.H Scenario 1.a.
NewGCMWithCounterNonce returns a new AEAD that works like GCM, but enforces
the construction of deterministic nonces. The nonce must be 96 bits, the
first 32 bits must be an encoding of the module name, and the last 64 bits
must be a counter. The starting value of the counter is set on the first call
to Seal, and each subsequent call must increment it as a big-endian uint64.
If the counter reaches the starting value minus one, Seal will panic.
This complies with FIPS 140-3 IG C.H Scenario 3.
NewGCMWithXORCounterNonce returns a new AEAD that works like GCM, but
enforces the construction of deterministic nonces. The nonce must be 96 bits,
the first 32 bits must be an encoding of the module name, and the last 64
bits must be a counter XOR'd with a fixed value. The module name and XOR mask
can be set with [GCMWithCounterNonce.SetNoncePrefixAndMask], or they are set
on the first call to Seal, assuming the counter starts at zero. Each
subsequent call must increment the counter as a big-endian uint64. If the
counter reaches 2⁶⁴ minus one, Seal will panic.
This complies with FIPS 140-3 IG C.H Scenario 3.
SealWithRandomNonce encrypts plaintext to out, and writes a random nonce to
nonce. nonce must be 12 bytes, and out must be 16 bytes longer than plaintext.
out and plaintext may overlap exactly or not at all. additionalData and out
must not overlap.
This complies with FIPS 140-3 IG C.H Scenario 2.
Note that this is NOT a [cipher.AEAD].Seal method.
checkGenericIsExpected is called by the variable-time implementation to make
sure it is not used when hardware support is available. It shouldn't happen,
but this way it's more evidently correct.
deriveCounterGeneric computes the initial GCM counter state from the given nonce.
See NIST SP 800-38D, section 7.1. This assumes that counter is filled with
zeros on entry.
gcmAuthGeneric calculates GHASH(additionalData, ciphertext), masks the result
with tagMask and writes the result to out.
gcmCounterCryptGeneric encrypts src using AES in counter mode with 32-bit
wrapping (which is different from AES-CTR) and places the result into out.
counter is the initial value and will be updated with the next value.
gcmInc32 treats the final four bytes of counterBlock as a big-endian value
and increments it.
ghash is a variable-time generic implementation of GHASH, which shouldn't
be used on any architecture with hardware support for AES-GCM.
Each input is zero-padded to 128-bit before being absorbed.
ghashAdd adds two elements of GF(2¹²⁸) and returns the sum.
ghashDouble returns the result of doubling an element of GF(2¹²⁸).
ghashMul sets y to y*H, where H is the GCM key, fixed during New.
ghashUpdate extends y with more polynomial terms from data. If data is not a
multiple of gcmBlockSize bytes long then the remainder is zero padded.
sliceForAppend takes a slice and a requested number of bytes. It returns a
slice with the contents of the given slice followed by that many bytes and a
second slice that aliases into it and contains only the extra bytes. If the
original slice has sufficient capacity then no allocation is performed.
updateBlocks extends y with more polynomial terms from blocks, based on
Horner's rule. There must be a multiple of gcmBlockSize bytes in blocks.
Package-Level Variables (total 3, none are exported)
The pages are generated with Goldsv0.8.4. (GOOS=linux GOARCH=amd64)
Golds is a Go 101 project developed by Tapir Liu.
PR and bug reports are welcome and can be submitted to the issue list.
Please follow @zigo_101 (reachable from the left QR code) to get the latest news of Golds.
