>>471
While that may be the case, C# is (conceptually) based on C++ and Java, which are both more recent than the BASIC variants on which VB.Net is derived. Also the original BASIC dates back the 1960s and even back then, it had many high-level abstractions that C still doesn't have now (proper string support for example). I strongly suspect MS had VB in mind for a reference model when designing a large portion of C#'s featureset, too.

Regardless, I really didn't mean for my nonsensical comment to get into a drawn-out discussion about the differences between orange-flavored apples and apple-flavored oranges. Back to the topic at hand...

I have been considering some qualities that would make a tripcode decidedly more difficult to crack. In particular, using SJIS, especially in the 2nd and 3rd position of the tripcode. Since an SJIS character is (obviously) not in the range [A-Za-z0-9/], the corresponding byte of the salt will end up as ".", but as it uses the high bit, the actual byte value as far as DES is concerned is (c & 0x7f). Now, looking at the SJIS table, if we only work with halfwidth katakana, we will end up with what amounts to another representation of all numbers and uppercase ASCII letters that produces a separate salt value. (Lowercase letters correspond to double-byte characters and are a bit more complex, but the underlying principle is the same.) Considering the possibility of an SJIS character in any combination of position 2, 3, both, or neither, an SJIS tripcode is theoretically four times as difficult to crack as one using plain ASCII.

As an example, #12345678 produces the tripcode !WBRXcNtpf. -- produced by crypt("12345678", "23"). To illustrate the effect of stripping the high bit, the key #ｱ23ｴｵｶｷｸ of course produces the same tripcode because the salt is the same and all of the high bits are stripped without any side effects. However, the key #ｱｲｳｴｵｶｷｸ instead produces !XlUiP8mHCU, the result of crypt("12345678", "..").

Since the high bit is simply stripped from the other six positions in the key, a tripcode searcher can conveniently ignore the possibility that the input data might be SJIS, and iterate through all ASCII characters in the range 1->127. (No SJIS character uses value 0x80, so we don't have to worry about any 0x0 bytes, and this reduces the total character set by one.) Then check if the second or third byte is in the range [A-Za-z0-9/] and substituting the first and second byte of the salt as appropriate.

One must keep in mind, though, the fact that such tripcodes are sometimes a pain to enter due to character set conversions and implementation differences, and when searching for a "safe" tripcode none of this applies. However, I would imagine using SJIS and so forth would make a tripcode much more secure, and it might be something to consider when looking for "vanity" tripcodes.