Anonymous user
Talk:Playfair cipher: Difference between revisions
m
added a forced table of contents.
(added a couple of REXX examples that handle multiple Xes in the plain text.) |
m (added a forced table of contents.) |
||
| (6 intermediate revisions by 4 users not shown) | |||
Line 1:
__TOC__
== Inadequate spec ==
Line 55 ⟶ 57:
════════════════Playfair encryption──► decryption──► encryption worked.
</pre>
::Of course this kind of thing is doable. But it's also unspecified behavior. I adopted something which I felt was closer to the spirit of the spec, for the J implementation, mangling some repeated X's in the process. Here's how that looks using your test cases:
::<lang J> choose 'IJ'
setkey 'playfirexm'
encrypt 'I like XXX better than XX beer.'
RPBTXMGWDIWIXEZBLOGWDIXE
decrypt encrypt 'I like XXX better than XX beer.'
ILIKEXXQBETXERTHANXQBEER
encrypt 'triple xxx is like, thirty, dude. No XXXX though. Bummer.'
UIBIARGWMRNFBTIVBMIUAGVCROQEGWIWDSWCBCZRIXEM
decrypt encrypt 'triple xxx is like, thirty, dude. No XXXX though. Bummer.'
TRIPLEXQXISLIKETHIRTYDUDENOXXQXTHOUGHBUMMERX</lang>
::I'm not saying that this is right, nor that yours is wrong. I am saying that the spec is not clear about how to handle this case. --[[User:Rdm|Rdm]] ([[User talk:Rdm|talk]]) 18:57, 28 May 2014 (UTC)
::: Right or wrong, the REXX version does encrypt/decrypt the above two messages correctly. It's not 100% successful in handling all cases that contain replicated characters however. As to the specs, yes, I agree, it's rather fuzzy, especially about the part that states "... dropping any extra "X"es, or "Q"s that do not make sense in the final message... That's pretty hard to do programmatically. -- [[User:Gerard Schildberger|Gerard Schildberger]] ([[User talk:Gerard Schildberger|talk]]) 19:22, 28 May 2014 (UTC)
== Disagreement about the way to process duplicate letters ==
It seems that there is two ways to interpret the specification.
Let’s choose some text with duplicate letters starting at an odd position, for instance “A TREE”.
As I understand the specification, the text ATREE should be successively decomposed in digrams, i.e. AT TR E and, as the last digram is incomplete, we add an X. So we have to encode AT TR EX with the table.
But some solutions have interpreted the specification another way. They process the whole text, searching for duplicates and inserting an X when found one. This way, the text becomes, when decomposed in digrams afterward, AT RE XE.
I think that the first interpretation is the right one but somewhat less easy to implement as we have to split in digrams a first time to add the X when necessary.
I have not checked all the solutions, but, for instance, the Java solution has chosen the first interpretation while the FreeBASIC solution has chosen the second interpretation. It doesn’t matter with the example “Hide the gold in...the TREESTUMP!!!!” as the duplicate appears at an even position. But in other cases, the result will be different.
:My understanding differs a little from yours. Using ATREE as an example: First digraph is 'AT' (no problem), 2nd digraph is 'RE' (not TR as above), The 3rd digraph (E) is incomplete as suggested, so X is added. So the text to encrypt is: AT RE EX
:If the original text was ATTREE: First digraph is 'AT' (no problem), 2nd digraph is 'TR' (no problem), The 3rd digraph (EE) needs to be split so an X is inserted in the string and the digraph becomes 'EX'. That leaves a singleton E again which needs an X added to complete it. So the text to encrypt is: AT TR EX EX . --[[User:Tikkanz|Tikkanz]] ([[User talk:Tikkanz|talk]]) 06:28, 20 March 2021 (UTC)
| |||