| CARVIEW |
Navigation Menu
-
Notifications
You must be signed in to change notification settings - Fork 6
The Krypton Cipher
Krypton is a symmetric cipher based on AES-256. It employs an additional step of obfuscating the plaintext by XOR-ing it with the output of a keyed cSHAKE256 hash function before encrypting the produced intermediary text with AES-256 in EAX mode to produce the final ciphertext. Once data encryption has finished, Krypton encrypts the nonce and the authentication tag of the data cipher with AES-256 in deterministic SIV mode acting as a key wrapper, producing an encrypted verification data packet. Krypton can facilitate automatic padding of input plaintext to a specified chunk size, if chunked processing has been enabled, which is useful for encrypting large files.
- Employed to create a bytestream that, through XOR operation, masks the plaintext prior to AES encryption. This preliminary step which occurrs before encrypting data with AES-256 in EAX mode introduces an extra security layer by obscuring the plaintext, thereby enhancing the difficulty for adversaries in attempting to recover the original plaintext. This additional step was introduced as a backup security measure in case news should break that AES-256 has been broken.
Note: The use of cSHAKE256 to mask plaintext before encryption introduces a novel approach to enhancing security. While this step adds complexity to potential plaintext recovery efforts, it's important to note that the specific security benefits of this masking technique have not been extensively tested within the cryptographic community. As such, while it contributes to Krypton's layered security model, its effectiveness as an encryption layer per se cannot be definitively claimed yet due to lack of research on the topic.
- Used for generating the final ciphertext of data that has previously been masked using cSHAKE256. Krypton uses EAX mode over GCM mode for data encryption, because it has higher tolerance for nonce misuse, suitability for a wide range of systems without specialized hardware, and enhanced security and error handling capabilities, making it a versatile choice for various cryptographic applications.
- Employed for encrypting the nonce and authentication tag generated by the data encryption process (AES-256 in EAX mode). SIV mode is chosen for its resilience to nonce reuse, operating in a deterministic mode that is influenced by the SHA3 hash of the context with which Krypton is initialized. This ensures the security of the data cipher metadata, increasing the effort required by an adversary to break the data encryption.
- Converts the initial 64-byte secret key into three distinct keys using KMAC256. These keys are utilized for:
- Keying the cSHAKE256 bytestream generator for masking the plaintext before encrypting it with the data cipher.
- Keying the AES-256 cipher in EAX mode for data encryption after the data has been masked with cSHAKE256.
- Keying the AES-256 cipher in SIV mode for encrypting the nonce and authentication tag of the data cipher.
An adversary who has access to the data ciphertext and the encrypted verification data packet, has the following knowledge:
- No knowledge of the 64 byte master secret key, which was used to key the KMAC-KDF algorithm.
- Knowledge of the 64 byte salt that was used to randomize the output of the KMAC-KDF algorithm.
- Knowledge of the plaintext auth tag of the key wrapper AES-256 cipher in SIV mode.
- Knowledge of the data ciphertext, which was produced by AES-256 cipher in EAX mode.
- Knowledge of the encrypted nonce and auth tag of the data cipher.
Given this knowledge, the adversary must have the ability to break AES-256 in SIV mode, AES-256 in EAX mode, and the SHA3-based cSHAKE256 hash function in order to successfully retrieve the correct plaintext without having access to the master secret key. Because Krypton requires a 64 byte (512 bits) master key, there are approximately 1.34*10^154 combinations of keys that Krypton can be initialized with, making brute-forcing a Krypton ciphertext an insurmountable task.
As per the NIST requirement for algorithm candidates to the Post-Quantum Cryptography standardization process, all Key Encapsulation Mechanism algorithms must output their shared secrets as 32 bytes (256 bits) long, even if the algorithm is capable of producing longer shared secrets. As you might have imagined, this produces a disconnect between the length of the KEM shared secrets and the secret key length expected by the Krypton cipher.
The solution is to transform 32-byte KEM shared secrets with Argon2 KDF into 64-byte secret keys using a memory cost of at least 1 GB. This results in about 1.158*10^77 GB of memory which will be required in total to brute-force all possible combinations of 32-byte input keys, which is an astronomically unattainable amount of RAM memory. QuantCrypt uses 1GB of memory cost for Argon2 in the KryptonKEM class by default, which introduces about 0.25 seconds of delay into the cipher process. When deriving secret keys from low-entropy sources like user passwords, such low delay would be unacceptable. Because KEM shared secrets are high-entropy and may have 2^256 combinations, the lower delay in this context does not impact the security factor of the Argon2 function in a relevant amount. It is also possible to override the default Argon2 security parameters of the KryptonKEM class.
Note: You can extend 32-byte keys into 64-byte keys using regular hash functions like SHA3-512, but doing so does not introduce any significant cost factor into the key derivation process and therefore is not recommended, as it would reduce the security of the Krypton cipher to 32-byte key lengths. If you want to use a symmetric cipher which uses 32-byte secret keys, you might as well use raw AES-256 directly without the Krypton overhead.