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.

HAM IT UP

HIR INFORMATION REPORT

Introduction to Amateur Radio by Asmodian X.

This article is intended as an informational introduction on the capabilities of
amateur radio.

Disclaimer :To broadcast using amateur radio frequencies it will require at least a FCC No-Code Technician License.

===================================
Topics:
1 . Getting your license
2 . Common HAM radio Activities
3 . Informative resources on Amateur radio
===================================

1. Getting your license

Amateur licenses are inexpensive to get and they require only a basic understanding of radio waves, Allotted FCC Frequencies for amateur use, basic electronic theory and FCC rules and regulations in regards to Ham radio.

The best way to find out about official testing for a Technician License will be through either a local radio club, a local or regional ham radio equipment store or... the Internet.

The test is fairly simple, under 50 questions and it covers mostly opperating procedures, FCC regulations, basic electronics and basic radio theory. They throw in some minutia questions covering basic electronics, radio theory and ham spectrum information just to make things interesting.

Once you have passed the test, they will send your details to the FCC who will then log your information into their national database and assign you a sequential amateur call sign. You can even create a semi-custom call sign for an additional fee.
Once you are logged into the national database you may then transmit on the amateur radio frequencies.

Gotchas:
1. You may not use codes or encrypted transmissions.
2. Only licensed radio operators may use the ham radio bands. There are specific regarding what may be transmitted and by/from and to.
3. Every radio transmission you make must have your call sign associated with it.
4. If you can't say that on television, you cant say that on the radio. (no cursing)
5. If you get caught breaking the rules, you could loose your license, go to jail and or get fined.
6. Certain frequencies are restricted to certain types of communication, for instance certain bands are limited to Morse code only, while others you can use, voice, packet radio or TV.

2 . Common HAM radio Activities
Amateur radio operators exist to innovate and expand the field of radio electronics, promote international communication and good will and provide emergency communications when needed.

There are regional, national and international radio organizations who provide resources for management of the radio spectrum and emergency communication services. A common activity to the emergency communications mission is creating an emergency "jump pack" which contains all of the necessities to create a mobile communications system. Many people have modified their vehicles to be able to serve this purpose. Others have mobile towers and camping gear to create a command center of sorts when the need arrives. Common activities amongst these groups are training exercises where radio transmissions sources are traced to their source. This is called a fox hunt.

Other activities HAM operators do is to access gateway or relay resources. A gateway could be a packet radio node which could connect a ham operator to the Internet (albeit very slowly (9.6 kbps max). There are also telephone relays which allow a HAM operator to connect to the phone network to make an out going call.

A common activity of some HAMs is to use an Internet gateway to send GPS information automatically to a tracking website, like bright kite.

You may also transmit video over radio.

The ionosphere is a wonderful thing, radio can bounce off of the ionosphere and reach whole other continents. There are no restrictions on who you can talk to, provided both governments are not at a state of war or some other political barrier exists.

Now here is the tricky part, A HAM operator must allow the FCC to inspect their radio upon request. SO if one were to modify the radio to transmit or receive on channels which the operator is not licensed for they can do bad things to you. However in an emergency transmitting on a restricted (emergency services frequencies for instance) is a forgivable offense. So it seems that there is a kind of unofficial grey area in regards to radio modification, a kind of "if you do this there had better be a darn good reason" kind of thing.

3 . Informative resources on Amateur radio

• FCC - Amateur Radio Services - http://wireless.fcc.gov/services/index.htm?job=service_home&id=amateur
  
• ARRL - National membership association for Amateur Radio operators. - http://www.arrl.org/
• ARES - Amateur Radio Disaster Services - http://www.ares.org/
• RACES - Radio Amateur Civil Emergency Service - http://www.usraces.org/

Good Enough Computing

I've been on the "good enough" bandwagon for at least 5 years. It's been long possible to "just barely keep up" with tech and stay in a decent budget. I buy stuff that's about 3 years or more old (unless something awesome drops off the back of a truck...) and it usually lasts me 6 months to a year, or more. And my purchase price is always 5-25% of the original price. Get a barely 3 year old IBM desktop, once $1200 for $30? Even with upgrades and replacement parts it's a steal. It's also all modern tech, with SATA, PCIe, DDR2 RAM, etc. so upgrades are cheap and plentiful. "Good enough" is often "not new" too... and that will be a push during the recession that will force manuf.s to keep low prices.

Ref: /.

GPG Part 1: Key Management, Key Signing

Introduction
Although I'm a fan of TrueCrypt for full-disk encryption and folder encryption I still rely on Gnu Privacy Guard for some of my needs. GnuPG is an Open-Source encryption tool that adheres to the OpenPGP standard. That means that this should also work on most other CLI OpenPGP-compatible packages as well. It's lightweight, cross-platform, and there are front ends that make it relatively easy to use. It can output ASCII that's easy to send in an e-mail or copy/paste into a document.

Compiling and installing GnuPG is beyond the scope of this article. That said, it's usually easy to install without compiling it, since GnuPG is available in many package repositories for Linux, BSD and OS X. Try installing gnupg, gpg or GnuPG to see if it shows up in the repository. On OpenBSD, it's as simple as running "sudo pkg_add -r gnupg". The windows package is available through the GnuPG website (linked above).

Today, I'm going to focus only on the command-line key-management features. They work the same on all platforms.

Quick-Ref
Look, I know some of you guys probably don't need to see the whole screen-shot walk-through for this. If you just want to tinker around or you already have some experience with PGP-Like tools and just want to know how to use a keyserver, sign other peoples' keys and the like, here are a few helpful commands.

Generate a new key:       gpg --gen-key
Show secret keyring:      gpg --list-secret-keys
Show public keyring:      gpg --list-keys
Export a public key:      gpg --export -a --output [filename] [hex KeyID]
Export a secret key:      gpg --export-secret-keys -a --output [filename] [hex KeyID]
Get key from keyserver:   gpg --keyserver [server] --recv-keys [hex KeyID]
Send a key to keyserver:  gpg --keyserver [server] --send-keys [hex KeyID]
Inport a key from file:   gpg --import [filename]
Sign a key:               gpg --sign-key [hex KeyID]
Editing keys (advanced):  gpg --edit-key [hex KeyID]

Generating your first key
If you've never used GnuPG before, you will have to generate a key pair. This key pair includes a public key and a secret key. The public key can be shared, and is used by anyone who wishes to send you something encrypted. Using your password-protected secret key, you can decrypt what is sent to you. This is called asymmetric crypto because a different key is used for encryption and decryption.

To generate a new key pair, use gpg --gen-key and then follow the prompts.

-bash-3.2$ gpg --gen-key
gpg (GnuPG) 1.4.9; Copyright (C) 2008 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

gpg: directory `/home/axon/.gnupg' created
gpg: new configuration file `/home/axon/.gnupg/gpg.conf' created
gpg: WARNING: options in `/home/axon/.gnupg/gpg.conf' are not yet
active during this run
gpg: keyring `/home/axon/.gnupg/secring.gpg' created
gpg: keyring `/home/axon/.gnupg/pubring.gpg' created
Please select what kind of key you want:
   (1) DSA and Elgamal (default)
   (2) DSA (sign only)
   (5) RSA (sign only)
Your selection? 0
DSA keypair will have 1024 bits.
ELG-E keys may be between 1024 and 4096 bits long.
What keysize do you want? (2048) 2048
Requested keysize is 2048 bits
Please specify how long the key should be valid.
         0 = key does not expire
        = key expires in n days
      w = key expires in n weeks
      m = key expires in n months
      y = key expires in n years
Key is valid for? (0) 0
Key does not expire at all
Is this correct? (y/N) y

You need a user ID to identify your key; the software constructs the user ID
from the Real Name, Comment and Email Address in this form:
    "Heinrich Heine (Der Dichter) <heinrichh@duesseldorf.de>"

Real name: HiR Team
Email address: team@h-i-r.net
Comment: HiR Information Report - http://www.h-i-r.net 
You selected this USER-ID:
    "HiR Team (HiR Information Report - http://www.h-i-r.net) 
    <team@h-i-r.net>"

Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? O
You need a Passphrase to protect your secret key.
... Password Mumbo Jumbo ...

We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
+++++.+++++.++++++++++++++++++++++++++++++.++++++++++.++++++++++++++++++
++++++++++++.++++++++++..++++++++++++++++++++++++++++++..++++++++++++++
++++++>....+++++.......+++++....+++++.....+++++....+++++
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
++++++++++.++++++++++++++++++++.++++++++++++++++++++++++++++++++++++++++
+++++++++++++++++++++++++..++++++++++.......+++++..+++++++++++++++.+++++
.+++++.++++++++++++++++++++.+++++.+++++...........+++++...........+
+++++++++..+++++.................................+++++...............
........................................................................
..........+++++^^^
gpg: /home/axon/.gnupg/trustdb.gpg: trustdb created
gpg: key 1ACB0D01 marked as ultimately trusted
public and secret key created and signed.

gpg: checking the trustdb
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0  valid:   1  signed:   0  trust: 0-, 0q, 0n, 0m, 0f, 1u
pub   1024D/1ACB0D01 2009-03-12
      Key fingerprint = 86B3 38F5 7999 73C9 F4D3  CA65 90FC CDF3 1ACB 0D01
uid                  HiR Team (HiR Information Report - http://www.h-i-r.net)
         <team@h-i-r.net>
sub   2048g/5D6C5DEE 2009-03-12

The end result is a secret key and a public key which you can view with the --list-secret-keys and --list-keys options.

Showing your keyrings

As mentioned above, the commands for listing the contents of your keyrings is simple. You can also see that my personal key (ax0n@h-i-r.net) is already in my secret and public keyring.

-bash-3.2$ gpg --list-secret-keys
/home/axon/.gnupg/secring.gpg
-----------------------------
sec   1024D/1ACB0D01 2009-03-12
uid                  HiR Team (HiR Information Report - http://www.h-i-r.net)
 <team@h-i-r.net>
ssb   2048g/5D6C5DEE 2009-03-12

sec   1024D/7144C09F 2008-02-02
uid                  ax0n@h-i-r.net <ax0n@h-i-r.net>ssb   2048g/1622B636 2008-02-02

-bash-3.2$ gpg --list-keys
/home/axon/.gnupg/pubring.gpg
-----------------------------
pub   1024D/1ACB0D01 2009-03-12
uid                  HiR Team (HiR Information Report - http://www.h-i-r.net)
 <team@h-i-r.net>
sub   2048g/5D6C5DEE 2009-03-12

pub   1024D/7144C09F 2008-02-02
uid                  ax0n@h-i-r.net <ax0n@h-i-r.net>sub   2048g/1622B636 2008-02-02

Exporting your keys

You can export your key to an ascii file with the following command. Note, we use the hex key ID for our public key as shown above. By default, GPG exports in a binary format. the "-a" option enables "ASCII Armor" mode, which is similar to uuencode or base64 in that it takes up more characters but is more human-readable.

-bash-3.2$ gpg --export -a --output team.key 1ACB0D01
... we might as well look at the results, right? 
-bash-3.2$ cat team.key
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.4.9 (OpenBSD)

mQGiBEm4heMRBAC8erPKBw5U6FepsGMta+Q/ZcXeVDP63TO5sed0k4MFVErOjfif
6T5lbqNtgkgEfccNKwDjEM+tHCJ/VnKwQYAP2QOfgPc6pI4esKT2oKeOOKn0+dX6
u75r7LSl3B9HwcPN7PqTnUIm/wpeqPmSjtse9+zBJzi15ucwL6IcHnM4swCgkIAn
SGEOLR8FQJjNVdUnYZPVh9UD/RmyLqzI3pxpqzE4oxLQr3ShBDwXsEnnzL7PjUhG
ElazYWHZ2A+InA+bT8uAKwHVEDbLA5UQQfNoGxXibHdERJpvxjOejPOn3R7qInzW
ZgPXDL1EK4oKt7OG6WoaFCyOcEStBen+8U6HSCB5DHe9YOwLa7D/6WzMq9f5U7ea
SoAyA/wNgs/USugO/5cH2babJUOFCvdL8ifRUwjQG68OqjjP/mRSxLfuJGMVp+2B
uYuGxUPc9ntd/UAl7XNYNOqIw1RCZ5Nd80E3okA0HG3b4vNWLYe+GpYid29jb6NI
WBEUywq4rlwt4l7Lql+yB+6Z0vtqpwxQa3rOpWYit30sEUoPGbRJSGlSIFRlYW0g
KEhpUiBJbmZvcm1hdGlvbiBSZXBvcnQgLSBodHRwOi8vd3d3LmgtaS1yLm5ldCkg
PHRlYW1AaC1pLXIubmV0PohgBBMRAgAgBQJJuIXjAhsDBgsJCAcDAgQVAggDBBYC
AwECHgECF4AACgkQkPzN8xrLDQG46ACfQUBqjT/qAX+Q32k46ljmz75phA0AmwU0
uei4Zko6XY7ntJTvzbwtvaGbuQINBEm4heMQCACfpP8GVFZRQ2IPW+f79Wwa4t2J
3d/R94xFj5MUhRjZr7ADghwzFHKpN+U3WnQafdNZisGcJ6DuGokaysUAC2vhzDrX
8ZbTXKHNHuPtcAMIG3Hn7dSPqm1mMs0/ffJFv3EHcqZJuDANcgvlk0UUMTWvvPn5
zEldBytoG63B/WWse29VbdRVmx7Q06gh9+bQ6dAqtr8OXxCiuOBFqn4t614Q5xwp
FPbEdvIRTYg9MJ5yg6oh/VtXl1Tkm7Tne9SbgJDXg3l0EEpLMAM3J77Ldl4Cv/0K
K1cv9IfObaPpRcGldd4Uw7B2/fyDXsoCfc1Z6C+6nPRNpS1q/BgGQ+gQ6d+fAAMF
B/0f6LTgkV5BDYPUFJEaXzhmEiBNy+2olMWFi3wnPLH7oMSXF6ExQDr6AD9rkOKQ
I7brsimhl3nQd5MBrBzDAx1LrKrGpc/ACp6muYbFAp5H0REWCxD/86xIE0mJMnF2
mYik/BvPFaBXPvLJDrqrNInpedUEkzfUav3ZqYAuyC4J2eKG8wMe8qowRr13+Ao6
tGl44P8PmQ9IbqwBX1xtA8UHUIb/4Q4YMPNSVmKFU7QeIzlmyRS4CM/0RaebbIvg
sKMr5CpQRdadgn6RoWsidPi00AuYRuBBZs3JM/5CY88rdWUqDtdX68U4GI6l+zjK
zl9A0IcvENJ6HvSlrXmF4YK1iEkEGBECAAkFAkm4heMCGwwACgkQkPzN8xrLDQH4
jQCaA83HgdCwZ63O1K7ZadciWHgK18QAoIMRyQikPKy/i7OCa9rufJx0UNgMmQGi
BEnocAgRBADZ3ju47qDUqTRMY7wIr81aOqaXxfTw7/JdgKAV29szXkj1Hc8k+nfe
fiYZ1sHrVb4tqHDNaj1e33IAzen3kYAMSXKq1pyHP7o36Y66KsgKEgX7o/B2dB01
boVdctgKB0zTiFLB+UN6LK5Da26CitXSMUSEx8bo+VNrLAS/TAzY6wCgnsRdPhum
H3EFKtpv9nF1Xwk8ea8EAKYN5gVwMvYOvGSxfEbD+6IxHsD0FV43Wr/PFBMSIhCY
MxSfHBCiIexJU1d/MyJxbS5OYkdgDS31Qa8QWnWAY0tA7h3LdLYvH7EDFRaxqR3O
CWHHR8iC57860/PQkgqpwUzeqVDy5ELd4mbRaUdPLhVlijn25zEiao/LDaHI1TQx
A/4q5aK3YAS0J74K5a2P/73NnEHsYMPCusrj3PRKejDhg9HwS70RgHh1s414hcSm
7bbXYZHHKlw4lbxEJUBDypSm1146JU839wAMRVxmncWIaQlIgHhPAAIeg92kpq7E
DQe7QyD3cyuM5T//6IQsS67wteqyBjU2Yi4p725YHfQZ8rRDSGlSIFRlYW0gKEdl
bnVpbmUgSGlSIEtleSAtIDFBQ0IwRDAxIGlzIG5vdCB2YWxpZCkgPHRlYW1AaC1p
LXIubmV0PohmBBMRAgAmBQJJ6HAIAhsDBQkB4TOABgsJCAcDAgQVAggDBBYCAwEC
HgECF4AACgkQCxvsb9wupskDMgCeKHz04FiTfVJI2Gul3bZ1M/YM/nAAn2mjsDGH
4ovZRfM3pyZKi5UdiVz9iEYEEBECAAYFAknodWoACgkQr8ciJ3FEwJ/2gQCfS9hR
Jcj1UqjEJQXCwMbxm1PA/GMAoKhy08OaO8aS4bIYtJtSh1HdBRpouQINBEnocAgQ
CAD6+GN1AGooX1xYvrpn//Lm2o70R1ymPPrWy80yZmNlStQJN6AgEgXRjbnJE7tv
Z8SkKw7rCnJ5TwFo5n1CBzh/o6S1nU5j3zL4RXA0OyozfoETthQFmWb41a4QB9Wx
s4VWHR7Y355RJX/gIYUHhfZ/sRPk4se9srvMWAhgPBBO/JcqnT5Pexzvz1huVCsg
wXFYJIbvhCpiT2CmT3UXYuvprWzG2lds9+V1aPKBr0mYiXee+rOVvhyyevfHji0T
r0XdRFaBs30FhRxse6rMgF93plkD6R9+4mDKHZ8c2upqlxem89z4kWQySE7F1rG0
odjf0KlaZoOWHY5e/uIxCmLLAAMFCACZr7rZNqYS2K9Lo4Ulqo/0GxJaeUB0ZXpJ
SOLLYwTXBDFaVZZmpRuWFJQAGuApR55p0FVZfsFKxucdOBu2tV/Wxu1NADMuCJLM
Ic7edxyl/Bv5WXnFaOHHXiLAyI2fFTDV+JWwbLkKxxKcju180in0Wi3kbCP1eoor
nY0yda2QeQ0V9QiUeqp8L+CVCTYObo3OnS+Y6OJrs8M3IeAhV3Jr5DHt1U6J4BEk
Cc21MvTZ02hR3tG91MDM2r17moVrb2dYM15u+H562NfW4cL/V9EdmSLDBWoeiqO4
aCHS9lbQsfCC2cFgYDHkQKPaDrPKQo/tPDju1xMFgsyjLZCnu52siE8EGBECAA8F
AknocAgCGwwFCQHhM4AACgkQCxvsb9wupskKAQCfTdOleps2EZ2um9OglV8tvvmw
1VIAniKKY6smdU2WBDq0+EeQE25xF2ld
=Lt53
-----END PGP PUBLIC KEY BLOCK-----

You can upload the public key to your website and link to it. You can attach it in email, or you can just copy-and-paste it since it's ASCII Armored.

Using the --export-secret-keys option, you can similarly export your secret key. Make sure to use the -a option if you wish to have it in a text file format. AND BE SURE TO KEEP THIS KEY SAFE. If your secret key is compromised, the password protecting it is a relatively small obstacle compared to the key itself.

You can also export your public key to a keyserver. This is a public repository that lets people search for and request GPG keys for people they know. Many of these keyservers are synchronized with one another. Read about Synchronizing Key Servers here. Two SKS search links:

keys.keysigning.org

keys.nayr.net

I'll use keys.keysigning.org in this example, since it's an SKS. To send your key to the keyserver, use the keyserver name and the hex KeyID from gpg --list-keys:

-bash-3.2$ gpg --keyserver keys.keysigning.org --send-keys 1ACB0D01
gpg: sending key 1ACB0D01 to hkp server keys.keysigning.org

Things to keep in mind when you upload to a keyserver:

• You can upload anyone's public key to a keyserver, but you probably shouldn't without their permission. The exception is if you're going to sign someone else's key that's already on a keyserver. I'll cover that later.
• The email addresses, names, and any other information that's part of the key will be forever stored in plain-text and indexed. This could open the email address up to being spammed, or could reveal more personal information than you'd liked. I'm just saying be careful with what you put in your key. The metadata may become public.

Importing keys

You can import keys a few different ways. The most basic is to download the key or paste and save the key as a text or ascii file. Then you import the key with --import [filename]

You can import both public and secret keys this way. GPG will auto-detect what kind of key you import.

-bash-3.2$ gpg --import phoneboy.gpg
gpg: key 597F5D2A: public key "Dameon D. Welch-Abernathy " imported
gpg: Total number processed: 1
gpg:               imported: 1
gpg: 3 marginal(s) needed, 1 complete(s) needed, classic trust model
gpg: depth: 0  valid:   4  signed:   0  trust: 0-, 0q, 0n, 0m, 0f, 4u

Hopefully, Phoneboy does not mind me using his key as an example. He links to it from his blog (which is a good read if you're into telecom and/or security stuff)

You can also import the key from a keyserver, much like the export we described above. You do need to actually go to the keyserver to find the Hex KeyID though, or A856F98C in this example, which is Packet Storm Security's key.

-bash-3.2$ gpg --keyserver keys.nayr.net --recv-keys A856F98C
gpg: requesting key A856F98C from hkp server keys.nayr.net
gpg: key A856F98C: public key "Packet Storm Security " imported
gpg: 3 marginal(s) needed, 1 complete(s) needed, classic trust model
gpg: depth: 0  valid:   4  signed:   0  trust: 0-, 0q, 0n, 0m, 0f, 4u
gpg: Total number processed: 1
gpg:               imported: 1

The Web Of Trust

The beautiful thing about GnuPG (and other PGP-based solutions) is that you can create a "web of trust" with friends and colleagues using a keyserver. Basically, you have other GnuPG users you know sign your key. This means that they have certified that a public key belongs to you. With enough signatures on your public key, this makes it more difficult for an impostor to masquerade as you. The GNU Privacy Handbook's section on Building Your Web Of Trust explains it in more detail.

In the examples I've shown importing keys, you can see some information about depth, trust, signed, and the like. I won't get too deep into this, just enough to get you started because the above link really is a good read.

If someone sends you a public key, you can't 100% trust that it is theirs, especially if it's someone you do not know well or in person. It may belong to an imposter who has registered a convincing email address and has created their own key. Communication that you encrypt for the person you believe you're talking to could actually fall into unintended hands. It is for this reason that key signatures come in handy.

Fingerprints are cryptographic hashes that can be used to authenticate the key, but are short enough that one can scrawl them onto a napkin or the back of a business card. If you have verified the fingerprint of a person's key while you're there in person, you can verify that fingerprint against the key when you receive the key from them (or from a key server) later on. Once you verify that the key is authentic, you can "sign" it and then re-upload it to the keyserver. This means that you have personally vouched for the key's authenticity. If enough people vouch for one another's keys, the Web Of Trust is formed. Any person who may not know someone well enough to trust the key can see that several people vouch for the authenticity of the key. Perhaps one of the signers is even a mutual friend.

Key Signing
Signing is pretty easy:

You import a key from a keyserver (see example above)

You sign the key: gpg --sign-key [KeyID] (you'll be prompted for your passphrase)

You export the key back to the keyserver (see example above)

Key-Signing Parties
Throwing a Key-Signing party is a geeky way to vastly increase the size of your Web Of Trust and maybe interest others in encryption.

If you're going to try to get some people together to sign one another's keys (say, your local hackerspace, the 2600 participants, or your colleagues in the office), you should have a few things in place:

1. Every participant's public key should be uploaded to an agreed-upon keyserver or synchronizing keyserver network.
2. Every participant should have their hex KeyID, Name/Email and public key fingerprint written down or printed out. It's easier if participants print out several copies per page of paper (as shown in the photo) and cut them into strips to hand out to other participants.
3. All the participants should know one another and be able to verify each other's identity. You don't need to flash Drivers' Licenses and compare them to the real name on the key, but it wouldn't hurt.

My Keysigning Party Paper just repeats the following block of text as produced by gpg --fingerprint [keyID]:

pub   rsa3072 2021-07-18 [SC] [expires: 2031-07-16]
      29A2 4961 E62E DC91 AC9B  5FED 6421 2F30 5A35 5321
uid           [ultimate] Noah Axon (Main GMail) <focushacks@gmail.com>
uid           [ultimate] ax0n@h-i-r.net <ax0n@h-i-r.net>
sub   rsa3072 2021-07-18 [E] [expires: 2031-07-16]

Participants basically make their rounds, gathering key information from every other person in the group. Then, everyone imports everyone else's key from the keyserver and verifies that the fingerprints and e-mail addresses match the ones they were given in person. After that, sign all the keys, and export the keys back to the keyserver.

Yes, this is a manually intensive process.

 

Continue: GPG Part 2: Key Revocation

Lock Fail

Actually, there are locks built into the doors of this roadside telecom cabinet (and they are locked), but these two chintzy padlocks have been unlocked like this for the past few days. I'm not sure what the deal is here, but I chuckle every time I pass it.

If at first you don't succeed...

Drill it!

Surbo (from i-Hacked) brought in his tubular pick tool last week. We tried and tried to get into the lock. None of us at CCCKC had much luck.


Frogman, DJ_Goku and I went at it with the drill this evening. Oddly enough, I found some lock-drilling bits in our favorite dumpster several years ago. They came in handy tonight.


Frogman will probably be around with a more thorough article once he's assessed what all is really inside his mysterious phone-card vending machine.


Last minute reminder: KC 2600 at Oak Park Mall. Friday April 3rd. We'll probably be there around 5:00 PM.

The Conficker Is A LIE!

Well, it's April 1st, and the Internet (and its lies stupid pranks) are still alive and well. The hype of Conficker causing some kind of Internet-crashing, world-dominating clustercoitus have played out the way the real security experts (as opposed to so-called 'Computer Experts') had expected.

In case you missed it, the reason that experts weren't freaking out about Conficker are because some very smart virus researchers had already picked apart the Conficker.C variant and determined what it's going to do today. It's really nothing serious. Check out the F-Secure Conficker.C Q&A and SRI's more detailed Analysis of Conficker.C.

Of course, just because the world won't die by Conficker's hands doesn't mean it's okay to be lax on your security. You should still:

• Consider not using Windows :P
• Install a virus scanner and keep it up to date if you need Windows
• Always stay on top of your operating system's patches and updates

Also, sorry for the meme-tastic headlines lately. "The Cake Is A Lie" comes from the video game Portal. "All Your Base Are Belong To Us" was from an arcade game called Zero Wing.

Now and Then: Anatomy of a buffer overflow

Today, Kevin Poulsen posted "How A Buffer Overflow Works" on Threat Level. It includes a simplistic flash animation that kind of helps one grasp what's going on with a buffer overflow... although I'd hesitate to call it "kid-friendly".

In the hacking culture, exploiting buffer overflow vulnerabilities was known as "Smashing The Stack", as stack-based overflow exploits were (and likely still are) the most common buffer overflow vulnerability and among the easiest to exploit.

Kevin's article and the accompanying animation reminded me of a piece of work that is both antique (as far as computer history is concerned) and relevant. Phrack 49 was published in 1996, and it included an article by Elias Levy (under the handle of Aleph One) entitled "Smashing The Stack For Fun And Profit"

It's practically required reading for people dealing with application security; It's just as useful for developers as it is for penetration testers and security researchers. Seriously, go give it a read. It's a long one. All the while, keep in mind that it was released nearly 13 years ago. That even puts my own work into perspective. Phrack 49 was released just as I was myself trying to rally the writers who put together the very first bits of content that got HiR off the ground in its original eZine format.

Damn, I feel old now.