As depicted in the diagram above, the PPP cryptographic algorithm is quite straightforward. On the left, is a cryptographically strong, keyed, pseudo-random sequence generator whose 128-bit output is used to derive individual passcodes by mapping the value into variable-size character sets.

The character set mapping is performed by the loop on the right which successively divides the large 128-bit pseudo-random value by the size of the chosen character set. The remainder from each successive division is used to select the next passcode character.

The 256-bit PPP "Sequence Key" directly provides the key for the AES-standard keyed Rijndael block cipher. A 128-bit sequence counter is initialized to zero for the first passcode, then increments once for every subsequent passcode to provide encrypted data that are translated into individual passcodes for printing on PPP passcards.

The passcode character set is always sorted from low-to-high in "ASCII" order. Then, the remainder from each successive long-division operation is used to select one passcode character from the sorted character set.

In the case of the PPP Standard 64-character set, the "remainder-to-character-selection" would look like this:

As shown in the table above, a division remainder value of zero (0) translates into the character '!', a remainder value of fifteen (15) translates into the character '@', and a remainder value of sixty-three (63) translates into the character 'z'.

That's all there is to it. While getting the details correct is important for repeatability and inter-system compatibility, the PPP CryptoSystem is straightforward to implement and use. It owes its strength not to any internal complexity, but to the well-tested and proven strength of the underlying Rijndael cipher.

There are two modes of attack against the PPP system: online and offline. The examples and discussion below applies specifically to the PPP Standard 64-character set using 4-character passcodes. The numbers can readily be scaled for larger and smaller character sets and longer or shorter passcodes:

The Online Attack:
In an online attack against PPP, a remote attacker attempts to pose as a valid client authenticating themselves to the server. As we know, a successful authentication first requires account identification so that the authentication server can lookup the client's current passcode information. Once that has been done the authenticating server should prompt the client for both their static secret passphrase and the next sequential passcode. These items should be collected simultaneously to prevent an attacker from obtaining information about the correctness of either item separately. No diagnostic information should be provided in response to a failed authentication other than to acknowledge the authentication failure and then re-prompt for the re-input of ALL three items. Note that the server should prompt the client for their secret passphrase and next passcode even if their account identification is invalid. This prevents attackers from probing the system for valid account IDs.

The online attack against this system is, therefore, performed by brute force guessing three separate pieces of information, none of which can be independently verified: the client's account ID, secret passphrase, and next passcode. Given the known strength of the Rijndael cipher, and the use of a high-quality source of random sequence keys, the passcode sequence is completely unpredictable. Therefore, not withstanding the client's unknown account ID and unknown secret passphrase, all possible passcodes are equally likely to occur, so any passcode guess has a 1 in 16,777,216 chance of being correct. An unknown account ID and a difficult-to-guess passphrase further increase the futility of attempting to authenticate by brute force.

If desired, the authentication server may opt to introduce a penalty delay into any failed authentication response and retry to limit the speed with which guesses can be submitted. And once some low upper limit of failed attempts has been reached (such as five successive failures), the attacker's remote IP address can be silently placed into a timed-expiration grey list to cause all subsequent attempts to fail without any authentication testing.

With these easily implemented remote abuse safeguards in place, even if both the client's account ID and their secret static passphrase were known in advance — which would, of course, render any conventional username and passphrase system completely vulnerable — an attacker would still only have one chance in 3,355,443 of correctly guessing the always unknowable passcode within five tries.

The Offline Attack:
The methodology of an offline attack on PPP is entirely different from the online attack. The idea behind an offline attack is to use high-speed brute force testing of millions and billions of possible Sequence Keys in an attempt to discover the secret sequence key associated with a client's account.

To attempt to determine the secret 256-bit Rijndael key an attacker would need to assemble several 128-bit Rijndael output blocks in order to decrypt them to obtain their original input counter values. Since 5.333... passcodes are generated from every 128-bit Rijndael code block, as many as ten passcodes could be needed to obtain just one 128-bit block. Since several code blocks would be needed to confirm a possible key match, many more (20, 30, 40 or more) successive passcodes would be needed.

So let's assume the worst-case scenario, which is that an offline attacker obtains a client's entire PPP passcard. By reversing the binary-to-character algorithm shown above on this page, the card's 70 passcodes would give the attacker about 13 sequential 128-bit encryption blocks to decrypt. This would be sufficient to test and confirm sequence key guesses with a high degree of confidence.

BUT . . . there's one big problem (big for the attacker, that is): The possible sequence key space is SO large that searching it, even at the highest speed imaginable, is utterly infeasible.

As was mentioned on the "PPP Design" page, 2²⁵⁶ possible keys is approximately 1.158×10⁷⁷. For the sake of establishing some sense of scale, let's assume an impossibly fast speed of one processor clock cycle per decryption and test. In reality many hundreds of processor clock cycles would be required to test a key by using it to decrypt a known Rijndael block back into the known counter input. But for the sake of getting a sense of scale, this would mean that a 3 gigahertz processor could test 3 billion keys per second. Even at that speed, testing all possible equally-likely keys would require 3.860×10⁶⁷ seconds, which is approximately 1.223×10⁶⁰ YEARS! And even if we had a distributed network of one billion machines each decrypting at the impossible speed of 3 billion tests per second, those billion machines would still require 1.223×10⁵¹ YEARS to test the entire key space. Although the proper key would likely be found before the entire key space had been tested, there would be a 50hance of discovering the proper key in half of this time. But that's still 6.115×10⁵⁰ YEARS for just a 50/50 chance of finding the key!

In conclusion it should be evident that attacking the PPP CryptoSystem through an offline brute force attack to determine the sequence key is absolutely infeasible. No significant portion of the possible key space can be tested within any practical period of time.

The Statistical Analysis page provides a conceptual overview and analysis of the statistical consequences of extracting members of arbitrary size character sets from PPP's 128-bit entropy source.