Proxmark3 community

rfider

Member

Registered: 2009-01-04

Posts: 15

CRYPTO-1: something about endian

void
crypto1_init(struct Crypto1State *state, uint64_t key)
{
  int i;

  state->odd = state->even = 0;
  for(i = 0; i < 48; i += 2)
  {
    state->odd  = state->odd  << 1 | BIT(key, i + 1);
    state->even = state->even << 1 | BIT(key, i);
  }
}

why key and state are totally reverse?

uint32_t
crypto1_word(struct Crypto1State *state, uint32_t in_word, int fb)
{
  uint32_t i, ret = 0;

  for (i = 24; i < 32; i ^= 24, ++i, i ^= 24)
    ret |= crypto1_bit(state, BIT(in_word, i), fb) << i;

  return ret;
}

why crypt a word in such a strange order, not from first to the last bit?

is it something about the standard or to simulate real system?

joker

Contributor

Registered: 2008-11-17

Posts: 34

Re: CRYPTO-1: something about endian

How the state is stored is an implementation choice, if it is that way presumably it simplifies the code. Keep in mind that it takes the key in opposite byte order than defined in the ISO standard and the one used on this board.

The reason for the bits to be encrypted in that order, is because that's how the tags/reader work. You will have to send an angry email to NXP(their empathy might be limited though) or the ISO commission. It's indeed somewhat tedious ... as mentioned on this board and in the papers even on several occasions.

edit: You might not realize that the order you call
crypto1_bit in is important. The function generates one bit of keystream at a time with the side effect of changing the internal state(which was past as first parameter). If you are more used to Object Oriented Programming, you should see it as state->getBit(). (The other arguments are only used during authentication)

So it's the order that crypto1_bit produces the bits of keystream that is to blame for that awkward for loop.  It's not that easy to change the order getBit produces the bits.

Last edited by joker (2009-03-27 08:50:18)