evanrichter / cipher-project-1

Applied Cryptography Project 1

Hi there 👋

cipher-project-1's Issues

update ARCHITECTURE.md

need to explain the organization of src/cipher/ and src/utils.rs

ability to spell check a very close plaintext to perfectly plausible plaintext

since we know the exact wordlist used, we should be able to take a very close plaintext and use "spell checking" to correct the few words that don't quite match, to exact words found in the wordlist.

even better would be to do a few "spell checks", note what index from the key was used to correct, and try to apply that pattern to the rest, seeing if that helps more words match automatically. this technique would need to know info about the assumed keylength that was guessed in previous steps.

this function would be applied after #20, but can be developed and tested in parallel. For testing, use keys that are mostly zeros, for example: [ 0, 0, 0, 0, 0, 0, -2, 0, 0, 1, 0, 0 ] with a simple RepeatingKey schedule, to simulate a "close" plaintext. Also throw in a light PeriodicRand in some tests.

Implement the example encryption

In the project description, one possible method of encryption is given. We should implement this so we can verify we can crack it

Matthew Create Scheduling algo

Evan Create Scheduling algo

integer underflow in OffsetReverse

When rustc compiles in release mode, it removes checks for integer wrapping (underflow in this case):

cipher-project-1/src/ciphers/schedulers/offsetreverse.rs

Line 21 in 3ad690e

let inverted_index = last_char - (index % eff_key_length);

When this happens, the returned key index wraps around and is actually quite large, around 0xffffffffffffffff! This makes the encryptor pick a random char to insert instead, and thus makes the cracking more difficult than intended.

we can try usize::saturating_sub() to floor the subtraction result at 0, but I'm not sure that's what is intended.

Christian Create Scheduling algo

given keylength, crack ciphertext by "ranking" the plaintext output

after guessing key values, there needs to be a way to figure out the best candidates for true key value.

we have access to the dictionary of plaintext words, so we can use character frequency with either strategy:

• just read every word from the dict and get a frequency. simple, words are sampled randomly so should be representative
• take the dict and build a plaintext of 10,000 words or so. then take character frequency of that

have a way to see how "close" a string of characters is to the expected character frequency distribution

generate code coverage in CI

Define a "Scheduler" trait

all key scheduling algorithms take the same inputs and produce the same type of output, so it should be a trait.

then any cipher can use any key scheduler by calling the trait function

or maybe this could just be a function type

confirm keylength guessing with randomized tests

keylength guessing works most of the time but that's not good enough.

In the tests that pass, the correct keylength or multiple of the keylength appears in the top 5 results, out of 70 or so key lengths guessed.

There seems to be an issue where longer keys are slightly favored over shorter keys, so I need to adjust the chunked hamming distance weights and penalize keylength a little bit.

Alex Create Scheduling algo