Talk:Playfair cipher

Inadequate spec

How should one encode a sentence containing "xxx"? Or should the implementation crash for that case? --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: ( I like XXX better than XX beer.

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.

output when the input is: (triple xxx is like, thirty, dude. No XXXX though. Bummer.

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.

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. --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. -- 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 . --Tikkanz (talk) 06:28, 20 March 2021 (UTC)