Forum Guidelines

This forum is for finished source code that is working properly. If you have questions about this or any other source code, please post it in one of the Discussion Forums, not here.
See more
See less

Rijndael (AES) Encryption (ver. 2)

  • Filter
  • Time
  • Show
Clear All
new posts

  • PBWin/PBCC Rijndael (AES) Encryption (ver. 2)

    Rijndael (AES) Encryption (ver. 2) for 4.0+/8.0+

    The code appearing in RIJNDAEL2.ZIP (available below) offers a drop-in replacement for my previous PB Rijndael/AES implementation originally posted in 2002 and revised in 2005. The primary improvement involves a considerable speed enhancement due to use of ASM (including MMX instructions) and controlled data alignment. See the implementation notes here and in RIJNDAEL2.BAS for information about conditional compiling to control inclusion of non-MMX code.

    * * *

    Rijndael has been designated by the NIST as "the AES [Advanced Encryption Standard] algorithm" and is described in FIPS-197, which is available here.

    Rijndael is free for any use public or private, commercial or non-commercial. This PowerBASIC implementation meets the AES standard for 16-byte block operations.

    This PB implementation is hereby placed in the public domain. Use it as you wish. My hope is discourage reliance on home-grown encryption schemes in favor of well-examined, strong, freely available algorithms.

    See the included TESTBED.BAS for an implementation example. All code requires compiler releases 4.0/8.0 or later.

    Implementation Notes
    • The algorithm operates on plaintext blocks of 16 bytes. Encryption of shorter blocks is possible only by padding the plaintext (often with zero bytes), which can be accomplished through several methods. The simplest method assumes that the final byte of plaintext always identifies the number of bytes of padding added, including the final byte itself.

         total plaintext bytes         = 30
         plaintext blocks encrypted:   = 2
         final block                   = chr$(x1 to x14) + chr$(0,2)
         total plaintext bytes         = 40
         plaintext blocks encrypted:   = 3
         final block                   = chr$(x1 to x8) + chr$(0,0,0,0,0,0,0,8)
    • Encryption key lengths can range from 1 to 32 bytes (8 to 256 bits).
    • Implementation is handled through an #INCLUDE file. No global data is employed. The code is thread-safe.
    • By default, MMX code is run if the MMX capability is available; if unavailable, 32-bit code runs instead. Conditional compiling (through %TRUE/%FALSE setting of the %INCLUDE_NON_MMX equate) controls inclusion of the 32-bit capability. The 32-bit code appears in the file RIJNDAEL32.BAS.
    • As presented, the code does not supply a ready-to-use encryption application. It offers necessary pieces only, as well as an illustration of their use. Always keep in mind that most encryption is broken because of implementation flaws and weaknesses.
    • Like most encryption algorithms, Rijndael was designed on big-endian systems. For this reason, little-endian systems return correct test vector results only through considerable byte-swapping, with efficiency reduced as a result. Because it adds nothing to the encryption security, an efficient implementation can avoid the byte-swapping by compiling with the %RETURN_LITTLE_ENDIAN equate set to %FALSE.
    • Because of the methods of data handling required for most encryption and hashing, PowerBASIC's LONGs should be used to assure correct bit-level results (as well as maximum speed).

    Greg Turgeon 01/2007 posting 11/2009
    Attached Files

  • #2
    problem when debug display on

    Hello scott

    First of all: impressive rewrite. Great!
    One thing though: if I wrap it in my app and use #DEBUG DISPLAY ON, it suddenly fails.
    I calls the PBMAIN code from the testbed.bas and the first encrypt returns a different cipher.

    Any ideas why this might occur?

    Jeroen Brouwers


    • #3
      the code includes look-up tables which are destroyed by inserting debugging code. You need to supress the debugging code in those places.



      • #4
        Paul has the answer. The IDE's debugging capability can be priceless, but debuggers depend on tactics that can have unavoidable side effects. These effects usually don't matter and aren't even noticeable, but you've found a good example of an exception.


        • #5
          Thanks for the quick reply. I'll try to work around it.