merge other dark images branch

Gemfile.lock

@@ -219,11 +219,10 @@ GEM
       jekyll (>= 3.5, < 5.0)
       jekyll-feed (~> 0.9)
       jekyll-seo-tag (~> 2.1)
-    minitest (5.21.2)
-    mutex_m (0.2.0)
-    net-http (0.4.1)
-      uri
-    nokogiri (1.16.0-x86_64-linux)
+    minitest (5.16.3)
+    nokogiri (1.13.8-arm64-darwin)
+      racc (~> 1.4)
+    nokogiri (1.13.8-x86_64-darwin)
       racc (~> 1.4)
     octokit (4.25.1)
       faraday (>= 1, < 3)
@@ -265,6 +264,8 @@ GEM
 
 PLATFORMS
   x86_64-linux
+  arm64-darwin-23
+  x86_64-darwin-21
 
 DEPENDENCIES
   github-pages

_includes/head_custom.html

@@ -6,6 +6,7 @@
 <script>
   let toggleDark = () => {
     let setDark = jtd.getTheme() !== 'dark';
+    document.documentElement.setAttribute('data-theme', setDark ? 'dark' : 'default');
     jtd.setTheme(setDark ? 'dark' : 'default');
     localStorage.setItem('darkMode', String(setDark));
   };
@@ -20,7 +21,10 @@
 
     /* Read local storage state. */
     if (localStorage.getItem('darkMode') === 'true') {
+      document.documentElement.setAttribute('data-theme', 'dark');
       toggleDark();
+    } else {
+      document.documentElement.setAttribute('data-theme', 'default');
     }
   });
 </script>

_sass/custom/custom.scss

@@ -7,3 +7,19 @@
   margin-top: 0;
   margin-bottom: 0;
 }
+
+.light-mode {
+  display: none;
+}
+
+.dark-mode {
+  display: none;
+}
+
+:root[data-theme="default"] .light-mode {
+  display: block;
+}
+
+:root[data-theme="dark"] .dark-mode {
+  display: block;
+}

crypto/key-exchange.md

@@ -64,7 +64,7 @@ As far as we know, there is no efficient algorithm to deduce $$S=g^{ab} \bmod p$
 
 {% comment %} do we still need this paragraph? -peyrin sp21 {% endcomment %}
 
-Here is how this applies to secure communication among computers. In a computer network, each participant could pick a secret value $$x$$, compute $$X=g^x \bmodp$$, and publish $$X$$ for all time. Then any pair of participants who want to hold a conversation could look up each other's public value and use the Diffie-Hellman scheme to agree on a secret key known only to those two parties. This means that the work of picking $$p$$, $$g$$, $$x$$, and $$X$$ can be done in advance, and each time a new pair of parties want to communicate, they each perform only one modular exponentiation. Thus, this can be an efficient way to set up shared keys.
+Here is how this applies to secure communication among computers. In a computer network, each participant could pick a secret value $$x$$, compute $$X=g^x \bmod p$$, and publish $$X$$ for all time. Then any pair of participants who want to hold a conversation could look up each other's public value and use the Diffie-Hellman scheme to agree on a secret key known only to those two parties. This means that the work of picking $$p$$, $$g$$, $$x$$, and $$X$$ can be done in advance, and each time a new pair of parties want to communicate, they each perform only one modular exponentiation. Thus, this can be an efficient way to set up shared keys.
 
 Here is a summary of Diffie-Hellman key exchange:
 

crypto/symmetric.md

@@ -20,7 +20,7 @@ A more formal, rigorous definition of confidentiality is: the ciphertext $$C$$ s
 
 We can further formalize this definition by designing an experiment to test whether the attacker has learned any additional information. Consider the following experiment: Alice has encrypted and sent one of two messages, either $$M_0$$ or $$M_1$$, and the attacker, Eve, has no idea which was sent. Eve tries to guess which was sent by looking at the ciphertext. If the encryption scheme is confidential, then Eve's probability of guessing which message was sent should be $$1/2$$, which is the same probability as if she had not intercepted the ciphertext at all, and was instead guessing at random.
 
-We can adapt this experiment to different threat models by allowing Eve to perform further actions as an attacker. For example, Eve might be allowed to trick Alice into encrypting some messages of Eve's choosing. Eve might also be allowed to trick Alice into decrypting some ciphertexts of Eve's choosing. In this class, we will be focusing on the chosen-plaintext attack model, which means Eve can trick Alice into encrypting some messages, but she cannot trick Alice into decrypting some messages.
+We can adapt this experiment to different threat models by allowing Eve to perform further actions as an attacker. For example, Eve might be allowed to trick Alice into encrypting some messages of Eve's choosing. Eve might also be allowed to trick Bob into decrypting some ciphertexts of Eve's choosing. In this class, we will be focusing on the chosen-plaintext attack model, which means Eve can trick Alice into encrypting some messages, but she cannot trick Alice into decrypting some messages.
 
 In summary, our definition of confidentiality says that even if Eve can trick Alice into encrypting some messages, she still cannot distinguish whether Alice sent $$M_0$$ or $$M_1$$ in the experiment. This definition is known as indistinguishability under chosen plaintext attack, or IND-CPA. We can use an experiment or game, played between the adversary Eve and the challenger Alice, to formally prove that a given encryption scheme is IND-CPA secure or show that it is not IND-CPA secure.
 
@@ -249,35 +249,27 @@ There are several standard ways (or modes of operation) of building an encryptio
 
 - ECB mode decryption: $$M_i = D_K(C_i)$$
 
-![Diagram of encryption for the ECB mode of
-operation in light mode](/assets/images/crypto/symmetric/ECB_encryption.png#gh-light-mode-only)
+<img src="/assets/images/crypto/symmetric/ECB_encryption.png" alt="Diagram of encryption for the ECB mode of operation in light mode" class="light-mode">
 
-![Diagram of encryption for the ECB mode of
-operation in dark mode](/assets/images/crypto/symmetric/ECB_encryption_invert.png#gh-dark-mode-only)
+<img src="/assets/images/crypto/symmetric/ECB_encryption_invert.png" alt="Diagram of encryption for the ECB mode of operation in dark mode" class="dark-mode">
 
-![Diagram of decryption for the ECB mode of
-operation in light mode](/assets/images/crypto/symmetric/ECB_decryption.png#gh-light-mode-only)
+<img src="/assets/images/crypto/symmetric/ECB_decryption.png" alt="Diagram of decryption for the ECB mode of operation in light mode" class="light-mode">
 
-![Diagram of decryption for the ECB mode of
-operation in dark mode](/assets/images/crypto/symmetric/ECB_decryption_invert.png#gh-dark-mode-only)
+<img src="/assets/images/crypto/symmetric/ECB_decryption_invert.png" alt="Diagram of decryption for the ECB mode of operation in dark mode" class="dark-mode">
 
 **CBC Mode** (Cipher Block Chaining): This is a popular mode for commercial applications. For each message the sender picks a random $$n$$-bit string, called the _initial vector_ or IV. Define $$C_0 = IV$$. The $$i^\textrm{th}$$ ciphertext block is given by $$C_i = E_K(C_{i-1} \oplus M_i)$$. The ciphertext is the concatenation of the initial vector and these individual blocks: $$C = IV \cdot C_1 \cdot C_2 \cdots C_l$$. CBC mode has been proven to provide strong security guarantees on the privacy of the plaintext message (assuming the underlying block cipher is secure).
 
 - CBC mode encryption: $$\begin{cases} C_0 = IV \\ C_i = E_K(P_i \oplus C_{i-1}) \end{cases}$$
 
 - CBC mode decryption: $$P_i = D_K(C_i) \oplus C_{i-1}$$
 
-![Diagram of encryption for the CBC mode of
-operation in light mode](/assets/images/crypto/symmetric/CBC_encryption.png#gh-light-mode-only)
+<img src="/assets/images/crypto/symmetric/CBC_encryption.png" alt="Diagram of encryption for the CBC mode of operation in light mode" class="light-mode">
 
-![Diagram of encryption for the CBC mode of
-operation in dark mode](/assets/images/crypto/symmetric/CBC_encryption_invert.png#gh-dark-mode-only)
+<img src="/assets/images/crypto/symmetric/CBC_encryption_invert.png" alt="Diagram of encryption for the CBC mode of operation in dark mode" class="dark-mode">
 
-![Diagram of decryption for the CBC mode of
-operation in light mode](/assets/images/crypto/symmetric/CBC_decryption.png#gh-light-mode-only)
+<img src="/assets/images/crypto/symmetric/CBC_decryption.png" alt="Diagram of decryption for the CBC mode of operation in light mode" class="light-mode">
 
-![Diagram of decryption for the CBC mode of
-operation in dark mode](/assets/images/crypto/symmetric/CBC_decryption_invert.png#gh-dark-mode-only)
+<img src="/assets/images/crypto/symmetric/CBC_decryption_invert.png" alt="Diagram of decryption for the CBC mode of operation in dark mode" class="dark-mode">
 
 **CFB Mode** (Ciphertext Feedback Mode): This is another popular mode with properties very similar to CBC mode. Again, $$C_0$$ is the IV. The $$i^\textrm{th}$$ ciphertext block is given by $$C_i = E_K(C_{i-1}) \oplus M_i$$.
 
@@ -292,41 +284,33 @@ operation in dark mode](/assets/images/crypto/symmetric/CBC_decryption_invert.pn
 
 - CFB mode decryption: $$P_i = E_K(C_{i-1}) \oplus C_i$$
 
-![Diagram of encryption for the CFB mode of
-operation in light mode](/assets/images/crypto/symmetric/CFB_encryption.png#gh-light-mode-only)
+<img src="/assets/images/crypto/symmetric/CFB_encryption.png" alt="Diagram of encryption for the CFB mode of operation in light mode" class="light-mode">
 
-![Diagram of encryption for the CFB mode of
-operation in dark mode](/assets/images/crypto/symmetric/CFB_encryption_invert.png#gh-dark-mode-only)
+<img src="/assets/images/crypto/symmetric/CFB_encryption_invert.png" alt="Diagram of encryption for the CFB mode of operation in dark mode" class="dark-mode">
 
-![Diagram of decryption for the CFB mode of
-operation in light mode](/assets/images/crypto/symmetric/CFB_decryption.png#gh-light-mode-only)
+<img src="/assets/images/crypto/symmetric/CFB_decryption.png" alt="Diagram of decryption for the CFB mode of operation in light mode" class="light-mode">
 
-![Diagram of decryption for the CFB mode of
-operation in dark mode](/assets/images/crypto/symmetric/CFB_decryption_invert.png#gh-dark-mode-only)
+<img src="/assets/images/crypto/symmetric/CFB_decryption_invert.png" alt="Diagram of decryption for the CFB mode of operation in dark mode" class="dark-mode">
 
 **OFB Mode** (Output Feedback Mode): In this mode, the initial vector IV is repeatedly encrypted to obtain a set of values $$Z_i$$ as follows: $$Z_0 = IV$$ and $$Z_i = E_K(Z_{i-1})$$. These values $$Z_i$$ are now used as though they were the key for a one-time pad, so that $$C_i = Z_i \oplus M_i$$. The ciphertext is the concatenation of the initial vector and these individual blocks: $$C = IV \cdot C_1 \cdot C_2 \cdots C_l$$. In OFB mode, it is very easy to tamper with ciphertexts. For instance, suppose that the adversary happens to know that the $$j^\textrm{th}$$ block of the message, $$M_j$$, specifies the amount of money being transferred to his account from the bank, and suppose he also knows that $$M_j = 100$$. Since he knows both $$M_j$$ and $$C_j$$, he can determine $$Z_j$$. He can then substitute any $$n$$-bit block in place of $$M_j$$ and get a new ciphertext $$C'_j$$ where the $$100$$ is replaced by any amount of his choice. This kind of tampering is also possible with other modes of operation as well (so don't be fooled into thinking that CBC mode is safe from tampering); it's just easier to illustrate on OFB mode.
 
 - OFB mode encryption:
 
   $$
   \begin{cases}
-    Z*0 = IV \\ Z_i = E_K(Z*{i-1}) \\ C_i = M_i \oplus Z_i
+    Z_0 = IV \\ Z_i = E_K(Z*{i-1}) \\ C_i = M_i \oplus Z_i
   \end{cases}
   $$
 
 - OFB mode decryption: $$P_i = C_i \oplus Z_i$$
 
-![Diagram of encryption for the OFB mode of
-operation in light mode](/assets/images/crypto/symmetric/OFB_encryption.png#gh-light-mode-only)
+<img src="/assets/images/crypto/symmetric/OFB_encryption.png" alt="Diagram of encryption for the OFB mode of operation in light mode" class="light-mode">
 
-![Diagram of encryption for the OFB mode of
-operation in dark mode](/assets/images/crypto/symmetric/OFB_encryption_invert.png#gh-dark-mode-only)
+<img src="/assets/images/crypto/symmetric/OFB_encryption_invert.png" alt="Diagram of encryption for the OFB mode of operation in dark mode" class="dark-mode">
 
-![Diagram of decryption for the OFB mode of
-operation in light mode](/assets/images/crypto/symmetric/OFB_decryption.png#gh-light-mode-only)
+<img src="/assets/images/crypto/symmetric/OFB_decryption.png" alt="Diagram of decryption for the OFB mode of operation in light mode" class="light-mode">
 
-![Diagram of decryption for the OFB mode of
-operation in dark mode](/assets/images/crypto/symmetric/OFB_decryption_invert.png#gh-dark-mode-only)
+<img src="/assets/images/crypto/symmetric/OFB_decryption_invert.png" alt="Diagram of decryption for the OFB mode of operation in dark mode" class="dark-mode">
 
 **Counter (CTR) Mode**: In CTR mode, a counter is initialized to IV and repeatedly incremented and encrypted to obtain a sequence that can now be used as though they were the keys for a one-time pad: namely, $$Z_i = E_K(IV + i)$$ and $$C_i = Z_i \oplus M_i$$. In CTR mode, the IV is sometimes renamed the _nonce_. This is just a terminology difference--nonce and IV can be used interchangeably for the purposes of this class.
 
@@ -336,17 +320,13 @@ Note that in CTR and OFB modes, the decryption algorithm uses the block cipher _
 
 - CTR mode decryption: $$M_i = E_K(IV + i) \oplus C_i$$
 
-![Diagram of encryption for the CTR mode of
-operation in light mode](/assets/images/crypto/symmetric/CTR_encryption.png#gh-light-mode-only)
+<img src="/assets/images/crypto/symmetric/CTR_encryption.png" alt="Diagram of encryption for the CTR mode of operation in light mode" class="light-mode">
 
-![Diagram of encryption for the CTR mode of
-operation in dark mode](/assets/images/crypto/symmetric/CTR_encryption_invert.png#gh-dark-mode-only)
+<img src="/assets/images/crypto/symmetric/CTR_encryption_invert.png" alt="Diagram of encryption for the CTR mode of operation in dark mode" class="dark-mode">
 
-![Diagram of decryption for the CTR mode of
-operation in light mode](/assets/images/crypto/symmetric/CTR_decryption.png#gh-light-mode-only)
+<img src="/assets/images/crypto/symmetric/CTR_decryption.png" alt="Diagram of decryption for the CTR mode of operation in light mode" class="light-mode">
 
-![Diagram of decryption for the CTR mode of
-operation in dark mode](/assets/images/crypto/symmetric/CTR_decryption_invert.png#gh-dark-mode-only)
+<img src="/assets/images/crypto/symmetric/CTR_decryption_invert.png" alt="Diagram of decryption for the CTR mode of operation in dark mode" class="dark-mode">
 
 For the rest of these notes, we will focus on analyzing CBC and CTR modes. As an exercise, you can try performing similar analysis on the other modes as well.
 

network/dos.md

@@ -18,7 +18,7 @@ Application level DoS attacks tend to target the resources that an application u
 
 1. Identification: You must be able to distinguish requests from different users and require some method to identify or authenticate them (though this process might be expensive and itself vulnerable to DoS attacks)
 2. Isolation: You must ensure that one user’s actions do not affect another user’s experience
-3. Quotas: You must ensure that users can only access a certain proportion of resources. Possible implementations of this are that you could limit each user to 4 GB of RAM and 2 CPU cores or you could ensure that only trusted users can execute expensive requests. Another possible “defense” could include proof-of-work (like a CAPTCHA) wherein you force users to spend some resources in order to issue a request. The idea here is that the DoS attack becomes more expensive for the attacker as they have to now spend extra resources in order to succeed.
+3. Quotas: You must ensure that users can only access a certain proportion of resources. There are many possible implementations of this. One method to implement this is to place specific limits on each user such as limiting users to only 4 GB of RAM and 2 CPU cores. Another example of is to assign specific roles to users such that only trusted people can execute expensive requests. Another possible “defense” would include proof-of-work (like CAPTCHA) wherein you force users to spend some resources in order to issue a request. The idea here is that the DoS attack becomes more expensive for the attacker as they have to now spend extra resources in order to succeed.
 
 ## 34.3. SYN Flood Attacks
 
@@ -34,6 +34,6 @@ Essentially, what is happening here is that the server does not create state unt
 
 ## 34.4. Distributed Denial of Service (DDoS)
 
-Today, most standard DoS attacks are impractical to execute from a single machine. Modern server technology allows websites to handle an enormous amount of bandwidth, much greater than the bandwidth that is possible from a single machine. Despite this however, DoS conditions can still be created by using multiple attacking machines in what is known as a Distributed Denial of Service (DDoS) attack. Here, malicious user(s) leverage the power of many machines (the number of machines could be in the thousands) to direct traffic against a single website in an attempt to create DoS conditions (i.e. prevent availability). Often, attackers carry out DDoS attacks by using botnets, a series of large networks of machines that have been compromised and are controllable remotely.
+Today, most standard DoS attacks are impractical to execute from a single machine. Modern server technology allows websites to handle an enormous amount of bandwidth, much greater than the bandwidth that is possible from a single machine. However, DoS conditions can still be created by using multiple attacking machines in what is known as a Distributed Denial of Service (DDoS) attack. Here, malicious user(s) leverage the power of many machines (the number of machines could be in the thousands) to direct traffic against a single website in an attempt to create DoS conditions (i.e. prevent availability). Often, attackers carry out DDoS attacks by using botnets, a series of large networks of machines that have been compromised and are controllable remotely.
 
 Theoretically, there is no way to completely eliminate the possibility of a DDoS attack since the bandwidth that a server is able to provide its users is always going to be limited. However, measures can still be taken to mitigate the risks of DDoS attacks. For example, several servers incorporate DDoS protection mechanisms that analyze incoming traffic and drop packets from sources that are consuming too much bandwidth. Unfortunately, IP spoofing makes this defense extremely difficult by obscuring the identity of the attacker bots and providing inconsistent information on where network traffic is coming from.