That's because incandescents are sensitive to the quality of the fixture and electricity that they are receiving. If you have fixture that doesn't regulate power well, then you'll got through more bulbs; if you have very bad electricity supply (too much/little power in fluctuations) then you'll also go through more bulbs. This is because the bulbs typically directly receive electricity from the power outlet - no regulation, so too much power the bulb gets brighter; too little it dims.

CFL and Fluorescent bulbs overcome that through a regulator in the fixture (aka ballast), and sometimes a fuse as well; and the regulator gets destroyed instead.

LEDs overcome it by the chips in the bulb itself which operate as a regulator, and will probably get destroyed before the LED bulb itself is useless. I have no clue, however, what the quality of the electricity supply or fixture will do to an LED bulb though.

Yes you can encrypt and encrypted file - just as you described. However, you have to use a different crypto keyset to do it or you defeat the encryption by revealing too much information.

That was done extensively throughout the Cold War, and is a common use of OTP. It's highly secure, and very difficult to break due to that exact kind of thing.

To start, most software detects file types based on the content, not the file names. They may use a file extension as a basic filter, but often that's more of a user-interface kind of thing than anything else. So changing the file type is not really a help of any kind, it barely even obfuscates things - smart filters will adjust accordingly, and we've seen those plenty in email systems that appropriately detects "piz" files a "zip" files, etc.

I said using an RNG not a PRNG.

A synchronized RNG is generated by synchronizing the clocks on the hardware, and initial seed data. True, it's not a fully random RNG, but it is sufficient for the needs of a OTP crypt/decrypt function as I described.

I also never said it was perfect; just theorizing on a way that you could do it with shared hardware instead of having to share an enormous file.

And yes, OTP has been used to securely communicate many things. In many senses, the Enigma machine is a OTP kind of system using a hardware dataset as the pad; it's no considered such because it didn't do the normal XOR operation associated with OTP functionality, but is also has the same flaws.

In reality, OTP is used with a large dataset to securely communicate messages when you want to ensure that no MITM attack can be possible, and you may have multiple receivers. OTP was a common means of communication for the Cold War - know what book to pick up, page to start with, etc. It's a very secure means of communication; and it still used for secure communications today.

Like it or not, any means of setting up a security context (Diffie-Hellman, TLS, etc) is susceptible to MITM attacks (during the security context creation, and therefore extending to the rest of the session) due to the simple fact that you have to dynamically create the security context. The only resolution to that is an OTP security context.

Well, my favorite bug of my own was in a batch file I put on a Win95 system to clean out the Temporary Internet directory; only it didn't change its working directory and ended up deleting stuff from the Windows directory instead...learned that Win95 can be installed over itself at run-time, thus saving the system before I rebooted it.

That said, I'm a strong believer in defensive programming practices. Not only do they make the software more secure, but they also help catch your own bugs. As the one article in TFS says

Hint: Performance is only vital in very few locations, namely interrupt handlers deep in the Operating System. So it's not likely that performance is vital enough to skip checking the inputs to your functions.

Hint: Checking the inputs to your functions will almost always help you catch logic errors, prevent memory overflows, etc. IOW, they'll save you many man months of debugging by making many things obvious. You just have to be disciplined enough to do them.

There is no requirement to skip a character in one-time pads. You can read sequential bytes without any issue. That said, how you use the one-time pad data can certainly contribute to its worth or worthlessness.

Supposing that the first example is used as is, and the second example all the A's are skipped, that that's correct - there is no difference. However, there is a big difference if in the second example you don't skip the A's - the pad is degrading your security as it's not sufficiently random.

That's what mathematical ciphers do -- they establish a synchronized pseudo-random number generator. A synchronized truly random number generator is almost a contradiction in terms, although quantum encryption does provide a way to transmit truly random information to exactly one recipient, which is pretty much a synchronized true RNG.

I did not say using a PRNG, but an RNG - think RSA token. We have plenty of synchronized hardware-based RNGs that we use for authentication. You would just need to up the rate of the number generation, which may make it harder to maintain synchronization. RSA tokens are good for a couple years, but only generate numbers every 60 seconds.

There's a big difference:

With a normal cipher stream (RC4, etc) it's data that is shared on the fly to create the cipher stream in a shared state (TLS, Diffie-Hellman, etc). The fact that you have to create it on the fly leads to vulnerabilities and MITM attacks.

Conversely with the one-time pad you have all the data pre-shared; in my example of using an RNG (not a PRNG) - it's a synchronized hardware device that is shared. This is why a one-time pad is more secure than any normal cipher stream.

However, the problem with using an RNG is that the clocks can skew between the two devices over time. So it's not a very good source.

What I like about LEDs is that they are generally solid-state, so less prone to breaking.

What I don't like is the cost, and the reliance on chips to run them...at least, the ones that replace the normal lightbulb sizes...not to mention the price.

Back in my student days I had a runaway pointer. On one of mid-1980s Motorola 68000 Macs, it would trigger the power-off function if it wasn't running under a debugger. Talk about frustrating.

At least it was consistent.

Remember, this was back in the days before protected memory. Also, if memory serves, the MacOS and applications always ran in "supervisor mode" (analogous to "ring 0" on Intel chips), so your program 0wned the machine while it was running.

Now now, Windows X isn't any more exploitable by the NSA than most previous versions.

I prefer to call it "Windows Madison Avenue version" or "Windows encourage us to give up our privacy for convenience version" or "Windows get us to pay for Microsoft's bandwidth version".

Well, maybe some of the hardened distros, but your run of the mill distros have so much on them that hasn't been scrubbed from a security standpoint that it makes Windows look merely like swiss cheese instead of confetti.

If you are serious about security but still want a "full featured", not-so-rare-that-almost-nobody-has-heard-about-it, modern OS that runs on and takes advantage of a modern PC, look at either the security-hardened Linux distros, OpenBSD and other security-hardened BSDs, or maybe a custom-stripped-down version of Windows with all unnecessary services turned off AND having it sitting behind a special-purpose, minimalist, hardened firewall appliance. Oh wait, that wouldn't be a "full featured OS", nevermind.

Except math is explicitly forbidden from being patented.

They only way you destroy patent trolls is by tying money earned from the patented invention to the cost of developing the patented invention along with some percentage of profits. Thereby, if it costs $1 to create the patented invention you get to hold the patent until you earn $1 and the percentage of profits, which would happen really quickly (sell it one time); it it costs $1000 or $1,000,000 then you would hold it longer - e.g the market decides how long you get to hold it; outright sale of the patented invention to a third party would nullify the patent itself since you would have recouped the costs, and the prime motivator for patents is therefore enforced - that inventors be encouraged to invent new things - while equally destroying the troll market.

The problem is that your OTP needs to be random and text is far from random. A lot of things are known about the data in text, such as the range of possible byte values and the frequency with which different characters are used. These sorts of problems will make your encrypted text extremely vulnerable to statistical analysis.

Not quite. You can't repeat the pad the same way ever - that is, you don't want to wrap it or reset to known locations using any kind of protocol. You can, however, randomly skip around in some manner, as long as you only go forward and do not wrap. So you're data limited unless you have an infinite data source.

That said, you could probably use a synchronized random number generator as the shared pad data. The other side would only be able to decrypt messages for as long as they buffer the random number data; after which the message is lost to everyone for eternity. This could work for a TLS session where messages are exchanged with only a couple minutes (or preferably seconds) delay so that the buffer does not need to be very big.

Give the "worst-case" time left rounded to the nearest 15 minutes, with some maximum ("more than 2 hours, but I won't tell you how much more").

By "worst case" I mean the amount of time if the device goes into "maximum power use" mode and stays there until it shuts off.

Oh, and to further prevent profiling, as the battery drains or charges have the "switch over point" to the next "reported" value be slightly off of "real." For example, if it's got 38 minutes left, it will report "30 minutes." But change it to "15 minutes" at some random point between 25 and 35 minutes and, if the device starts charging, change it to "45 minutes" at some random point between 40 and 50 minutes.

Oh, and as for the percentage left, there's no reason for a web site to have that information.

The value of a one-time pad is that if you can get data securely to someone else only during certain time periods, you can exchange your pads at that time then you can exchange data securely whenever you want to (well, until you use up your pad).

It's really useful when one party, say, a government, is free to "broadcast" the encrypted information, say, over shortwave radio, and the other party, say, a spy, is only a listener. For the spied-upon country to detect the shortwave radio the spy is using will be very difficult, especially if it's in a country where such things aren't outlawed (scratch North Korea). If the spy can sneak into the country with his one-time-pad (say, maybe it's buried in a hearing aid or something) then he's good to go.