Tuesday, November 2, 2010

MAC-then-encrypt - also harmful, also hard to do in Solaris

Hello again!

Kenny Paterson's once again turning the theoretical into practical. This time he's pointed out that if one configures IPsec to MAC-then-encrypt (do packet authentication first, THEN encrypt the packet), one is open to cryptographic attack. Here's a citation for his ACM CCS paper.

The good news is that we cannot configure the IPsec SPD to perform MAC-then-encrypt at all. One could configure transport mode to just MAC, then have the packet transit a tunnel that just encrypts, but then you'll see warnings about the encryption-only tunnel configuration. This has been true for a LONG time (starting with S9, maybe even S8).

So basically, we don't make it easy for you to shoot yourself in the foot this way. You really have to try, and as I pointed out earlier, the encryption-only part will warn you.

Thursday, August 19, 2010

Thinking about the Birthday Problem on my Birthday, as it applies to my Birthday Present

My birthday is upon me.

My birthday present was an iPhone 4. Yeah, I got it early, but it was nice to have for my just-finished vacation drive. I noticed that when I'd reshuffle the 1763 songs on there, I'd more often than not hit a collision with a song I swear I'd heard during the previous shuffling. Time for some math...

The Birthday Problem (or Birthday Paradox, not because it's a real paradox, but because it's counterintuitive) shows that it only takes 23 people to be in the same room before the chances that two of them share a birthday are equivalent to a coin flip. The link above shows how one derives this. Basically, as you keep adding people, the probability of there NOT being a shared birthday decreases. That probability hits near-enough to 50% at 23 people.

I figured if I would have listened/remembered 30 songs from a previous shuffle. That's 2-3 hours of music, not a lot when you're driving all day. So if I accidentally shook my iPhone and reshuffled the songs, how many would I need to hear until I had a coinflip's chance of hearing a repeat from the previous 30?

Basically, the probability of NOT hearing a previously-heard song was (1763-30) / 1763. If that wasn't a repeat, the probability of another non-collision would be (1762 - 30) / 1762. Note that unlike the birthday problem, I'm decrementing the denominator as well. This is because I'm not going to hear the same song twice in a random shuffle.

I wrote a C program (because I hack way too much ON code) to compute things. Here it is:

#include <stdio.h>

int
main(int argc, char *argv[])
{
double p;
int i, listened, total, tries;

if (argc != 4) {
fprintf(stderr,
"usage: ipod [listened-songs] [total-songs] [tries]\n");
return (1);
}

p = 1.0;
listened = atoi(argv[1]);
total = atoi(argv[2]);
tries = atoi(argv[3]);

for (i = 0; i < tries; i++)
p *= (double)(total - listened - i) / (double)(total - i);

printf("P(NO repeat for %d on the second playthough): %lf%%\n", tries,
p * 100.0);
printf("P(Repeat for %d on the second playthough): %lf%%\n", tries,
(1 - p) * 100.0);
return (0);
}


Turns out, I need to hear 40 songs to have a coinflip's chance of hearing one of the previous 30 songs I heard before reshuffling the 1763 total songs.

mactavish(~/sources)[0]% ./a.out 30 1763 40
P(NO repeat for 40 on the second playthough): 49.942794%
P(Repeat for 40 on the second playthough): 50.057206%
mactavish(~/sources)[0]%

The above program should work for any sized iPod/iPhone collection, or any sized song-memory/patience. I really hope I got the math/derivation right. Any probability wizards in the audience can feel free to school me in the comments section.

Sunday, February 7, 2010

Do a "pkg image-update" with multiple zones!!!

Hello you half-dozen readers!

Recently I reinstalled my home server to OpenSolaris, build 130. I used zfs send and zfs recv to recover my relevant bits of data. I also constructed new zones, this time using ipkg zones.

Using ipkg zones takes a bit of acclimation. The biggest thing to note is that if you need a specific software package, you have to use pkg install in the zone you wish to have the software. For example, I have three zones:

  • The Global, internal-only, server zone - My global zone spends most of its time without a default route, serving NFSv4 and anything else I can think of only to my local LAN. If I need a new service, I temporarily add a global route, and pkg install away.

  • The Webserver zone - Just like it says. I needed Apache here, and had to pkg install Apache here.

  • The Router/NAT/IPsec-remote-access/Firewall zone - If you're going to put potential targets on the Internet, why put the global zone there? Especially with Crossbow VNICs and IP Instances!


So I got all of these zones, and the global zone isn't even net-attached most of the time? More interesting still, I need to upgrade all of these zones.

I posed this problem to pkg-discuss@opensolaris.org. Right now, pkg image-update won't upgrade the non-global zones. Worse still, I need to upgrade a zone that's also acting as my NAT and router. Luckily for me, Ed Pilatowicz gave me some good advice:

i do have one other workaround/suggestion you could try. after you do
an image-update of your global zone. before rebooting, use beadm to
mount the new image on /a. then you can try doing "pkg -R
/a/path_to_your_zone/root image-update" for each of your zones. this
will probably work as long as your always image-update'ing to the latest
bits in the repository (and no new images get pushed to the repository
in between all the image-update opreations.)

So I took Ed at his word.

Even if you have an ultra-paranoid global zone, you need to get it talking to an IPS repository. Either temporarily add an off-link route like I do, or have a local repository handy. Proceed and pkg image-update your global zone. Make sure you use --be-name to pick a BE name that you'll remember.

Next, you literally beadm mount new-be-name /mnt and for each zone root directory (while still able to reach the repository from your global zone) do pkg -R zone-root-path image-update. For my own example, I did:

  • pkg image-update --be-name 132

  • beadm mount 132 /mnt

  • pkg -R /mnt/export/home/webserver/root image-update

  • pkg -R /mnt/export/home/router/root image-update

  • beadm umount 132

  • reboot


This worked quite well for me moving up from 130 to 132. Just make sure your global zone can reach the repository, and you should be golden.

Wednesday, January 27, 2010

I, for one, welcome our new database-selling overlords.

In all honesty, I'm glad this regulatory dance is over. We've all been having a little itch in our brains about this. Even if any of us have had real work to do, we've been at least a little distracted by by this whole acquisition uncertainty.

Well, we're finally part of Oracle now, and I think that's pretty cool. Larry E. wants to butt heads with IBM and HP directly, and quite honestly, we at Sun have been doing that on-and-off for at least my not-quite-14-years here. Now that this uncertainty has been removed, we can at least narrow the uncertainty to any internal-to-Oracle decisions, which given certain statements both in the past and yesterday seem pretty encouraging, at least from my engineering perspective.

Jonathan said we should light a candle for Sun. As a prank gift for my 40th birthday, I got a 40-ounce bottle of Olde English. I think instead I will pour that 40 for Sun.

Wednesday, January 20, 2010

Wanna help your Girl Scouts? Not unless you have Windows. :-P

My wife is the "cookie mom" for our twin girls who are in Daisy Scouts. She was very surprised when she logged in to the regional Girl Scouts cookie site (URL withheld in case any rabid fanboys do something stupid), and discovered that apparently, she needs to use Windows and Internet Explorer.

Their user documentation says: "We do not provide Mac support," and "Use any (non-Mac) computer at home or at work or at the local library." Does this mean they support OpenSolaris, Linux, or *BSD? Naaah, didn't think so.

We're a no-Windows household. We have three Macs, one work-issued OpenSolaris laptop, and a homebuilt OpenSolaris server. Especially in this age of people understanding vendor lock-in as a Bad Idea (TM), I'm shocked and appalled.

I'm going to forward this to a few Mac sites, and maybe slashdot. I'm sure nothing's going to change, but at least this should be discussed a bit, no?

Tuesday, January 5, 2010

IKEv2 project page updated

The IKEv2 project page on opensolaris.org now has links to both an early-revision design document, and a webrev pointer.