Wednesday 29 June 2011

FIFTY!!! YAAAYY!!!

So, this is my 50th post. WOOHOOO!!! Enough with the celebrations, we have work to do. I decided to mark this momentous milestone, I will discuss the basics of cryptography. Now, I know I have covered some bits of this before, feel free to skip any parts you think you know. So, let's start by naming  the three principle components of cryptography : Encryption, Signatures/Message Authentication Codes(MACs) and Proofs.


So, let's start with the first, and probably most well-known, section: Encryption. The scenario is simple, you have a message that you wish to communicate to somebody else, without anybody else finding out that message. The way to do this is encryption. Think back to when you were a kid and you and your friends made up a secret language. That could be viewed as a crude form of encryption, as can all languages. But now, lets talk about the more modern stuff.

An encryption scheme is basically two functions: and encryption function, which I will denote by ENC, and a decryption function, which I will denote by DEC. ENC takes a normal message and turns it into something unintelligible, called a ciphertext. DEC takes a ciphertext and turns it back into the message. To do this, both functions need some additional information, called a key. There are two flavours of encryption, both defined by the relation between the keys used by ENC and DEC. In symmetric or secret key encryption, both ENC and DEC use the same key, whereas in asymmetric or public key encryption, they use distinct but related keys.

Now you must be wondering where all these keys come from and how they get to the right people. For the asymmetric setting it's fairly simple. The receiver generates the keys and publishes the public encryption key, PK, and keeps the decryption key, SK, secret. The publication of PK leads to some very interesting problems, but that's out of scope, but worth mentioning. In the symmetric setting, it's a tad more complicated and this problem is a whole research area on it's own. Let's just say that there are clever ways of doing it in several circumstances.

Now signatures/MACs are essentially the same thing, with different key settings. MAC use symmetric keys and signatures use asymmetric keys. They both serve the same purpose, that is to authenticate the source of a message. For simplicity, I will refer to both of them as codes, which is an abuse of many notations, but will suffice for our purposes. All code systems have two functions: generate, denoted GEN, and verify, denoted VER, and they work as follows: generate takes in a message and outputs a tag and verify takes in a message and a tag and checks if the tag was indeed generated by the sender for that message.

Here we must note two very important things. Tags are both sender and message dependant. Thus a valid tag for one message, cannot be a valid tag for another message sent by the same person. Also, a valid tag for a message sent by one person cannot be a valid tag for the same message sent by another person. Thus the VER functions takes as input the message and the identity of the person, implicitly in the key.  The main assumption here is that only the sender can generate a valid tag and thus any valid tag implies that the message was sent by them. This is very close to real world signatures and how we view them. Yes, I know that real signatures can be forged, but we also consider that in cryptography. There are some subtleties as to how this is done, but we shan't venture into that.

Finally, we come upon proofs. These are the least well-known and some would say the least understood of the three. The basic idea behind a proof system is that one party wants to prove to the other that a secret value x has some property. The property could be proven by revealing x, but then that would defeat the point of it being secret. So you need to somehow show that x has this property, but without revealing x. We seem to be in a bit f a pickle. That is, until our hero zero knowledge proofs show. These are protocols which allow you to prove certain statements about a value(s) without revealing the value and without the other person learning anything about the secret value.

A simple way to view this is by the simple statement: "Pick a card, any card!" Let's say I hand you a deck of cards and you pick one out at random and put it aside. Now I ask you what suit it is. You tell me it's a spade. I ask you to prove it. You could show me your card, but that's a secret right? Well, how about you show me 13 clubs, 13 hearts and 13 diamonds. *DING*! Now I know nothing more about your card than that it is in fact a spade. This example is great when explaining not only zero knowledge proofs, but also some of it's stranger variants. But that's all for later (read: maybe if I feel like, but don't hold your breath).

So, all in all, we covered the three basic concepts in cryptography because I'm too lazy to do real posts and the number 50 was just mainly an excuse. We hope to have a resumption of normal service soon-ish.

Saturday 25 June 2011

Why is digital money may be a bad idea.

Basically right after I posted this, I read this. Kind of an "I told you so" moment. But apart from that I am at a lack of words for this. I've been staring at my screen for a couple of days now and I have nothing (useful or insightful) to write. Apart from the fact that this whole real currency-bitcoin exchange is a little bit hinky and this is one of the problems you can have with it. For this post, please insert the accustomed amount of wit, cynicism and all that jazz you are used to. Thanks :)

Monday 20 June 2011

Let's talk money, digital money!

Alrighty then, I'm going to assume that everybody has some basic understanding of the concept of money. Next, I assume you all have some idea of how to spend money online using things like paypal, credit cards, debit cards and so forth. Also, the reason nobody that people shouldn't be able to steal your details and thus your money, if it's all done right, depends heavily on crypto. Best way to explain what I do, is to ask "Have you ever bought anything online?" When they answer in the affirmative, then I say "You're welcome."

All levity aside, let's talk about money. Money is official looking paper and bits of metal that carry some value. This value is backed by some central authority. This would normally be the central bank of the country, but could be larger such as the Eurozone. There's a whole lot of economics behind how and why this works, inflation, deflation, devaluation, exchange rates etc that I don't even pretend to understand. We all accept this at face value and move with our lives.

In the online world, it's basically the same thing. The authorities may have changed to credit card issuers, certification authorities and others, but the principle remains the same. Now, this idea doesn't sit too well with the über-privacy people. They are now afraid of all the digital "paper trail", if you will, that is created by all of this. They say that if we can use crypto to secure our transactions, then why not use it to preserve our privacy and create anonymity.

Well, there is quite a lot of cryptographic research in the field of what we like to call e-cash. All this research is completely agnostic of the economic aspects and focuses on the crypto stuff. Until a few days ago, I thought there was no real implementation of any sort of e-cash. Then I heard about Bitcoin. Just as a brief side-note, cryptographers love coins. It's some what of a convention that all randomness is generated using coins and that all e-cash schemes are described in terms of coins. There is good reasoning behind it, but I shan't go into details.

So, back to Bitcoin, which is "the first decentralised digital currency" according to the introductory video. They then go on to explain how it all works and what the advantages are. I'll just recap it for you, for completeness. Bitcoins works using identifiers called addresses, which are essentially random strings. Each user gets 1 when they download the client software. They can then create more so as to have different types of payments come and/or go to/from different addresses. All of these are tied to the same wallet. So if person has addresses a and b then sending money to either address would be the same. This is how anonymity is preserved.

When Bitcoins are sent from person to person, the transaction is hashed and signed. The hash value and digital signature are then verified by the the other users in the system. Once a transaction is verified, the Bitcoins are added to and subtracted from the relevant accounts. This is the decentralised aspect. In normal e-commerce transactions, the verification would be done by a centralised authority such as a bank or clearing house. With Bitcoins this is done in a peer-to-peer (P2P) manner. Another interesting thing is that Bitcoins are super divisible. You can go down to 0.00000001BTC. Which is the advantage of having a digital currency.

So I thought I'll give this a try. So, I downloaded the client software and started reading through the literature and all the wikis and got a feeling for how this all works. There is a whole sub-culture built based around bitcoins and it is quite fascinating. There are entire forums and IRC channels dedicated to the provision of trade in and using Bitcoins. However, as I dug deeper I discovered two very interesting points.

Firstly, Bitcoins are more of a commodity than a currency IMHO. I would like to think of Bitcoins as digital gold. This analogy is fairly apt given the way the currency works, especially with respect to generation. The generation of Bitcoins is called "mining" and involves essentially finding a pre-image for a hash function. Now this requires huge amounts of computations, but once done, a "block" is created. The creation of this block gives the creator some Bitcoins, at time of writing this stands at 50BTC. For those of us that do not have a super computer, there are still options.

The basic technique is called "pooled mining." Here what you do is you combine your computational power and split up the profits according to how much work you did. One way of doing this, if you have a reasonable large amount of computational power, is to join a mining pool. There are several ways this can be done and there are a few technical details that need to considered. Mostly these depend on a central server, which is ironically what Bitcoin was trying to avoid. For those of us with less computational power, there are alternatives, such as this (BTW if you are feeling really nice, you could try and generate a few coins for me here or you could  just send some to 1KbnDDaS3UTAMZkqHSJwGuWgdApQr3wAqp).

However, there are other ways. Carrying on the gold analogy, there are people who own gold but have never even been near a mine. How? They buy it! The same goes for Bitcoins. There are some marketplaces where you can buy and sell Bitcoins for real money. It's fairly easy to compare to say a fresh fish market, let's say. Basically, the fishermen catch the fish (in this case they mine Bitcoins) and then go to a fixed place to sell it. The public knows this place and come there to buy some fish (or in our case Bitcoins). The reason I use the fish market analogy is that there is some haggling and negotiations involved, which is not unlike the Bitcoin marketplaces. In this places you can buy and/or sell Bitcoins for USD, GBP, EUR, or even SLL, the currency of Second Life. Not kidding on the last one.

Which sort of brings me to the second point. Even though Bitcoin is supposed to be decentralised, it seems to be doing it's best to achieve the exact opposite. The whole idea is to not trust this one monolithic central institution, but instead distribute the trust amongst all participants in the system, that is using P2P. There is always some sort of large trust placed in central entities, of varying size, but the point still remains. Transaction verification is still very much P2P, but not much else is. And therein lie the problems.

"With great power comes great responsibility" said Uncle Ben, rightly so. In the mining context, there are ways that servers and miners can cheat. The details of this are fairly technical and thus I will skip them. The essence is that if you control a large enough share of the mining pool, you can control the outcome of the pool, in that who receives how much money. Some people would argue that such attacks are infeasible, but I think they are possible. Further more, with all the multiple currency exchanges, it's not unlikely that somebody could be making, or trying to make, money speculating of price rises and drops. The problem here is that because it's so decentralised, there is the risk of somebody "making a run on the currency." I'm not entirely sure I know how that works, but I believe them.

The most recent problem that has surfaced is that of theft. All the "money" is stored locally on your hard drive in a single file called "wallet.dat". After reading a few of the forums, it became painfully obvious that everybody knows exactly what this file is and what it does. I thought to myself "That's quite a nice target for an attack". Hey presto, somebody did it. The thing with attacks of this kind is that they are pretty much untraceable. Remember, Bitcoin operates on anonymous identities, so even if you get the address that the money was sent to, you don't really learn anything.

So, there are some really cool things about Bitcoin and some not so cool things. I really have no strong opinions about it either way at this point in time. I am just going to let things develop and see what happens. There is a lot of talk about how these may be used to buy and sell drugs, which could lead to the whole thing being shut down, but we shall have to wait and see.

Monday 13 June 2011

Something that has been bugging me for a while

Do you have a facebook account? Rhetorical question, of course you do. If you don't well then you can leave now because this post is all about *drumroll* FACEBOOK! Seeing as how it is on my blog, one can safely assume that it is about facebook security. So, what have facebook done now? They are protecting your from them.

Confused? So was I. Basically they have started up this new scheme to prevent Cross-Site Scripting(XSS) and Clickjacking and other scripting based vulnerabilities. Some of you may be unfamiliar with scripting and the vulnerabilities therein. Most modern webpages serve up dynamic content, making the experience different for each user. A good example of this is your facebook newsfeed, which is different from your friend's feed.

This is all achieved using scripting. A script is essentially some sort of program code that runs within your web-browser. The catch is, you never explicitly execute the scripts like you do programs. They are embedded in the webpage and are executed when you open the webpage, or at some other suitable trigger. The problem then is that people could embed malicious scripts into pages and you will not realise they have run, until it's too late.

I'm sure you've all had that one friend who has posted the same spam link to everybody and 10mins later warned you not to click it. That is basically what these malicious scripts do. So, facebook decided that they need to address the issue, which they did pathetically.


What they have done is now they "read" your URLs and check it for any script. Again, ANY script. That means that if any script is detected, you will be logged out of facebook instantly as a security precaution. You may wonder why this is a problem. Well, as eluded to earlier, almost all actions on facebook are scripts. See more items in your news feed, liking a post, commenting on a post, writing on somebody's wall, the chat feature. Everything is a script. So now, facebook sees you trying to do something legitimate and decides to kick you out. It doesn't always happen, but it's often enough to be mildly aggravating.

It's bad enough that you have to re-login, but what's even worse is that you go through the following twp screens: (full size images here and here)
and then a 3rd asking if you would like to share a link explaining how great facebook security is. Honestly, I would rather have a red-hot iron bar slapped onto my arm. This is because if you read the messages carefully, you will notice a couple of "< br >" tags popping up.

This is not a security issue, but it does mean that whom so ever wrote those pages is probably a moron! "< br >" was/is the tag used in HTML to induce a line break. However, newer standards such as XHTML and HTML5 insist on using "< br />" for technical reasons. Believe me, it's a good idea. So, this lead me to the conclusion that most facebook web developers have written sloppy HTML/PHP/JScript/Whatever else they use and that is causing the "safety filter" to go off at least twice a week on my account. Also, I'm not sure how good the code for the "filter" is. I have very low expectations.

The first time I was logged out by this "filter", I was impressed that facebook had implemented such a feature. I guess that they had some bugs in it, which was understandable. With each subsequent occurrence of me being "filtered out", I grew more sceptical. Then when I saw the horrendous HTML code in the warnings, I gave up hope and waited for it to happen again to make screen shots.

I didn't have to wait too long. Most people would say "Well at least they tried!" To which I reply, "Welcome to cyber-security, where a half-assed attempt doesn't count!" Really, facebook, get your act together and actually make an attempt and then maybe I'll be impressed and stop writing evil comments on the your security fan pages.

Sunday 12 June 2011

Quick post on how I may be kind of wrong.

If you know me at all, you will know that I have strong opinions on some things. If you don't know me, you now know that I have strong opinions on certain things. Now that everybody is caught up, let's all sit back and enjoy me being wrong-ish. I had a post earlier, which really is based on the fact that access to the Internet is a privilege, that some people abuse. Well now the United Nations has declared it a human right. My argument falls flat on it's face. I'm a big boy and I am willing to admit that in light of this, those arguments no longer hold water. Things change, people's ideas are made to be wrong, that's life.

Also, just a minor side-note: read this article!

Monday 6 June 2011

Cyberwarfare Part 2 (No more lazy me, for now)

Alrighty then, we had a basic intro to cyberwar in my previous post. In between then and now, the clever chaps at the SIS, commonly incorrectly referred to as MI6, told us about this little gem. This has to be one of the funniest things in existence... EVER!!! But minor state-sponsered hacktivism aside, back to the crux of the matter: the issues arising from cyberwar.

One of the main problems is that you may not even know that you were attacked. If somebody blows up a building the sound, and the lack of building, would alert you pretty quickly to the fact that there was an attack. The attacker may have installed some malicious software on your system or copied some data and you would be none the wiser. Yes, there are ways to detect this, but it is very possible that you wouldn't even notice.

Not only is it the lack of physical evidence, but also the time scale. Normal wars tend to take a long time. If you don't notice you are at war, well then you have bigger problems than the army barrelling down you front driveway. A cyberwar or cyber attack can be executed and completed within a matter of hours, if not minutes. It is really that fast. Yes there is a lot of prep time required but this is analogous to training your army, building your tanks etc.

Then there is the last (I promise, well for now) issue arising in cyberwar: non-interactivity. To take a touch of a cryptographic twist onto the whole matter war is an interactive protocol. Sure if you surprise the enemy they won't know they are at war right away, but they will pick up pretty quickly and then return in kind. The thing with cyberwar is that not only is the decision to go to war unilateral, but in some sense so is the war. One party decides to attack another party and does so. The other may or may not discover this and may or may not respond in kind. But again the whole thing is done very non-interactively (despite what pop culture (couldn't find anything for that, sorry) and video games may tell you).

So, to sum up: cyberwar is confusing, unclear, hard to track, pinpoint and blame the perpetrators and is inherently non-interactive. And if that wasn't bad enough, the actual definition of cycberwar is pretty fuzzy and very much up in the air right now. Most likely I may revert back to lazy me. Unless something cool happens.

Friday 3 June 2011

Cyberwarfare Part 1 (A post I have been procrastinating on)

Well this post has been in the works for a couple of week now. I have been procrastinating on a epic level about finishing this off. However the universe decide to give me a kick in the backside in the form of these related recent articles (all links to separate slashdot stories)

So, in recent times, there has been a lot of talk of digital warfare, internet wars, cyberwar and so forth. The most recent being the aforementioned. The general idea behind them is all the same, we have a strategy/army/assets/whatever for cyberwarfare. What happens when warfare goes from being about things in the real world to things in the digital world?

So let's start from the start shall we? What is modern warfare? (apart from a terrible pun on a pretty good video game) War as a concept is fairly simple. Two nation states (in general) disagree on something and wish to resolve the issue. So basically they start blowing each other up until they get bored or one party is very very dead. Yes, that is a gross oversimplification, but the concept holds. Now, onto the crux of the matter: What is Cyberwafare?

Cyberwar (which is the term I shall be using from now on, because I think it's the coolest) is essentially a war fought in the digital realm. This is generally in tandem with conventional warfare with the aim of disabling digital assets. There could also be political goals, achieved by defacing websites and so on, but IMHO the main goal is the destruction of digital assets.

Well, this is all pretty fine and dandy when the war is being carried out by nation states, because there is some inherent chain of command and somebody who would be responsible for ordering these attacks. However, this is not always the case with cyberwar. Now you may ask "why this is possible?"

Good question. The thing with conventional war (ignoring any peace negotiations) is that the winner is the side with the most and/or better equipment and/or training. There is the main point where cyberwar becomes so much easier. To build a real army you need to train people to drive tanks and fly planes and shoot guns and blah blah blah. To build a cyber army, you need to teach people how download a program and run it.

Here the "army" is recruited by word of mouth and because there is no physical danger caused by participating in this attack the number of people who join in are much more numerous. However, we do fall into an interesting problem: who is responsible for this attack, which is essentially tantamount to an act of war?

The answer to the question is ill-defined at best. An prime example would be the recent attack on the Playstation Network (another blog post I will finish soon). First Sony said it was Anonymous, who then claimed it wasn't them, but then it later turned out the be a "faction" (for lack of a better word) of anonymous. So here we see no chain of command and the leaders of the group had no idea what the other members were upto.

And there in lie the first complications of cyberwar. First off, we have the ability to engage in cyberwar. ConvenConventional warfare requires a substantial amount of resources, which are pretty much never available to the average individual. In the cyber realm, all you need is an Internet connection and possibly some more people to help out, or just their computers (whole other problem there, which I will cover later). And then there is the problem of accountability. At best you get an IP address(es) for the attacking platform(s) which may just be under the control of the attacker (again, to be covered in more detail in another post) and thus may not yield anything useful.

Now, this post is getting pretty long and falling into TL;DR territory. That and I really don't want to write anything more at this point in time. So, I will end here and will pick this up later (note the "Part 1" in the title of the post).