nostandard/cyphers

Pure Rust implementation of classical ciphers (for fun and learning!)

cyphers's Issues

Playfair cipher: Issues in current implementation

1. Input Validation Attacks:

• Since the implementation does not validate the characters in the keyword string (other than deduplicating and removing characters not in the alphabet), it might be susceptible to attacks where an invalid keyword is used to create a matrix that doesn't function correctly.

2. Panic Conditions:

• If there are conditions under which the program could panic (like array index out of bounds), an attacker might be able to craft inputs that cause the program to crash, creating a Denial-of-Service (DoS) condition. Thus, we need to ensure that the program does not panic under any circumstances to prevent such potential DoS attacks. One such solution is a robust error handling.

Caesar cipher: Issues in current implementation

1. Parameter Tampering:

• Depending on how the key parameter is handled in our application, an attacker might manipulate the key input to gain unauthorised access or information.

2. Side-Channel Attacks:

• These involve gathering information from the physical implementation of the cipher, such as timing attacks, where an attacker could infer data based on the time it takes to perform encryption or decryption.

3. Error Handling:

• If errors or panics are not handled properly in the larger application that uses this library, it might reveal information that can be exploited or used to crash the application.

4. Code Injection:

• If user inputs are not validated and sanitized properly in the larger application, it might be possible to execute a code injection attack, though Rust's strong type system generally makes this difficult.

Affine cipher: Issues in current implementation

1. Input Validation:

• Currently, the program does not check whether the a key is co-prime with 26. If a is not co-prime with 26, the decryption will fail, as a modular inverse will not exist. An attacker can use this to cause denial of service by providing keys that don't have modular inverses, causing the decryption function to fail. This is not exactly an attack to break the cipher, but an exploitation of a weakness in the implementation to possibly cause service disruptions.

2. Timing Attack:

• Though somewhat theoretical and less practical in this context, attackers might attempt to use the timing information (how long it takes to encrypt or decrypt a message) to find information about the keys, especially since the modular inverse function uses a loop that can take different amounts of time depending on the input.

To mitigate these two attack vectors, we might consider adding more robust input validation (such as checking whether a is co-prime with 26) and possibly considering ways to make the encryption and decryption times more consistent to prevent timing attacks.

Vigenère cipher: Issues in current implementation

1. Input Validation Vulnerability:

• The prepare_string function is not called within the encrypt and decrypt functions. As such, these functions will not handle non-alphabetic characters and mixed case inputs correctly. This could potentially be used to introduce invalid characters into the encrypted text or to cause errors in decryption.

2. Error Handling:

• The use of unwrap_or_default() and unwrap_or() could potentially mask errors that occur during encryption and decryption, making the implementation less robust against malformed inputs or other unexpected conditions.

3. Key Length Attack:

• Since the extend_key function simply repeats the key to match the length of the plaintext, a short key might make the cipher more susceptible to attacks as it effectively reduces the cipher to a set of repeated Caesar ciphers.

4. Denial of Service (DoS):

• The current implementation does not have protections against excessively large inputs, which could be used to perform a denial-of-service attack by causing the program to consume large amounts of memory or CPU time.

5. Timing Attack:

• As with many cryptographic implementations, this code might be susceptible to timing attacks where an attacker measures the time taken to encrypt or decrypt messages to gather information about the key.

To make the implementation more secure and robust, we must introduce additional input validation, custom error handling, and possibly rate-limiting to prevent abuse. We must also explore ways to make the key generation more secure and to prevent potential timing attacks.

ROT13 cipher: Issues in current implementation

The current implementation is quite solid and doesn't seem to have any particular vulnerabilities intrinsic to the algorithm or code. However, one could consider potential attacks not on the cipher logic itself, but on how the program interacts with its environment or handles input. Here are some considerations:

1. Input Handling:

• In the future, if we add more features, we must ensure that inputs are validated properly to avoid issues like buffer overflow or injection attacks.

2. Error Handling:

• As of now, the program doesn't have proper custom error handling. In a more comprehensive application, lack of error handling could potentially be exploited or result in unexpected behaviour.

Polybius Square cipher: Issues in current implementation

1. Input Validation: The clean_input helper function only considers alphabets and spaces as valid inputs, discarding others. This means messages containing numbers or special characters can't be encrypted or decrypted correctly, which might be used as an attack vector to feed malicious inputs.

2. Error Handling: The implementation uses Option to handle errors, returning None when encountering an error. A more detailed error handling is desired.

3. Unicode Support: The implementation currently does not handle Unicode characters well, which might be exploited in various ways, including bypassing input validation or creating unexpected outputs.

One-Time Pad (OTP): Issues in current implementation

1. Panic Conditions:

• The program panics if the key and the plaintext/ciphertext lengths do not match. An attacker might exploit this to cause denial of service by crafting inputs that trigger panics.

2. Error Handling:

• Lack of proper error handling can potentially leak information about the plaintext or key. For instance, by returning an error instead of panicking when lengths do not match, we could prevent potential denial of service attacks.

3. Key Generation:

• If there are any weaknesses in the rand::rngs::OsRng random number generator used for key generation, these could potentially be exploited to predict keys.

4. Memory Safety:

• The unsafe block in the testing section (String::from_utf8_unchecked) could potentially lead to undefined behaviour if misused. While it seems safe in our current test setup, in a larger codebase or with modifications, it might introduce vulnerabilities.

5. Key Transmission and Storage:

• While not explicitly part of our implementation, the transmission and storage of keys are critical points of vulnerability. If keys are not transmitted and stored securely, they could be intercepted or accessed by attackers.

6. Chosen Plaintext or Ciphertext Attack:

• If an attacker can somehow influence or choose the plaintexts or ciphertexts, they might be able to exploit this to learn information about the key or other plaintexts.

7. Side-Channel Attacks:

• While not a flaw in the algorithm itself, attackers might exploit side channels (like timing information, power consumption, etc.) to learn information about the key or plaintext.

Annotate public APIs with examples

Add example usage for all encrypt and decrypt functions.