@bsv/sdk/dist/types/src/primitives/AESGCM.d.ts

BSV Blockchain Software Development Kit

export declare function AES(input: number[], key: number[]): number[];
export declare const checkBit: (byteArray: number[], byteIndex: number, bitIndex: number) => 1 | 0;
export declare const getBytes: (numericValue: number) => number[];
export declare const getBytes64: (numericValue: number) => number[];
type Bytes = Uint8Array;
export declare const exclusiveOR: (block0: Bytes, block1: Bytes) => Bytes;
export declare const rightShift: (block: Bytes) => Bytes;
export declare const multiply: (block0: Bytes, block1: Bytes) => Bytes;
export declare const incrementLeastSignificantThirtyTwoBits: (block: Bytes) => Bytes;
export declare function ghash(input: Bytes, hashSubKey: Bytes): Bytes;
/**
 * SECURITY NOTE – NON-STANDARD AES-GCM PADDING
 *
 * This implementation intentionally deviates from NIST SP 800-38D’s AES-GCM
 * specification in how the GHASH input is formed when the additional
 * authenticated data (AAD) or ciphertext length is zero.
 *
 * In the standard, AAD and ciphertext are each padded with the minimum number
 * of zero bytes required to reach a multiple of 16 bytes; when the length is
 * already a multiple of 16 (including the case length = 0), no padding block
 * is added. In this implementation, when AAD.length === 0 or ciphertext.length
 * === 0, an extra 16-byte block of zeros is appended before the length fields
 * are processed. The same formatting logic is used symmetrically in both
 * AESGCM (encryption) and AESGCMDecrypt (decryption).
 *
 * As a result:
 *   - Authentication tags produced here are NOT compatible with tags produced
 *     by standards-compliant AES-GCM implementations in the cases where AAD
 *     or ciphertext are empty.
 *   - Ciphertexts generated by this code must be decrypted by this exact
 *     implementation (or one that reproduces the same GHASH formatting), and
 *     must not be mixed with ciphertexts produced by a strictly standard
 *     AES-GCM library.
 *
 * Cryptographic impact: this change alters only the encoding of the message
 * that is input to GHASH; it does not change the block cipher, key derivation,
 * IV handling, or the basic “encrypt-then-MAC over (AAD, ciphertext, lengths)”
 * structure of AES-GCM. Under the usual assumptions that AES is a secure block
 * cipher and GHASH with a secret subkey is a secure polynomial MAC, this
 * variant continues to provide confidentiality and integrity for data encrypted
 * and decrypted consistently with this implementation. We are not aware of any
 * attack that exploits the presence of this extra zero block when AAD or
 * ciphertext are empty.
 *
 * However, this padding behavior is non-compliant with NIST SP 800-38D and has
 * not been analyzed as extensively as standard AES-GCM. Code that requires
 * strict standards compliance or interoperability with external AES-GCM
 * implementations SHOULD NOT use this module as-is. Any future migration to a
 * fully compliant AES-GCM encoding will require a compatibility strategy, as
 * existing ciphertexts produced by this implementation will otherwise become
 * undecryptable.
 *
 * This non-standard padding behavior is retained intentionally for backward
 * compatibility: existing ciphertexts in production were generated with this
 * encoding, and changing it would render previously encrypted data
 * undecryptable by newer versions of the library.
 */
export declare function AESGCM(plainText: Bytes, initializationVector: Bytes, key: Bytes): {
    result: Bytes;
    authenticationTag: Bytes;
};
export declare function AESGCMDecrypt(cipherText: Bytes, initializationVector: Bytes, authenticationTag: Bytes, key: Bytes): Bytes | null;
export {};
//# sourceMappingURL=AESGCM.d.ts.map