Anonymous user
Talk:Playfair cipher: Difference between revisions
m
added a forced table of contents.
(→Inadequate spec: new section) |
m (added a forced table of contents.) |
||
| (7 intermediate revisions by 4 users not shown) | |||
Line 1:
__TOC__
== Inadequate spec ==
How should one encode a sentence containing "xxx"? Or should the implementation crash for that case? --[[User:Rdm|Rdm]] ([[User talk:Rdm|talk]]) 05:04, 28 May 2014 (UTC)
-----
The REXX program handles these two examples (below) without problems.
Note the '''(''' [left parenthesis] is used to parse the plaintext from any specified options.
'''output''' when using the input of: <tt> ( I like XXX better than XX beer. </tt>
<pre>
old cipher key: Playfair example. ◄───using the default.
new cipher key: PLAYFIREXM
omit char: J
double char: X
original text: I like XXX better then XX beer.
cleansed text: IL IK EX XX BE TT ER TH EN XX BE ER
ILIKEXXXBETTERTHENXXBEER
encrypted text: RP BT XM MM MM DI WI VI IU DM QR MM DI MX EM
RPBTXMMMMMDIWIVIIUDMQRMMDIMXEM
plain text: IL IK EX XX XX BE TX TE RT HE NX XX BE XE RX
ILIKEXXXXXBETXTERTHENXXXBEXERX
possible text: IL IK EX XX BE TT ER TH EN XX BE ER
ILIKEXXXBETTERTHENXXBEER
original text: ILIKEXXXBETTERTHENXXBEER
════════════════Playfair encryption──► decryption──► encryption worked.
</pre>
'''output''' when the input is: <tt> (triple xxx is like, thirty, dude. No XXXX though. Bummer. </tt>
<pre>
old cipher key: Playfair example. ◄───using the default.
new cipher key: PLAYFIREXM
omit char: J
double char: X
original text: triple xxx is like, thirty, dude. No XXXX though. Bummer.
cleansed text: TR IP LE XX XI SL IK ET HI RT YD UD EN OX XX XT HO UG HB UM ME R
TRIPLEXXXISLIKETHIRTYDUDENOXXXXTHOUGHBUMMER
encrypted text: UI BI AR MM MM MR NF BT IV BM IU AG VC RO QE MM MM MM ZB NV HB CT IM IX EM
UIBIARMMMMMRNFBTIVBMIUAGVCROQEMMMMMMZBNVHBCTIMIXEM
plain text: TR IP LE XX XX XI SL IK ET HI RT YD UD EN OX XX XX XX TH OU GH BU MX ME RX
TRIPLEXXXXXISLIKETHIRTYDUDENOXXXXXXXTHOUGHBUMXMERX
possible text: TR IP LE XX XI SL IK ET HI RT YD UD EN OX XX XT HO UG HB UM ME R
TRIPLEXXXISLIKETHIRTYDUDENOXXXXTHOUGHBUMMER
original text: TRIPLEXXXISLIKETHIRTYDUDENOXXXXTHOUGHBUMMER
════════════════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)
| |||