《A Graduate Course in Applied Cryptography》Chapter 13 Digital Signatures(4)

╰+哭是因爲堅強的太久メ 2022-08-28 04:39 40阅读 0赞

原文教材 与 参考资料：

Boneh Dan , Shoup Victor . A Graduate Course in Applied Cryptography\[J\].

该书项目地址（可以免费获取）：http://toc.cryptobook.us/

博客为对该书的学习笔记，并非原创知识，仅帮助理解，整理思路。

### 13.7.3 Constructions: encrypt-then-sign and sign-then-encrypt ###

本节介绍两种自然的签密构造：

（1）先加密，后签名，此处简称EtS.

![watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAem1ybGludXg_size_20_color_FFFFFF_t_70_g_se_x_16][]

EtS 首先使用接收者的公钥以及发送者的ID，对明文进行加密，并对（密文，接收者ID）进行签名。解密时，首先使用发送者的公钥进行签名验证，如果验证通过，则进一步进行解密。

（2）先签名，后加密，此处简称为StE：

![watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAem1ybGludXg_size_20_color_FFFFFF_t_70_g_se_x_16 1][]

![watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAem1ybGludXg_size_20_color_FFFFFF_t_70_g_se_x_16 2][]StE 首先使用发送者的私钥对（消息，接收者ID）进行签名，然后使用接收者的公钥对发送者的ID，消息，签名。解密时，使用接收者私钥对密文进行解密，如果密文合法，则进一步，对签名进行验证。这里假设，签名是一个比特字符串其长度仅仅依赖于明文消息m的长度。（因为这里的签名有泄露明文可能，而EtS不会泄露明文）

**AE可认证加密 和 SE签密的对比**

首先给出一张，二者类比关系及其构造的图：

![watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAem1ybGludXg_size_20_color_FFFFFF_t_70_g_se_x_16 3][]

对于签密SE来说，其两种构造方式都是安全的，但是类似的MAC构造可认证加密却不是，对称加密-MAC可构造 可认证的加密，但是MAC-对称加密 不能提供可认证的安全属性（见该书第9章）。在公钥的签密构造中，这两种构造方法都是安全的。原因是StE是安全的，因为使用了一个CCA安全的公钥加密系统，而MAC-enc是使用的CPA安全加密系统，如果Mac-enc构造能够使用一个CCA的对称加密方案，那么该构造也可以提供可认证加密性质。因此EtS也是安全的。

EtS系统要求使用一个CCA安全加密方案，而不是CPA方案，这点与encryp-then-mac是不同的，因为该方案使用的对称加密算法是CPA的，具有延展性，且任何人都可生成一个新密文的验证码，这也是CCA加密方案要求的动机之一。

EtS构造要求一个强安全签名协议，在这个构造中，如果没有一个强安全的签名协议，将会导致一个对密文的CCA攻击，如果一个敌手获得一个挑战密文（c,s）, 敌手可以针对同样的密文伪造一个签名s1。那么，敌手就可以使用挑战密文（c,s1）进行一次解密询问，并赢得该次CCA游戏，在签密模型中，解密请求是允许这个解密请求的，如果想要规避这个问题，在后文中有两个具体的方法，但是都伴随一定的安全性牺牲。为了防止签名不安全导致CCA被攻破，要求签名方案必须是具有很强的安全性。相反，StE就不需要这样一个强安全数字签名。

下面给出两个构造的安全性定理：

![watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAem1ybGludXg_size_20_color_FFFFFF_t_70_g_se_x_16 4][]

定理13.8 指出一个EtS协议是安全的签密，如果使用一个CCA安全的公钥加密协议和一个强安全的数字签名协议。

对于任意的密文完整性敌手Aci, 该敌手运行攻击游戏13.5（签密完整性攻击游戏），那么存在一个伪造签名敌手Bsig可以调用Aci, 赢得攻击游戏13.2，该敌手的优势描述如下：

![watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAem1ybGludXg_size_20_color_FFFFFF_t_70_g_se_x_16 5][]

另外，对于任意的CCA敌手针对EtS方案运行攻击游戏13.6，那么存在一个CCA敌手Bcca, 和一个强签名敌手Bsig, 这两个敌手可以调用Acca赢得各自的挑战游戏，该敌手的优势描述如下：

![watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAem1ybGludXg_size_20_color_FFFFFF_t_70_g_se_x_16 6][]

** 定理13.8 证明：**

**密文完整性证明：**

**       **存在一个签名敌手Bsig与签密中的S挑战者进行交互，并且该Bsig敌手扮演攻击游戏13.5中敌手Aci的挑战者角色，Bsig 首先从自己的S签名挑战者处获得一个签名公钥Pk\*，此时注意，该签名私钥Bsig是不知道的，该签名私钥是由S签名挑战者保存的，给出下图来描述这个过程:

![watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAem1ybGludXg_size_20_color_FFFFFF_t_70_g_se_x_16 7][]

下一步，敌手Aci 选择两个身份IDS 和 IDR。Bsig 为这个两个身份生成签名公私钥对和加密公私钥对。其中IDS的签名密钥是由Bsig之前从其挑战者处获得的，Bsig期望攻击这个公钥对应的签名方案，过程如下图所示：

![watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAem1ybGludXg_size_20_color_FFFFFF_t_70_g_se_x_16 8][]

PKS 和 PKR的具体内容描述如下：

![watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAem1ybGludXg_size_20_color_FFFFFF_t_70_g_se_x_16 9][]

Bsig这里是知道所有的公钥-私钥的，除了PK\* 对应的私钥不知道。

然后Aci 向 Bsig 发出以下加密与解密请求，具体过程如下图所示（此处聚焦B和A的交互，暂时不看Signature-challenger的情况）

![watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAem1ybGludXg_size_20_color_FFFFFF_t_70_g_se_x_16 10][]

根据之前的签密模型，这里给出具体的细节，敌手可以询问S发送给R，S发送给其他人Y，R发送给其他人的加密信息，这里的两个S-Y并不是写错，X可以指代S或者R是两种情况。其中，S发送的签名都是由Bsig 对应的挑战者代为签名的，因为Bsig并不掌握S的签名私钥，这是其想要攻破的签名算法实例。

Bsig 回复Aci的解密询问通过直接调用EtS的解密算法，因为此时Bsig掌握所有的加密的私钥和所有的验证公钥，这里直接给出一个简单的描述图。

![watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAem1ybGludXg_size_20_color_FFFFFF_t_70_g_se_x_16 11][]

Bsig掌握所有的签名公钥和解密私钥，所以此处仅仅按照流程正确运行解密算法即可。

![watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAem1ybGludXg_size_20_color_FFFFFF_t_70_g_se_x_16 12][]

如图，在多次询问后，敌手最终输出一个伪造的密文，这个密文对应的明文是不能在S->R中进行过加密询问的（对应签名定义中，挑战签名是不能进行签名询问的）。那么，这个输出就是针对签名协议S的一个强伪造。这种情况失败的唯一可能为，敌手对C\`进行过一次签名询问，并最终获得了签名内容，特别是签名内容包括了IDR，这更是一个关键性证据。该签名询问被实现在了上述签密的S->R加密询问中。我们可以得到，挑战者不能生成该伪造签名，因为伪造的密文应当与所有S-R中由Bsig 做过加密询问的结果不同。所以，这里得到该伪造是一个合法的强存在性伪造。换句话说，（1）该消息的签名没有询问过，意味着伪造签名对应的消息是新的。（2）伪造的签名和之前任何询问过的明文签名都不同，不存在一个明文对应两个签名的情况。故而，本质上就是在要求此处的签名协议组件必须是强安全的。也就是，如果存在强安全的数字签名协议，EtS的方案密文完整性可以得到保证。

** 选择密文安全性：**

首先定义Game0 作为原始的签密CCA游戏，该游戏由EtS挑战者和一个CCA敌手组成，接着定义游戏Game 1. Game 1 和 Game 0 表现是完全相同的，除了增加了一个“特殊拒绝条件”在挑战者的S->R解密请求的逻辑中。也就是，如果给与一个S-》R的解密请求，该请求中签名是之前在S-R加密请求中出现过的，那么挑战者直接拒绝解密。模型如下图所示：

![watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAem1ybGludXg_size_20_color_FFFFFF_t_70_g_se_x_16 13][]

不难看出，这两个游戏运行起来后表现是相同的，除非挑战者在Game1中拒绝某个解密，而在Game 0中没有拒绝。（注意，这是会发生事件，因为在Game 0中没有对签名是否询问的特殊性检测）如果这里的解密询问时一个强存在性伪造。那么我们可以构造一个敌手Bsig\`其优势等于在Game1中被检测出来的概率。

现在构造一个敌手Bcca, 其优势等于Acca的优势在Game 1中的优势，和往常一样，Bcca与自己的CCA挑战者进行交互，并在Game1中扮演Acca的挑战者在游戏1中。

![watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAem1ybGludXg_size_20_color_FFFFFF_t_70_g_se_x_16 14][]

敌手Bcca 首先从自己的CCA挑战者处获取公钥，然后，选择两个身份IDS和IDR，

![watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAem1ybGludXg_size_20_color_FFFFFF_t_70_g_se_x_16 15][]

公钥内容为：

![watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAem1ybGludXg_size_20_color_FFFFFF_t_70_g_se_x_16 16][]

这里将R的公钥设置为挑战者生成是合理的，因为S在模型中是发送消息的一方，解密请求显然是询问R的，所以R就是CCA的关键询问对象。

加密请求：

![watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAem1ybGludXg_size_20_color_FFFFFF_t_70_g_se_x_16 17][]

除了不知道私钥的那部分密文需要由标准CCA挑战者生成，剩下的任何加密内容BCCA都可以自主完成。

![watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAem1ybGludXg_size_20_color_FFFFFF_t_70_g_se_x_16 18][]

CCA解密请求如上图描述，S-R阶段，需要进行一个签名是否出现过的验证，如果存在一个强伪造敌手，在此处也会被侦测到，从而拒绝解密。所以说，如果此处不加这个签名的验证，那么CCA将会被直接自然的攻破，在该攻击游戏中，(![c,\\sigma][c_sigma]) 和 （![c,\{\\sigma \}'][c_sigma 1]）视为不同的询问，如果存在一个强伪造性敌手，那么这两个请求都会被解密询问接受，那么CCA游戏将被攻破。如果对C加以甄别，那么就可以过滤掉这种情况，CCA模拟将是完备的，故得到：

![watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAem1ybGludXg_size_20_color_FFFFFF_t_70_g_se_x_16 19][] 类似的给出StE方案的安全性定理：

![watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAem1ybGludXg_size_20_color_FFFFFF_t_70_g_se_x_16 20][]

###  13.7.4  A construction based on Diffie-Hellman key exchange ###

这里给出一个不需要使用签名的签密方案。这里使用一个非交互式的DH密钥协商方案。

方案构造如下：

![watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAem1ybGludXg_size_20_color_FFFFFF_t_70_g_se_x_16 21][]

![watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAem1ybGludXg_size_20_color_FFFFFF_t_70_g_se_x_16 22][]

这里需要考虑一个问题，结合签密的模型，ICDH假设在这里将不在适用，这里给出一个符合安全模型的新攻击游戏：

![watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAem1ybGludXg_size_20_color_FFFFFF_t_70_g_se_x_16 23][]

进一步，给出安全定理：

![watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAem1ybGludXg_size_20_color_FFFFFF_t_70_g_se_x_16 24][]

这个定理的安全性证明从DH方案是一个安全的NIKE得到其安全性。

### 13.7.6 Property I: forward secrecy (security in case of a sender corruption) ###

前向安全，如果发送者被腐化，那么之前会话内容将受到威胁，Alice向Bob发送了一条密文，过了一段时间，Alice遭到盗用，其私钥被敌手盗走。那么我们期望，即使在这种情况下，敌手也无法使用盗用的私钥解密之前的加密消息。也就是说CCA安全依然存在，即使敌手获得了发送者的私钥。那么针对之前的签密的CCA攻击游戏，就需要进行一定的改动，仅仅修改set up阶段即可。这里给出修改后的签密攻击游戏如下：

![watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAem1ybGludXg_size_20_color_FFFFFF_t_70_g_se_x_16 25][]

**Forward secrecy for sign-then-encrypt：**

**        **对于StE构造，发送者的私钥仅仅用来签名，并不会帮助敌手进行解密，所以这个构造是支持前向安全的。从安全定理13.9可以看出，这个方案的SCCA安全性完全不依赖于数字签名，仅仅依赖于最终使用的公钥签名方案的安全性。

**Forward secrecy for encrypt-then-sign：**

在EtS方案中，最终的签密CCA安全性既依赖于数字签名的强安全，也依赖于方案中使用的公钥加密方案安全性。如果敌手具备强伪造性，那么根据签密CCA攻击游戏的规则，敌手可以直接进行CCA询问，攻破该CCA安全性（尽管并非敌手真的具有CCA攻击能力，利用了签密模型中的规则漏洞）。

那么，在敌手不掌握签名私钥的情况下，只要使用了强安全的数字签名方案，亦是安全的，但是，如果此时敌手掌握强安全的签名的私钥。那么，由于签名是概率的，敌手可以任意重新对密文c进行签名，任意的发动上述CCA攻击。

然而，这里并非没有办法抵抗这种情况，这里有两种方法抵抗这种攻击：

（1）使用确定性签名（unique signatures），即使掌握密钥也不行，因为确定性签名必然只有一个合法的签名内容。

（2）降低一定的安全性，在攻击游戏中不允许敌手提交这种解密询问，因为任何人都可以比较容易的检测到两种请求 虽然签名不同（都合法），但是加密的是同样的东西，这符合一种被称为gCCA安全的定义，并且在实际的应用中是相对可以接受的。

**Forward secrecy for DH：**

**     ** DH签密方案在这里是不满足前向安全的，因为敌手一旦掌握发送者的私钥，那么他就获得了整个方案的会话密钥，这是显然的，因为通信双方都是使用同样的对称密钥加密消息。然而，如果进行一定的改造，那么该方案将在一定程度上保障前向安全。

改造的DH方案，加密时给与一个随机数，使用一个临时密钥解决问题：

![watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAem1ybGludXg_size_20_color_FFFFFF_t_70_g_se_x_16 26][]

但是这里需要注意一个问题，随机数Bata在这里是假定不能丢失的，要及时擦除内存中的临时数据，这在AKE协议中是一个非常重要的安全属性。下面给出该方案的安全性定理：

![watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAem1ybGludXg_size_20_color_FFFFFF_t_70_g_se_x_16 27][]

###  13.7.7 Property II: non-repudiation (security in case of a recipient corruption) ###

假设Alice加密一个消息给Bob，该消息定义为c。此时仅仅依靠 Bob的私钥和c 是否能够有足够的证据表明，该消息就是Alice发送的？这个属性称之为“不可抵赖性”，即发送发不可抵赖发送的消息非自身发出。然而，这是本章方案的一个固有限制，假设Alice宣称自己的密钥被偷窃或者其主动泄露，从而否认消息是来自于自己。由于不可抵赖性在某些条件下是必须的，所以这里定义这个属性，并展示如何构造提供该属性的方案。不可抵赖性也是一个有用的属性，作为一个实用的抵抗Bob私钥被盗用的攻击，否则，敌手可以获得Bob的私钥，然后假装ALice给Bob发送消息，这称之为key compromise impersonation or KCI. 不可抵赖性去报了Bob的秘钥不能被用来模拟Alice，因此KCI攻击是不可能的。

不可抵赖性定义与攻击游戏：

![watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAem1ybGludXg_size_20_color_FFFFFF_t_70_g_se_x_16 28][]

** Non-repudiation for encrypt-then-sign.**

EtS方案提供了不可伪造性，因为接收者的私钥仅仅用来解密，不会帮助敌手进行签名，所以敌手腐化接收者也无法伪装发送者给别人发送消息。

**Non-repudiation for sign-then-encrypt.**

在StE方案密文完整性既依赖于签名也依赖于加密，实际上无法提供不可抵赖性。敌手获得了接收者的私钥，总是可以先解密获得明文然后再重新加密，则得到一个新的密文（概率性加密），这个密文依然是合法的，那么敌手就相当于可以假装Alice向Bob发送消息。那么，实际上其满足的是一种更弱的安全属性，即明文完整性，而不是密文完整性。可以通过修改完整性攻击游戏实现这个定义，即要求伪造的密文解密的明文不能是在S-R加密中请求过加密的明文。

**总结**

首先给出本章所以提方案的一个安全属性总结图示：

![watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAem1ybGludXg_size_20_color_FFFFFF_t_70_g_se_x_16 29][]

前向安全是一个非常有用的属性在真实的世界中，而不可抵赖属性往往是根据上下文，不一定总是需要。满足前向安全但是不满足不可可抵赖性，修改版DH方案是满足的。从这两个需求来看，EtS 方案相对较好一些，尽管只提供了一个比较弱一点的CCA安全。一些ETS的方案变体可以同时满足上述两种属性。

[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAem1ybGludXg_size_20_color_FFFFFF_t_70_g_se_x_16]: /images/20220828/1552f9e94b354de5aaa065a91ccd9c71.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAem1ybGludXg_size_20_color_FFFFFF_t_70_g_se_x_16 1]: /images/20220828/69257d15f6ab4b42a74d318097ff13be.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAem1ybGludXg_size_20_color_FFFFFF_t_70_g_se_x_16 2]: /images/20220828/0c6cc7b4f42c458faab6fcd597496bd7.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAem1ybGludXg_size_20_color_FFFFFF_t_70_g_se_x_16 3]: /images/20220828/bf71765aadda412195c835173cc8aa73.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAem1ybGludXg_size_20_color_FFFFFF_t_70_g_se_x_16 4]: /images/20220828/dc6a0db99b504343a70fbcd8171d07c2.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAem1ybGludXg_size_20_color_FFFFFF_t_70_g_se_x_16 5]: /images/20220828/ed0522e4244e46a287f0238e6eaff6cb.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAem1ybGludXg_size_20_color_FFFFFF_t_70_g_se_x_16 6]: /images/20220828/ab683a9c0f9c4542ab6f067b4ab6832e.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAem1ybGludXg_size_20_color_FFFFFF_t_70_g_se_x_16 7]: /images/20220828/f840230957b4423399b74a83de102a34.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAem1ybGludXg_size_20_color_FFFFFF_t_70_g_se_x_16 8]: /images/20220828/81195834b09f4fa18ee5dc2ebdf41098.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAem1ybGludXg_size_20_color_FFFFFF_t_70_g_se_x_16 9]: /images/20220828/c80cac40c4c14079bdb3462672e4f7dd.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAem1ybGludXg_size_20_color_FFFFFF_t_70_g_se_x_16 10]: /images/20220828/377ddf021e2b49c1b447206f0d34276b.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAem1ybGludXg_size_20_color_FFFFFF_t_70_g_se_x_16 11]: /images/20220828/a0165a14292f46e18b46f47107849fa9.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAem1ybGludXg_size_20_color_FFFFFF_t_70_g_se_x_16 12]: /images/20220828/8cc5f387e43040bebec778ec2da884f0.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAem1ybGludXg_size_20_color_FFFFFF_t_70_g_se_x_16 13]: /images/20220828/45f9e5b7fada4bfaa4dcfbe9d3d2a629.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAem1ybGludXg_size_20_color_FFFFFF_t_70_g_se_x_16 14]: /images/20220828/8e15e8ec979c47bcabcb2ef4b7ae38f9.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAem1ybGludXg_size_20_color_FFFFFF_t_70_g_se_x_16 15]: /images/20220828/b392d1d9b1f64ed8a8a05ae14281503f.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAem1ybGludXg_size_20_color_FFFFFF_t_70_g_se_x_16 16]: /images/20220828/a80ecbef27be41a08ada1d11c73a22ee.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAem1ybGludXg_size_20_color_FFFFFF_t_70_g_se_x_16 17]: /images/20220828/c575960de542462986dfc2c8f17e84ed.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAem1ybGludXg_size_20_color_FFFFFF_t_70_g_se_x_16 18]: /images/20220828/138e3e91daa24e869299119a51445065.png
[c_sigma]: https://latex.codecogs.com/gif.latex?c%2C%5Csigma
[c_sigma 1]: https://latex.codecogs.com/gif.latex?c%2C%7B%5Csigma%20%7D%27
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAem1ybGludXg_size_20_color_FFFFFF_t_70_g_se_x_16 19]: /images/20220828/0465b841b1b4459ebc704aa79e772790.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAem1ybGludXg_size_20_color_FFFFFF_t_70_g_se_x_16 20]: /images/20220828/018f4e8105eb419693aec3dd19dba286.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAem1ybGludXg_size_20_color_FFFFFF_t_70_g_se_x_16 21]: /images/20220828/598ae1a4daac4db6a05ee23085a85130.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAem1ybGludXg_size_20_color_FFFFFF_t_70_g_se_x_16 22]: /images/20220828/e6201b00782e442ca0f88d2ce6d5ed6c.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAem1ybGludXg_size_20_color_FFFFFF_t_70_g_se_x_16 23]: /images/20220828/a07e9a67972a4a2bbed53c53c56e936a.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAem1ybGludXg_size_20_color_FFFFFF_t_70_g_se_x_16 24]: /images/20220828/0710389250984b8a91fe385560df945c.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAem1ybGludXg_size_20_color_FFFFFF_t_70_g_se_x_16 25]: /images/20220828/831e872a4d41400fa52bd02258f54c6c.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAem1ybGludXg_size_20_color_FFFFFF_t_70_g_se_x_16 26]: /images/20220828/cbfaeb5a816e42a2bc898b8830f6f244.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAem1ybGludXg_size_20_color_FFFFFF_t_70_g_se_x_16 27]: /images/20220828/ce78b0f10163416b95af90646aa20642.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAem1ybGludXg_size_20_color_FFFFFF_t_70_g_se_x_16 28]: /images/20220828/c9edf600c74f45a392b5e6225c5d58b1.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAem1ybGludXg_size_20_color_FFFFFF_t_70_g_se_x_16 29]: /images/20220828/c138b4cdad2845a487482ccdcd17dc4f.png