Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror

Comment Re:Not surprising (Score 1) 283

Yes more expensive per bulb, but not more expensive when it comes to replacing bulbs. Much cheaper than CFLs in my view, for incandescent you just have to wait longer to amortize the cost.

I used to always have a few incandescent boxes because they were always burning out (it varies, I have one fixture that I haven't ever replaced a bulb in, and others where I replace them often).

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.

Comment Re:One time pad (Score 1) 123

I am a math geek. I am not now, nor have I ever been, a crypto-geek. I do have a dumb question...

Is it possible, and I will try to explain as well as I can, to have an encrypted file that, when decrypted, becomes an actual encrypted file which requires a password to open? I realize that may be a strange way to think about it.

Let's say that I have a file, a plain text file, and I put it into a password protected .zip file. That new file, the .zip, would then be encrypted, as a whole, into a new file - say file.tar.bz. Now, to open it, you would need to have the shared key PLUS you would need to know the password to the encrypted .zip file.

I understand that this has nothing to do with TLS and would be wholly impractical for browsing. However, the talk of encryption made me wonder about this and I have been pondering this for a couple of years now. It means it would be something you have and something you know.

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.

I can think of many ways to share the needed password/pass-phrase securely (for certain definitions of securely). Say, five books in a certain order on a bookshelf and calling with a series of numbers which determine with pages and words are used to make up the pass-phrase. A call could be as simple as, "Number 3, 27, 5, 18, number 7, 14, 32, 8. Confirm?" Which would be book number 5, chapter 3, 27th page, fifth and eighteenth words and book seven, chapter fourteen, thirty second and eighth word would be the password. This does not help if there is someone physically present.

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.

Anyhow, there may be some need to change the file type at the recipient's end because decrypting the file.tar.bz file will not necessarily mean that the file has the appropriate .zip extension but, well, that is pretty trivial.

What am I missing? This, obviously, has absolutely no value in the real world for almost every single person on the planet. I could see it being useful for TLAs or those who are trying to subvert their government (for a variety of reasons which may be good or bad).

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.

Comment Re:One time pad (Score 1) 123

No; a true OTP is NOT the same as pseudo-random OTP.

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.

In reality, nobody uses a OTP because if you can securely communicate the length of the pad, you can just as easily communicate the entire message. What is used instead is public-key encryption where your partner can encrypt a message, but only you can decrypt it.

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.

Comment My favorite... (Score 1) 265

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

Unless out-and-out performance is vital, checking inputs is always a good idea.

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.

Comment Re:One time pad (Score 1) 123

You can, however, randomly skip around in some manner, as long as you only go forward and do not wrap

You're just performing anti-compression / encryption on the pad, which was already perfectly encrypted.

There is literally no security difference between these two pads:

XOJIGQIOJG XAOAAJAAAIAAAAGAAAAAQAAAAAAIAAAAAAAOAAAAAAAAJAAAAAAAAAG (for every character you have already decoded, you must skip that many characters before reading the next character from the one-time pad).

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 said, you could probably use a synchronized random number generator as the shared pad data.

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.

Comment Re:One time pad (Score 1) 123

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.

That's roughly the definition of a stream cipher (e.g. RC4 or a block cipher in Counter mode). Only a cryptographically secure random number generator works, which is why such a thing is called a stream cipher and not just a "pseudo-random one time pad". In any case it's not a true one time pad because the entropy of the stream of pseudorandom data is limited to the entropy of the internal state of the cipher, and further limited by the entropy of the key. That means stream ciphers can be broken given only the ciphertext, as opposed to using a one time pad. Stream ciphers also share the same weakness as one time pads; reusing the same stream cipher key is just as bad as reusing a one time pad (virtually automatic recovery of all plaintexts encrypted with the same pad/stream).

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.

Comment Re:Not surprising (Score 1) 283

I never liked CFLs, they burned out as fast as my incandescents did, not even long enough to cover the cost of energy to make them. LED lights though seems a better deal overall; more expensive but also longer lasting with an even lower energy cost.

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.

Comment Runaway pointer shut down computer (Score 2) 265

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.

Comment Re:You forgot to include the quote Re:haha (Score 1) 123

Kind of convenient that they make this sort of "breakthrough" right after Windows NSA edition is given away for "free".

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".

Comment Linux distros secure??? (Score 2) 123

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.

Comment Re:SOFTWARE PATENT SHOULD BE GRANTED (Score 2) 123

A large number of people religiously state Software Patents are evil and should never be permitted. If the claims by Microsoft are true, then a Patent should be granted for this "mathematical" discovery. It is a significant improvement in security over existing encryption, and so deserves Patent protection.

Except math is explicitly forbidden from being patented.

I think that Patents should only protect PUBLICLY AVAILABLE products. In this case Microsoft can sell IIS Server / Edge Web browser ($0 cost) with enhanced encryption and the Patent will protect them from competition. Patent Trolls should be destroyed. They way to do this is to only allow legal action if you actually sell a product and other companies are reducing your sales or profits. If there is no reduction in sales or profits, your maximum gain from a Patent should be limited to $0.

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.

Comment Re:One time pad (Score 1) 123

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.

Comment Re:One time pad (Score 2) 123

OTPs are great. On the other hand, you have to use each pad only once. Ever. So to encrypt 1GB of data, you need 1GB of cryptographically random pad. Which you can never use again. And must be a secret with regards to the rest of the world. And must be present on both the sending and receiving end of the communication.

If I knew how to get 1GB of unique data (be in OTP pad or the real data) from the sender to the receiver in secrecy I wouldn't need encryption in the first place.

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.

Comment We need even less resolution than that (Score 1) 89

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.

Comment The value of a OTP (Score 2) 123

If I knew how to get 1GB of unique data (be in OTP pad or the real data) from the sender to the receiver in secrecy I wouldn't need encryption in the first place.

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.

Don't sweat it -- it's only ones and zeros. -- P. Skelly

Working...