tls 1.2加密

A couple of reader alerts:

读者警告：

In order to (somewhat) simplify the description process and tighten the volume of the article we are going to write, it is essential to make a significant remark and state the primary constraint right away — everything we are going to tell you today on the practical side of the problematics is viable only in terms of TLS 1.3. Meaning that while your ECDSA certificate would still work in TLS 1.2 if you wish it worked, providing backwards compatibility, the description of the actual handshake process, cipher suits and client-server benchmarks covers TLS 1.3 only. Of course, this does not relate to the mathematical description of algorithms behind modern encryption systems.

为了(某种程度上)简化描述过程并收紧我们将要写的文章的数量，有必要做一个重要的评论并立即指出主要的限制，我们今天将在实用上告诉您的一切问题的一面仅在TLS 1.3方面才可行。 这意味着，尽管您希望ECDSA证书能够工作，但仍可以在TLS 1.2中使用，但可以提供向后兼容性，但实际握手过程，密码套件和客户端-服务器基准的描述仅涵盖TLS 1.3。 当然，这与现代加密系统背后的算法的数学描述无关。

This article was written by neither a mathematician nor an engineer — although those helped to find a way around scary math and reviewed this article. Many thanks to Qrator Labs employees.

这篇文章既不是由数学家也不是由工程师撰写的，尽管他们帮助找到了解决可怕数学问题的方法，并回顾了这篇文章。 非常感谢Qrator Labs的员工。

(

Ë

((

E

)

lliptic

卵状的

C (C)

urve)

urve)

d (D)

iffie-

菲菲

H (H)

ellman (

埃尔曼(

Ë (E)

phemeral)

暂时的)

Diffie-Hellman在21世纪的遗产 (The Diffie–Hellman legacy in the 21 century)

Of course, this has started with neither Diffie nor Hellman. But to provide a correct timeline, we need to point out main dates and events.

当然，这不是从Diffie还是Hellman开始的。 但是，为了提供正确的时间表，我们需要指出主要日期和事件。

There were several major personas in the development of modern cryptography. Most notably, Alan Turing and Claud Shannon both laid an incredible amount of work over the field of theory of computation and information theory as well as general cryptanalysis, and both Diffie and Hellman, are officially credited for coming up with the idea of public-key (or so-called asymmetric) cryptography (although it is known that in the UK there were made serious advances in cryptography that stayed under secrecy for a very long time), making those two gentlemen pioneers.

现代密码学的发展有几个主要角色。 最值得注意的是，艾伦·图灵(Alan Turing)和克劳德·香农(Claud Shannon)都在计算和信息论以及通用密码分析领域进行了令人难以置信的大量工作，并且Diffie和Hellman都因提出了公共密钥的想法而被正式认可。 (或所谓的非对称)加密技术(尽管众所周知，在英国，加密技术已经取得了长足的发展，并且长期处于保密状态)，这使这两位先生成为了先驱。

In what exactly?

到底是什么？

Well, this may sound peculiar; however, before November 6, 1976, there was no public knowledge of public-key encryption systems. Whitfield Diffie and Martin Hellman (and, by the matter of fact, Ralph Merkle) — mathematicians, computer engineers and enthusiasts, as well as cryptologists were the first.

好吧，这听起来很奇怪。 但是，在1976年11月6日之前，还没有公众对公用密钥加密系统的了解。 惠特菲尔德·迪菲(Whitfield Diffie)和马丁·海尔曼(Martin Hellman)(实际上是拉尔夫·默克尔(Ralph Merkle))—数学家，计算机工程师和发烧友以及密码学家是第一批。

For those not aware — due to the role cryptanalysis overtook during the World War II and its enormous impact on keeping information in secret, the two countries that believed they had most advanced cryptography knowledge — the U.S. and U.K. included encryption into their Munitions Lists and leveraged a heavy export ban (simultaneously weakening encryption implementation for domestic private and commercial use). For this reason, the U.K. researchers working at the in Government Communications Headquarters and developing an analogous scheme weren’t recognized for this invention until 1997, when restrictions on cryptography algorithms and their description were rendered ineffective.

对于那些不知道的人-由于二战期间密码分析已超越角色，并且对保密信息具有巨大影响，因此两个国家认为他们拥有最先进的密码学知识-美国和英国将加密纳入了弹药清单并加以利用严格的出口禁令(同时削弱了针对家庭私人和商业用途的加密实施)。 由于这个原因，直到1997年英国政府研究人员在政府通信总部的工作并开发类似方案的英国研究人员才意识到这项发明，当时对密码算法的限制及其描述无效。

Back to our dual inventors — what has Diffie and Hellman revolutionized specifically?

回到我们的双重发明家-Diffie和Hellman特别革新了什么？

Let’s take a look at their original paper, perfectly illustrating the giant leap they’ve introduced (even theoretically with their research paper):

让我们看一下他们的原始论文，完美地说明了他们所引入的巨大飞跃(甚至在理论上与他们的研究论文一起)：

And the following one:

和以下之一：

These two pictures perfectly illustrate the huge change Whitfield Diffie and Martin Hellman introduced after cryptography and cryptanalysis centuries of evolution — the establishment of a shared secret key as a result of a cryptographic computation.

这两张照片完美地说明了在加密和密码分析百年演变之后，Whitfield Diffie和Martin Hellman所进行的巨大变化-加密计算的结果是建立了共享的秘密密钥。

Let’s take a look at another good picture with colors:

让我们看一下另一种颜色不错的图片：

It explains what is going on. Before Diffie and Hellman key agreement invention, there was only one symmetric key — it was used both to encrypt and decrypt the message. If you want to give someone such a “key”, it must be transferred over a “secure” channel. You can imagine all the restrictions of such a previous generation scheme right away — you need an already established secure channel, you , and, ideally, the length of the key should be the same as the length of the message.

它解释了发生了什么。 在Diffie和Hellman密钥协商发明之前，只有一个对称密钥-它既用于加密也用于解密消息。 如果要给某人这样的“密钥”，则必须通过“安全”通道进行转移。 您可以立即想象出这种上一代方案的所有限制-您需要一个已经建立的安全通道， ，并且理想情况下，密钥的长度应与消息的长度相同。

Claude Shannon in his wartime classified work “” proved that all theoretically unbreakable ciphers must have the same requirements as the one-time pad — famously known as the Vernam cipher, by the author of this symmetrical polyalphabetic stream cipher.

克劳德·香农(Claude Shannon)在其战时分类的著作“ ”中证明，所有理论上均不可破解的密码必须具有与一次性密码垫相同的要求，该密码垫由对称多字母流密码的作者而著称，即一次Vernam密码。

Again, we’re going to take a look at the original paper:

再次，我们将看一下原始论文：

Before we go any further, let’s ask ourselves — how two, even if brilliant, however, human beings came up with such a significant improvement in an applied field with such a history, especially at the time of war?

在进一步探讨之前，让我们问问自己：两个人，即使是杰出的人，在具有如此悠久历史的应用领域，特别是在战争时期，都取得了如此显着的进步？

Well, because of the:

好吧，因为：

• , formulated by Claude Shannon;

  ，由克劳德·香农(Claude Shannon)提出；

• influenced by, most notably, Alonzo Church, John von Neumann, and Alan Turing;

  最受Alonzo Church，John von Neumann和Alan Turing的影响；

• And, more importantly, based mostly on Turing’s work, which we could say all developed and matured at the same period of the 20th century. Diffie and Hellman both mentioned Claude Shannon as the most significant influencer of their work.

  而且，更重要的是， 主要基于图灵的工作，我们可以说所有这些都是在20世纪同一时期发展和成熟的。 Diffie和Hellman都提到克劳德·香农(Claude Shannon)是他们工作中最重要的影响者。

Lenstra’s “” illustrates the quantity of energy needed to “break” the symmetric cryptosystem with various key lengths. It turned out that breaking a 228-bit long, elliptic curve key would require the same amount of energy that is needed to boil all the water on Earth. It is, however, valid only under consideration of known algorithms and hardware, as, strictly speaking, no one knows if significantly more efficient algorithms or hardware exist. 228-bit EC key is comparable to the 2380-bit long RSA key, more on that later. Although in this estimation both RSA and EC keys are used in an asymmetric encryption scheme, such key lengths are somewhat equivalent to a 128-bit symmetric encryption key.

Lenstra的“ ”说明了“破坏”具有各种密钥长度的对称密码系统所需的能量。 事实证明，打破228位长的椭圆曲线键将需要与煮沸地球上所有水所需的能量相同的能量。 但是，仅在考虑已知算法和硬件的情况下它才有效，因为严格来说，没有人知道是否存在效率更高的算法或硬件。 228位EC密钥可与2380位长的RSA密钥相提并论。 尽管在此估计中，RSA和EC密钥都用于非对称加密方案中，但是这种密钥长度在某种程度上等效于128位对称加密密钥。

It is easy to imagine that something “hard to calculate” would require much energy and/or time needed for the computation. We tend to think that computers can “calculate everything”, but it turns out that it is not true. First, there exist undecidable examples, like the halting problem, though in the field of cryptography, we can avoid this pitfall. Second, if we consider the time needed for a particular algorithm to run, it may be arbitrary high. That is what we exploit in cryptography. A problem is considered “easy” to calculate if the time required to run the respective algorithm depends on the input size (measured in bits) like a polynomial: $inline$T(n) = O(n^k)$inline$ , for some positive constant $inline$k$inline$ . In the field, such problems form the .

不难想象，“难以计算”的内容将需要大量的能量和/或时间来进行计算。 我们倾向于认为计算机可以“计算一切”，但事实证明事实并非如此。 首先，存在一些不确定的例子，例如停止问题，尽管在密码学领域，我们可以避免这种陷阱。 其次，如果我们考虑运行特定算法所需的时间，则它可能是任意高的。 这就是我们在密码学中所利用的。 计算运行相应算法所需的时间是否像多项式一样取决于输入大小(以位为单位)，是一个“容易”计算的问题： $ inline $ T(n)= O(n ^ k)$ inline $ ，对于一些正常数 $ inline $ k $ inline $ 。 在领域，此类问题形成了 。

The is almost central, as it represents the problem for which a deterministic polynomial time algorithm exists. Another complexity class is the (the problems that are “hard” to calculate), representing a set of decision problems, i.e., problems requiring “yes” or “no” answer, that have a proof verifiable in polynomial time. You see the word “proof” here? That is where we get to the trapdoor functions, belonging to the NP complexity class.

几乎是核心问题，因为它表示存在确定性多项式时间算法的问题。 另一个复杂度类别是 (难于计算的问题)，代表一组决策问题，即需要“是”或“否”答案的问题，并且可以在多项式时间内验证。 您在这里看到“证明”一词吗？ 那就是我们进入陷门函数的地方，该函数属于NP复杂度类。

Credits:

积分：

单向功能； 活板门功能 (One-way functions; Trapdoor functions)

By definition, a one-way function is such a function that is easy to compute on every input but is hard to reverse, i.e. compute original input given output only. “Easy” and “hard” refer to the computational complexity theory definitions above. Interestingly, that one-way functions existence is not (mathematically) proved because their existence would prove that the P and NP complexity classes are not equal, while either P equal NP or not is nowadays an open problem. So, keep in mind that all modern cryptography relies on unproven hypotheses.

根据定义，单向函数就是这样一种函数，它易于在每个输入上进行计算，但难以逆转，即仅计算给定输出的原始输入。 “简单”和“困难”是指上面的计算复杂性理论定义。 有趣的是，单向函数的存在没有(从数学上)得到证明，因为它们的存在将证明P和NP复杂度类不相等，而如今P等于NP或不等于NP是一个开放的问题。 因此，请记住，所有现代加密技术都依赖未经证实的假设。

Now, in their original paper Diffie and Hellman introduce another generation of the one-way functions they called “trapdoor functions”. How do they differ?

现在，Diffie和Hellman在他们的原始论文中介绍了另一种称为“活板门功能”的单向功能。 它们有何不同？

As they explain in their landmark paper:

正如他们在具有里程碑意义的论文中解释的那样：

$inline$10^{100}$inline$ instructions). The enciphering key E can be disclosed [in a directory] without compromising the deciphering key D. This enables any user of the system to send a message to any other user enciphered in such a way that only the intended recipient is able to decipher it ...The problem of authentication is perhaps an even more serious barrier to the universal adoption of telecommunications for business transactions than the problems of key distribution…[it]…is at the heart of any system involving contracts and billing. $ inline $ 10 ^ {100} $ inline $ 说明)。 可以在不破坏解密密钥D的情况下[在目录中]公开加密密钥E。这使得系统的任何用户都可以将消息发送给任何已加密的其他用户，使得只有目标接收者才能解密该消息。 ..与密钥分发问题相比，认证问题可能是对电信普遍采用电信进行更为严重的障碍……[它]……是涉及合同和计费的任何系统的核心。

$inline$n$inline$ and $ inline $ n $ inline $ 和 $inline$g$inline$ with $ inline $ g $ inline $ 与 $inline$1< g< n$inline$ . The selection impacts the security of the system. “The modulus $ inline $ 1 <g <n $ inline $ 。 选择会影响系统的安全性。 “模数 $inline$n$inline$ should be a prime; more importantly $ inline $ n $ inline $ 应该是素数 更重要的是 $inline$(n-1)/2$inline$ should also be a prime <…> and $ inline $(n-1)/ 2 $ inline $ 还应该是素数<...>，并且 $inline$g$inline$ should be a primitive root modulo $ inline $ g $ inline $ 应该是原始的根模 $inline$n$inline$ <…> [and] $ inline $ n $ inline $ <…> [和] $inline$n$inline$ should be <…> at least 512 bits long.” The Diffie–Hellman protocol can be stated in elemental form in 5 steps. $ inline $ n $ inline $ 至少应为<…> 512位。” Diffie-Hellman协议可以用5个步骤以元素形式表示。

1. Alice chooses $inline$x$inline$ (a large random integer) and computes $inline$X=g^x \bmod n$inline$

   爱丽丝选择 $ inline $ x $ inline $ (一个大的随机整数)并计算 $ inline $ X = g ^ x \ bmod n $ inline $

2. Bob chooses $inline$y$inline$ (a large random integer) and computes $inline$Y=g^y \bmod n$inline$

   鲍勃选择 $ inline $ y $ inline $ (一个大的随机整数)并计算 $ inline $ Y = g ^ y \ bmod n $ inline $

3. Alice sends $inline$X$inline$ to Bob, while Bob sends $inline$Y$inline$ to Alice (they keep $inline$x$inline$ and $inline$y$inline$ secret from each other)

   爱丽丝发送 $ inline $ X $ inline $ 给Bob，而Bob发送 $ inline $ Y $ inline $ 给爱丽丝(他们保留 $ inline $ x $ inline $ 和 $ inline $ y $ inline $ 彼此的秘密)

4. Alice computes $inline$k = Y^x \bmod n$inline$

   爱丽丝计算 $ inline $ k = Y ^ x \ bmod n $ inline $

5. Bob computes $inline$k' = X^y \bmod n$inline$

   鲍勃计算 $ inline $ k'= X ^ y \ bmod n $ inline $

As a result Alice and Bob have the same value $inline$k=k'$inline$ that serves as a shared secret.

结果，爱丽丝和鲍勃的价值相同 $ inline $ k = k'$ inline $ 作为一个共享的秘密。

Trapdoor function is a one-way function that makes it possible to find its inverse if one has a piece of special information called the “trapdoor”. Sounds easy, though it was rather hard to find such functions — the first feasible method was found in the implementation of a public-key cryptography asymmetric encryption algorithm named RSA after its creators: Ron Rivest, Adi Shamir and Leonard Adleman.

活板门功能是一种单向功能，如果有一条称为“活板门”的特殊信息，则可以查找其倒数。 听起来很容易，尽管很难找到这样的功能-第一种可行的方法是在实现了以其创建者Ron Rivest，Adi Shamir和Leonard Adleman命名的RSA公用密钥密码非对称加密算法的过程中找到的。

RSA (RSA)

In RSA the hardness of inverting the function is based on the fact that factoring (finding prime multipliers of a number) takes much more time than multiplication, or should we say here that no polynomial-time method for factoring large integers on a classical computer has been found, however, it has not been proven that none exists.

在RSA中，函数求逆的难点是基于以下事实：因式分解(查找一个数的质数乘方)比乘积要花费更多的时间，或者在这里我们应该说，在经典计算机上没有用于分解大整数的多项式时间方法具有但是，尚未证明不存在。

In RSA, like in any other public-key encryption system, there are two keys: public and private. RSA takes the input message (represented as a bit string) and applies a mathematical operation (exponentiation modulo a big integer) to it to get a result looking indistinguishable from random. Decryption takes this result and applies a similar operation to get back the original message. In asymmetric cryptography, the encryption is made with the public key and decryption with the private one.

与其他任何公共密钥加密系统一样，在RSA中，有两个密钥：公共和私有。 RSA接受输入消息(表示为位字符串)，然后对其应用数学运算(对大整数取模的幂)，以得到与随机变量难以区分的结果。 解密将获得此结果，并应用类似的操作以取回原始消息。 在非对称密码学中，加密是用公钥进行的，而解密是用私钥进行的。

How? Because the operands belong to a finite cyclic group (a set of integers with multiplication in modular arithmetic). Сomputers don’t deal great with arbitrarily big numbers, but, luckily, our cyclic group of integers is to perform an operation called “wrap around” — a number larger than the maximum allowed is wrapped around to a number in the valid range we operate. This allows us to operate with keys of “no longer than” length. In elliptic curve cryptography cyclic (multiplicative) groups are used too but constructed a bit differently as we will see later.

怎么样？ 因为操作数属于有限循环组(在模块化算术中一组带有乘法的整数)。 Сomputers不能很好地处理任意大数字，但是，幸运的是，我们的整数循环组执行的操作称为“环绕”-大于允许的最大值的数字会被包裹为一个有效范围内的数字。 这使我们可以使用“不超过”长度的键进行操作。 在椭圆曲线密码学中，也使用循环(乘法)组，但其构造稍有不同，我们将在后面看到。

Basically what RSA does is taking two large prime numbers and multiplying them to get the so-called modulus. All the other numbers to be dealt with reside between zero and the modulus. The modulus is to be a part of the public key, and its bit length determines the key length. The second part of the public key is a number chosen between zero and the Euler’s totient (modern RSA implementation takes the Carmichael’s totient instead of Euler’s) of the modulus with some additional restrictions. Finally, the private key is to be calculated by solving some modular equation. To encrypt a number we simply raise it to the power equal to the public key, and to decrypt a number back, we raise it to the power equal to the private key. Thanks to the cyclic nature of the group, we get back the initial number.

基本上，RSA的工作是取两个大质数并将它们相乘以获得所谓的模数。 所有其他要处理的数字都位于零和模数之间。 模数将成为公共密钥的一部分，并且其位长决定密钥长度。 公用密钥的第二部分是在零和Euler的模数(现代RSA实现采用Carmichael的模数而不是Euler的模数)之间选择的数字，并带有一些其他限制。 最后，通过解决一些模块化方程来计算私钥。 要加密数字，我们只需将其提高到等于公钥的幂，然后解密一个数字，就将它提高到等于私钥的幂。 由于该组具有周期性，因此我们可以获取初始编号。

There are two significant problems with the RSA nowadays, one being a consequence of the other. As the length of a key (i.e., the number of its bits) grows, the complexity factor grows not so fast as one may expect. That is because there exists sub-exponential (but still ) factorisation . So, in order to keep an appropriate security level, the length of the RSA key needs to grow somewhat faster than the ECC key length. That is why most widespread RSA keys nowadays are either 2048 or 3072 bit long.

如今，RSA存在两个重大问题，一个是另一个问题的结果。 随着密钥的长度(即其位数)的增加，复杂度因子的增长并不像人们期望的那样快。 那是因为存在次指数(但仍然是 )分解 。 因此，为了保持适当的安全级别，RSA密钥的长度需要比ECC密钥的长度更快地增长。 这就是为什么当今最广泛使用的RSA密钥的长度为2048或3072位。

A bit later, we will see in numbers how the length of the key affects overall cryptosystem efficiency by comparing the RSA and ECDSA certificate signed with Let’s Encrypt authority.

稍后，我们将通过比较用Let's Encrypt授权签名的RSA和ECDSA证书，从数字上看到密钥的长度如何影响整体密码系统的效率。

(

Ë

((

E

)

lliptic

卵状的

C (C)

urve)

urve)

d (D)

igital

原始的

小号 (S)

ignature

点燃

一个 (A)

lgorithm

算法

The search for a better trapdoor function eventually led cryptographers to an actively evolving in the mid-80s branch of mathematics dedicated to elliptic curves.

寻找更好的活板门功能最终导致密码学家积极地发展到80年代中期的椭圆曲线专用数学分支。

It would be the ultimate task to describe elliptic curve cryptography in one article, so we shall not. Instead, let's take a look at an elliptic curve trapdoor function based on the discrete logarithm problem.

在一篇文章中描述椭圆曲线密码学将是最终的任务，因此我们不会。 相反，让我们看一下基于离散对数问题的椭圆曲线陷门函数。

There are many primers and more in-depth introductions into elliptic curve cryptography, and we would especially recommend if you are interested in math.

椭圆曲线密码学有许多入门和更深入的介绍，如果您对数学感兴趣，我们特别推荐 。

What we are interested in are rather “simple” parameters.

我们感兴趣的是相当“简单”的参数。

The elliptic curve is defined by an equation like this: $inline$y^2 = x^3 + ax + b$inline$

椭圆曲线由以下等式定义： $ inline $ y ^ 2 = x ^ 3 + ax + b $ inline $

Such a curve is needed to construct a cyclic subgroup over a finite field. Therefore, the following parameters are being used:

需要这样的曲线才能在有限域上构造循环子组。 因此，正在使用以下参数：

• The

  的

  主要 $ inline $ p $ inline $ (prime $inline$p$inline$ )

  that specifies the size of the finite field;

  指定有限域的大小；

• The

  的

  系数 $ inline $ a $ inline $ 和 $ inline $ b $ inline $ (coefficients $inline$a$inline$ and $inline$b$inline$ )

  of the elliptic curve equation;

  椭圆曲线方程

• The

  的

  基点 $ inline $ G $ inline $ (base point $inline$G$inline$ )

  that generates the mentioned subgroup;

  产生提到的子组；

• The

  的

  订购 $ inline $ n $ inline $ (order $inline$n$inline$ )

  of the subgroup;

  分组中的

• The

  的

  辅因子 $ inline $ h $ inline $ (cofactor $inline$h$inline$ )

  of the subgroup.

  子组中的

In conclusion, the

总之，

域参数 (domain parameters)

for our algorithms is the

因为我们的算法是

六胞胎 (sextuplet)

$inline$(p, a, b, G, n, h)$inline$ . $ inline $(p，a，b，G，n，h)$在线 。

Such elliptic curves work over the finite field $inline$\mathbb{F}_p$inline$ , where $inline$p$inline$ is a rather large prime number. So we have a set of integers modulo $inline$p$inline$ , where operations, such as addition, subtraction, multiplication, additive inverse, multiplicative inverse are possible. Addition and multiplication work similarly to the modular or so-called “clock” arithmetic we saw in the RSA “wrap arounds”.

这样的椭圆曲线在有限域上起作用 $ inline $ \ mathbb {F} _p $ inline $ ，在哪里 $ inline $ p $ inline $ 是一个相当大的素数。 所以我们有一组整数取模 $ inline $ p $ inline $ ，其中可以执行加法，减法，乘法，加法逆运算，乘法逆运算等运算。 加法和乘法的工作方式类似于我们在RSA“环绕式”中看到的模块化或所谓的“时钟”算法。

Since the curve is symmetrical about the x-axis, given any point $inline$P$inline$ , we can take $inline$−P$inline$ to be the point opposite it. We take $inline$−O$inline$ to be just $inline$O$inline$ .

由于曲线是关于x轴对称的，因此给定任何点 $ inline $ P $ inline $ ，我们可以 $ inline $ -P $ inline $ 正好相反。 我们采取 $ inline $ -O $ inline $ 只是 $ inline $ O $ inline $ 。

Addition for curve points is defined in a way that given points $inline$P$inline$ and $inline$Q$inline$ , we can draw line intersecting both those points and intersecting curve in a third point $inline$R$inline$ so that $inline$P+Q=-R$inline$ and $inline$P+Q+R=0$inline$ .

曲线点的加法定义为给定点 $ inline $ P $ inline $ 和 $ inline $ Q $ inline $ ，我们可以画出与这些点相交的线和与第三点相交的曲线 $ inline $ R $ inline $ 以便 $ inline $ P + Q = -R $ inline $ 和 $ inline $ P + Q + R = 0 $ inline $ 。

Let’s take a look at :

让我们来看看 ：

A line of constant slope that travels along the surface of the torus is shown above. This line passes through two randomly selected integer points on the curve.

上面显示了一条沿着圆环表面的恒定斜率线。 这条线穿过曲线上的两个随机选择的整数点。

To add two points on the graph, draw a line from the first selected point $inline$P$inline$ to the second selected point $inline$Q$inline$ , and extend the line until it intersects another point on the graph $inline$-R$inline$ , extending it across the plot boundaries if necessary.

要在图形上添加两个点，请从第一个选定点绘制一条线 $ inline $ P $ inline $ 到第二个选定点 $ inline $ Q $ inline $ ，并延长线直到与图上的另一个点相交 $ inline $ -R $ inline $ ，并在必要时将其扩展到绘图边界。

Once you intercept an integer point, reflect the point vertically across the middle of the graph (an orange dotted line) to find the new point $inline$R$inline$ on the graph. Therefore $inline$P+Q=R$inline$ .

截取一个整数点后，在图的中间垂直反射该点(橙色虚线)以找到新点 $ inline $ R $ inline $ 在图上。 因此 $ inline $ P + Q = R $ inline $ 。

$inline$n\cdot P = P + P + P + \dots + P$inline$ (here are $ inline $ n \ cdot P = P + P + P + \点+ P $ inline $ (这是 $inline$n$inline$ summands). $ inline $ n $ inline $ 要求)。

The trapdoor function here lies within the discrete logarithm (for elliptic curves) problem, not the factorisation we took a look at within the RSA section. The problem is: if we know $inline$P$inline$ and $inline$Q$inline$ , what is such $inline$k$inline$ , that $inline$Q=k\cdot P$inline$ ?

这里的活板门函数位于离散对数(对于椭圆曲线)问题中，而不是我们在RSA部分中看到的分解。 问题是：如果我们知道 $ inline $ P $ inline $ 和 $ inline $ Q $ inline $ ，这是什么 $ inline $ k $ inline $ ， $ inline $ Q = k \ cdot P $ inline $ ？

Both the factorisation problem (underlying the RSA) and the discrete logarithm for elliptic curves (which is the basis for ECDSA and ECDH) are supposed to be hard, i.e., there are no known algorithms for solving this problem in polynomial time for a given key length.

分解问题(位于RSA之下)和椭圆曲线的离散对数(这是ECDSA和ECDH的基础)都被认为很困难，即，对于给定的键，在多项式时间内没有解决此问题的已知算法长度。

While, typically, anyone would be shamed for mixing the key exchange (ECDH) with the signature (ECDSA) algorithm, we need to explain how they work together. A modern TLS certificate contains a public key, in our case, of the elliptic curve algorithm-generated key pair, usually signed by a higher-level authority. The client verifies the signature of the server and obtains the shared secret. The shared secret is used in a symmetric encryption algorithm, such as AES or ChaCha20. However, the principle remains the same: agree upon domain parameters (the sextuplet), get the key pair, where the private key is a randomly selected integer (the multiplicand from $inline$Q=k\cdot P$inline$ ), and the public key is a point at the curve. Signature algorithms use the base point $inline$G$inline$ , which is a generator for a subgroup of large prime order $inline$n$inline$ , such that $inline$n\cdot G=0$inline$ , where 0 is the identity element. The signature proves that the secure connection is being established with the authentic party — a server which has the TLS certificate (public key) signed by some certificate authority for the given server name.

通常，尽管任何人都会因将密钥交换(ECDH)与签名(ECDSA)算法混合而感到羞耻，但我们需要解释一下它们如何协同工作。 在我们的案例中，现代TLS证书包含一个由椭圆曲线算法生成的密钥对的公钥，通常由更高级别的权威机构签名。 客户端验证服务器的签名并获取共享密钥。 共享密钥用于对称加密算法，例如AES或ChaCha20。 但是，原理仍然是相同的：同意域参数(sextuplet)，获得密钥对，其中私钥是随机选择的整数(来自 $ inline $ Q = k \ cdot P $ inline $ )，而公钥是曲线上的一个点。 签名算法使用基点 $ inline $ G $ inline $ ，这是大质数阶子组的生成器 $ inline $ n $ inline $ ，这样 $ inline $ n \ cdot G = 0 $ inline $ ，其中0是标识元素。 签名证明与正当方建立了安全连接，该服务器具有由某些证书颁发机构为给定服务器名称签名的TLS证书(公用密钥)。

(EC)DH(E)+ ECDSA =当前握手形式 ((EC)DH(E)+ECDSA= Current handshake form)

In modern TLS (1.3) the client and the server generate their public-private key pair on the fly, while establishing the connection, this is called Ephemeral version of key exchange. Most popular browser TLS libraries support this. Mostly they use , introduced by Daniel J. Bernstein (djb), offering 128-bit security. Since 2014 openssh uses this curve for the key pair creation. In 2019 though, browsers still don’t support TLS sessions with servers having a certificate with EdDSA public key.

在现代TLS(1.3)中，客户端和服务器在建立连接的同时会动态生成其公私密钥对，这称为密钥交换的临时版本。 最流行的浏览器TLS库支持此功能。 大多数情况下，它们使用由Daniel J. Bernstein(djb)引入的 ，提供128位安全性。 从2014年开始，openssh使用此曲线创建密钥对。 但是在2019年，浏览器仍然不支持具有带有EdDSA公钥证书的服务器的TLS会话。

But let’s get back to how things work at the end of 2019 with TLS 1.3.

但是让我们回到TLS 1.3在2019年底的工作方式。

The key exchange mechanisms in TLS 1.3 are restricted to (EC)DH(E)-based (with the x25519 is the one supported in client-side TLS libraries of most popular browsers as well as server-side TLS libraries, such as OpenSSL, which we will inspect a bit later), and the cipher suite list contains only three entries: TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384 and TLS_CHACHA20_POLY1305_SHA256. For those of you aware of how the cipher suites were named in the TLS 1.2 version it is apparent right away that the key exchange mechanism is now “detached” from the cipher suite name, also the static RSA and static Diffie–Hellman exchange modes removed from the specification entirely. Even the session resumption based on PSK is made over ECDHE in TLS 1.3. It is also true for custom DH parameters, which aren’t allowed now, leaving only those generally agreed to be secure in the final protocol specification.

TLS 1.3中的密钥交换机制仅限于基于(EC)DH(E)的机制(x25519是大多数流行浏览器的客户端TLS库以及服务器端TLS库(如OpenSSL， (我们将在稍后进行检查)，并且密码套件列表仅包含三个条目：TLS_AES_128_GCM_SHA256，TLS_AES_256_GCM_SHA384和TLS_CHACHA20_POLY1305_SHA256。 对于那些了解TLS 1.2版本中密码套件的命名方式的人来说，显而易见的是，密钥交换机制现在已与密码套件名称“分离”，还删除了静态RSA和静态Diffie-Hellman交换模式。完全来自规范。 即使是基于PSK的会话恢复也是在TLS 1.3中通过ECDHE进行的。 对于自定义DH参数(现在不允许)，也是如此，仅保留最终协议规范中普遍认为安全的那些参数。

It is interesting that there is a rather significant difference in how asymmetric encryption algorithms work nowadays. With ECC (and ECDSA certificates in particular) we use smaller keys to get to “convenient” levels of security, compared with RSA. That enables usage of a stronger asymmetric encryption algorithm and key exchange mechanisms on smaller devices and sometimes even in things that are not generally considered a device (smartcard).

有趣的是，当今非对称加密算法的工作方式存在相当大的差异。 与RSA相比，有了ECC(尤其是ECDSA证书)，我们可以使用较小的密钥来达到“便捷”的安全级别。 这样就可以在较小的设备上，有时甚至在通常不被视为设备(智能卡)的设备上使用更强大的非对称加密算法和密钥交换机制。

First of all, it is necessary to mention what “hybrid cryptosystem” means in terms of TLS 1.3.

首先，有必要提及TLS 1.3中的“混合密码系统”的含义。

A hybrid cryptosystem is the one that uses asymmetric (public key) encryption to establish a shared secret, that is further used as a key in a symmetric stream or block cipher.

混合密码系统是一种使用非对称(公共密钥)加密来建立共享机密的系统，该系统还用作对称流或分组密码中的密钥。

Secondly, public-key infrastructure and certificates. It is interesting that in Martin Hellman mentioned an “unsung hero” Loren Kohnfelder, whose MIT bachelor’s thesis introduced a tree structure of what we now know as public key infrastructure. Nevertheless, let’s roll back to certificates.

其次，公钥基础结构和证书。 有趣的是，马丁·赫尔曼(Martin Hellman)在提到了“无名英雄”洛伦·科恩菲尔德(Loren Kohnfelder)，他的麻省理工学院学士学位论文介绍了我们现在称为公钥基础结构的树形结构。 不过，让我们回退到证书。

The fact that the server really has the private key is ensured by his signature, which can be verified with the server public key. And the certificate ensures that some public key belongs to a specific server. It means that you are establishing secure communication with the specific party and not with an imposter. Your bank, not a cybercriminal. In TLS 1.3 there is a significant improvement over previous negotiation format — the server signs all the information it has up to this moment: the client hello and the server hello, including negotiated cipher. Let’s take a look at the corresponding section of the :

服务器确实具有私钥这一事实是通过其签名来确保的，可以通过服务器公钥进行验证。 并且证书确保某些公钥属于特定服务器。 这意味着您正在与特定方而不是冒名顶替者建立安全的通信。 您的银行，而不是网络犯罪分子。 在TLS 1.3中，对以前的协商格式进行了重大改进-服务器对到目前为止拥有的所有信息进行签名：客户端问候和服务器问候，包括协商的密码。 让我们看一下的相应部分：

Client                                           ServerKey  ^ ClientHelloExch | + key_share*     | + signature_algorithms*     | + psk_key_exchange_modes*     v + pre_shared_key*       -------->                                                  ServerHello  ^ Key                                                 + key_share*  | Exch                                            + pre_shared_key*  v                                        {EncryptedExtensions}  ^  Server                                        {CertificateRequest*}  v  Params                                               {Certificate*}  ^                                         {CertificateVerify*}  | Auth                                                   {Finished}  v                               <--------  [Application Data*]     ^ {Certificate*}Auth | {CertificateVerify*}     v {Finished}              -------->       [Application Data]      <------->  [Application Data]

In TLS 1.3 client sends the key share (along with needed parameters), signature algorithms right away in the first message (Client Hello). The keys needed to exchange with the server are created in the background, without the user even noticing that fact. They are further exchanged with the server to create a common secret, from pre-master secret keys that were established when the server sent his message (Server Hello) answering the client.

在TLS 1.3中，客户端立即在第一条消息(客户端Hello)中发送密钥共享(以及所需的参数)和签名算法。 与服务器交换所需的密钥是在后台创建的，而用户甚至没有注意到这一事实。 它们与服务器进一步交换，以根据服务器发送其消息(服务器Hello)来答复客户端时建立的预主密钥来创建公共密钥。

On the “Server Hello” side you can see the Certificate* being transferred to the client, along with the CertificateVerify* part which verifies that the party possesses the private key for the corresponding public key entry, and creates the session (symmetric) key if everything goes as planned — meaning, that the side requesting the data (client) successfully verified the answering side (server), further creating a common secret.

在“服务器问候”侧，您可以看到证书*正在转移到客户端，以及证书验证*部分，该部分验证当事方是否拥有相应公共密钥条目的私钥，并在创建会话(对称)密钥时一切都按计划进行，这意味着请求数据的一方(客户端)成功验证了应答方(服务器)，从而进一步创建了一个公共机密。

There are two essential operations hidden in this transmissions — signature creation and signature verification. Those are made on both sides of communication since “signature” is essentially a proof that the party actually has the private key corresponding with the public key, that the data comes from signatory and the message was not altered in transit.

此传输中隐藏了两个基本操作-签名创建和签名验证。 之所以在通信的两面进行，是因为“签名”本质上是证明该方实际上具有与公钥相对应的私钥，数据来自签名者并且消息在传输过程中没有发生变化。

With RSA, as we will further see, the signing operation is the most expensive. Since we’re signing with a 2048 or 3072-bit long key, such operation loads the server significantly, much more than it loads the client verifying such a signature.

正如我们将进一步看到的，使用RSA，签名操作是最昂贵的。 由于我们使用的是2048位或3072位长的密钥进行签名，因此这样的操作将大大增加服务器的负载，远远超过了验证这种签名的客户端的负载。

With ECDSA, we have smaller keys (we are going to look at the ECDSA with NIST P-256 (or the secp256v1)) but more complex operations. As a result, it could be viewed as the “upside-down” RSA — the client is loaded most, by the signature verification computation, while the server easily handles the signature creation. The measurements verify that, see “A bit of benchmark” section.

使用ECDSA，我们可以使用较小的密钥(我们将使用NIST P-256(或secp256v1)查看ECDSA)，但操作更为复杂。 结果，它可以看作是“上下颠倒”的RSA-客户端通过签名验证计算负载最多，而服务器则可以轻松地处理签名创建。 测量结果证实了这一点，请参阅“一些基准”部分。

This effect handily scales the nowadays Internet — since modern clients are almost equally powerful as the servers (taking in mind just the CPU core frequency), so they could effectively take the expensive operation to bare. The server, in its turn, can use the freed capabilities to create more signatures and establish more sessions.

这种效果可以轻松扩展当今的Internet，因为现代客户端的功能几乎与服务器相同(仅考虑CPU核心频率)，因此它们可以有效地暴露昂贵的操作。 反过来，服务器可以使用释放的功能来创建更多签名并建立更多会话。

让我们加密证书签名 (Let’s Encrypt certificate signature)

So, in order to provide the reader with a bit of practical and handy instructions on how to create a TLS-enabled server with the ECDSA key pair signed by the Let’s Encrypt authority, we decided to illustrate a full process of creating a key pair needed to create a CSR (certificate signing request) for the Let’s Encrypt and, as a result, get the needed ECDSA certificate for our server.

因此，为了向读者提供一些实用且方便的说明，说明如何使用由Let's Encrypt机构签名的ECDSA密钥对创建启用TLS的服务器，我们决定说明创建所需密钥对的完整过程。为Let's Encrypt创建CSR(证书签名请求)，并因此为我们的服务器获取所需的ECDSA证书。

We have to generate a private key to proceed. We will use the OpenSSL library.

我们必须生成一个私钥才能继续。 我们将使用OpenSSL库。

The OpenSSL manual describes the generation of any EC keys through a special command, designated especially to the elliptic curve branch of the generation algorithm.

OpenSSL手册描述了通过特殊命令的任何EC密钥的生成，该命令特别指定给生成算法的椭圆曲线分支。

openssl ecparam -genkey -name -secp256v1 -out privatekey.pem

To check that the OpenSSL library did everything right, we can execute the ec command.

要检查OpenSSL库是否正确执行了所有操作，我们可以执行ec命令。

openssl ec -in privatekey.pem -noout -text

The output will show us the specified curve the key has been created with.

输出将向我们显示已创建关键点的指定曲线。

Next step is quite essential to the creation of the CSR — in order to skip the process of filling all the information details needed to obtain the certificate we need the config file. Luckily, Mozilla did the entire work for us, introducing the “”. There, you can choose from any available server options. The pure OpenSSL config, peculiarly not present at the Generator’s page would look something like this:

下一步对于创建CSR非常重要-为了跳过填写获取证书所需的所有信息详细信息的过程，我们需要配置文件。 幸运的是，Mozilla为我们做了整个工作，引入了“ ”。 在这里，您可以从任何可用的服务器选项中进行选择。 纯粹在生成器页面上不存在的OpenSSL配置看起来像这样：

[ req ]prompt = noencrypt_key = nodefault_md = sha256distinguished_name = dnamereq_extensions = reqext[ dname ]CN = example.comemailAddress = admin@example.com[ reqext ]subjectAltName = DNS:example.com, DNS:*.example.com

Note: it is not necessary to have the CNF — if you don’t, you would be asked to fill these details in the command line. 注意：没有必要安装CNF-如果没有，则将要求您在命令行中填写这些详细信息。

Now, follow the creation of a CSR itself. Here we have a handy OpenSSL command.

现在，遵循CSR本身的创建。 在这里，我们有一个方便的OpenSSL命令。

openssl req -new -config -pathtoconfigfile.cnf  -key privatekey.pem -out csr.pem

We can also verify the correctness of a newly created CSR.

我们还可以验证新创建的CSR的正确性。

openssl req -in csr.pem -noout -text -verify

Here we’ve come to a final phase — using an ACME client, certbot, to pass our certificate signing request to Let’s Encrypt.

在这里，我们进入了最后阶段-使用ACME客户端certbot将我们的证书签名请求传递给Let's Encrypt。

Certbot helps you to get the needed certificate and has a whole lot of options. Here said, if you are new to the public-key encryption, and the PKI infrastructure we have in 2019, you better use --dry-run before you try to obtain the certificate for any domain of yours.

Certbot可帮助您获得所需的证书，并有很多选择。 这里说的是，如果您不--dry-run公钥加密以及我们在2019年拥有的PKI基础结构，则在尝试获取您任何域的证书之前，最好使用--dry-run 。

certbot certonly --dry-run --dns-somednsprovider --domain “example.com” --domain “*.example.com” --csr csr.pem

In this case, the certbot client checks that the requested domains list (in the command line) matches the domains listed in the certificate signing request. In the --dns-somednsprovider command lies a bit of a lie, because there are plenty of ways you could prove Let’s Encrypt you are in possession of a particular part of the Internet traffic. However, if you are using some public cloud hosting provider, say DigitalOcean, Hetzner, Amazon, Azure, anything — there probably would be a more natural way to provide the needed information, because your provider already made some integration tool.

在这种情况下，certbot客户端会检查所请求的域列表(在命令行中)是否与证书签名请求中列出的域匹配。 在--dns-somednsprovider命令中有一个谎言，因为有很多方法可以证明“让我们加密”是您拥有Internet流量的特定部分。 但是，如果您使用某些公共云托管提供商，例如DigitalOcean，Hetzner，Amazon，Azure等，则可能会提供一种更自然的方式来提供所需的信息，因为您的提供商已经制作了一些集成工具。

After, if you are sure about the correctness of the parameters you are using in passing your CSR to the Let’s Encrypt via a certbot client — exclude the --dry-run parameter out of your command and proceed.

之后，如果您确定通过certbot客户端将CSR传递给Let's Encrypt时所用参数的正确性，请从命令中排除--dry-run参数，然后继续。

If successful, the client would produce several certificates as output: the signed certificate itself, the root and intermediate certs, and the combination of the latter as the last-named certificate chain, all in the .pem file format.

如果成功，则客户端将生成多个证书作为输出：签名证书本身，根证书和中间证书，以及后者的组合作为姓氏证书链，所有格式均为.pem文件格式。

OpenSSL has a command we could use to inspect the certificates:

OpenSSL具有可用于检查证书的命令：

openssl x509 -in chainfilepath.pem -noout -text

At this point, it becomes evident that Let’s Encrypt signed the certificate using SHA256 digest. In addition, ECDSA Root and Intermediates signing fall under the “Upcoming Features” section, which effectively means that right now you’d get only RSA intermediates. But that’s okay since you are still using the ECDSA public key.

在这一点上，很明显，让我们加密使用SHA256摘要对证书进行了签名。 此外，ECDSA根目录和中间件签名属于“即将推出的功能”部分，这实际上意味着，现在您仅会获得RSA中间件。 但这没关系，因为您仍在使用ECDSA公钥。

At the end of this section, we’d like to say something in connection to the length of keys. In information security, it is common to say the security level is 2^x, where x is the bit length (RSA is a bit of an exception here, as it grows somewhat slower than exponentially). To approximate how keys used for different algorithms correspond to each other, we would refer to the OpenSSL .

在本节的最后，我们想说一些与键的长度有关的内容。 在信息安全中，通常说安全级别是2 ^ x，其中x是位长(RSA在这里有点例外，因为它的增长比指数增长要慢)。 要估算用于不同算法的密钥如何彼此对应，请参考OpenSSL 。

已知问题和例外以及国家安全局 (Known issues and exceptions, and THE NSA)

Credits:

积分：

Probably, the central issue of using elliptic curve cryptography through the years was the need for a very carefully crafted random number generator, in order to create keys of required security level.

多年来，使用椭圆曲线密码学的中心问题可能是需要精心设计的随机数生成器，以便创建所需安全级别的密钥。

There was a massive scandal around the (dual elliptic curve deterministic random bit generator) algorithm, which took many years to resolve. Also, there is uncertainty around ECC patents, as it is known that many of them belonged to the Certicom company, which was acquired by Blackberry. There also are companies that are known to be certified the use of ECC from Blackberry. Of course, there is a simple distrust in some NIST standards, which could or could not be affected by the NSA or any other United States enforcement and surveillance institution.

(双椭圆曲线确定性随机位生成器)算法周围发生了大规模丑闻，解决了许多年。 此外，ECC专利存在不确定性，因为众所周知，其中许多专利属于Certicom公司，该公司被黑莓(Blackberry)收购。 也有一些公司被黑莓公司证明可以使用ECC。 当然，在某些NIST标准中存在简单的不信任感，这些标准可能会受到美国国家安全局(NSA)或其他任何美国执法和监视机构的影响，也可能不会受到影响。

The implementation side of an issue is an entirely different question. In 2010 PlayStation 3 console suffered a Sony private key recovery due to improper implementation of the ECDSA algorithm —they had a static random that made the trapdoor function solvable. OpenSSL also suffered in the following year, however, quickly fixing the vulnerability that allowed retrieval of a private key with the help of a timing attack, for more information look at the .

问题的实现方面是一个完全不同的问题。 在2010年，由于ECDSA算法的实施不正确，PlayStation 3控制台遭受了索尼私钥恢复，因为它们具有静态随机性，因此可以解决活板门功能。 但是，OpenSSL在第二年也遭受了损失，但很快修复了该漏洞，该漏洞允许在定时攻击的帮助下检索私钥，有关更多信息，请参阅 。

In 2013 at the RSA conference a group of researchers presented their “” paper about SecureRandom Java class vulnerabilities. Half a year later it came down to wallets, created using not enough cryptographically secure PRNG.

2013年，在RSA会议上，一组研究人员展示了他们的“ 关于SecureRandom Java类漏洞的文章。 半年后，它归结为使用加密安全性不足的PRNG创建的 钱包。

Due to serious serial vulnerabilities discovered, in the same August 2013, IETF released an , describing a deterministic generation of k used in the key creation. We could say that such a measure fixed the issue, but we won’t — anytime researchers could find issues in numerous implementations due to unnecessary deviation from the protocol specifications.

由于发现了严重的串行漏洞，2013年8月，IETF发布了 ，描述了密钥创建中使用的确定性k代。 我们可以说这样的措施可以解决问题，但是我们不会-由于不必要地偏离协议规范，研究人员可以在众多实现中发现问题。

About the NSA. If you haven’t heard about the Dual_EC_DRBG story — reserve some time and read corresponding articles, you won’t regret getting into details. Edward Snowden is a part of this story because the 2013 revelations proved the earlier suspicions. It resulted in many prominent cryptographers losing trust to NIST since that organization designed and described many of the curves and further algorithms, underlying ECDSA.

关于国家安全局。 如果您还没有听说过Dual_EC_DRBG的故事-请花些时间阅读相应的文章，您将不会后悔获得详细信息。 爱德华·斯诺登(Edward Snowden)是这个故事的一部分，因为2013年的披露证明了早先的怀疑。 由于该组织设计并描述了ECDSA的许多曲线和其他算法，这导致许多杰出的密码学家对NIST失去信任。

Daniel Bernstein’s 25519 curve and DH function is the answer to both these issues and, as we described earlier, a transition towards EdDSA is slow though evident. Even with the NIST curves, no evidence of their vulnerability has been found yet and, as we have already mentioned, random-related experience has been quite instructive.

丹尼尔·伯恩斯坦(Daniel Bernstein)的25519曲线和DH函数可同时解决这两个问题，而且正如我们前面所述，向EdDSA的过渡虽然缓慢，但显而易见。 即使使用NIST曲线，也尚未发现其脆弱性的证据，而且正如我们已经提到的，与随机相关的经验也很有启发性。

To conclude this part, we want to give John von Neumann’s quote: “Anyone who attempts to generate random numbers by deterministic means is, of course, living in a state of sin.”

作为本部分的总结，我们想引用约翰·冯·诺伊曼的话：“任何试图通过确定性手段生成随机数的人当然都处于犯罪状态。”

有点基准 (A bit of benchmark)

We used an NGINX 1.16.0 server with OpenSSL 1.1.1d to run these benchmarks with various certificates. As we mentioned earlier, currently Let’s Encrypt allows only prime256v1 and secp384r1 algorithms for certificate signing requests, and does not provide root and intermediary ECDSA certificates, probably working at this feature at the time of us writing this article.

我们使用带有OpenSSL 1.1.1d的NGINX 1.16.0服务器，以各种证书运行这些基准测试。 如前所述，当前的“加密”仅允许prime256v1和secp384r1算法用于证书签名请求，并且不提供根ECDSA证书和中间ECDSA证书，在撰写本文时，此功能可能起作用。

Now let’s take a look at the same processor’s OpenSSL -speed results with ECDSA and RSA.

现在，让我们看看使用ECDSA和RSA的同一处理器的OpenSSL -speed结果。

If you are interested in how your CPU performs cryptographic computations you may run a simple openssl speed command. The -rsa, -ecdsa and -eddsa parameters would give you benchmark results for the corresponding signature algorithms.

If you are interested in how your CPU performs cryptographic computations you may run a simple openssl speed command. The -rsa , -ecdsa and -eddsa parameters would give you benchmark results for the corresponding signature algorithms.

(Superpositioned) Future ((Superpositioned) Future)

Credits:

Credits:

It is ironical that while we were preparing this article, Google announced “”. Does this mean that we’re in danger right now and everything developed up to this moment does not provide any secrecy?

It is ironical that while we were preparing this article, Google announced “ ”. Does this mean that we're in danger right now and everything developed up to this moment does not provide any secrecy?

Well, no.

Well, no.

As Bruce Schneier wrote in his essay for IEEE Security and Privacy “” a huge blow with powerful enough quantum computer could be done to the public-key (asymmetric) cryptography. Symmetric cryptography would still be strong.

As Bruce Schneier wrote in his essay for IEEE Security and Privacy “ ” a huge blow with powerful enough quantum computer could be done to the public-key (asymmetric) cryptography. Symmetric cryptography would still be strong.

We want to quote Bruce Schneier with following:

We want to quote Bruce Schneier with following:

But if the unimaginable happens, that would leave us with cryptography based solely on information theory: one-time pads and their variants.

But if the unimaginable happens, that would leave us with cryptography based solely on information theory: one-time pads and their variants.

This is the area where, except looking for implementation flaws, most issues could be found. If there is a group of well-funded mathematicians, cryptanalysts/cryptographers and computer engineers working on proving or disproving some extraordinary complex mathematical problems (like the P?=NP) and achieving substantial results up to this moment, we could be in trouble. However, such advances in computer science, information and computability theories are unlikely to be hidden, since that fact would write the names of their creators on the pages of History and, specifically, History of the Internet textbooks, which is priceless for anyone that smart. So, such a scenario could be taken out as nearly impossible.

This is the area where, except looking for implementation flaws, most issues could be found. If there is a group of well-funded mathematicians, cryptanalysts/cryptographers and computer engineers working on proving or disproving some extraordinary complex mathematical problems (like the P?=NP) and achieving substantial results up to this moment, we could be in trouble. However, such advances in computer science, information and computability theories are unlikely to be hidden, since that fact would write the names of their creators on the pages of History and, specifically, History of the Internet textbooks, which is priceless for anyone that smart. So, such a scenario could be taken out as nearly impossible.

It is not clear, whether in the nearest 5 years there would be any successes with quantum computing, though there already are several cryptography primitives considered suitable for the post-quantum world: lattices, supersingular elliptic curve isogeny-based, hashes and codes. For now, security specialists are just experimenting with them. However, there is no doubt that in the case of a need, humanity would quickly employ such algorithms at a mass scale.

It is not clear, whether in the nearest 5 years there would be any successes with quantum computing, though there already are several cryptography primitives considered suitable for the post-quantum world: lattices, supersingular elliptic curve isogeny-based, hashes and codes. For now, security specialists are just experimenting with them. However, there is no doubt that in the case of a need, humanity would quickly employ such algorithms at a mass scale.

For now, elliptic-curve based cryptography seems to be a perfect fit for the future decade, providing security and performance.

For now, elliptic-curve based cryptography seems to be a perfect fit for the future decade, providing security and performance.

翻译自:

tls 1.2加密