A tripcode is a hash. Hash algorithms are made so that the result cannot be reverse engineered to figure out what the input was. A salt is a fixed random garbage that gets added to the input to make reverse engineering even harder (if it was possible at all). As long as the input and the salt are the same the result will always be the same. When you change the salt you're changing the input, the result will not be the same.
So if they "whitelisted" his tripcode, then they must have added another stage to the system where it will check the passwords entered by users with the old salt added for his result first, then if not a match do the hash again with the new salt. Either that or they have his plaintext password and now have the site check every user's entered password against that before proceeding with the hash which would be a really stupid idea.
The fact that they call this "whitelisting a tripcode" seems off to me. Instead of this whitelisting business what Q should have done was post what his new tripcode will be with the new salt before they changed the salt used by the site. Or better yet create a GPG key pair, post the public key before they changed the salt, and sign every post from now on.
Since he didn't do that, and since tripcodes are sus to me now, he'll have to include another future proof, such as a phrase he would ask Trump to use, along with his new public key in a post that will have many witnesses (witnesses to ensure the post wasn't created by the board admins after the proof occurs) in order to gain my trust as an example.
Agreed the whole "whitelisting" tripcodes sounds fishy, and I wonder why there is no explanation of what or how that was done. However, if I was developing something like that then I would:
Have the whitelist of trip codes
Have the salt and list of previous salts
Hash the password with salt, and previous salts
See if any of those resulted in a hash that is whitelisted
If so use that one. Otherwise use the one with the newest salt.
Doing a hash is not exactly computationally expensive, you can generate thousands a second on old hardware so I would not see an issue doing this with every tripcode ever posted.
Edit: also entirely possible to check a tripcode when it comes in and if it has a certain match to provide a different hard coded tripcode in place . This may be feasible depending on access to the code base and how it is architected.
I'm with you - I have wondered all along how someone was supposed to rig the salting to generate the same hash for a different password.
As for the whitelisting - the only way I could think of doing it is to fix the salt for a specific account and hardwire it into the hashing code itself. Not impossible, but certainly not a simple task either.
Personally I'm waiting for a trip coded drop with a zero delta before I'm 100% convinced.
Once again...
A tripcode is a hash. Hash algorithms are made so that the result cannot be reverse engineered to figure out what the input was. A salt is a fixed random garbage that gets added to the input to make reverse engineering even harder (if it was possible at all). As long as the input and the salt are the same the result will always be the same. When you change the salt you're changing the input, the result will not be the same.
So if they "whitelisted" his tripcode, then they must have added another stage to the system where it will check the passwords entered by users with the old salt added for his result first, then if not a match do the hash again with the new salt. Either that or they have his plaintext password and now have the site check every user's entered password against that before proceeding with the hash which would be a really stupid idea.
The fact that they call this "whitelisting a tripcode" seems off to me. Instead of this whitelisting business what Q should have done was post what his new tripcode will be with the new salt before they changed the salt used by the site. Or better yet create a GPG key pair, post the public key before they changed the salt, and sign every post from now on.
Since he didn't do that, and since tripcodes are sus to me now, he'll have to include another future proof, such as a phrase he would ask Trump to use, along with his new public key in a post that will have many witnesses (witnesses to ensure the post wasn't created by the board admins after the proof occurs) in order to gain my trust as an example.
Agreed the whole "whitelisting" tripcodes sounds fishy, and I wonder why there is no explanation of what or how that was done. However, if I was developing something like that then I would:
My brain hurts and I want hash browns now…
But here to say thank God we have people like you guys on our side too!
#MAGA
Nice and salty hash browns
This is how I see it as well.
Edit: also entirely possible to check a tripcode when it comes in and if it has a certain match to provide a different hard coded tripcode in place . This may be feasible depending on access to the code base and how it is architected.
I'm with you - I have wondered all along how someone was supposed to rig the salting to generate the same hash for a different password.
As for the whitelisting - the only way I could think of doing it is to fix the salt for a specific account and hardwire it into the hashing code itself. Not impossible, but certainly not a simple task either.
Personally I'm waiting for a trip coded drop with a zero delta before I'm 100% convinced.
This is pretty much exactly what I said. It must be the same 4 accounts downvoting lol.