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.
With a release date of May 1, OpenBSD 4.5 is probably going to be hitting the mirrors later today -- maybe late tonight.
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 =============
2. Known insecure encryption technologies
4. Informative resources
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 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)
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)
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.
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
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.
The answer is interesting, and the binary stream above was crafted by some of 1974's most brilliant minds.0000001010101000000000000101000001010000000100100010001000100101100101010
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!
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 19A473C7This 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.
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
-----END PGP PUBLIC KEY BLOCK-----
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.txtYou 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.
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
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.
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.
Introduction to Amateur Radio by Asmodian X.
This article is intended as an informational introduction on the capabilities of
Disclaimer :To broadcast using amateur radio frequencies it will require at least a FCC No-Code Technician License.
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.
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/
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.
Labels: tech economy cheap
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.
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) <firstname.lastname@example.org>" Real name: HiR Team Email address: email@example.com 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) <firstname.lastname@example.org>" 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) > email@example.com 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.
-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) <firstname.lastname@example.org> ssb 2048g/5D6C5DEE 2009-03-12
sec 1024D/7144C09F 2008-02-02 uid email@example.com< > firstname.lastname@example.org -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) <email@example.com> sub 2048g/5D6C5DEE 2009-03-12 ssb 2048g/1622B636 2008-02-02 pub 1024D/7144C09F 2008-02-02 uid firstname.lastname@example.org< > email@example.com sub 2048g/1622B636 2008-02-02
-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.
-bash-3.2$ gpg --keyserver keys.keysigning.org --send-keys 1ACB0D01 gpg: sending key 1ACB0D01 to hkp server keys.keysigning.orgThings 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.
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-AbernathyHopefully, 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)
" importedgpg: 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
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
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.
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)
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:
- Every participant's public key should be uploaded to an agreed-upon keyserver or synchronizing keyserver network.
- 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.
- 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.
pub 1024D/7144C09F 2008-02-02 Key fingerprint = CA25 8D31 72A9 1105 F7E6 7EFB AFC7 2227 7144 C09F uid Noah Axon (Main GMail) <firstname.lastname@example.org> uid email@example.com <firstname.lastname@example.org>
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.
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.
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.
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
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.