Loading ...
Sorry, an error occurred while loading the content.

RE: tracker2 tea cipher

Expand Messages
  • juha.nurmela@quicknet.inet.fi
    ... Would it be possible to include a monotonic number in the digest ? It still needs the challenge ( use this counter ), when counters get out of sync. Just a
    Message 1 of 12 , Apr 20 9:39 PM
    • 0 Attachment
      On Wed, 19 Apr 2006 scott@... wrote:

      > ... the command text and optionally a challenge
      > provided by the target device (to prevent replay attacks)

      Would it be possible to include a monotonic number in the digest ?
      It still needs the challenge ("use this counter"), when counters get out
      of sync. Just a layman speaking here.

      You are in the position to pick the byte order for the 32-bit y/z/k[]
      cipher variables. I'd be happy to go with motorola-order ;)

      > delimiter. Length and encoding of the tag hasn't been decided yet.

      Delimiter, algoritm/operation identifier and four character base91 ? Four
      characters would handle 26 bits of tag. Not that the 2 additional bits
      much matter, in practice.

      > including the source callsign in the MAC might be a good idea ...
      > ... illegally impersonate a valid user's callsign.

      Ve-ry nice.



      having trouble with yahoo registration (and +/^ "C" precedences),
      Juha, OH5NXO
    • scott@opentrac.org
      ... What I m leaning toward now is a use this counter plus up to n so that you can skip ahead and guess if you re missing the current challenge. The unit
      Message 2 of 12 , Apr 26 6:47 PM
      • 0 Attachment
        > Would it be possible to include a monotonic number in the digest ?
        > It still needs the challenge ("use this counter"), when
        > counters get out
        > of sync. Just a layman speaking here.

        What I'm leaning toward now is a "use this counter plus up to n" so that you
        can skip ahead and guess if you're missing the current challenge. The unit
        just needs to keep track of what's been used.

        > You are in the position to pick the byte order for the 32-bit y/z/k[]
        > cipher variables. I'd be happy to go with motorola-order ;)

        I'll check the TEA algorithm and see how it's set up as far as byte order
        goes. I do tend to go with big-endian when I have the choice.

        > Delimiter, algoritm/operation identifier and four character
        > base91 ? Four
        > characters would handle 26 bits of tag. Not that the 2
        > additional bits
        > much matter, in practice.

        Base91 isn't as easy to translate to base2. Base64 would be simpler. Might
        be able to reuse some code, though.

        Scott
      • juha.nurmela@quicknet.inet.fi
        ... There s the decompression of lat/lon which does 4 bytes. Suggestion; ... Juha
        Message 3 of 12 , Apr 27 12:11 AM
        • 0 Attachment
          On Wed, 26 Apr 2006 scott@... wrote:

          > Base91 isn't as easy to translate to base2. Base64 would be simpler. Might
          > be able to reuse some code, though.

          There's the decompression of lat/lon which does 4 bytes.

          Suggestion;

          :!!un-authenticated command (type 0)
          :!"ABCD authenticated command, type 1
          :!#EFGHJK type 2, auth data between # and ' '

          :."LMNO authenticated response, type 1


          Juha
        • scott@opentrac.org
          I d planned to have the authentication string at the end of the command for simplicity, but I guess it doesn t matter too much. What I really hate in APRS is
          Message 4 of 12 , Apr 27 10:32 AM
          • 0 Attachment
            I'd planned to have the authentication string at the end of the command for
            simplicity, but I guess it doesn't matter too much. What I really hate in
            APRS is trying to keep track of what delimiters are safe to use where, and
            what's already been overloaded for other purposes.

            Scott

            > -----Original Message-----
            > From: tracker2@yahoogroups.com
            > [mailto:tracker2@yahoogroups.com] On Behalf Of
            > juha.nurmela@...
            > Sent: Thursday, April 27, 2006 12:12 AM
            > To: tracker2@yahoogroups.com
            > Subject: [tracker2] RE: tracker2 tea cipher
            >
            >
            >
            > On Wed, 26 Apr 2006 scott@... wrote:
            >
            > > Base91 isn't as easy to translate to base2. Base64 would
            > be simpler. Might
            > > be able to reuse some code, though.
            >
            > There's the decompression of lat/lon which does 4 bytes.
            >
            > Suggestion;
            >
            > :!!un-authenticated command (type 0)
            > :!"ABCD authenticated command, type 1
            > :!#EFGHJK type 2, auth data between # and ' '
            >
            > :."LMNO authenticated response, type 1
            >
            >
            > Juha
            >
            >
            >
            >
            > Yahoo! Groups Links
            >
            >
            >
            >
            >
            >
            >
            >
          • juha.nurmela@quicknet.inet.fi
            ... You call the shots. besserwissers spectate. ... A-men. About the N vs replays . I meant that every spent N would mark a chunk of N:s. Let s say the
            Message 5 of 12 , Apr 27 12:32 PM
            • 0 Attachment
              On Thu, 27 Apr 2006 scott@... wrote:

              > I'd planned to

              You call the shots. besserwissers spectate.

              > What I really hate in APRS is trying to keep track of what delimiters
              > are safe to use where, and what's already been overloaded

              A-men.

              About the 'N vs replays'.

              I meant that every "spent N" would mark a chunk of N:s. Let's say the
              chunk is 256 bytes, and T2 has N at 10. Command with N 15 arrives, is
              accepted, as it is between 10 and say 110. Bit 15 / 256 == 0 is tested and
              seen already cleared by previous commands. Finally, N is set at 16 (in
              RAM).
              T2 resets, bitstring in flash is scanned { FE, FF, FF ... }
              and N set at 256, as a surprise for future commands.

              Would it loose strength, if the N was part of the message text, the
              normal APRS message identifier {nnnnn. That would save from
              iterating the cipher thru many times, testing each separately.


              Juha
            Your message has been successfully submitted and would be delivered to recipients shortly.