Rail fence decode does not appear to work as expected

[alblue]

Describe the bug

Text created with the 'Rail Fence Encode' does not appear to be decodable with 'Rail Fence Decode' with the same key and offset.

To Reproduce

Click on https://gchq.github.io/CyberChef/#recipe=Rail_Fence_Cipher_Encode(3,0)Rail_Fence_Cipher_Decode(3,0)&input=Sm9sbHlCcm9rZW4 to load it in the simulator, or alternatively:

1. Add a Rail Fence Encode with key 3 and offset 0
2. Add a Rail Fence Decode with key 3 and offset 0
3. Enter "JollyBroken" into the encode
4. The output does not contain "JollyBroken" but rather "JorlyBnoke l"

Expected behaviour

When using the same cipher to encode and decode data, I would expect to see the plaintext in the result unchanged.

Screenshots

Additional context
Taken on the version on the website at time of raising bug,

Version 9.21.4
Compile time: 22/01/2021 19:00:54 UTC

[alblue]

What's odd is that the input length is 11; if the decode is a key length of 2 then the length is 11, but if the key length is 3 then the decode length is 12 and an extra space appears.

If I use "JollyBroken " with a space afterwards, the encode/decode works as expected.

[mt3571]

Could #1069 be related to your problem? If so, there is a pull request in to fix that so if you are building locally you could try and apply those changes 🙂 #1108 may also be related

[alblue]

It’s the same issue as #1108 but I don’t know that #1069 will solve the problem. When encoding “JollyBroken” it gets displayed as “JykolBoelrn” with no spaces, but although the output of encode says “Length: 11” for the text, it also says “Length: 12” for the output of the cipher, which I suspect is where the space is coming from.

Simply deleting spaces isn’t going to fix the problem — if you type “JykolBoelrn” (no spaces) into a Rail Fence decode with key 3, it produces the incorrect output whether or to the space is there in the output. The issue seems to be that the decode is ‘rounding up’ the length of the string (11) to the nearest multiple of the key (12) which then affects the algorithm.

Using a Rail Fence Encode with key 3 and “JollyBroken” and piping the output to hexdump shows that the output generated by the Encode isn’t adding any additional spaces to the output, so stripping the spaces in the encode isn’t going to fix a problem. Similarly, the output claimed by the Encode is 11 (same as input) so there’s no spaces being introduced there.

https://gchq.github.io/CyberChef/#recipe=Rail_Fence_Cipher_Encode(3,0)Rail_Fence_Cipher_Decode(3,0/disabled)To_Hexdump(16,false,false)&input=Sm9sbHlCcm9rZW4

The problem appears to be that the Rail Fence Decode rounds up the length to the nearest multiple of the key, and that introduces the space into the mix,.

[mt3571]

I have just run #1071 (the PR associated with #1069) against this example and it works. The PR is removing the rounding in the decode operation and so no additional spaces are being introduced, so the right output is achieved. Please let me know if you find any examples that this doesn't fix! 🙂

[alblue]

Yup, looks like #1071 will fix this issue as well.

[alblue]

BTW this came up because one of the questions in https://www.ncsc.gov.uk/cyberfirst/girls-competition uses a rail fence encoding and my daughter found this issue in CyberChef. Reproduced here with a different example so as not to give the game away :)

[n1474335]

This should be closed by #1071

[alblue]

This works now on the website as of the build an hour ago