Rosio Pavoris

After watching a few more videos by and about creationists on the YouTube, I realised that not only do I have more computing power at my fingertips than most scientists in history could ever have dreamed of and a greater-than-average ability to use said power, I also have a neat, educational, and easily implemented project to use it for.

Perhaps you remember the weasel program, but in case you don’t, here’s how my implementation worked:
The user enters a string consisting of characters from a certain pool (in our case, just capital letters and spaces). The program generates a random string of character from that pool, of the same length as the string the user entered. Every “generation”, the program takes one character in that string at random, and replaces it with another random character from the pool; it then compares the new (offspring) string and the old (parent) string to the target string the user entered, and discards the string that’s least like the target. The other one goes on to be the parent in the next generation.
This continues until the program’s own initially random string matches the user’s.

It’s a very simplistic example of Darwinian evolution, and while the point of it can be missed by people aiming to miss it, it demonstrates the power of evolution quite well.

Of course, casually running the program, seeing the number, and nodding absent-mindedly before forgetting all about it is no way to treat a nice algorithm, so I decided to drive the point home by modifying it a bit.

I decided to do a series of tests with successively longer strings (starting with one character, working up to fifty), and record how long it took on average to get from the random starting string to the target string (which is now just a series of As; I hope you realise why this doesn’t matter). The pool of characters was brought down from 27 possible characters to 10, to speed up execution times¹, and each test was then run five thousand times, to get rid of statistical artifacts.
The results were then plotted on a graph:

The X axis is the length of the string. The Y axis is the number of generations it took to get from a random starting string to the target. The blue line is the results my program found. The red line is how long you’d expect to take on average if you just rerolled the string entirely, which is how most creationists seem to think evolution works (the “tornado through a junkyard” fallacy).
For a string of length 50 this number is (10⁵⁰)/2, so forgive me for cutting it off the graph pretty early on.

There are some odd spikes the large sample size should have gotten rid of, which I blame on java.util.Random crapping out², but the trend is pretty clear all the same. (Edit: yeah, the problem was indeed that, and specifically how Java caches things in ways that breaks seeding random number generators. I fixed the issue as best I could and ran the program again; the results are here, and the spikes are indeed gone.)
It took about half an hour to run on my laptop, and the results are even clearer than I expected. Rather than the exponential growth in the number of generations needed so many creationists “predict”, there’s a linear one, which is much healthier.

You can debate how directly this applies to real-life evolution, since organisms tend to have genomes rather larger than fifty base pairs (though their pool of characters is only four, not ten), but they also tend to have more than one kid, and evolution is a trend over an entire population, not just one lineage, and they tend to have more than one mutation per generation (not to mention a bunch of other ways to stir things up, like chromosomal crossover), and sexual reproduction makes a whole new mess of everything.
The point, though, is to show the power of the Darwinian process; specifically, that it’s not just random chance, but something much, much more powerful.

Of course, people can show you all kinds of graphs and give you all kinds of programs to run, but it’s much more satisfying if you do it yourself and understand what you’re doing.
So I’m not going to post my code. Do it yourself. You have the algorithm (and if you think it sucked, improve on it (and post in the comments)), write your own code. It’s simple enough, it’s fun, and it’s quite gratifying.

¹ I also made a multi-threaded version of the program which works with a pool of fifty characters and goes up to string lengths of 500, and it’s been running on my reasonably pathetic cluster for the past two hours. I expect it to finish in a few weeks, unless the fans give out again and the entire cluster shuts down.

² ENTERPRISE TURKEY SOLUTIONS

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.

Nearly all cultures have historically used numeral systems in base-10 (that is, the decimal system) or some multiple thereof (Mayans used base-20, Babylonians base-60), supposedly because a human hand has ten fingers.¹ If that’s the case, the ancients suffered from a severe lack of imagination.
If you count on your fingers in base-1 (that is, the normal way), you can count to ten. However, there is a way you can get up to 1023 using just both of your hands.

How? Use binary, of course.

It’s actually really easy once you get used to it. If your finger is up, that bit is set. If it’s down, it’s not.
For example, the following are the numbers 0, 24, 17, and 31 (only one hand is shown, because it’s easier; 31 is the highest you can go on one hand, obviously).²

Counting on your fingers in binary is a skill well worth picking up, especially if you intend to use computers more often than never, but also just because.
You can even count with negative numbers, if you use two’s complement or similar.

It might be harder to expand this to also use your toes, but every toe you add doubles your range of numbers (you can count up to 2ⁿ - 1, where n is the number of digits; including 0, that means you can represent 2ⁿ numbers), so you probably wouldn’t need all of them. If you’re counting up to 1,048,575 (or 2,097,151 if you’re a guy, hurr), you’re better off grabbing a calculator anyway.

¹ The Native American Yuki tribe actually used a base-4 system, because they counted the spaces between the fingers of one hand, which is interesting. Some Nigerian tribes use a duodecimal system (that is, base-12), because they are mutants.
(Actually, base-12 exists in a lot of places, mostly in the Imperial system of measurement (twelve rods to a hogshead, and all), and in various forms in time-keeping (twelve zodiac signs, twelve hours on the clock).)

² These hand pictures are actually repurposed from a chart detailing some variety of sign language.

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 »

I didn’t get anything. ;____;
I did, however, skip class to help my mom set up the Christmas tree. It’s made of blinky lights and tastelessness.

And then it turned out classes were cancelled anyway because of some student demonstration (well, not officially cancelled, but the “we won’t punish you if you don’t show up” type of cancelled, which is the same thing in a hogeschool) against some proposed law that would fund higher education based on the number of credits students acquire each year.
It doesn’t take a genius to figure out this is a fucking retarded idea, but apparently only 800 1,500 students (from all over Flanders) showed up to protest. I’m guessing the weather had something to do with that. And maybe the fact that although it was announced well in advance and there were posters all over our building, nobody actually knew what they were supposed to be protesting.

And of course, since the twit proposing it (Frank Vandenbroucke) is a member of the SP.a (the Flemish socialist party, which I voted for), the socialist education union didn’t support the manifestation, because obviously party loyalty comes before common sense, and even fucking party principles.
Neither did the KUL student council, by the way, though the KHL student council, which is technically subservient to said council, did. Of course, the problem with the KHL is that very few people there care about politics, what with the brain damage and everything.

Anyway, it’s just a proposal at this point. With luck it’ll get shot down in January.

(Side note: annual government funding for the entire Flemish higher education system is about a thirtieth of the endowment of Harvard University alone, even with the 10% increase in funding over the past decade or so.)

Edit: Okay, the Standaard said 800 students, VRT Nieuws said 1,500. I’m more inclined to trust the VRT.
1,500 still isn’t an enormous number, given the fact that there are nearly a hundred thousand students in just the five Flemish universities, and presumably considerably more than that in the hogescholen, but it’s better, at least.

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 »

You can pretend to be teaching OO principles all you want, if you really were you’d be using a pure OO language to do it, and you’d realise just teaching OOP creates crippled programmers at best.
The way you wank on over design patterns reveals what you’re really doing; you aren’t teaching about programming. You aren’t even (for those who think higher education and vocational schooling should have anything to do with each other) training programmers. You’re training typists who happen to know enough programming idioms to wing it some of the time, as long as they’re never asked to create software more complicated than a typical accounting application, or to explain the reasoning behind said idioms.
You aren’t even giving them the tools to pick up languages besides Java and its bastard children, because they’ve never heard of most of the important concepts in computer science.

No wonder there are so many job openings for programmers even a decade after the dot-com bust: colleges and universities just aren’t producing them anymore.

(That is all.)

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 »

This took a while to finish. In part because I’m reading too many books at once, but also because it’s so depressing I had to put it down a few times.
Silent Spring, by Rachel Carson, published in 1962, is single-handedly responsible for revitalising the environmental movement around the world. I wanted to read it just for historical context, but the message is so powerful and important that it’s still a very important book.

The book is mainly concerned with indiscriminate pesticides (biocides) such as DDT and various chlorinated hydrocarbons. The book is, of course, famous for inspiring a movement that would very quickly get most of these banned, and it’s very obvious why.
She describes the various projects in the ’50s and ’60s that used these biocides, and how they have a tendency to not just affect the insects or plants targetted, but also, through a process of bioaccumulation in which the pesticides get stored in the bodies of animals in greater and greater doses as they travel up the food chain (that is, a single insect may contain X amount of DDT; a bird that eats twenty of those insects would contain 20X, and because it passes from the system only very slowly, it will remain there while that bird keeps eating insects, or while it is eaten itself), with the result that in the end, applications of these biocides end up killing enormous numbers of larger animals; several projects she described have been successful in wiping out all birds, squirrels, and fish in the (generally very large) treated areas, while not affecting the target insects very much at all, except by removing its natural predators, which, of course, is rather counterproductive.
And of course it’s not just dangerous to birds and the like. She documents a number of cases of human casualties; hardly surprising, given the toxicity of the products involving. Even if death doesn’t occur, permanent brain damage is far more common than it should be, in people handling or just being casually exposed to these supposedly safe products.
And even forgetting the immediate toxicity, there are long-term effects to be considered. Many of the products she talks about (including DDT) are powerful carcinogens. And speaking of long-term effects, insects, with their short generation times, are, of course, going to build up a resistance (and already have), so people will only keep using more and more dangerous pesticides.

She ends the book with alternative approaches to insect control, mostly through introducing natural predators of the insects involved. This has the advantage of being much cheaper and species-specific, and there’s no danger of developing resistance. Or, of course, poisoning your cat.

It’s all very, very depressing to read. If nothing else, it destroyed the myth that “if it’s bad for you, the government wouldn’t allow it!”. Fortunately, Carson’s book made a difference and got all of the products she discusses essentially banned; DDT was banned in the US in 1972, and in most of the rest of the world over the next few decades. Dieldrin, aldrin, endrin, chlordane, heptachlor, and its ilk soon followed.
Regulations on biocides and pest control became stricter and more sane, and most of the projects Carson describes would now be immediately dismissed as retardedly reckless.

Still, it’s alarming how many assholes are out to reverse the DDT ban. The meme that a DDT ban caused thousands/millions/billions of preventable deaths due to malaria is still out there, and for some inexplicable reason gaining support, even though it’s complete nonsense.
It’s important to remember that these people, regardless of their motivation (be it Kool-Aid-flavored ignorance or outright malice (well, greed; same thing)), are very directly working to kill your children.
This is only barely hyperbolic.

(If Rachel Carson and the things she cares about interest you, Deltoid is a very interesting blog that often deals with DDT nutjobs.)