diff --git a/Cure53/Cryptocat-2-Pentest-Report.pdf b/Cure53/Cryptocat-2-Pentest-Report.pdf
new file mode 100644
index 0000000..71add12
Binary files /dev/null and b/Cure53/Cryptocat-2-Pentest-Report.pdf differ
diff --git a/Cure53/Cure53_-_Subrosa.pdf b/Cure53/Cure53_-_Subrosa.pdf
new file mode 100644
index 0000000..730614f
Binary files /dev/null and b/Cure53/Cure53_-_Subrosa.pdf differ
diff --git a/Cure53/cure53-audit-may2014.pdf b/Cure53/cure53-audit-may2014.pdf
new file mode 100644
index 0000000..730614f
Binary files /dev/null and b/Cure53/cure53-audit-may2014.pdf differ
diff --git a/Cure53/pentest-report_casebox-1.pdf b/Cure53/pentest-report_casebox-1.pdf
new file mode 100644
index 0000000..0bf5932
Binary files /dev/null and b/Cure53/pentest-report_casebox-1.pdf differ
diff --git a/Cure53/pentest-report_casebox-2.pdf b/Cure53/pentest-report_casebox-2.pdf
new file mode 100644
index 0000000..5f00fba
Binary files /dev/null and b/Cure53/pentest-report_casebox-2.pdf differ
diff --git a/Cure53/pentest-report_clipperz.pdf b/Cure53/pentest-report_clipperz.pdf
new file mode 100644
index 0000000..61601f8
Binary files /dev/null and b/Cure53/pentest-report_clipperz.pdf differ
diff --git a/Cure53/pentest-report_globaleaks.pdf b/Cure53/pentest-report_globaleaks.pdf
new file mode 100644
index 0000000..93efce3
Binary files /dev/null and b/Cure53/pentest-report_globaleaks.pdf differ
diff --git a/Cure53/pentest-report_mailvelope.pdf b/Cure53/pentest-report_mailvelope.pdf
new file mode 100644
index 0000000..de666eb
Binary files /dev/null and b/Cure53/pentest-report_mailvelope.pdf differ
diff --git a/Cure53/pentest-report_minilock.pdf b/Cure53/pentest-report_minilock.pdf
new file mode 100644
index 0000000..97c0668
Binary files /dev/null and b/Cure53/pentest-report_minilock.pdf differ
diff --git a/Cure53/pentest-report_onion-browser.pdf b/Cure53/pentest-report_onion-browser.pdf
new file mode 100644
index 0000000..0ab5dd2
Binary files /dev/null and b/Cure53/pentest-report_onion-browser.pdf differ
diff --git a/Cure53/pentest-report_openpgpjs.pdf b/Cure53/pentest-report_openpgpjs.pdf
new file mode 100644
index 0000000..c906507
Binary files /dev/null and b/Cure53/pentest-report_openpgpjs.pdf differ
diff --git a/Cure53/pentest-report_securedrop.pdf b/Cure53/pentest-report_securedrop.pdf
new file mode 100644
index 0000000..930dea3
Binary files /dev/null and b/Cure53/pentest-report_securedrop.pdf differ
diff --git a/Defuse/Defuse_-_EncFS.txt b/Defuse/Defuse_-_EncFS.txt
new file mode 100644
index 0000000..b13d6b6
--- /dev/null
+++ b/Defuse/Defuse_-_EncFS.txt
@@ -0,0 +1,225 @@
+------------------------------------------------------------------------
+                          EncFS Security Audit
+                             Taylor Hornby
+                            January 14, 2014
+                      (Updated: February 5, 2014)
+------------------------------------------------------------------------
+
+1. Introduction
+
+  This document describes the results of a 10-hour security audit of
+  EncFS 1.7.4. The audit was performed on January 13th and 14th of 2014.
+
+1.1. What is EncFS?
+
+  EncFS is a user-space encrypted file system. Unlike disk encryption
+  software like TrueCrypt, EncFS's ciphertext directory structure
+  mirrors the plaintext's directory structure. This introduces unique
+  challenges, such as guaranteeing unique IVs for file name and content
+  encryption, while maintaining performance.
+
+1.2. Audit Results Summary
+
+  This audit finds that EncFS is not up to speed with modern
+  cryptography practices. Several previously known vulnerabilities have
+  been reported [1, 2], which have not been completely fixed. New issues
+  were also discovered during the audit.
+
+  The next section presents a list of the issues that were discovered.
+  Each issue is given a severity rating from 1 to 10. Due to lack of
+  time, most issues have not been confirmed with a proof-of-concept.
+
+2. Issues
+
+2.1. Same Key Used for Encryption and Authentication
+
+  Exploitability: Low
+  Security Impact: Low
+
+  EncFS uses the same key for encrypting data and computing MACs. This
+  is generally considered to be bad practice.
+
+  EncFS should use separate keys for encrypting data and computing MACs.
+
+2.2. Stream Cipher Used to Encrypt Last File Block
+
+  Exploitability: Unknown
+  Security Impact: High
+
+  As reported in [1], EncFS uses a stream cipher mode to encrypt the
+  last file block. The change log says that the ability to add random
+  bytes to a block was added as a workaround for this issue. However, it
+  does not solve the problem, and is not enabled by default.
+
+  EncFS needs to use a block mode to encrypt the last block.
+
+  EncFS's stream encryption is unorthodox:
+
+    1. Run "Shuffle Bytes" on the plaintext.
+        N[J+1] = Xor-Sum(i = 0 TO J) { P[i] }
+        (N = "shuffled" plaintext value, P = plaintext)
+    2. Encrypt with (setIVec(IV), key) using CFB mode.
+    3. Run "Flip Bytes" on the ciphertext.
+        This reverses bytes in 64-byte chunks.
+    4. Run "Shuffle Bytes" on the ciphertext.
+    5. Encrypt with (setIVec(IV + 1), key) using CFB mode.
+
+    Where setIVec(IV) = HMAC(globalIV || (IV), key), and,
+        - 'globalIV' is an IV shared across the entire filesystem.
+        - 'key' is the encryption key.
+
+  This should be removed and replaced with something more standard. As
+  far as I can see, this provides no useful security benefit, however,
+  it is relied upon to prevent the attacks in [1]. This is security by
+  obscurity.
+
+2.3. Generating Block IV by XORing Block Number
+
+  Exploitability: Low
+  Security Impact: Medium
+
+  Given the File IV (an IV unique to a file), EncFS generates per-block
+  IVs by XORing the File IV with the Block Number, then passing the
+  result to setIVec(), which is described in Section 2.2. This is not
+  a good solution, as it leads to IV re-use when combined with the
+  last-block stream cipher issue in Section 2.2:
+
+  The stream algorithm (see previous section) adds 1 to the IV, which
+  could *undo* the XOR with the block number, causing the IV to be
+  re-used. Suppose the file consists of one and a half blocks, and that
+  the File IV's least significant bit (LSB) is 1. The first block will
+  be encrypted with the File IV (block number = 0). The second (partial)
+  block will be encrypted with File IV XOR 1 (since block number = 1),
+  making the LSB 0, using the stream algorithm.  The stream algorithm
+  adds 1 to the IV, bringing the LSB back to 1, and hence the same IV is
+  used twice. The IVs are reused with different encryption modes (CBC
+  and CFB), but CFB mode starts out similar to CBC mode, so this is
+  worrisome.
+
+  EncFS should use a mode like XTS for random-access block encryption.
+
+  Correction 12/05/2014: XTS mode is probably not the ideal option, see
+  Thomas Ptacek's blog post for good reasons why:
+
+      http://sockpuppet.org/blog/2014/04/30/you-dont-want-xts/
+
+2.4. File Holes are Not Authenticated
+
+  Exploitability: High
+  Security Impact: Low
+
+  File holes allow large files to contain "holes" of all zero bytes,
+  which are not saved to disk. EncFS supports these, but it determines
+  if a file block is part of a file hole by checking if it is all
+  zeroes. If an entire block is zeroes, it passes the zeroes on without
+  decrypting it or verifying a MAC.
+
+  This allows an attacker to insert zero blocks inside a file (or append
+  zero blocks to the end of the file), without being detected when MAC
+  headers are enabled.
+
+2.5. MACs Not Compared in Constant Time
+
+  Exploitability: Medium
+  Security Impact: Medium
+
+  MACs are not compared in constant time (MACFileIO.cpp, Line 209). This
+  allows an attacker with write access to the ciphertext to use a timing
+  attack to compute the MAC of arbitrary values.
+
+  A constant-time string comparison should be used.
+
+2.6. 64-bit MACs
+
+  Exploitability: Low
+  Security Impact: Medium
+
+  EncFS uses 64-bit MACs. This is not long enough, as they can be forged
+  in 2^64 time, which is feasible today.
+
+  EncFS should use (at least) 128-bit MACs.
+
+2.7. Editing Configuration File Disables MACs
+
+  Exploitability: High
+  Security Impact: Medium
+
+  The purpose of MAC headers is to prevent an attacker with read/write
+  access to the ciphertext from being able to make changes without being
+  detected.  Unfortunately, this feature provides little security, since
+  it is controlled by an option in the .encfs6.xml configuration file
+  (part of the ciphertext), so the attacker can just disable it by
+  setting "blockMACBytes" to 0 and adding 8 to "blockMACRandBytes" (so
+  that the MAC is not interpreted as data).
+
+  EncFS needs to re-evaluate the purpose of MAC headers and come up with
+  something more robust. As a workaround, EncFS could add a command line
+  option --require-macs that will trigger an error if the configuration
+  file does not have MAC headers enabled.
+
+3. Future Work
+
+  There were a few potential problems that I didn't have time to
+  evaluate. This section lists the most important ones. These will be
+  prioritized in future audits.
+
+3.1. Information Leakage Between Decryption and MAC Check
+
+  EncFS uses Mac-then-Encrypt. Therefore it is possible for any
+  processing done on the decrypted plaintext before the MAC is checked
+  to leak information about it, in a style similar to a padding oracle
+  vulnerability. EncFS doesn't use padding, but the MAC code does
+  iteratively check if the entire block is zero, so the number of
+  leading zero bytes in the plaintext is leaked by the execution time.
+
+3.2. Chosen Ciphertext Attacks
+
+  Since the same key is used to encrypt all files, it may be possible
+  for an attacker with read/write access to the ciphertext and partial
+  read access to the plaintext (e.g. to one directory when --public is
+  used) to perform a chosen ciphertext attack and decrypt ciphertexts
+  for which they have no plaintext access.
+
+  EncFS should consider using XTS mode.
+
+  Correction 12/05/2014: XTS mode is probably not the ideal option, see
+  Thomas Ptacek's blog post for good reasons why:
+
+      http://sockpuppet.org/blog/2014/04/30/you-dont-want-xts/
+
+3.3. Possible Out of Bounds Write in StreamNameIO and BlockNameIO
+
+  There is a possible buffer overflow in the encodeName method of
+  StreamNameIO and BlockNameIO. The methods write to the 'encodedName'
+  argument without checking its length. This may allow an attacker with
+  control over file names to crash EncFS or execute arbitrary code.
+
+3.4. 64-bit Initialization Vectors
+
+  Initialization vectors are only 64 bits, even when using AES instead
+  of Blowfish. This may lead to vulnerabilities when encrypting large
+  (or lots of) files.
+
+4. Conclusion
+
+  In conclusion, while EncFS is a useful tool, it ignores many standard
+  best-practices in cryptography. This is most likely due to it's old
+  age (originally developed before 2005), however, it is still being
+  used today, and needs to be updated.
+
+  The EncFS author says that a 2.0 version is being developed [3]. This
+  would be a good time to fix the old problems.
+
+  EncFS is probably safe as long as the adversary only gets one copy of
+  the ciphertext and nothing more. EncFS is not safe if the adversary
+  has the opportunity to see two or more snapshots of the ciphertext at
+  different times. EncFS attempts to protect files from malicious
+  modification, but there are serious problems with this feature.
+
+5. References
+
+[1] http://archives.neohapsis.com/archives/fulldisclosure/2010-08/0316.html
+
+[2] http://code.google.com/p/encfs/issues/detail?id=128
+
+[3] https://code.google.com/p/encfs/issues/detail?id=186
\ No newline at end of file
diff --git a/Defuse/Defuse_-_Hash0.txt b/Defuse/Defuse_-_Hash0.txt
new file mode 100644
index 0000000..326c5fb
--- /dev/null
+++ b/Defuse/Defuse_-_Hash0.txt
@@ -0,0 +1,314 @@
+-----------------------------------------------------------------------
+                        Security Audit of Hash0
+                             Taylor Hornby
+                            April 13,  2014
+-----------------------------------------------------------------------
+
+1. Introduction
+
+   This report is the result of a 5-hour audit of Hash0 [1]. Hash0 is
+   a tool for generating different passwords for websites based on
+   a master password, similar to pwdhash [2] and hashpass [3].
+
+   The audit scope and threat model are discussed in sections 1.2 and
+   1.3 respectively. Section 2 gives an overview of Hash0's
+   cryptography. Section 3 presents security issues found during the
+   audit. Section 4 recommends improvements. Section 5 lists future
+   work, and Section 6 concludes.
+
+1.2 Audit Scope
+
+   This audit focused on the implementation and design of Hash0's
+   cryptography, and did not explicitly check for other kinds of
+   vulnerabilities.
+
+   While some light review of the supporting libraries was performed,
+   the audit focused on code unique to Hash0 and did not include
+   significant time reviewing the PasswordMaker, SJCL, or CryptoJS
+   libraries.
+
+   The SHA1 of the commit that was reviewed is:
+
+        09338e4f0f453e8ad95859e0f882cf7c7d54aa26
+
+1.3 Threat Model
+
+   There are three types of entities involved in every use of Hash0:
+
+        1. The User
+
+            The User is the person using the Hash0 software. The User
+            knows the master password and uses Hash0 to generate
+            site-specific passwords from the one master password.
+
+        2. The Storage Provider
+
+            The Storage Provider is responsible for storing metadata
+            like the salts and synchronization settings. We assume this
+            entity is controlled by the adversary.
+
+        3. The Website
+
+            This is the website the user is using Hash0 to generate
+            a password for. The website provides a standard username and
+            password login interface and is not necessarily aware that
+            Hash0 is being used. We assume this entity is controlled by
+            the adversary.
+
+   The following list summarizes some kinds of attacks that would be
+   considered security flaws in Hash0.
+
+        - Attacks that leak useful information about the Master Password
+          to any entity other than the User, even when the attacker can
+          see many generated passwords.
+
+        - Attacks that leak passwords for one Website to any entity
+          other than the User or the intended Website.
+
+        - Attacks that cause weak passwords to be generated.
+
+        - Attacks that speed up the recovery of the master key from
+          derived data (ciphertext, generated passwords, etc).
+
+2. Cryptography Design
+
+   Given a master password, Hash0 runs it through 100 iterations PBKDF2
+   with the salt "saltysnacks" to produce 512 bits of output*. That
+   output is used as a key to HMAC the string "zerobin1337". The HMAC
+   output is converted to a 30-character password, called the
+   "encryption password", with a base conversion algorithm. This
+   password is used for encrypting and decrypting data stored by the
+   Storage Provider.
+
+   The data stored by the Storage Provider is encrypted and decrypted
+   using SJCL's encrypt() and decrypt() convenience functions, with the
+   default parameters. The default is to derive an 128-bit key from the
+   password with PBKDF2 then encrypt the data with AES in CCM mode,
+   which is an authenticated encryption mode.
+
+   To generate a password for a website, Hash0 runs the master password
+   through 100 iterations of PBKDF2 with a random salt** to generate 512
+   bits of output.  That output is used as a key to HMAC the string
+   which is the domain name of the website prefixed to the password
+   number (used to generate multiple passwords for the same website).
+   The HMAC output is converted to a password of configurable length
+   using a base conversion algorithm.
+
+   * - The PBKDF2 output is encoded in hex and is used as the HMAC key
+       without being decoded.
+
+   **- The salt may be the empty string if the Storage Provider URL is
+       not configured. See Issue 3.7. The salt is encoded (and used) as
+       a 128-bit hex string.
+
+3. Issues
+
+   This section lists the issues discovered during the audit. We do not
+   attempt to assign criticality or exploitability ratings to the
+   issues.
+
+3.1 Encryption is Stored in LocalStorage
+
+   The encryption key, which is used to encrypt and decrypt the data
+   stored by the Storage Provider, is stored in localStorage. Unless the
+   browser is in private browsing mode, it will be written to disk. It
+   should be kept it memory.
+
+   The Hash0 author was aware of this issue before this audit began.
+
+3.2 Salts Generated with Math.random()
+
+   The salts are generated with CryptoJS's WordArray.random(), which
+   uses Math.random(). This is insecure. Salts must be generated with
+   a CSPRNG.
+
+   Use window.crypto.getRandomValues() or the SJCL cryptographic random
+   number generator.
+
+   The Hash0 author was aware of this issue before this audit began.
+
+3.3 Low PBKDF2 Iteration Count
+
+   Only 100 iterations of PBKDF2 are used when deriving the encryption
+   password or a website password. This low value was explicitly chosen
+   for performance reasons. According to these benchmarks...
+
+        https://wiki.mozilla.org/SJCL_PBKDF2_Benchmark
+
+   ...most platforms can support many more iterations. The iteration
+   count should be increased to 1000.
+
+   This is probably because 1000 iterations of PBKDF2 actually are being
+   used, but not in the right place. SJCL's encrypt() and decrypt()
+   functions compute 1000 iterations of PBKDF2 to turn the passed string
+   into a key. To avoid this, pass a key (bitArray), not a string, to
+   encrypt() and decrypt().
+
+   The Hash0 author was aware of this issue before the audit began.
+
+3.4 Corrupted Ciphertext Exception is Not Caught
+
+   The SJCL decrypt() function will throw sjcl.exception.corrupt if the
+   key is wrong or if an attacker has tampered with the ciphertext.
+   Hash0 does not handle this case, and simply crashes without giving
+   the user any explanation.
+
+   This exception should be caught, and the user should be told that
+   either the password they entered was wrong, or an attacker has
+   tampered with the data saved by the Storage Provider.
+
+3.5 Encryption Password Derived with Constant Salt
+
+   The encryption password is derived from the master password with
+   a constant salt:
+
+        generatePassword(
+            'on', 30, 'zerobin', '1337', 'saltysnacks', password
+        );
+
+   This is insecure, because the same master password will always
+   generate the same encryption password, so rainbow tables and lookup
+   tables can be used to crack the encrypted data.
+
+   Fixing this is left as future work. See Section 5.3.
+
+3.6 Migration Code Always Runs
+
+   This is not a security issue. The code to prompt the user if they
+   want to migrate will always run, because the "if" statement's
+   condition will always be true:
+
+        var password = $('#setup_master').val();
+        localStorage['encryptionPassword'] = // ... snipped ...
+
+        var url = $('#setup_url').val();
+        localStorage['settingsURL'] = url;
+
+        // Check if there is existing settings
+        if (defined(localStorage['settingsURL']) &&
+            defined(localStorage['encryptionPassword'])) {
+
+3.7 Empty Salt Used Without Warning
+
+   If the URL to the Storage Provider is not provided or is empty, an
+   empty salt is used:
+
+        if (!defined(localStorage['encryptionPassword']) ||
+            !defined(localStorage['settingsURL']) ||
+            localStorage['settingsURL'] == '') {
+            salt = '';
+        } else {
+            ...
+
+   Instead of using an empty salt, display an error (refuse to generate
+   passwords), or warn the user and ask them to opt-in to using the
+   empty salt.
+
+3.8 HMAC Key is a Hex String
+
+   When deriving the encryption password or a website password, the
+   string used for the HMAC key is hex-encoded. This does not cause any
+   immediate weaknesses, however using a key that isn't uniformly
+   distributed is not ideal and probably breaks some of HMAC's security
+   proofs.
+
+3.9 Salt is a Hex String
+
+   The salt passed to PBKDF2 is a hex string. While this doesn't cause
+   any immediate security problems, it is not ideal.
+
+3.10 Password is Output Before Settings are Saved
+
+   When generating a website password, the password is shown to the user
+   before the settings are uploaded. This means an attacker who can
+   prevent the settings from being uploaded (e.g. by a DoS attack) can
+   cause password reuse in some cases:
+
+        1. User generates a password for example.org.
+        2. Example.org's password database is breached.
+        3. User generates a new password, but the upload fails.
+        4. Example.org's password database is breached again.
+        5. User generates a new password, but this time it's the same as
+           the one generated in (4) because the upload with the
+           incremented number failed.
+
+3.11 Browser Tab Race Conditions
+
+   Because of a TOCTTOU bug, it's possible for the password to be
+   entered in to the wrong tab. 
+    
+   The init() function first obtains the password for the current param
+   (domain), and then, AFTER it already has the password, it inserts it
+   into the current tab. The tab might have changed in between.
+    
+   A malicious website could potentially "steal focus" at just the right
+   time to steal a password that was intended for another website.
+
+   To fix this, make sure that the tab the password is going to be
+   inserted into is the same as the one that was the source of param.
+
+4. Recommendations
+
+4.1 Unit Tests
+
+   Hash0 could benefit from unit tests, especially of important
+   functions like initWithUrl() and generatePassword().
+
+4.2 Use PBKDF2 alone, not PBKDF2 then HMAC
+
+   It doesn't seem necessary to use PBKDF2 to generate a key then to use
+   HMAC on top of that to apply the param and number. It would be better
+   to encode everything unambiguously into the PBKDF2 salt.
+
+4.3 Do Not Use Passwords as Intermediate Keys
+
+   Hash0 is somewhat strange in that instead of deriving an encryption
+   key from the password, it derives another "encryption password." This
+   is inefficient at best, and error-prone at worst. Stick to binary
+   keys whenever possible.
+
+5. Future Work
+
+5.1 Side Channel Attacks
+
+   Some of the code seems vulnerable to side-channel attacks. For
+   example, passwordmaker/hashutils.js uses charAt() to get the
+   character at an index into the character set, where the index is
+   a secret.
+
+   It could be possible for other scripts running in the browser, or
+   other processes running on the system (as other users), to extract
+   the key this way.
+
+5.2 URL Reliability
+
+   This audit did not fully explore all possible problems with the URL
+   used to find the domain name not matching up with the actual URL of
+   the page. Is it possible for a page to lie about its URL, so that
+   Hash0 is fooled into giving it the password for another website?
+
+5.3 Salting the Master Password
+
+   The encryption key is derived from the master key with a fixed salt.
+   Obviously, a random salt should be used instead. More time is needed
+   to design a secure solution.
+
+5.4 Storage Provider Replaying Old Data
+
+   What exactly happens when the Storage Provider replays an old
+   ciphertext?  This will cause old passwords to be generated, and
+   possibly some passwords re-used. What kind of risk does this pose to
+   the user?
+
+6. Conclusion
+
+   No fatal flaws in Hash0 were identified. However, there is room for
+   improvement. The most significant issues are 3.1, 3.2, 3.4, and 3.5.
+   3.11 may be very important as well, depending on how exploitable it
+   is in practice (something this audit did not investigate).
+
+7. References
+
+[1] https://github.com/dannysu/hash0
+[2] https://www.pwdhash.com/
+[3] http://www.hashapass.com/en/index.html
\ No newline at end of file
diff --git a/Defuse/Defuse_-_ZeroBin.txt b/Defuse/Defuse_-_ZeroBin.txt
new file mode 100644
index 0000000..29e5969
--- /dev/null
+++ b/Defuse/Defuse_-_ZeroBin.txt
@@ -0,0 +1,334 @@
+-----------------------------------------------------------------------
+                       Security Audit of ZeroBin
+                             Taylor Hornby
+                           February 02, 2014
+-----------------------------------------------------------------------
+
+1. Introduction
+
+   ZeroBin's website [ZBW] describes ZeroBin as "a minimalist,
+   opensource online pastebin/discussion board where the server has zero
+   knowledge of hosted data."
+
+   This report documents the results of a 4-hour security audit of
+   ZeroBin. It was performed for free as a service to the free and open
+   source software community.
+
+   The audit was performed on a current clone of ZeroBin's Git
+   repository [GR]. The commit hash is:
+
+     4f8750bbddcb137213529875e45e3ace3be9a769
+
+   Note that this code is newer than the code available for download
+   from the ZeroBin website [ZBW] (version 0.18), which has known
+   vulnerabilities [XSS].
+
+1.1 Audit Scope
+
+   This audit focused on the PHP side of ZeroBin. The JavaScript side
+   was only audited briefly, so most issues could not be verified, and
+   were added to Section 4, Future Work, below. The audit did NOT check
+   for XSS vulnerabilities in zerobin.js, and did NOT check for correct
+   usage of the SJCL cryptography library.
+
+   The audit did NOT cover the following files:
+
+     - lib/rain.tpl.class.php
+     - js/base64.js
+     - js/highlight.pack.js
+     - js/jquery.js
+     - js/rawdeflate.js
+     - js/rawinflate.js
+     - js/sjcl.js
+
+2. Issues
+
+2.1. Salt and HMAC Key Generated with mt_rand()
+
+   Exploitability: Medium
+   Security Impact: Low
+
+   In serversalt.php, generateRandomSalt() generates a salt using the
+   mt_rand() pseudo-random number generator. Because mt_rand() is not
+   a cryptographic random number generator, this function will return
+   easily-guessed salts with a much higher probability of collision.
+
+   The salts generated by this function are relied on for security. For
+   example, it is used as an HMAC key when checking delete tokens in
+   processPasteDelete(). It should be replaced with mcrypt_create_iv()
+   or openssl_random_pseudo_bytes().
+
+   Another unused mt_rand() salt generator appears in
+   vizhash_gd_zero.php. This should be removed.
+
+   This issue has already been reported in [GH68], but has not been
+   fixed (the issue is still open).
+
+2.2. Fixed Server Salt
+
+   Exploitability: Low
+   Security Impact: Low
+
+   The security of the VizHash hashes of IP addresses (used to generate
+   comment avatars) and delete tokens both rely on a fixed "salt" which
+   is generated once per deployment, saved in data/salt.php.
+
+   As noted in Issue 2.1, this salt is not generated with a secure
+   random number, but keeping it fixed has several other disadvantages:
+
+     - If the salt is compromised and published, anyone can reverse
+       a VizHash into the corresponding IP address, even for expired
+       posts (that they saved). This would not be possible if a random
+       comment salt was generated for each post, then destroyed along
+       with the post when it expires. This would, however, give users
+       different avatars on different posts (which may be desired).
+
+     - If the salt is compromised and published, anyone can find the
+       delete link for any post, since they can compute the HMAC. This
+       does not need to be possible. A random delete token could be
+       generated for each post, and its hash stored along with the post.
+       Then, the post could only be deleted if the user can provide the
+       preimage of the hash.
+
+     - Reusing the same key for two purposes is generally a bad idea.
+
+2.3. Traffic Limiter Race Conditions
+
+   To rate limit requests, ZeroBin keeps a history of hit times in
+   data/traffic_limiter.php, which is generated and re-generated in
+   traffic_limiter_canPass(). Because requests can be made
+   asynchronously, the file may become corrupted.
+
+   This might allow remote code execution, if the attacker is clever
+   enough to corrupt the file in just the right way, since the
+   traffic_limiter.php file is require()'d.
+
+   This issue has already been reported, and a patch has been provided,
+   in [GH61], but has not been fixed (the issue is still open).
+
+2.4. VizHash IP Address Online Guessing
+
+   Exploitability: Very Low
+   Security Impact: Low
+
+   The VizHash system is used to give users who comment an avatar
+   derived from their IP address. If an attacker can create connections
+   to the ZeroBin server from arbitrary source IPs (e.g. if they are in
+   the same LAN as the ZeroBin server, or man-in-the-middling its
+   traffic), they can perform an online guessing attack on the VizHash
+   they are interested in.
+
+2.5. Relies on .htaccess files, which may not be enabled.
+
+   Exploitability: N/A
+   Security Impact: Very Low
+
+   ZeroBin relies on .htaccess files being enabled to prevent access to
+   the 'data' directory. This directory contains the ciphertexts, salt,
+   and rate limiter array. If .htaccess is disabled, of if ZeroBin is
+   installed on a non-Apache web server, then an attacker may be able to
+   access these files. 
+   
+   The salt and rate limiter array are safe since they are in .php
+   files. However, the attacker would be able to access the ciphertext.
+   This is not a security issue because the attacker already has access
+   to the ciphertext.
+
+   If directory traversal is enabled, the attacker can see all of the
+   post ids, too.
+
+2.6. The robots.txt does not work in a subdomain.
+
+   Exploitability: N/A
+   Security Impact: Low
+
+   ZeroBin uses a robots.txt file to prevent search engines from
+   indexing the posts. If you install ZeroBin into a subdirectory, this
+   does not work. A note about this should be added to the README or
+   other documentation, so that the user knows to install the robots.txt
+   file in the right place.
+
+2.7 HMAC Not Compared in Constant Time
+
+   Exploitability: Medium
+   Security Impact: Low
+
+   ZeroBin uses an HMAC to generate and check delete tokens. The HMAC is
+   compared against the correct one with PHP's "!=" operator. A timing
+   attack can exploit this error to compute the HMAC of arbitrary data
+   with the server's salt.
+
+   ZeroBin should check if the strings are equal in constant time:
+
+     function slow_equals($a, $b)
+     {
+         $diff = strlen($a) ^ strlen($b);
+         for($i = 0; $i < strlen($a) && $i < strlen($b); $i++)
+         {
+             $diff |= ord($a[$i]) ^ ord($b[$i]);
+         }
+         return $diff === 0;
+     }
+
+2.8. Arbitrary File Unlink
+
+   Exploitability: Medium
+   Security Impact: High
+
+   An attacker can delete arbitrary files on the server by exploiting
+   a vulnerability in processPasteDelete(). Here is a condensed version
+   of the code:
+
+   function processPasteDelete($pasteid,$deletetoken)
+   {
+       if (preg_match('/\A[a-f\d]{16}\z/',$pasteid))  
+       {
+           $filename = dataid2path($pasteid).$pasteid;
+           if (!is_file($filename)) 
+           {
+               return ... error message ...
+           }
+       }
+   
+       if ($deletetoken != hash_hmac('sha1', $pasteid , getServerSalt())) 
+       {
+           return ... error message ...
+       }
+   
+       deletePaste($pasteid);
+       return array('','','Paste was properly deleted.');
+   }
+
+   The $pasteid variable comes directly from $_GET['pasteid'], which the
+   attacker can control. The $deletetoken variable comes from
+   $_GET['deletetoken']. If $deletetoken matches the HMAC, $pasteid is
+   passed to deletePaste(), which runs:
+   
+     unlink(dataid2path($pasteid).$pasteid);
+
+    Thus, if an attacker can compute the HMAC, they can delete arbitrary
+    files on the server. The HMAC can be computed if the salt is known.
+    Forging the HMAC without already knowing the salt is easy because of
+    Issue 2.7 and Issue 2.1.
+
+2.9. HMAC Uses SHA1 instead of SHA256
+
+   Exploitability: Very Low
+   Security Impact: Low
+
+   ZeroBin uses a SHA1 HMAC to derive the delete token. SHA1 should be
+   replaced with a better hash function, like SHA256.
+
+2.10. No Cross-Site Request Forgery Protection
+
+   Exploitability: Medium
+   Security Impact: Medium
+
+   ZeroBin does not attempt to prevent Cross-Site Request Forgery (CSRF)
+   attacks. A malicious website can make a user's browser delete ZeroBin
+   posts (if the delete token is known), create posts, and post comments
+   to existing posts.
+
+   A CSRF attack to post comments can be a problem when a malicious
+   website wants to find out the ZeroBin VizHash of its visitors, to see
+   what they have been commenting. The attack would work as follows:
+
+     1. Alice suspects Bob posted a rude ZeroBin comment.
+     2. Alice generates a web page that causes Bob's browser to comment
+        "I AM BOB!" on a ZeroBin post.
+     3. Alice emails a link to the malicious page to Bob.
+     4. Bob clicks the link.
+     5. Alice checks the post, sees that the "I AM BOB!" comment has the
+        same VizHash as the rude comment. Alice now knows it was Bob
+        that made the rude comment.
+
+3. Coding Practices
+
+   The ZeroBin code could be made more secure, and easier to audit, by
+   following some good coding practices. These are documented in the
+   next sections.
+
+3.1. Always Assume Malice
+
+   When a string is used in a way that might affect security, it should
+   always be assumed to be malicious, even if it is just a constant
+   string. The ZeroBin code does not do this, for example:
+
+     - In the post creation code, it assumes $dataid is safe, which it
+       is, since it it is a hex string from an MD5 hash, but it would be
+       better if the code assumed it was malicious and checked/escaped
+       it anyway.
+
+     - Several strings are not escaped in tpl/page.html. $VERSION is not
+       escaped in the header, and $STATUS is not escaped in the body.
+       Even though these are static strings, they should be escaped
+       anyway, since someone might change the error messages to reflect
+       user input in the future. See Section 4.6.
+
+4. Future Work
+
+4.1. Secure Code Delivery
+
+   ZeroBin relies on the JavaScript code being delivered securely.
+   A malicious server or man-in-the-middle can modify the code to leak
+   the key. This is already well known and is being addressed in [GH17].
+
+4.2. urls2links XSS
+
+   In zerobin.js, urls2links() converts a URL text into a clickable
+   link. The replacement is done purely by regular expression, and no
+   escaping is done. This may be a source of XSS vulnerabilities. I did
+   not have enough time to understand what the regular expression is
+   doing, so I'm not sure if this is exploitable or not.
+
+   There are other bits of code that look like they might be XSS
+   vulnerabilities (e.g. line 233 in zerobin.js where divComment is
+   set). I did not have enough time to check these in detail.
+
+4.3. Low Entropy in Browsers Without CSPRNGs
+
+   If the web browser does not have window.crypto.getRandomValues(), the
+   key is derived from mouse movements and stuff. That may not be good
+   enough. Perhaps in these cases the server could help the client by
+   supplying some of its own entropy from mcrypt_create_iv() or
+   openssl_random_pseudo_bytes().
+
+4.4. Plaintext is Compressed Before Encryption
+
+   Posts are compressed before they are encrypted. This makes the
+   ciphertext length depend on the plaintext content. This may create
+   vulnerabilities in specific use cases where an attacker can choose
+   variations of the same post to be encrypted.  This would be similar
+   to the CRIME and BREACH attacks, except happening at the application
+   layer.
+
+4.5. Is SJCL used correctly?
+
+   This audit did not check if zerobin.js uses the SJCL cryptography
+   library correctly.
+
+4.6. Possible XSS in tpl/page.html
+
+   JSON encoded data is inserted into the HTML page unescaped in
+   tpl/page.html. This is because $STATUS is set to the return value of
+   processPasteFetch(), which returns JSON encoded data based on the
+   user's input. I did not check if this is exploitable.
+
+5. Conclusion
+
+   Several issues were found. The most critical being the arbitrary file
+   unlink vulnerability, described in Section 2.8, and the use of
+   mt_rand() to generate HMAC keys, described in Section 2.1.
+
+   This audit did not cover the JavaScript cryptography, nor did it
+   cover XSS vulnerabilities in the JavaScript code. More auditing time
+   is recommended.
+
+6. References
+
+   [GH17] https://github.com/sebsauvage/ZeroBin/issues/17
+   [GH68] https://github.com/sebsauvage/ZeroBin/issues/68
+   [GH61] https://github.com/sebsauvage/ZeroBin/pull/61
+   [GR]   https://github.com/sebsauvage/ZeroBin
+   [ZBW]  http://sebsauvage.net/wiki/doku.php?id=php:zerobin
+   [XSS]  https://github.com/sebsauvage/ZeroBin/commit/4f8750bbddcb137213529875e45e3ace3be9a769
\ No newline at end of file
diff --git a/Defuse/Defuse_-_eCryptfs.txt b/Defuse/Defuse_-_eCryptfs.txt
new file mode 100644
index 0000000..8d012ab
--- /dev/null
+++ b/Defuse/Defuse_-_eCryptfs.txt
@@ -0,0 +1,149 @@
+-----------------------------------------------------------------------
+                        eCryptfs Security Audit
+                             Taylor Hornby
+                            January 22, 2014
+-----------------------------------------------------------------------
+
+1. Introduction
+
+   This document describes the results of a 10-hour security audit on
+   the latest version (at time of writing) of the eCryptfs encrypted
+   file system. It follows a previous 10-hour audit on EncFS [4].
+
+1.1. What is eCryptfs?
+
+   eCryptfs is an encrypting file system similar to EncFS. The main
+   difference is that it runs as a kernel module instead of on top of
+   FUSE.
+
+1.2. Audit Results Summary
+
+   Due to the limited amount of time, this audit could only cover
+   a small portion of eCryptfs's design and implementation. Analysis of
+   the cryptographic design was prioritized.
+
+   Documentation about eCryptfs's crypto design is sparse and
+   contradictory. The design has changed dramatically from initial
+   (very old) design documents like [3]. The only reliable source is the
+   actual source code itself, which takes longer to review.
+
+   Some non-critical issues were discovered while looking over
+   eCryptfs's source code. These are documented in the next section.
+
+2. Issues
+
+2.1. ecryptfs-rewrap-passphrase salt reuse
+
+   Exploitability:  Low
+   Security Impact: Low
+
+   The ecryptfs-rewrap-passphrase command does not generate a new random
+   salt when the password is changed. I'm not sure if this is an
+   architectural requirement or not (I don't think so), but a new random
+   salt would be better.
+
+2.2. IV is the MD5 hash of key and extract (block) offset.
+
+   Exploitability:  Low
+   Security Impact: Low
+
+   The "Root IV" is the MD5 hash of the session encryption key, which is
+   a per-file random key. From the Root IV, the IV for an extract
+   (portion of the file) is generated by hashing it with the offset.
+
+   This doesn't immediately lead to vulnerabilities, and it's much
+   better than the way EncFS does it, but it doesn't seem safe. It would
+   be much better to use proper CBC ESSIV mode or XTS mode.
+
+   Correction 12/05/2014: XTS mode is probably not the ideal option, see
+   Thomas Ptacek's blog post for good reasons why:
+
+       http://sockpuppet.org/blog/2014/04/30/you-dont-want-xts/
+
+   There is a comment in the code that derives the IV...
+
+        /* TODO: It is probably secure to just cast the least
+         * significant bits of the root IV into an unsigned long and
+         * add the offset to that rather than go through all this
+         * hashing business. -Halcrow */
+
+   ...which is wrong, and needs to be removed.
+
+2.3. Filename Encryption Does Not Use IVs
+
+   Exploitability:  Low
+   Security Impact: Low
+
+   The file name encryption in encfs_write_tag_70_packet uses a zero IV
+   for filename encryption. However, "random bytes" are prepended to the
+   path before encrypting, and they are supposed to "do the job of the
+   IV here." However, they are not actually random bytes, they are the
+   hash the "session key encryption key." This key does not appear to
+   change, so I doubt these bytes are serving the purpose of an IV.
+
+   This may be required for determinism (so that you can look up a file
+   path without iterating through all files in a directory), but it's
+   a weird way of doing it. The comment does say "We do not want to
+   encrypt the same filename with the same key and IV, which may happen
+   with hard links, so we prepend random bits to each filename" ... but
+   it doesn't. This needs further analysis.
+
+   Prepending random IVs is not sufficient when using cipher modes other
+   than CBC, such as GCM and CTR, which are being discussed on the
+   mailing list [1,2].
+
+   Update (February 14, 2014): Filename encryption actually uses ECB
+   mode, so the random bytes are useless. Thanks to @samuelks for
+   reporting this.
+
+3. Future Work
+
+   The following sections document what should be prioritized in future
+   audits.
+
+3.1. The Mailing List is Discussing GCM Mode
+
+   Possible Exploitability:  Medium
+   Possible Security Impact: High
+
+   The eCryptfs mailing list is discussing the option of using other
+   modes like GCM and CTR. There are already patches submitted that
+   allow this, however, as far as I can tell, they haven't made it into
+   the git repository.
+
+   Using a stream mode like GCM would destroy eCryptfs's security, since
+   the key stream would not depend on the plaintext and an attacker
+   could simply XOR snapshots of a ciphertext at two different times to
+   learn the XOR of the plaintexts that changed. This is not the case
+   with a block mode like CBC (currently the default).
+
+3.2. Authenticated Encryption
+
+   The mailing list is discussing patches for adding authenticated
+   encryption (GCM, HMAC, etc). There was not enough time to review
+   these proposed changes, and I'm not sure if they're already in the
+   released code or not.
+
+3.3. Produce Crypto Documentation
+
+   eCryptfs's current crypto implementation is not well-documented. It
+   would be useful to create a document that describes it at a high
+   level, so that it is easier for experienced cryptographers to review
+   it.
+
+4. Conclusion
+
+   eCryptfs appears to have a better crypto design than EncFS [4], but
+   there are some red flags indicating that it was not designed by
+   a cryptographer, and has not received enough security review. It
+   should be safe to use, but more auditing would be a good idea.
+
+5. References
+
+[1] http://thread.gmane.org/gmane.comp.file-systems.ecryptfs.general/494
+
+[2] http://www.spinics.net/lists/ecryptfs/msg00381.html
+
+[3] http://ecryptfs.sourceforge.net/ecryptfs.pdf
+
+[4] https://defuse.ca/audits/encfs.htm
\ No newline at end of file
diff --git a/Fox-IT/Fox-IT_-_DigiNotar.pdf b/Fox-IT/Fox-IT_-_DigiNotar.pdf
new file mode 100644
index 0000000..39b53a0
Binary files /dev/null and b/Fox-IT/Fox-IT_-_DigiNotar.pdf differ
diff --git a/Fraunhofer/Fraunhofer_-_TrueCrypt.pdf b/Fraunhofer/Fraunhofer_-_TrueCrypt.pdf
new file mode 100644
index 0000000..5a05451
Binary files /dev/null and b/Fraunhofer/Fraunhofer_-_TrueCrypt.pdf differ
diff --git a/IOActive/ioactive-bromium-test-report-final.pdf b/IOActive/ioactive-bromium-test-report-final.pdf
new file mode 100644
index 0000000..f4f1810
Binary files /dev/null and b/IOActive/ioactive-bromium-test-report-final.pdf differ
diff --git a/IndependentSecurityEvaluators/ISE_-_Apple_iPhone.pdf b/IndependentSecurityEvaluators/ISE_-_Apple_iPhone.pdf
new file mode 100644
index 0000000..556ad7d
Binary files /dev/null and b/IndependentSecurityEvaluators/ISE_-_Apple_iPhone.pdf differ
diff --git a/LeastAuthority/LeastAuthority-Cryptocat-audit-report.pdf b/LeastAuthority/LeastAuthority-Cryptocat-audit-report.pdf
new file mode 100644
index 0000000..2c834ad
Binary files /dev/null and b/LeastAuthority/LeastAuthority-Cryptocat-audit-report.pdf differ
diff --git a/LeastAuthority/LeastAuthority-GlobaLeaks-audit-report.pdf b/LeastAuthority/LeastAuthority-GlobaLeaks-audit-report.pdf
new file mode 100644
index 0000000..ebc1d1e
Binary files /dev/null and b/LeastAuthority/LeastAuthority-GlobaLeaks-audit-report.pdf differ
diff --git a/Leviathan/SpiderOak-Crypton_pentest-Final_report_u.pdf b/Leviathan/SpiderOak-Crypton_pentest-Final_report_u.pdf
new file mode 100644
index 0000000..85b7c40
Binary files /dev/null and b/Leviathan/SpiderOak-Crypton_pentest-Final_report_u.pdf differ
diff --git a/Matasano/Matasano SourceT Security Evaluation Report.pdf b/Matasano/Matasano SourceT Security Evaluation Report.pdf
new file mode 100644
index 0000000..d281132
Binary files /dev/null and b/Matasano/Matasano SourceT Security Evaluation Report.pdf differ
diff --git a/Matasano/wp-multistore-security-analysis.pdf b/Matasano/wp-multistore-security-analysis.pdf
new file mode 100644
index 0000000..07893a7
Binary files /dev/null and b/Matasano/wp-multistore-security-analysis.pdf differ
diff --git a/OPM-OIG/OPM-OIG_-_US_Office_of_Personnel_Management.pdf b/OPM-OIG/OPM-OIG_-_US_Office_of_Personnel_Management.pdf
new file mode 100644
index 0000000..ff8bd00
Binary files /dev/null and b/OPM-OIG/OPM-OIG_-_US_Office_of_Personnel_Management.pdf differ
diff --git a/PrincetonUni/Princeton_University_-_Diebold_AccuVote-TS.pdf b/PrincetonUni/Princeton_University_-_Diebold_AccuVote-TS.pdf
new file mode 100644
index 0000000..aad04c5
Binary files /dev/null and b/PrincetonUni/Princeton_University_-_Diebold_AccuVote-TS.pdf differ
diff --git a/PrincetonUni/Princeton_University_-_Safeplug.pdf b/PrincetonUni/Princeton_University_-_Safeplug.pdf
new file mode 100644
index 0000000..1c0190a
Binary files /dev/null and b/PrincetonUni/Princeton_University_-_Safeplug.pdf differ
diff --git a/ProCheckUp/CHECK-1-2012.pdf b/ProCheckUp/CHECK-1-2012.pdf
new file mode 100644
index 0000000..07d14a9
Binary files /dev/null and b/ProCheckUp/CHECK-1-2012.pdf differ
diff --git a/PwC/PwC_-_HM_Revenue_and_Customs.pdf b/PwC/PwC_-_HM_Revenue_and_Customs.pdf
new file mode 100644
index 0000000..55c33a5
Binary files /dev/null and b/PwC/PwC_-_HM_Revenue_and_Customs.pdf differ
diff --git a/QuarksLab/14-03-022_ChatSecure-sec-assessment.pdf b/QuarksLab/14-03-022_ChatSecure-sec-assessment.pdf
new file mode 100644
index 0000000..cce772d
Binary files /dev/null and b/QuarksLab/14-03-022_ChatSecure-sec-assessment.pdf differ
diff --git a/README.md b/README.md
new file mode 100644
index 0000000..bcfb8d7
--- /dev/null
+++ b/README.md
@@ -0,0 +1,3 @@
+# Public penetration testing reports
+
+Curated list of public penetration testing reports released by several consulting firms.
diff --git a/Sakurity/Sakurity_-_Peatio.pdf b/Sakurity/Sakurity_-_Peatio.pdf
new file mode 100644
index 0000000..9959906
Binary files /dev/null and b/Sakurity/Sakurity_-_Peatio.pdf differ
diff --git a/TrailOfBits/Trail_of_Bits_-_Apple_iOS_4.pdf b/TrailOfBits/Trail_of_Bits_-_Apple_iOS_4.pdf
new file mode 100644
index 0000000..2999e29
Binary files /dev/null and b/TrailOfBits/Trail_of_Bits_-_Apple_iOS_4.pdf differ
diff --git a/UniWashington/UW-CSE-13-08-02.PDF b/UniWashington/UW-CSE-13-08-02.PDF
new file mode 100644
index 0000000..23f2355
Binary files /dev/null and b/UniWashington/UW-CSE-13-08-02.PDF differ
diff --git a/Veracode/Veracode_-_Cryptocat.pdf b/Veracode/Veracode_-_Cryptocat.pdf
new file mode 100644
index 0000000..f834288
Binary files /dev/null and b/Veracode/Veracode_-_Cryptocat.pdf differ
diff --git a/Veracode/Veracode_-_GlobaLeaks_and_Tor2web.pdf b/Veracode/Veracode_-_GlobaLeaks_and_Tor2web.pdf
new file mode 100644
index 0000000..76dd6b7
Binary files /dev/null and b/Veracode/Veracode_-_GlobaLeaks_and_Tor2web.pdf differ
diff --git a/iSEC/NCC_Group_-_Ricochet.pdf b/iSEC/NCC_Group_-_Ricochet.pdf
new file mode 100644
index 0000000..24d0fb5
Binary files /dev/null and b/iSEC/NCC_Group_-_Ricochet.pdf differ
diff --git a/iSEC/NCC_Group_-_phpMyAdmin.pdf b/iSEC/NCC_Group_-_phpMyAdmin.pdf
new file mode 100644
index 0000000..a05ccff
Binary files /dev/null and b/iSEC/NCC_Group_-_phpMyAdmin.pdf differ
diff --git a/iSEC/TrueCrypt_Phase_II_NCC_OCAP_final.pdf b/iSEC/TrueCrypt_Phase_II_NCC_OCAP_final.pdf
new file mode 100644
index 0000000..3153d62
Binary files /dev/null and b/iSEC/TrueCrypt_Phase_II_NCC_OCAP_final.pdf differ
diff --git a/iSEC/iSEC_Cryptocat_iOS.pdf b/iSEC/iSEC_Cryptocat_iOS.pdf
new file mode 100644
index 0000000..3e770b1
Binary files /dev/null and b/iSEC/iSEC_Cryptocat_iOS.pdf differ
diff --git a/iSEC/iSEC_Wikimedia.pdf b/iSEC/iSEC_Wikimedia.pdf
new file mode 100644
index 0000000..7af9903
Binary files /dev/null and b/iSEC/iSEC_Wikimedia.pdf differ
diff --git a/iSEC/iSec_Final_Open_Crypto_Audit_Project_TrueCrypt_Security_Assessment.pdf b/iSEC/iSec_Final_Open_Crypto_Audit_Project_TrueCrypt_Security_Assessment.pdf
new file mode 100644
index 0000000..7396a2a
Binary files /dev/null and b/iSEC/iSec_Final_Open_Crypto_Audit_Project_TrueCrypt_Security_Assessment.pdf differ
diff --git a/mnemonic/mnemonic_-_Norwegian_electronic_voting_system.pdf b/mnemonic/mnemonic_-_Norwegian_electronic_voting_system.pdf
new file mode 100644
index 0000000..580c4d4
Binary files /dev/null and b/mnemonic/mnemonic_-_Norwegian_electronic_voting_system.pdf differ