Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: 1.5, 1.6, 1.6.1, 1.7
    • Fix Version/s: 1.8.0
    • Labels:
      None
    • Environment:
      Windows 7 / VS 2008 / .Net 3.5

      Description

      Serpent Test Vectors for NESSIE from serpent authors do not mach the algorithm.

      test vectors at:

        Activity

        Hide
        David Hook added a comment - - edited
        You'll appreciate it completely contradicts the original we received. Actually, no it doesn't, well not quite, but I'm not sure if it helps. If you feed:

        key=00000000000000000000000000000000
               00000000000000000000000000000000
        plain=000000000000000000000

        into BC you get:

        9FAA1E723BE36AA803321C2383DE86AD

        I'm not really sure what to make of this. At this point I have managed to identify at least 3 different Serpent implementations.
        Show
        David Hook added a comment - - edited You'll appreciate it completely contradicts the original we received. Actually, no it doesn't, well not quite, but I'm not sure if it helps. If you feed: key=00000000000000000000000000000000        00000000000000000000000000000000 plain=000000000000000000000 into BC you get: 9FAA1E723BE36AA803321C2383DE86AD I'm not really sure what to make of this. At this point I have managed to identify at least 3 different Serpent implementations.
        Hide
        kerukuro added a comment - - edited
        Sorry for being a PITA. The test vector is a hex string, this is the source of confusion. Think about the byte level. The encrypt method of the cipher engine accepts an array of bytes:

        public final int processBlock(
                byte[] in,
                int inOff,
                byte[] out,
                int outOff)

        This is the Serpent test vector:

        key=00000000000000000000000000000000
               00000000000000000000000000000000
        plain=000000000000000000000
        cipher=9FAA1E723BE36AA803321C2383DE86AD

        Since the test vectors are in the "last-byte-printed-first Serpent printout format", as clarified by Eli, this vector represents the following byte array:

        byte[0] = 0;
        byte[1] = 0;
        ...
        byte[15] = 1;

        And this byte array should give the result matching the test vector in the same printout order, i.e.

        byte[0] = 0xAD;
        byte[1] = 0x86;
        ...
        byte[15] = 0x9F;

        However, if the same byte array is fed to the processBlock() method in BC, it produces a different result, right?

        The test vectors pass only because they are interpreted as "first-byte-printed-first" instead of "last-byte-printed-first" when they are converted into byte arrays.
        Show
        kerukuro added a comment - - edited Sorry for being a PITA. The test vector is a hex string, this is the source of confusion. Think about the byte level. The encrypt method of the cipher engine accepts an array of bytes: public final int processBlock(         byte[] in,         int inOff,         byte[] out,         int outOff) This is the Serpent test vector: key=00000000000000000000000000000000        00000000000000000000000000000000 plain=000000000000000000000 cipher=9FAA1E723BE36AA803321C2383DE86AD Since the test vectors are in the "last-byte-printed-first Serpent printout format", as clarified by Eli, this vector represents the following byte array: byte[0] = 0; byte[1] = 0; ... byte[15] = 1; And this byte array should give the result matching the test vector in the same printout order, i.e. byte[0] = 0xAD; byte[1] = 0x86; ... byte[15] = 0x9F; However, if the same byte array is fed to the processBlock() method in BC, it produces a different result, right? The test vectors pass only because they are interpreted as "first-byte-printed-first" instead of "last-byte-printed-first" when they are converted into byte arrays.
        Hide
        David Hook added a comment - - edited
        I get that. I'm not sure how to deal with it though, the Serpent implementation dates back to 2001, before the Nessie vectors were even published. At the time it was largely compatible across the board. As I mentioned earlier I've also found no less than 3 versions of serpent, the majority fall into the "NIST out of the box"/"Nessie out of the box" category, and I'm afraid there's a couple where they picked up the input reversal but not at the right level. I've confirmed the GNU one has now changed as well (when this first came up they were the same as us), as they are the custodians OIDs we need to follow their implementation, or pull ours altogether and just rename it Tnapres.

        But really my advice to you, or anyone in your position, if you don't want to use AES, either use Twofish or Camellia. There's a much bigger problem here than our implementation.
        Show
        David Hook added a comment - - edited I get that. I'm not sure how to deal with it though, the Serpent implementation dates back to 2001, before the Nessie vectors were even published. At the time it was largely compatible across the board. As I mentioned earlier I've also found no less than 3 versions of serpent, the majority fall into the "NIST out of the box"/"Nessie out of the box" category, and I'm afraid there's a couple where they picked up the input reversal but not at the right level. I've confirmed the GNU one has now changed as well (when this first came up they were the same as us), as they are the custodians OIDs we need to follow their implementation, or pull ours altogether and just rename it Tnapres. But really my advice to you, or anyone in your position, if you don't want to use AES, either use Twofish or Camellia. There's a much bigger problem here than our implementation.
        Hide
        Peter Dettman added a comment -
        We have modified SerpentEngine to not do any byte-order swapping for keys, plaintext and ciphertext blocks. A new TnepresEngine has been added retaining the historical behaviour of SerpentEngine.
        Show
        Peter Dettman added a comment - We have modified SerpentEngine to not do any byte-order swapping for keys, plaintext and ciphertext blocks. A new TnepresEngine has been added retaining the historical behaviour of SerpentEngine.
        Hide
        David Hook added a comment -
        A corresponding Java change is now available at http://www.tsg911.cn/betas.
        Show
        David Hook added a comment - A corresponding Java change is now available at http://www.tsg911.cn/betas .

          People

          • Assignee:
            Peter Dettman
            Reporter:
            Stefan Thöni
          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: