include/crypto/sm4.h
Source file repositories/reference/linux-study-clean/include/crypto/sm4.h
File Facts
- System
- Linux kernel
- Corpus path
include/crypto/sm4.h- Extension
.h- Size
- 1248 bytes
- Lines
- 49
- Domain
- Repository Root And Misc
- Bucket
- include
- Inferred role
- Repository Root And Misc: implementation source
- Status
- source implementation candidate
Why This File Exists
Top-level or miscellaneous repository surface. Use this as map coverage unless a later manual pass promotes the file into a deeper subsystem dossier.
- Top-level or miscellaneous repository surface. Use this as map coverage unless a later manual pass promotes the file into a deeper subsystem dossier.
- Defines or uses C structs; map object ownership, embedded links, reference counts, and lock ownership.
Dependency Surface
linux/types.hlinux/crypto.h
Detected Declarations
struct sm4_ctx
Annotated Snippet
struct sm4_ctx {
u32 rkey_enc[SM4_RKEY_WORDS];
u32 rkey_dec[SM4_RKEY_WORDS];
};
extern const u32 crypto_sm4_fk[];
extern const u32 crypto_sm4_ck[];
extern const u8 crypto_sm4_sbox[];
/**
* sm4_expandkey - Expands the SM4 key as described in GB/T 32907-2016
* @ctx: The location where the computed key will be stored.
* @in_key: The supplied key.
* @key_len: The length of the supplied key.
*
* Returns 0 on success. The function fails only if an invalid key size (or
* pointer) is supplied.
*/
int sm4_expandkey(struct sm4_ctx *ctx, const u8 *in_key,
unsigned int key_len);
/**
* sm4_crypt_block - Encrypt or decrypt a single SM4 block
* @rk: The rkey_enc for encrypt or rkey_dec for decrypt
* @out: Buffer to store output data
* @in: Buffer containing the input data
*/
void sm4_crypt_block(const u32 *rk, u8 *out, const u8 *in);
#endif
Annotation
- Immediate include surface: `linux/types.h`, `linux/crypto.h`.
- Detected declarations: `struct sm4_ctx`.
- Atlas domain: Repository Root And Misc / include.
- Implementation status: source implementation candidate.
Implementation Notes
- This generated page is the file-by-file coverage layer; curated subsystem chapters should link here when they synthesize a multi-file control flow.
- Core OS pages should be promoted from atlas-only to deep-reviewed when they explain data structures, invariants, locking, lifecycle, and C implementation snippets.
- Driver-family pages are intentionally pattern-oriented unless they are part of the selected PCIe/NVMe representative device path.