OpenBSD 4.5

With a release date of May 1, OpenBSD 4.5 is probably going to be hitting the mirrors later today -- maybe late tonight.

Notable features and enhancements:
* Enhanced support for the sparc64 platform
* Support for more hardware monitoring sensors
* Lots of new or improved drivers for miscellaneous hardware
* Reliability and security improvements from 4.4, which was fraught with a couple of critical issues.

Thanks to Venture37, I've already got my hot little paws on 4.5; I didn't get to pre-order it. I plan on upgrading my main workstation to 4.5 over the weekend, but for the time being, this looks like a release worth upgrading to!

If you're not familiar with OpenBSD, it uses a "text-adventure" style installation script with a couple of very straightforward options. The only tricky part is partitioning and formatting the disk for installation. The Installation Guide can help you set up the disks.

Once installed, OpenBSD is "secure by default" without any remote services running other than the ones you specify. The only ones you can enable during installation are ntp and ssh (but they default to disabled).

OpenBSD's minimalist nature means that you're left with a powerful but svelte platform upon which to build to suit your needs: whether that's a workstation, firewall/router or an Apache/MySQL/PHP (OAMP) web-hosting environment. The installation media comes with apache, Xenocara (which includes Xorg), GCC, perl, Suhosin PHP and a host of other open-source components, most of which have been audited, patched and hardened by the OpenBSD dev team.

Related Posts:

Xorg.conf for OpenBSD on MacBook / Parallels

OpenBSD 4.4 / Apache / MySQL / PHP

Operating System Junkie

Encryption Technologies to Avoid

This is intended to be a supplementary information resource on cryptographic best practices. In this article I will cover some cryptographic algorithms with known flaws and some alternatives.

=== ToC =============

1. Introduction

2. Known insecure encryption technologies

3. Alternatives

4. Informative resources

====================

1. Introduction

Security is not the black box on your desktop or network. It it isn't a graphic you put on your website saying that the site is secure because you have a firewall. Security is the constant dialog between you and the other people in your organization on how to best secure the information which you have been entrusted with.

To that end I would like to bring up some technologies which we should avoid or migrate away from at our earliest opportunity.

2. Known insecure encryption technologies.

• DES - DES has been broken for quite a while.
• MD5
  
• SHA1

DES stands for Digital Encryption Standard, it was developed by IBM in 1972. Originally the team at IBM was said to have specified a 128 bit algorithm but was later asked by the NSA to reduce it to 64bit and later 56. This is refuted by government probes, then the insecurity was verified by cryptanalysis and later interviews with the people involved in the project and in de-classified documents.

MD5 is a hashing algorithm designed by Professor Ronald Rivest of MIT. There was research which theorized collisions in the algorithm in 1993, more collisions in 1996 and finally an algorithm was created to generate collisions in 2005 using a large cluster and in 2006 the algorithm was perfected only requiring a single computer.

The SHA cryptographic functions were written by the NSA in 1992. In 2005 flaws were found in the SHA-1 algorithm, although these flaws are yet to be exploited it was decided to move on to a different algorithm.

Things that were never a good idea to begin with:

• Character replacement ex. ROT13, Caesar Cipher
  
• XOR encryption against a trivial key
  
• base64 encoding (or any other encoding)

Character replacement, encoding and XOR are trivial to decrypt/decode. In the case of encoding or replacement, these are easily detected because the structure of the message itself isn't changed. XOR is computationally simple so brute forcing, frequency analysis and other methods can be used to decipher it. Using XOR against a very complex non-repeating one-time pad can offer quite a bit of security as long as strict protocol is followed in handling cleartext and the pad itself.

3. Alternatives
DES users should consider using AES, preferably one of the versions with larger key sizes 256 or 512. MD5 and SHA1 users should consider using the SHA-2 algorithm which are considered to be safe for now. There is an on-going contest to decide what algorithm to use for the new SHA-3 standard.

Many SSL certificates are signed using a MD5 algorithm. This creates the possibility of forging ssl certificates. In addition there was a bad patch to the OpenSSH package in Debian Linux in 2008 which made certificates generated by the affected server insecure. There is a firefox extension which will warn you if the certificate is vulnerable.

4. Informative resources

Wikipedia.org (Accessed April 26, 2009)

• http://en.wikipedia.org/wiki/Advanced_Encryption_Standard
• http://en.wikipedia.org/wiki/Data_Encryption_Standard
• http://en.wikipedia.org/wiki/MD5
• http://en.wikipedia.org/wiki/SHA1

Anka, Márton. "SSL Black List." (Accessed April 26, 2009)
http://www.codefromthe70s.org/sslblacklist.aspx

See also:

• GPG Part 1
• GPG Part 2
• Rubber Hose Cryptanalysis
• Steganography
• Encrypted filesystem images
• Cryptography fun with newLISP
  

May 1st: KC 2600 + Casa De Ax0n

Just a reminder for the Kansas City crew: We've heard some rumblings that the Independence 2600 meeting seems to be a wash. I know it's a bit of a haul for some people in this sprawling metroplex, but KC 2600 is alive and well at Oak Park Mall in Overland Park, KS.

Official start time is 5:00 PM but sometimes we run a little late. You can usually find us near Street Corner News in the food court. There's a large pillar (with power outlets!) so keep your eyes peeled for geeks with excessive amounts of gadgets.

The weather forecast for Friday looks pretty gloomy. Not sure what we're food-ing after the meeting, but attendees are invited to my place afterward for grub, suds, more discussion and geekery.

Risk Analysis: Swine Flu

Fact: More people will die of heart disease and traffic accidents today than have died by Swine Flu in the past week.

Fact: People will drive to and from work today, probably stuffing their faces with McGriddle sandwiches, breakfast burritos or grease-burgers while living in fear of getting sick by the media-hyped pandemic.

Fact: Some of those scared people will have a heart attack or get creamed by a drunk driver in the next few days.

Fact: Humans positively suck at risk analysis.

Reference: CDC - Leading Causes of Death in the US

Hackers in space

Intelligent life. It's a scarcity on our own planet, so we look beyond our atmosphere, hoping to find something, somewhere out there in the vastness of space that has more than two or three brain cells to rub together.

Have you ever seen the kinds of things we've sent into space for others to find and make sense of? I've often myself wondered what our own scientists, hackers, and problem-solvers would make of these messages.

In 1972 and 1973, Pioneer 10 and 11 were respectively sent off into space. Both were labeled with a gold-plated aluminum-alloy plaque engraved with information about humans, Earth and our solar system. Warning: If you zoom in on the image, it includes drawn nude human anatomy.

On November 16, 1974, Scientists at the Arecibo Observatory in Puerto Rico blasted 1,679 bits (not bytes!) into the sky at 1 bit per second, aiming their transmitter at Globular Cluster M13, some 25,000 light years away. How much information can be contained in 1,679 bits? What would you do with it? Would you even know where to begin? It's not divisible by 8, so it isn't using "bytes" in the traditional way you would expect. Remember, this is 1974 and the message is intended to be received and decoded by intelligent life.

0000001010101000000000000101000001010000000100100010001000100101100101010
1010101010100100100000000000000000000000000000000000001100000000000000000
0011010000000000000000000110100000000000000000010101000000000000000000111
1100000000000000000000000000000000110000111000110000110001000000000000011
0010000110100011000110000110101111101111101111101111100000000000000000000
0000001000000000000000001000000000000000000000000000010000000000000000011
1111000000000000011111000000000000000000000001100001100001110001100010000
0001000000000100001101000011000111001101011111011111011111011111000000000
0000000000000000010000001100000000010000000000011000000000000000100000110
0000000001111110000011000000111110000000000110000000000000100000000100000
0001000001000000110000000100000001100001100000010000000000110001000011000
0000000000001100110000000000000110001000011000000000110000110000001000000
0100000010000000010000010000000110000000010001000000001100000000100010000
0000010000000100000100000001000000010000000100000000000011000000000110000
0000110000000001000111010110000000000010000000100000000000000100000111110
0000000000010000101110100101101100000010011100100111111101110000111000001
1011100000000010100000111011001000000101000001111110010000001010000011000
0001000001101100000000000000000000000000000000000111000001000000000000001
1101010001010101010100111000000000101010100000000000000001010000000000000
0111110000000000000000111111111000000000000111000000011100000000011000000
0000011000000011010000000001011000001100110000000110011000010001010000010
1000100001000100100010010001000000001000101000100000000000010000100001000
0000000001000000000100000000000000100101000000000001111001111101001111000

The answer is interesting, and the binary stream above was crafted by some of 1974's most brilliant minds.

In 1977, two identical Voyager Golden Records were sent into space aboard Voyager 1 and 2. The record itself contained several recordings including an audio representation of captured brain waves. It was pressed in copper and plated with gold, but was technologically identical to vinyl phonograph records of the era, and I believe it would likely play on any regular phonograph. The record itself was contained in a cover (shown below, click to zoom) that contained similar information to the Pioneer Plaque.


Would an alien civilization understand what to do with any of these? What would Earth's own hackers and scientists do with information like this if we found it? Things like this fascinate me, and the 1970s were certainly an exciting time for technology and communications, which includes the space program.

The Apollo 13 mission itself (April 11-17, 1970) is proof of the kinds of things that hackers can do. While the mission was a failure, geniuses hard at work within NASA were busy finding ways to force equipment to do things that simply "couldn't be done" in order to bring the crew home safely. I don't know if it was actually spoken in real life, but in the movie Apollo 13, Flight Director Krantz tells off an engineer who is concerned about equipment being used unconventionally: "I don't care about what anything was DESIGNED to do, I care about what it CAN do." If that's not the hacker spirit, I don't know what is!

GPG Part 2: Key Revocation

Almost immediately after posting the last article on creating, distributing, and signing GPG keys, a few good questions started flowing in over Twitter. The questions were basically about "what if I lose my secret key?"

In short: the answer is "well, you're hosed." But GPG has some other features built-in to help you out. You just need to be prepared. That usually means having a revocation certificate ready to use. I'll cover that in a moment.

If you have lost your secret key (the secret keyring file itself) for any reason, for all intents and purposes you cannot ever decrypt anything that was encrypted with your public key ever again. The secret key is almost assuredly much, much more complex than the password or passphrase that you chose to protect it. As MC Frontalot would say: "you can't hide secrets from the future with math." so when petaflop computing power comes to the desktop, you may be able to crack it in a matter of months. Until then, your data is gone. This includes any new communication sent to you from others who have your public key.

Obviously, if people are sending you encrypted data and you have no way to decrypt it, that's A Bad Thing™.

If you have simply forgotten your passphrase, and it's a simple one that's 8 characters or less, alpha-numeric with upper/lowercase and no keyboard symbols, you may be able to brute-force the password that is protecting the key. That's way beyond the scope of this post.

Enter: Key Revocation
Revoking your public key is a quick way to advertise that the key should no longer be used. This can be for many reasons. The most obvious is if you feel your secret key has been compromised. In the event that your workstation got rootkitted, your backups were stolen, or you errenously left your secret key somewhere that it could have been accessed by someone else, you can't rely on the passphrase itself to maintain absolute secrecy of your data. Remember: passphrases can be cracked much easier than the unprotected secret key itself.

When to generate a revocation certificate:
I usually generate one soon after generating my keypair, which states "I have lost the secret key" or something of that nature. If you lose the secret key or forget the password to it, it's too late to generate the revocation certificate. You need both the secret key (and thus its password) to do this.

If you fear that the key has been compromised, you should generate one at that time which states the nature of the compromise.

To generate a revocation certificate, issue "gpg --gen-revoke [keyID]" and follow the prompts.

$ gpg --gen-revoke 19A473C7

sec  1024D/19A473C7 2009-04-25 Test! (This one is getting revoked!) 

Create a revocation certificate for this key? (y/N) y
Please select the reason for the revocation:
 0 = No reason specified
 1 = Key has been compromised
 2 = Key is superseded
 3 = Key is no longer used
 Q = Cancel
(Probably you want to select 1 here)
Your decision? 3
Enter an optional description; end it with an empty line:
> I'm revoking this on purpose
>
Reason for revocation: Key is no longer used
I'm revoking this on purpose
Is this okay? (y/N) y

You need a passphrase to unlock the secret key for
user: "Test! (This one is getting revoked!) "
1024-bit DSA key, ID 19A473C7, created 2009-04-25

ASCII armored output forced.
Revocation certificate created.

Please move it to a medium which you can hide away; if Mallory gets
access to this certificate he can use it to make your key unusable.
It is smart to print this certificate and store it away, just in case
your media become unreadable.  But have some caution:  The print system of
your machine might store the data and make it available to others!
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.4.9 (OpenBSD)
Comment: A revocation certificate should follow

iGUEIBECACUFAknzlDweHQNJJ20gcmV2b2tpbmcgdGhpcyBvbiBwdXJwb3NlAAoJ
EPfQr48ZpHPHbu8AoKRL0GJFb4MfgeaNYcjh9NUrMPQcAJ92z9KS9yA7TvNVZe2M
eMyWmaULZQ==
=NzxY
-----END PGP PUBLIC KEY BLOCK-----

This key, if it falls into the wrong hands, can be used by anyone to revoke your public key! Make sure to keep it safe. Back it up onto long-term storage that is reliable, or even print it out. It's relatively short, so it won't be too hard to type it in manually.

To use the revocation cert, simply import your public key (if it's not already in your keychain) and import the revocation cert. This will merge it with your public key and notify GPG that it's no longer valid. Then, if you have exported your public key to a keyserver, export it again as shown in part 1.

$ gpg --import testrev.txt 
gpg: key 19A473C7: "Test! (This one is getting revoked!) " revocation certificate imported
gpg: Total number processed: 1
gpg:    new key revocations: 1
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0  valid:   2  signed:   0  trust: 0-, 0q, 0n, 0m, 0f, 2u

You should also contact those who may send you communication and let them know to refresh your key from the keyserver. Until they do so, their installation of GPG (or other OpenPGP compliant software) will not know your public key has been revoked.

Of course, it's best to avoid the need to revoke certificates in the first place!

• Keep your secret key in a safe place, such as on your workstation, not a file-server or a shared host.
• Keep UNIX permissions at 600 (rw- --- ---) or otherwise make sure your account is the only one that can access the keyrings and/or any exported secret keys.
• Back up your keys to long-term media (CD-RW is usually fine) and keep it in a place that's safe from attackers and environmental harm (a cool, dark, dry place like a fire safe).
  
• For crying out loud, remember your passphrases without making them short and/or easy to guess. Example: use a favorite quote or passage written in l33t. Preferably a passage that few people know you like. Using your email signature line? Bad idea.

Personal backups for the win!

I might be preaching to the choir here a little bit, but perhaps you need a quick reminder to back up your personal workstations as well as your enterprise data.

After two and a half years of what I can only describe as abuse, my MacBook's hard drive gave up the ghost last night. This thing has traveled over 5,000 miles with me on my bicycle in my panniers, been slung hither to yon on buses, subways, planes and trains. Until recently, it was even my primary workstation at home.

It came with little surprise: my hard drive died mostly due to shock. Not one brute-force blow, by any means. It was just its time. As I sit here letting Time Machine restore my old stuff, I can say I'm thankful that I was at least somewhat diligent about backups. I probably only lost a few photographs that were on my hard drive for the past few days, and some of those got uploaded to Flickr anyway. The only lump in my throat was from having to explain to my wife why I'll need to lay out a Benjamin for a 320GB SATA drive this coming paycheck. It's amazing how much laptop storage you can get for $100. It's too bad I have to do this now, because it looks like the 500GB drives are going to be there soon.

You can read all kinds of reviews about Time Machine as a bare-metal restore tool as well as recovering from accidental data removal. I won't dwell on that here. All I can say is that when the time came, I wasn't sweating any bullets about my lost data. I can simply fork over some cash next week, and everything will be back the way I left it.

However you get your backups done, consider this a reminder to remain diligent. You never know when you'll need to restore, and the backup you made 8 months ago, while better than nothing, probably will leave you with a bit of regret.