Proxmark3 community

Research, development and trades concerning the powerful Proxmark3 device.

Remember; sharing is caring. Bring something back to the community.


"Learn the tools of the trade the hard way." +Fravia

You are not logged in.

Announcement

Time changes and with it the technology
Proxmark3 @ discord

Users of this forum, please be aware that information stored on this site is not private.

#1 2009-03-26 13:58:36

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?

Offline

#2 2009-03-26 14:11:27

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)

Offline

Board footer

Powered by FluxBB