Hashes, Salts, and Trips, Oh My

The noise level over a few new posts by the "Q" account has increased lately. There exists a "hurricane" of opinions on this topic. I'm keenly interested in facts and analysis; here's where I stand.

Recently, someone who styles himself an “expert” of sorts in the “Q phenomenon” invited me to debate him on some topic regarding the authenticity (or not) of the recent “Q” posts.

I have no interest in taking him up on that.

The short story for those with little technical interest or patience to read the rest: tripcodes as they are used on 8kun might NOT be unique to a particular combination of usernames and passwords on 8kun—there’s some math below showing why. But it doesn’t matter.

The 8kun server system could trivially “detect and prevent” any such duplicates from being used, even if they did occur (and that’s exactly what I would do, if I were designing the system.) The authentication server could “lock the tripcode” assigned to a user such that the same code can’t be used by any other account, even if somehow a duplicate is generated.

If the 8kun source code is designed in that way, the possibility of “hacking” a duplicate tripcode—as computationally difficult as that may be—is therefore a red herring. It doesn’t matter, because it’s detectable and preventable. It’s a non-issue, even if its somehow computationally possible (but it’s damn difficult.)

Looking stormy out there!

In this essay, I’ll lay out what I know—and draw limits around what I do not know—in order to help others to at least understand the questions for which there are insufficient answers.

I’ll also explain why a “debate” isn’t of interest.

The simple truth: there is a hurricane of mostly unsupportable opinions around “salts” and “tripcodes” etc. that has arisen because there is a vacuum of hard facts, and this gets amplified by a miasma of confusion and poor understanding (possibly with some purposeful “help” from certain people with a vested interest in creating fog.)

The pot is continuously stirred up by people who have strong opinions but don’t know enough about these topics.

I’m not interested in a debate with Mr. expert because I’m not looking to engage in a battle of what amounts to mostly a contest of ego and opinion from people who have built their online personas around the “Q” phenomenon.

I’m not making a value judgement one way or another about various players; I don’t personally know the people involved well enough, or at all. I’m simply saying it doesn’t interest me personally to engage in an opinion brawl. It’s not what makes me tick.

I’ll say this up front very clearly, again, as I stated on social media over the last few days: the facts that I’m after exist within the source code and system architecture of the currently operating 8kun system, and only there. Old source code, while interesting, is insufficient.

If I’m able to review that source code, I can make my own assessments of what is likely or possible. Absent that source code, this essay is as far as I can go.

I studied math, engineering and science when I was younger, and chose a career in those fields over a career in law or politics for a good reason. I’m wired to be an analytical thinker, not a demagogue.

I’m not a traditional “influencer”, either: I’m just a nobody who has had some interesting life experiences in a number of technology-related areas; someone who has an interest in technical topics in addition to political ones.

My friends, family, colleagues and readers happen to enjoy my writing style and encourage me to continue doing it. I have also developed a considerable knowledge base about social media PSYOP techniques that I acquired over the decades through observation. My other substack posts about (anti-) social media delve into that.

This background, along with my former career, forms at least some of the basis for my interest in “Q” as well as in the information warriors who are arrayed against “Q”.

Let’s start with the background of the recent event. On June 24th, the evening of the day of the Roe v. Wade decision from the Supreme Court, some Anons noticed that a new post had appeared on the 8kun message board where Q had been known to post “drops” up until “he” stopped doing so in December of 2020. It appeared to have the same “tripcode” that “he” had used before.

I don’t know whether it’s “he”, or “she”, or “group” with regards to “Q”, nor does it matter for the purposes of this essay.

From now on I’ll use the formerly generic term “he” to refer to “Q” from now on just for simplicity. I’m also going to steer clear of making any assertions about “who” Q is; interpreting what the drops may or may not mean; or discuss how they tie into past and present geopolitical events. Plenty of other people discuss those things.

There was, and is, uncertainty and skepticism about the “authenticity” of those new posts, and potentially about older ones. I’m not going to go into various theories of “confirmation”, the need for plausible deniability in an operation such as this, or disinformation PSYOPs, or any of the other “explanations” for what might account for these new posts.

I’m just going to highlight a few facts and expose some questions.

I’m also not going to delve into any of the various “proofs” theories, get into the “why Q exists” questions, or enter into discussions about the blizzard of “poison the well” tactics that various oppositional information-warfare groups, politicians and the media are actively engaging in.

These tactics are used to muddy the water, undermine credibility, inject false narratives and distract and divide the community. You can see them employed daily if you know how to spot them.

The technique of “stapling on” a bunch of incoherent garbage, propaganda and false narratives onto what is actually a threatening and truthful narrative—in order to sink it—is a well-known information warfare tactic. In this kind of information warfare battle, finding and holding onto the truthful narrative is really hard, and not many can manage the process without becoming “black pilled.”

I guarantee you that kind of warfare IS happening, which by itself tells you there is something that several parties consider intensely threatening about “Q”. Nothing is what it seems, and many of you are following the wrong sorts of “influencers” without realizing the nature of the warfare that is going on around you.

I won’t get into who might be the “bad apples”, but I do believe Jordan Sather has a list worthy of consideration and I independently arrived at some of the same answers through my own analysis and observation.

Anyhow, there are plenty of other people who focus their attention on those subjects.

Let’s zero in on what interests me at the moment.

What we know from June 24th is this: someone posted a message on the 8kun qresearch message board—using the handle “Q” as well as the password that (we assume) had been used before to access that “account”.

That is the extent of what we know.

Shortly thereafter, someone accessed the “projectdcomms” board—what is called “Q’s private board”— and deleted what is believed to have been a “rogue post” by someone named “B”.

That message had no tripcode; it was allegedly put there by a board volunteer who somehow had access to that board back in May of 2021. Whatever the truth of this situation is, that post had been languishing untouched on that board until June 24th of 2022. Until it was suddenly deleted. By someone.

These are the bare facts. We do not know if “Q” actually did both of those things; if someone who had “Q”s password(s) (but wasn’t “Q”) did these things; or if rogue sysadmins at 8kun did these things. Nor do we even know if “Q” used two different passwords—one for the qresearch board, and one for the private board.

We also do not know if the “new Q” is the same as the “old Q”. All we can say is—assuming honorable behavior on the part of 8kuns admin staff, and a robust design for the authentication of the 8kun service— that “someone with the correct password logged in and took these two actions.” If the 8kun system is properly designed, even the 8kun sysadmins could not know whether there were two distinct passwords being used for these two purposes.

For these reasons, if the “new Q” is the same as the “old Q”, some other confirmations will have to come along to establish “plausible continuity”.

Let me pause here and say this. I am reasonably well versed in the general nature of cryptographic protocols and authentication systems. I know what salts are used for in the context of password protection; I know what salt rotation is and why it is actually a red herring in this recent blizzard of claims, which I wrote about here; I know quite well how hashing algorithms like SHA-256 are used to help to secure passwords in combination with salts.

I know very well how the 8kun system should work. I do not know (because I don’t have access to the source code) whether it does work the way it should work. I trust only the source code to show me that; I don’t trust anyone’s opinion regarding it.

Let’s talk in generalities for a bit to arrive at some numbers of interest.

I’m going to assume for the time being that the authentication system in 8kun uses SHA-256 hashes for passwords—just to explore some numbers. SHA256, if that applies, generates a 32-character base-16 string from a given user’s password.

I’m going to assume that the 8kun server keeps, in a database, the user’s “name”, the hash of his password in combination with a random n-digit salt, and the salt value itself.

It might also keep one other thing that I’ll get to later; but I’ll assume (if properly designed) that it does NOT keep the user’s password anywhere on the server for use in comparisons or for any other purpose (only the hash is kept for security.)

For this reason—the fact that the password isn’t kept on the server—salt values cannot be changed until the very moment the user next logs in and supplies the password again. The password is only kept in memory momentarily (if at all; newer auth techniques don't send it at all over the wire) and discarded. That whole line of “salt rotation to hack a tripcode blah blah blah” theory falls apart on this one point.

If the salt had been changed while “Q” was offline, then the hash could not have been regenerated (it depends on both the password and the salt) because there was no password available to recalculate the hash. If the “salt” change had been done anyway, “Q” would never have been able to authenticate again in the future, because the hash would be wrong. I also made these points here.

About “Tripcodes”. In order to display to other participants on the 8kun system that a given user has been “authenticated” in some way by the server, so that some number of future “posts” can be collectively attributed to that same particular user over time and across boards, a visual indicator called a “tripcode” is used.

It’s simply a string of 10 letters and numbers. The tripcode says, in theory: “we may not know who this anonymous person is; but he used the same password to login each time, and the self-same user wrote this post, that post, and the other post—which all have the same tripcode. It’s all guaranteed to be his voice, and nobody else’s. When you see the tripcode, you know it’s the same him.”

It’s a signature, in essence.

Again: we must assume, for the time being, that the tripcode feature is faithfully implemented and does what it is supposed to; if it doesn’t, the blame lies with the 8kun sysadmins and developers. Let’s assume for the time being they are honest and competent.

The tripcode may be calculated as some function of the user’s password hash, which would therefore make it also indirectly dependent on the salt value that is assigned to that user.

I’m going to explain later why that doesn’t matter. It may also be a function of other information such as IP addresses, but this too doesn’t matter; I’m not particularly interested in the tripcodes dependency on anything other than the hash (the rest isn’t relevant to me, you’ll see why.)

Let’s just follow this path for a while and see where it leads. The tripcode has 10 characters in it, each of which may (apparently) be an uppercase or lowercase letter or digit 0 through 9. That means there are 62 possible symbols to be chosen from in each of 10 positions; and that means there are 62 to the 10th power possible combinations of trip codes, assuming that repeated characters are allowed. That’s a massively big number.

That means there are 839,299,365,868,340,224 (834 quadrillion or 8.34 x 10^17 ) possible “tripcodes”.

Because the trip is “calculated” in some way from the hash (ignoring for a moment all other things it might also depend on), and the hash is a 32-character string with 32 positions of hexadecimal digits (therefore 16 possible choices of “digits” in each position), we need to know something about the size of the value-space of the hash.

With SHA-256, there are 3.4 x 10 ^38 possible unique hash output values. That means for every possible tripcode, there are roughly 10^19 (“sextillions”) potentially corresponding hash values. That’s a huge number of potential “duplicate” matches.

Because of the scale of these numbers, I’ll argue that it doesn’t (meaningfully) matter how the hash is constructed for the rest of this essay. It doesn’t matter what the salt value is, or how large it is compared to the password.

We’ll just focus on the number of possible hashes to make a point.

I’m going use the word “collision” here. Because there are 10 sextillion possible hash values for every possible tripcode, and because the hash value depends on the user’s password plus randomly assigned salt value, it follows that there are many possible hash values that could each “result” in the same tripcode.

Here, by the way, is an example of a SHA-256 hash of a complicated password, for those who aren’t familiar.

Let’s assume for the moment that however the tripcode is calculated, the odds of getting any one particular tripcode value is just as likely as any other value (i.e., the probability distribution is “flat”.)

Let’s take a swag at how long it would take to “brute force” the finding of a tripcode collision by searching through a bunch of hash values looking for a match under these somewhat ideal conditions, just to get a sense of things.

If you line up all the trip codes on one side, and all the possible hash codes on the other side, and tried to draw lines from one tripcode to a sextillion “collisions” on the hash side, you would still have to search through, roughly speaking, about 10^16 hash values (about 100 trillion) before you might find another hash value that would generate the same tripcode (a collision.) Something like that.

That’s a *lot* of computational work, but not impossible. If you could do one comparison every microsecond, it could take 3.17 x 10^8 years to find another possible match—that is, to find another hash that generates the same tripcode. (that’s on the order of the 1/10th the age of the Universe.)

If you somehow did a million such comparisons in parallel, instead of one at a time, you might get it down to a few years of continuous computation—just to find one collision.

OK fine, so you rent an NSA supercomputer for two whole years just to try to do this silly thing. Or let’s say that you somehow fiddle with the salt values to try to make the computational work of finding the next hash that matches to the same trip code a little bit faster.

So what? There’s an easy way to make sure that even if you go to the trouble to do this, it doesn’t matter. What could you do?

Quite simply: if you calculate the tripcode for a particular user’s hash, you save that tripcode in the 8kun user authentication database—along with the user’s hash. And if another user generates a tripcode for themselves (even if a rogue 8kun system administrator, who could have access to the authentication database, is fiddling with password and salt values to shortcut finding a match), you have a rule that says the new tripcode can’t be one that’s already been “memorized” in the database.

You simply check to see if you already have one with that value. If it wasn’t an 8kun sysadmin doing this searching, by the way, it would have to be the case that the authentication database or file was stolen (exfiltrated) to work on outside of 8kun.

That simple step—memorizing existing tripcodes— eliminates all of the shenanigans: even if you think its computationally possible to “hack a trip”.

To restate: you “lock the tripcode” so that nobody else, even if by accident or by brute force—can use the same one. You can’t algorithmically prevent a “collision” between tripcodes and hash values—but you can DETECT when they happen, and simply reject the duplicates.

This is a very simple and elegant solution that undercuts a lot of “theories” about “faking” or “hacking” tripcodes. You could go to a lot of computational trouble, and still —it wouldn’t matter in the slightest.

As I said before: this is how I would have done it. Is this what is currently in use in the 8kun source code? I don’t know. But until someone shows me the current source code, I see no value in “debating” any people who claim otherwise.

Show me the source code and spare me the hot air.

A final comment. With regard to the person who seemed interested in initiating a debate: I’m told (but I’m not certain) that this person was fired from 8chan before the move happened to 8kun—so what knowledge he may have had is not even necessarily useful.

He might not know, for instance, whether “trip locking” was added as a feature later.

With regard to getting fired: I haven’t been fired from a job (yet), but if that eventually happens, it will be for one of these reasons:

1. Incompetence (inability to meet the requirements of the job)

2. Incompatibility with co-workers or bosses (can’t get along well)

3. unethical behavior (stealing, lying, cheating, late to work, etc.)

You don’t tend to get fired unless it’s for one of these three reasons.

Sometimes you might get laid off from a job for financial reasons rather than being fired for incompetence; but it still means that you possess 'relative incompetence’. That is, the people who remained were deemed less incompetent than you, and they were selected to stay.

Also, it’s fair to say that incompatibility with co-workers doesn't necessarily mean "you're wrong and they're right" on some particular set of situations or points. You could be an honorable citizen among a band of crooks, or a smart person among a group of idiots, and they'll still fire you because you’re “incompatible”.

With all that said: if you are fired from a job, it tends to undercut your credibility. If somehow, after being fired, you still have access to the currently used source code for 8kun, and you’re ethically and legally allowed to share it, please do.

Otherwise, this is as far as I go.