whitespace fix

Author: drbruced12

crypto.rst

@@ -80,12 +80,12 @@ there are plenty of people who will try to break ciphers and who will
 let it be widely known when they have succeeded.
 
 Parameterizing a cipher with keys provides us with what is in effect a
-very large family of ciphers; by switching keys, we are 
+very large family of ciphers; by switching keys, we are
 switching to another cipher in the family. It is common to limit the amount
 of data that a *cryptanalyst* (code-breaker) can access before the key
 changes. This provides the attacker with less ability to break the cipher
 (for reasons discussed below) and limits the damage done if the code is
-broken. 
+broken.
 
 The basic requirement for an encryption algorithm is that it turns
 plaintext into ciphertext in such a way that only the intended
@@ -109,7 +109,7 @@ session. Common headers appear at the start of HTTP messages. This may
 enable a *known plaintext* attack, which has a much higher chance of
 success than a *ciphertext only* attack. Even better is a *chosen
 plaintext* attack, which may be enabled by feeding some information to
-the sender that you know the sender is likely to transmit. 
+the sender that you know the sender is likely to transmit.
 
 The best cryptographic algorithms, therefore, can prevent the attacker
 from deducing the key even when the individual knows both the
@@ -135,7 +135,7 @@ It turns out that it is not trivial to create cryptographic ciphers
 that can be broken only by brute force. For example, the original DES
 (data encryption standard) algorithm had a key of only 56 bits; when
 it became clear that 56 bits was too small, triple DES was introduced, using three
-rounds of DES each with its own key. It might seem that this 
+rounds of DES each with its own key. It might seem that this
 increased the key size to 168 bits (:math:`3 \times 56`) but because
 of the 3-round structure of triple DES, the attacker only has to
 search a key space of 112 bits. This depends on something called a
@@ -212,7 +212,7 @@ to be an issue is available at the "Sweet32" website.
 .. admonition:: Further Reading
 
    Sweet32. `Birthday attacks on 64-bit block ciphers in TLS and OpenVPN
-   <https://sweet32.info>`__. 
+   <https://sweet32.info>`__.
 
 
 
@@ -237,11 +237,11 @@ two participants use different keys.)
        secure communication since that is a common networking term to
        identify the two endpoints of a communication channel. In the
        security world, the parties are often called *principals*.
-       
+
 The U.S. National Institute of Standards and Technology (NIST) has
 issued standards for a series of secret-key ciphers. *Data Encryption
 Standard* (DES) was the first, and it survived for several decades
-before being deprecated. 
+before being deprecated.
 
 DES keys have 56 independent bits (although they have 64 bits
 in total; the last bit of every byte is a parity bit). As noted above,
@@ -284,7 +284,7 @@ Bruce Schneier puts it this way:
   hard. What is hard is creating an algorithm that no one else can
   break, even after years of analysis. And the only way to prove that
   is to subject the algorithm to years of analysis by the best
-  cryptographers around. 
+  cryptographers around.
 
 3.3 Public-Key Ciphers
 ------------------------
@@ -355,7 +355,7 @@ confidentiality to secret-key ciphers. The symmetric key sent over
 this confidential channel is called a *session key*. The reasons for this two-step
 approach include the higher efficiency of secret-key ciphers, and the need
 for reasonably frequent changing of encryption keys as described
-above. 
+above.
 
 .. _fig-pksign:
 .. figure:: figures/f08-04-9780123850591.png
@@ -470,7 +470,7 @@ Suppose that an adversary intercepts the message on its way to the
 receiver and tries to modify the transmitted message in
 some way. The message digest for this corrupted message would (with
 very high likelihood) differ from that of the original message. And
-the adversary lacks the necessary key to 
+the adversary lacks the necessary key to
 encrypt the digest of the corrupted message. An adversary could,
 however, obtain the plaintext original message and its encrypted digest
 by eavesdropping. The adversary could then (since the hash function is
@@ -511,7 +511,7 @@ cipher is used, the digest is encrypted using the sender’s private
 key, and the
 receiver—or anyone else—could decrypt the digest using the sender’s
 public key. If a secret-key cipher is used, the sender and receiver
-have to agree on the secret key ahead of time using some other means. 
+have to agree on the secret key ahead of time using some other means.
 
 A digest encrypted with a public-key algorithm using the private
 key of the sender
@@ -527,7 +527,7 @@ message herself. Any public-key cipher can be used for digital
 signatures. NIST has produced a series of *Digital Signature
 Standards* (DSS). The most recent standard at the time of writing
 allows for the use of three public-key ciphers, one based on RSA,
-another based on elliptic curves, and 
+another based on elliptic curves, and
 and a third called the *Edwards-Curve Digital Signature Algorithm*.
 
 .. should check the above for updates
@@ -580,7 +580,7 @@ associated data—while the rest
 of the message is encrypted, and the whole thing, headers included, is
 authenticated. We won't go into details here, but there is now a set of
 integrated algorithms that produce both ciphertext and authentication
-codes using a combination of ciphers and hash functions. 
+codes using a combination of ciphers and hash functions.
 
 
 Now that we have seen some of the building blocks for encryption and

intro.rst

@@ -14,7 +14,7 @@ they run code on the same system. At the same time, when one user
 *wants* to share data with another, the operating system needs to
 support that in a controlled way. Similarly, multi-user systems ensure
 that malicious or poorly written code from one user cannot interfere
-with the operation of another user's programs. 
+with the operation of another user's programs.
 
 Computer networks are, like multi-user computers, shared
 resources, and similar requirements apply. One network user should not
@@ -94,7 +94,7 @@ that meet certain security objectives, such as protection against
 eavesdropping and modification of data in transit. The systems
 approach requires us to look at the entire system: the network
 components and the end systems connected by the network, both hardware
-and software. 
+and software.
 
 1.1 A Short History of Internet Security
 ----------------------------------------
@@ -180,7 +180,7 @@ similarly lacked any security provisions in its original design. Not
 only do we need to be concerned about modification of routing messages
 in transit, but it has historically been all too easy to simply send
 incorrect routing updates in BGP. For example, a router might advertise a good route to
-some prefix from an autonomous system that has no such route. 
+some prefix from an autonomous system that has no such route.
 Securing BGP has likewise proven to be a multi-decade, incremental task.
 
 This is by no means a complete history of Internet security but it
@@ -195,7 +195,7 @@ pioneers are interviewed.
 
   C. Timberg. `A Net of Insecurity
   <https://www.washingtonpost.com/sf/business/2015/05/30/net-of-insecurity-part-1/>`__.
-  The Washington Post, May 30, 2015. 
+  The Washington Post, May 30, 2015.
 
 1.2 Trust and Threats
 ----------------------
@@ -244,14 +244,14 @@ security strategy:
 * Step 2: What are the risks to these assets?
 * Step 3: How well does the security solution mitigate those risks?
 * Step 4: What other risks does the security solution cause?
-* Step 5: What costs and trade-offs does the security solution impose?  
+* Step 5: What costs and trade-offs does the security solution impose?
 
 Schneier's book is targeted at a general audience, addressing
 security in a broad context (e.g., airports), not just computing systems and
 networks. Nevertheless it provides some useful guidelines that are
 applicable to system security.
 
-  
+
 .. admonition:: Further Reading
 
   B. Schneier. Beyond Fear: Thinking Sensibly About Security in an
@@ -343,7 +343,7 @@ In addition to these issues, the Internet has notably been used as a
 means for deploying malicious code, generally called *malware*, that
 exploits vulnerabilities in end systems. *Worms*, of which the Morris
 worm is a famous example, are pieces of
-self-replicating code that spread over networks. 
+self-replicating code that spread over networks.
 *Viruses* differ slightly from worms, in that they are spread by the transmission of infected files.
 Once infected, machines can then be arranged into *botnets*, in which
 a set of compromised machines are harnessed together

key-distro.rst

@@ -323,20 +323,20 @@ much larger number), then we might choose 2 to be the generator *g*
 since:
 
 .. math::
-    
-   1 = 2^0 \bmod p 
+
+   1 = 2^0 \bmod p
 
 .. math::
-    
-   2 = 2^1 \bmod p 
+
+   2 = 2^1 \bmod p
 
 .. math::
-    
-   3 = 2^3 \bmod p 
+
+   3 = 2^3 \bmod p
 
 .. math::
-    
-   4 = 2^2 \bmod p 
+
+   4 = 2^2 \bmod p
 
 Suppose Alice and Bob want to agree on a shared secret key. Alice and
 Bob, and everyone else, already know the values of *p* and *g*. Alice
@@ -347,65 +347,65 @@ corresponding public values—the values they will send to each other
 unencrypted—as follows. Alice’s public value is
 
 .. math::
-    
-   g^a \bmod p 
+
+   g^a \bmod p
 
 and Bob’s public value is
 
 .. math::
-    
-   g^b \bmod p 
+
+   g^b \bmod p
 
 They then exchange their public values. Finally, Alice computes
 
 .. math::
-    
-   g^{ab} \bmod p = (g^b \bmod p)^a \bmod p 
+
+   g^{ab} \bmod p = (g^b \bmod p)^a \bmod p
 
 and Bob computes
 
 .. math::
-    
-   g^{ba} \bmod p = (g^a \bmod p)^b \bmod p. 
 
-Alice and Bob now have :math:`g^{ab} \bmod p` (which is equal to 
+   g^{ba} \bmod p = (g^a \bmod p)^b \bmod p.
+
+Alice and Bob now have :math:`g^{ab} \bmod p` (which is equal to
 :math:`g^{ba} \bmod p)` as their shared secret key.
 
-Any eavesdropper would know *p, g*, and the two public values 
-:math:`g^a \bmod p` and :math:`g^b \bmod p`. 
+Any eavesdropper would know *p, g*, and the two public values
+:math:`g^a \bmod p` and :math:`g^b \bmod p`.
 If only the eavesdropper could determine *a* or *b*, she could easily
 compute the resulting key. Determining *a* or *b* from that information
 is, however, computationally infeasible for suitably large *p,a,* and
 *b*; it is known as the *discrete logarithm problem*.
 
 For example, using *p = 5* and *g = 2* from above, suppose Alice picks
-the random number *a = 3* and Bob picks the random number *b = 4*. 
+the random number *a = 3* and Bob picks the random number *b = 4*.
 Then Alice sends Bob the public value
 
 .. math::
-    
-   2^3 \bmod 5 = 3 
+
+   2^3 \bmod 5 = 3
 
 and Bob sends Alice the public value
 
 .. math::
-    
-   2^4 \bmod 5 = 1 
+
+   2^4 \bmod 5 = 1
 
 Alice is then able to compute
 
 .. math::
-    
+
    g^{ab} \bmod p = (2^b \bmod 5)^3 \bmod 5 = (1)^3 \bmod 5 = 1
 
-by substituting Bob’s public value for :math:`(2^b \bmod 5)`. Similarly, 
+by substituting Bob’s public value for :math:`(2^b \bmod 5)`. Similarly,
 Bob is able to compute
 
 .. math::
-    
-   g^{ba} \bmod p = (g^a \bmod 5)^4 \bmod 5 = (3)^4 \bmod 5 = 1. 
 
-by substituting Alice’s public value for :math:`(2^a \bmod 5)`. 
+   g^{ba} \bmod p = (g^a \bmod 5)^4 \bmod 5 = (3)^4 \bmod 5 = 1.
+
+by substituting Alice’s public value for :math:`(2^a \bmod 5)`.
 Both Alice and Bob now agree that the secret key is :math:`1`.
 
 There is the problem of Diffie-Hellman’s lack of authentication. One
@@ -431,7 +431,7 @@ supports authentication of one or both participants. It relies on
 certificates that are similar to public key certificates but instead
 certify the Diffie-Hellman public parameters of an entity. For example,
 such a certificate would state that Alice’s Diffie-Hellman parameters
-are *p, g*, and :math:`g^a \bmod p` 
+are *p, g*, and :math:`g^a \bmod p`
 (note that the value of *a* would still be known only to Alice). Such
 a certificate would assure Bob that the other participant in
 Diffie-Hellman is Alice—or else the other participant won’t be able to

principles.rst

@@ -32,7 +32,7 @@ what quantity. This presents some distinct challenges from data
 confidentiality; there is no need for network devices to see our data,
 but they generally must look at packet headers, which contain
 destination information, to determine where to
-send traffic.  
+send traffic.
 
 An equally important requirement in many cases is
 *authentication*. This is the ability to verify that an item of data
@@ -204,7 +204,7 @@ The idea behind this principle is the default settings of a system are
 the ones most likely to be used, so by default, undesired access
 should be disabled. It then takes an explicit action to enable
 access. This is a principle that dates back at least to 1965 according to
-the Saltzer and Schroeder paper. 
+the Saltzer and Schroeder paper.
 
 It turns out that the design of the Internet really doesn't follow
 this approach. The datagram delivery model of the Internet, by
@@ -298,7 +298,7 @@ Saltzer whose book (with Kaashoek) we referred to in Chapter 1. The
 fact that many of the principles from the 1975 paper reappear in the
 2009 is probably a sign that Saltzer had some confidence that these
 principles have stood the test of time. We recommend reading the
-entire paper. 
+entire paper.
 
 .. admonition:: Further Reading
 

systems.rst

@@ -5,7 +5,7 @@ Chapter 6:   Example Systems
    for ways to highlight the underlying open source software (and the
    general role open source plays in helping secure the Internet --
    lots of eyes on the code).
-   
+
 We have now seen many of the components required to provide one or two
 aspects of security. These components include cryptographic algorithms,
 key predistribution mechanisms, and authentication protocols. In this