Long-Delayed Updates - Life, Projects, Work

I've been putting off updates here for quite some time, primarily due to lack of focus. I've been working on quite a few personal things lately:

• Attending free college courses on cryptography and algorithms
• Working out the design of the cryptoface library
• Getting my feet wet developing mobile/desktop games with Moai
• Beta testing games

On the work/career side, I've been busy as well:

• Designing a new cryptographic data interface
• Designing a new memory management interface
• Implementing a new web-request client
• Attending people/skill-management training
• Answering recruitment messages

While working on designing a new cryptographic data interface at work, I've had a chance to get a better handle on how certain sets of operations should behave and how one might best structure a generic system. This should help out with figuring out how to best setup how cryptoface will work out.

I also had to design a memory management interface... that was quite an eye-opener. The main objectives were to ensure that data in memory would not get flushed to disk and that any flushable memory would be protected. This issue of flushable memory was relatively easy, use unflushable memory to store a key to encrypt the flushable memory. The unflushable memory was difficult and yielded a problem: What about suspend-to-disk? It turns out that, for the relevant systems, on a suspend-to-disk operation, your 'unflushable' memory will end up on disk (unless you implement some crazy notification system that 'might' be implementable on a given platform). I plan on writing a larger article on how the memory management interface will make its way into cryptoface.

Earlier this year I attended free online courses on cryptography and algorithms. These were awesome, they took much more time than I anticipated, but they stretched my mind quite a bit. I was thinking that, given I work on cryptography so much, it would just be a refresher course. Not at all! I was also better prepared for analyzing the recent "padding oracle" attacks that have come up lately. Taking the algorithms class was a great refresher and helped give me a better appreciation than I did when I first had it at MSU as a freshman.

Recently I came upon the Moai development framework. It strikes me as a great fit of technologies:

• Lua
• Android
• Chrome (via NaCl)
• Desktop (Linux/Windows/OSX)
• iOS

Unlike many of the other frameworks out there, it is open-source! I took advantage of this during my exploration of one the physics system in place (box2d) and used some free time to patch it up with some documentation and unify the scaling system to better honor the virtual unit system. I plan on using it sometime in my free time to develop and publish a game for Android for my kids to play. What cooler way to get kid-kudos than be the one with the dad who "wrote a video game!"

This open-source experience also gave me an interesting insight into an area that I had not yet ventured into: getting approval for "outside" work. My prior long-running projects were grandfathered in through the acquisition process, but I had not yet envisioned writing game software.

I have also had the task of answering many recruiter messages on Linked-in. For the longest time I was receiving many opportunities that involve moving out to an area w/ at least double the cost of living... not my cup of tea... at least yet. (Quick stats from a site show that moving to California would cost me 55% more and I would only be making 25% more... not cool) I discovered about a month ago that there was a section to input text for recruiters/etc to see when considering to send a message. Lately I haven't heard from as many (yay!) but a few received still seem to not read this. I also typically get requests to forward this information to any I may think fit-the-bill. Sorry... even your offer of an iPad on recruitment pass-through isn't going to work well. My current network of people is pretty much where I'd like them to be: local! In addition, most of the talent I know well and would recommend well are those that I work with (a great team!) and dare not trade them off in return for getting someone new (though are two new contractors look to be doing quite well).

On the receiving end of this when observing the contractor-search process, it looks like the hiring process for skilled individuals is extremely difficult. It seemed the process was to funnel people through that look like they "might" have qualifications. We ended up with people who lacked entry-level computer science skills... quite annoying when we have 3rd party hiring staff "pre-screening"... as the smaller TrustBearer Labs, I was more involved and had to directly deal with such individuals, but at least then it was more understandable since we didn't have a big arm to work on the screening task. Not to dismiss the recruiter's negligence in the hiring process, it seems that the pool of qualified skilled software engineers is getting quite diluted... Which will make it a bigger challenge for me if/when I ever enter the active employment search role: I'll have to fight to differentiate myself from the crowd of others out there. At least there are sites out there that are trying to help in this area:

• Nerdability - My profile is http://nerdability.com/user/harningt
• Github - My public page is https://github.com/harningt

These work well since I do like to work on open-source software. Yet another benefit to the open-source industry, if you write good code, potential employers can see it before you work for them!

Hopefully this blog post will put an end to the long blocker on writing more posts.

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).

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")))

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!

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).

Venture Back to GnuPG and my GPG Key

GPG KEY:
sec#  8192R/B7CE5252 2011-04-11
    Key fingerprint = 5359 D88D 11DB 6981 C92E  A723 023C 6BB2 B7CE 5252
uid                  Thomas Harning Jr 
ssb   2048R/7B0654AB 2011-04-11 (email signing)
ssb   2048R/72F567FF 2011-04-11 (email/file decryption)
ssb   4096R/97E7681D 2011-04-11 (codesigning/etc)

I've ventured back in the the realm of GPG with its web-of-trust and easy file signing/encryption. I was prompted to do this when I realized I had no good long-term cryptography solution for dealing with documents that I want to be protected and be available in the future, even if my safe drives fail.

In my scheme I planned to have the following sort of key structure:

• Root Protected Key - large key and stored off-disk
• Machine Keys - each machine gets its own keys to manage for encryption/decryption

The problem I realized with this is that in order to do email encryption/signing, I may have to go to a specific machine to recover the data.  There is also the problem that multiple keys complicate managing trust.

When working through GPG's features, I realized I could have a similar structure without multiple independent GPG keys... GPG has the concept of subkeys that lets me do what I want with a centrally managed identity. A short little dance lets me setup a root protected key that is not on the system disk, but instead on an encrypted-removable drive. You could also do this with a hardware token, but currently keysize is limited and a hardware token has more value if you operate in a less-trusted environment or may potentially lose it.

My single key is setup as follows:

• Master key non-expiring 8192-bit RSA key with Certifier and Signing capabilities
  Stored on a hardware encrypted drive (with copies of "day-to-day" keys) and only when in a "safe" environment (ex: Linux LiveCD)
• 2048-bit Email/File signing key expiring in a few years
• 2048-bit Email/File decryption key expiring in a few years
• 4096-bit Signing key - for uses such as software signing, expiring after email keys

Request: Sign my GPG key, any measures you feel good for proving my identity, let me know. Depending on who you are, I'll try to figure out what sort of proof I'd need to cross-sign your key.