Archive for the ‘crypto’ Category

Update 20110723 – CentOS 6, Sabayon, Slackware, NetBSD, Etc.

July 23, 2011

Long time no see, haters. Since my last update earlier this year, I’ve been pretty busy. Usual stuff: family, work, and sports injuries.

I have a shiny new Lenovo laptop. One of the reasons I chose this one is because I was able to get a list of the hardware and checked it against lists of supported devices. It’s all supported very well under Linux and the BSDs (Net, Open) I looked at.

First thing I did was reduce the very large NTFS partition someone formatted it with (I never have booted this into Windows 7) so that it’s actually quite small. Then I installed a release candidate for Scientific Linux 6 on it, as that was the first available RHEL6 clone. I’ve since changed that over to CentOS 6 using a net install. And since I have no interest in booting the pre-installed OS, I changed my grub menu.lst to no wait, no options, just load that one in a freaking hurry.

As usual, I found some nits to pick about how certain other things were configured and I had to make some changes to get simple things to work. This goes for software as well as hardware.

First the hardware side of it. I thought the inkjet printer I keep in my room was supported out of the box despite noticing the printer would “eat” up paper upon finishing the job — not fully ejecting it before pulling it back in to the printer. It was only the past few days, though, I realized there was more wrong than met the eye. I needed to make some quick scans and xsane reported back I had no scanner. Hmmm. I checked it via scanimage and it was detected. I also double-checked the drivers and saw that the sane backends for hp and usb were there. I decided to see if the hplip site had a newer RPM than is available in any of the repositories I’ve enabled. I entered the relevant information and downloaded an up-to-date RPM with new drivers. Installing it required removing old RPMs. Then I had to set some permissions so I could use the scanner without escalating my privileges to root. The new hplip RPM also resulted in better printing and no more “eating” paper.

There was a variety of software I installed from the normal as well as third-party repositories. Most of it has been without any trouble — only a couple things from a more bleeding edge repository (EPEL) have conflicted with packages from others. Some of the configuration issues have been simple and straightforward. I’m coming around to accepting pulseaudio, especially as it makes some things easier. My Bluetooth headphones work fine and are able to remotely control playlists in totem. Haven’t tried yet in rhythmbox but mplayer (from rpmforge) needs remuco to work.

Even though I’d be exaggerating to call RHEL6 or its clones bleeding edge, it’s still new enough that repositories lack certain packages that I wanted to install. One solution (other than “wait”):

sudo yum groupinstall 'Development Tools'

I’ve recompiled things that bugged me as well as things that were either unavailable or that I wanted to update. I wanted liferea so I had to compile it myself. Dittos sylpheed (NOT claws) and mew (emacs e-mail client). I also wanted an update of org-mode for emacs, but I’ve also played around with compiling other emacsen. This morning, I decided to try sxemacs.

I wasn’t impressed with the clunky xaw widgetry, let alone the faces available on my laptop (trust me, terminus looked only a little better), and I decided against installing GTK1 headers just to see if that would look any better. Not even some minor color changes helped. I usually run emacs from console anyway because it’s easier to run it in screen and then shell in and out, locally or remotely, as needed. The faces (fonts) bother  me a lot more than the widgets — it’s not about the aesthetics as much as if I can clearly see what the hell I’m doing.

I’m going to try this for a while and see how much work it’ll take to get it working the way I use GNU emacs. Just remembered I forgot to change EDITOR=emacsclient to EDITOR=gnuclient. Also, this (last line!) has to go in the init.el to keep from opening a new sxemacs GUI instance:

(require 'gnuserv)
(setq gnuserv-frame (selected-frame))

Sheesh! Recompiled –without-x. Much better, too, after removing background color (transparent terminal over black wallpaper).

Now the fun of getting my other emacs stuff to work correctly with this.

I also converted my previous laptop over to CentOS 6. I did a minimal net installation, installed xfce from EPEL, and then added some of my own packages (including dwm and jwm because I decided I don’t care for xfce). My ridiculous Acer Aspire One is still running SL6 and still having issues with the fucking Atheros wireless card. When it starts to flake out on me, I pop in a zyd-based USB wireless adapter. Voila. I should blacklist the module for the Atheros card but, honestly, the AA1 has been such a pain in the ass that I seldom use it. I recently updated XP (30-something packages!) after not even booting it for like half a year and suffered some USB-related issues as a result. The good news is under the RHEL6 clones, all the other AA1’s hardware — including both internal card readers — work properly, without having to boot one side with a card inserted.

Okay. The headline mentions other distros and NetBSD. I’m considering some changes on the other laptop because a lot of stuff I’ve compiled for it would be just as easy from scratch instead of using source RPMs or new source. I tried to get a measure of how many packages are installed by default on a minimal install of various distros. I figure RHEL clones will have the most, followed by Debian, and on the other side of the scale will be Slackware and Gentoo (I haven’t used Sabayon before but I like the option of using a binary or portage depending on my tastes — this is why I’m also considering a BSD and pkgsrc).

There are certain distros I’ve taken off my radar list despite having a fondness for them. As I now use laptops, netbooks, and other portable devices — including portable USB storage — about 90% of the time, encryption is very important to me; one of my parents’ was a victim of identity theft in the past couple years and I was already a bit paranoid about what kind of information could be found in plaintext on my computers. On all my computers, I like the option of installing to, or easily setting up, one encrypted LVM which includes at the very least my /home, /var, /etc, and swap. I used to think it was adequate to encrypt just /home and swap but I’ve changed my mind after auditing “identifying” information available elsewhere on an unencrypted system. For example, plaintext wifi passwords in /etc/wpa_supplicant/wpa_supplicant.conf (or elsewhere on a “non-standard” system) or stuff stored in /tmp. I also think it’s not enough that the “core” of the operating system be protected from threats, such as over the Internet; the biggest vulnerabilities usually stem from applications and user choices, and you can’t reboot those problems away — they’ll still be there if (or because) /home and /usr/local are RW, not read-only. When storage is measured in GB and TB and speedy multi-core processors, it’s harder for me to choose to run my OS in some “embedded” style.

Still on my TODO list is my post about what I use instead of Also, I’ll try to write a post about the minimal install I did with more specifics (need to edit my gnote version of it — wish I could import that into this without reformatting) in the near future. As usual, no promises on time lines.

Skanky Garofalo Can’t Crack Blowfish on 24

March 17, 2009

Morris O’Brian, husband of Chloe, turned on Jack Bauer to save Chloe from 15  years in prison and agreed to crack “Blowfish 148” encryption on last night’s episode of 24. This is at least the second time in which Blowfish is cracked on the show. The first time it was cracked with the help of a “proprietary algorithm” but they started out with a list of  “nicknames, birthdays, pets,” etc., anyway.

Last night I chortled when Morris announced to the special agent in charge of the DC field office that the designer of the algorithm left a backdoor. Janeane Garofalo, who’s unbelievable in her role as an FBI agent (I’ve seen no female agents in the Bureau with commie red star tattoos on their hands; let alone characters anything like the IRL mouth-breathing skanks of Garofalo’s ilk), had been stymied by the encryption and needed either Morris or Chloe to crack it for her. Imagine that. I was unhappy to see Gar0falo in the series at all but I guess she was available and cheap following the cataclysmic flop of Air America. Seeing that she couldn’t crack Blowfish might help me sleep easier at night. Heh.

Maybe “Blowfish” just went over casual viewers’ heads as they were impressed that Morris could crack it in just a few seconds and learn that Jack was visiting a US Senator after being accused of murdering a federal witness. I don’t know why writers and producers don’t just make up names for algorithms and techniques and programs, but it gave me a chuckle — not as deep as seeing Garofalo working for the FBI but a good one nevertheless.

Debian and Derivatives (and Beyond) Serious SSL Advisory

May 16, 2008

HD Moore of Metasploit has tested a serious problem with Debian-based implementations — including Knoppix, Finnix, Mepis, Ubuntu and its derivatives, et al. — dating to September 17, 2006, of OpenSSL due to removal of code that was responsible for seeding random number generation (which is used to calculate encryption keys). This makes random number generation predictable and means keys are guessable/crackable. Moore writes that “Instead of mixing in random data for the initial seed, the only ‘random’ value that was used was the current process ID. On the Linux platform, the default maximum process ID is 32,768, resulting in a very small number of seed values being used for all PRNG operations.”

Debian OpenSSL Predictable PRNG Toys:

If we continue this process for all PIDs up to 32,767 and then repeat it for 2048-bit RSA keys, we have covered the valid key ranges for x86 systems running the buggy version of the OpenSSL library. With this key set, we can compromise any user account that has a vulnerable key listed in the authorized_keys file. This key set is also useful for decrypting a previously-captured SSH session, if the SSH server was using a vulnerable host key…

The interesting thing about these keys is how they are tied to the process ID. Since most Debian-based systems use sequential process ID values (incrementing from system boot and wrapping back around as needed), the process ID of a given key can also indicate how soon from the system boot that key was generated. If we look at the inverse of that, we can determine which keys to use during a brute force based on the target we are attacking. When attempting to guess a key generated at boot time (like a SSH host key), those keys with PID values less than 200 would be the best choices for a brute force. When attacking a user-generated key, we can assume that most of the valid user keys were created with a process ID greater than 500 and less than 10,000. This optimization can significantly speed up a brute force attack on a remote user account over the SSH protocol.

In his FAQ, HDM says, “It took two hours to generate the 1024-bit DSA and 2048-bit RSA keys for x86” using 31 Xeon cores clocked at 2.33Ghz. He also adds that “It should be possible to try all 32,767 keys of both DSA-1024 and RSA-2048 within a couple hours” barring anti-brute force scripts on the server.

In my recent page for re-engineering DSL for traditional hard drive installation, I recommended updating zlib, openssl, and openssh because of the age and (in)security of the packages upon which DSL was built. Security is not a one-time shot, it’s a matter of persistence and requires constant attention and commitment. My page was published before becoming aware of this particular issue, which doesn’t affect DSL, per se, because the versions affected are Debian Etch and later; DSL was built on Woody, which predates Sarge and this particular Debian/SSL issue.

Unfortunately, this problem goes beyond just Debian users (and users of Debian-based distros like DSL) because of the number of certificates exchanged between secure sessions involving affected servers. Certificates from Debian servers — from banks, from websites, etc. — are affected regardless if the end user uses Debian, Slackware, FreeBSD, OSX, or Windows. As Moore adds,

In the case of SSL keys, all generated certificates will be need to recreated and sent off to the Certificate Authority to sign. Any Certificate Authority keys generated on a Debian-based system will need be regenerated and revoked. All system administrators that allow users to access their servers with SSH and public key authentication need to audit those keys to see if any of them were created on a vulnerabile system. Any tools that relied on OpenSSL’s PRNG to secure the data they transferred may be vulnerable to an offline attack. Any SSH server that uses a host key generated by a flawed system is subject to traffic decryption and a man-in-the-middle attack would be invisible to the users. This flaw is ugly because even systems that do not use the Debian software need to be audited in case any key is being used that was created on a Debian system.

The Debian advisory notes,

This is a Debian-specific vulnerability which does not affect other operating systems which are not based on Debian. However, other systems can be indirectly affected if weak keys are imported into them.

It is strongly recommended that all cryptographic key material which has been generated by OpenSSL versions starting with 0.9.8c-1 on Debian systems is recreated from scratch. Furthermore, all DSA keys ever used on affected Debian systems for signing or authentication purposes should be considered compromised; the Digital Signature Algorithm relies on a secret random value used during signature generation.

The first vulnerable version, 0.9.8c-1, was uploaded to the unstable distribution on 2006-09-17, and has since that date propagated to the testing and current stable (etch) distributions. The old stable distribution (sarge) is not affected.

Affected keys include SSH keys, OpenVPN keys, DNSSEC keys, and key material for use in X.509 certificates and session keys used in SSL/TLS connections. Keys generated with GnuPG or GNUTLS are not affected, though.

Anyone who’s used SSH and/or OpenVPN between their own and a Debian- or any of its derivatives- based computer/server needs to update and generate new keys. Users of all operating systems may also get pop up messages from their browsers over the coming days that secure sites they visit may have new or different certificates. I think users should read each new certificate to verify integrity because this could prove wide enough that criminals may take advantage of the confusion with their own dubious and insecure certificates, which could make a bad situation even worse.

This was a dumb mistake made by the removal of only a few lines of code. Sometimes dumb mistakes turn out to have the widest effects on users. Even those who don’t use Linux or Debian.

GPG 2.0.7 Released

September 11, 2007

GnuPG 2.0.7 released:

We are pleased to announce the availability of a new stable GnuPG-2 release: Version 2.0.7 This is maintenance release with a few minor enhancements.

WiFi Insecurity: Gmail Cracking 101

August 3, 2007

Humphrey Cheung writes about Errata Security president Robert Graham’s point-and-click demonstration at Black Hat USA. Graham used a sniffer and ran Ferret to copy captured cookies (over wifi at the conference). He then cloned the cookies into his own browser and demonstrated the easy effect by showing someone else’s gmail account in his browser. (He also used the hijacked account to send a message to Cheung.)

Since the attack relies on sniffing traffic, using SSL or some type of encryption (like a VPN tunnel) would stop Graham in his tracks. However, many people browsing at public wireless hotspots don’t use such protections.

You’re an idiot if you use T-Mobile hotspot,” said Graham.

Clipperz: Your Browser As Security Tool

May 18, 2007

I’ve come across a web-based service called Clipperz that may at first glance seem just a password manager, but the service can be as broad as any user wants it to be.

First, some highlights. It’s platform (OS) neutral — it uses the browser’s javascript capabilities to encrypt information locally and upload it, in encrypted form, to their servers for storage. It works with Firefox, Opera, MSIE, etc. So you can use it on any operating system and continue to access service if you change temporarily (such as borrowing a friend’s computer). It’s completely portable so you can access it from any computer, any time, anywhere. It allows you to store your passwords, certificates, and any other online credentials. You can use it to manage and auto-log into your online accounts through one interface. It can also be used to encrypt and manage other text-based information like PINs, access codes, confidential notes, etc., so they can be accessed from anywhere.

Second, some technical information. They use standard 128-bit encryption (SRP, AES, SHA-2, ECC, Fortuna PRNG, SSSS) which all occurs on your own computer using javascript. You keep your own key (Clipperz doesn’t); you lose it, you’re screwed. All they get on the server-side is scrambled data. They don’t know what you’ve uploaded, they don’t even know who you are; your account isn’t tied to an e-mail account, but to your own registered account. They don’t install anything on your computer.

Third, some minor concerns. Encryption is only as strong as the protocols used: stronger passphrases are harder to break than weak ones. I’m also not keen on the idea of storing PINs, account passwords, and information best not shared with the world on someone else’s servers; Clipperz does have an offline copy, which basically dumps what they have in your account down to your computer. The offline copy can’t be modified; modifications are online. And since it’s encrypted, the offline copy is only accessible by passphrase.

This could be a solution for people who use multiple computers and are concerned about the security of data they need to access and store online.

Coming soon: a review of PassPack, a competing service to Clipperz.

Added bcrypt Page

May 14, 2007

I’ve added a page about using bcrypt across different platforms. Since it’s highly portable (~125kb for the Windows version with zlib.dll) and very easy to use, there’s no excuse to not carry and use it to encrypt files and avoid scares like these on laptops and USB keys.

Securing Laptop/Notebook Data

May 13, 2007

Many people store personal information as well as important business data on their laptops, notebooks, PDAs, and other portable computing devices. These devices can be very easily stolen or even “lost,” exposing individuals, corporations, and customers to more harm like identity theft (as happens with every new story about companies losing laptops and portable drives with customer credit card and SSN information) and loss of proprietary information.

The old rule of thumb about not owning things that someone wants bad enough to steal applies to data as much as it things like cars, jewelry, and even laptops themselves. If it’s important enough to cautiously protect, it probably shouldn’t be stored on such a portable (steal-able) device. That’s impractical for a lot of reasons in today’s world, but there are steps people can take to protect themselves and their data.

This article notes that laptop/notebook thefts eclipsed 750,000 in the US alone last year, and that 97% of stolen notebooks are never recovered and details a few steps to at least secure their data should their devices be stolen. Most are simple and straightforward: using passwords. Those aren’t impervious, though: I regularly bypass passwords (such as the last hard drive I bought at a garage sale — only the user account was password-protected, the rest of the drive was accessible).

Data can also be secured via encryption (which is only as strong as the protocol used). Stolen computers can also report their locations via services primarily targeted at Microsoft and Mac users. I think the former is preferable to the latter because I can think of several ways to keep a computer from e-mailing its most recent locations (and I’m pretty sure I could also disable such functions). In fact, it’s a lot easier to prevent a computer from calling home than it is to crack a well-encrypted file or partition.

There are open source options available in addition to those listed in the article. GPG is available for both Windows, Linux/BSD, and there’s also a Mac port now. Another smaller, and maybe simpler, encryption solution for those working across platforms is bcrypt. It’s not as feature-filled as GPG, but it’s small enough that it can be very portable — it’s only 61kb so it can be installed (along with the required zlib dll, 63kb) on every USB thumbdrive to encrypt/decrypt its contents regardless of where one may use it.

I’ve found bcrypt to be very useful when using both Windows, whether with PortableApps and U3 or just to encrypt/decrypt normally stored data, and Linux. Its only drawback in the Windows version is it doesn’t hide or mask passphrases. It works so simply (the same command encrypts and decrypts) and seamlessly, though, between Windows and Linux versions that I highly recommend it for those using either or both systems.

Shoring Up Wireless Security

May 4, 2007

Here’s an article about how exploits are now being distributed among the criminal class after cracking WEP encryption to violate the security people have on home networks (if they even bother enabling encryption — too many people don’t), at public hotspots, etc.

You might not even know if these hackers have gained access to your connection. They may be a couple houses over or on the next street. But if they’re doing something illegal with your Internet connection, it’s going to come back to you.

It’s no longer just free-loading piggybackers you have to worry about slowing you down by hogging your bandwidth. Your IP is tracked regardless of who’s using it through your wireless router. Use stronger encryption, like AES and WPA, instead of WEP.

TJX Thieves First Hit At MN Store

May 4, 2007

A Wall Street Journal article cited here quotes investigators familiar with the TJX breach as saying the criminals used an antenna connected to a laptop to capture data moving between scanning devices, cash registers and PCs, which were using wireless LAN connectivity and WEP encryption.

John Pescatore of Gartner is quoted as saying:

The encryption to keep someone from breaking in was done very poorly in this first generation. It’s no better than (no security at all). This is something I would have thought an audit would’ve caught.

It’s something an audit should have caught, and it shouldn’t have gone undetected for 19 months and compromised the security of 45.7 million customers.