arosspope / cipher-crypt Goto Github PK

This shift rule does not correctly handle cases where the usize index into the vector will overflow negative upon subtraction.

Example code that replicates the issue:

extern crate cipher_crypt;
use cipher_crypt::{Cipher, Playfair};

fn main() {
    let c = Playfair::new("APT".to_string()).unwrap();
    let pt = "Hello World";

    let ct = c.encrypt(pt).unwrap();
    let _d = c.decrypt(&ct).unwrap();
}

The patch to fix this is ready. It includes a unit test for this condition. I can push to the same cipher/playfair branch and increment to 0.14.1 if that works, @arosspope .

I think it will be useful to have a "common" function to generate a scrambled alphabet from a key. e.g. for a key of alphabet you would get an alphabet of alphbetcdfgijkmnoqrsuvwxyz. This could be used with several of the ciphers in the README.

PR #35 introduced the use of the lipsum crate. This works well and avoids the Baconian code bloating with boilerplate text constants.

However, currently, the usage is rather blunt, inelegant, as simply assigns lipsum text of an arbitrary 160 char length that may break if the plaintext is over ~50 chars in length.

Desired functionality: is that the default decoy text (generated using the lipsum crate) would automatically size to the length of the plaintext passed into the encrypt function.

Currently, the creation of the polybius square in keygen is not great.

The Hill cipher is a polygraphic substitution cipher based on linear algebra.

I was thinking of implementing this. Two things:

• Having a file/struct name like FractionatedMorse seems a bit long. Would something like FracMorse be preferable or should i spell it out in full.
• Should I include encoding of numbers? It would mean a new alphabet and a new set of access functions.

Implement the Porta cipher as described in http://www.practicalcryptography.com/ciphers/porta-cipher/.

This solves part of #2.

The current implementation of the Columnar Transposition cipher pads uneven columns with whitespace ' ' to make sure that the resulting columns are easier to handle on decryption.

loop {
       if let Some(c) = chars.next() {
            key[i].1.push(c);
        } else if i > 0 {
            // This can cause issues ->
            key[i].1.push(' '); //We must add padding characters
        } else {
            break;
        }

This is is a good idea and makes the code much simpler for decrypt, however, in some cases the pad comes on the final transposed column and the whitespace may exist at the end of the encrypted text.

See the implementation for the ADFGVX cipher and the tests, where there is a trailing whitespace char. Kept in to ensure there is a viable fix created.

I suggest that the ColumnarTransposition code is changed to remove the whitespace padding and handle the code complexity in the decrypt function.

As an example, see pycipher/columnartransposition.py for an implementation that manages this. However, note that this implementation also removes all non-alphanumeric chars when encoding. Not sure this is ideal, as it seems to lose niceties, but may be worth a look on how to handle the uneven columns.

Determine ciphers to implement. The list is currently:

• Caesar
• Vigenere
• ROT13
  . . .

I feel like the manner in which the alphabet array is being accessed is unsafe.
Would much prefer access to be performed through functions that return errs - rather than panicking when we encounter an out of bounds error (for example)

Very similar to the Vigenere cipher, but uses a different method of generating the key.

As per Issue #30 - ensure that the ciphertext of the scytale cipher doesn't contain trailing whitespace characters.

Time is a bit tight, but will use this issue to work against.

The current implementation of the encrypt and decrypt traits don't allow for an error to be returned. I'd be happy to implement this.

Cargo.toml requires num = "^0.1", which pulls an old num_bigint with a dependency on rustc_serialize, which is deprecated. Suggest change of dependency to num = "^0.4"