Identity Management Atoms: Cryptographic Hashes

Computer memory has almost no structure:  it's just a big field of "bits" collected into nice-sized chunks ("bytes", which are 8 bits,  are the most well-known, but these collections have varied over time, with some as few as 6 bits, to modern computers having 32 or 64 bits) -- and "addresses" to specify which particular block of bits you are referring to.  In terms of "raw data", these bits represent integers -- but not quite integers, because they can't hold negative values.  Instead, it is up to us to decide that a particular value -- or several of values, if it suits us --  means "199" or "-32" or "17.125" or "3/4" or "2.5 + 5.7i" or ever "Q" or "v" or "fuschia with 25% transparency" or "440Hz at 37dB" or "seconds since January 1, 1970".  And that is the beauty of this:  numbers can mean anything!

Ok, so I'm going off on a tangent.  I didn't quite mean to wax eloquent this -- but it's also tempting to pull out that paragraph and put it into its own atom:  raw Integers.  It is because we can encode anything as numbers, after all, that makes cryptography possible!

Now, while there's no structure to any of this at the lowest levels of the computer, one of the first things I learned in my Computer Science class is about data structures, which are made possible when one observes that an integer can represent a block of memory as readily as it can anything else.  Thus, with the simple idea of a "Node" and "Data", we can create "arrays" and "vectors" and "lists" and "trees", each with special properties and perils for keeping track of data.

One of these data structures is called a "Hash Table".  The idea is simple:  for some of these data structures, it can take a long time to find an item -- but we can make it incredibly fast if we took the data we wanted to store, "scrambled" the bits somehow, and then stick it in memory based on this scrambled "hash".

My toy hash table had a simple "scrambling" algorithm:  divide the number by 10, and use the remainder as a memory address in an array.  Thus, 29 would be stuck in "slot 9" and 77 would be stuck in "slot 7".  What happens if we try to stick "17" in there, when "77" is already there?  We then have what's called a collision -- and there are different strategies for handling when that happens -- in my case, I used a "list" to store all the possible values at that location, for example.  And this is a weakness of hash tables:  if we have a lot of data to store, we're more likely to get collisions, which is going to slow the whole thing down.

Hence, my little implementation being merely a toy -- it's only good for a couple dozen data points, in particular -- but it's sufficiently large to get an idea of how these data structures work!

Of course, in cryptography, there's no need to worry about memory locations -- but there is a need to be able to scramble a lot of data and reduce it to a tiny thing!  Functions that do that are called cryptographic hashes, and they typically take hundreds or even millions of bytes, and reduce them to a few dozen bytes.  These are also sometimes called "one way" encryption schemes -- they encrypt data, but they aren't intended to be reversible -- and what's more, reversibility would even lead to weaknesses in our cryptographic schemes.

In order for a hash function to be cryptographic, it has to satisfy several properties:

• Given two slightly different inputs (eg, two duplicates of a document, but one has the character in position 937 changed from the letter "A" to the letter "B"), the outputs need to be wildly different,
• Collisions between two different documents need to be rare, and
• For a given a hash output, it needs to be nearly impossible to identify or create documents that match that hash output.

The purpose of these properties is to make it possible to identify documents:  the first property ensures that even tiny changes will produce dramatic results; the second makes it less likely that two different documents will have the same identity, and the third?  It prevents the forging of documents.

The last property isn't just a theoretical concern:  a couple of popular algorithms, MD5 and SHA1, have already been compromised!  I'm not entirely sure if any attack had been successfully made against systems using these hashes, but they have been replaced with algorithms SHA256 and SHA512 -- which, oddly enough, is just SHA1 repeated 256 or 512 times, respectively.

There are two kinds of cryptographic hashes, which to the best of my knowledge, aren't really "named" -- but I like names, and this is a distinction that's rather important! -- so the first kind I call "digest" hashes, and the second, "password" hashes.

The purpose of the first type of cryptographic hash is to identify documents -- and when you have a document of millions or even billions of bytes you want to identify, you need to do it quickly.  And that's just what digest hashes do:  they take a big document, and give you a result quickly.  These types of hashes can be used in special data structures designed to detect changes quickly; they can be used to identify changes made to a project; they can be used to prove that a document was unchanged -- and because in this use-case, it's far easier to encrypt this little bit with a private key, than it is to encrypt an entire document, it is an important function for "signing" documents.  (Because of this, I have been tempted to call these hash functions "signing" hashes, but that confuses the issue:  signing is only one role, of several, of these functions, and all these roles are captured by the notion of "digest".)

But there are also situations where being fast can be disastrous!  The above conditions are perfect for storing encrypted passwords -- hence, my desire to call them "password" hashes -- and, in particular, these hashes can guard passwords against a data breach, when a password cracker gets a hold of lots of a lot of usernames and passwords all at once -- this is our last line of defense against crackers, because once they are in the hands of evil people, they are at the mercy of all the tricks that can be deployed against them.

In this case, we have a major advantage over the nefarious schemes of a cracker:  we don't really care if there's a few seconds of delay in getting our credentials approved -- but when a cracker has millions of password hashes, he's going to want to try as many passwords as he can, as fast as he can, to find the valid ones.  In this a day and age of heavy computation power, particularly with GPUs that can run millions of operations in parallel, a cryptographic password hash function needs to be able to throw "wrenches" into these works.  The latest algorithm for this purpose, called "scrypt", is not only specifically designed to be slow -- it requires a lot of memory in order to speed it up somewhat!  Since GPUs in particular are designed to do millions of small, memory limited functions in parallel, this means that a GPU is just as ineffective at cracking these passwords in parallel as a single fast microprocessor.

Identity Management Atoms: Universally Unique Identifiers and Nonces

I have a confession to make:  I'm not sure what role, if any, Universally Unique Identifiers (UUIDs) play in cryptography.  Nonetheless, I find them fascinating, and figure it would be useful to understand them, just in case.

A UUID is a 128-bit number (ie, 16 bytes) that does not need to be assigned from a "central" location (and thus doesn't need to have an internet connection to be generated), and has a very high probability of being unique.  They enable networks of devices to create packets of data and assign IDs for them, so that when they are brought together, very few, if any, of these packets will have the same ID.

There are 7 official versions of UUIDs and two "customizable" versions -- and anyone who needs an ID for their purposes doesn't even have to adhere to these standards.  Twitter, for example, created their own "Snowflake ID" standard, a 64-bit ID that has since been adopted (and sometimes modified) by various other communication platforms, to keep track of messages.

Most of the different versions are various mashups of device IDs, organization IDs, incremental IDs (in case you create several items at the same millisecond), hashes, timestamps, and even random numbers, with a few bits reserved for designating which version is being used.  The version that most amuses me (I refuse to say I have a "favorite" version, both because I haven't used them much, and because I can see reasons for using any of several of the versions) is Version 4:  it is a completely random number, with the exception of the four bits that are reserved to say "I'm just a completely random number!"

Version 4 amuses me in no small part because the chance of two separate devices generating the same 124-bit number is practically nonexistent -- but it has nonetheless happened in the "wild", both because of bad random number generation, and because it has happened by chance.

So, why would anyone want to use Version 4, when you have versions that pretty much guarantee you'll always have a different ID?  (So long, at least, as you ensure that device IDs and other parts are unique! -- because apparently even other versions have had their own collisions.)  One major reason is that all the other versions are predictable -- and what's worse, they provide useful information, like timestamps, device IDs, and even sequential information about when a particular packet of data was created.

If something is created at random, none of these issues arise.  Granted, they aren't "useful" in the way that other IDs are -- but they can't be guessed, or forged, or created out of full cloth, either.

Such an ID is called a "nonce" -- a term for something that's intended to be used only once -- and they can be used when a "throwaway" ID is needed.  A nonce can be used to protect passwords, uniquely identify packets, maintain session connections, and seed cryptographic algorithms to provide even more randomness to their results.

Identity Management Atoms: Randomness

The enemy of cryptographic systems is predictability. If you can find patterns in a bit of encrypted text, those patterns can be used to find other patterns, which can then, eventually, lead to the recovery of the original message.

To illustrate this, consider a popular puzzle found in newspapers: the cryptogram. Granted, this isn't a "serious" encryption scheme -- it is only, after all, the assigning of each letter in the alphabet to a different letter -- but it's also illustrative of why randomness is so important! Here is a cryptogram from one of my puzzle books:

JRCJ BRQPR UOOIU JRO ROQXRJ GS 

CXUMWTQJV QY GYO XOYOWCJQGY GSJOY 

KOPGIOU JRO ROQXRJ GS BQUTGI QY JRO 

YONJ.

This may seem a little intimidating, but if you squint long enough, you might notice "JRCJ" and "JRO" share a "JR" -- and recall that "THAT" is a common word that begins and ends with the same letter -- and guess that "JRCJ" is "THAT" and "JRO" is "THE".  From there, you might look at "ROQXRJ", which we now have letters for:  "H E -- -- H T" -- and wonder if that word is "HEIGHT" -- and from there, wonder whether "QY" might be "IN" or "IS" (it can't be "IT", though, because we already know that "J" is the code for "T"!) -- hopefully it's clear how recognizing these patterns can "break" little bits of this code, which can then be used to "break" other little bits, until it cascades and unravels completely.  Indeed, while it's challenging, it's easy enough that this technique is used as a popular past-time!

So, if we want to encrypt something, we need to make it look as random as possible.  It has been proven that the strongest encryption, hands down, is the "One Time Pad" -- a pair of notepads filled with duplicate copies of random numbers, shared with person you wish to communicate with -- and if you wish to send a message, you take a page from your pad, use it to encrypt your message, and send it to your friend, who uses the same page to decrypt the message.  Really simple!  And proven mathematically that it's absolutely unbreakable, if it's used right.

Why don't we use this "one time pad" for all our communication needs, then?  There are several reasons:

1. It can be difficult to get a One Time Pad to your friend, and thus, he'll have a difficult time reading your messages;
2. You have to make sure you and your friend are literally on the "same page" for the messages;
3. If you mess up, or get lazy, and use the same page for two messages, both of the encrypted messages can be combined to reveal both messages -- perhaps the most dramatic illustration of this I have seen uses two images encrypted with a One Time Pad to show just how both messages become apparent when combined;
4. A One Time Pad has a limited number of pages -- and if you run out, you'll be tempted to reuse pages, or you will have to get another pad to your friend;
5. If you want to communicate with another friend, you have to have another pair of One Time Pads, and this doesn't scale very well!

Modern cryptography techniques are designed to get around these problems -- at the cost of being "less secure" than this gold standard -- but the methods are complex enough that they make pattern recovery pretty much impossible ... and yet much of the security of these methods still hinge on the ability to create random numbers!

Which begs a couple of questions:  How are random numbers generated, anyway?  And how do we know if something is "sufficiently random"?  While I said in the introduction that I'm not going to discuss the algorithms behind these "atoms" of cryptography, I'm going to make randomness somewhat of an exception, because it's at the core of everything!  And it's good to see how difficult it can be to be truly random.

I'll answer the second question first.  "Randomness" has a simple statistical definition:  if you have a list, or perhaps a way of generating a list, of allegedly random numbers, and you cannot reliably guess what the next number will be, the list of numbers is considered random.  Considering that statistics is the mathematical art of finding patterns in data, essentially this definition boils down to "we can't find any patterns, no matter how hard we try!"

The first random number "generator" was a simple polynomial, used over and over again, using the previous output as a "seed" for the next number -- but after a limited number of these steps, the "next" number would be the first, and the sequence would repeat!  The mathematician who suggested this wasn't serious about it -- he thought that the very notion of using a deterministic machine like a computer was particularly funny -- but it was relatively simple way to provide "randomness" for simple games.

Naturally, if we assume we cannot calculate random numbers, it would seem to be reasonable to turn to nature itself for randomness.  These strategies have included watching a bit of radioactive material decay over time and watching a wall of lava lamps.  It might be tempting to suggest that this is just as bad as a computer, because theoretically the universe is "deterministic" -- but while quantum mechanics itself throws a wrench in this notion, it doesn't really matter if these things are deterministic, because our ability to capture "initial conditions" to the degree needed to make these things predictable is woefully inadequate -- and chaos theory even suggests that it will always be so.

Nonetheless, these methods have their own gotchas that can make them impractical.  For one thing, it's necessary to be very careful with sampling!  If we attempt to sample the events at too fast or too slow of a rate, we can introduce extra "1"s and "0"s into the data that eat away at the randomness we're trying to capture.  (There are strategies for fixing this that I won't review here.)  Also, it's kindof hard to keep a wall of lava lamps in your laptop or pocket computer, so it's necessary to get these bits from the internet -- and if other people are getting these same bits at the same time, that can eat away at randomness too.

Nowadays, we use a combination of the two approaches:  cryptographic functions like "hashes" and "symmetric keys" are designed to thoroughly scramble data to the point that you can only use these functions to restore the data again, and thus have made the notion of "cryptographic pseudo-random number generator" possible, contrary to our original intuition!  But to ensure further randomization, these functions need a "seed" value to start with ... and that seed is provided by the random fluctuations of things like the start times and keyboard inputs of the computers themselves.

An Interesting Insight into the Notion of Calculus

Yesterday, I had an interesting insight! An important notion of "calculus" is the notion of symbol -- and that the "calculus" of identity management would benefit from a "symbolic" approach. Before I explain why this is an interesting insight, I will have to go through a little digression.

Several months ago, I came across a math book in a used bookstore, that had an interesting claim in its introduction: that mathematicians over the years have distanced themselves from the notion of "variable" -- that the notion is rather confusing, and they have been thinking about things in different ways. My reaction at the time was "well, that is weird! I'm a mathematician, and I have never known about this controversy". I put the book back on the shelf, even though I really wanted to get it, just for the introduction alone, but I couldn't bring myself to justify, at the time, even that tiny expense, especially since I have so little space for yet another book.

Bah! I should have bought that book!

The notion wormed its way into my head as I wondered "what would I use, if not variables?" -- and then it hit me: "variables" imply too much -- the word implies that what you are working with can be expected to change -- so the notion you really need is symbols.

A "symbol" can be anything -- it can be a word, a letter, a wedge or dot or dash above a letter, a picture, a collection of lines and wedges pressed into clay, even a physical object sitting in front of you. Anything can be a symbol, and any given symbol can represent anything.
All you need to do, when you want to talk about a particular idea, is to choose a symbol, describe what you want that symbol to mean, and then use the symbol for that purpose.
Symbols are the foundation of civilization. When sequences of sounds are assigned "meaning", they make spoken language possible. When they are used as hieroglyphics for words or letters for sounds, they make writing possible. Those same words can capture abstract ideas, and whether they are manipulated by sentences or by letters, or combined with dots, circles, and lines, they become the foundations for exploring mathematical ideas. And they are one of the features that makes Common Lisp the powerful computer language it is -- you can create whatever symbol you need for the task at hand, and even create "hidden" symbols, used once for a very specific purpose, so that no one can "clobber" that symbol by accidentally using it.

If you think Algebra is challenging, try doing it without letters! There is a common notion that the devil introduced letters into math, but compare this: "consider a function that takes a number, multiplies it by itself, adds three of itself to that, and adds five" to this: "f(x) = x^2 + 3x + 5". In the latter statement, "f" is commonly recognized as a function, "x" as a number, "^2" as "multiply the number by itself", etc -- and because of its compact form, it's far easier to work with! (Indeed, when one considers the "Cubic Formula" -- the equivalent of the "Quadratic Formula" used to find zeros of something like "f(x)" above -- and is a big complicated jumble of cube roots and square roots, requiring the use of "imaginary" numbers to get to "real" number solutions, which may very well be plain vanilla integers disguised as a mix of square and cubic roots that non-obviously can be simplified -- when one considers all this, what is amazing is that it was all done in words, well before letters and other symbols were introduced to mathematics!)

So, what does all this have to do with Identity Management? It has occurred to me that perhaps discussions of the various components of Identity Management can be simplified by treating their applications symbolically -- making it a lot easier to see what's going on -- than is typically handled by Cryptography texts.

Consider an example (putting aside that I haven't really discussed what each of these things mean!): Let M be a message, H be a hash function, and (Af, Ap) be a Alice's Public-Private Key Pair -- I call the key "A" for "Alice", but the "f" here means free, and "p" means "private" (it kindof drives me nuts that "public" and "private" start with the same letter; however, I may want to come up with better ways to designate the parts of the key) -- with these things in mind, how would I sign a message, and send it to Bob, who has a Public-Private key pair (Bf, Bp)?

First, Alice would need to sign the message, by obtaining the hash H(M) of the message, signing the hash with the private key, Ap(H(M)), and then appending the result to the message itself: [M|Ap(H(M))]. (Since this is an "exploration" on my part, I'm going to leave the parentheses in for now, but it might be easier to see what's going on by shortening all this to [M|ApHM].) Now, to send this to Bob, she'll want to encrypt it with Bob's public key: Bf([M|Ap(H(M))]). She then sends this message to Bob.

So, how does Bob read all this? He applies his private key to the message: Bp(Bf([M|Ap(H(M))])) -- and since Bp(Bf) cancel each other out, he has the message [M|Ap(H(M))]. To confirm that the message really came from Alice, he then takes the hash of the message H(M), and "decrypts" the message from Alice with her public key: Af(Ap(H(M)) -- the Af(Ap) cancel each other out, so if the H(M) that Bob calculated matches the H(M) that Alice "signed", the message indeed came from Alice!

Ah, so the approach has promise! (And I'll definitely want to drop the parentheses!) Perhaps this approach has already been done -- I may be duplicating other people's efforts while creating an equivalent notation that no one else uses -- but if that's indeed the case, it means I'm on the right track! Having said that, while I'm not an expert in this field, I have read a few documents describing these principles over the years, and while I remember a lot of pretty pictures, I don't recall anyone doing this kind of thing.

And this approach will go a long way to justifying the use of the term "calculus" to describe the field!

And this may also mean I'll want to figure out how to display mathematical notation in Blogger ....

An Introduction to the Calculus of Identity Management

"Calculus" for many people is a scary word -- it conjures up images of "integrals" and "derivatives" and tortured algebraic expressions that don't quite work out as expected, because of a tiny mistake made three or four lines ago! -- but it doesn't have to be a scary word!

"Calculus" is the Latin word for "pebbles". Why pebbles? Because the antient Romans used pebbles to keep track of numbers as they worked through things. (I tried very hard to avoid saying "calculate things" -- because that would be kindof circular!) Thus, when Sir Isaac Newton and Gottfreid Wilhelm Leibniz developed a way to handle rates of change, it was only natural for them to call it "the Calculus" -- and considering the range of things made possible by the Calculus, ranging from understanding how little particles interact with each other to creating buildings and bridges and flying things to aiming weapons and guiding rockets to the Moon and beyond to coming to terms with the creation and functioning of galaxies of galaxies, it kindof deserves the extra emphasis!

Now, at the moment, I don't want to conjure up the vast power of the Calculus -- instead, I want to call attention to a more humble "calculus", one that was developed in the 1920s by one Alonzo Church. Using only three rules, and a function called a "Lambda", he developed a tiny little theory that, along with Alan Turing's Machine, proved to be the foundation of this tiny little movement we call "computing". Maybe some day it will prove to be consequential ... but in the meantime, I cannot help but be fascinated by how outright powerful these ideas has been in their own little sphere. The Lambda Calculus is the foundation for the Lisp family of computer languages, which are known for their power and flexibility, while the Turing Machine is the foundation of computers themselves, along with ALGOL-based languages that are known for their computing speed and power (albeit at a cost of flexibility).

It is with this in mind that I would like to create a series of posts on what I call "Identity Management Calculus". Perhaps this isn't exactly appropriate -- we don't necessarily "calculate" identities -- but I nonetheless wish to draw on the notion that we can build something pretty incredible from a handful of simple components. The first part of this series would descibe each of these components, and the second will describe some of the many ways these components interact with each other, to make identity, and even "reputation", something that can be managed!

In the spirit of these various "calculus" methods, I will not be discussing how particular algorithms work -- partially because I find them a little intimidating, and partially because I'm not entirely sure if they really matter. In much the same way that using the idea of "gates" made it possible to design computers without knowing what the circuits underneath look like, enabling "computer architects" to design how a computer operates, leaving the actual circuits to electrical engineers who would constantly improve them, my goal is to show how these fundamental bits interact with each other to create powerful methods for establishing identity -- ideas that will work, despite the underlying algorithms used underneath.

I should add that I do not consider myself an expert. To be sure, as a mathematician pretending to be a software engineer, I have had to become familiar with how to manage accounts and protect passwords; however, as I have explored these topics, I have had the impression that too often "cryptography" and "security" focuses on the algorithms, and loses track of how they are supposed to interoperate. I hope to fix that gap -- if for no other reason than I would like to have a reference for myself on this topic!

But there is a second reason I wish to pursue this topic: for several years now, I have been concerned about how much the Internet has fallen into "closed gardens" that leave us vulnerable both to the whims of massive corporate entities and to massive structural failures. In just the last few years, we have seen governments around the world work with world-wide corporations to squelsh speech, and we have also seen large portions of the internet break down because of a single bad setting pushed by a single software engineer. This isn't the internet we were promised!

To fix this, though, we need to find ways to run our own document services, create our own social networks, and index our own web pages -- but we cannot do this when our identities are created piecemeal, with every social media site, every bank, every school, and every forum either asks us to create a new identity, or offers to let on of the three or four internet giants to manage our identity for them. In short, we need a way to personalize and decentralize our personal identities, so that each one of us is responsible for both maintaining our own identities, and for managing the identities of others!

And what makes this decentralization possible, are the fundamental building blocks of identity, and how they interact with each other to make the keeping track of those identities manageable!

Self Re-Orientation: Beginning a new personal brand!

Hello!
   [tap tap tap]
Is this thing on?
   [Screeeeeeech]
Hey, I guess so!


I find it rather difficult to believe that it's been 13 years since I last posted here; a lot of life has happened since then, along with distraction via Social Media!

But I thought it was about time to dust this blog off, oil the hinges, and figure out where to go from here -- and this is a part of an effort to re-orient myself. It's tempting to say I'm trying to "reinvent" myself, but I'm not trying to reinvent myself, so much as ... try to find my original self, and try to be true to who I am.

Several months ago -- make that a year and a half or so -- I attended a presentation on a company that uses Virtual Reality games for companies to use as team-building exercises. I had the opportunity to try out the team-building exercises; in the first demo afterward, I discovered the horrors of being attacked by a troll! I didn't want to let this experience scar me for life, though, so I went through two or three more rounds. Perhaps too many, because I needed to get home for a family trip!

As I drove home from that activity, I had a rather devastating thought: "Everything you have been doing up to this point is wrong!" Really? Everything?!? As I have reflected on this over the months, I have concluded that, well, maybe not everything, but I nonetheless needed to reconsider things.

On February 7th, 2024, I had a very clarifying moment: I watched a video on YouTube, and the video convinced me that I'm autistic. Now, it sounds silly to say it this way -- "you watched a video? pfft!" but between having a daughter and a brother diagnosed with autism, and another daughter who had just gone through an evaluation (and was later confirmed to be autistic too), and both my wife and I had suspicions about myself for several years now, it wasn't exactly a sudden revelation. It's also just a tad dangerous to click on a video titled 9 Signs You're Actually NOT Autistic... thinking "Let's settle this once and for all!"

This discovery launched me into learning a lot more about autism, but it nonetheless took me a couple of months to stumble onto why I related to some autistic experiences -- both in YouTube videos and in books -- but not others. On April 5th, 2024, I stumbled onto An Introduction to AuDHD and discovered I have ADHD as well, everything clicked into place!


So, where do I go from here? I'm still trying to figure that out, but one thing I am currently convinced of, is that I cannot continue down the path I have taken: putting out applications to everything I see, struggling to network because I'm terrified to talk to others, trying to get a "classic" 9-to-5 job with two weeks vacation every year, perhaps with the nice energy of a startup or the nice stability of an established company, only to burn out, or have the company burn out, or both, and then be let go, lather, rinse, repeat. I realize now that the burnout I suffered was more than likely the "autistic burnout" that comes as a result of the constant mostly-unconscious "masking" of my traits to fit in, the constant evaluation and re-evaluation of everything I said or did, to see what I could learn from it, and, between work and family duties, the inability to ever find rest!

Thus, I am considering my options. I have the impression that part-time short-term contacts with longish breaks in between would be a productive path -- if I could find the contracts -- but finding these kinds of things are kindof hard when, due to intense social anxiety, I struggle to network with others.

I also cannot rule out seeking vocational training or disability. I cannot help but fear that vocational training for autistics will be "here's how to interview!" or "here's how to fit in with your colleagues!" -- basically, stuff I have learned my entire life, and the kinds of things that have very likely been leading to my burnout -- but, as for disability, I cannot help but fear that this is "giving up", and that going down that route would limit me in ways I would find chaffing.

But, above all, I have reflected on two things: First, that I have seemed to thrive the most when I was in school (likely due to the combination of a schedule that satisfies my autistic need to have a schedule, of a variety of topics and activities that satisfy my ADHD need for constant stimulation, and of the longish breaks I could take in the library and during summer, spring, and Christmas vacations, enabling me to "recharge" myself to prevent burnout); and Second, that I love to create things, to design things, to make things out of random items I have at hand, and to explore and discover new things. I cannot help but suspect that if I could just structure my own life, and figure out how to explore, I would be on solid footing!

I have signed up for a waitlist for an evaluation. Insomuch that I may need to try occupation therapy or ADHD medication, this is a necessary step -- but the waitlists are long, and I cannot help but be a little unnerved when I have a family to support! And I am, day by day, trying to do a little something here or there, to push me forward, even if just a little bit. After more than two years of unemployment, I have struggled to have the energy to do things, but if I can take things a day at a time, I'm sure things will work out!


I have this notion that, contrary to popular belief, Free Market Capitalism is fundamentally based on helping each other out -- that the Free Market is the very Communism that Marxists believe will come once they establish a bloody dictatorship and let that dictatorship miraculously "whither away" -- but this only works because individuals are out there figuring out for themselves what their needs are, and figuring out for themselves what their abilities are, and then figuring out for themselves how to best match those abilities and needs. This is distressing, when I'm autistic, and all I want is to be left alone to do my own thing! But there's an escape hatch, too: I don't just want to do things on my own. I want to tell other people about what I do, too! (Whether that person likes it or not .... sigh, there's always a catch, isn't there?)


Now, on this is Day of Infamy -- it is the dreaded "Dependence Day" that I had posted about before, but not regularly (both because I didn't want this blog to become a yearly announcement of the "Day of Infamy", and because I've never been all that great at keeping track of dates) -- I suppose it is a fitting to declare that I am now seeking for Independence. I will scale back my efforts to try to "fit in" with the "real world", push forward with my strengths, and hope for the best!

Will this work? I don't know. I figure that, if all else fails, and I'm really not "fit for work" in any sort of way, disability may just be there for me, if the National Debt doesn't come crashing down first.


Oh, and I'll likely need to ask for donations, too. At least, at some point, because "designing things" at random isn't likely to pay the bills. I don't have a link for that, though, because I have no idea what I'm doing, and I'm just taking it a day at a time!

Dependence Day, Medicare Edition! Or, Let the Attacks on Ryan Begin!

It seems only seconds after Mitt Romney chose Paul Ryan, that Ryan had come under fire because of his attempts to reform Medicare. These attacks have struck a nerve, and I have decided that I need to respond to them.

And what better time to do so, than on Dependence Day, the anniversary of when Government Dependence was established for the American Middle Class?

Now, I'm not going to defend Romney or Ryan here. They are politicians, and so I have little faith that they can change things for the better. Even the best-intentioned, most-determined politician--or rather, the politician who is right--cannot do much, when trying to go against the Will of the People.

Instead, I am going on the attack: I'm going to try to slaughter these sacred cows of Medicare and Social Security. In order to understand where Ryan is coming from, we need a good, hard look at what these institutions represent--we need to face the ugly truths associated with these institutions.

First. Social Security and Medicare will destroy us financially. Between Social Security, Medicare and Medicaid obligations, these three institutions take up most of the budget; if they continue to grow without reform, in just a few years they will exceed our government's income. Thus, reform is necessary for our survival as a nation.

Second. Social Security and Medicare destroy our freedoms. When we accept these things, we are required to observe restrictions on how much we can earn, and who we can donate money to; we also commit ourselves to a substantially lower quality of life. Indeed, Medicare is the greater offender of these things: while we are forced to pay into these things, whether we accept their goals or not, Medicare requires everyone of a certain age to receive its services.

Third. Social Security and Medicare destroy our character and our individuality. These institutions deaden our desires to save and to provide for ourselves, and thus destroy our individual initiative. Why save for disability, or save money for retirement, or spend money on insurance, when we "paid into" a lousy system, and expect to "get" our money back from them? Of course, the answer ought to be "because I can do better than what Government does", but because we're forced into lousy systems, that answer loses its potency.

Fourth. Medicare has wreaked havoc on our medical infrastructure. The excuse for passing Obama-nable-Care was that our medical institutions were failing us. But no one ever examined the question, "Why are our Medical Institutions failing us?" While not a complete answer, Medicare is a major portion of the answer. Through policies of forcing doctors to only accept a maximum amount for services rendered, and forcing doctors to accept a minimal amount from Medicare, requiring doctors to "man up" and accept the loss in difference, and then prosecuting doctors for fraud, when they chose to charge a different fee for Medicare patients, and one for non-Medicare patients, Medicare has literally forced higher prices on us all, in both services and insurance premiums, just to maintain the illusion that they are helping the elderly with their medical expenses. And because of this rise in premiums, wo be to the poor soul who has to see a doctor, but has no insurance!

Fifth. Social Security and Medicare are based on a false premise: "We pay money in, and we get money, with interest, out". The reality is that what we pay into these institutions are taxes, pure and simple. As such, they can be, and are, used for other purposes, from building roads to paying for wars. Furthermore, this false premise has developed an entitlement mentality: "I've paid all my life into these retirement and health programs, you had better pay me back." Since this is a tax, this money was taken from us by gunpoint; the Government has no obligation to make sure we get a return on this "investment".

Besides, as investments go, when we make a bad one, it is important to learn to cut our losses, and to put our resources in places that would better benefit us.

Sixth. Senator Paul Ryan is accused of trying to destroy Medicare. Oh, if only this were true! Medicare, and its Sister Institution Social Security, are blights on our character, chains on our ankles, and millstones around our necks. They weaken us, enslave us, and will prove to be our financial destruction, if we allow them to continue to exist. Thus, these institutions ought to be destroyed! Or, at a minimum, they ought to be phased out of existence, over the next decade or two.

Instead, Ryan has merely proposed minor reforms, to allow the abomination we call Medicare to continue to limp in existence, wounded, but nonetheless lurking in a cave like a giant, greedy spider, continuing to grow bloated as it consumes unsuspecting souls, and as it continues to destroy our liberties, and the medical institutions that we once held dear.

So attack Ryan, if you will, for working to alter Medicare. Just don't claim he is trying to destroy it!

Oh, and happy Dependence Day. May God have mercy on your soul!