Raaz: A cryptographic network library for Haskell

This is my first post on Raaz, a cryptographic network library for Haskell. Raaz broadly aims at developing into:

1. A platform to experiment with various cryptographic primitives.

2. A library to write high performance servers and clients to some common cryptographic network protocols.

I believe that Haskell as a language has a lot of features that allow writing fast (as fast or better than any C library available) as well as secure cryptographic code. In this post, I attempt to explain some of the features of Haskell that we make use of.

Speed

Let me first dispose of the one myth that seems to persist in the mind of people who have never seen a modern functional language. No one wants their software to be slow. Cryptographic protocols should be especially well implemented otherwise folks would simply avoid using the secure options. Clearly when it comes to performance Haskell can beat any of the interpreted languages Python, Ruby or Java. But what about C?

The tight loops in the library which implements the primitives will anyway be written in C/Assembly. If one wants speed then one needs to do this whether one likes it or not. So for primitives it really does not matter which language one chooses. It then boils down to how easy it is to integrate C/Assembly code with Haskell. Having a low overhead foreign function Interface (FFI) is really critical here and Haskell fortunately has it.

Having fast primitives helps but a network library is not just a set of fast cryptographic primitives. Here are some of the features that one would.

1. High performance concurrency primitives for server applications. Haskell really has no competition in this department. Here are some of the features that GHC (and libraries) supports: Light weight threads (green threads), STMs, MVars etc. Using these features, servers written in Haskell have been competitive (often outperforming) servers written is C. See for example mighttpd.

2. Efficient data serialisation and parsing libraries: Implementing the wire protocol efficiently is critical in improving the efficiency of the network application. Haskell is especially rich in this department as well: attoparsec, binary, blaze-builder etc. There are libraries that supports high performance (close to hand written C performance) at the same time achieving these feats at a much higher level of abstraction (which translates to less bugs and high maintainability).

While having fast libraries is great, languages like C achieve this at the cost of abstraction. It often appears to the programmer that one needs to sacrifice elegance for speed. Not so with Haskell. Many of the libraries I mentioned above achieve C speed with no compromise on the level of abstraction. This greatly enhances the maintainability and leads us to the next important feature that we want in our libraries, safety.

Safety.

Cryptographic implementations are full of corner cases and the bugs in them can be particularly lethal. A cryptographic library is usually broken, not by a direct attack on the underlying algorithm, RSA although quite dated is still secure, but through other means like buffer overflows, cache timing attacks and other side channel attacks. How can one minimise this? Let me give an example of a code which, while correct in normal circumstances, is bad in a crypto setting. Suppose you grant privileged access to a user by comparing a secret that you posses with the user supplied password. A naive string comparison will be prone to timing attacks: The time taken to reject a password is proportional to length of the longest common prefix of the secret and the password. The attacker then can guess the password one character at a time by looking at the time it takes for you to reject the password. One would usually not compare the secrets directly but hash them together with a salt and the hashes. However, any comparisons that take time dependent on the user input is prone to lead to future attacks when deployed without much thought.

We could avoid this problem by asking users of our library to always use string comparisons that take constant time irrespective of the input. However, it is very likely that a user of our library, most of them will not be cryptographers, might miss this instruction. Won’t it be nice if such incidents are caught at compile time?

We avoid this problem in Haskell by leveraging its type safety. Instead of representing cryptographically significant data types like hashes, macs etc. as mere byte string, we define Haskell data types for Them. For example sha1 hashes are represented (in a simplified form) as follows:

module Raaz.Hash.Sha1 ( Sha1 )

data Sha1 = Sha1 Word32 Word32 Word32 Word32 Word32

instance Eq Sha1 where
	(==) (Sha1 h0 h1 h2 h3 h4) (Sha1 g0 g1 g2 g3 g4) 
             =   xor h0 g0
             .|. xor h1 g1
             .|. xor h2 g2
             .|. xor h3 g3
             .|. xor h4 g4
             == 0

The Eq instance for Sha1 has comparison operator defined in such a way that it will take time independent on the number of positions they match. A user is then be forced by the compiler to use this equality as we will not be exposing the constructor to her.

Status of the project and how to contribute

Currently we have just began. We have made no releases yet and we are still experimenting with the API. All code is available under BSD3 license from http://github.com/piyush-kurur/raaz).

I look forward to your contributions. In particular, if computer architecture is your bread and butter and you are the Chuck Norris of assembly language programming, do join us for some fun coding: A lot of primitives require fast implementation often exploiting the platform specific features like SIMD instruction set.

Comments on this blog.

This blog does not support comments. The reasons are the following

1. This is a static using no dynamic PHP or any such monstrosities. I could have something like Disqus.

2. I am already full with spams in my inbox and do not have the motivation like others to weed out the spam.

However if you are motivated, and feel that some one is wrong on the internet, then you can send your comments to me via email. I hope to make the source code of this site open to all. Once that happens you can also send patches to me which will be incorporated.

Update 28 May 2013: The entire hakyll source is available at http://hub.darcs.net/ppk/website

Webpage Reloaded

This is my very first post. It also coincides with the entire rewriting of my homepage and these two events are not independent. I used to use a set of Makefiles for dependency checks, pandoc for generating html, m4 for templating and no css. The stuff worked but it soon became difficult to maintain.

It was more or less clear to me from the start that I wanted a static site managed via darcs, written in markdown. Of course there is jekyll but I always thought pandoc was way more powerful than some of the other markdown processors that comes with jekyll. And then I heard of hakyll. It uses pandoc as its markdown processor which means that I get all the pandoc goodies: easy math integration, syntax highlighting, and possibility of using different input (say latex) and output (say pdf) formats. Besides, it is written in my favorite programming language. No more excuses for a bad homepage.

I never thought my page would ever be styled with css. As a language (if you can call it one) css is pretty lousy, maybe slightly better than html. Besides, no two browser seems to agree on the standard. Who, in their right senses would want to work with it ? Compass made me change my opinion. Firstly, you can use the sass now instead of css, an advantage comparable to using markdown instead of html. Secondly, it has mixins that take care of all (most) of those browser incompatibilities. It might not go well with IE users: I don’t know, neither do I care to know. But it should work mostly. The style for this page is entirely written in sass using the compass framework. I will publish the source code soon after some refactoring.

Thanks to the great softwares mentioned above, I now have a clean homepage complete with a blog and atom/rss feeds. Some lecture notes that I had are not yet hakyllised. It will soon be.

A big thank you to the folks behind hakyll, pandoc and compass.

Update 18 May 2013: I have added my old wrtings as blog post. So it might appear as if this not my first post.

Why kick Elsevier?

This is my understanding of the issue. You are free to send me any correction.

Economic damage

1. High cost of journal subscription. Journals of Elsevier are too costly. What is worse is that they have taken over other journals and currently have a huge monopoly.

2. Bundling journals. Libraries have to subscribe to a bundle to get a few journals of interest. Often bundles contain journals that are not of any interest to a particular institution. Worse, they include journals which themselves are questionable: e.g. journals like Chaos, Soliton and fractals.

Unethical publishing practice

1. Reviewing, which is important scientific responsibility of any journals, have been a sham in many cases. For example, Journals like Chaos, Soliton and fractals have published 302 papers from their Editor-in-chief El Naschie. (See http://rationalwiki.org/wiki/Mohamed_El_Naschie)

2. Setting up journals on pseudo-sciences like for e.g. The Homeopathy (No link given so that they don’t get the benefit of page ranking) which give them unnecessary scientific credibility. Astrologers, What are you waiting for? Call Elsevier right now.

3. There has been cases of Elsevier publishing many fake papers written by ghost writers in return to getting paid by drug companies. See for example

   • The Scientist article on Merck affair
   • They do it again

4. Reed Elsevier’s role in arms trade (See http://www.idiolect.org.uk/elsevier/) While an action that is difficult to justify, I would not consider this hurting the scientific publishing directly (other than the minor danger of completely wiping out humanity and thus the scientific establishment, at least on earth). With pressure mounting, apparently they have given up on this illustrious business.

Summarising, the business practice of Elsevier has hurt scientific foundation not only economically but also led to lose of scientific credibility due to the questionable publishing standards they have followed.

What can we do ?

1. Boycott them. See http://thecostofknowledge.com.

2. If you are an editor of an Elsevier journal, resign now and encourage your fellow editors to resign en masse. See

   • Journal of Algorithms editorial board resignation
   • Resignation of the editorial board of Topology

3. If you happen to be in the library committee of your institute try to get Elsevier out of the subscription list.

4. Support and form journals like Theory of Computing

5. Make all your work available on the net.

Remember all of this is not without ``risks’’. So evaluate the best options for you and make up your mind.

SSHFS: Remote directory over ssh

Often one wants shared access to files across machines. Traditionally one uses the network file system (nfs). The network file server works as follows: There is an nfs server that exports some directories in its filesystem hiearchy to various nfs clients that mount these directory over the network into their file system hierarchy. As a result, each of the clients shares the directories exported by the nfs server. However nfs is probably the worst protocol when it comes to security and is rightly called network failure system.

This is a tutorial on sshfs or ssh file system. The idea is to provide a nfs like mount which is secured by the very dependable ssh (the sftp subsystem of ssh).

Using sshfs.

1. First mount the remote directory onto a local directory

1
2

$ sshfs ppk@remote: path/to/mount

where path/to/mount is the point where you want the remote file system to be mounted.

2. After step 1, path/to/mount on your local machine is actually the home directory of the remote machine. So you can use it just like a local machine. Expect slow response if your network connection to remote machine is slow though.

1
2
3

$ cd path/to/mount
$ emacs myfavoritprogram.hs
$ ghc myfavoritprogram.hs

3. After you are done with the work on the remote machine you may unmount the file system

1
2

$ fusermount -u path/to/mount

How it works.

Sshfs is a userspace file system (fuse) that works over ssh, or rather sftp. Fuse is an implementation of filesystem primitives in userspace rather than in kernel space. This essentially means that users can mount and unmount file system without having to be root. Sshfs makes use of the sftp subsystem to do the remote file system operations. Thus all the great features of ssh holds true, i.e. key based authentication, use of ssh-agents. See my tutorial blog on ssh for more details on how to use ssh.

Installing sshfs.

All linux distros have a prebuilt package for sshfs. On Debian/Ubuntu and Arch the relevant package is sshfs. So all you need to do is to install it.

1
2
3
4

$ aptitude install sshfs # as root.
$ sudo aptitude install sshfs # if you are on Unbutu
$ pacman -S sshfs # as root on an Arch machine

On Fedora it looks like it is called fuse-sshfs so something like this should work.

1

$ yum install fuse-sshfs

Ssh is working but not sshfs.

A common error that people have reported is that ssh works but sshfs fails. If this happens, check whether your sftp subsystem is working. Most probably this too would fail or work incorrectly. One of the main reasons why sshfs/sftp does not work is because your startup scripts in the remote machine prints stuff on the screen. To check this out, try the following command.

1

$ ssh ppk@remote /bin/true

If this command produces any output then you are in trouble. You have to fix your startup script in your remote machine — .bash_profile and .bashrc, if you are using bash as your default shell. The startup script should check whether the standard output is a terminal before it outputs something. For this protect your output generating commands inside a test -t 1 block as follows

1
2
3
4
5
6

$ cat .bash_profile

if [ -t 1 ] # Check if stdout is connected to a terminal
then
    echo "The answer is 42"
fi

See the openssh FAQ for more details.

SSH: A quick guide

The secure shell or ssh is much more than a secure replacement for telnet. Using ssh is not only secure but also convenient. We will have a look at ssh in this article. The objective is not to explain all the features of ssh, for that you can consult the man page, but to examine some of the key features and their use. All the code in this poset should work if you cut and paste (without the $ prompt of course) it on to the terminal. Also by ssh I mean openssh throughout.

Your .ssh directory

All the files used by ssh are inside the .ssh directory in your home area. Here is a list of them and their use.

• known_hosts: This file contains the public keys of some of the hosts that you have logged in to.
• id_rsa: RSA private key.
• id_rsa.pub: RSA public key.
• id_dsa: DSA private key.
• id_dsa.pub: DSA public keys.
• authorized_keys: List of public keys of users who are authorised to access this account.

Managing known_hosts

The known_hosts file contains the public keys of all the hosts that you have logged in to. It is a good idea to get these known hosts from a trusted source. When your ssh client contacts a server, it receives public key of the server. If there is a mismatch, ssh warns you that the key has changed. This could be due to a man-in-the-middle attack or due to a system reinstallation. When you get such a message it is better to be sure that there is no tampering. Be especially careful if you in an unknown LAN or WiFi network like that of an airport or a hotel. Having a trusted known_hosts file is a very good security measure.

Key based login.

Usually one uses ssh with passwords to login. Although this is secure in the sense that the passwords sent are encrypted, it has all the problems of password based authentication. An alternative is to use public key/private key based authentication. The public key access is more secure and in fact more convenient than the password based access. Here is the step by step procedure.

1
2

$ ssh-keygen # Generate the public key/private key pair.

You will find the generated keys inside the .ssh directory. The files with extension .pub are the public keys. Copy them into the .ssh/authorized_keys file of the remote machine.

1
2
3
4
5
6
7

$ scp .ssh/id_rsa.pub @remote:
$ ssh remote
ppk@remote: mkdir .ssh
ppk@remote: cat id_rsa.pub >> .ssh/authorized_keys
               # copy the key to the authorized_keys file.
ppk@remote: chmod 644 .ssh/authorized_keys
               # Ensure that it is readable only to user.

The last step is particularly important. Ssh will refuse to login if it finds that the .ssh/authorized_keys is writeable to someone other than the user. Otherwise an intruder could leave his public key and will have unrestricted access. So do not forget to change permissions. Many have been stumped by this and ssh does not give any indication on where the problem is.

In case you connect to many hosts it is a good idea to install the same public key in all the different hosts you log into. Thus you need to remember only one passphrase for all these hosts.

Generating keys from a Windows machine

Of course the best option is to install yourself an operating system, one of the BSD’s or GNU/Linuxes for example. However if you don’t have that option, you will also be forced to use other ssh clients like putty. My experience with these clients are limited and that prevents me from giving a detailed procedure. Usually they have a click-click interface to generate keys. The keys generated are however not in the format expected by by openssh. Don’t you worry. The correct format is only a command line away.

As before you have to copy the public key to the remote machine. The command

1
2

$ ssh-keygen -i -f pubkeyfile

will convert an SSH2 compatible key format, which is what many of the commercial ssh-client uses, to openssh compatible key format and print it on the standard output. So after copying the public key to the remote machine, you can type

1
2

$ ssh-keygen -i -f pubkeyfile >> .ssh/authorized_keys

on the remote machine.

Passphrase, Empty Passphrase and SSH-agents.

While generating a public key/private key pair one is asked for a passphrase. The passphrase is used to keep you private key encrypted on the disk. It is never sent across the network or used in the protocol. Thus one can use an empty passphrase in which case the private key is kept unencrypted on the disk. In case your machine is a private laptop this is not such a bad idea. The advantage of an empty passphrase is that you will never have to type any passwords while ssh-ing or scp-ing. However there is always a risk of your private key getting compromised if the local machine from which you log on to the remote machine is a shared machine. You could, for example, forget to logout from the common terminal. So it is a good idea to have a passphrase.

A better alternative to an empty passphrase is to use an ssh-agent. The ssh-agent keeps you private key with it and does all authentication on your behalf. Here is a quick example.

1
2
3
4
5
6

$ ssh-agent bash  # start a new shell session with an ssh-agent running
$ ssh-add         # add your public keys to the agent.
$ ssh remote      # No passphrase will be asked
ppk@remote: exit
$ scp foo ppk@remote:  # No passphrase will be asked.

I like to use ssh-agent in conjunction with screen (another cute program). This is what I do.

1
2
3

$ ssh-agent screen # start a screen session with an ssh-agent
$ ssh-add          # in any of the windows of the screen.

Now no passwords are asked in any of the windows of the screen session. Usually I leave my screen session running in the office machine (which is physically secure as only I have the key to my office) and when I connect from home, I attach my self to the already running screen in my office machine.

1
2
3

ppk@home: ssh office
ppk@office: screen -x  # connect to the already running screen

When I am done I detach the screen. Thus one can go on for months without typing any passphrase for any of the ssh/scp/sftp sessions.

SSH-tunneling or port forwarding.

One of the most powerful uses of ssh is its ability to port forward. You can build an ssh tunnel and connect a local port to a remote port. For all purpose this local port is the remote port. For example suppose there is an smtp server (mail server) running on remote which relays mails only from remote. You can set up a tunnel that connects your local port with that of the remote smtp port provided you have shell access to the remote host. Here is how you do it.

1
2

$ ssh -N -L 2500:remote:25 ppk@remote &

Now you have a smtp server “running” at port 2500 of your machine. All the traffic to port 2500 is redirected via the ssh tunnel to the port 25 of the remote machine. If you want to actually forward the port 25 of you local machine, you need to be root on your local machine as this is a privileged port. However you don’t need root access on remote.

Using tunnel devices and ssh port forwarding one can also setup vpn like network. We wont go into the details in this article.

Markdown: or how I stopped hating html and started liking homepage creation

% Piyush P Kurur

It was hate at first sight. I remember quite well my first encounter with html. It was way back in the previous century (somewhere around 1997-98) when I first saw an actual html page. It looked uglier than the DO 10 CONTINUE lines of Fortran 77 that we were forced to use as part of our B.Tech “Learn how to use a computer” course. Many of my friends considered this Fortran course as part of the “Ragging” that one has to endure to become Engineers. But I am sure when they started their webpage creating phase of life they would have come for an even bigger shock. To put it politely: html is an ugly format that has caused more miseries to humanity than all the world’s religions put together.

The popularity of html is baffling. It is not the most efficient of the formats from the rendering point of view and definitely not a format for mere mortals. The kludge called html also brought about an industry of WYSIWYG html editors which really spits venom when asked to render a Hello world page. This has lead to many “Best view by …. under 1024 x 798 resolution” pages; so much for the “portability” of html. Despite all these shortcomings html became popular. What more its “success” as a text format lead people to the creation of even uglier cousins like XML.

In this difficult world I had to make my homepage. Having a homepage is important in today’s world, they say. It is important to have your papers online, for example, in the unlikely event that some one is interested in your work. But the ugliness of html was unbearable. I searched far and low for other ways to create html including LaTeX2HTML. All had their drawbacks.

Enter Markdown. This really changed my life as far as webpage creation is concerned. Here is a format that one can easily convert to html and is as pleasing to write as an anonymous hate mail to your boss (markdown’s format is based on email conventions). To convert markdown to html one just uses the markdown.pl script. However my favourite converter is the swiss army knife for format conversion pandoc. Pandoc is a program that can inter convert between various text formats much like the convert for image formats. This means that if you already have an existing homepage you can use pandoc to first convert it into markdown, edit it and then reconvert to html. Pandoc also supports much needed extensions like the inline math a la LaTeX, a horror if one has to do it using MathML.

Pandoc is not just a text format converter. It comes with a supporting Haskell library which can be used to program specialised converters if needed.