I'm working on modernizing Rosetta Code's infrastructure. Starting with communications. Please accept this time-limited open invite to RC's Slack.. --Michael Mol (talk) 20:59, 30 May 2020 (UTC)

Talk:ADFGVX cipher

From Rosetta Code

Rows with fewer than key chars elements?[edit]

It doesn't seem to be spelled out specifically anywhere. How should we handle ending rows with fewer elements than the number of characters in the key word? If you look at the wikipedia page under "Operation" the keyword is CARGO (5 letters), the message has 12 letters, resulting in 24 elements. When the columns are rearranged, the R column [AFAFX] goes to the end, and the O column [AFAX] moves 1 space to the left. But the last element of the R column [X] gets shifted over to fill the gap; so now O is [AFAXX] and R is [AFAF].

I choose to follow the wikipedia example and shift to fill any gaps after rearranging columns. The order can be recovered by simply compressing the last row to the left after reshuffling. See the Raku example.

It is not strictly necessary to do so, but not doing it significantly weakens the effectiveness of the encryption. It is a strong hint to the relative order of the columns. --Thundergnat (talk) 17:43, 16 August 2021 (UTC)

There are two ways to proceed in this case. They are explained in the Wikipedia article which describes column transposition: https://en.wikipedia.org/wiki/Transposition_cipher#Columnar_transposition. We can fill the missing elements with random characters or accept to deal with incomplete columns. The Wikipedia example uses the second solution. This is also what I have done in the Nim solution. --lscrd (talk) 18:02, 16 August 2021 (UTC)
That is also what I have chosen to do; but I did it in a way that doesn't inherently weaken the encryption. Any incomplete rows are compressed left after shuffling; then, when reshuffling to decode, again, any incomplete rows ares compressed left. This removes any hint about which columns come earlier and which come later without needing to generate and remove noise filler characters. --Thundergnat (talk) 18:12, 16 August 2021 (UTC)
I quite like the first method (adding nulls) as this automatically makes all the columns the same length. The drawback is that on decryption you end up with some noise at the end of the plaintext and so have to hope that this doesn't spell anything meaningful. For this reason I decided not to use it.
Anyway, I've added a note to the task description to confirm that either method is acceptable.
--PureFox (talk) 20:32, 16 August 2021 (UTC)
With or without padding, it still weakens the encryption to reveal the key length with the spacing of the encoded message, and I think the Wikipedia example includes spaces to help the reader understand the method, but that does not mean that the actual messages contained that key-length-revealing-revealing spacing. The column sizes can be reconstructed from knowing the key and its length even without putting in spaces in the encrypted string.--Wherrera (talk) 22:51, 16 August 2021 (UTC)