miracle091/Picocrypt
miracle091
/
Picocrypt
mirror of https://github.com/HACKERALERT/Picocrypt.git
1
0
Fork 0
Code Releases Activity

Incorporate feedback from @samuel-lucas6

This commit is contained in:
Evan Su 2022-04-09 00:11:50 -04:00 committed by GitHub
parent 470ed17b3a
commit f7d2d8836b
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 13 additions and 12 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

25
Internals.md
View File

@ -1,25 +1,16 @@
# Internals # Internals
If you're wondering about how Picocrypt handles cryptography, you've come to the right place! This page contains the technical details about the cryptographic algorithms and parameters used, as well as how cryptographic values are stored in the header format. If you're wondering about how Picocrypt handles cryptography, you've come to the right place! This page contains the technical details about the cryptographic algorithms and parameters used, as well as how cryptographic values are stored in the header format.
**Note: This is a work in progress.**
# Core Cryptography # Core Cryptography
Picocrypt uses the following cryptographic primitives: Picocrypt uses the following cryptographic primitives:
- XChaCha20 (cascaded with Serpent in CTR mode for paranoid mode) - XChaCha20 (cascaded with Serpent in counter mode for paranoid mode)
- Keyed-BLAKE2b for normal mode, HMAC-SHA3 for paranoid mode (256-bit key, 512-bit digest) - Keyed-BLAKE2b for normal mode, HMAC-SHA3 for paranoid mode (256-bit key, 512-bit digest)
- HKDF-SHA3 for deriving a subkey for the MAC above, as well as a key for Serpent - HKDF-SHA3 for deriving a subkey for the MAC above, as well as a key for Serpent
- Argon2id: - Argon2id:
- Normal mode: 4 passes, 1 GiB memory, 4 threads - Normal mode: 4 passes, 1 GiB memory, 4 threads
- Paranoid mode: 8 passes, 1 GiB memory, 8 threads - Paranoid mode: 8 passes, 1 GiB memory, 8 threads
All primitives used are from the well-known golang.org/x/crypto module. All primitives used are from the well-known [golang.org/x/crypto](https://golang.org/x/crypto) module.
# Keyfile Design
Picocrypt allows the use of keyfiles as an additional form of authentication. Picocrypt's unique "Require correct order" feature enforces the user to drop keyfiles into the window in the exact same order as they did when encrypting, in order to decrypt the volume successfully. Here's how it works:
If "Require correct order" is not checked, Picocrypt will take the SHA3 hash of each file individually, and XORs the hashes together. Finally, the result is XORed to the master key. Because the XOR operation is both commutative and associative, the order in which the keyfiles hashes are XORed to each other doesn't matter - the end result is the same.
If "Require correct order" is checked, Picocrypt will combine (concatenate) the files together in the order they were dropped into the window, and take the SHA3 hash of the combined keyfiles. If the order is not correct, the keyfiles, when appended to each other, will result in a different file, and therefore a different hash. Thus, the correct order of keyfiles is required to successfully decrypt the volume.
# Header Format # Header Format
A Picocrypt volume's header is encoded with Reed-Solomon by default, since it is, after all, the most important part of the entire file. An encoded value will take up three times the size of the unencoded value. A Picocrypt volume's header is encoded with Reed-Solomon by default, since it is, after all, the most important part of the entire file. An encoded value will take up three times the size of the unencoded value.
@ -37,5 +28,15 @@ A Picocrypt volume's header is encoded with Reed-Solomon by default, since it is
| 237+3C | 72 | 24 | Nonce for XChaCha20 | 237+3C | 72 | 24 | Nonce for XChaCha20
| 309+3C | 192 | 64 | SHA3-512 of encryption key | 309+3C | 192 | 64 | SHA3-512 of encryption key
| 501+3C | 96 | 32 | Hash of keyfile key | 501+3C | 96 | 32 | Hash of keyfile key
| 597+3C | 192 | 64 | Message authentication code (BLAKE2b/HMAC-SHA3) | 597+3C | 192 | 64 | Authentication tag (BLAKE2b/HMAC-SHA3)
| 789+3C | | | Encrypted contents of input data | 789+3C | | | Encrypted contents of input data
# Keyfile Design
Picocrypt allows the use of keyfiles as an additional form of authentication. Picocrypt's unique "Require correct order" feature enforces the user to drop keyfiles into the window in the exact same order as they did when encrypting, in order to decrypt the volume successfully. Here's how it works:
If "Require correct order" is not checked, Picocrypt will take the SHA3 hash of each file individually, and XOR the hashes together. Finally, the result is XORed with the master key. Because the XOR operation is both commutative and associative, the order in which the keyfile hashes are XORed with each other doesn't matter - the end result is the same.
If "Require correct order" is checked, Picocrypt will concatenate the files together in the order they were dropped into the window and take the SHA3 hash of the combined keyfiles. If the order is not correct, the keyfiles, when appended to each other, will result in a different file, and therefore a different hash. Thus, the correct order of keyfiles is required to successfully decrypt the volume.
# Reed-Solomon
By default, all Picocrypt volume headers are encoded with Reed-Solomon to improve resiliency to bit rot, etc. The header uses N+2N encoding, where N is the size of a particular header field such as the version number or Argon2 salt. If Reed-Solomon is to be used with the input data itself, the data is encoded using 128+8 encoding, with the data being read in chunks of 1 MiB, and the final set padded to 128 bytes using PKCS#7.