Slashdot Mirror

Doing some research... It looks like that's exactly it.

LED Christmas Lights, and how to fix them

Philips christmas lights - 60 LEDs using 2 legs of 30. Depends on the LED's own voltage/current resistance to prevent burnout by reverse current, and is actually 'lit' around 35% of the time.

Another AC design option might be to bridge-rectify the AC power to use both sides of the AC cycle. That would double the pulse rate, which might be better. But it would also double the average current flow, which would require a larger resistor to reduce it, with more power loss.
Alternately, a power supply with current control could produce high-voltage DC, which would eliminate light pulsing. That would come at substantial cost, and introduce potential reliability issues when compared to the resistor alternative.

One thing I think he's wrong on is that a simple rectifier circuit would decrease efficiency due to higher average current - I think it'd increase efficiency, but also double the apparent brightness of the string*. After all, it'd be lit 70% of the time, 'blinking' at 120Hz. You might need a 'larger' resister in the sense of higher wattage, but it wouldn't have to be larger in terms of ohms. With something built to a price point like this, they might be depending on that 35% duty cycle to halve the wattage rating of the resister.

If building from scratch, the solution might be to use smaller LEDs**.

As for the 'current limited high voltage DC supply', given that we don't need to change the voltage, a still pretty simple full-wave bridge rectifyer circuit with a cap and resister would work. You'd probably still be able to use the one that came with the lights; the voltage drop from the rectification would help.

*keeping in mind that human perception of 'brightness' is non-linear and highly variable due to our automatic adoption to wildly different illumination levels
**Possibly saving enough money to pay for the rectifyer circuit?

But wait! Is that stronger? Is ROT13 a group? We may never know...

In the analogue synthesizer era, it was common to use a Zener diode as a noise source. Here's an older writeup about a simple circuit with cryptography in mind. The A/D converter in this case is the one on the author's sound card.

In a public policy debate, the idea is supposed to be that the law in question is maybe actually good public policy in that it has indirect benefits for the public, as well as direct benefits for certain individuals.

For example, in the copyright debate, some people will argue that the copyright monopoly offers the population at large a benefit by giving an incentive for creators to create new works. Moreover, some people argue this even though they themselves do not have a significant financial stake in copyright; that is, they will only benefit through that indirect gain of more new works. The fact that some people will argue even this position even though they only gain indirectly gives some credence to the idea that it's a legitimate public policy argument.

On the other hand, you have the patent argument. A similar claim is advanced re: innovation. However, in my experience, everyone who defends (software) patents turns out to have a direct financial stake:

• patent holders (and patent-holders-to-be)
• patent lawyers
• the patent office

Obviously a government program that gives money to people of type A, B, and C is beneficial to people of type A, B, and C, and of course people of type A, B, and C are going to be in favor of such a program. But this is not evidence that such a program is good public policy, especially if it deprives other people of something (in this case, by granting a monopoly).

So when an individual in the patent debate turns out to have a direct stake in patents, I think it's perfectly reasonable to say "I'm not even going to bother reading that because I've seen this pattern far too many times over the last 15 years.

Johnson noise is the noise created by the fact that current is moving across a PN junction.

Not quite. I did a lot of work on this for a true random bit generator years ago, and Johnson (thermal) noise is the noise in a resistor, caused by brownian motion of ionized particles. The PN junction noise is different, and is caused by individual electrons jumping the potential barrier at the PN junction, sometimes called shot noise. See here. There's also avalanche noise, which is noise across a reverse biased PN junction after breakdown occurs, such as in a zener diode. This is typically much larger than regular shot noise.

Johnson noise is the noise created by the fact that current is moving across a PN junction.

Not quite. I did a lot of work on this for a true random bit generator years ago, and Johnson (thermal) noise is the noise in a resistor, caused by brownian motion of ionized particles. The PN junction noise is different, and is caused by individual electrons jumping the potential barrier at the PN junction, sometimes called shot noise. See here. There's also avalanche noise, which is noise across a reverse biased PN junction after breakdown occurs, such as in a zener diode. This is typically much larger than regular shot noise.

Relying on this permutation calculator since I've long forgotten how to do the math myself, so hopefully it's accurate.

Assuming alphanumeric characters only, pass length of five, gives you:
              45239040 Permutations.

Password length of five, letter case added (n of 62):
              776520240 Permutations.

Extending the password length two characters to seven (but ignoring case):
              42072307200 Permutations.

Password length seven, with mixed case:
              2478652606080 Permutations.

So adding length is certainly more effective, but adding case also increases the complexity a good bit, if you want to maintain a given length.

Hello,

Science is difficult and one may find that there doesn't exist definite answers on anything, hence it is very hard to be authoritative.

In your case, perhaps you would benefit from reading some litterature on Random Number Machines.

Hint: the grandparent is correct. Radioactive sources are deemed truly random according to QM, but not the way we can measure decay. This is enough to generate some autocorrelation and spoil the randomness.

An excerpt:

Santha, M. and U. Vazirani. 1986. Generating Quasi-random Sequences from Semi-random Sources. Journal of Computer and System Sciences. 33: 75-87.

"Several computational applications require a source of 'random bit-sequences.'" "Unfortunately, the available physical sources of randomness (including zener diodes and geiger counters) are imperfect [9]. Their output bits are not only biased but also correlated."

All the best.

Certainly. In fact, I'll let someone else comment for me :)

Cipher reference

Esssentially a quantum computer provides many remarkable benefits, but it does not completely obliviate the benefits of a large bit size for a standard symmetric cipher, in this case you have essentially half the bit length equivalent, or 256bits...that's still a bloody huge number:

115792089237316195423570985008687907853269984665 64 0564039457584007913129639936

The big fuss about quantum cryptography is its effect on crypto systems with *known* faster than brute force weaknesses, such as public key ciphers. The problem in there is not a complete key space search, but a factoring problem. That's why we use 2048 and 4096 bit keys for RSA for example, a ludicrous size for a symmetric cipher but due to the inherent weakness in the algorithm, a necessity for RSA.

In this instance, the main defense for the algorithm is the difficulty in factoring large numbers, something which a quantum computer would be spectacularly good at.

Once again it may turn out that the availability of a quantum computer may make some algorithms weaker than expected, but it is not the mere presence of vast quantities of computational power that will break them. Nobody is going to wake up tomorrow and go, oh, by the way, we can hash the entire 160bit space of SHA-1 in a day. They will come up with cleverer and clever methods and techniques for reducing the search space utilising all the tools available, and eventually some (possibly many) algorithms will fall to one attack or another.

AC: If you'll admit, just once, that you're wrong, then all the time I've spent will have been worth it.

TSD: Wrong about what?!??!?!

AC: I just mean, in general, about being wrong.

TSD: First off, "in general" I'm not always wrong when I post in public. I do make mistakes [but /. can hardly count as a serious discussion forum] but you cannot sum up a persons entire existance to three posts or something.



You're defensive if you took that to mean that I think you're wrong in general. I mean that in general, when you're wrong, you don't admit it. You seem willing to admit that you COULD be wrong, and claim that you never claim to be infalliable, but I have yet to see a single instance of you unambiguously admitting that you were incorrect about something. At best, you side-step the issue, more usally, you resort to name-calling.

As for the cipher security, I was referring to this thread.

You seem to have convinced yourself that the crap you get in sci.crypt is from arrogant newcomers who are unwilling to face reality. While you've been around long enough to no longer be considered a newcomer, you yourself are still arrogant and unwilling to face reality. This is what I, fruitlessly it seems, am trying to get you to recognize.

I participate publicly in various forums related to my technical expertise. I have no intention of taking this particular project of mine public, since it has no bearing on my professional life. It is, however, something that needs to be said.

I don't choose not to participate for fear of making a mistake. Rather, I choose to refrain publicly from insisting that I am correct, and labeling anyone who points out the truth to the contrary as jealous, arrogant, or otherwise deluded.

BTW, I just pointed out above where you made claims that, among other things, "Of course anybody can make a cipher that is trivial breakable. But those that have survived all our known tests, are secure." This is a concrete instance of you "claiming that a cipher is almost certainly secure just because nobody has publicly proven it broken."

You just made a false claim of fact, which I can disprove. True, it's an understandable one, since the post was from a couple of years ago. The question is now, are you capable of saying something like: "you're right, I'm wrong, I made that claim", or will you have to qualify it in weasel-words and insults?

I was like you when I was your age, and I made an ass out of myself. Fortunately, I learned to knock it off before it negatively impacted my professional life. You stand a good chance of making serious mistakes with your life. Perhaps a good therapist could help you?

SCO threatens sue Linus

...yep I can remember it like it happened today my grandsons ... thousands of angry geeks stormed SCO place and torn the place apart, and then they marched to the Evil Empire(TM) and confronted the Prince of Darkness himself
yeah...in what was called the first geek revolution..

now seriously there should be no patents on software, or you will end up paying a royalty for something stupid like a patent for a blinking cursor??

act today, write your congressman.

I don't think Matsuis paper is available for free online. If you have access to a good (university) library you can find "Linear cryptanalysis method for DES cipher" by Matsui in Advances in Cryptology, Eurocrypt '93. The results were improved in "The first experimental cryptanalysis of the Data Encryption Standard", published in Crypto '94 by Springer Verlag in the "Lecture Notes in Computer Science" series.

Biham wrote "On Matsuis linear cryptanalysis", available at http://citeseer.nj.nec.com/biham94matsuis.html which contains a nice overview.

Terry Ritter has a literature survey at http://www.ciphersbyritter.com/RES/LINANA.HTM

When DVDs are burned and read, you don't simply read raw data off. The information is, of course, encoded. The DVD (and CD for that matter) specification says to use Reed-Solmon encoding. Saving the long math, RS encoding is about the most advanced error-correcting scheme that can be implemented in low-cost hardware today. By encoding data this way, your DVD (or CD) can become fairly scratched, but still play. RS protects against multiple-point errors. However, there is a price to pay - for every ~33k byte block on a DVD, almost 5K bytes are used in the parity checks for the DVD. See this file for more gritty details about DVDs. This means your 4.7GB DVD really holds about 5.48 GB of raw data.

Now, why is this relevant? Harddrives use their own error correcting schemes too. Manufacturers have the luxury of creating their own encoding systems since they're the ones that provide the read/write mechanisms. You can't pull the platter out of one harddrive and stick it in another. Hard drives typically use CRC (cyclic redundancy check) encoding schemes. I know you have all gotten CRC errors on a floppy way back when - that's what it stands for. Anyway, CRC is much less efficent when you compare the protected data to parity information ratios. While I wasn't able to pull the actual numbers from the Internet or my old math books, you can find a discussion and sample math here.

When you boil it down and relate all this information to our magical harddrive, the maximum usable density of the data would hover between 85%, or 6630 DVDs/in^2, to 60%, a measly 4680 DVDs/in^2, of the listed capacity. This is all assuming that the ideal lab conditions are maintained for a consumer level product.

As always, beware what the numbers tell you. However, if this can fly, then it would be an awesome step forward. Once you get Windows 2010 installed, you might even have a few Gig to play around with!

Terry Ritter offers us "Random Number Machines: A Literature Survey" which discusses random numbers from noise and other sources. Well worth a look.

Ritter expounds on Geiger counters:

Nisley, E. 1990. BASIC Radioactive Randoms. Circuit Cellar Ink. April/May. 58-68.

"While pseudo-random (pronounced "fake random") numbers may be OK for computer science types, Real Engineers get Real Random Numbers by timing nuclear disintegrations with a Geiger-Muller detector." "A few months ago I saw the RM-60 Micro Roentgen Radiation Monitor from Aware Electronics. It is a Geiger-Muller tube that connects to a PC's parallel or serial port, with the circuitry drawing power from a single interface pin."

Now they also offer canned software - a random number generator based on radioactive decay.

Terry Ritter offers us "Random Number Machines: A Literature Survey" which discusses random numbers from noise and other sources. Well worth a look.

Ritter expounds on Geiger counters:

Nisley, E. 1990. BASIC Radioactive Randoms. Circuit Cellar Ink. April/May. 58-68.

"While pseudo-random (pronounced "fake random") numbers may be OK for computer science types, Real Engineers get Real Random Numbers by timing nuclear disintegrations with a Geiger-Muller detector." "A few months ago I saw the RM-60 Micro Roentgen Radiation Monitor from Aware Electronics. It is a Geiger-Muller tube that connects to a PC's parallel or serial port, with the circuitry drawing power from a single interface pin."

Now they also offer canned software - a random number generator based on radioactive decay.

Terry Ritter, a really cool guy on sci.crypt, who happens to be a cryptographer suggests using a known algo along with a new algorithm. The tested algorithm (such as blowfish, or DES) provides security against known attacks. The new algo (such as the AES candidates, or something your best friend coded while he was drunk.. joking) can provide an extra layer to thwart cryptanalysis. Just use different keys for each step.

I love crypto, too bad I'm going to wind up as a crypto-narc one day.

/dev/random is not truly random, but it's as close as unclassified research knows how to make it, and it's damned good.

I don't think "use a Zener diode" or "get a chunk of radioactive stuff (try a smoke detector) and a Geiger conuter" are classified...