New Thumb Drive Encryption Procedure

In this article, I’ll describe a procedure for preparing a brand-new USB flash drive for use. First we’ll securely erase all the data on the drive, then we’ll encrypt the entire drive, and–finally–we’ll check the drive for bad blocks.

Ah, remember the good-ole days of spinning disks? When your OS could tell your hard *disk* to shred a specific sector? Like it or not, those days are gone in the land of USB flash volumes.

There’s a lot of great reads on the complications of securely erasing data on a USB thumb drive. Unfortunately, a lot of the techniques are not universal to all technologies or manufacturers. Consequently, my approach is more ignorant, straight-forward, and broad (at the risk of causing these cheap usb drives to fail sooner & the process taking longer):

First, I make sure never to write any unencrytped data to the disk Second, when I want to wipe the disk, I fill it entirely with random data

Below are the commands that I use to prepare a new usb drive for my use immediately after purchase. These commands are presented as a rough guide; they’re mostly idempotent, but you probably want to copy & paste them
. . . → Read More: New Thumb Drive Encryption Procedure

How to check the Public Key Algorithm used for a given gpg key (ie: RSA vs DSA)

Today I discovered how to validate the Public Key Algorithm that’s used for a given gpg key. Unfortunately, it’s extremely unintuitive & took quite a bit of digging to figure out how. So I’m leaving this here in hopes it helps someone in their future searches.

. . . → Read More: How to check the Public Key Algorithm used for a given gpg key (ie: RSA vs DSA)

HPKP Best Practices for Let’s Encrypt

This post describes how to generate a few backup public key hashes to add to your HTTP Public Key Pinning (HPKP) config that might save you from bricking your domain if Let’s Encrypt ever gets untrusted like StartCom did.

If you have a healthy distrust of the X.509 PKI trust model, then you’ve probably heard of HPKP (and probably also HSTS & CAA). Website certificate pinning was a trend first started by google, who hard-coded a pin of their certificates in their Chrome browser. Eventually, google helped build a more standardized pinning method under RFC 7469. And today, it’s supported by Chrome, Firefox, and Opera.

Pinning is a great TOFU improvement to https, but–if misconfigured–you could “brick” your domain–making it so that your client’s browsers will refuse to let them access your site for months or years (interestingly, this has also caused some security experts to think of how HPKP could be abused in ransom-ware). Therefore, it’s a good idea to follow a few HPKP Best Practices.

. . . → Read More: HPKP Best Practices for Let’s Encrypt

Howto Guide: Whole House VPN with Ubiquiti + Cryptostorm (netflix safe!)

This post will describe what hardware to buy & how to configure it so that you have 2 wireless networks in your house: One that seamlessly forces all of the traffic on that network through a VPN–and one that connects to the Internet normally . When finished, the internet activity for any device connected to the first network will be entirely encrypted so that the ISP cannot see which websites are visited*, what software you use, and what information you send & receive on the internet.

* Assuming your config doesn’t leak DNS; see improvements section

Update 2017-08-25: Added “kill switch” firewall rule that prevents LAN traffic from escaping to the ISP unless it passed through the VPN’s vtun0 interface first. Following this change, if the VPN connection is down, the internet will not be accessible (as desired) over the ‘home’ wifi network (without this, the router bypasses the VPN by sending the packets straight to the ISP–giving a false sense of privacy).


In April 2017, Trump signed Bill S.J.Res.34, which repeals the Broadband Consumer Privacy Proposal from October 2016. This enormous step backwards permits anyone’s ISP to sell their Internet activity. The EFF put it best:

. . . → Read More: Howto Guide: Whole House VPN with Ubiquiti + Cryptostorm (netflix safe!)

Eavesdropping Analysis of PGP Metadata

This post attempts to answer the following question: If an evesdropper intercepts a message encrypted with gpg, how much information will they be able to extract from the message without a decryption key?

I will show the unencrypted metadata added to a GPG-encypted message, and I will present commands that can be used to extract this unencrypted metadata.

. . . → Read More: Eavesdropping Analysis of PGP Metadata

Extend GPG Key Expiration

I came back from my “cross-country bicycle trip”: to discover I could no longer send signed email because my key expired! I’ve also changed colleges from “SPSU”: to “UCF”:, and my old college is expiring my email address, so here’s what I need to do:

# Extend my key’s expiration another year # Add new email address to subkey # Save updates to key # Export a new public key

Background Information GPG

“GPG (GNU Privacy Guard)”: (used here) is a popular, cross-platform implementation of “OpenPGP (Pretty Good Privacy)”: defined in “RFC 4880”: OpenPGP outlines a standard, open message format for maintaining the “confidentiality”: and “integrity”: of electronic messages.

Why Subkeys?

“Public Key Cryptography”: is long, complicated, and well outside the scope of this post. However, one thing I never fully understood was the functional purpose of subkeys. Thankfully, “the GPG documentation”: is excellent.

So, there’s 2 major things I want to accomplish by using GPG with my email

# Confidentiality through encryption # Integrity through signatures

The designers of PGP viewed the signature role as indefinitely important while the encryption role as dynamic overtime. Therefore, when we first generate a keypair, 2 keys are created: 1 primary key for
. . . → Read More: Extend GPG Key Expiration

Plausibly Deniable File Encryption

Plausibly deniable encryption is a fascinating concept. For example, “TrueCrypt”: (a FOSS for hard disk encryption) has a wonderful “Hidden Volume”: feature that provides “Plausible Deniability”: The concept is: you install 2 OS instances on your computer–1 in a hidden volume. If, for whatever reason, you were forced to reveal your encrypted data, you could give access to decrypt your fake, but seemingly legitimate, OS instance. If done correctly, this could prevent you from forfeiting your sensitive data.

What if you want to encrypt some data to a file, bury it on a thumbdrive somewhere, and make it appear to be just an obscure filetype (possibly corrupted)? I ran across “the answer”:–td26392408.html when studying for my Secure Computing final.

I haven’t had a chance to research this potential solution, but there seems to exist a project that builds onto the Blowfish cypher to achieve this plausibly deniable encryption: “Blowfish Updated Re-entrant Project (BURP)”:

Exerpt from “burp.txt”:

Unlike many similar programs, BURP writes to the output file only the ciphertext (i.e., it writes no “file headers”, password verification data, system, program or content identification strings, etc.). Consequently, such file can not be “provably” identified as ciphertext, as long as the key
. . . → Read More: Plausibly Deniable File Encryption

Sabayon, KDE, and Evolution

I recently reformatted my hard drive–switching from pure Gentoo to the Sabayon fork. Sabayon did for Gentoo what Ubuntu did for Debian. It’s generally a lot easier to use, but–unlike Ubuntu–it doesn’t sacrifice functionality for ease-of-use.

. . . → Read More: Sabayon, KDE, and Evolution