### EVRYTHING YOU WANTED TO KNOW ABOUT EUROCRYPT

### BUT WERE AFRAID NOBODY WOULD TELL YOU

    BY JOHN MACDONALD

    This file contains everything I know about the Eurocrypt TV scrambling
    system. I have built this knowledge up from scratch by reading articles
    (very few and far between), disassembling PIC programs and then working out
    what they do (interesting) and watching decoder<->card traffic using a
    season-type PC interface (lots of tripping over cables and running between
    rooms). Its not complete, but there's more in it than I've seen anywhere else.

    I have written this for two reasons:

    	1 If any of this is new to you, I hope you find it useful,
    	  enjoyable and instructive.

    	2 If you know more than this, please share it with me and I
    	  will update/correct this to form what will hopefully become
    	  a definitive document on the subject.

    You can contact me on the BBS where you found this file.

    I'll describe the DC<->card protocol, what each instruction does, and how
    the DES-based decryption algorithm works for Eurocrypt M and S2. Unless
    specified, all numbers are in hex.

    The Decoder<->Card Protocol

    When you insert the card into the DC the DC sends a signal down the reset
    line as per the ISO 7816 standard and waits for the card to respond. The
    card sends an answer-to-reset sequence of bytes (ATR) which tells the DC
    information about the behaviour of the card itself, such as transmission
    parameters, manufacturing details etc.

    For Eurocrypt, the ATR seems to be the 9 byte sequence

    	3f 67 2f 00 11 14 00 03 68

    For anyone who is interested in the nitty-gritty of this, there's a very
    good explanation in a file called atr.zip written by JC, available on BBSs
    and the web.

    The ISO standard defines that the DC addresses the card by sending a 5 byte
    header to it containing:

    	INSTRUCTION CLASS
    	INSTRUCTION CODE
    	followed by 3 parameters usually called P1, P2, P3.

    The instruction class is either 87 or ca and can be ignored (I'm not sure
    of its significance) and the P3 byte is usually a length byte denoting the
    number of bytes to follow or the number of bytes expected to be received
    by the DC.

    How the card behaves depends upon the values of the 5 byte header, but it
    usually sends at some point a 2 byte message called SW1, SW2. This is 90 00
    meaning the instruction in the header executed OK or 90 08 meaning there
    was some kind of error. This SW1, SW2 message is also sent at the end of the
    ATR.

    Instruction Processing

    INSTRUCTION 02

    After receiving the ATR, the DC sends instruction 02 as:

    	87 02 00 00 03

    The 02 instruction seems to be sending 3 bytes to the card - what these mean
    I've no idea. So to process an 02 instruction, if P3<>0 send 02 to the DC
    as an acknowledgement, then get P3 bytes (3 in the example). If any of these
    bytes are 40 then send 90 08, else send 90 00.

    INSTRUCTION 04

    Next the DC sends a packet like

    	87 04 00 00 07

    The 04 instruction is requesting some result from the card following the 02
    instruction. So first acknowledge by sending 04 (if P3<>0). All the PIC code
    I've looked at sends a fixed message

    	00 15 00 00 followed by 3 padding bytes such as ff

    I don't know what this means. Finally, 90 00 is sent.

    INSTRUCTION 06

    The DC then sends

    	87 06 00 00 04

    which is asking for a block of data from the card. Again, all the PIC
    programs send

    	10 02 ca 20 ff

    followed by 90 00.

    I guess this sequence of 02, 04, 06 is some kind of authentication of the
    card and the fixed sequences give the right answers.

    From here on in the instruction class changes to ca.

    INSTRUCTION A4

    The a4 instruction is used to give the card information about the channel's
    identity which is used by the card for key selection, expiry data,
    entitlements, parental control and pay-per-view (PPV) controls. There are
    several forms of this instruction - we'll concentrate on the form for
    channel identification and come back to the others later.

    The DC sends

    	ca a4 04 00 03

    which tells the card that 3 bytes are to be received which indicate the
    channel's id. So since P3<>0 (3 in this case) send a4 to the DC then
    receive the three bytes. Then send 90 00. I think that if you send 90 08
    the DC displays the 'no access' message but I haven't tested this.

    Actually the 3 bytes can identify a channel or a group of channels -
    for example, all the TV3s are 00 04 00 and CANAL+ is 10 00 20. Card programs
    typically use this data to construct a byte between 1 and n where n is
    the number of ids supported by the card. We'll call this byte CHAN# and use
    it later on.

    INSTRUCTION 88

    Immediately after the a4 instruction the DC sends a packet like

    	ca 88 00 08 24

    88 instruction processing is the main decoding work done by the card
    protocol handler. The P2 byte (08 in the example) is the key number to be
    used to decode the encrypted data obtained shortly. Each channel has a
    number of 7 byte keys which are used in the decryption and this byte defines
    which one is to be used. If the card doesn't have this key stored in its
    memory then no decryption can occur! The P3 byte indicates the number of
    bytes to be received by the card, in this example hex 24 ie decimal 36.
    In the 24 byte string are two encrypted 8 byte words which have to be
    decrypted using the 7 byte key. Obviously, the P2 and P3 values vary from
    channel to channel and time to time.

    The card must send 77 to the DC in order to receive one of the P3 (24) bytes.
    It must do this repetitively until there are 8 bytes left, then it must send
    89 and receive the last 8 bytes directly. Finally the card sends 90 00.

    A typical string obtained in this way would be (broken in to substrings for
    readibility)

    	df 00
    	e1 04 20 21 ff 7f
    	ea 10 ca a8 e2 1b 4b 7b db 66 8c 29 0a 3b 32 4d 61 5f
    	f0 08 8a 18 2d 8b 91 e2 cd 84

    Byte 2 always seems to be zero, and the 4th byte indicates the length of the
    next substring and I think is always 4 though I haven't checked this
    exhaustively. Bytes 5 and 6 represent a date with the first 7 bits being
    the year from 1980, the next 4 bits the month and the last 5 the day of
    the month. So the date shown (20 21) is year 0010000 or decimal 16,
    month 0001 or 1, and day 00001 or 1 ie January 1 1996. Bytes 7 and 8 are
    theme and level.

    The substring beginning ea contains a length byte (10 or decimal 16)
    followed by 2 8 byte words. These are the 2 encrypted words which have
    to be decrypted into 2 8 byte plain words by the card using the 7 byte key
    defined in the 88 packet for the channel defined in the preceding A4
    instruction. I'll explain how this is done later.

    The substring beginning f0 contains a length byte (08) followed by 8 bytes.
    This is some kind of checksum which is compared with another bit of
    decryption to verify the result, but I'm not sure of the details.

    There are variations on this string which cause lots of complexity in the
    PIC code I've examined, but basically the idea is straightforward.

    INSTRUCTION C0

    Immediately after the exchange described in the last section the DC sends
    the following packet

    	ca c0 00 00 12

    This instruction is asking the card to send the two plain words to the DC
    and if these are correct, the picture is unscrambled. (Hooray!)

    The card should first send c0 acknowledging the instruction then ea 10,
    followed by the 10 (decimal 16) bytes of plain data. This equates to the
    12 bytes requested in P3.

    I have seen another form of the c0 instruction, namely

    	ca c0 00 00 06

    From examination of PIC code it seems that this instruction is asking the
    card to send the 3 bytes of channel identification (obtained via the a4 04
    instruction) followed by 20 00 8f. I don't know what these last 3 bytes mean.

    INSTRUCTION 18

    Some of you may wonder how the auto-update feature on twin PIC cards works,
    where (usually once a month) the card can deduce what the new key is for
    CANAL+ and Cine Cinemas. Well, this is where the 18 instruction comes in.

    Prominent in the DC<->card traffic for these channels is a packet like

    	ca 18 00 06 29

    The P2 byte (06 in the example) is the key number to be used to decode the
    encrypted data obtained shortly in order to obtain the new key. If the
    card doesn't have this key stored in its memory then no decryption can occur
    and the auto-update won't work. For a reason I don't know, CANAL+ and Cine
    Cinemas use keys 05 and 06 only for this purpose. Therefore in all the PIC
    programs I've examined, these keys are present with space in the EEPROM for
    the new keys when they've been found.

    The P3 byte indicates the number of bytes to be received by the card, in
    this example hex 29 ie decimal 41.
    In the 29 byte string is an encrypted 8 byte word which has to be decrypted
    using the 7 byte 06 key. The result of this operation is an 8 byte plain
    word of which the first 7 bytes are the new key.

    Obviously, the P2 and P3 values vary from channel to channel and time to time.

    The string of length P3 (29 in the example) is obtained in exactly the same
    way as for instruction 88 except that e7 is used instead of 77 to get a
    byte from the DC and 19 is used instead of 89 to get the last 8 bytes.

    A typical string obtained in this way would be (broken into substrings
    for readibility)

    	a0 01 22
    	a1 03 10 00 36
    	a8 06 20 31 20 36 ff ff
    	a1 03 10 00 39
    	ef 08 14 c4 cb d7 2c 16 1a f2
    	f0 08 aa fa 7f c8 b2 65 db 4a

    Byte 2 is the length of the first substring- I don't know the significance
    of this. Byte 5 is the length of the second substring which contains the
    channel id bytes (10 00 30 for Cine Cinemas) concatenated with the base key
    to be used (06 in this case). The next substring is preceded by type and
    length bytes followed by what look like 2 dates (17th and 22nd Jan 1996)
    followed by either theme and level bytes or just ff padding.

    The fourth substring is similar to the second except that it contains the
    number of the new key to be obtained (09 in the example). The fifth
    substring (after the type and length bytes) is a 8 byte encrypted word.
    When this is fed through the decryption algorithm (see later) with the base
    key (06) a 8 byte plain word is obtained, the first 7 bytes of which are
    the new key (09).

    Given the foregoing, I can't see the need for a touch pad on the twin PIC
    card, since the program can find the new key for itself when necessary -
    perhaps someone can enlighten me.

    The last substring is a checksum as per the 88 instruction.

    Again there are variations in the number and length of substrings which
    can appear, and most of the complexity (and amateurish code) in the PIC
    programs I've seen is trying to cope with all the variations of 18 and
    88 substrings with one piece of code. There must be lots of simple ECMs
    which would break this code very easily.

    REMOTE CONTROL INTERFACE

    There are some instructions which are only used when the remote control is
    used (on mine its a PPV button) for display, parental lock, consultation
    and PPV purposes. The exact display format of these depends on the DC used,
    but this section describes how the DC<->traffic works. Of course if you're
    only interested in decryption you don't need to implement any of this.

    The instructions used are AC, B8, 24 and two variations of the A4 instruction.
    The P1 parameter varies in these instructions and acts as a sub-instruction.

    I'm going to assume that the card sends the instruction to the DC whenever
    P3<>0 as an acknowledgement and that it terminates with 90 00 as before.

    PPV (or whatever its called on your handset)

    When you ask for a display via the handset the decoder sends the following
    packets

    	ca a4 00 00 00
    	ca ac 08 00 00
    	ca b8 00 00 03

    Remember CHANN# described when we discussed the a4 04 instruction? Well, the
    a4 00 instruction tells the card to zeroise this number. The ac 08
    instruction tells the card to select the Lock Status (whatever that is!) and
    the b8 is asking for 3 bytes from the card, presumably the Lock status. The
    card that I monitored sent 08 01 08 to the DC which then issued

    	ca a4 00 00 00
    	ca 24 00 00 09

    I'm not sure what is happening here, but the card sent 25 and the DC then
    sent 00 00 00 00 00 00 00 00 08 to the card.

    CONSULTATION

    When you take the consultation option from the main menu, the DC sends the
    following packet

    	ca a4 00 00 00

    to clear CHANN#, then

    	ca a4 02 00 00
    	ca ac a7 00 00
    	ca b8 00 00 12

    which we'll call Packet A.

    The a4 02 instruction tells the card to increment CHANN# by 1, the ac a7
    instruction asks the card to select the Label for that channel, and the b8
    instruction asks the card to send back 12 (decimal 18) bytes containing
    the channel Label (eg the literal TV 1000). The card should send a7 as an
    acknowledgement, 10 as a length byte, 0e Label bytes padded as necessary,
    and 00 00.

    The DC continues to send Packet A until the supported limit of CHANN# is
    exceeded, although its not exactly clear how this sequence terminates.

    CONSULTATION - CHANNEL SELECT

    You use the down arrow keys on your handset to select the channel you wish
    to consult and press a select key. The DC sends the following

    	ca a4 00 00 00

    to clear CHANN# followed by

    	ca a4 02 00 00

    for each time you pressed the down arrow on your remote. This enables the
    card to increment CHANN# to the correct value for the channel selected. The
    DC then sends

    	ca ac a7 00 00
    	ca b8 00 00 12

    requesting the channel Label and the card reponds as with Packet A.
    Let's call this sequence Packet B. The DC then sends

    	ca ac ac 00 00
    	ca ac b1 00 00
    	ca ac b2 00 00
    	ca ac ad 00 00

    I've no idea what this does.

    SUBSCRIPTION

    When you take the Subscription option, Packet B is invoked followed by

    	ca ac a8 00 04

    from the DC. The ac a8 instruction is asking for 2 dates (4 bytes) from
    the card, presumably subscription start/end dates. The card responds with
    (for example) 00 21 27 9f (Jan 1st 1989 and Dec 31st 1999). The DC then
    sends

    	ca b8 00 00 08

    asking for 8 bytes containg subscription data. The card I monitored sent
    a8 for acknowledgement, 06 as a length byte followed by 00 21 ff 9f ff ff.
    presumably this was 2 dates (Jan 1st 1980 and Dec 31st 2007) followed by
    theme and level bytes.

    SUBSCRIPTION/LINK

    I don't even know what this means, but the DC<->card traffic is Packet B to
    get the channel Label, then the DC sends

    	ca ac a9 00 04

    to which the card sends 4 date bytes, then the DC sends

    	ca b8 00 00 02

    asking for 2 data bytes. The card sends a9 05, then the DC sends

    	ca b8 00 00 05

    and the card I monitored sent 00 21 ff 9f bc which was 4 date bytes
    followed by a class byte (whatever that is).

    PREBOOKED PPV

    When this option is taken, the traffic is Packet B to get the Label, then
    the DC sends

    	ca ac aa 00 06

    presumably asking for 6 bytes containing the PPV pool value. The card I
    monitored sent 00 00 00 ff ff ff which is probably some big number.

    IMPULSE PPV

    I observed this to be the same as for Prebooked PPV except that the ac
    subinstruction was e4 not aa. The DC also responded with the 4 packet
    sequence at the end of Consultation - Channel Select above.

    ACCESS CONTROL

    My DC supports four locks, PPV, Consultation, Parental Control and New
    Secret Code and these are independent of any channel so no Packet B
    processing is apparent. In each case the DC cleared CHANN# with the
    ca a4 00 00 00 packet first.

    PPV LOCK

    When I took the unlock option the DC sent

    	ca 24 00 00 09

    to the card which then received 8 zero bytes followed by 09. This
    presumably would write some data to a genuine card.

    CONSULTATION LOCK

    This was as for PPV Lock.

    PARENTAL CONTROL

    The DC sent

    	ca ac 06 00 00

    which is asking the card to selct a Maturity Rating (Universal, PG etc),
    followed by

    	ca b8 00 00 03

    to which the card responded with 06 01 06. I would have thought the DC
    would send a 24 instruction to update the card with the Maturity
    rating selected from the onscreen menu, but I didn't observe this.

    NEW SECRET CODE

    The dialogue is as per the PPV Lock then the DC sends

    	ca 24 01 00 10

    and the card receives 0e bytes of zero followed by a four-nybble secret
    code.

    INSTRUCTION 26

    This instruction is catered for in the PIC code I've examined, but I've
    never monitored its purpose. All the PIC code does is send 6e 90 00 to
    the DC.

    THE DECRYPTION SYSTEM

    So far I've described how the key for a channel is obtained, how the two
    encrypted words are obtained, and how the decrypted words are sent to the
    DC. The next sections deal with the algorithm which is applied to the key
    and an encrypted word to obtain a decrypted word.

    The algorithm is based upon the Data Encryption Standard originally
    created for the secure transmission of military data. There is a very good
    scholarly paper on this standard in a file called des-how-.txt by Matthew
    Fischer of The University of Iowa on the Web and BBSs which is worth a read.

    The Eurocrypt system has two flavours, Eurocrypt-M and Eurocrypt-S2 which are
    currently used by TV channels. I'll describe M first, then S2.

    In this section all numbers are decimal unless stated otherwise, not hex.

    EUROCRYPT-M

    The main steps in the process are:

    	- key preparation

    	- data word manipulation

    	- process iteration.

    In other words, we perform some operations on the key, then manipulate
    the data word, do some interaction between the two (based on exclusive
    ORing) and repeat the process several times until we have the decrypted
    word. In fact the process is performed (decimal) 16 times.

    KEY PREPARATION

    This is very straightforward. We have a 7 byte or 56 bit key which we split
    into two 28 bit halves and we rotate each half 1 or 2 bits to the left
    depending which of the 16 rounds we're on then put the two halves together.
    A single rotation left means that the first (most significant or left hand)
    bit moves to the last (least significant or right hand) position and all the
    other bits move one to the left.

    The exact number of left rotations is determined by the table:

    Round            1  2  3  4  5  6  7  8  9  10  11  12  13  14  15  16
    No of rotations  1  1  2  2  2  2  2  2  1   2   2   2   2   2   2   1

    We then create a new 48 bit key by reordering 48 of the bits in the 56 bit
    shifted key according to the pattern:

    		       14 17 11 24  1  5
    			3 28 15  6 21 10
    		       23 19 12  4 26  8
    		       16  7 27 20 13  2
    		       41 52 31 37 47 55
    		       30 40 51 45 33 48
    		       44 49 39 56 34 53
    		       46 42 50 36 29 32

    This means that the new 1st bit is the 14th old bit, new 2nd bit is old 17th
    and so on with the new 48th bit being the old 32nd bit. The old bits 9, 18,
    22, 25, 35, 38, 43, 54 are not used. This operation is called a Permutation
    and the table is called Permuted Choice 2 or PC-2 in DES terminology.

    Preparation of the key is now complete for a single round. Note that net
    result is that we have a new 48 bit key for use later on.

    DATA WORD MANIPULATION

    The encrypted data word is 8 bytes or 64 bits long. The first thing to do is
    to split this into two halves each 32 bits long called L and R. Then we
    build a new R called R1 of length 48 bits by using the pattern:

    		       32  1  2  3  4  5
    			4  5  6  7  8  9
    			8  9 10 11 12 13
    		       12 13 14 15 16 17
    		       16 17 18 19 20 21
    		       20 21 22 23 24 25
    		       24 25 26 27 28 29
    		       28 29 30 31 32  1

    This means our R1 has its 1st bit as old R's last bit, its 2nd bit as old
    R's 1st bit and so on with its last bit being the ols R's 1st bit. As you
    can see, some of old R's bits are used more than once. The table is called
    the Expansion or E-Table.

    We now XOR this 48 bit R1 with the 48 bit key we prepared earlier, and we
    split the result up into eight 6-bit blocks. Each of these blocks is used
    to locate an entry in one of the eight tables below, called Substitution
    or S-Boxes.

    		       Substitution Box 1

    		       14  4 13  1  2 15 11  8  3 10  6 12  5  9  0  7
    			0 15  7  4 14  2 13  1 10  6 12 11  9  5  3  8
    			4  1 14  8 13  6  2 11 15 12  9  7  3 10  5  0
    		       15 12  8  2  4  9  1  7  5 11  3 14 10  0  6 13

    		       Substitution Box 2

    		       15  1  8 14  6 11  3  4  9  7  2 13 12  0  5 10
    			3 13  4  7 15  2  8 14 12  0  1 10  6  9 11  5
    			0 14  7 11 10  4 13  1  5  8 12  6  9  3  2 15
    		       13  8 10  1  3 15  4  2 11  6  7 12  0  5 14  9

    		       Substitution Box 3

    		       10  0  9 14  6  3 15  5  1 13 12  7 11  4  2  8
    		       13  7  0  9  3  4  6 10  2  8  5 14 12 11 15  1
    		       13  6  4  9  8 15  3  0 11  1  2 12  5 10 14  7
    			1 10 13  0  6  9  8  7  4 15 14  3 11  5  2 12

    		       Substitution Box 4

    			7 13 14  3  0  6  9 10  1  2  8  5 11 12  4 15
    		       13  8 11  5  6 15  0  3  4  7  2 12  1 10 14  9
    		       10  6  9  0 12 11  7 13 15  1  3 14  5  2  8  4
    			3 15  0  6 10  1 13  8  9  4  5 11 12  7  2 14

    		       Substitution Box 5

    			2 12  4  1  7 10 11  6  8  5  3 15 13  0 14  9
    		       14 11  2 12  4  7 13  1  5  0 15 10  3  9  8  6
    			4  2  1 11 10 13  7  8 15  9 12  5  6  3  0 14
    		       11  8 12  7  1 14  2 13  6 15  0  9 10  4  5  3

    		       Substitution Box 6

    		       12  1 10 15  9  2  6  8  0 13  3  4 14  7  5 11
    		       10 15  4  2  7 12  9  5  6  1 13 14  0 11  3  8
    			9 14 15  5  2  8 12  3  7  0  4 10  1 13 11  6
    			4  3  2 12  9  5 15 10 11 14  1  7  6  0  8 13

    		       Substitution Box 7

    			4 11  2 14 15  0  8 13  3 12  9  7  5 10  6  1
    		       13  0 11  7  4  9  1 10 14  3  5 12  2 15  8  6
    			1  4 11 13 12  3  7 14 10 15  6  8  0  5  9  2
    			6 11 13  8  1  4 10  7  9  5  0 15 14  2  3 12

    		       Substitution Box 8

    		       13  2  8  4  6 15 11  1 10  9  3 14  5  0 12  7
    			1 15 13  8 10  3  7  4 12  5  6 11  0 14  9  2
    			7 11  4  1  9 12 14  2  0  6 10 13 15  3  5  8
    			2  1 14  7  4 10  8 13 15 12  9  0  3  5  6 11

    The entry in the S-Box is found by using the 1st and 6th bits of the 6 bit
    block as the row (0, 1, 2, or 3) and the middle 4 bits as the column
    (0 - 15). Also, the 1st 6 bit block uses S-1, the 2nd S-2, and so on with
    the 8th using S-8.

    You will notice that each of the S-Box entries is between 0 and 15; we now
    form a new R called R2 from each of the located S-Box entries in order
    giving us a new 32 bit R2.

    The last operation is to create a (third and final) R called R3 from R2 by
    using the following Permutation or P Table:

    		       16  7 20 21
    		       29 12 28 17
    			1 15 23 26
    			5 18 31 10
    			2  8 24 14
    		       32 27  3  9
    		       19 13 30  6
    		       22 11  4 25

    This means that the 1st bit of R3 is the 16th of R2, the 2nd is the 7th
    and so on, with the 32nd being the 25th bit of R2.

    PROCESS ITERATION

    The net result of the previous section was to split the encrypted word into
    two halves, ignore the left-hand one L and eventually create a new right-
    hand one R3.

    Now we XOR L and R3 together, and we've finished a decryption round.

    For the next round, we treat R3 as the left-hand half of a new data word and
    the result of the XOR operation as the right-hand half and repeat the
    process of key preparation (for that round) and data manipulation (of the
    new data word). We do this 16 times and we end up with a last left-right
    pair of 32 bits each.

    Put these together and we have a decrypted 8 byte word.

    Continue the whole decryption process for the second encrypted word obtained
    from the 88 instruction dialogue and then both can be sent to the DC via
    the C0 instruction dialogue and the TV picture is unscrambled!

    EUROCRYPT-S2

    There are three variations on Eurocrypt-M which together form Eurocrypt-S2.

    KEY PREPARATION

    The key is split into a left and right pair as before. However, no left
    shifting is performed prior to data word manipulation; the shifting is
    performed after the manipulation and the shifts are to the right, not the
    left.

    DATA WORD MANIPULATION

    Before performing the E-table operation, a new data word should be created
    using the following permutation:

    		       58 50 42 34 26 18 10  2
    		       60 52 44 36 28 20 12  4
    		       62 54 46 38 30 22 14  6
    		       64 56 48 40 32 24 16  8
    		       57 49 41 33 25 17  9  1
    		       59 51 43 35 27 19 11  3
    		       61 53 45 37 29 21 13  5
    		       63 55 47 39 31 23 15  7

    This means that the new data word is 64 bits long, and its 1st bit is the
    original word's 58th and so on. This is called the Initial Permutation or IP
    and is performed once per 16 decryption rounds.

    After the decryption is complete as per Eurocrypt-M (ie after 16 rounds),
    the decrypted data word is permuted using the following table:

    		       40  8 48 16 56 24 64 32
    		       39  7 47 15 55 23 63 31
    		       38  6 46 14 54 22 62 30
    		       37  5 45 13 53 21 61 29
    		       36  4 44 12 52 20 60 28
    		       35  3 43 11 51 19 59 27
    		       34  2 42 10 50 18 58 26
    		       33  1 41  9 49 17 57 25

    This means that the final decrypted word is 64 bits long and its first bit
    is the previous word's 40th and so on. This is called the Inverse Initial
    Permutation or IP**-1.