You're making a fool of yourself. Try again to look at the basic concept. For EVERY POSSIBLE cleartext of the correct length, there is a key that decodes your ciphertext to it. Every. Possible. Cleartext.
Pick whatever method you use to decide if a cleartext 'makes sense'. EVERY POSSIBLE message that fits your criteria will be output during the brute forcing process.
You don't seem to realize just how nigh-infinite the number of different keys there are. If I give you a kilobyte blob of one-time-pad data, it could be any [sub-minute-long] sentence that has ever been spoken or ever will be spoken in the history of the human race, in any language.
.
I can explain it a different way, that will explain how you can kill the signal. Okay so the original message has 0s and 1s.
1. What happens if we take a 1 and have a 50% chance of flipping it: we get a 0 50% of the time and a 1 50% of the time.
2. What happens if we take a 0 and have a 50% chance of flipping it: we get a 0 50% of the time and a 1 50% of the time.
3. What happens if we know someone had a 0 or 1 and had a 50% chance of flipping it: we get a 0 50% of the time and a 1 50% of the time.
4. What happens when we try to figure out the original bit: Well both 0 and 1 have the same output, so it is fundamentally impossible to figure it out without knowing if they flipped it.
5. Repeat for every bit. Store which ones you flipped. Congratulations, you have a one-time-pad utilizing the XOR method of application.
.
Also you're right that adding noise as in addition won't mask a signal, but we're not 'adding'. We're looking at the signal, and the completely random noise, and marking down whether they match or not. If I tell you that bits 1, 2, 3, 5, and 8 matched my coin flips that doesn't tell you a single thing about what my data was.
Pick whatever method you use to decide if a cleartext 'makes sense'. EVERY POSSIBLE message that fits your criteria will be output during the brute forcing process.
You don't seem to realize just how nigh-infinite the number of different keys there are. If I give you a kilobyte blob of one-time-pad data, it could be any [sub-minute-long] sentence that has ever been spoken or ever will be spoken in the history of the human race, in any language.
.
I can explain it a different way, that will explain how you can kill the signal. Okay so the original message has 0s and 1s.
1. What happens if we take a 1 and have a 50% chance of flipping it: we get a 0 50% of the time and a 1 50% of the time.
2. What happens if we take a 0 and have a 50% chance of flipping it: we get a 0 50% of the time and a 1 50% of the time.
3. What happens if we know someone had a 0 or 1 and had a 50% chance of flipping it: we get a 0 50% of the time and a 1 50% of the time.
4. What happens when we try to figure out the original bit: Well both 0 and 1 have the same output, so it is fundamentally impossible to figure it out without knowing if they flipped it.
5. Repeat for every bit. Store which ones you flipped. Congratulations, you have a one-time-pad utilizing the XOR method of application.
.
Also you're right that adding noise as in addition won't mask a signal, but we're not 'adding'. We're looking at the signal, and the completely random noise, and marking down whether they match or not. If I tell you that bits 1, 2, 3, 5, and 8 matched my coin flips that doesn't tell you a single thing about what my data was.