A brief introduction to tripcodes:
For the sake of this blog, allow me to define the following terms:
crypt(3): The function used commonly for tripcodes
DES: The algorithm crypt(3) uses to generate a tripcode
Passcode: The input to the algorithm (your password)
Tripcode: The output to the algorithm (what everyone sees)
The original imageboard software had a bit of a problem when it was being developed: space constraints.
Images take up a large amount of space, but are predictable in terms of max space used (an upper bound can be placed on how large a picture can be, and it can be assumed every post will have a max picture), which allows for exact fitting (buying exactly as much space as one will ever use).
Text was also upper bounded, as was the amount of threads possible at any given point in time. These restraints allowed a single server to handle an entire imageboard at low cost, as there is zero variable space used....unless one wishes to allow user identification. Storing logins and passwords and dealing with all of the things related to that requires O(N) space used, where N is the amount of total users who have registered. Finally, it leads to internal fragmentation and waste; how many people will register and never use the imageboard again, compared to those who use it frequently or constantly?
Obviously, leaving no mechanism for identification isn't the best idea either (even on a truly anonymous board, there are times when one wants to be identified), but space was at quite the premium way back when, so a trade off was necessary: tripcodes. A tripcode is the result of a a cryptographic hash or symmetric cryptographic function being executed on a passcode provided by the user. It is uniquely predicated on the passcode provided, is extremely difficult to reverse (find the passcode given the tripcode), and most importantly, doesn't require any storage space.
Advantages:
Space-Time tradeoff: Constant space required for store tripcode for authentication
Anonymity: Tripcode can be discarded easily, serves only as authentication when it is wanted.
Disadvantages:
Space-Time tradeoff: Unbound amounts of CPU processing time required (function must be invoked every time a tripcode is generated)
Attacks: The passcode can be attacked through precomputed tables (rainbow tables).
The idea is sound, but there were a few problems, mostly dealing with the cryptographic function used. It needed to be relatively fast, but not too fast; too fast and it could be precomputed, too slow and it'd lag the entire server. The function also needed to have security against a wide array of attacks, such as known plaintext attacks; one can obviously ask for any tripcode one wants using any passcode one wants, so it must be hard to find a particular tripcode based off of any particular passcode.
The Unix crypt function was both widely available, fit all of these requirements, and therefore was used, with modification for the new authentication method.
Tomorrow, I'll talk more about crypt, and move into how we generate a tripcode we want.
