PRN
2019-08-31 17:24:32 UTC
Does anyone have this implementation or can you tell me where you can find it? Thanks!
Discussion:
(too old to reply)
Robert Wessel
2019-09-01 00:30:51 UTC
On Sat, 31 Aug 2019 10:24:32 -0700 (PDT), PRN
Lucifer was the predecessor to what eventually became DES. It was
developed by IBM, and submitted to the DES competition. It saw a bit
of usage in 19 early eighties. Several incompatible versions were
developed under the same name. You can find some additional
information and lines at:
https://en.wikipedia.org/wiki/Lucifer_(cipher)
Lucifer was the predecessor to what eventually became DES. It was
developed by IBM, and submitted to the DES competition. It saw a bit
of usage in 19 early eighties. Several incompatible versions were
developed under the same name. You can find some additional
information and lines at:
https://en.wikipedia.org/wiki/Lucifer_(cipher)
PRN
2019-09-01 00:34:40 UTC
Post by Robert Wessel
On Sat, 31 Aug 2019 10:24:32 -0700 (PDT), PRN
Lucifer was the predecessor to what eventually became DES. It was
developed by IBM, and submitted to the DES competition. It saw a bit
of usage in 19 early eighties. Several incompatible versions were
developed under the same name. You can find some additional
https://en.wikipedia.org/wiki/Lucifer_(cipher)
Yes, i already saw that. But im asking for a Java implementation of it. Like this but with Lucifer cipher (https://n3vrax.wordpress.com/2011/07/26/rc6-encryption-algorithm-in-java/) (This is RC6)On Sat, 31 Aug 2019 10:24:32 -0700 (PDT), PRN
Lucifer was the predecessor to what eventually became DES. It was
developed by IBM, and submitted to the DES competition. It saw a bit
of usage in 19 early eighties. Several incompatible versions were
developed under the same name. You can find some additional
https://en.wikipedia.org/wiki/Lucifer_(cipher)
david eather
2019-09-01 02:32:43 UTC
Post by PRN
Very unlikely you will find it. You might find a sufficiently detailedPost by Robert Wessel
On Sat, 31 Aug 2019 10:24:32 -0700 (PDT), PRN
Lucifer was the predecessor to what eventually became DES. It was
developed by IBM, and submitted to the DES competition. It saw a bit
of usage in 19 early eighties. Several incompatible versions were
developed under the same name. You can find some additional
https://en.wikipedia.org/wiki/Lucifer_(cipher)
Yes, i already saw that. But im asking for a Java implementation of it. Like this but with Lucifer cipher (https://n3vrax.wordpress.com/2011/07/26/rc6-encryption-algorithm-in-java/) (This is RC6)On Sat, 31 Aug 2019 10:24:32 -0700 (PDT), PRN
Lucifer was the predecessor to what eventually became DES. It was
developed by IBM, and submitted to the DES competition. It saw a bit
of usage in 19 early eighties. Several incompatible versions were
developed under the same name. You can find some additional
https://en.wikipedia.org/wiki/Lucifer_(cipher)
specification so you can write your own, but a cipher that was old,
little used, little known and superseded even before the widespread use
of Java is an almost impossible ask.
David Entwistle
2019-10-10 13:25:09 UTC
Post by david eather
Very unlikely you will find it. You might find a sufficiently detailed
specification so you can write your own, but a cipher that was old,
little used, little known and superseded even before the widespread use
of Java is an almost impossible ask.
Keeping up my six week delay in replying to posts....Very unlikely you will find it. You might find a sufficiently detailed
specification so you can write your own, but a cipher that was old,
little used, little known and superseded even before the widespread use
of Java is an almost impossible ask.
Does anyone have access to any implementation of Lucifer, closely based
on the Arthur Sorkin paper: "Lucifer, A Cryptographic Algorithm"?
As a learning exercise, I've had a stab a writing the components of the
Lucifer encryption algorithm, in Java. I could do with something to
compare results with, before I spend too much time working on the
decryption algorithm.
I produce the following results. The only example of similar efforts, I
can find online, doesn't correspond. But those online results are
produced by an algorithm that differs somewhat from that in the paper.
I've almost certainly done something wrong, but I'd be interested if
anyone can easily produce a reasonably "standards-compliant" Lucifer
ciphertext.
Key: 01 23 45 67 89 AB CD EF FE DC BA 98 76 54 32 10
Input: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Cipher: D8 84 73 0F 04 6F 6E 42 49 33 58 16 0F AA 36 60
Key: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Input: 01 23 45 67 89 AB CD EF FE DC BA 98 76 54 32 10
Cipher: A0 67 8E 7A 25 4F CC 01 90 AD 25 0E EB 7D E9 98
Key: 01 23 45 67 89 AB CD EF FE DC BA 98 76 54 32 10
Input: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
Cipher: 5E 7E 4C DF 1E CA 31 53 86 EE C7 6D 9F 24 82 A8
Key: 01 23 45 67 89 AB CD EF FE DC BA 98 76 54 32 10
Input: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
Cipher: 5E 7E 4C DF 1E CA 31 53 86 EE C7 6D 9F 24 82 A8
Key: 01 23 45 67 89 AB CD EF FE DC BA 98 76 54 32 10
Input: 01 23 45 67 89 AB CD EF FE DC BA 98 76 54 32 10
Cipher: DA 21 49 48 90 9D 2B 3E 3C 7A 9E 03 D9 43 F0 DF
It's been an interesting an informative exercise, even if I don't get a
working solution.
Many Thanks,
--
David Entwistle
David Entwistle
wizzofozz
2019-10-10 20:27:20 UTC
Post by David Entwistle
Does anyone have access to any implementation of Lucifer, closely based
on the Arthur Sorkin paper: "Lucifer, A Cryptographic Algorithm"?
As a learning exercise, I've had a stab a writing the components of the
Lucifer encryption algorithm, in Java. I could do with something to
compare results with, before I spend too much time working on the
decryption algorithm.
I produce the following results. The only example of similar efforts, I
can find online, doesn't correspond. But those online results are
It would help if you told us what "the only example you could find" is ;-)Post by david eather
Very unlikely you will find it. You might find a sufficiently detailed
specification so you can write your own, but a cipher that was old,
little used, little known and superseded even before the widespread use
of Java is an almost impossible ask.
Keeping up my six week delay in replying to posts....Very unlikely you will find it. You might find a sufficiently detailed
specification so you can write your own, but a cipher that was old,
little used, little known and superseded even before the widespread use
of Java is an almost impossible ask.
Does anyone have access to any implementation of Lucifer, closely based
on the Arthur Sorkin paper: "Lucifer, A Cryptographic Algorithm"?
As a learning exercise, I've had a stab a writing the components of the
Lucifer encryption algorithm, in Java. I could do with something to
compare results with, before I spend too much time working on the
decryption algorithm.
I produce the following results. The only example of similar efforts, I
can find online, doesn't correspond. But those online results are
So, I'm not sure if you already found this, but here goes anyway:
https://github.com/robwaddell/lucifer-go/blob/master/lucifer-go.go
It looks pretty close to this paper:
https://www.staff.uni-mainz.de/pommeren/Cryptology/Bitblock/2_Feistel/Lucifer.pdf
Maybe it helps.
Ozz
David Entwistle
2019-10-11 01:10:28 UTC
Good point. It was the following:
https://github.com/scorpiochn/Applied-Cryptography/tree/master/lucifer-
outerbridge-5.0
This includes test outputs, but I didn't understand the c source code.
Excellent. The comments in the source code explain the part I wasn't
understanding within the previous source code I'd looked at - the fixed
permutation, as Sorkin describes it, has been pre-computed and presented
as a look-up table. Now I understand what's going on there, I have more
confidence that I'm doing the same thing, but in a different way. I
should be able to compare outputs round-by-round.
Lucifer.pdf
Yes, pretty close. If I'm reading it correct, the paper has a slightly
different permutation (the z0-> z2 stuff, on the last page, looks
different to Sorkin and the c source code).
It certainly does. Many thanks.
https://github.com/scorpiochn/Applied-Cryptography/tree/master/lucifer-
outerbridge-5.0
This includes test outputs, but I didn't understand the c source code.
Excellent. The comments in the source code explain the part I wasn't
understanding within the previous source code I'd looked at - the fixed
permutation, as Sorkin describes it, has been pre-computed and presented
as a look-up table. Now I understand what's going on there, I have more
confidence that I'm doing the same thing, but in a different way. I
should be able to compare outputs round-by-round.
Lucifer.pdf
Yes, pretty close. If I'm reading it correct, the paper has a slightly
different permutation (the z0-> z2 stuff, on the last page, looks
different to Sorkin and the c source code).
It certainly does. Many thanks.
--
David Entwistle
David Entwistle
David Entwistle
2019-10-19 16:40:35 UTC
Apologies to the follow-up to my own post.
I went back to the FORTRAN listing included in Sorkin's Lucifer paper and
implemented that. It made interesting use of FORTRAN's array equivalence
to store the message block and manipulate is as either a one-dimension, a
two-dimension, or three-dimension array.
I changed the program slightly to print the encrypted output block and
then used a debugger to compare the variables in my implementation with
the FORTRAN. I'd made a couple of mistakes, but there was something else.
The FORTRAN program uses arrays of integers to hold each bit of an
integer. These are used to provide the input to the S-Boxes, which form
part of the confuser. Looking at the values stored, the bit order seemed
reversed. The nibbles get swapped at the input to the two 4 x 4 S-Boxes,
under the control of the transfer control bit, but it wasn't that. The
order of the bits within the nibbles was reversed. Same with the output
from the confuser - the bits were reversed to what you'd expect. This
isn't documented behaviour, as far as I could tell.
I'm thinking, but I'm not sure, that the original implementation was
intended to run on little-endian hardware and operating system. That
would possibly make more sense.
I started to implement the swap in my own implementation, but realizing I
was implementing something that probably wasn't an accurate reflection of
correct operation, gave up on the idea.
Having got a good understanding of how Lucifer works, that's probably as
far as I'll go for now, but if anyone has any little-endian hardware that
can run FORTRAN, feel free to get in touch.
I went back to the FORTRAN listing included in Sorkin's Lucifer paper and
implemented that. It made interesting use of FORTRAN's array equivalence
to store the message block and manipulate is as either a one-dimension, a
two-dimension, or three-dimension array.
I changed the program slightly to print the encrypted output block and
then used a debugger to compare the variables in my implementation with
the FORTRAN. I'd made a couple of mistakes, but there was something else.
The FORTRAN program uses arrays of integers to hold each bit of an
integer. These are used to provide the input to the S-Boxes, which form
part of the confuser. Looking at the values stored, the bit order seemed
reversed. The nibbles get swapped at the input to the two 4 x 4 S-Boxes,
under the control of the transfer control bit, but it wasn't that. The
order of the bits within the nibbles was reversed. Same with the output
from the confuser - the bits were reversed to what you'd expect. This
isn't documented behaviour, as far as I could tell.
I'm thinking, but I'm not sure, that the original implementation was
intended to run on little-endian hardware and operating system. That
would possibly make more sense.
I started to implement the swap in my own implementation, but realizing I
was implementing something that probably wasn't an accurate reflection of
correct operation, gave up on the idea.
Having got a good understanding of how Lucifer works, that's probably as
far as I'll go for now, but if anyone has any little-endian hardware that
can run FORTRAN, feel free to get in touch.
--
David Entwistle
David Entwistle
Robert Wessel
2019-10-20 04:00:38 UTC
On Sat, 19 Oct 2019 11:40:35 -0500, David Entwistle
If not, binaries for various systems are available here:
https://gcc.gnu.org/wiki/GFortran
Post by David Entwistle
Apologies to the follow-up to my own post.
I went back to the FORTRAN listing included in Sorkin's Lucifer paper and
implemented that. It made interesting use of FORTRAN's array equivalence
to store the message block and manipulate is as either a one-dimension, a
two-dimension, or three-dimension array.
I changed the program slightly to print the encrypted output block and
then used a debugger to compare the variables in my implementation with
the FORTRAN. I'd made a couple of mistakes, but there was something else.
The FORTRAN program uses arrays of integers to hold each bit of an
integer. These are used to provide the input to the S-Boxes, which form
part of the confuser. Looking at the values stored, the bit order seemed
reversed. The nibbles get swapped at the input to the two 4 x 4 S-Boxes,
under the control of the transfer control bit, but it wasn't that. The
order of the bits within the nibbles was reversed. Same with the output
from the confuser - the bits were reversed to what you'd expect. This
isn't documented behaviour, as far as I could tell.
I'm thinking, but I'm not sure, that the original implementation was
intended to run on little-endian hardware and operating system. That
would possibly make more sense.
I started to implement the swap in my own implementation, but realizing I
was implementing something that probably wasn't an accurate reflection of
correct operation, gave up on the idea.
Having got a good understanding of how Lucifer works, that's probably as
far as I'll go for now, but if anyone has any little-endian hardware that
can run FORTRAN, feel free to get in touch.
If you're running x86 Linux, gfortran is probably already installed.Apologies to the follow-up to my own post.
I went back to the FORTRAN listing included in Sorkin's Lucifer paper and
implemented that. It made interesting use of FORTRAN's array equivalence
to store the message block and manipulate is as either a one-dimension, a
two-dimension, or three-dimension array.
I changed the program slightly to print the encrypted output block and
then used a debugger to compare the variables in my implementation with
the FORTRAN. I'd made a couple of mistakes, but there was something else.
The FORTRAN program uses arrays of integers to hold each bit of an
integer. These are used to provide the input to the S-Boxes, which form
part of the confuser. Looking at the values stored, the bit order seemed
reversed. The nibbles get swapped at the input to the two 4 x 4 S-Boxes,
under the control of the transfer control bit, but it wasn't that. The
order of the bits within the nibbles was reversed. Same with the output
from the confuser - the bits were reversed to what you'd expect. This
isn't documented behaviour, as far as I could tell.
I'm thinking, but I'm not sure, that the original implementation was
intended to run on little-endian hardware and operating system. That
would possibly make more sense.
I started to implement the swap in my own implementation, but realizing I
was implementing something that probably wasn't an accurate reflection of
correct operation, gave up on the idea.
Having got a good understanding of how Lucifer works, that's probably as
far as I'll go for now, but if anyone has any little-endian hardware that
can run FORTRAN, feel free to get in touch.
If not, binaries for various systems are available here:
https://gcc.gnu.org/wiki/GFortran
David Entwistle
2019-10-20 09:04:42 UTC
Post by Robert Wessel
If you're running x86 Linux, gfortran is probably already installed.
https://gcc.gnu.org/wiki/GFortran
Yes, indeed. I was impressed to find I could run GFORTRAN from within theIf you're running x86 Linux, gfortran is probably already installed.
https://gcc.gnu.org/wiki/GFortran
Eclipse IDE and get access to full debugging facilities. I was able to
run the Lucifer FORTRAN program and happily produce output (see below).
The cipher text decrypted back to the original plain text.
It was when I was trying to reproduce the same output using a Java
implementation I noticed that behaviour within the FORTRAN program wasn't
what I expected. Reading a byte (stored as an integer) into the Confuser,
uses a integer array as the transport. If the integer was say hex 'E9'
11101001, (ignoring the possible input hexdigit interchange), it was
presented to the S-Box as hex '97' 10010111. The S-Boxes permutated
nibbles '9' and '7' and presented the expected output, but as this output
was read back into an integer, from the integer array, the bit order was
again reversed. As part of the confuser, that may be intentional, but it
seems unlikely and it isn't documented, as far as I can see.
Running on a little-endian system, I suspect there would be no bit
reversal, but that's just my thought and I may have it quite wrong.
Figure 1 - Confuser Interrupter Diffuser
<Loading Image...
>Figure 2 - S-Boxes.
<Loading Image...
>key
0123456789abcdeffedcba9876543210
plain
00000000000000000000000000000000
key
0 0 0 0 0 0 0 1 0 0 1 0 0 0 1 1
0 1 0 0 0 1 0 1 0 1 1 0 0 1 1 1
1 0 0 0 1 0 0 1 1 0 1 0 1 0 1 1
1 1 0 0 1 1 0 1 1 1 1 0 1 1 1 1
1 1 1 1 1 1 1 0 1 1 0 1 1 1 0 0
1 0 1 1 1 0 1 0 1 0 0 1 1 0 0 0
0 1 1 1 0 1 1 0 0 1 0 1 0 1 0 0
0 0 1 1 0 0 1 0 0 0 0 1 0 0 0 0
plain
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
cipher
C318179D5848D88C322F7462C4F82B2A
cipher
1 1 0 0 0 0 1 1 0 0 0 1 1 0 0 0
0 0 0 1 0 1 1 1 1 0 0 1 1 1 0 1
0 1 0 1 1 0 0 0 0 1 0 0 1 0 0 0
1 1 0 1 1 0 0 0 1 0 0 0 1 1 0 0
0 0 1 1 0 0 1 0 0 0 1 0 1 1 1 1
0 1 1 1 0 1 0 0 0 1 1 0 0 0 1 0
1 1 0 0 0 1 0 0 1 1 1 1 1 0 0 0
0 0 1 0 1 0 1 1 0 0 1 0 1 0 1 0
plain
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
key
0123456789ABCDEFFEDCBA9876543210
plain
00000000000000000000000000000000
--
David Entwistle
David Entwistle
Robert Wessel
2019-10-21 13:22:39 UTC
On Sun, 20 Oct 2019 04:04:42 -0500, David Entwistle
First, x86 is little-endian. You usage of the term is a bit confused.
Second, byte order does not impact the bit order within bytes. Thus a
byte 0xe9 will get stored as such on both little-endian x86 and
big-endian S/360. You'll never see it as 0x97. A larger type will
get the order of the bytes changes - thus a 32-bit variable holding
the value 0x12345678 on x86 would have the bytes 0x78, 0x56, 0x34,
0x12, while on S/60 they'd be 0x12, 0x34, 0x56, 0x78.
Note that this does not apply to some types of I/O, where the bit
order can also vary on the "wire".
Now that doesn't mean a program can't expose the byte order of the
machine in various ways, but it can only happen if you access data as
both the larger (byte order dependent) and smaller types. I think you
mentioned in one of the other posts that some of the structures in the
Fortran source you're using make use of Fortran equivalence, which
would certainly provide some opportunities for doing that (as would,
say, a C union). But again, you should not see reinterpretations of
units of things smaller than a byte.
If the code is doing something like storing a "byte" as individual
objects (perhaps bytes), then any byte order changes might be visible.
Consider a C union:
union BITS {unsigned long long ull; unsigned char b[8]} bits;
bits.ull = 0x0101010001000001; 0xe9, one bit at a time
for (i=0; i<8; i++) printf("%i\n", bits.b[i]);
This would print 1/1/1/0/1/0/0/0/1 on a big-endian machine, and
1/0/0/1/0/1/1/1 on a little-endian machine.
Post by David Entwistle
Eclipse IDE and get access to full debugging facilities. I was able to
run the Lucifer FORTRAN program and happily produce output (see below).
The cipher text decrypted back to the original plain text.
It was when I was trying to reproduce the same output using a Java
implementation I noticed that behaviour within the FORTRAN program wasn't
what I expected. Reading a byte (stored as an integer) into the Confuser,
uses a integer array as the transport. If the integer was say hex 'E9'
11101001, (ignoring the possible input hexdigit interchange), it was
presented to the S-Box as hex '97' 10010111. The S-Boxes permutated
nibbles '9' and '7' and presented the expected output, but as this output
was read back into an integer, from the integer array, the bit order was
again reversed. As part of the confuser, that may be intentional, but it
seems unlikely and it isn't documented, as far as I can see.
Running on a little-endian system, I suspect there would be no bit
reversal, but that's just my thought and I may have it quite wrong.
Figure 1 - Confuser Interrupter Diffuser
<http://www.radiometeor.plus.com/Lucifer/CID.jpg>
Figure 2 - S-Boxes.
<http://www.radiometeor.plus.com/Lucifer/S-Box.jpg>
key
0123456789abcdeffedcba9876543210
plain
00000000000000000000000000000000
key
0 0 0 0 0 0 0 1 0 0 1 0 0 0 1 1
0 1 0 0 0 1 0 1 0 1 1 0 0 1 1 1
1 0 0 0 1 0 0 1 1 0 1 0 1 0 1 1
1 1 0 0 1 1 0 1 1 1 1 0 1 1 1 1
1 1 1 1 1 1 1 0 1 1 0 1 1 1 0 0
1 0 1 1 1 0 1 0 1 0 0 1 1 0 0 0
0 1 1 1 0 1 1 0 0 1 0 1 0 1 0 0
0 0 1 1 0 0 1 0 0 0 0 1 0 0 0 0
plain
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
cipher
C318179D5848D88C322F7462C4F82B2A
cipher
1 1 0 0 0 0 1 1 0 0 0 1 1 0 0 0
0 0 0 1 0 1 1 1 1 0 0 1 1 1 0 1
0 1 0 1 1 0 0 0 0 1 0 0 1 0 0 0
1 1 0 1 1 0 0 0 1 0 0 0 1 1 0 0
0 0 1 1 0 0 1 0 0 0 1 0 1 1 1 1
0 1 1 1 0 1 0 0 0 1 1 0 0 0 1 0
1 1 0 0 0 1 0 0 1 1 1 1 1 0 0 0
0 0 1 0 1 0 1 1 0 0 1 0 1 0 1 0
plain
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
key
0123456789ABCDEFFEDCBA9876543210
plain
00000000000000000000000000000000
You seem to have some misunderstanding about byte order issues.Post by Robert Wessel
If you're running x86 Linux, gfortran is probably already installed.
https://gcc.gnu.org/wiki/GFortran
Yes, indeed. I was impressed to find I could run GFORTRAN from within theIf you're running x86 Linux, gfortran is probably already installed.
https://gcc.gnu.org/wiki/GFortran
Eclipse IDE and get access to full debugging facilities. I was able to
run the Lucifer FORTRAN program and happily produce output (see below).
The cipher text decrypted back to the original plain text.
It was when I was trying to reproduce the same output using a Java
implementation I noticed that behaviour within the FORTRAN program wasn't
what I expected. Reading a byte (stored as an integer) into the Confuser,
uses a integer array as the transport. If the integer was say hex 'E9'
11101001, (ignoring the possible input hexdigit interchange), it was
presented to the S-Box as hex '97' 10010111. The S-Boxes permutated
nibbles '9' and '7' and presented the expected output, but as this output
was read back into an integer, from the integer array, the bit order was
again reversed. As part of the confuser, that may be intentional, but it
seems unlikely and it isn't documented, as far as I can see.
Running on a little-endian system, I suspect there would be no bit
reversal, but that's just my thought and I may have it quite wrong.
Figure 1 - Confuser Interrupter Diffuser
<http://www.radiometeor.plus.com/Lucifer/CID.jpg>
Figure 2 - S-Boxes.
<http://www.radiometeor.plus.com/Lucifer/S-Box.jpg>
key
0123456789abcdeffedcba9876543210
plain
00000000000000000000000000000000
key
0 0 0 0 0 0 0 1 0 0 1 0 0 0 1 1
0 1 0 0 0 1 0 1 0 1 1 0 0 1 1 1
1 0 0 0 1 0 0 1 1 0 1 0 1 0 1 1
1 1 0 0 1 1 0 1 1 1 1 0 1 1 1 1
1 1 1 1 1 1 1 0 1 1 0 1 1 1 0 0
1 0 1 1 1 0 1 0 1 0 0 1 1 0 0 0
0 1 1 1 0 1 1 0 0 1 0 1 0 1 0 0
0 0 1 1 0 0 1 0 0 0 0 1 0 0 0 0
plain
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
cipher
C318179D5848D88C322F7462C4F82B2A
cipher
1 1 0 0 0 0 1 1 0 0 0 1 1 0 0 0
0 0 0 1 0 1 1 1 1 0 0 1 1 1 0 1
0 1 0 1 1 0 0 0 0 1 0 0 1 0 0 0
1 1 0 1 1 0 0 0 1 0 0 0 1 1 0 0
0 0 1 1 0 0 1 0 0 0 1 0 1 1 1 1
0 1 1 1 0 1 0 0 0 1 1 0 0 0 1 0
1 1 0 0 0 1 0 0 1 1 1 1 1 0 0 0
0 0 1 0 1 0 1 1 0 0 1 0 1 0 1 0
plain
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
key
0123456789ABCDEFFEDCBA9876543210
plain
00000000000000000000000000000000
First, x86 is little-endian. You usage of the term is a bit confused.
Second, byte order does not impact the bit order within bytes. Thus a
byte 0xe9 will get stored as such on both little-endian x86 and
big-endian S/360. You'll never see it as 0x97. A larger type will
get the order of the bytes changes - thus a 32-bit variable holding
the value 0x12345678 on x86 would have the bytes 0x78, 0x56, 0x34,
0x12, while on S/60 they'd be 0x12, 0x34, 0x56, 0x78.
Note that this does not apply to some types of I/O, where the bit
order can also vary on the "wire".
Now that doesn't mean a program can't expose the byte order of the
machine in various ways, but it can only happen if you access data as
both the larger (byte order dependent) and smaller types. I think you
mentioned in one of the other posts that some of the structures in the
Fortran source you're using make use of Fortran equivalence, which
would certainly provide some opportunities for doing that (as would,
say, a C union). But again, you should not see reinterpretations of
units of things smaller than a byte.
If the code is doing something like storing a "byte" as individual
objects (perhaps bytes), then any byte order changes might be visible.
Consider a C union:
union BITS {unsigned long long ull; unsigned char b[8]} bits;
bits.ull = 0x0101010001000001; 0xe9, one bit at a time
for (i=0; i<8; i++) printf("%i\n", bits.b[i]);
This would print 1/1/1/0/1/0/0/0/1 on a big-endian machine, and
1/0/0/1/0/1/1/1 on a little-endian machine.