Goodbye PGP Global Directory Key - Hello Mountain View

After discovering that the PGP Global Directory has been spamming my public key biweekly w/ 2-week signatures (see here for a snapshot of keys), I trashed my account there to put an end to that.
At first I thought the email threads about keyserver spam not being a big problem, I'm seeing how it could easily be a problem without it technically being spam. Hopefully a good solution comes about so that owners of keys could sign requests to remove keys from the signature list. I'd guess such a solution would restrict what sort of signatures be removed (ex: signature revocations couldn't be removed, etc).

Putting out my key-signing policy appears to have worked pretty good for getting keys signed, so far have 3 cross-signatures out of it. Hopefully I can get some more signatures this year.
If anyone in the Mountain View, CA area wants to work out a key-signing arrangement, I'm out there on business ~January 23-27. Could possibly work out my first signatures of the "Level 3 - 0x13 - Careful Check" type mentioned in my Key Signing Policy :) It is pretty trivial to get a Level 3 key signed, basically just need keys pre-exchanged and ID (driver's license, passport, other government ID).

LuaJSON 1.3 Released

LuaJSON 1.3 is released to the wild!
Major changes made:

• new 'nothrow' global option - currently a trivial 'pcall' hook on decode, but could later resolve to a more efficient handler
• enhanced error output from the 'next' branch
• hopefully "stackless" parser - limit of parsing depth now as large as heap and not stack

Rockspec for those using LuaRocks if it hasn't hit their repo yet: https://raw.github.com/harningt/luajson/b7cb1e6221ae6b70b208b242c1654da39087230d/rockspecs/luajson-1.3-1.rockspec
GitHub link for signed tag: https://github.com/harningt/luajson/tree/1.3
Release download tarball: https://github.com/downloads/harningt/luajson/luajson-1.3.tar.gz

The "stackless" parser is basically a linearization of the LPeg parser so that it parses JSON tokens and passes them into a stack/state-machine implemented as a Lua state object. This degrades performance slightly in the pre 1.2.1 era, but removes C/LPeg stack depth problems encountered in all prior implementations (including the abominably slow 1.2.2 version that reduced the problem, but didn't solve it).

While profiling performance, I found that some unrolling versions seemed to be a wee bit faster, but used more memory and had more pagefaults. My focus on future releases of LuaJSON will be on speed, including a possibility of 2.0 release breaking compatibility in the interest of getting > 2 MB/s JSON parsing performance. Looking at the strict YAJL parser - it hits >100 MB/s on the same data where I get 2 MB/s at best. If I can pull in an MIT-like-licensed C-based JSON parser into Lua and get >= 10x performance, I may add an option for the parser to try to consume the other parser under the LuaJSON interface (for uniformity).

Later I plan on enhancing encoding performance, but for the time being, decoding is most important right now.

CryptoFace Digest Design Oops

Designing an interface for managing a library of cryptographic digests seems so easy, right?

Select a digest from a list, process data, get a hash... all there is to it, right?

WRONG!

While pulling in another digest provider, Botan, I found some items that did not fit into the simple model. Namely the configurability of some of the uncommon and new digest algorithms:

• Customizable output size of the 3 Skein internal storage variants
• Customizable "personalization" value of Skein
• Custom number of rounds and output size for Tiger
• ...

This is even without the notions of composing digests in various fashions, such as in parallel or in a Feistel scheme.

In light of this, I anticipate changing my mechanism for obtaining and enumerating digest implementations. Changes will likely include moving the enumeration of digests to more of a secondary feature, making the move to a set of 'well-defined' digest identifiers to be mapped from strings, and making way for parameterized construction of digests to accommodate more complex notions, including hash-based MACs/etc.

The change will not be without complication, however in light of analyzing the problem and the Botan library, I think I may be able to make some elegant structures possible for dealing with complex algorithms... at least with the Lua engine. An example set of structures could be:

-- Simple sized sha2 filter
x = Filter(SHA2(256))
-- HMAC
x = Filter(HMAC(SHA2(256),"KEY")
-- Complex chain of hashes
x = Filter(Parallel(SHA2(512), Skein(512,1024,"Personalization")))
-- Take the filter and stream file-to-file using ltn12
ltn12.pump.all(
  ltn12.source.file("SOURCEFILE"),
  ltn12.sink.chain(x, ltn12.sink.file("SOURCEFILE.hash")))

Review of "SQL Pocket Guide" by Jonathan Gennick

SQL Pocket Guide by Jonathan Gennick
My rating: 4 of 5 stars

The complexity of developing database queries with SQL is a challenge often requiring frequent documentation searches. The "SQL Pocket Guide" by Jonathan Gennick is a great converged reference for many common database implementation.

The best feature of this guide is its breadth of detail offered. It provides a high-level view of database structures and provides useful details for taking strategies available in one implementation and possibly using it in another database engine. An example of this are the references from custom database function naming of Oracle's "analytic functions" and DB2's "OLAP functions" to the standard's name of "windowing functions". This allows you to take the naming you are familiar with, have been taught, or overheard and refer to it using that name and finding an appropriate redirection.

If you find that you are working with many different databases or want a quick reference to see if a given structure is available in a given database implementation, this guide is for you. Need a list of common data types for a category of data type: this guide has it. Need the details on dealing with times and dates: this guide has a good 20 pages on it. Even if it may not have all the tiny details you may need on a given topic, it can be a compass for finding your way through detailed documentation to what you want to find out.

The eBook format of this book was provided free through O'Reilly's Blogger Review program, you can purchase the book from the O'Reilly book store at: http://oreilly.com/catalog/0636920013471

You can support this blog by purchasing the book through Amazon at: SQL Pocket Guide (Pocket Guides)

View all my GoodReads reviews

GnuPG Key Plan

After much reading and analyzing the issue of re-keying (again!). I've come up with a plan for my GnuPG key security to help put some predictability in my key management.

• ~week - 2011/04/20-2011/04/22 Generate and put in place an RSA 3072-bit primary keypair.
• ~month - 2011/04/20-2011/04/30 Generate ECDSA NIST P-384 and ECDSA NIST P-521 primary keys
• ~19 years - 2030 Migrate to new ECDSA keys and revoke the RSA 3072-bit key marking it superceded.

I will put in active use my 3072-bit keypair for compatibility reasons and the fact that it should be adequate, per NIST SP800-57 Part 1, for beyond 2030. To better future-proof in case of a strong attack against RSA that compromises 3072-bit keys, I will put into practice key-signing where possible my ECDSA P-384 and P-521 keypairs. I have chosen to use 2 additional keypairs in order to better prepare for possible stronger attacks in the future. ECDSA for OpenPGP is currently an IETF draft in its 8th draft (last 7 drafts not touching ECDSA definitions)

Management of Multiple Primary Keys

With regards to key management, I intend to avoid publishing the P-384 and P-521 keys for the fact that I do not know which I will be using in the future and do not want to clutter the keyservers with keys that I will not be using in the near future. I will test key signing with at least the released version of GnuPG (2.0 series) to see if it can sign ECC keys (even though it will not likely be able to do anything with them)... hopefully this will reveal that the key management process is somewhat blind to key contents. Assuming no better mechanism arrives by the year 2030, I will probably transition to either the P-384 or P-521 ECDSA key. I intend to follow the NIST publications to watch for adjustments to the guidelines on RSA key usage for signatures.

Key Signing Policy

I will also write a key signing policy to be attached to signatures issued by my keys. One feature that I hope to be able to write in is a reasonable mechanism to commute the signature to another of their keys with a lesser level of authentication than initial key signing. Given that obtaining key signature authentication is quite a challenge in Indiana, I want to make it practical to walk keys forward instead of an extra "ordeal" to get keys resigned. I intend to read published key signing policies to come up with one that provides good practices with practicality.

Key Publication

All of my keys will be published on my primary web site at http://www.eharning.us/gpg/. My active keys will be published to the key servers through hkp://keys.gnupg.org and also independently to the PGP Global Directory. I intend to keep the naming the same beyond moves to other web page management systems for uniformity. I will also publish the key signing policy underneath that (eventually at http://www.eharning.us/gpg/key-signing-policy/). I will be signing the markdown content generating the key-signing-policy and hopefully publishing it linked directly in the web site for verification. What good is a policy if you can't verify who wrote it!

Key backup for the paranoid

When doing this GPG key work, I realized that if by some chance drives failed and USB keys no longer worked right, I'd be unable to access tons of data backed up encrypted with them. I wouldn't want to backup the GPG keys in the same way as my other data due to the sensitivity.

Some conventional methods of backup that can be used as a "standard" item to handle recovery:

• CD/DVD backup
• USB Flash Drive
• Hard Drive

Hard drive backup is somewhat out of the question as using an entire hard drive for backup and putting in a safe is out of my budget. USB flash drives paired with optical backup work great as a "fast" recovery mechanism in case something goes wrong. The problem with these is that testing them as backups is somewhat tedious.

Here's where paper comes in. You print out your key data in some form that can be input back into the computer in a reasonable manner. Now this may seem backwards, but it is quite useful for backup. You can easily print say, 10 copies of the key, slip them in something to reduce air exposure, and put them in safe deposit boxes / home safe / etc. For recovery check, you can visually inspect them to make sure that they are not degrading. To test thoroughly, you can take a small sample (ex: 1 from each backup location) and attempt a recovery. Redundancy with paper backup is quite trivial.

Now... how do you put the key on paper. You could print it in hex or base64-encode it and OCR or manually type it in... but that is tedious and error-prone. For high-density machine-readable data storage on paper you can use 2D barcodes. These typically have error-codes builtin to help manage slight flaws in the paper or scan. A good article at Coding Horror, The Paper Data Storage Option illustrates some mechanisms for paper backup. I tried stuffing backup data into QR codes and datamatrix blocks, but found that the encoding/decoding software available were quite finicky. Another problem with these formats was that they are not intended to store bulk data. There must be some other good way of encoding data for printing and recovering...

In steps in the mentioned Windows application PaperBack by Oleh Yuschuk. This tool takes an input file and prints out dotted pages arranged in blocks to store your data. It provides redundancy through duplicating blocks and arranging throughout the pages as well as error-checking codes within each individual block.

I also tried the Twibright Optar paper backup mechanism, but ran into the problem that it expected a high quality printing medium and I found it hard to tweak it to work with my readily available inkjet. Of course for final usage, laser printing would likely yield high enough quality to meet my needs.

The two backup mechanisms have their pros and cons.

PaperBack
Pros:

• Easy to use - builtin printing and scanning capabilities
• Visual display of the quality of the scan, permitting visual detection of where your backup may be degrading
• Easy customization of DPI, dot-size, redundancy
• Good reliability even in the face of injected errors through gimp

Cons:

• Windows only - right now
• Imports/Exports only as bitmap if not using direct print/scan

Twibright Optar
Pros:

• Linux-compatible
• Provided documentation describes the theory of how the encoding works well
• Better data density
• PNG input support

Cons:

• Needs hand-edited code to change dot-size
• Seems to be very sensitive to artificially introduced errors through whole-image noise/damage/rotation

I selected PaperBack as my primary backup mechanism since it met my needs and provided an easy way to tell how "bad" my backup was. I took my GPG secret key blob, sent it to PaperBack for handling and was able to pack on less than a single sheet of paper with the lowest DPI (80) and a redundancy of 10 block copies, and AES encryption of the entire data blob (beyond what GPG protects the key data with). Recovering was fast, however showed errors right from the start. These errors were quite recoverable and well within the range were errors could be recovered from. Seeing how useful paper/image-based data transfer is, I intend on using a QR or datamatrix code that has my public key information (ID/thumbprint) to help make key signing & simple detection of what key should be used for verification/encrypted-email.

With a paper copy in protected locations, I can be even more certain that the lifetime of my GPG keys will be beyond the lifetime of the machine in which they came from. The sort of thing becomes quite important when protecting information that may by chance or specifically on purpose outlive you.

8192-bit GPG Certification Key - Why and How

I generated my primary key, the certification key with an 8192-bit RSA key to help ensure that it lasts for quite some time. I figure that this should prove adequate until ECC is integrated into the OpenPGP specification and a majority of applications start supporting it. I keep this key very well protected and excluded from the set of private keys I use regularly.

Now for the how. GPG does not permit generation of 8192-bit keys normally. I found something somewhere hinting at using the batch mode of GPG key generation, but do not recall where. An example command-set that will get you a 8192-bit RSA signing key:

gpg --batch --gen-key <<EOF
Key-Type: RSA
Key-Length: 8192
Name-Real: ME
Name-Comment: COMMENT
Name-Email: EMAIL
Passphrase: PASSWORD
EOF

To segregate my certification key from the other used keys, I exported the secret portion of the subkeys using --export-secret-subkeys, wiping out the overall key, then re-importing the 'subkey' file. One downside to this sort of mechanism is that it isn't quite OpenPGP compliant and other tools such as APG cannot use the subkeys file (they complain about the missing primary key).