Closed avastmick closed 6 years ago
Is there any particular reason as to why we've decided with the 'null chars' wording? To me, it seems much more intuitive to call them 'padding characters' (e.g. pad_char
). Also, if it is a character, why are we passing it in as a string to the CT
/ADFGVX
constructor?
Why am I calling it null
chars, instead of padding
, or pad
chars?
When I did some research, that is what the cryptographical community term these extraneous characters. They are irrelevant characters, that only aide in processing the cipher, they are, null
with respect to the message meaning.
In all cases, the padding was termed nulls
so I went with that...
Thanks for the clarification. If thats the consensus then we will go with that.
This commit provides a fix for Issue #30 by providing support for
null
chars. As per issue comments, support fornull
chars is common in the implementations of theADFGVX
andColumnar Transposition
ciphers. See Wikipedia entry on CT, for example.I have increased the params for both
ColumnarTransposition
andADFGVX
to allow the passing of anull
char. Thenull
char may be anything but will error if the char exists in thekeyword
.Using whitespace
' '
, is allowed, however, it will mean the ciphers behave as per crate version0.11.0
, and the original problem of potentially trailing whitespace in the ciphertext persists. SeeADFGVX
test for both encrypt and decrypt using whitespace nulls:These tests show that the ciphertext trailing space problem persists when using whitespace nulls, but can be now avoided, by using either no nulls
String::from("")
, or using a different padding null char, such as\u{0}
.I have incremented the crate version to
0.12.0
as there are a fair amount of changes, including how theADFGVX
andColumnarTransposition
ciphers are initialised.