What the heck are we supposed to take from this article...
So this guy clearly doesn't have access to any of the code, and he's trying to reverse engineer what he thinks specific algorithm's are doing... Okay, that's pretty difficult at the best of times... What do we actually have here?
After partitioning the numbers, CID numbers are segregated by county, any alphabetical characters are stripped out, and then a decimal point is added to the left of the number. These are then sorted in ascending order. By adding a decimal point to the left, the numbers are effectively changed into different numbers so that they sort differently. For instance, the following numbers are in ascending order: 1, 23, 111, 1081, and 15,000. After decimalization, they sort like so: .10000, .10810, .11100, .15000, and .23000. After this is done, the decimal points are removed, thus hiding their previous existence.
They don't really "hide their previous existence", they just made a new number. Cool, what do these new numbers actually being used for?
After this, the algorithm performs a series of calculations to determine how many times the number of voters in each partition can be divided by the following repunit numbers: 1,111,111, 111,111, 11,111, 1,111, 111, 11, and 1. From this, it calculates SBOEID numbers based on the repunits and the number of SBOEID numbers that will fit in each group.
Wait, what partition? We were talking about the new decimal numbers that associate with each CID. Now we are talking about partions of those numbers. How did those partitions get created? Apparently, we're taking a set of those new decimals, and doing a modulus calculation of 7 repunits... for what reason?
The algorithm then cuts each group of numbers [The results of the mods? The numbers of voters? The numbers of voters in the partition?], just like a deck of cards, putting the top half of the deck (lower numbers) below the bottom of the deck (higher numbers). Last, it interlaces the numbers belonging to each repunit to achieve the equivalent of a stacked deck.
Okay it sorts the results. Great. Why?
And what do you mean by interlaces? Are we saying the results of each modulus are then sorted into this pile of numbers you didn't state came from? Or are you saying that the results of each modulus are segregated in this "deck"?
And what the hell does any of this actually tell us?
After all these transformations have been performed, the scrambled list of CID numbers is attached to the scrambled list of SBOEID numbers.
So these new numbers are re-assigned to the CID's. Great. For what purpose?
At this point, the casual observer will see what looks like randomly assigned numbers. They are not random. They are deterministic and fully reversible.
I'm sure they are. No random number generator is able to generate truly random numbers. Many simple ones apply some complicated mathematics to the current date-time value when the computer is asked to execute the random number generation. All random number generators on a computer are deterministic... because computers are deterministic.
Although the presence of the algorithms in the voter roll database is unambiguous, the purpose remains unknown.
Great. So after all that we still have no idea why this code fires the way it does, or for what purpose.
So, if my CID is ABC12345, it gets turned into .12345, then converted into an integer of 12345, then mod'd by 1, 11, 111, 1111, 11111, 111111, and 1111111, giving me: {0, 3, 24, 124, 1234, 12345, 12345} ... and from that point on his explanation starts to become incoherent. All I know is that these numbers may be sorted among other blocks of moduluses. I'm going to just assume for simplicity, that u/AntonioOfVenice also participated in this vote with me, and has a CID of EFG90210. Preforming all the same steps I have my set of mods, and now his set of mods which are: {0, 10, 78, 219, 1322, 90210, 90210}. So then putting all the numbers in descending order (removing repeated numbers because it's probably designed in some way to prevent multiple entries): {90210, 12345, 1322, 1234, 219, 124, 78, 24, 3, 10, 0}... and then somehow these numbers are re-organized in some way to be re-assigned back to the original CID's. Which still doesn't tell me anything. That missing "how are they assigned part" is pretty important.
Every county official I’ve spoken with about this subject (they wish to remain anonymous) has stated they had no idea the algorithms existed. None had seen any sign of their existence.
No shit they don't fucking know. They're county officials. Their probably scared of fractions! I'll ask the elected official that is a former defense attorney, I'm sure he's well versed in programming and computational mathematics!
This is an "algorithm" you've reverse engineered that is probably comprised of several other functions, or is some sort of random number generator of some kind, that is apparently a subfunction of something else. Most of the software developers aren't going to know what the fuck you are talking about until they start looking into the code.
As anyone who knows anything about IT security, there is no way to save that database, it must be deleted and rebuilt from scratch. This is the only way to be sure. It also means that no election using that database can ever be trusted again, forever.
OP, this could be easily corrected by using any number of random number generator methods. If there's anything even wrong, which I still don't know. The data itself is fine, and does not need to be re-collected.
Worst case scenario, where we assume the author's rambling hypothesis, some individual CID's are tagged. Cool: remove the tags, re-assign new CID's. You don't need to delete any actual data record of a voter.
What the heck are we supposed to take from this article...
So this guy clearly doesn't have access to any of the code, and he's trying to reverse engineer what he thinks specific algorithm's are doing... Okay, that's pretty difficult at the best of times... What do we actually have here?
After partitioning the numbers, CID numbers are segregated by county, any alphabetical characters are stripped out, and then a decimal point is added to the left of the number. These are then sorted in ascending order. By adding a decimal point to the left, the numbers are effectively changed into different numbers so that they sort differently. For instance, the following numbers are in ascending order: 1, 23, 111, 1081, and 15,000. After decimalization, they sort like so: .10000, .10810, .11100, .15000, and .23000. After this is done, the decimal points are removed, thus hiding their previous existence.
They don't really "hide their previous existence", they just made a new number. Cool, what do these new numbers actually being used for?
After this, the algorithm performs a series of calculations to determine how many times the number of voters in each partition can be divided by the following repunit numbers: 1,111,111, 111,111, 11,111, 1,111, 111, 11, and 1. From this, it calculates SBOEID numbers based on the repunits and the number of SBOEID numbers that will fit in each group.
Wait, what partition? We were talking about the new decimal numbers that associate with each CID. Now we are talking about partions of those numbers. How did those partitions get created? Apparently, we're taking a set of those new decimals, and doing a modulus calculation of 7 repunits... for what reason?
The algorithm then cuts each group of numbers [The results of the mods? The numbers of voters? The numbers of voters in the partition?], just like a deck of cards, putting the top half of the deck (lower numbers) below the bottom of the deck (higher numbers). Last, it interlaces the numbers belonging to each repunit to achieve the equivalent of a stacked deck.
Okay it sorts the results. Great. Why?
And what do you mean by interlaces? Are we saying the results of each modulus are then sorted into this pile of numbers you didn't state came from? Or are you saying that the results of each modulus are segregated in this "deck"?
And what the hell does any of this actually tell us?
After all these transformations have been performed, the scrambled list of CID numbers is attached to the scrambled list of SBOEID numbers.
So these new numbers are re-assigned to the CID's. Great. For what purpose?
At this point, the casual observer will see what looks like randomly assigned numbers. They are not random. They are deterministic and fully reversible.
I'm sure they are. No random number generator is able to generate truly random numbers. Many simple ones apply some complicated mathematics to the current date-time value when the computer is asked to execute the random number generation. All random number generators on a computer are deterministic... because computers are deterministic.
Although the presence of the algorithms in the voter roll database is unambiguous, the purpose remains unknown.
Great. So after all that we still have no idea why this code fires the way it does, or for what purpose.
Every county official I’ve spoken with about this subject (they wish to remain anonymous) has stated they had no idea the algorithms existed. None had seen any sign of their existence.
No shit they don't fucking know. They're county officials. Their probably scared of fractions! I'll ask the elected official that is a former defense attorney, I'm sure he's well versed in programming and computational mathematics!
This is an "algorithm" you've reverse engineered that is probably comprised of several other functions, or is some sort of random number generator of some kind, that is apparently a subfunction of something else. Most of the software developers aren't going to know what the fuck you are talking about until they start looking into the code.
As anyone who knows anything about IT security, there is no way to save that database, it must be deleted and rebuilt from scratch. This is the only way to be sure. It also means that no election using that database can ever be trusted again, forever.
OP, this could be easily corrected by using any number of random number generator methods. If there's anything even wrong, which I still don't know. The data itself is fine, and does not need to be re-collected.
Worst case scenario, where we assume the author's rambling hypothesis, some individual CID's are tagged. Cool: remove the tags, re-assign new CID's. You don't need to delete any actual data record of a voter.