Rosio Pavoris

In case you’re one of the three remaining peope who doesn’t know what Tor is, it’s basically an anonymising proxy on steroids.
Any request you make over a network (say, to retrieve a web page to display in your browser) is sent to a random node in the network, which then passes it on to the next node, which passes it on to the next node, and so on, until it finally reaches its destination. Each node only knows about the previous and the next node in the chain, so it becomes impossible to trace who made the original request.

Everything’s encrypted except for the final step between the last node and the webserver (for example), so some care should be taken when entering passwords and things, as a malicious exit node can intercept those if you don’t use things like TLS or other end-to-end encryption.
This is, of course, just as much of a risk on the internet in general (and one too many people aren’t aware of, too).

It’s pretty slow, since far more people are running clients than nodes (I’ll be setting up a node myself as soon as my ISP stops sucking; I’m giving it another week), but it’s not meant for general browsing (and certainly not filesharing) anyway; there’s a plug-in for Firefox that lets you turn it on briefly when you need it, and disable it when you don’t.

As with all privacy-preserving tools, genuinely undesirable activity is an issue (see picture), but the potential for good is considerable. While it may seem paranoid in (much of) the West (though maybe not even), much of China, for instance, depends on tools like these.
And you never know, you may need it yourself one day, and it’s better to become acquainted with it now than when it’s too late.

Get it here, if you don’t have it already. You don’t have to run a node (you can just set up the client (complete instructions for configuring Firefox to use it are there)), but if you can, please do. People depend on it.

So I probably should too.
This video describes a simple but effective attack again whole disk encryption and similar cryptosystems, based on the fact that, contrary to popular belief, modern DRAM retains its data for some time after power is cut, and the encryption key is stored in said DRAM.

There’s some more information in the full paper.

There are some obvious ways to defend against this as a user. One is to not leave your computer unattended while you’re logged in, or for several minutes after you’ve logged out and powered down.
The former should be obvious, but isn’t, and BitLocker’s thing that lets you boot straight to log-in makes it less than straightforward. Though if you use Vista, chances are you’re only doing the encryption thing because your boss made you anyway, and you don’t care about security or privacy.
Basically, if you aren’t typing the encryption password as well as your account password every time you boot, you have a problem.

It shouldn’t be too difficult to have the OS or some hardware device clear the entire RAM (or just a given area of it) as soon as a power failure is detected (it can keep running for a few milliseconds after the PSU sends the power failure signal, which is still a few thousand clock cycles), but that would be just as easy to get around, so it’s not worth the effort.

Another option is to just not store the key in RAM, but in a CPU register or the cache or something. I’m not sure how long their retain their information, but presumably it’s not nearly as long; possibly short enough to prevent this attack.
Of course, keeping something in the cache or the registers all the time isn’t something most OSes will play nice with, so that will require some OS-level retooling, and encryption keys tend to be comparatively large (128 to 256 bits may not seem like a lot, but a CPU register is 32 or 64 bits wide nowadays, and there aren’t that many of them), so that’s only going to increase the performance hit of whole disk encryption (which isn’t as big as people expect, but big enough that you don’t want to increase it).

The easiest thing is just to keep people away from your precious RAMs.

As you may or may not have heard, a new version of TrueCrypt was released yesterday. As you may remember, it’s a cross-platform encryption type program, which has the ability to (among other things) create hidden containers, which is a simple but effective steganography.

Last time I mentioned TrueCrypt, I lamented the absense of full disk encryption, unlike a rivalling (non-free) product by the PGP Corporation, but apparently they added that in this version, complete with a pre-boot authentication prompt. Unfortunately, this seems to be Windows-only, which is, to put it plainly, retarded.
Still, if you use Windows, use this whole disk encryption (and remember to back up your data first, and store your backups in a safe location if you aren’t going to encrypt them). There’s no good reason not to.

The Linux version gets a GUI, though it apparently comes at the cost of the command line interface. While Ubuntu users everywhere will undoubtedly rejoice, I want my command line. I guess it makes the learning curve a bit less steep, even though it’s not actually more user-friendly for experienced users.
A useful change, though, is that you now no longer have to recompile TrueCrypt every time you update your kernel, though the fact that that’s finally fixed isn’t as good as the fact that that was an issue in the first place was bad.

And there’s also a Mac OS version now, which was a long time coming. It’s been announced as “real soon now!” for forever, so it’s about time they got around to it. They don’t get whole disk encryption either.

It’s becoming more and more obvious that TrueCrypt only cares about its Windows users, and that it only has the other versions for e-penis points. Being able to claim your software is cross-platform impresses certain types of people, even if the versions available for other platforms are severely crippled.
And of course, the license still sucks, which seriously limits its usefulness for anyone but home users.

So basically, if you’re a Windows user, use the whole disk encryption. If you’re a Linux user, OpenSSL actually does more than TrueCrypt if you don’t need hidden volumes (and even if you do, they’re not too hard to simulate using other tools). If you’re a Mac user, who cares?
If you’re a developer, you’re much, much better off avoiding TrueCrypt entirely and just finding your libraries elsewhere (such as with OpenSSL).

Still, projects like TrueCrypt are steps in the right direction; in a world where governments increasingly see privacy rights as a threat, it’s up to citizens to step in and take control of their own privacy themselves.
And to stop voting for idiots, obviously.

(No, not blogging about Supercalifragilistuesday. Go away.)

The point of these posts on cryptography is mainly to demonstrate that while cryptography may seem like a very arcane field that’s next to impossible for the layperson to get into, it’s actually reasonably straightforward. Still, there are some pitfalls one should watch out for.
A famous one of these involves block ciphers.

Suppose you want to encrypt your data, and you pick a block cipher to do it. Let’s say you pick AES, reasoning that since NIST thinks it’s good enough to encrypt top secret documents, it must be pretty good.
AES has a block size of 128 bits, but the data you want to encrypt is much larger than that. So what happens? You divide the data into 128-bit blocks and encrypt each one separately, right?

Well, yes. This is the way things were done for a long time.¹
The problem, though, is that identical 128-bit segments of plaintext also encrypt to identical segments of ciphertext. For certain datasets this isn’t a huge problem, but for many, it means that a lot of patterns in the plaintext are in fact preserved in the ciphertext, no matter how awesome your cipher is.
By way of illustration, take a look at this illustration I shamelessly stole from Wikipedia:

The picture on the left is our plaintext. The picture on the right is that data encrypted by dividing it into blocks and just using some block cipher on each of those blocks separately.
While the data can’t be extracted completely anymore, it’s still quite obviously Communist propaganda, and no less incriminating than the original.

Read the rest of this entry »

Now that we’ve seen an asymmetric cipher (sort of) and a symmetric stream cipher, maybe it’s time to look at a symmetric block cipher. Specifically, DES.
DES is perhaps the cannonical block cipher, but it’s also atypical in some ways. The main reason I picked it, though, is because it also has some history beyond “X thought it would be fun”, for people who aren’t interested in the messy details of the algorithm.

History

In the early ’70s, the American National Bureau of Standards (which is now NIST) decided the US government needed an encryption standard suitable for general use, and after consulting with the NSA, they decided to solicit suggestions from the general public.¹
The first request was issued in 1973, but no acceptable candidates were found. After the second request in 1974, though, IBM developed and submitted a cipher that was deemed acceptable: Horst Feistel’s² Lucifer algorithm.
After some additional prodding by the NSA, the proposed DES cipher was published and the public’s comments were requested.

Read the rest of this entry »

A lot of textbooks make a distinction between classical cryptography and modern cryptography that is, in my mind, completely artificial. To demonstrate, allow me to explain one particular algorithm that many would put in the category of “classical” cryptography (because it doesn’t involve computers), but that’s a stream cipher using a pseudo-random number generator in a way that one would normally consider to be entirely modern.

The Solitaire cipher was developed in early 1999 by Bruce Schneier for Neal Stephenson’s novel Cryptonomicon (which I still haven’t read). It generates a reproducible random number stream and uses them as keys in a regular addition cipher.
And it’s done with playing cards.

Read the rest of this entry »

Well, for a given value of useful. My Public Key is an application that displays your PGP public key in your Facebook profile, and lets you view which of your friends have public keys listed.
It’s a very simple application, but it’s quite useful for people who don’t want to deal with keyservers and the like.

PGP is, of course, a program for encrypting and decrypting things using asymmetric cryptography. It does more than that, but that’s the short of it. There are implementations available for every major OS.
(Actually, PGP is the original, non-free program. OpenPGP is the standard, which came later, and there are implementations of that available, of course. The most popular one is probably GnuPG, which is installed by default on many Linux systems.)

Using it is quite straightforward, once you’ve done it once.
The first thing you do is generate your own keypair. Using GnuPG (on the Lunix; may be different for other OSes), you type:

gpg --gen-key

And just follow instructions. If you aren’t sure about a question, just leave it on the default. It’s entirely possible your random number generator will run out of entropy while generating your key, especially for large keys. If this happens, just leave the window open and play a game for a bit.
Don’t forget to pick a solid passphrase, too. And if you pick a phrase from a famous book, at least substitute some of the words. I’m assuming it’ll let you use a single-word password as well, but why would you?

When that’s done, your keypair will automatically be added to your keychain. To see your public key, just type:

gpg --export -a

The -a is short for the --armor option, which outputs ASCII instead of binary (which is particularly useful, since binary output can fuck up your command prompt; if that happens, just type reset (though you’ll be typing blindly) to fix it).
The output from this command is what you paste into the My Public Key app.

To import a friend’s key, just save his key to a file and do the following:

cat FILENAME | gpg --import

Replacing “FILENAME” with the filename, of course.
You can also just use echo and paste the key directly into the prompt, of course, but it’s kind of long. The important bit is that the key is read from standard input.
If this is successful, you’ll get a message saying whose key you just imported.

To encrypt a message, you would do the following:

echo "Message" | gpg --encrypt -a -r "Recipient"

Where “Message” is your message (you can save your message to a file and use cat if you like; again, standard input), and “Recipient” is the message’s recipient. You can use just the name, or the name + e-mail, or whatever. It’s pretty lenient about that.
If you leave out a recipient (that is, use gpg --encrypt -a), you’ll be prompted for it.
Note the use of -a again. This isn’t necessary if you’re encrypting files (which you can also do), but most of time you’ll be encrypting messages to paste into e-mails and the like, so it’s useful to have a readable output.
An example:

xarn@xarn:~$ echo "Lol penis." | gpg --encrypt -a -r "Koen Crolla"
-----BEGIN PGP MESSAGE-----
Version: GnuPG v1.4.6 (GNU/Linux)

hQIOA6Lx7eVV8dSwEAgAo94SqA40e4+EYP5LPbpBdqZjq/yc14M5VQW34SN0foeQ
PPFAjKY2aZKaPSXSLPZON6Z5sTL7yIYppBdAbhFQJSEBJEqKE2tH/Gp9sGmB5Soq
pVMDoyg/tIZGXwf7neTJ71t2mTQVBi/z/jiWBa7Ys1QcY6qh3yUCBzKCrV7aLPOA
4U1kZDRNL3Vl8XDQzEWmZ3WYVxcn//ecceD3b122eFLtXGhLThVOFQhxh329qoe0
TkGvMK2NcITeud3tqR9d9E/7k5gOfeUQaGrantbqEm1jXbbSrBfcGib5u5LZed6G
5cz2OR/oztm/ZD/bhzwKpARiafmfLefVZHDjhza58ggArWr2z1rFiPNL1TH3tGnG
6ZbEBJZ47M9wODpta+3Ne2DDScKt/AvFe9mYOpaA6TlwpNi634YkwXydFu6OsC+w
JuqoOujizHaA74YEnLYinMPfvYBysH/nJxCbhcbGI+Ur/1ugrIbLxvTr9gDNbDDR
fFSmfDplsDWnk5kuBKbBwfqHSHr9aJsRCnm1tMwjp+qf77e2PkTqiXFuQCYo4FY/
Dq9J8Rx+q8yXkh1EAHGwCuMNQpgcPPGU8liDWnGHGJNVm4Z0ZhsNvi3gDtBRRqhX
lGZjGpLFqj4nHNkdsxLXsmaiiuWYTRGRJT+8PcVckR1pv89X37k1C08ruxAvPoTO
ZtJGAbgrwV+egZ+P/rBHANGj61LiTmLIehZSIJLARVAtmIVNGU2iygYbWII7KS6r
ZerQz3MRxQglKu3dtPPDPXSoCnsEabIFgw==
=EY8h
-----END PGP MESSAGE-----

If you’re using a friend’s key which you imported, it will probably give you a warning message about being unable to verify the key belongs to the person you think it belongs to. You can generally ignore that.

This output is what you send along to your friend, who can decrypt it doing:

cat FILENAME | gpg --decrypt

Where FILENAME is the name of the file with the message in it. Or, again, you could use echo. The program will automatically select the correct key from your private keychain, and you’ll be prompted for your passphrase to unlock it.

Obviously you’ll need the private key to decrypt the message, so you can’t test to make sure you encrypted a message you want to send to a friend correctly. If you want to test thing, you’ll need to test using your own keypair. It’s easy if you just pipe the encrypted message directly into the decryption command.

Anyway, all of this is rather involved, of course. There are graphical front-ends which make it a bit easier, and most major e-mail clients have at least one plug-in available to deal with the messy parts of PGP on its own (Thunderbird has Enigmail, for instance), so if you want to use it a lot and dislike the command line, look into those.
Since e-mail is slightly less private than writing your message on a postcard and giving it to a random stranger to mail (as I, and several other people, have mentioned before), I do encourage you to use it, though. Even Gmail’s totalitarian disregard for privacy becomes less pressing if you take control yourself.

At least until someone builds a quantum computer.

A federal judge in Vermont has ruled defendants cannot be forced to reveal their PGP passphrase:

U.S. Magistrate Judge Jerome Niedermeier ruled that a man charged with transporting child pornography on his laptop across the Canadian border has a Fifth Amendment right not to turn over the passphrase to prosecutors. The Fifth Amendment protects the right to avoid self-incrimination.

In this regard, the US is more sane than the UK.
This is good news, but not primarily from a constitutional angle.

The main problem with forcing people to turn over their encryption keys (any encryption keys, not just PGP passphrases) is that good encryption produces essentially random data, but on any computer, the empty space on the HD (for example) is going to contain pretty much random data as well (as deleting a file doesn’t actually zero out the bits, generally (ignoring tools like shred and the safe deletion option on Macs), but just flags the area it was stored in as being empty space), so the only thing a prosecutor would have to do if withholding encryption keys were against the law would be to claim (part of) the empty space is actually an encrypted file, cleverly hidden (which a lot of software is capable of doing). There would be no way of disproving it.
I use the empty space example, but of course this applies to steganography of any kind. If you look hard enough, you can find random data “hidden” anywhere, and that’s all you need to claim someone is hiding encryption keys and thus breaking the law. The UK’s RIPA can make criminals out of anyone.

Of course, what with the presumption of innocence it might take a mildly corrupt (or ignorant) judiciary to allow it, but let’s face it, those aren’t in short supply.

If this decision holds in appeal, this could be a very important precedent.

(Of course, since this involves an alleged pedophile, many people are getting entirely the wrong message out of this decision, and a lot of the knee-jerk retards are actually rooting for it to be overturned. Let’s hope the judge isn’t swayed by the public opinion, because the public is comprised of ignorant morons.)

I mentioned Diffie-Hellman key exchange in the context of asymmetric cryptography. I think it’s time to look at the algorithm a bit more closely.

As usual, Alice and Bob are trying to securely exchange some information, and they’re trying to agree on a key they can use for a symmetric algorithm. Perhaps they don’t know about asymmetric encryption, or they’re trying to exchange too much data for it to be feasible, or they need a stream cipher. Either way, they want to use symmetric encryption.
They have no secure way to exchange keys, because Eve is listening. After all, this is why they want to use the symmetric cipher as well. This is a very common situation on the internets.

Read the rest of this entry »

TrueCrypt is shinywin. Try it.
It even comes with plausible deniability, in case you live in one of the more totalitarian countries.

I’d very much like to use PGP’s Whole Disk Encryption, like Schneier the Bruce, but I don’t have 141 € to drop on it, handy though it would be.
And I’m leery of crypto software that both is closed source (despite Schneier’s endorsement) and has an enterprise edition.

Speaking of Schneier, I’m getting Applied Cryptography for Christmas. :3

Last time, I talked about the difference between symmetric and asymmetric ciphers, and said the symmetric ones were further divided into block and stream ciphers. I’ll say a little about what that means, without getting too deeply into it, since it’s not really that important.

Well, I say symmetric, but I can’t think of a conceptual reason asymmetric ciphers also couldn’t be divided into those two classes. In practice, though, I don’t know of a single asymmetric cipher that isn’t basically a block cipher.

Read the rest of this entry »

Another post in my series on cryptography for beginners. This time: the difference between symmetric and asymmetric encryption!

Basically, there are two main types of encryption: symmetric and asymmetric.
The most important difference between them is that symmetric encryption uses the same key for encrypting and decrypting, while asymmetric encryption uses different keys. Let’s see what this means.

Read the rest of this entry »

Re: the issue with Muffins! passwords travelling over the network in plaintext: this has been fixed.
The solution involves a nonce, client-side MD5 hashing, and lots of stolen Javascript.

And through the magic of graceful degradation, it will automatically fall back on the old system for people who disabled Javascript. It will also warn these people they should fucking turn on Javascript, because nonces aren’t much fun to implement and if they’re not going to take advantage of them they should go play some other game.

Anyway, the upshot of this is that passwords no longer travel over the network in plaintext (except during registration, which I’m very probably not going to do anything about), so if they get guessed, it’s seriously not my fault.

(Next up, the bruteforce thing. Which is pretty straight-forward: failed log-in attempts are logged, and before it logs you in it checks if there are fewer than, say, three failed attempts in the past fifteen minutes from your IP. If not, it won’t log you in. Shouldn’t bother legitimate users (if it didn’t check IPs malicious users could use it as a denial-of-service attack on users; I guess they sometimes still can through the magic of braindead ISPs), but it makes bruteforce and dictionary attacks completely unfeasible, even for people with very dynamic IPs.
It’ll have to wait until tomorrow, though.)

(Long post! You probably won’t think this is very interesting unless you play Muffins! and have a passing interest in cryptography and/or network security.)

When I started working on Muffins! over two years ago, I was a Japanese language student with no experience in programming or security whatsoever. I had heard about things like packet sniffing, though, and had a vague idea how the internets worked, but my ability to design a log-in system was limited by my ignorance of both PHP and of the possible vectors for attack.
Consequently, when Muffins! was just a blank page with a note saying “Imagine there’s a map here!”, the authentication mechanism sucked. Passwords were stored as unsalted MD5 hashes, and logging in sent your username and password in plaintext to the server, where the password was hashed and compared to the stored hash for your username. The server would then set a cookie with two fields: one for your user ID, and one for your password hash.
With every pageload, the server would look at your cookie and compare it to the contents of the database. If there was something wrong, it’d destroy your cookie and kick you to the log-in page, and that was that.

Read the rest of this entry »

Cryptography is becoming increasingly important in our daily lives, but there’s still a lot of confusion over even very basic cryptographic concepts in the media, so I thought I’d write a bit about some general cryptography-related topics for a bit.
This may be the first post in a series, or I may get tired of it after this one. We’ll see.

Hash functions have lots of uses beyond cryptography, making it particularly important for people to understand. The media generally seem fond of confusing them with encryption, which they aren’t.
A hash function is any function that takes data as input and converts this input into fixed-length string, or hash. They differ from encryption in that they are meant to be irreversible, while encryption is always meant to be reversed.

Read the rest of this entry »