struct crypto_tfm {
u32 crt_flags;
union {
struct cipher_tfm cipher;
struct digest_tfm digest;
struct compress_tfm compress;
} crt_u; //该联合体指出linux实现了cipher，digest和compress三类算法，每一类中有许多种算法，注意这个联合的每一个都仅仅实现了一大类算法的实现封装，并不是具体的实现。
struct crypto_alg *__crt_alg;
char __crt_ctx[] __attribute__ ((__aligned__));
};
下面这个结构体才是具体算法的实现，上面crypto_tfm中的crt_u中一系列函数都是对下面结构体中cra_u中一系列函数的封装：
struct crypto_alg {
struct list_head cra_list;
u32 cra_flags; //这个flags很重要
unsigned int cra_blocksize;
unsigned int cra_ctxsize;
unsigned int cra_alignmask;
int cra_priority;
char cra_name[CRYPTO_MAX_ALG_NAME];
char cra_driver_name[CRYPTO_MAX_ALG_NAME];
union {
struct cipher_alg cipher;
struct digest_alg digest;
struct compress_alg compress;
} cra_u;
int (*cra_init)(struct crypto_tfm *tfm);
void (*cra_exit)(struct crypto_tfm *tfm);
struct module *cra_module;
};
上面的两个结构中都有一个联合体，事实上每个联合体字段都是一个完整的算法实现，而且三个算法类型几乎没有任何共同点可言，对于摘要类算法来说，回调函数是init，update，final等，而对于cipher而言，就是encrypt和decrypt等，linux实际上是利用联合体的性质来将三类算法封装到了一个结构体中。
crt_u里面的回调函数和cra_u中的回调函数名称几乎一模一样，但是它们的层次不同，crt中的函数实现了一大类算法的运行逻辑，比如cipher中的des中的块应该怎么分割等等，虽然对于摘要算法，sha1或者别的什么的算法逻辑没有什么区别，但是对于cipher来讲就不是这样了，同一种算法可能拥有ecb，cbc，fcb等不同的模式，于是就来了个中间层，这个中间层就是上面的联合体crt_u。
最后，linux将所有的三大类算法组织成了并列的链表，在注册算法的时候要通过crypto_register_alg将一个crypto_alg结构体注册进内核，就是说摘要和加密算法不做区别，只有在crypto_alloc_tfm的时候才会根据算法的名称和flags来确定这个算法到底是做什么的，判断的依据就是crypto_alg中的cra_name字段和cra_flags字段。
从上述结构体和代码可以看出，linux对加crypto的算法的组织要远比openssl的简单，这也许是linux内核运行效率决定的吧。下面看一下重要的crypto_alloc_tfm函数，很多工作都在这个函数里面完成，比如初始化函数的执行逻辑，也就是初始化crt_u的一堆函数指针，顺便说一下，如果你把crypto_alg理解成一个静态的结构的话，那么crypto_tfm就是一个动态的容器，这种动静结合的方式在优秀的开源代码中很常见，都是用静态的结构初始化动态的结构，然后再根据一些策略逻辑完成动态结构的初始化，有时候动态结构就是一个用于解除耦合的桥梁，比如一些过程的controler，有的时候它就是一个上下文环境或者说是一个容器，比如命名为xxx_ctx的结构体，对于linux内核的cryptoAPI，crypto_tfm可以说是一个桥梁，也可以说是一个容器，一个controler，具体是什么不重要，重要的是代码灵活了：
struct crypto_tfm *crypto_alloc_tfm(const char *name, u32 flags)
{
struct crypto_tfm *tfm = NULL;
struct crypto_alg *alg;
unsigned int tfm_size;
alg = crypto_alg_mod_lookup(name);//根据名称来查找算法实现
tfm_size = sizeof(*tfm) + crypto_ctxsize(alg, flags);
tfm = kzalloc(tfm_size, GFP_KERNEL);
tfm->__crt_alg = alg;
crypto_init_flags(tfm, flags);
crypto_init_ops(tfm);
alg->cra_init(tfm);
...
return tfm;
}
crypto_init_ops函数完成了具体实现的封装，也就是说它初始化了crypto_tfm结构体中crt_u中的一系列函数指针：
static int crypto_init_ops(struct crypto_tfm *tfm)
{
switch (crypto_tfm_alg_type(tfm)) {
case CRYPTO_ALG_TYPE_CIPHER:
return crypto_init_cipher_ops(tfm);//初始化cipher封装函数，下面例子中以digest来说明，它在这里的调用逻辑和cipher原理是一样的，都是在crypto_init_ops实现具体实现的封装过程。
...
}
下面是使用linux内核中cryptoAPI实现的digest的一个例子的大致过程，流程和openssl的evp系列是差不多的，只是在涉及算法实现的点上有差异：
char *Kern_Digest(const void *data, size_t count,
unsigned char *md, unsigned int *size, const char *name)
{
struct crypto_tfm *tfm;
struct scatterlist sg[1];
tfm = crypto_alloc_tfm(name, 0);
sg_init_one(sg, data, count); //此往下，摘要算法的实现已经确定了，接下来只剩下回调函数的调用了
crypto_digest_init(tfm);
crypto_digest_update(tfm, sg, 1);
crypto_digest_final(tfm, md);
if (size != NULL)
*size = tfm->cra_digest.dia_digestsize;
crypto_free_tfm(tfm);
}
crypto_digest_xxx系列函数仅仅是具体实现的封装，以init为例：
static inline void crypto_digest_init(struct crypto_tfm *tfm)
{
tfm->crt_digest.dit_init(tfm);//dit_init依然是一个封装，它在crypto_init_ops中被初始化，这个dit_YYY系列的封装才是有意义的封装。
}
这种封装解除了调用者和实现者之间的耦合。下面是openssl中的digest的实现过程：
int EVP_Digest(const void *data, size_t count,
unsigned char *md, unsigned int *size, const EVP_MD *type, ENGINE *impl)
{ //传入的type参数其实只是一个空壳，仅仅包含了nid字段是有效的，对于EVP_MD来说就是type字段，因为别的字段具体是什么还要看engine的实现，所以此处的参数type可以仅仅理解成一个算法id。
EVP_MD_CTX ctx;
EVP_MD_CTX_init(&ctx);
M_EVP_MD_CTX_set_flags(&ctx,EVP_MD_CTX_FLAG_ONESHOT);
ret=EVP_DigestInit_ex(&ctx, type, impl)
&& EVP_DigestUpdate(&ctx, data, count)
&& EVP_DigestFinal_ex(&ctx, md, size);
EVP_MD_CTX_cleanup(&ctx);
...
}
在对外呈现的接口上，openssl和linux是一致的，openssl需要一个算法的id，而linux需要一个算法的名称，所不同的是，openssl有engine的支持，这样同一个算法就可以指定不同的实现，engine作为算法名称或者id和算法实现之间的桥梁存在，解除了它们之间的耦合。而linux由于没有engine，那么只要给定了一个算法名称，比如sha1，那么只能得到唯一的实现，虽然内核可能通过增加优先级字段来影响算法实现的被选中率，但是这种做法远没有openssl的engine灵活，但是反过来想一下，内核中的机制都是比较稳定的，不经常变动的，而且linux本身就不提倡你在内核完成一些功能，除非万不得已，因此linux的crypto的设计也算是圆满了。
本文转自 dog250 51CTO博客，原文链接:http://blog.51cto.com/dog250/1271919