Frog

• 1. Origins And Submission

  ›

  In 1998, a Costa Rican software company named TecApro submitted an algorithm called FROG to the Advanced Encryption Standard competition. The submission came from three authors: Georgoudis, Leroux and Chaves. They proposed a block cipher that could handle any block size between 8 and 128 bytes. Their proposal also supported key sizes ranging from 5 to 125 bytes. This entry arrived during a global effort to find a new encryption standard for digital security. The team hoped their design would replace older methods used by governments and businesses worldwide.

  1

• 2. Design Philosophy

  ›

  Most block ciphers apply fixed mathematical operators like XORs or additions on data. FROG broke this pattern by using the secret key as executable instructions instead of mere data. An expanded version of the key functioned as a program within the system. The algorithm acted as an interpreter that applied this key-dependent program to plaintext. Decryption worked by running the same program in reverse order on ciphertext. This approach aimed to hide the exact sequence of operations even if attackers knew how the cipher itself worked.

• 3. Technical Implementation

  ›

  The reference C implementation of FROG contained only about 150 lines of code. Developers could write an assembly routine with just 22 machine instructions to perform full encryption and decryption. No bit-specific operations were required since all work happened at byte level. This made the algorithm run well on 8-bit processors. A version written in 8086 assembler achieved speeds over 2.2 megabytes per second on a 200 MHz Pentium PC. Much of the code was dedicated to generating the internal key rather than performing the actual cipher rounds.

• 4. Cryptanalysis Findings

  ›

  David Wagner, Niels Ferguson and Bruce Schneier published their analysis in proceedings of the 2nd AES candidate conference in 1999. They discovered that 2 to the power of minus 33 of all possible keys were weak. These specific keys allowed attackers to break the cipher using 2 to the power of 58 chosen plaintexts. Another flaw emerged where 2 to the power of minus 29 of keys were vulnerable to chosen ciphertext attacks requiring 2 to the power of 36 attempts. The weakness stemmed from the fact that some keys corresponded to inefficient or broken encryption programs within the system.

• 5. Performance Limitations

  ›

  Despite its compact design, FROG suffered from very slow key setup times compared to other candidates. Encryption speeds remained relatively low when measured against competing algorithms submitted for the standard. The complex key schedule required extensive computation before any data could be processed. This bottleneck made the algorithm impractical for high-speed applications despite its small code footprint. Researchers noted these limitations alongside the security flaws during the evaluation phase of the competition.