I'm a small government guy. If that comes as a surprise to you, then I need to write about politics more on this blog. However, a though has occurred to me regarding the size of our house of the lower house. Perhaps it is too big.I say it is too big because of a concept called Dunbar's number. Basically humans can only have social connections with about 148 people. When the first congress met there were 59 members. When the current sitting one hundred and eleventh congress first met, there were 434 members.I'm not sure how to solve this problem. Perhaps we can draw up congressional districts without regards for state lines, and have the state legislatures appoint senators. The lower house can be reduced to about 125 members, which will account for the local office, and non elected people in the capitol building the congressmen will have to interact with regularly.I don't pretend to have a clear answer to this problem, I just know that 400+ is to many people.

While I usually read El Reg for teh lulz occasionally they come up with an interesting nugget, like their article on a "severe" OpenSSL vulnerability (quotes theirs). This vulnerability comes to us courtesy of the University of Michigan, and is tied to a simple oversight in the OpenSSL code: It doesn't perform a verification pass on signatures before sending them to a client.
So all you crypto-nerds, how many of you do a verify on your signatures before you send them? Hands please? Nobody? Not even me? -- Yeah, we all tend to trust that our math Just Works. I mean it's a computer, you put in fixed input through a deterministic algorithm and you get the same output ever time. Right? Nope.

Computers, as we all hopefully know, aren't perfect. Trillions of minor errors happen every day, and they're usually compensated for: ECC RAM, cross-checks of math, etc. But because OpenSSL doesn't do a cross-check it's possible for those minor errors to creep into a transmitted signature. As the good folks from UMichigan explain in their paper if you can induce some minor errors in the OpenSSL signature math and collect a good signature and a large enough set of flawed signatures you can eventually derive the private key used for the signing.

That is all well and good, except it relies on errors in the system generating the signatures. These errors are rare (and pretty random) in the real world, so no problem, right? Wrong again Sparky! These clever folks came up with something I wouldn't ever have thought of.

Those of you who have worked on old Commodore computers probably know one of the first symptoms of a power supply going wonky is that the system starts acting up: Lots of random crashes, video corruption, etc. Why does that happen? Because the voltage being supplied to the system is fluctuating. Fluctuating voltages (specifically down-swings) cause all the magical voltage regulation hardware to go out of regulation, which feeds out-of-spec voltages to the chips, which in turn start making mistakes in their math.

The bottom line for this attack is an extension of that well-known Commodore problem: By putting controlled voltage fluctuations into the power supply of real computers (SPARC boxen running Linux) the UMichigan folks were able to induce errors in the math used by the real-world OpenSSL code and recover an actual key.
Continue reading "Interesting (impractial) OpenSSL attack"

So the point of this whole thing is trivial enough that I went ahead and did it: Go to Wikipedia and type in your birthday (month and day). Then you write down 3 events, 3 births, 3 deaths and 3 holidays.December 29
Events

• 1778 – American Revolutionary War: 3,500 British soldiers under the command of Lieutenant Colonel Archibald Campbell capture Savannah, Georgia without firing a shot.Way to go Georgia, just roll over and take it. Bitches.
• 1890 – United States soldiers kill more than 200 Oglala Lakota people with four Hotchkiss guns in the Wounded Knee Massacre.120 years later we're still treating the natives like shit & using the treaties to wipe our national ass -- Progress, we no can has
• 2003 – The last known speaker of Akkala Sami dies, rendering the language extinct.Interesting tidbit in honor of all those linguistics courses I took.

Births

• 1800 – Charles Goodyear, American inventor (d. 1860)A subtle reminder from the universe to check your tire inflation and wear pattern
• 1921 – Robert C. Baker, Inventor of the chicken nugget (d. 2006)Cue ironic chorus of "Nugget Man"
• 1967 – Andy Wachowski, American directorI still won't forgive him for the Matrix sequels. Filthy humans ruinsed a good thing.

Deaths (Excluding the "event" death)

• 1731 – Brook Taylor, English mathematician (b. 1685)
• 1737 – Joseph Saurin, French mathematician (b. 1659)
• 1891 – Leopold Kronecker, German mathematician (b. 1823)

Apparently not a good day to be a mathematician… Do I get any bonus points for a trifecta?
Holidays
Only 2 and nothing relevant: The 5th day of Christmas (but nobody cares aside from the song) and apparently St. Becket's day (patron saint of secular clergy, so I suppose that's appropriate with me being an ordained minister and all)

Blocked waiting for my either the software development group to give me new code to test or my FreeBSD build VM to give me a new OS build to test, so how about some random thoughts on programming?
 
I've reached the inescapable conclusion that all software development cycles can be expressed as a single equation: y=tan(x+(π/2))
X represents time (on a totally non-linear scale) with each interval of width π being the development of a software release and the zero point where the function crosses the X axis representing the release of the X/πth version.  The Y axis represents the state of the code - how "bug free" it is.  I'll call the Y value within a version the "completeness" of the code for simplicity.
This functional model actually works surprisingly well:

• During pre-0.0 release (X|0...π/2) the software is riddled with bugs and brokenness ("completeness" is negative - that shit don't work!).
  • At some point (X=(π+ε)/2) the software becomes at least functional (miniscule positive completeness), and is released to the unsuspecting public.
  • The initial release is buggy as shit, and massive patching and bug fixing happens
    (This is roughly from X|(π+ε)/2...3π/2 -- For the sake of argument let's call the 3π/2 mark the .1 release, or in MS parlance, "Service Pack 1")
  • The software continues asymptotically approaching infinite completeness -- that nirvana state of having no bugs...
• ...At which point Marketing comes along and says the users want new features -- On our graph this corresponds to one of the vertical asymptote at multiples of π.
  • Development begins on the next (N/π)-dot-zero release, starting al over again from negative completeness.

 
In practical terms software development is not a true function: Each development window is independent and shifted toward X=0, with some overlap between the currently released version and the version under development.