Scheming on a Thing

May 9, 2007 · by Scott Fradkin

I’ve decided that I really need to be more multilingual. Not in the sense that I should speak another verbal language, though that would be a really great idea, but in the programming language sense.

All of the languages that I’ve learned in the past are standard procedural, object-oriented languages. There is a whole other realm of languages which I hadn’t really taken a look at before, functional programming languages. That’s one of the things that really stands out about Ruby. Ruby has a wide range of uses, but the most noticeable thing about it is that even though you can use it as an object-oriented language, it contains a lot of functional programming paradigms.

Functional programming is a bit strange to wrap your head around if you’ve never really used it before. The entire structure is based upon Lambda Calculus which seems to be nearly impossible to understand unless you’ve got a degree in mathematics. Lambda Calculus basically says that you can represent everything as a function that takes one argument and that argument can be another function. There are ways to represent the natural numbers, standard arithmetic, and even logic functions via Lambda Calculus. It’s pretty heady material to read.

I got curious and started taking a look at Scheme. Scheme is a derivative of Lisp, which makes it one of the “parentheses” languages. Lots and lots of them. It’s no worse than having curly braces everywhere, really. Functions are first class objects. It uses stack notation to perform arithmetic, so there is no operator precedence. It’s a really interesting language. I haven’t really used it for anything yet. I’m still looking through the language specs trying to figure out everything it can do. I’m sure I’ll have more things to say about it in the future. Until then, I’m just going to have some fun with it.

Filed in: Team Member Blog Comments (1)languages

MD5 Checksums

April 5, 2007 · by Scott Fradkin

I recall a few weeks ago, one of my wife’s brothers was visiting and installing a piece of software on her computer. I casually mentioned as he was downloading that he should grab the MD5 checksum so that he could compare it against the downloaded file. He said that he didn’t even know what that was.

Verifying a checksum is a fairly important step in validating that a file that you have downloaded is definitely the file you expect it to be.

Here’s how it works:

• The person with a file for download will use an MD5 utility to generate an MD5 hash.
• The file and the text of the hash will be put onto a server for download.
• The downloader downloads the file to his or her computer.
• The downloader uses an MD5 utility to generate an MD5 hash of the downloaded file.
• The downloader compares his or her results to the posted MD5 hash. If they are the same, then the file is legitimate. If the hashes are different, the downloader should not open the file.

Of course, this does mean that there has to be a certain level of trust between the downloader and the website from which the file is downloaded. Files and checksums can be replaced to look legitimate when they may include viruses or other worms in them.

On a Linux system the utility md5sum is usually installed by default. For Windows systems there are various third party utilities that can be downloaded to calculate hashes. One is called digestIT and can be found at http://www.kennethballard.com/modules/xproject/index.php?op=viewSummary&pid=2. The md5sum command line utility has a Windows version which can be found at one of a number of links listed on OpenOffice.org’s website http://www.openoffice.org/dev_docs/using_md5sums.html.

The output of an MD5 hash is a 32 byte hexidecimal number which can be a little tough to manually inspect, but the Windows programs usually do the comparison for you. Some websites have started using SHA1 hashes (which generate 40 byte hexidecimal numbers) instead since SHA1 is more secure and harder to find hash collisions for. Many of the Windows programs will also perform hashing for this and other algorithms. In Linux, the OpenSSL program can calculate many different hashes.

The actual algorithms aren’t too complex, but the discussion takes up a fair amount of space. I may post about those at a later time.

I’d encourage everyone to use the checksums when they are available. Even if you’re downloading from a trustworthy website, you never know if the files have been surreptitiously replaced. It’s a good security habit to get into.

Filed in: Team Member Blog Comments (0)

Proving Your Identity

March 17, 2007 · by Scott Fradkin

Email is a wonderful communication tool.  It’s also a wonderful way to spam people, phish for their personal information, and to be a general nuisance.  What if instead of having spam filters to filter out all the unwanted email, all you have to do is filter out any email messages for which the sender can’t prove his or her identity?

I can send email to anyone anywhere in the world and claim that I’m someone I’m not.  It’s really not that hard to falsify email message headers and even the TCP/IP packet headers to look like the data is coming from someone else.  This should be a huge red flag to everyone who uses email, but for some reason it’s usually overlooked.

There is a decent solution to this problem.  There is an open standard for PGP (Pretty Good Privacy) called OpenPGP (the open source GNU implementation is called GnuPG or GPG).  If you’re interested in all the gory details, the RFC is available [RFC 2440]. Many people have heard of PGP, many have not.  Of those that have heard of PGP many may not know exactly what PGP does for you or how it works.

So, what does PGP actually do?  PGP allows a user to digitally sign and/or encrypt and decrypt data.  Sounds pretty simple.  The standard allows a user to generate a public/private key-pair with which pieces of data can be digitally signed or encrypted.  It allows for a bunch of different key generation, hashing, and encryption algorithms.

To start with a user needs to generate a key-pair.  The key (no pun intended) to generating a nice and secure private key is to make sure that enough random entropy is created during the key generation and that a strong passphrase is used.  Key generation algorithms use the random byte generator of the underlying operating system to generate sufficiently secure keys.  The operating system usually generates securely random bytes by sampling data from the various system interrupts (you can find the source code from the random byte generator in the Linux kernel fairly easily).  This means that the more typing and mouse movements are performed during key generation, the better the random bytes should be.  A strong passphrase is necessary so that in the event that the private key is compromised, it will be exceedingly difficult for someone to guess or crack the passphrase so they can emulate your digital identity.

After the key-pair is generated, the public key should be exported into one of the OpenPGP keyservers.  The main keyserver can be found at http://keyserver.veridis.com:11371/.  It doesn’t really matter too much which keyserver the key is exported to.  All of the OpenPGP keyservers replicate with one another.  By exporting the public key, it will be available to anyone who wishes to import that key to validate a signature or identity.

Now that everything is setup, things can be encrypted and signed!  Email is probably the thing that PGP is used for the most.  By signing email messages with your private key, a user who receives the email from you can import your public key and use that to verify that the email was actually signed by you.  Encrypting email goes one step further.  By encrypting an email with the recipient’s public key and then signing the entire encrypted email with your private key, the recipient is assured that the email they receive came from you and could not be viewed by anyone else since they do not have the private key necessary to decrypt the message.

This is all well and good, but how do you prove that your public key really is yours?  The OpenPGP standard includes a trust model.  The GNU Privacy Guard handbook calls this trust model the “web of trust”.  Everybody is allowed to sign any public key.  Generally, you would only want to sign someone’s public key if you knew them personally.  When you import a public key you can view the signatures on that key.  It’s possible that someone you know has signed keys that you haven’t signed and when you notice this you may want to sign that key also.  Eventually, this model of key signatures should build a web of keys that you have signed either because you trust one of the signers either directly or indirectly.  To go along with this, you can privately set various trust levels on each public key so that when you view emails signed with someone’s key, you will know to what level you trust that signature.

The largest problem with the adoption of at the very least digitally signing email messages is that a lot of email programs do not come with PGP/GPG support built in.  I currently use Mozilla Thunderbird as my email program with the Enigmail OpenPGP plugin.  Underneath the covers Enigmail uses GPG.  I’ve been trying to get into the habit of signing my email most of the time.  Even though most people don’t use OpenPGP aware email programs, I’m hoping that this raises awareness of the necessity to verify that the email that we receive everyday is really being sent by the person claiming to have sent it.  I’d also advocate for encrypting messages, but that requires the recipient to also have an OpenPGP key-pair.

One thing that’s left in the background of all this is that a PGP key can also be used to encrypt and decrypt local data.  If you have some files on your harddrive that you want to be secured, go ahead and encrypt them using your own public key.  The files cannot be decrypted unless someone has both your corresponding private key and your passphrase.

In a nutshell, digitally signing email is a good thing.  It helps to validate the sender of the email.  The OpenPGP standard has a nice trust framework built in to help people decide how much they trust the identity of the sender.  Encrypting email and signing it provides even more protection of the contents of the message.

Below are some extra resources about OpenPGP.

• RFC 2440
• OpenPGP Alliance
• GNU Privacy Guard
• Enigmail
• PGP Corporation

Filed in: Team Member Blog Comments (0)

Barcamp Madison 2007

March 4, 2007 · by Scott Fradkin

I made it to the Barcamp on Saturday and it was great.  I really wish that I would have been able to stay longer, but I was only able to attend on Saturday afternoon.

From the beginning, the Barcamp embraced the Wiki concept.  All planning information was kept updated on the Barcamp Madison Wiki page and it continued to be used throughout the event.  When checking in, one of the people manning the registration desk was entering attendees names into the Wiki along with sessions to let everyone know that the person had arrived.  As everyone chose when and where they wanted to hold their sessions, someone was putting an electronic version on the Wikis.  During the event, people updated the Wiki with new information.

The Barcamp was well attended.  Though the goal was to get 400 people to the Barcamp, at last count 128 people were added to the “Present” portion of the Wiki.  I have to say, it really seemed like more than that were there.

I did manage to lead two sessions right away in the afternoon.  The first session I gave a presentation about Gentoo Linux.  There weren’t too many people there, maybe 15 – 20, but they all seemed to be pretty interested.  Hopefully they enjoyed the presentation.  The presentation is available on my website for download [tech.fradkin.com].  The second session I threw out there because there were no Ruby on Rails sessions listed.  I ended up just facilitating a nice discussion about Ruby and Rails.  There was enough interest that a bunch of us holed up in the Hack Room for an extra 2.5 hours and discussed Rails 101.  I let others take over to demonstrate Rails for those who had never seen it.

There were a  bunch of people with cameras taking all kinds of pictures and video.  If you head over to flickr and check out all the images tagged with barcampmadison, you’ll see some of the action.  I even found some pictures of myself.

Just before I left the Barcamp, one of the organizers, Ken Rheingans, asked me if I’d consider being one of the Ruby on Rails Community organizers for Barcamp USA.  I accepted.  Now, I’m considering helping out with the Linux Community also.

So, put August 23 – 26, 2007 on your calendars now.  Barcamp USA is at the Jefferson County Fairgrounds, just a hop, skip, and jump away from Madison.  They’re expecting around 5000 people to attend from all over the US and even from overseas.  As fun as Barcamp Madison was, I expect that Barcamp USA will be even more fun.

Filed in: Team Member Blog Comments (1)

This is All Weekend

February 24, 2007 · by Scott Fradkin

def isItSnowing?
 true
end
 
def howMuchSnow?
 if isItSnowing?
    puts“a ton”
 end
end

howMuchSnow?

Filed in: Team Member Blog Comments (0)ruby

On Randomness

February 24, 2007 · by Scott Fradkin

What does it mean to be random?

To most observers as long as numbers/characters/events don’t show any type of descernable pattern while being observed, those items would be considered to be random.  Coin flips are random.  Dice rolls are random.

There are official definitions of the word random.

From www.dictionary.com:

• Having no specific pattern, purpose, or objective
• Of or relating to a type of circumstance or event that is described by a probability distribution.
• Of or relating to an event in which all outcomes are equally likely, as in the testing of a blood sample for the presence of a substance.

Why is this even important?  Randomness is the key to good security.  Random numbers are used to generate keys used in encryption, they are used in generating hashes, they are used in stream ciphers, and in other areas of cryptography.  In order for messages, data, and identities to remain secure, the random numbers and bytes need to be as unpredictable as possible.

This area of cryptography and mathematics is widely studied.  People are becoming more and more interested in privacy and want their data to be secure.

There are many different ways to generate random data.  Some are very predicable, some are unpredictable, some are fairly secure, and yet others are considered to be cryptographically secure.  The need for the different types depends upon what kind of security is needed for your data.

Stay tuned to future entries about Randomness and how random data can be generated.

Sources:
Wikipedia(Randomness)
Wikipedia(Random number generator)
Wikipedia(Cryptographically secure pseudorandom number generator)
Bruce Schneier, Applied Cryptography

Filed in: Team Member Blog Comments (0)

Ruby Implementation Speed Shootout

February 19, 2007 · by Scott Fradkin

Check out this write-up that has been written about how fast different implementations of Ruby run.

It points to good things for the next generation Ruby implementation, YARV.  The next release of Ruby does away with the single-pass interpreter that it currently uses and adds a real virtual machine.

Filed in: Team Member Blog Comments (0)ruby