2. cnp3-ebook
3. principles/security
4. English
5. Zen

33 ../../principles/security.rst:371
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — These two keys are generated together and they are linked by a complex mathematical relationship that is such that it is computationally difficult to compute :math:`K_{priv}` from :math:`K_{pub}`. 196/10000 · 196
34 ../../principles/security.rst:375
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — A public key cryptographic scheme is a combination of two functions : 69/10000 · 69
35 ../../principles/security.rst:377
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — an encryption function, :math:`E_{p}`, that takes a key and a message as parameters 83/10000 · 83
36 ../../principles/security.rst:378
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — a decryption function, :math:`D_{p}`, that takes a key and a message as parameters 82/10000 · 82
37 ../../principles/security.rst:380
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The public key is used to encrypt a message so that it can only be read by the intended recipient. For example, let us consider two users : Alice and Bob. Alice (resp. Bob) uses the keys :math:`A_{priv}` and :math:`A_{pub}` (resp. :math:`B_{priv}` and :math:`B_{pub}`). To send a secure message `M` to Alice, Bob computes :math:`CM=E_p(A_{pub},M)` and Alice can decrypt it by using :math:`D_p(A_{priv},CM)=D_p(A_{priv},E_p(A_{pub},M))=M`. 438/10000 · 438
38 ../../principles/security.rst:393
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Several public key encryption schemes have been proposed. Two of them have reached wide deployment : 100/10000 · 100
39 ../../principles/security.rst:396
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The Rivest Shamir Adleman (RSA) algorithm [#frsa]_ proposed in [RSA1978]_ that relies on modular exponentiation with large integers. 132/10000 · 132
40 ../../principles/security.rst:398
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The Elliptic Curve Cryptography techniques [#fecc]_ that rely on special properties of elliptic curves. 103/10000 · 103
41 ../../principles/security.rst:401
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Another interesting property of public key cryptography is its ability to compute `signatures` that can be used to authenticate a message. This capability comes from the utilization of two different keys that are linked together. If Alice wants to sign a message `M`, she can compute :math:`SM=E_p(A_{priv},M)`. Anyone who receives this signed messaged can extract its content as :math:`D_p(A_{pub},SM)=D_p(A_{pub},E_p(A_{priv},M))=M`. Everyone can use :math:`A_{pub}` to check that the message was signed by using Alice's private key (:math:`A_{priv}`). Since this key is only known by Alice, the ability to decrypt `SM` is a proof that the message was signed by Alice herself. 678/10000 · 678
42 ../../principles/security.rst:412
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — In practice, encrypting a message to sign it can be computationally costly, in particular if the message is a large file. A faster solution would be to summarize the document and only sign the summary of the document. A naive approach could be based on a checksum or CRC computed over the message. Alice would then compute :math:`C=Checksum(M)` and :math:`SC=E_p(A_{priv},C)`. She would then send both `M` and `SC` to the recipient of the message who can easily compute `C` from `SC` and verify the authenticity of the message. Unfortunately, this solution does not protect Alice and the message's recipient against a man-in-the-middle attack. If Mallory can intercept the message sent by Alice, he can easily modify Alice's message and tweak it so that it has the same checksum as the original one. The CRCs, although more complex to compute, suffer from the same problem. 873/10000 · 873
43 ../../principles/security.rst:433
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — To efficiently sign messages, Alice needs to be able to compute a summary of her message in a way that makes prohibits an attacker from generating a different message that has the same summary. `Cryptographic hash functions` were designed to solve this problem. The ideal hash function is a function that returns a different number for every possible input. In practice, it is impossible to find such a function. Cryptographic hash functions are an approximation of this perfect summarization function. They compute a summary of a given message in 128, 160, 256 bits or more. They also exhibit the `avalanche effect`. This effect indicates that a small change in the message causes a large change in the hash value. Finally hash functions are very difficult to invert. Knowing a hash value, it is computationally very difficult to find the corresponding input message. Several hash functions have been proposed by cryptographers. The most popular ones are : 957/10000 · 957
44 ../../principles/security.rst:447
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — MD5, originally proposed in :rfc:`1321`. It has been used in a wide range of applications. In 2010, attacks against MD5 were published and this hash function is now deprecated. 176/10000 · 176
45 ../../principles/security.rst:450
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — SHA-1 is a cryptographic hash function that was standardized by the NIST in 1995. It outputs 160 bits results. It is now used in a variety of network protocols. 160/10000 · 160
46 ../../principles/security.rst:453
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — SHA-2 is another family of cryptographic hash functions designed by the NIST. Different variants of SHA-2 can produce has values of 224, 256, 384 or 512 bits. 158/10000 · 158
47 ../../principles/security.rst:458
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Another important point about cryptographic algorithms is that often these algorithms require random numbers to operate correctly (e.g. to generate keys). Generating good random numbers is difficult and any implementation of cryptographic algorithms should also include a secure random number generator. :rfc:`4086` provides useful recommendations. 348/10000 · 348
48 ../../principles/security.rst:469
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Cryptographic protocols 23/10000 · 23
49 ../../principles/security.rst:471
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — We can now combine the cryptographic operations described in the previous section to build some protocols to securely exchange information. Let us first go back to the problem of authenticating Alice on Bob's computer. We have shown earlier that using a simple password for this purpose is insecure in the presence of attackers. 328/10000 · 328
50 ../../principles/security.rst:478
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — A naive approach would be to rely on hash functions. Since hash functions are non-invertible, Alice and Bob could decide to use them to exchange Alice's password in a secure manner. Then, Alice could be authenticated by using the following exchange. 249/10000 · 249
51 ../../principles/security.rst:509
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Since the hash function cannot be inverted, an eavesdropper cannot extract Alice's password by simply observing the data exchanged. However, Alice's real password is not the objective of an attacker. The main objective for Mallory is to be authenticated as Alice. If Mallory can capture `Hash(passwd)`, he can simply replay this data, without being able to invert the hash function. This is called a `replay attack`. 416/10000 · 416
52 ../../principles/security.rst:516
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — To counter this replay attack, we need to ensure that Alice never sends the same information twice to Bob. A possible mode of operation is shown below. 151/10000 · 151