So, with the current ID generation code, people on dynamic IPs play by different rules than people with static ones, since just a small change in the IP will change the ID code entirely.
I have here an idea to change this, which I'd like some feedback on. The basic idea is to encode the ID bit-by-bit, and having each bit of the ID code depend on all the bits in the IP before it. What this would mean in practice is that an IP like "123.234.56.78" might encode as "poaSdo3W", "123.234.56.90" as "poaDdo4t", but "12.34.56.78" would encode as something entirely different, like "xzWc32D1".
This would reveal a little bit more about the IP, but combined with the "thread board" mode of ID generation the encodings would change between threads anyway so it should still be quite effective for privacy, but people on dynamic IPs would now be identifiable.
Technical details follow.
I was thinking this could be implemented with an algorithm along these lines: Take a symmetric block cipher C(key,b), where b is a block of at least 32 bits. Then, for N going from 1 to 32, take the N first bits (starting from the MSB) of the integer-encoded IP, and encode it with C(), select one or more bits from the output of C() (for instance, the first bits of the resulting block), and append this to the ID code. The key for C is selected as a combination of a secret key and certain other parameter, such as the thread number and board address.
Addendum:
In my case, C() would probably be RC5 or RC6, since they're simple to implement and accept long keys, thus avoiding the need to take a hash of the various piece of data that would go into the key.
Correction:
"poaSdo4t", not "poaDdo4t"
I think that's a stupid idea and would bring far too much confusion into the game. People with similiar IPs could be taken for each other and people could try to give other people's IP range away by revealing their own and pointing out that their ID is similiar to... etc.
They could only give the IP range away if they themselves were in the same IP range, and that's pretty unlikely. And personally I think it'd bring less confusion if similar IPs had similar IDs.
It's just another way of somehow compromising anonimity even if the requirements are "pretty unlikely" (which I don't agree with).
I think it would be better to implement the IP revealing feature that was talked about earlier.
I just judge that that problem as smaller than the current problem, which is that ID codes fail almost completely when people have dynamic IPs.
Also, as long as we're talking about anonymous posting, you can only reveal someone's IP range in one thread at a time. In the next thread over, all the IDs will be different again.
Can you present an example of a situation where it's actually beneficial that ID codes are foolproof? JISAKU JIEN behavior is usually easily detectable, just from the content of the posts.
If a dynamic IP user wants his posts to be identifiable within a thread, he can simply use a temporary name like the number of his first post.
PS. What is jisaku jien?
Well, if it doesn't actually do anything, the ID code becomes kind of useless. Shii would say to drop it entirely, no doubt, but I wonder if it can't be tamed to be a bit more useful.
Also, I think I'll implement this first for the wiki and for the annotation thing that I keep mysteriously mentioning, and see how it seems there.
Incidentially, the algorithm I described sucks ass. It reveals runs of zeroes in the IP. It either needs to pick the output bits from different places of the ciphertext, or feed back the ciphertext into the algorithm. Gotta think a bit more about how to do this right.
>>12
Hmm. What is it actually used for?
Identifying oneself (in lieu of a name): isn't the intended purpose. That's why they change regularly.
Identifying others: is only useful on rare occasions. (and will be less useful as the user base increases) If I don't remember anyone's tripcode, I'm sure not going to remember temporary IDs.
Identifying trolls: savvy trolls put 'sage' or something else in the email field to disable the ID. Non-savvy trolls are easy to spot even without the ID.
It seems the main use is as a quiet reminder not to shit the place up (because yes, you are identifiable at least to the point where your current access can be banned).
I wouldn't say drop it entirely, but maybe have it disabled by default. I don't think it's all that useful, and it makes people paranoid...
I think one should be able to configure it pretty detailed if wanted:
All of that is implemented, except the sage option, which might be a better idea for a default behaviour than the current one.
Also, the current default setup is for ID not to change at all with time, but to change between threads and boards instead. This seems a nice way to identify speakers in a single discussion, without sacrificing any privacy when discussing other things.
Well, here's an attempt at a much better algorithm than the ones described before:
Take a generic function for hiding information, F(key,data). This can either be constructed from a secure hash function H(data) as F(key,data)=H(data+key) or a from a symmetric cipher function C(key,block) as F(key,data)=C(key,truncate(data)).
Next, initialize a block of data B as either zeroes, or some fixed starting value (this should not matter much). Also initialize an integer I as the integer-encoded IP address.
Then, for N going from 1 to 32:
Extract the bit I_N (the Nth bit, counting from 1, starting at the MSB) of the integer-encoded IP. Calculate and set B = H(key,B). If bit 0 (or some other arbitarily selected bit) of B is 1, invert bit N of the integer I. Finally, set B = I_N+B.
I will now be the ID code corresponding to the IP. It will have the properties that if two different IPs have the same N first bits, the corresponding ID codes will also have the same first N bits. Furthermore, there is a one-to-one mapping between IPs and IDs (this was not true of the earlier algorithms, where several nearby IPs could have the same ID). Finally, if you know the key, the encoding is reversible - you can do this with almost the same algorithm, moving the extraction of I_N to the end of the algoirthm.
People familiar with crypto may notice that this is very similar to a cipher working in CFB mode on single bits.
I implemented this on the notes script, by the way.
I notice I made a typo in >>19. In the description of the loop, H(key,B) should of course be F(key,B).
I think this is a bad idea. I have local friends who use the same ISP and whose IPs are very similar to mine. This proposal would reveal (or at least suggest) the fact of these people's physical proximity to me.
Besides, with IPv6 hitting the mainstream in the next two years or so, there won't be much reason for dynamic IPs to even exist anymore.