July 16, 2013

What if we paid for risk with time?

Cryptography offers us many things - not just the ability to lock up secrets that can only be decoded if we know some secret password.  Using the processes of hashing, encoding and decoding, we've been brought capabilities such as digital signatures, network secrecy and non-shared key authentication.  I was thinking about one particular capability offered by our cryptography geniuses - the use of hashing algorithms to derive secret keys over a given number of cycles without an easy way to determine the solution without actually performing the calculations over that number of cycles.  Wow - that sounds like it's going to get complicated...Let's back up and take a look at just what a key derivation function is.

In essence, what these protocols do is come up with a determinate sequence of pseudo-random numbers by performing a set of specific calculations over and over (you set the number of repetitions).  By feeding the function a pass-phase, it will blend that pass-phrase into a messy sequence of numbers that supposedly can not be reverse-engineered through any other means other than using the same blending process with the exact same pass-phrase over the same number of cycles. There's different versions of this, bcrypt, PBKDF2 and scrypt, with scrypt being the more modern of the three - designed to not only take repetition into account, but also arbitrary memory usage, which helps you to keep function costs higher by requiring additional hardware costs for parallel attacks.

What struck me today is that this function can essentially be used as a time-lock.  To the analogies!!! You walk into a bank and go to hold up the teller - you might get out of the bank with $1,000 - $2,000...hardly worth the risk. Why don't you rob the safe in the back that holds all of the money? Because it has a time-lock on it. It can probably only be unlocked by the bank manager after putting in the combination and waiting for an hour for the safe to open. If you're robbing a bank, your time frame is a lot shorter than an hour. It raises the risk of being caught and the bank knows this - which is why they use time locks. The longer it takes you, the heavier the risk side of your risk/reward see-saw.

What if people implemented time-locks for high-risk transactions in the automation of business transactions. The risk of a transaction could be a measurement of how long transactions would need to take.  Time locks would be implemented in such a way that the verification of the transactions would utilize key derivation functions to complete, with half of the compute time being taken by the sender, and half the compute time being taken by the receiver.


Transferring $10 to your wife's account?  No problem, sir, take but a second..

Oh, you want to transfer $200,000 to a random account number in the Grand Cayman Islands?  Yes, sir - we can do that for you - the transaction will begin now, and the transfer will complete in 12 hours.  No, sir, the receiving party will not credit the amount until both sides reach the agreed upon key for the transaction. The transaction will show as 'pending' until it completes or is aborted.

As computing time/resources get cheaper, validation time can be kept in line with the risk, requiring specific amounts of resources (cycles, processes, memory) to perform the transaction. Resource costs would have to be passed on to customers as part of transfer fees - time increases would be enforceable at the interface level, since communication of the transaction verification could not be done without the derived key, enforced by a protocol standard.

Now for the devil's advocacy - This would have a negative impact on customers performing high-risk transactions.  It would probably never make it past lobbying organizations, and people who regularly pass around large sums of money would find some other way of performing wire transfers to get around the limitations.  Also, time-locks could be implemented without even using these processes if banks REALLY cared about the risks of risky automated transactions, through simple business rules and agreed upon timelines and risk limits.  So- just another random rambling....

July 08, 2013

Agile Development and Documentation

Some wisdom to write an article on in the future:

Agile Development doesn't mean excluding the need for documentation – however, processes and tools can be used to create documentation FROM the process of development.  Rather than putting the cart before the horse to lead him, you allow the horse to pull the cart, and, when you GET there, look back and follow the cart tracks to inform and document the path you've taken (upon which you can decide to pave a road, perhaps).  This is why Agile CAN BE an effective software development practice - because you don’t have to pay for someone to pull the cart ALL THE WAY from Start to Finish and pull the kicking and screaming horse behind…you instead get smart drivers on the cart to lead the horse only to the next step toward the destination and a horse  who is smart enough to walk around the trees.

July 06, 2013

Don't forget the Auditing

Yet another unfinished thought on auditing and system design - I cleaned up a little, but again - publishing from draft:

When it comes to performing information security, it's easy to get lost in technical solutions and overtly technical discussions regarding what you need to lock down your business.  With the complexities of password policy, application and network design, encryption algorithms, VPNs and firewalls all spinning around in your head, there is something very easy to understand that is at the core of providing risk awareness.

Auditing, not just logging of security events, either - but I mean good old fashioned auditing of your books and business transactions.  Keeping an eye on what's going on in your business may help you to identify when there's someone with their hand in the cookie jar - and it won't make any difference they got in to your network when you catch them in the act of siphoning off your accounts.

Supervisory function: I can't imagine that a bank teller would be permitted to leave the premises at the end of his or her shift if their drawer was short of cash.  Managers count them up and monitor whether or not their transactions line up and everything checks out.  In so doing, anything out of the ordinary would be reviewed and questioned.  The bank manager performs the supervisory function and is aware of the business rules that are applied to ensure proper operation of the business.  Even with automated teller machines in banks, this supervisory function is not forgotten - review of transactions and matching them up to the cash in the machine during cash outs help the banks ensure that everything is performing at least to some modest business constraints.

Constraints and Limitations: In the same instance, tellers are not given access to the entire bank balance.  Those who rob banks will likely tell you that robbing a teller these days is hardly worth the risk since the take will be very low.  It's probably more rewarding to hold up a cash business like a fast food restaurant, where the controls are not as involved and there's more chance of obtaining large cash drawer balances.  Even ATMs, which are entrusted with large cash drawers (since they're not likely to turn over their cash to a gunman), still have a limit to their losses based on how much they're loaded with.  When we design computer systems that access things like bank balances and accounts, we need to be reminded that business rules that impart these constraints and limits on transactions still need to be in place.  Even more so, hair triggers on constraints should lock down transactions from a source (such as a web front-end) that shows signs of being erratic.

There's a Difference

Something I had drafted - wasn't sure of whether I agreed with myself or had switched analogies where I'd meant things in an opposite manner, so I originally didn't publish - but I'm going to publish it now with the caveat that this is not completely thought out, and is indeed, just a rambling.

In discussing atheism on the Internet, some people are making an assumption that atheists and agnostics and the nonreligious are one and the same.  There is a difference, and an analogy came to me that I though I would mention.  In computer science, there are three concepts that are similar but distinctly different.  The concepts are NULL, ZERO and EMPTY.  Some databases do not recognize the difference between null, zero and empty - after all, they are all void of any value, so why should I treat them differently?  Some recognize a difference between zero and empty, but not null and empty.

To store an EMPTY value, I must allocate memory appropriately sized to the type of value I intended to store in that location, and then not store any value there.  In many computer languages, this EMPTY value will default to a particular value.  In other languages, this particular action leaves an UNDEFINED value in the memory location that I have assigned.  No matter, I have actually allocated memory space to hold some value - I merely have not made any effort to store something there.  In our analogy, these are the nonreligious.  The way that English defines this state is, upon recall, the response to 'What do you believe to be the supreme being?' is 'I don't know'.  In some computer languages, this answer will be random gibberish.  This means that when asked who is the supreme being, their answer MAY be 'a flying spaghetti monster'.  The questioner has no way of knowing whether this value has been placed there intentionally or is a random response.  It is obvious, however, that this is a garbage response and not an actual value [with the assumption that no one TRULY believes that a flying spaghetti monster exists and created the world].  It is also true that this person may, on random chance, answer 'Jehovah'.  However, because this dimension is a known EMPTY value - the respondent will know that the answer holds no conviction, even though the questioner does not know this.  To test the EMPTY value response against an actual belief, it is necessary to ask many more questions about the nature of the stored value and attempt to determine how that value got into that memory location. (This is beyond the scope of this discussion).

Code sample for EMPTY value:
String supreme_being;

print supreme_being;

Sample output:
The Flying Spaghetti Monster
Mahatma Ghandi
Error: pointer exception!

A ZERO value is when I have made the effort to allocate memory to store information, and have made a conscious effort to store the placeholder which means OF NO VALUE, invented by the Babylonians in the 4th century BC.  So, I have set aside a location and stored a marker that is consistent with my data type that means this location is dedicated to the fact that the value of the dimension I am storing is void of any significant value.  In our analogy, this memory location is pointed to by the dimension 'supreme being' and the value we are storing is ZERO (non-existent, no-value added).  This is the atheist.  When asked 'Who is the supreme being', their response is 'There is none.' and this is a definitive answer.

Code sample for ZERO value:
String supreme_being;
supreme_being = "";

print("The supreme being is %s.",supreme_being);

Sample output:
The supreme being is .

The remaining concept is a little more difficult to comprehend at first - but it is best defined as the ignorance-is-bliss option.  Failing to set aside any location in memory, and failing to set aside any pointer to the value dimension, when attempts to reference a NULL value are made, computer languages will normally throw an error, which means that the question will have to be handled as an exception to the logic tree.  There simply is no dimension defined that meets the criteria of the question.  In our analogy, this is the agnostic.  The way that English defines this state is, upon recall, the response to 'What do you believe to be the supreme being?' is 'I don't care.'  Another potential answer may be 'I have never given that any thought' - but this answer may allude to the person beginning to provide some thought energy to the subject - which may immediately put them in the EMPTY category as they begin to think about it.

Code sample for NULL value:
print("The supreme being is %s.",supreme_being);

Sample output:
Error: Undefined variable.

One could argue that there are few people in modern western society who have truly given no thought or significance to the question 'Who/what is the supreme being' and will continue to do so.  Because of our society giving great weight to the discussion of this question, you could argue that it is difficult to find people who are truly agnostic and that people are either religious, nonreligious or atheists.  In fact, Richard Dawkins argued that one should not and can not logically define oneself as an agnostic.  And this holds true with these analogies.  The only agnostics are those that can not or will not self-identify because either they do not care, or have not heard of religion.  However, I disagree with Dawkins that all agnostics are atheists.  By my analogy, people who have identified themselves as agnostic are actually nonreligious.  If they TRULY are agnostic, they wouldn't identify themselves as anything - they would simply respond to religious queries with 'I do not care.' or 'You're not making sense - please leave me alone'.

Because of the nature of the true agnostic, it is impossible to include them in the debate field.  Rather than all four opinions, all religious debate automatically excludes them (because they don't care to get involved).  All debate, therefore, exists between three populations: religious/nonreligious/atheists.  It is also impossible for an outsider to know the difference between someone who is religious and nonreligious because of the possibility that a non-committal answer to religious questioning may come from a nonreligious population.  This discussion is important, but outside of the scope of this article.

Bleagh - Hot Today

Probably to my neighbors' dismay, I woke up early and cut the lawn this morning at 7:30.  I was trying to beat the heat in this wonderful DC area July.  Unfortunately, that means I don't get to beat the dew.  The lawn was wet, it's still hot as hell and between the moisture on the grass and the buckets of water streaming down from my head, I only got the front lawn done in the hour I was out there.  That's right, I packed it in early once I'd finished the front.  My rear lawn is definitely looking pretty long comparatively, but it takes every bit as long as the front to finish, and I'll be damned if I'm going to spend another hour plus out there.

So, Microsoft is getting rid of TechNet.  They sent out an ad to people on their mailing lists last week, and in it, they mentioned two alternatives for people who still need to test and use their technology to learn.  One of them is TechNet Virtual Labs and the other is TechNet Evaluation Center.  I tried out one of their Virtual Labs to play with AppBlocker technology in Windows 8, and then decided to download Windows 8 evaluation edition for my virtual lab that I run at home.  I downloaded the 64-bit Windows 8, which means I had to turn on Intel Virtualization Technology in my BIOS - simple enough to do while running patches last night.  I'm going to try out Windows 8 this weekend and see how I feel about it.  I don't like the tightly squared windows of the design, but then I didn't like Windows XP look and feel at first, either.  It may grow on me.

I've been playing Texas Hold'em recently.  If you know me on Facebook, I play on Zynga Poker and I'm happy to hook up with folks.  I actually managed to zero out at Zynga Poker - fake chips are fake chips after all.  When I did, their mini-game slot machine that gives you 1 free spin a day starting spitting out 10x rewards when I pulled it.  They make sure their players don't completely run out of chips.  I had a chance to play 1/2NL at Casino Niaga while I was on a trip 2 weeks ago.  It was a lot of fun to sit down with 10 total strangers and to see the wide range of abilities.  There were definitely some guys that showed up that probably shouldn't be playing for real money yet.  One of them folded from checked-around in the big blind, three times, no less.  Either he was nervous, or he's only barely learned to play.