SHA384.jpg
[Hide] (468KB, 1000x667) Thoughts on a new standard for cross-site tripcodes for open-source imageboard software.
The current implementation of tripcodes (as used by futaba channel -> 4chan, tinyboard/vichan boards, and many others including this site) uses an ancient method involving a very strange DES system that has many collisions and has a password limit of 8 characters, with an output of 9.25 characters encoded in pseudo-base64 for a total of 10 displayed characters with the last character space having only 16 of 64 possible values. It's still used to this day for its software support including the ability to generate vanity tripcodes for use with cross-site verification, but it is quickly showing its age and the entire thing does not seem very well thought out.
I have a proposition for a new cross-site or "insecure" tripcode standard. By "insecure" i am referring to the fact that it is not salted and therefore would be able to work across websites which is actually a desirable feature; "secure" tripcodes which are salted and only work on a per-site basis. This is not to say my methodology is not secure: mathematically, my "insecure" tripcode would be far more secure than, say, 4chan's "secure" tripcodes.
My proposition is to use SHA-384 and instead of encoding the digest into hexadecimal (which would be longer) you would instead encode it into base64 to make it shorter. This has many advantages:
-Base64 is very similar to the character space of existing tripcodes. The only difference in character space would be the removal of the "." character and the addition of the "+" character.
-Would contain the entire english alphabet unlike hexadecimal, same as old tripcodes.
-Pretty secure, low chance of collisions, I don't see why there would have to be a password length limit either.
-SHA is pretty fast and therefore the generation of vanity tripcodes should be possible, while still being considerably secure.
The use of SHA-384 is due to the fact that you would be able to encode the digest into base64 without the need for padding. The total tripcode length would be 64 characters long after the "!" but fear not, because I propose that using CSS and/or HTML, you would hide the last 75% of the tripcode (but not actually truncate in a destructive way) and only display the first 16 characters for appearance reasons. Vanity tripcodes would still be rather attractive as it would be easier to attain an attractive-looking first 16 characters, however, the entire 64 character tripcode could be displayed to anons by either hovering over the tripcode or clicking on the tripcode. Someone wishing to impersonate you would still be inclined to "crack" this entire 64 character string, which would be quite a feat. As far as hiding most of the tripcode and hovering or clicking to display the entire thing, I do not believe that this would require javascript to implement for any reason.
These should be able to work across any imageboard, textboard, or any kind of website that implements it. You would be able to cross-site verify with ease. The developer of whatever imageboard software would need to run the password through sha384 and encode the binary output as base64. It would need support from the open source IB developers (lynxchan and jschan, possibly others) who are not exactly good company. It would also not need, but very much benefit from, the same kinds of tools that are used to generate vanity onion addresses and current tripcodes. A tool that could generate vanity tripcodes for this new standard being made would be a significant help to its implementation.