Archive for December, 2005

gbde and memory disks

Friday, December 30th, 2005

So, as mentioned earlier, I played around with using gbde on memory disks in FreeBSD 6. The following are a few notes. At the very end, I also talk about encrypting the disk partitions used for swap and mounted as “/tmp”.

-

Let’s begin with encrypted memory disks.

First, if not already enabled, turn on gbde in the kernel by adding

	options         GEOM_BDE                #FreeBSD disk encryption

to the kernel configuration (for example, “DKript_Lap1″ as discusssed in a previous post). Then, rebuild the kernel.

  • make kernel KERNCONF=DKript_Lap1

(Don’t forget to build and/or copy any kernel modules outside of the kernel build tree to “/boot/kernel” before rebooting – for example, copying “bcmwl5_sys.ko” to “/boot/kernel”, as discussed in a previous post).

Ok, we are creating a file-backed memory disk, so let’s create a file for the memory disk. Here, we create a ~1GB regular file named “md1″ in the directory “/usr/home/emd”.

  • dd if=/dev/random of=/usr/home/emd/md1 bs=1K count=1M

Configure the file-backed memory disk.

  • mdconfig -a -t vnode -f /usr/home/emd/md1 -u 1

Next, label the new memory disk.

  • bsdlabel -w /dev/md1

We are all set to initialize encryption for the memory disk, and this will prompt for a passphrase that will be used as part of deriving encryption keys. (Note: I used the directory “/etc/gbde” for the gbde lock files.)

  • gbde init /dev/md1c -L /etc/gbde/md1c.lock

Ok, attach to the encrypted memory disk. (This prompts for the passphrase entered previously.)

  • gbde attach md1c -l /etc/gbde/md1c.lock

Create a filesystem on it.

  • newfs /dev/md1c.bde

With all that done, mount it.

  • mount /dev/md1c.bde /usr/home/emd/enc1

That is about it. In the future, all we have to do to mount this encrypted memory disk after a reboot is configure the memory disk, attach to it with gbde, and then mount it.

  • mdconfig -a -t vnode -f /usr/home/emd/md1 -u 1
  • gbde attach md1c -l /etc/gbde/md1c.lock
  • mount /dev/md1c.bde /usr/home/emd/enc1

Umounting is simply a matter of…

  • umount /usr/home/emd/enc1
  • gbde detach md1c

(An ugly script for mounting/unmounting the encrypted memory disk setup as described above can be found here.)

So, now we have an encrypted memory disk for storing up to ~1GB of data.

-

Let’s encrypt the disk partition used for swap, which is quite easy on FreeBSD 6. All that has to be done is append “.bde” to the device entries used for swap in “/etc/fstab”. (For example, I changed the swap entry in my “/etc/fstab” from “/dev/ad0s1b none swap sw 0 0″ to “/dev/ad01sb.bde none swap sw 0 0″.) The “/etc/rc.d/encswap” script will then take care of the rest upon boot. (I did make one small modification to “/etc/rc.d/encswap”, which is not absolutely necessary – I changed “md5″ to “sha256″ for hashing the data gathered from “/dev/random”.)

Ok, let’s encrypt the disk partition mounted as “/tmp”. First, I quickly hacked the “/etc/rc.d/gbde” script to encrypt the partition mounted as “/tmp” with a random key. (The hacked “/etc/rc.d/gbde” script can be found here. It requires the specific mount point to be “/tmp”.) After that, add “gbde_devices=”AUTO”" to “/etc/rc.conf” to invoke automatic initialization of gbde devices during boot, and, as with swap, append “.bde” to the device entry in “/etc/fstab” for the disk partition mounted as “/tmp”. (For example, I changed “/dev/ad0s1e /tmp ufs rw 2 2″ to “/dev/ad0s1e.bde /tmp ufs rw 2 2″ in my “/etc/fstab”.) The “/etc/rc.d/gbde” script will then take care of the rest upon boot. (Of course, if things like “/var” are not on an encrypted partition, there may be little temporary files lying around, like in “/var/tmp”. Perhaps symlinking such things to “/tmp” or other points on encrypted partitions would help, like “ln -s /tmp /var/tmp” for “/var/tmp”. Unfortunately, temporary files pop up all over the place.)

As for creating encrypt disk partitions, the gbde commands used on our memory disk are the same type of commands as those you would use on a disk partition. Additionally, for automatic mounting during boot, add “gbde_devices=”AUTO”" to “/etc/rc.conf”, as we did in our “/tmp” discussion, and append “.bde” to the device entries in “/etc/fstab” for the relevant disk partitions, such as the “/etc/fstab” entry changes we made for disk partitions used for swap and and mounted as “/tmp”. Of course, if the partition has data on it that you want to keep, back the data up before setting up disk encryption for the partition and then copy the data back over once disk encryption is properly configured for the partition. And, automatically mount encrypted partitions during boot could result in being prompted for passwords during the boot process.

-

Lengthy comment and nice list

Monday, December 26th, 2005

Before fun with the family for this holiday weekend, I wrote a somewhat lengthy blob of a comment for this post on the Spire Security Viewpoint blog, so I wanted to call attention to it. (Side note: These stream of thought jumbles are becoming commonplace for me. I try to edit them a bit before publishing, but I really need to work on this more; however, don’t expect doing so to be on my list of new year’s resolutions. ;) )

“My assessment of the risk suggests that the imminent threat and corresponding risk from successful cryptanalysis is much lower than with bughunting”

In general, I agree with this statement, but probably in a different way than implied by the post. There seems to be some implication that these types of research should not be published (even conducted?) and that seems naive. How can one attempt to build things without first understanding how to break things? And, how can one fix something they do not know is broken in the first place?

Anyway, the comment flies off in a different direction from there. Searching for related posts on here, it looks like we have posted on an entry in that blog before. There is also this previous post, the mailing list mentioned in here, and a slight reference to fixes and formal third party audits in here.

(On a very slightly related tangent, I fixed our comment settings after breaking them.)

Speaking of security and crypto research, I just received the latest IACR newsletter (no active link to it as of this writing, but I assume it will be placed here). I find the “Top Downloads from the Cryptology ePrint Archive” section to be a great addition to recent newletters.

Top downloads from the Cryptology ePrint Archive

The top six downloads from the ePrint archive for the period May
18th through November 22, 2005. The first two have been noted in
this newsletter before and still remain heavily accessed.

This newletter’s list was composed of the following six papers.

Risky security and crypto research, each and every one of them.

Electronics Recycling

Friday, December 23rd, 2005

So, I happened across the “New York City Electronics Recycling” events, the next of which occurs on…

Sunday, January, 8th, 2006
9a.m. to 5 p.m.
Union Square Park – North Plaza

I must say I was a little disappointed. I was expecting a bit more creativity in the following.

Think your old monitor is too heavy to schlep? Check out our gallery of champion recyclers who have transported their e-waste in creative ways.

Now, look at this photo.

Pile of junked electronics

And, read about last year.

Last year the recycling collection at PS 321 captured about 23,000 pounds of unwanted equipment.

Besides being able to dump some archaic paperweights, this looks and reads like a good place to score some free parts! So, clean out those closets and check it out.

(Some would say I do not need anymore “junk” lying around. Fine, just give me those used hard drives. ;) )

And, with this fluffy post, I bid everyone a… Happy Holidays!

Prediction or hindsight

Thursday, December 22nd, 2005

Thomas Ptacek made a few security predictions about 2006. I am not qualified to make such predictions, but hindsight lets me comment on one of his predictions.

5. Side-Channel and Timing Attacks Go Mainstream

The prediction I am least qualified to make, but most interested in. Remote cache timing, local cache timing, HTT, virtualization, distributed side-channel analysis. To paraphrase a friend who knows the space better than me: “The 10 people in the world who actually spent any time thinking about this had no access to a [useful] side channel… other than Bernstein, no public crypto projects are doing anything about this in a systematic way”. We’re approaching a point where localhost “nobody” will equate to key recovery.

Hasn’t this already happened? To try to date it, I would put it at 2001. That makes the prediction better suited to y2k. (The fact the file DPA.pdf on my storage media in use has a November 2001 creation date might be secretly influencing me here. That would be unfortunate.)

Besides all the stories of side channel attacks used by spies, side channel attacks went quite mainstream with research and attack demonstrations on smartcards a few years back. I can remember a couple of RSA conferences ago when there was a demonstration of SPA on the showroom floor, and most (all?) smartcard vendors have now tried to implement some sorts of countermeasures for the various attacks that have surfaced publicly (and not so publicly). I remember this making the news as well, which was probably as much due to the slight humor in flashing lights to induce faults as to the publicity around SPA/DPA attacks on smartcards. I noticed that government procurement specialists started requesting smartcards have countermeasures for these sorts of attacks at some point during this period as well. Recently, side channel attacks and their testing were discussed in numerous papers at the physical security workshop by the CMVP for possible inclusion in future evolutions of the program.

If that is not mainstream enough, then we need to throw in the timing analysis attacks on OpenSSL a couple of years ago (wow, has it been that long?). And then, of course, the AES cache timing analysis attacks demonstrated on OpenSSL this year, which prompted this 2006 prediction.

This is by no means comprehensive, and these are the bigger news items on this topic that stuck out in my mind when reading the prediction. These types of attacks will continue to be extended and to grow in application, which will bring them back into the news, but I think they went mainstream a long time ago.

(Side note: This is useful; however, I just wanted to be useless and comment on the file name. As is my tendency, I am quite amused. My peers and I use the term “black bag job” quite a bit in our lingo and have for years.)

Update: Thomas Ptacek explains I went in the wrong direction when reading his prediction.

Windows GUI code moves

Monday, December 19th, 2005

I just read this post on the blog ADD / XOR / ROL, and there is good news on the Windows front.

Microsoft is moving the GUI code back out of the kernel in Vista according to this article. This is bad news: Finding local priviledge escalation bugs might become hard in the future.

GUI code is like ASN.1 code, big and complicated. Thrown into the kernel, it is “all your base are belong to us” exploitable.

Microsoft has really been making strides in the security arena of its products, which is great for end users and small businesses. These moves also strengthen Microsoft’s software selling position in communities such as defense and intelligence, as does getting this official stamp of approval.

WASHINGTON, D.C. – Dec. 14, 2005 – Microsoft Corp. today announced that a wide range of Microsoft® Windows® platform products have been awarded Common Criteria (CC) Evaluation Assurance Level (EAL) 4 Augmented with ALC_FLR.3 certification.

For the small business, the use of CC certified products mainly takes on significance when dealing with government agencies and their sensitive data. (This significance often comes from government requirements, such as those for USA government agencies compiled here by Corsec Security.)

(As far as operating systems with a security focus go, we like OpenBSD. It is open source, rigorously audited, and completely free (consider donating or buying stuff though – I have this t-shirt). The NSA also played around with Linux at some point.)

On a side note, the word “assurance” was used quite a bit in the above, and the Apex Assurance Group blog has a definition of assurance in this post.

A measure of confidence and trust (usually via a third party) that a product or system meets its claims or meets a specified set of requirements (even when under attack)

A key point to make here is that, if the requirements are meaningless to the user, then the assurance around those requirements tends to be meaningless as well. I think TaoSecurity was trying to make such a point here about the Windows CC certifications.

via ADD / XOR / ROL, Apex Assurance Group – Weblog, and TaoSecurity

(On a completely different topic, I have been using Scroogle to query Google through TOR of late. In doing so, this Scroogle picture was displayed and made me laugh. Wasn’t there a study that discredited this use of aluminum foil hats?)

Locked door, no walls

Friday, December 16th, 2005

I was cutting across town a couple of weeks ago and ran smack dab into the middle of the lighting of the tree at Rockefeller Center in NYC. Somehow, I wandered right passed the barricades, which meant I got out of the crowd, but I must have been in a special area, because when I got to the end of the zone, people were barricaded out and had to show tickets or passes or something to get in. The law enforcement officers moved out of the way to let me walk out, and people looked at me like I was special.

What popped into my head was back a few years ago when web sites would require a username/password for their content when going through their main page, but this simple authentication could easily be skipped by directly accessing the open directories behind that front door. I imagine there are still some sites out there vulnerable to such attacks. A locked door without any walls.

loop-aes and Debian

Wednesday, December 14th, 2005

This post was lying around, but I never actually popped it up on the blog. I was just playing around with loop-aes on Debian, since I had used it in days long since gone by and had a desire to try it out again. Loop-aes served its purpose for a short period, but over a month has now passed since I touched any of the Debian boxes around here.

(On FreeBSD 6, I just quickly hacked /etc/rc.d/gbde script to support encryption of the device mounted as /tmp with random keys, much like is already available for swap via /etc/rc.d/encswap, and I played around with using encrypted memory disks, so maybe I will do a quick post on that.)

The way one of my Debian workstations was configured, all of my personal data was stored in the partition mounted as “/home”, and I wanted all data written to this partition transparently encrypted before write (and, of course, transparently decrypted on read). I also wanted this functionality applied to the parition mounted as “/tmp” and the swap partition. While I used GPG to provide services for encryption my email and files, I needed something more robust and settled on loop-aes. I say this as if I researched it, but the reality was that I had used loop-aes a while back, and, in slightly more recent times, brought that knowledge back for a project at my previous employer.

As has been read numerous times in previous Debian posts on this blog, I fired up “aptitude” and searched for “loop-aes”. Lo and behold, there it was. I installed the “loop-aes-source” and “loop-aes-utils” Debian packages. Now, as described in the previous post, the “loop-aes-source” was the code for kernel module, and so it had to be custom built for the custom kernel I was running. Well, as we saw before, that can be quite easy.

From the “/usr/src” directory, I extracted (“tar -xvjf loop.aes.tar.bz2″). This created the directory “modules/loop-aes” under the “/usr/src” directory, which contained the loop-aes kernel module source code.

Unhappily, as I looked at the readme for loop-aes (“cat /usr/src/modules/loop-aes/README | less”), I found that I would have to rebuild the kernel after editing the kernels configuration (/usr/src/linux/.config). While “CONFIG_MODULES=y” and “CONFIG_KMOD=y” were proper, “CONFIG_BLK_DEV_LOOP=m” was not and needed to be changed to “CONFIG_BLK_DEV_LOOP=n”. I made the change, cleaned up a few other areas I wanted to tweak in the kernel, and proceeded to build the new kernel image.

I ran the following from “/usr/src/linux”.

  • fakeroot make-kpkg clean
  • fakeroot make-kpkg –append-to-version=.03102005 –revision=10.01.Custom –added-modules=loop-aes kernel_image
  • modules_image

This built a kernel-image and loop-aes into Debian packages, which could be installed as root by running “dpkg -i kernel-image-2.6.8.03102005_10.01.Custom_i386.deb” and then “dpkg -i loop-aes-2.6.8.03102005_10.01.Custom_i386.deb”.

The kernel was installed as “/boot/vmlinuz-2.6.8.03102005″, a System.map was created as “/boot/System.map.2.6.8.03102005″, and the configuration for the kernel was installed as “/boot/config-2.6.8.03102005″. I ran “depmod -v 2.6.8.03102005″ and, then, to create the initrd-img, I run “mkinitrd -o /boot/initrd-img-2.6.8.03102005 2.6.8.03102005″. In “/boot”, I remove the symbolic links for “config”, “initrd.img”, “System.map”, and “vmlinuz”, and replaced them with symbolic links to the 2.6.03102005 counterparts. Finally, I ran “update-grub”, which updated “/boot/grub/menu.lst” to include this kernel and set it as the default, and then I rebooted the system.

That was the easy part. Now I needed to configure it.

First, I needed to activate the loops for loop-aes. I ran “modprobe -r loop” and then “modprobe loop”. This loaded the loop-aes module and created devices “/dev/loop0″ through “/dev/loop7″ by default. In order to have loop-aes automatically loaded during boot up, which I needed for mounting “/home” automatically during boot, I added the “loop” on a separate line in “/etc/modules”.

The readme for loop-aes contained all sorts of useful examples for setting up the system exactly as I wanted it. After reading the readme (“zcat /usr/share/doc/loop-aes-2.6.8.03102005/README.gz | less”), I decided to create keyfile encrypted with gpg for use by loop-aes for encrypting “/home”. I did this with the following commands as “root”, based on an example in the readme for loop-aes.

  • mkdir /etc/loop-aes
  • openssl rand -base64 2880 | head -n 65 | tail -n 64 | gpg –symmetric –cipher-algo aes256 -a > /etc/loop-aes/homekey.gpg
  • chown root:root /etc/loop-aes/homekey.gpg
  • chmod 600 /etc/loop-aes/homekey.gpg

Note: The GPG command above prompted for a password to be entered. This password will be derived into a symmetric key that GPG will use to AES encrypt the keys that will be used to encrypt the “/home” partition. This is one of the weakest links in the chain of this setup, so choosing the longer and more random the password, the better.

After this was completed, I rebooted the system into single user mode. On Debian with the grub bootloader, this was simply a matter of selecting the “Recovery” boot up variant for the kernel desired (2.6.8.03102005 in this case).

My goal was to encrypt swap, “/tmp”, and “/home”. Once in single user mode, I backed up the contents of home (“cd /home; tar -cvjf /root/home.tar.bz2 *”), and then unmounted “/home” (“umount /home”), unmounted “/tmp” (“umount /tmp”), and turned off swap (“swapoff -a”). Next, I edited “/etc/fstab”, placing the configurations for our encrypted partitions at the bottom of the file and commenting our their previous “unencrypted” variants.

    /dev/hda5 none swap sw,loop=/dev/loop1,encryption=AES128 0 0
    /dev/hda6 /tmp ext2 defaults,loop=/dev/loop2,encryption=AES128,phash=random/1777 0 0
    /dev/hda9 /home ext2 defaults,loop=/dev/loop3,encryption=AES128,gpgkey=/etc/loop-aes/homekey.gpg 0 0

Now that the partition for “/home” was going to be encrypted, I needed to reformat it with the following commands.

  • losetup -F /dev/loop3
  • mkfs -t ext2 /dev/loop3
  • losetup -d /dev/loop3

Note: When running this first command, I was prompted to enter the password for the “/etc/loop-aes/homekey.gpg” file. Anytime an attempt to mount “/home” is made, a password prompt appears to enter the password for the “/etc/loop-aes/homekey.gpg” file.

After this was completed, I was turned swap back on (“swapon -a”), mounted “/tmp” (“mount /tmp”), and mounted “/home” (“mount /home”). Next, I extracted my backup of the contents of “/home” into “/home” (“cd /home; tar -xvjf /root/home.tar.bz2 ./”).

Then, I rebooted the system and was good to go.

The negative side effect here was that during boot up, I was prompted to enter the password for the “/etc/loop-aes/homekey.gpg” file as this was required to mount “/home” and mounting of “/home” was configured to happen automatically at boot. I preferred this extra layer during boot, but there are ways to avoid it; however, this avoidance might not be good for the overall security of the configuration.

Note: If this is done on a laptop, beware of suspsend, as it could suspend to disk the plaintext keys for any mounted encrypted partitions. There are steps that can be taken here, such as making sure to manually unmount encrypted partitions and turn off swap before letting a laptop suspend, shutting down a laptop rather than letting it suspend, or having the laptop unmount encrypted partitions and turn off swap automatically as part of the suspend process. The latter can be accomplished using using suspend scripts, but it has the disadvantage of needing a forced unmount that could be problematic to open files contained within the encrypted partition; however, if suspend is configured such that it can occur automatically, then I typically do this as having the plaintext keys written to disk essentially nullifies all of the previous efforts.

What reminded me of this lingering blog post was a quick discussion that occured on the Practical Security mailing list. My minor post was bounced, so I will just pop it in down here. (x’s used below so the email addresses are not harvested.)

Date: Tue, 13 Dec 2005 00:07:44 -0500
From: lists <xxxxxxxx@xxxxxxxx.xxx>
To: Alexander Klimov <xxxxxxxx@xxxxxxxx.xxx>
CC: Hagai Bar-El <xxxxxxxx@xxxxxxxx.xxx>, xxxxxxxx@xxxxxxxx.xxx
Subject: Re: [PracticalSecurity] Not-different-enough IVs?

On 12 Dec 2005 12:42:48 +0200, Alexander Klimov wrote:
> On Sun, 11 Dec 2005, Hagai Bar-El wrote:
>> The authors claim that (without encryption) adjacent sectors will
>> have IVs that are just a few bits apart from each other. However,
>> does this matter? Does anyone see the motivation for “hashing”
>> addressed before using them as IVs?
>
> First of all CBC with a non-random IV gives away information about
> plain text: if, say, one (even) sector starts with ‘x…x0′ and the
> next one (odd) starts with ‘x…x1′ (IV is the sector number), then
> the first block of both sectors will be the same.

This made me remember an implementation issue in loop AES (and others),
and a quick Google (loop aes watermark) popped up a post [1] and a paper
[2].

[1] http://www.uwsg.iu.edu/hypermail/linux/kernel/0402.2/1137.html
[2] http://mareichelt.de/pub/notmine/wisa2004.pdf

-Andrew

Services and software

Monday, December 12th, 2005

So, I met up with a buddy that founded a company down in North Carolina, and we grabbed a beer at The Ginger Man while catching up and talking tech. My associate threw out some interesting business ideas and recommended that I start doing presentations at meetings of small business organizations in NYC, which is an absolutely terrific idea. And, a great deal of our tech discussion revolved around the concept that software is really no longer something that tech companies should be selling. Instead, those tech companies should be focusing on providing services around the software. Open source gets this right, and even the big software companies are/will be embracing this model.

(Short interlude here… This was last Wednesday (07-12-2005) evening. After this meeting, I had to hop on the N to Astoria to view an apartment, and the viewing literally lasted hours (over 4), which was way too long, especially since I had last eaten around noon. This means I missed the last NYCBUG meeting, which was on a great topic, jails. So, no write-up on NYCBUG meetings this month, unless someone else cares to contribute. ;) Now back to the post.)

This got me thinking I should note some of my thoughts in this blog, so here is a random dump of those thoughts. I do not have any articles referenced in here, but I do not think I am saying anything here that has not been said by someone else before. Comments are welcome, as this is just some abstract ideas and needs to be flushed out. My focus here is on end users and small businesses, and the information technology useful to them.

Selling software is so last century, much like long distance call fees. New software is distributed for free virtually immediately after its development, regardless of a company’s desire to sell it, and we could chat about ways to control that, but I don’t think there is much point in that. Services are what matter now. A company could build custom software into your architecture and then provides services to clients through this infrastructure. Or, a company could give away their software, perhaps even open source it, and then support customers in using it – build a custom architecture for clients out of it, add specific features requested by customers, support customer developers in modifying it, etc. You know, services.

(I remember getting speeches about how building a company around supporting a piece of open source software was ridiculous. It is the services, not the software, that matter, and these companies sell services, not software.)

So, software companies need to become services companies, and many (most?) are. One of the primary reasons for listing Web 2.0 on D-Kriptik’s main page is because of the openness, the interoperability, and the communities involved in Web 2.0. That is part of this services future. And, the web itself is becoming an open platform.

With openness, interoperability, and community, companies will need to distinguish themselves by providing the best services to meet their customers’ needs and strengthen their communities. The underlying software will be a cheap commodity, and only the services will matter. Companies will sell solutions, not products. And, communities will help to enhance those solutions and grow companies. Reputation, which everyone who knows me knows I preach :) , is one of the cores here.

Some will point out copyright/content protection, in its various incarnations, is being pushed by many big software and media companies, and that in some of the models that help to enable such protection schemes, the actual control of what is running on your computer could be taken out of your hands and placed into these companies’ hands. Of course, the hardware, firmware, and software that support this type of model will be pushed by some software companies unwilling to accept the end of paid software.

If this direction really takes hold, a split will occur between trusted computing platforms that take control out of your hands (closed platforms) and open platforms similar to what we have today (open platforms). (I can see an open platform that is a form of trusted computing platform, but with the control of what runs on that system completely under your control, so the system is still open and your trust is what matters on your system.) Closed platforms will have strong money behind them, and many people, like my mother, do not care enough about open platforms to push back; however, I think enough people want open platforms that closed platforms will not be able to fully dominate. I can think of all the people that have grown up with computers – easily moving digital media around is just a part of their lives. Not to mention, there are many techies that support open systems.

(On open systems that provide a trusted computing model, I can see companies springing up that help end users with configuring such trust.)

Now, I have heard stories about how pirating software costs companies huge sums of money, say multi-billions of dollars (USD) a year for Microsoft. These stories often miss the point that many of the people that are using pirated software would not actually buy it otherwise. In fact, if these users were forced to buy it in order to use it, I think the software companies would end up losing even more business.

If the platforms become closed and people/businesses are forced to either buy expensive software, invest in much more difficult circumvention techniques, or switch to cheaper, open platforms, they will take the latter. So, closed platforms, after their initial push and attempt at dominance, will continue the decline of selling software, and bring about the end of closed systems themselves.

You can see the importance of openness here. The news about the secret distribution of rootkit DRM software by Sony only furthers the push for continued open platforms. Even my parents, non-technical computer users, understood that Sony abused its customers so nonchalantly and that can easily be translated into a distrust of closed platforms.

All of this could be great for a companies like D-Kriptik, and this makes a wonderful world for the customers of these services. This direction is a boon for open software and should be a boost to many open operating systems, desktop environments, development tools, office tools, etc. And, the more money that pumps in here, the better these tools and services will become.

This is the direction things are moving, don’t you think?

Update: A comment from Ray Potter that includes supporting links. And, I just noticed that Apex Assurance Group started a blog. Check it out.

Posting comments

Saturday, December 10th, 2005

A quick note about posting comments on this blog. We currently use the following setting.

Comment author must have a previously approved comment
When this box is checked, comments are only posted if the comment author’s email address matches the address of a previously approved comment, otherwise, the comment is held for moderation. Comments from blacklisted email addresses (those listed in the Local Spam Words Text Box) are held for moderation regardless of whitelist status. (WordPress 1.5 and later)

We also require a name and email address be entered as part of posting a comment. This information is not verified, of course, and the email address is not posted. We use none of the “Comment Moderation” or “Comment Blacklist” settings currently.

These simple WordPress settings have eliminated all comment spam from making it to the live blog at this point. However, in the interest of supporting our beliefs, we will now post (and approve) a comment in response to this post. The contents of this comment will be an nonexistent D-kriptik email address, nonexistent@d-kriptik.com, and this email address will be used to fill in the email field required as part of posting the comment. Since this email address will then be tied to an approved comment, all subsequent comment posts that use this email address will bypass moderation.

Update: We had one mistake in our setup. We did not set any value for the “Hold a comment in the queue if it contains more than xxx links” field, and so all comments were being flagged for moderation regardless of the other settings. This value has now been set to 100.

Security blogs

Friday, December 9th, 2005

I have read the chargen 19/udp blog for a while now. The blog has had a slow period over last couple of months, but it is back now, under a new name (matasanochargen), and with impressive additions to its resume. If IT security is an interest of yours, start reading the matasanochargen blog immediately, if you don’t already. I think the content is about to take off.

While talking about security-oriented blogs, here is a list of some of the blog and news feeds to which I am subscribed.

Actually, I should throw in these three as well.

Of these, I find myself reading matasanochargen, Emergent Chaos, Schneier on Security, and TaoSecurity as often as they are updated, and quickly skiming Rootsecure.net and Packet Storm Security Last Files quite regularly.

Update: What about mailing lists? Good question, I may do a post on these in the future. Actually, after a period of remaining fairly static, my mailing list subscriptions have been growing of late, due to everything from peer recommendations to stumbled upon discoveries. And, thinking about it, I gather much more information from mailing lists than blogs.

Update: Catching up on reading the Emergent Chaos feed, I saw Hey, Look, It’s Matasano!. Doh!

Update: A few more…

Update: A couple more.

Update: Yet more added to my feed subcriptions.

Update: It has been a while since I updated this, so here are more additions…

I still read matasanochargen, Emergent Chaos, Schneier on Security, and TaoSecurity as often as they are updated, and the Metasploit blog has been added to that list. milw0rm.com and IACR Eprint Archive have been added my frequently skimmed rotation, which still includes Rootsecure.net and Packet Storm Security Last Files.

(And, yes, I still plan on doing a list of mailing lists to which I am subscribed when I can get up the “oomph” to perform such a tedious task – I can’t just export a clean list like I do for feeds, and my subscription list has gotten insanely large, much like this feed list.)