let me try to clear this up. this is a trivial step. just reverse the
order of the bits.
note: when in doubt about what the process is supposed to be, refer to the
example. The example is correct. But you can ask here just to be sure
too :)
input from KB_HEX is the normal ordering for a hex value. for example:
0 = 0000
1 = 0001
2 = 0010
3 = 0011
etc...
the first step in the encryption process is to reverse the order of these
bits. so:
0 = 0000 -> 0000
1 = 0001 -> 1000
2 = 0010 -> 0100
3 = 0011 -> 1100
*** reverse the bits, and continue with the next step. that's what you
need to do. ***
so it they were
N = B1B2B3B4 -> B4B3B2B1
so I suppose the new bits could be labed (b10, b11, b12, b13), but this
does not show the reversal very well, since b00 -> b10 etc...
hope that clears things up.
--Paul
On Mon, 8 Oct 2001, Harvey Wong wrote:
>Hi all,
> I was just looking at lab 3 and you have under reverse the order of the input bits as:
>
> Original: B00 B01 B02 B03
> New: B13 B12 B11 B10
>
> Shouldn't the order of the "New" bits be B10, B11, B12, and B13? This way, the example that you give us later on in the lab specs (the one where we encrypt the letter "A") works when we "expand and permute," since the bits will match up. I was just wondering if this was the case since you say you derive the first bit in the "expand and permute" step using B13 and in the example you use bit 3 of the new bit pattern (which would be B10). Just need a little clarification as to which one we use. Thank you for your time.
>
>-Harvey Wong
>
"Oh, there it is...
...Then what the heck was that other piece of code we changed?"
This archive was generated by hypermail 2.1.3 : Wed Nov 21 2001 - 15:50:12 MST