1. Child process issues the signal SIGCHLD to the parent.
2. Parent receives SIGCHLD, issues the “wait()” system call.
3. Parent now receives the exit code of the child.
4. Parent reaps the child from the process table.

So, when the child process has finished execution of its task, it will report the exit code to the parent. At this point, the child process will remain in the process table until it receives further instruction from the parent. This wait is the defunct, or zombie state. So, in reality, child processes are in this state all the time. It’s just that normally, the parent process acts on it immediately. When the parent does not respond, then we have the zombie state of that child process.

You can check if there are any zombie processes on your system with the following command:

$ ps -eo pid,ppid,user,args,stat --sort stat

Any state of “Z” is a zombie state. So, the question becomes, how do you clean out the zombie, if it is causing issues with your system? Well, you have 3 options:

1. Physically wait around. Sometimes, the parent is busy, and just hasn’t acknowledged the child. When the parent is free, it could clean it up.
2. Send the “SIGCHLD” signal to the parent process. The above command will give you that output in the “PPID” column.
3. Fully kill the parent process. Any child processes will be orphaned, and picked up by INIT. INIT does frequent reaping of child processes and will reap any zombie states.

Quick post on installing ZFS as a kernel module, not FUSE, on Debian GNU/Linux. The documents already exist for getting this going, I’m just hoping to spread this to a larger audience, in case you are unaware that it exists.

First, the Lawrence Livermore National Laboratory has been working on porting the native Solaris ZFS source to the Linux kernel as a kernel module. So long as the project remains under contract by the Department of Defense in the United States, I’m confident there will be continuous updates. You can track the progress of that porting at http://zfsonlinux.org.

Now, download the SPL and ZFS sources. I’m running the latest RC, which seems to be quite stable:

$ mkdir ~/src/{spl,zfs}
$ cd ~/src/spl
$ wget http://github.com/downloads/zfsonlinux/spl/spl-0.6.0-rc8.tar.gz
$ cd ~/src/zfs
$ wget http://github.com/downloads/zfsonlinux/zfs/zfs-0.6.0-rc8.tar.gz

At this point, you will need to install the dependencies for SPL, then go ahead and compile and make the necessary .deb files:

$ sudo aptitude install build-essential gawk alien fakeroot linux-headers-$(uname -r)
$ cd ~/src/spl
$ tar -xf spl-0.6.0-rc8.tar.gz
$ cd spl-0.6.0-rc8
$ ./configure
$ make deb
$ sudo dpkg -i *.deb

Now do the same for ZFS:

$ sudo aptitude install zlib1g-dev uuid-dev libblkid-dev libselinux-dev parted lsscsi
$ cd ~/src/zfs
$ tar -xf zfs-0.6.0-rc8.tar.gz
$ cd zfs-0.6.0-rc8
$ ./configure
$ make deb
$ sudo dpkg -i *.deb

If you’re running Ubuntu, which I know most of you are, you can install the packages from the Launchpad PPA https://launchpad.net/~zfs-native.

A word of note: the manpages get installed to /share/man/. I found this troubling. You can modify your $MANPATH variable to include /share/man/man8/, or by creating symlinks, which is the approach I took:

# cd /usr/share/man/man8/
# ln -s /share/man/man8/zdb.8 zdb.8
# ln -s /share/man/man8/zfs.8 zfs.8
# ln -s /share/man/man8/zpool.8 zpool.8

Now, make your zpool, and start playing:

$ sudo zpool create test raidz sdd sde sdf sdg sdh sdi

It is stable enough to run a ZFS root filesystem on a GNU/Linux installation for your workstation as something to play around with. It is copy-on-write, supports compression, deduplication, file atomicity, off-disk caching, encryption, and much more. At this point, unfortunately, I’m convinced that ZFS as a Linux kernel module will become “stable” long before Btrfs will be stable in the mainline kernel. Either way, it doesn’t matter to me. Both are Free Software, and both provide the long needed features we’ve needed with today’s storage needs. Competition is healthy, and I love having choice. Right now, that choice might just be ZFS.

However, mounting an image file means knowing where the root filesystem begins, which means knowing how to offset the mount, so you can access your data correctly. I used the following:

First, I setup a loop back device, so I could gather information about its partition setup:

# losetup /dev/loop0 virt01.img
# fdisk -l /dev/loop0

Disk /dev/loop0: 21.5 GB, 21474836480 bytes
255 heads, 63 sectors/track, 2610 cylinders, total 41943040 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x0009bdb7

      Device Boot      Start         End      Blocks   Id  System
/dev/loop0p1        37943296    41940991     1998848   82  Linux swap / Solaris
/dev/loop0p2   *        2048    37943295    18970624   83  Linux

Partition table entries are not in disk order

In this case, the virtual machine filesystem is 21.5 GB in size, in reads and writes in 512 byte blocks. Further, it appears as though swap occupies the second partition, while the ext4 root filesystem occupies the first, and begins at sector 2048, or byte 2048*512=1048576.

So, now I just need to tear down the loop back device, and create it again with an offset of 1048576 bytes, at which point, I should be able to mount the device:

# losetup -d /dev/loop0
# losetup /dev/loop0 virt01.img -o 1048576
# mount /dev/loop0 /mnt
# ls /mnt
bin/   home/            lib32/       mnt/   run/      sys/  vmlinuz@
boot/  initrd.img@      lib64/       opt/   sbin/     tmp/  vmlinuz.old@
dev/   initrd.img.old@  lost+found/  proc/  selinux/  usr/
etc/   lib/             media/       root/  srv/      var/

At this point, I can edit my problematic /mnt/etc/fstab file to fix the troubled boot, and boot it up.

The hacker, David Kernell, had obtained access to Palin’s account by looking up biographical details such as her high school and birthdate and using Yahoo!’s account recovery for forgotten passwords.

Ever since then, I decided to change how I answer these “security questions” on websites. Knowing what I know about security and cryptography, I applied what I knew to these security questions. Here’s how I handle them now:

1. Generate a random string of characters, known as a “salt”. Something like “Ga0Au1Ieshea”.
2. Answer the question. If the question is “What is your mother’s maiden name?”, suppose the answer is “Smith”.
3. Apply MD5(salt+answer). In this case, it would be MD5(Ga0Au1IesheaSmith) which results in “28e03f4c2d90b8c1120bf541927976f1″.

So, when the site is asking you “What is your mother’s maiden name?”, the answer you would provide is “28e03f4c2d90b8c1120bf541927976f1″.

Obviously, there are a couple concerns that you should be aware of. First, the form field might have a character limit. Adjust accordingly. You could provide the first x-characters, based on the restriction. Personally, I’ve never seen this restriction, but I certainly won’t say that it hasn’t been implemented. Second, it’s critical that you generate a strong random salt, and that you keep the salt private. If the salt is known, or weak, then this whole thing falls apart, and you’re no better off than just providing the answer to the question.

But, if you do everything correct, then you have tightened down these lame “security questions”, and the attacker will not be any more successful than hacking your account password. And, by using a cryptographically secure hashing algorithm, the output will always be the same. Feel free to use SHA1 or some other hashing algorithm instead of MD5.

Setting it up was rather painless. I installed it using my operating system vendor’s packaging system, ran ZNC, and it asked my some questions out the gate. I accepted only defaults during this first run, but made sure that I loaded the web admin module, and bound to a port via SSL. After the installer finished, I logged into the web interface (securely), and began configuring ZNC the way I would like it.

The web interface is easy to use. It is loaded with plenty of options and features, and the layout is clean and intuitive. One thing that I learned quickly was how users are setup. Unlike Irssi, where you setup network definitions for the network you want to connect to, then assign nicknames based on those networks, with ZNC, a username IS a network. So, because I connect to multiple IRC servers, I need a username (and password) for each. So, setup a username, tell it the server you will be connecting to, set other options, such as buffer backlog, and save. Do this for each server you wish to connect to. Lastly, poke a hole in your firewall for your clients to connect through, and you’re set.

So far, I’ve been very pleased with ZNC. It’s a solid IRC bouncer. And it’s great to not need to setup an SSH tunnel to bind to Irssiproxy, so I can load local clients securely (this was a pain to setup on Android (which BTW, Yaaic is a SOLID Android client)). Suspect more posts about ZNC on this blog.

The Problem
You are running Irssi on a shared shell provider. Many people also have logins to the provider. You worry that the administrators of the service could see your usernames and passwords in your software configs.

The Solution
In all reality, just don’t put your login credentials in the configuration file, if the utility does not support encrypting them. Plain and simple. It sucks typing in your credentials every time you run the software, but it is the best solution. However, if you want the convenience of having your credentials automatically provided, yet you want them securely stored, then this may be the next best solution.

First, have the site administrator install the eCryptfs utilities:

% sudo aptitude install ecryptfs-utils

Now, create a private encrypted mount, mount it, move your Irssi config (or whatever) into the private directory, create a symlink, start the application, then unmount the encrypted mount:

% ecryptfs-setup-private
% ecryptfs-mount-private
% mkdir ~/Private/configs
% mv ~/.irssi/config ~/Private/configs/irssi-config
% ln -s ~/Private/config/irssi-config ~/.irssi/config
% irssi
% ecryptfs-umount-private

There are a few drawbacks to this setup, that you should be aware of. First, you won’t be able to “/reload” or “/save” unless you remount the encrypted ~/.Private filesystem. Second, anything else that Irssi is doing, will not be encrypted on disk, such as autologging channels and queries. You could put those in the encrypted filesystem as well, but then you would not be able to unmount it. It would need to remain mounted, which means the site administrators would still be able to see the login credentials. Third, the encrypted filesystem in ~/.Private/ could be removed or corrupted by the site administrators (at which point, I would stop using the service). Regardless, you would be without an Irssi config entirely. Best to keep a backup.

Until Irssi provides a way to allow encrypting the server or NickServ passwords with GnuPG, OpenSSL, or some other utility, this seems to be the best way to do it.

First, let’s look at the basic setup for getting an interface online with DHCP. The file we’ll be looking at this entire time is the /etc/network/interfaces file:

auto eth0
allow-hotplug eth0
iface eth0 inet dhcp

The first line tells the kernel to bring the “eth0″ interface up when the system boots. The second line tells the kernel to start the interface if a “hotplug” event is triggered. The third line defines the configuration of the “eth0″ interface. In this case, it should use IPv4, and should request an IP address from a DHCP server. A static configuration could look like this:

auto eth0
allow-hotplug eth0
iface eth0 inet static
    address 10.19.84.2
    network 10.19.84.0
    gateway 10.19.84.1
    netmask 255.255.255.0

The first two lines remain the same. In the third line, we have decided to use static addressing, rather than dynamic. Then, we followed through by configuring the interface. It’s important to note that the indentation is not required. I only indented it for my benefit.

What about bonding? Simple enough. Suppose you have 2 NICs, one on the motherboard, and other in a PCI slot, and you want to ensure high availability, should the PCI card die. Then you could do something like this:

auto eth0
iface eth0 inet manual
    post-up ifconfig $IFACE up
    pre-down ifconfig $IFACE down

auto eth1
iface eth1 inet manual
    post-up ifconfig $IFACE up
    pre-down ifconfig $IFACE down

auto bond0
iface bond0 inet static
    bond-slaves eth0 eth1
    # LACP configuration
    bond_mode 802.3ad
    bond_miimon 100
    bond_lcap_rate faste
    bond_xmit_hash_policy layer2+3
    address 10.19.84.2
    network 10.19.84.0
    gateway 10.19.84.1
    netmask 255.255.255.0

Technically, I don’t need to tell the kernel to bring up interfaces eth0 and eth1, if I tell the kernel to bring up bond0, and slave the eth0 and eth1 interfaces. But, this configuration illustrates some points. First, there are the pre-up, up, post-up, pre-down, down, and post-down commands that you can use in your network interfaces(5) file. Each does something to the interface at different times during the configuration. Also notice I’m using the $IFACE variable. There are others that exist, that allow you to create scripts for your interfaces. See http://www.debian.org/doc/manuals/debian-reference/ch05.en.html#_scripting_with_the_ifupdown_system for more information.

On the bonded interface, I’m putting in two slaves, then setting some bonding configuration that I want, such as using 802.3ad mode. Of course, the interface is static, so I provided the necessary information.

What if we wanted to add our bonded interface to a VLAN? Simple. Just append a dot “.” and the VLAN number you want the interface in. Like so:

auto bond0
iface bond0 inet manual
    bond-slaves eth0 eth1
    # LACP configuration
    bond_mode 802.3ad
    bond_miimon 100
    bond_lcap_rate faste
    bond_xmit_hash_policy layer2+3

auto bond0.42
iface bond0.42 inet static
    address 10.19.84.2
    network 10.19.84.0
    gateway 10.19.84.1
    netmask 255.255.255.0
    # necessary due to a bonding bug in vlan tools
    vlan-raw-device bond0

Bring the interface up, the verify that the kernel has assigned it to the right VLAN:

$ sudo cat /proc/net/vlan/config
VLAN Dev name    | VLAN ID
Name-Type: VLAN_NAME_TYPE_RAW_PLUS_VID_NO_PAD
bond0.42        | 42  | bond0

Notice that I specified “vlan-raw-device bond0″. This is due to a bonding bug in the VLAN tools, where merely specifying which VLAN the interface should be in by its name is not enough. You must also tell the kernel the bonded interface that the VLAN interface should be in.

How about bridged devices:

auto bond0
iface bond0 inet manual
    bond-slaves eth0 eth1
    # LACP configuration
    bond_mode 802.3ad
    bond_miimon 100
    bond_lcap_rate faste
    bond_xmit_hash_policy layer2+3

auto bond0.42
iface bond0.42 inet manual
    post-up ifconfig $IFACE up
    pre-down ifconfig $IFACE down
    # necessary due to a bonding bug in vlan tools
    vlan-raw-device bond0

auto br42
iface br42 inet static
    bridge_ports bond0.42
    address 10.19.84.1
    netmask 255.255.255.0
    network 10.19.84.0
    gateway 10.19.84.1

The only new thing here is the “bridge_ports” command. In this case, our bridged device is bridging our bond0.42 interface, which is in VLAN 42. Imagine having a KVM or Xen hypervisor that has a guest that needs to be in several VLANs. How would you setup all those bridges? Simple. Just create a VLAN interface for each VLAN, then create a bridge for each bonded interface in that VLAN.

Lastly, what about virtual IPs? I’ve heard that you can assign multiple IP addresses to a single NIC. How do you set that up? Simple. Just add a colon “:” the append a unique number. For example, say I have only one NIC, but wish to have 2 IP addresses, each in different networks:

auto eth0
iface eth0 inet static
    address 10.19.84.2
    netmask 255.255.255.0
    network 10.19.84.0
    gateway 10.19.84.1

auto eth0:1
iface eth0:1 inet static
    address 10.13.37.2
    netmask 255.255.255.0
    network 10.13.37.0

It’s important to note that you generally only need one default gateway to get out. Your kernel will route packets accordingly. If you must specify multiple gateways, then you must manually make edits to the kernel’s routing table, if everything isn’t setup correctly.

Of course, we could combine everything we learned here. See if you can make out what each interface is doing:

auto eth0
iface eth0 inet manual
    pre-up ifconfig $IFACE up
    post-down ifconfig $IFACE down

auto eth1
iface eth1 inet manual
    pre-up ifcanfig $IFACE up
    post-down ifconfig $IFACe down

auto bond0
iface bond0 inet manual
    bond-slaves eth0 eth1 eth2 eth3
    # LACP configuration
    bond_mode 802.3ad
    bond_miimon 100
    bond_lacp_rate faste
    bond_xmit_hash_policy layer2+3

auto bond0.42
iface bond0.42 inet static
    address 10.19.84.2
    netmask 255.255.255.0
    netwark 10.19.84.0
    gateway 10.19.84.1
    # necessary due to a bonding up in vlan tools
    vlan-raw-device bond0

auto bond0.42:1
iface bond0.42:1 inet manual
    pre-up ifconfig $IFACE up
    post-down ifconfig $IFACE down
    # necessary due to a bonding bug in vlan tools
    vlan-raw-device bond0

auto br42
iface br42 inet static
    bridge_ports bond0.42:1
    address 10.13.37.2
    netmask 255.255.255.0
    network 10.13.37.0

Lastly, MTU. There is a lot of misinformation out there about frame size. In my professional experience, setting the MTU to 9000 bytes does not result in improved performance. Not noticeably at least. But it does have an effect on the CPU. Setting a larger frame size can result in much lower CPU usage, both on the switch, and in your box. However, some protocols, such as UDP, might break with a 9k MTU. So, use appropriately. At any event, here is how I generally set my MTU when dealing with multiple interfaces:

auto eth0
iface eth0 inet manual
    pre-up ifconfig $IFACE up
    post-down ifconfig $IFACE down
    mtu 9000

auto eth1
iface eth1 inet manual
    pre-up ifcanfig $IFACE up
    post-down ifconfig $IFACe down
    mtu 9000

auto bond0
iface bond0 inet manual
    bond-slaves eth0 eth1
    # LACP configuration
    bond_mode 802.3ad
    bond_miimon 100
    bond_lacp_rate faste
    bond_xmit_hash_policy layer2+3
    mtu 9000

auto bond0.42
iface bond0.42 inet static
    address 10.19.84.2
    netmask 255.255.255.0
    network 10.19.84.0
    gateway 10.19.84.1
    mtu 9000
    # necessary due to a bug in vlan tools
    vlan-raw-device bond0

auto bond0.43
iface bond0.43 inet static
    address 10.13.37.2
    netmask 255.255.255.0
    network 10.13.37.0
    mtu 1500
    # necessary due to a bug in vlan tools
    vlan-raw-device bond0

Note that I set the MTU to 9000 on all interfaces except for bond0.43, which is 1500. This is perfectly acceptable. In all reality, setting the MTU to 1500 on bond0.43 is just capping what bond0 can really do. But, it is important to set the MTU on each interface, otherwise the frame size of 1500 bytes will get set, and you’ll end up chopping up your packets anyway. You must also set the MTU to 9000 on the switch ports as well, and any other server and interfaces that you want jumbo frames on.

I’ll be using bitmaps in this example, as I did in the previous, except I’ll use a different image. First, let’s create a “random filesystem”. Encrypted data should appear as nothing more than random data to the casual eye. This will be our target image for this exercise.

$ dd if=/dev/urandom of=target.bmp bs=1 count=480054
$ dd if=glider.bmp of=target.bmp bs=1 count=54 conv=notrunc

Here is what my target “encrypted filesystem” should look like (converting to GIF format for this post). Click to zoom:

Plaintext image	Target filesystem

Now let’s create a file full of binary zeros. This file will be the basis for our block device, and imitates an unused hard drive quite well. I have chosen ext2 over other filesystems, mostly because the size restriction with these files. Feel free to increase the file sizes, and use ext3, ext4, XFS, JFS, or whatever you want.

The file “400×400.bmp” is a white bitmap that is 400×400 pixels in size, rather than the 200×200 pixel “glider.bmp”. This is to accommodate for the larger filesystems used in this post, and make the illustrations more clear. For your convenience, download the 400×400.bmp and glider.bmp for this exercise.

In these commands, “$” means running the command as an unprivileged user, “#” means running as root.

$ dd if=/dev/zero of=plain-zero-ext2.bmp bs=1 count=480054
# losetup /dev/loop0 plain-zero-ext2.bmp
# mkfs.ext2 /dev/loop0
# mount /dev/loop0 /mnt
# cp glider.bmp /mnt
# umount /mnt
# losetup -d /dev/loop0
$ dd if=400x400.bmp of=plain-ext2.bmp bs=1 count=54 conv=notrunc

This should give us a reference image to see what a “plaintext” filesystem would look like with our file copied to it. Now, let’s setup two encrypted filesystems, one using ECB and the other using CBC, and we’ll compare the three files together:

First the ECB filesystem:

$ dd if=/dev/zero of=ecb-zero-ext2.bmp bs=1 count=480054
# losetup /dev/loop0 ecb-zero-ext2.bmp
# cryptsetup -c aes-ecb create ecb-disk /dev/loop0
# mkfs.ext2 /dev/mapper/ecb-disk
# mount /dev/mapper/ecb-disk /mnt
# cp glider.bmp /mnt
# umount /mnt
# dmsetup remove ecb-disk
# losetup -d /dev/loop0
$ dd if=400x400.bmp of=cbc-zero-ext2.bmp bs=1 count=54 conv=notrunc

Now the CBC filesystem:

$ dd if=/dev/zero of=cbc-zero-ext2.bmp bs=1 count=480054
# losetup /dev/loop0 cbc-zero-ext2.bmp
# cryptsetup create cbc-disk /dev/loop0
# mkfs.ext2 /dev/mapper/cbc-disk
# mount /dev/mapper/cbc-disk /mnt
# cp glider.bmp /mnt
# umount /mnt
# dmsetup remove cbc-disk
# losetup -d /dev/loop0
$ dd if=400x400.bmp of=ecb-zero-ext2.bmp bs=1 count=54 conv=notrunc

What do we have? Here are the results of my filesystems. Click to zoom:

Plaintext filesystem	ECB filesystem	CBC filesystem

How do they compare to our target filesystem? Well, not close really. Even when using CBC mode with AES, we can clearly see where the encrypted data resides, and where it doesn’t. Now, rather than filling our disk with zeros, let’s fill it with random data, and go through the same procedure as before:

First the “plaintext” filesystem:

$ dd if=/dev/urandom of=plain-urandom-ext2.bmp bs=1 count=480054
# losetup /dev/loop0 plain-urandom-ext2.bmp
# mkfs.ext2 /dev/loop0
# mount /dev/loop0 /mnt
# cp glider.bmp /mnt
# umount /mnt
# losetup -d /dev/loop0
$ dd if=400x400.bmp of=plain-urandom-ext2.bmp bs=1 count=54 conv=notrunc

Now the ECB filesystem:

$ dd if=/dev/urandom of=ecb-urandom-ext2.bmp bs=1 count=480054
# losetup /dev/loop0 ecb-urandom-ext2.bmp
# cryptsetup -c aes-ecb create ecb-disk /dev/loop0
# mkfs.ext2 /dev/mapper/ecb-disk
# mount /dev/mapper/ecb-disk /mnt
# cp glider.bmp /mnt
# umount /mnt
# dmsetup remove ecb-disk
# losetup -d /dev/loop0
$ dd if=400x400.bmp of=cbc-urandom-ext2.bmp bs=1 count=54 conv=notrunc

Finally, the CBC filesystem:

$ dd if=/dev/urandom of=cbc-urandom-ext2.bmp bs=1 count=480054
# losetup /dev/loop0 cbc-urandom-ext2.bmp
# cryptsetup create cbc-disk /dev/loop0
# mkfs.ext2 /dev/mapper/cbc-disk
# mount /dev/mapper/cbc-disk /mnt
# cp glider.bmp /mnt
# umount /mnt
# dmsetup remove cbc-disk
# losetup -d /dev/loop0
$ dd if=400x400.bmp of=ecb-urandom-ext2.bmp bs=1 count=54 conv=notrunc

Check our results. Click to zoom:

Plaintext filesystem	ECB filesystem	CBC filesystem

Much better! By filling the underlying disk with (pseudo)random data first, then encrypting the filesystem with AES using CBC, we have a hard time telling the difference between it and our target filesystem, which was our main goal.

So, please, for the love of security, before putting down an encrypted filesystem on your disk, make sure you fill it with random data FIRST! The Debian installer, and many others, does this by default. Let it run to completion, even if it takes a few hours.

$ openssl enc -aes-256-ecb -in ubuntu.bmp -out ubuntu-ecb.bmp
$ openssl enc -aes-256-cbc -in ubuntu.bmp -out ubuntu-cbc.bmp
$ dd if=ubuntu.bmp of=ubuntu-ecb.bmp bs=1 count=54 conv=notrunc
$ dd if=ubuntu.bmp of=ubuntu-cbc.bmp bs=1 count=54 conv=notrunc

Now, open all three files, ubuntu.bmp, ubuntu-ecb.bmp and ubuntu-cbc.bmpp, and see what you get. Here are my results with the password “chi0eeMieng7Ohe8ookeaxae6ieph1″:

Plaintext	ECB Encrypted	CBC Encrypted

Feel free to play with different passwords, and notice the colors change. Or use a different block cipher such as “bf-ecb”, “des-ecb”, or “rc2-ecb” with OpenSSL, and notice details change.

What’s going on here? Why can I clearly make out the image when encrypted with EBC? Well, EBC, or electronic codeblock, is a block cipher that operates on individual blocks at a time. ECB does not use an initialization vector to kickstart the encryption. So, each block is encrypted with the same algorithm. If any underlying block is the same as another, then the encrypted output is exactly the same. Thus, all “#000000″ hexadecimal colors in our image, for example, will have the same encrypted output, per block (thus, why you see stripes).

Compare this to CBC, or cipher-block chaining. An initialization vector must be used before the encryption can begin. Because I chose AES in 256-bit mode, AES is operating on 256-bit blocks at a time. The password in our case is our initialization vector. It is hashed to provide a 256-bit output, then AES encrypts the hash, plus the first block to provide a 512-bit output, 256-bits for the next vector, and 256-bits encrypted output. That vector is then used to encrypt the next 256-bits. This chaining algorithm continues to the end of the file. This ensures that every “#000000″ hexadecimal color will have a different output, thus causing the file to appear as random (I have an attacking algorithm to still leak information out of a CBC-encrypted file, but that will be for another post).

Hopefully, this simple illustration convinces you to use CBC, or at least to not use ECB, when encrypting data that might be public.

I’ve never known anyone personally that this has happened to, until now. But, I’ve been cryptographically signing my email since 2004. Every single one. I have almost 10,000 emails in my Sent folder, all of which are signed. Further, I think I’ve been very clear to my friends and family, that it is their responsibility to verify the signature. Should they receive an email claiming to come from me, they should doubt the authenticity of the mail if it is not signed.

Of course, this does not prove anything about future email. I may wish to stop signing my mail at anytime. But, all I need to do is cast reasonable doubt that I sent the mail. A back history of over 7 years and 10,000 cryptographically signed emails should cast enough reasonable doubt as to the message is question, should I be placed in that situation. Along with anyone being able to forge email headers, it’s all over. Unless you can clearly, logically, and rationally prove that I sent the mail, there is enough doubt surrounding it, that I remain innocent.

I know others don’t see email the same way I do, and treat their email experience differently, such as John. And in all reality, if setting up OpenPGP or S/MIME wasn’t such a major PITA, it might be more widely used. But for the time being, all I can do is continue to lead by example. For me, the 15 minutes it took for initial setup, and having to provide a passphrase every time I wish to send an email, is peanuts compared to threats, such as this. Of course, if the organization John worked for required S/MIME on their email (I’ve worked for one such organization that made this requirement), then it would be clear that the mail was a fake.

UPDATE: Turns out that this organization has a utility to send messages to anyone in the organization. It’s not email, but some custom, proprietary application. Further, it requires no authentication. Anyone can send messages to anyone pretending to be whoever they wish.

• I am, by definition, “the intended recipient”.
• All information in the email is mine to do with as I see fit and make such financial profit, political mileage, or good joke as it lends itself to. In particular, I may quote it where I please.
• I may take the contents as representing the views of your company.
• This disclaimer overrides any disclaimer or statement of confidentiality that may be included on your message.

Dear Jim Matheson, Rob Bishop, Jason Chaffetz, Orrin Hatch and Mike Lee:

If you vote in favor of supporting SOPA and PIPA passing, not only will you not get a vote from me, I’ll launch an online campaign to make sure I take as many people with me this November in doing the same (I’ll tell you right now Mr. Hatch, that Pete Ashdown already has my vote, but its not too late to withold the campaign). The ball is in your court.

Here’s how I set mine up using my GnuPG key. First, I created a ~/.mutt/passwords file. The file is in plain text. Before encrypting it, here are its contents:

set imap_pass="password"
set smtp_pass="password"

I then encrypt that file with the following command:

% gpg -r your.email@example.com -e ~/.mutt/passwords
% ls ~/.mutt/passwords*
/home/user/.mutt/passwords /home/user/.mutt/passwords.gpg
% shred ~/.mutt/passwords
% rm ~/.mutt/passwords

The last two commands are to ensure that the temporary file you created for encryption is securely wiped from the disk using the GNU Shred utility. Now, you should only have an encrypted binary data file that contains your passwords. All that is left is to configure Mutt to decrypt them when starting up. You can set that easily in your Muttrc:

source "gpg -d ~/.mutt/passwords.gpg |"

The string is just a standard string. Also, it’s important to have “|” at the end of the command, to pipe the output to Mutt, so it can be appropriately sourced.

At this point, you should be able to launch Mutt, be asked for the passphrase for your private GnuPG key, and it should log you in to your IMAP account. You should also be able to send mail as normal, logging automatically into your SMTP account. The only time you are asked for a password, is your GnuPG passphrase when starting Mutt. If your “gpg-agent” is already running, and you’ve configured GnuPG to use the agent and added your private key to it, then starting Mutt won’t ask you for your key passphrase, and will use the agent instead.

Other than temporarily creating the plain text file to encrypt, which stores your passwords, and which you promptly and securely shred later, your IMAP/SMTP passwords for your remote account are never on disk in plain text.

Happy encrypted hacking!

• I get A LOT of missed calls when people call my Google Voice number.
• I get A LOT of static on the line versus calling my cell directly (I honestly don’t understand why).
• Managing the “other” numbers for contacts is messy.
• Conference calls only support 4 people- you, and 3 other callers.
• Conference calls can only be initiated when people call your Voice number (you cannot invite people to the call).
• When using SMS on Android, the notifications are filled with the name presented twice- once for the Google Contact contact, and then again for the Voice Caller ID.
• Unless you’re using Android (or maybe other OSes), calling from your phone will not show the Google Voice number on their caller ID, unless you call your Voice number first, then follow the phone tree to dial the number you wish to call (a PITA).
• Some cell phone providers offer unlimited minutes when calling other cellular phones. Using Voice means calling a landline, which means using your minutes, regardless of who made the call.

I like the spam options of the service. It has come in handy. And I’ve recorded a few phone calls for logging reasons. However, I’ve found that using Google Voice in totality is becoming more of a pain than a benefit. Losing calls is especially annoying, definitely when you’re waiting for a job offer (ugh). I’ll continue to hand out the number to companies and people that I don’t care much about, but I’ve been handing my cell phone number out more and more lately, because Voice is just getting in the way.

Anyway, just had to get this off my chest (missing a call this morning was REALLY upsetting, and sparked the post).

|1|kFJT5z0x3ndyutgZ4E5pRk+ORBA=|hzXvdYUudo+qK9BGlFWtSAUXlXc=
|1|8wo1+FO0hkATPgQZoeNHeIlvAjw=|dt/a9jz9CnLKP72j+Jr8MKMjgEE=
|1|pvBQEKEGLnH0RCJr+8Dmqqnvlrs=|fJJvjyG/TmHFnuIX57nDThq/C4M=
|1|HKV4DzgDkajXoUHf9B82JBu7J10=|c/K+MdJvWaZeJFs/W7iqhqo0wvE=
|1|rtvQhRVnNanQZYkLUMbjoBGNhn0=|0U6a1LUQqLL6P1T2Wji3VWw69pw=
|1|0ziSYi4c+xBXGEBZcNN1LMhYUc4=|qRSN5GSPyQi+fmaVz2zNwkmKoy8=
|1|6nv6Vpk3AYgICHxJGVgVdsYRuq0=|fBNOIz1l3RW+N61jyDPunKX9n7E=
|1|+b4uA+Mq7RHRAFW21qv8aO3rIRs=|1eizMri01IxEKrXquBnwTYP61Ow=
|1|BkB0PZu2qtsLID/Ibe/D68gANQU=|qW6uAzcpecOOKNI4zEvngyfpGkI=
|1|n+QrRn7QXeAJ5hRe2M8v8IspihE=|EqUxXdSeIF1cl1fQjl5zILebkGY=
|1|BOKuKnWojy028tJf9Y671lws0d0=|SuBQJmJZp5JNVYG/rP9yb9ZhJcE=
|1|WACsxtodOiM89kf4rNPLgF1CXZ4=|UTccVeLDZJF3wlH8V05XJNlsOBw=
|1|o6FFoirXYblM7wBMdeJDYGMPI58=|5jJB7T7itY702ZHHByXtSpGk9SE=

The column fields are similar to that of the /etc/shadow file on GNU systems, except where the “$” is the column delimiter, “|” is in this case. If the string was “|1|o6FFoirXYblM7wBMdeJDYGMPI58=|5jJB7T7itY702ZHHByXtSpGk9SE=”, then the breakdown is as follows:

• |1- HASH_MAGIC. This tells the client that the host information has been salted and hashed with the SHA1 algorithm.
• |o6FFoirXYblM7wBMdeJDYGMPI58= This is the salt applied to the host- base 64 encoded 160-bit string.
• |5jJB7T7itY702ZHHByXtSpGk9SE= This is the base 64 encoded version of the hashed host

Now, if you want to get at the actual strings, not base 64 encoded, you could run the following command (I admit, not elegant, and could probably be better solved without nesting, and a single awk(1) statement, but I’ll get to that later):

% echo $(echo o6FFoirXYblM7wBMdeJDYGMPI58= | openssl base64 -d | xxd | cut -c 10-48) | sed 's/ //g'
a3a145a22ad761b94cef004c75e24360630f239f
% echo $(echo 5jJB7T7itY702ZHHByXtSpGk9SE= | openssl base64 -d | xxd | cut -c 10-48) | sed 's/ //g'
e63241ed3ee2b58ef4d991c70725ed4a91a4f521

There you have it. Very cool. Now, the only question is how to apply the salt to the hostname, to get to the hash? I’m working that out, but I wasn’t motivated enough to get to it. Of course, there’s no application to this, that I can tell, unless you want to brute force the known_hosts file.