TGP - Thor's Godly Privacy - Encryption for the Cloud. And anything else you want to secure!

Stacks Image 369
Before we get started, if you would like a (somewhat) brief explanation of PKI, well, more appropriately the use of RSA key-pairs, you might want to check out my blog entry Thor's PKI Primer. One thing I've found lacking in articles I've seen is the lacking of the most important part of key-pair processes. It isn't that you encrypt with public keys and decrypted with private keys, it's how a public key can be used in conjunction with a private key and why you can share it publicly. I cover that, and find it all quite interesting.
Stacks Image 2958

05/27/17 Update
v2.2 - Current Stable Release
There was some pressure from external influences to remove the Rainmaker API. Apparently it’s considered “too easy to be leveraged for abuse.” That’s obviously untrue, but I removed it anyway. Not because of the pressure, but because I’m working on bigger and better API calls with the ability to automatically format disparate data sources into proper XML tags and will include sources such as Facebook and Google. It’s awesome.

The linked zip file has been compiled in x64 Debug mode with both DEBUG and TRACE constants set and includes all build information. You can just run the .exe though.

TGP - Thor's Godly Privacy v2.2 by Thor (Net 4.0 Client Profile required)
Executable SHA256:
92aa4afee58252b55b22f3003d380dfcc15b7cce6826e8ea7cdc1a3f4ae4fe1e


Feature manifest for minor versioning increment. Full revision history is here.
Stacks Image 512
The Password Strength Machine is now living on its own, and has been moved (along with the docs) to HERE. It seems like it's a popular tool, and it's gratifying to see folks thinking differently about security.
Stacks Image 845
v1.2.4 - Beta (RC) now including x64 bit versions. For what it's worth, I've not seen any appreciable difference between x32 and x64. Just thought I'd throw that in there.
Stacks Image 849
Added single-file AES256 encryption functions for binary encryption of files outside of the TGP KeyFob/MSL framework, using user-supplied passwords instead of RSA key-based AES key encryption. It's your basic "password protected AES256 encrypted files," but it actually has a pretty decent use case
Stacks Image 851
Auto Complete" function to predict decryption output file name and auto-populate the OutFile variable. Note this function automatically overwrites existing output files by design. User toggled.
Stacks Image 853
Added block crypto-stream buffering in order to support very large AES file encryption (tested to several gig). This is not yet possible for TGP XML files due to the complexities in creating large embedded crypto-blobs inside XML text files. But I'm working on that. However, I did optimize bit-chunking as much as I could in my current generation framework and have no problem with generating 500 meg TGP XML files. That's pretty big for a single file, so I'm OK with that for now.
Stacks Image 855
Added "Launch File on Success" feature to automatically launch decrypted files upon successful decryption. User toggled. The sub-file extension must obviously be registered with a particular application.

I’ve been continually frustrated with the limits of personal file/data encryption products. PGP’s key management sucks and is completely unwieldy. None of these products allows for easy consumption of key material for automated distribution and retrieval. Well, PGP does have a server license with APIs to use their proprietary binary format and further shut yourself off from the real world. Oh, and it is grossly overpriced, as in "PGP salesmen go to hell" overpriced. So I decided to design an encryption paradigm of my own to do whatever I wanted it to. It took some work learning freaky math stuff, but hey, it’s only math.

About TGP: The Wherefores and the Whys

The Basics
TGP is a small yet very powerful encryption paradigm with a unique key management and distribution solution.  With all eyes on “the cloud,” I decided to write an encryption application better suited to an environment where key portability and data security were, at the least, challenging.   In cloud computing, not only is the use of file structures becoming more abstract, but the very concept of “file servers” is becoming more and more ubiquitous as they are converted into “instances” and “containers.” As such, I designed TGP with “encryption for the cloud” in mind.  That means that not only does TGP do everything your normal PGP-type applications do, but it does even more, and goes about things a bit differently – differently in a way that can change the way you work with your encrypted data.  At the simplest level, this is done by encrypting data into byte arrays, and then converting those byte arrays into Base64 encoded text wrapped inside XML tags.  In this way, not only do you get your typical file-based encrypted representation of your data, but you also get data that you can copy and paste directly into any email, mailing list, blog-page, or social networking site if you choose to.  It also makes processing multiple encrypted files as key management much easier that other implementations as the XML encoding allows you to processes and manage encrypted data files or blobs programmatically.

I’ve researched many different products, processes, and features designed to manage encrypted material (I even worked with the encryption board at MSFT) and can say with confidence that this solution is the only working paradigm where it doesn’t matter whether you are using file-system data, database-sourced tables and fields, or data literally posted to a Facebook page - it can all be directly accessed and manipulated. What I think is interesting about this is that if we choose to, we no longer have to be the custodians of our encrypted data – we don’t have to worry about actually housing the files or data: we can just post them to the internet and let someone else assume the burden of storing the files for us while still offering security. If I want to share encrypted files with someone or secure my own files, all I have to do is TGP encrypt the data I want, and post it to a mailing list somewhere.  In the case of a list like Bugtraq or Full Disclosure, the data is actually automatically replicated out to any number of archive sites, thus distributing my data for me.
I can literally be anywhere in the world and just do a quick search for keywords in my posts to retrieve my data.  And since the TGP public key files are also text representations of encrypted key data, I can do the same with my keys.
Stacks Image 245
I think this offers up some very interesting use cases. Normally, you want to keep your private keys as safe as possible.  This is still the case with TGP.  However, it is trivial to build as many private keys as you wish, to use for anything you want to use them for.  TGP Private Key files are password protected and individually salted, so with a strong passphrase you have very reasonable assurance that no one is going to get to your key any time soon.  The key structure is also build so that the password/passphrase can be programmatically provided “in-process.” So, you can create a private key with a strong password, post that, and then, say, encrypt a scan of your passport and post that.  Then if you are ever in a pinch while traveling or something of the like, you can simply use Google to find and access your data wherever you are. Of course, that’s just an example, but I think it illustrates the power of encrypted file structures like this.  You can literally use Facebook to post encrypted documents that you don’t have to maintain and use Facebook as a distribution method for you to securely exchange data without actually have to possess it. That’s really the main different between TGP and an application like PGP.  That and of course, TGP is free, and personally, I think PGP is tardware.  It’s bloated, it’s far too expensive, it’s hard to use, and if you don’t watch your licensing, you can get screwed hard like I did when I didn’t want to buy the extended support and one day my encrypted drives stopped working until I paid them.  That’s called “ransom-ware” and that doesn’t fly.  TGP also doesn’t require that you are an admin to install - in fact, you don’t even have to “install it.” I wrote it specifically to operate as a stand-alone executable that can be directly run without installation from any media. 
TGP Data Elements, Components, and File Types
Regardless of how "cool" it may be to have your data "crowd-sourced" (which I still think is quite cool), it is certainly not a use-case for businesses. At the risk of repeating myself, it is the structure of TGP that makes it a bit different. PGP, the commercial product, is actually used for major business encryption requirements, which makes me shudder. Everything is done at the "file" level, key files are compressed into single data-files, and it's closed source (now). Companies need a flexible data and key management paradigm so they can better manage keys, substantially increase portability, and have a general paradigm base allowing for growth, compatibility, and of course, security. To that end, the actual utility I wrote illustrates all these concepts at the "file" level, but should be thinking "API" in application.

Rather than just being a "Pontificating Architect" of a solution without implementing anything, I've actually built everything out so I could see what worked, and more importantly, what didn't. I provide full functionality in the utility so you can test everything for yourself, and see if you like it. To that end, the following are features, functions, and structures I've coded up for you.
TGP and XML
Though I've optimized block cipher binary chunking, TGP XML files are still limited to a (tested) 500meg per file.   It’s not a huge deal, but it does keep you from encrypting multi-gigabyte files.  However, I fully support direct AES file encryption (binary) where my chucking scheme works well - I've tested up to 3 gig individual files which I'm fine with.  But that's not what this is all about - it's about platform independent, vendor independent, location independent solutions for managing encrypted data. You shouldn't be working with massive files like that anyway. In fact, at the place I used to work, there were many people who worked with 1000-terabyte individual file structures. These "peta-files" were actually quite popular. At MSFT, I know for a fact that many people actually enjoyed working with peta-files. It was something about a peta-file and manipulating the Little Endian into messing around with the Big Endian's bits.

Anyway, the important takeaway here is not XML-based files and file-system limitations - Again, I only use actual
files for quick, one off encryption requirements; or when I need to post something to the web and have it propagated throughout the universe for me (which I still think is awesome). The main reason for my development of this project is to show how easy it is to properly implement encryption solutions for the cloud without going through a complete refit of your IT structure. And guess what - you won't be any more secure than you are now.

I take source data, and rather than reading into a memory-stream and out through a file-stream object, I create PostgresSQL query object which pull the encrypted data out of the memory-stream and into parameterized query objects which allow me to upload variable data through directly from a LoadFromStream. It's even easier than that with more recent getBlob functions. Note that this doesn't have to be actual binary data type information. I can just store base64 encoded binary data in the block and literally execute a "select encrypted blog from shite" command to retrieve whatever I want from the cloud and just search Facebook for my key. Awesome.
Complete Data and Key Portability
I think that offers up some very interesting use cases. Normally, you want to keep your private keys as safe as possible.  This is still the case with TGP.  However, it is trivial to build as many private keys as you  wish to use for anything you want to use them for.  TGP Private Key files are password protected and individually salted, so with a strong passphrase you have very reasonable assurance that no one is going to get to your key any time soon.  So, you can create a private key with a strong password, post that, and then, say, encrypt a scan of your passport and post that.  Then if you are ever in a pinch while traveling or something like that, you can simply use Google or Bing to access your data wherever you are. Of course, that’s just an example, but I think it illustrates the power of encrypted file structures like this.  You can literally use Facebook to post encrypted documents that you don’t have to maintain and use Facebook as a distribution method for you to securely exchange data without actually have to possess it. That’s really the main different between TGP and an application like PGP.  That and of course, TGP is free, and personally, I think PGP is tardware.  It’s bloated, it’s far too expensive, it’s hard to use, and if you don’t watch your licensing, you can get screwed hard like I did when I didn’t want to buy the extended support and one day my encrypted drives stopped working until I paid them.  That doesn’t fly.  TGP also doesn’t require that you are an admin to install. 

Key Management
Everywhere I write about "files," you should also be thinking the equivalent of "data fields." The version of TGP I use personally doesn't use files per se; the data is all stored in a database with the XML structures either stored (which is a bit cheesy, but it's faster and "bug proof.").

Key Management will be the most difficult part of Cloud Encryption companies will have to contend with. To be pedantic,
correct key management which produces tangible security will be the most difficult development enterprise. With TGP I use a set of API functions which I call "Rainmaker" to manage my keys. This gives me "anywhere" access to keys on an on-demand basis, and at no time do my fingers leave my hand. Nor do keys get stored on mobile devices and such. More on that later.
Private Key “KeyFob” XML Format
TGP allows you to build keys from 1024 - 16384 bits. The Private Key XML document contains the root KeyFob elements, and the following field elements:

PublicKey

If you have exported your public key, or if you have created a public key file from someone else’s public key XML, then a Base64 encoding of the  public key will be in this field.  If you have a “full” key pair created, the public key field will be blank.   Even though you always use your public key to encrypt files,  TGP will always create your public key from your private key pair every time you encrypt something.

EncPrivateKey
This is a Base64 encoded string representing the password protected AES-256 symmetrically encrypted private key pair.   When you load the key fob into TGP, your password will be validated and the encrypted key decrypted and assigned for use in TGP.

KeyHash
This is a SHA256 computed hash of either your public or private key (whichever one the fob contains) and is used for validation. If someone alters your private or public fob file, then it will fail validation upon being loaded into TGP.  You should always protect your key files to prevent people from tampering with them obviously, but I wanted to ensure that every time a key fob file was loaded that it was verified.  Note that in the case of a public key, the hash value is actually of the public key byte array before it is converted to Base64.   With a private key, I actually hash a byte array of the Base64 encoded key so that I can compare it upon load without requiring the user to decrypt it first.  That way if someone mucks about with your key, you’ll know before you have to put in your passphrase to decrypt the private key.

KeyNaCl
This is a randomly generated (by a cryptographic service provider) 16byte salt that is combined with your password to derive the key bytes used  to encrypt your private key in the key fob file.  This field is blank for public keys.
How to use TGP Features
The actual encrypt and decrypt process is fairly straight forward.  I attempted to make it as easy as possible.  In the simplest form, you load your keys (You use other people's public keys to encrypt for them, your public key to encrypt for yourself, and your  private key to decrypt data encrypted with your public key) and then choose encrypt or decrypt.  That’s really it.  More detailed instructions and suggestions follow:

Create New Key Pair
The first thing you will need to do in order to encrypt or decrypt data is to create a key pair.  A key pair is what we call a collection of a private key and a public key.  It’s actually a bit of a misnomer as the private key already contains the public key in most implementations, but let’s not worry about that here.   Public and Private keys are used for asymmetric encryption.  That means that the key one uses to encrypt the data is different from the key one uses to decrypt the data.  If you and I want to exchange data and have it be kept secret, we both exchange public keys but not private keys.  We encrypt data with each other’s public keys and send it to one another.  We then decrypt the data with our private keys.  With symmetric encryption, the same key is used to encrypt and decrypt.    As such, you can’t communicate the key in public.  If you use a password to symmetrically encrypt a file, that password is the only means to decrypt it – as such, it should be kept secure.  As long as you are the only one decrypting the data, that’s fine – but if someone else has to decrypt it, you’ve somehow got to get the password to them.  You might be thinking, “Well, just use asymmetric encryption for everything and be done with it.”  One day we’ll be able to do that, but as it is today, asymmetric encryption is “expensive” - it takes time and processor power to accomplish due to the overhead of multiple keys being involved in the process.  Because of this, there is a limitation to the amount of data that can be asymmetrically encrypted, depending on the implementation.  This is where symmetric encryption comes in.   Symmetric encryption is quick and easy (relative to asymmetric) and we are not limited in the amount of data we can encrypt as opposed to asymmetric.  However, we’ve got the “how do we communicate the password” issue noted above.  The answer is to use symmetric encryption for the data itself, based on a very large yet random key and initialization vector.  This key and IV are used to decrypt the file.  To protect the symmetric key, it is asymmetrically encrypted with one’s public key.   On the other side of the operation, one uses their private key to decrypt the asymmetrically encrypted symmetric key.   When we talk about public and private keys being used to exchange data, what we’re really talking about is using private keys to decrypt the “secret password” which is then used to decrypt the actual file you are using.  More on this later, but for now, you’ve got to get your keys created, and the New Key Pair function does that.  When creating your key pair, be sure to use a strong passphrase to protect your private key because that is what will be used to access the key used to symmetrically decrypt data.  It can also be used to “sign” data validating that your key was used to do so.

Here’s what happens technically:  An RSACryptographicServiceProvider object is invoked, and key pair is created.  The default size is 2048, but TGP supports 1024-16384. This key is then exported from the RSA object to a byte array, and is finally converted to Base64 and written to the Private Key Fob XML file as per the above file format.  However, before it is written, I invoke an AES symmetric cryptographic provider to symmetrically encrypt your private key data using a password and salt.  The salt is a cryptographically strong random number that is combined with your password to derive a 256 bit key used to symmetrically encrypt the private key.   The reason we do this is to further protect the strength of the key derived from the passphrase to thwart Rainbow Table attacks.  “Rainbow Table” can mean two things: one, it’s where Dan Kaminsky sits down for lunch at a security conference, or, it is a collection of pre-computed values derived from a set of characters used for brute force attacks against passwords.  For purposes of this paper, we will be using the latter definition.  If one has an encrypted key derived from a password, one can use a pre-compiled set of all possible passwords to attack the password.  The attacks are costly (from a storage space standpoint) but can be successful.  A “salt” is used in combination with a passphrase to randomize the bits.  The salt is therefore required to decrypt the password, and there are a couple of ways to go about handling the salt.  One, it can be obfuscated somehow in your program, stored separately, or actually published.  I publish the salt used in each key fob.  Yes, one gets the salt used to accompany the passphrase, which can indeed be used in Rainbow Table attacks – however, one would have to generate a complete set of rainbow tables specifically for that one key fob.   To give you some perspective, a rainbow table to create all possible combinations of uppercase letters, numbers, and symbols, for 1-7 characters, is something like 64, 64-gig files according to the rainbow crack people.   That’s with no salt.  A 16bit salt increases that that to 2 to the 16th.   How big is that?   I have no idea and I don’t feel like figuring it out, but I know it’s big.  A 12 character passphrase consisting of upper and lower case alpha characters, numbers, and symbols (like (*&) in combination with a 16bit salt is really, really big.  And that’s just to get the key for the one fob you create.  I’m good with that.

So, where were we…  Ah.  You create your private key, and that gets encrypted with and AES-256 encryption algorithm, based on your passphrase and salt.  That binary key is converted to Base64 and stored in the XML file.  As noted previously, a SHA256 hash is computed against the private key Base64 string and stored in the file as well.  I do the same thing for public key files, except there I hash the binary data before converting to Base64.  This lets me check the private key for tampering before requiring you to enter your password to open it.  Somehow that seems better to me.   TGP also weighs your password against hard cracking metrics to provide you with quantifiable statistics on strength.  That is covered above.

Make sure to label your key files so that you know what they are.  Even though the private keys are encrypted by a passphrase, there’s no need to give it out unless you want to.  I name private keys in a different way than public keys from other people (or myself).  I have many private keys that I use for different things, but that’s me. Once your Key Fob is created, you are ready to go.

Load Key Fob
Load Key Fob opens a key fob file.  This can be your private key file which you can use to encrypt data for yourself, or decrypt any data encrypted with your public key.   Note that if all you are ever going to do is encrypt, you don’t need a private key. The private key is only used (needed for) decryption.  If you are involved in a process where you simply secure data for other people, all you need is their public key. TGP automatically knows what kind of key you’ve loaded.  If you’ve loaded a public key, it will tell you that, and only allow you to encrypt data.  A private key will let you encrypt and decrypt.  If I want to encrypt data for other people to decrypt, I’ll load their public keys and go nuts.

When a Key Fob is loaded, the hash of the key is checked against the stored hash, and a newly computed hash based on the bits in the file.  If someone has changed public keys from what TGP created, or is otherwise screwing around with you, you’ll know it.  If a person’s public key doesn’t match the hash, I’ll still let you load it and use it to encrypt data for them, but I have no way of knowing if it is valid or not.  I figured this would be good in the case that the person decrypting the data didn’t use TGP to create their public RSA key.  While the file format in TGP is unique, everything is based on industry standards so you can theoretically do whatever you want with the data.
Export Public Key
This function takes your private key and parses out your public keys and stores it in an XML file for you to give out as you please.  Others can then use your public key to encrypt data that only you can decrypt with your private key.

Key DropBox
This function is pretty cool.  If you get someone’s public* key off the internet or via email, you can just cut and paste it into the Key Dropbox field and hit “Create” to validate the data and create a new XML public key file.  If you trust the person sending the key to you, you can of course just save the file and a .fob and be done with it.  However, the Dropbox parsing function actually validates the data, checks the hash, and creates a new file for you.  It also parses out those irritating “-“ signs that IE puts around expanded XML Nodes if you used IE to view it.  I’ll work up more little functoids like that when I have time. I know functoid isn’t a word, but I don’t care. I like the way it sounds. Funk-toid. Yeah.
Encrypt
This is where your data is put into a magic blender with tequila so you can take advantage of it. Actually, this is where you’ll select an input file that you want encrypted, and the destination file name.  By default, the source files are “*.*” and the destination files are “*.tgp” but you can name them whatever you want to.  TGP doesn’t change anything about your system or the files association.   Ver 1.2.4 introduces an "Auto-generate filename" feature to predict the name of your output file.  This makes TGP/AES file generation easier.  Note that when this feature is enabled, existing files will be automatically overwritten, as opposed to the Open/Save dialog that warns you to overwrite.  This works the same when decrypting a file, enabling you to easily decrypt a TGP/AES file to it's original file type.

Decrypt
This is where you’ll select the input file, typically a “*.tgp” file that is a valid TGPContainer XML file and decrypt it to whatever file you want.  Ver 1.2.4 introduces a "Launch file on success" feature where upon successful decryption, the file is automatically launched by the associated application.
Use Cases
What I think is cool about TGP is that you no longer need to be the custodian for data if you don’t want to be.  You can just paste your encrypted files wherever you want around the world in emails, Facebook posts, blogs, etc. 
This is an example of a TGP Private Key XML Fob file. The key-data has been trimmed for brevity.
< ?xml version="1.0"?>
< !--TGP - Thor's Godly Privacy: KeyFob XML Document-->
< KeyFobs>
< KeyFobName>TGP< FobName>PrivateTest< /FobName>
< PublicKey>< /PublicKey>
< EncPrivateKey>
193PM88EjC/C7DtVH/UWzI9ALhLyxr/vbeV95vGvVPlw5KKH3szdnzCMs7cFWC7Hq2vqxIVwIDMrp9fG43m
DxX9rFbv2rEKMTKLXnW6dMSdJbfCN1AOI+jCsv+9pm7bcbSCRMaOJZoXUHjZiW1gpunUqi0zgbXYo10WGZJhfYa1uL9x4NuUjZ9P
aN2EJpgpzlxDEmTWpaAomKk/3gd4TAo+iM53XX3uwwL0g8yXWqgllZRLZS9u5jS6ZPzNwhy8n4+FER7as4IpDZwOjg9vKNyBPYNN
SpiCH2dzuhJR8Rj+LJcTTgzNsVNo2zSq9BfdTLZNsV5g2l/2PTecA9DbDWrDQHBmMbSIbxqBLtxD+kVUm1XPf1C/5bhfbuZroCXG
HejuPP2x9KRWjb7en7GFnC9u3BE/92qOxJO1x98pdYn3HS6QkmJKM1cvHhoxrowT8T87YEjK6o3J6s36xKW6kzTVS6AQMS8CfAb2
VMfYMuDk2SsJzkZvhOylsJNYmLrd9TuGOh7XTDqi5GjT9Bg2rPFImxuuB5Y1kSag9Po2FKAfHIfxmDzPQQDo7wyclN5yrGmVCJOZ
YvvrSwCn7MBZM2qI/fZnuQp6SsbwyCznDub2wtx+Yjz4hoYnmDd3B2uY11WZ8Fd3NOHV9vcNhEfr2gjCyJoaSK2chiz1BJGWlI85
VfdumNw1bINQMdSfJDw7ViHlmWuOlDaJHQY2soeI/mSB8Wem7551iS//jN4iCM8yJ0RDKay8d4HHRdGFyy4zGMVByzTOyAqH3k90
0+nymbaksnQireZH6YIGNd2WutE2R/2/fGmDR0YebA4dP7KJ0NzKnLzFYnCY/WR9oxdKRHCa8pY1xvs+V722+qLHmI97bKkxWEnY
zUvcKUeOj2gHs0Qw9z0QxcMqe0Pp1k8ZqoSBqO7T4j3LHDkwwvfe8kp6ve9QhksYLnqI/5Gegu7/lz1srwFo8+kbAMns/O55h5IS
C9fX08hg1YZzAdoyDsefRu5dAwOfOeXKVmVkbIUcEASm5/8k1gvdDEDy6gBl0u1xLOGYK0i3liyLlOgWbPA3iEmYsGZyorRKn5q2
Fd3sQXm98l6IV/hGoevr4zRFrWktiCnh5QG5viy4NcoqCcgkU514v4RUMjQMytEKQhGgTOoJdAdutlD8B0nQ5pYExcecamlMhWwj
LtnepAzfJbs4WQziLSUijK+BtnZVujpihFDkz2ZFMIcOiVaKLtl1kU2uBCziw2WrBsq37CyzZZRhr9vNd4PWO6QBopPq4pPTM3ll
TYtYz3Fgoc46cfwmVKGOQkJdSJzD8vVKj8BdguLGLf4s0IQrxncLWGjOAic4nz7xKxqz6wIUzgkisO6QMZ/T3lXZTTdP9pTyEnyd
378ceEjr442a+B22QYoD+TpDCT0gifrku6BBjpdsUoRENqC/bRqGY+qtIZr3EcGHroop60TlxSnIrBDqqX1lywn73uKu4Uge+A1/
N6q12qBzufV0YX3BfFKWe7wEiz7tjUj9U+NmtbFHGqe9n4ngE/BdmTGmYACEVnUSnaaRSGq1KB5bPAb/os4yaSxFkild+4p0ASX6
GmydQM+g+/
< /EncPrivateKey>
< KeyHash>2w2VMX86mHXzPwvRgfj/Nq/UUfsTGUcRHSPiE2UHFns=< /KeyHash>
< PublicHash>uTv/7E0oAF95nX6n55q0mpX71NBR1qFR9Ln9FYK18Jw=< /PublicHash>
< KeyNaCl>7axIg9wHwSx/Xy9MK/g36w==< /KeyNaCl>
< /KeyFobName>
< /KeyFobs>
TGP Public Key “Key Fob” XML Format. As with the above, the key-data has been trimmed for presentation.
The Public Key XML document is of the same format as the Private Key XML document, but only uses fields as necessary. 
The following is an example of a public key XML document:
< ?xml version="1.0"?>
< !--TGP - Thor's Godly Privacy: KeyFob XML Document-->
< KeyFobs>
< KeyFobName>
TGP< FobName>Thor HoG< /FobName>
< PublicKey>PFJTQUtleVZhbHVlPjxNb2R1bHVzPnRCck1PMmRPUGd1RkJUbjRZNlJvYkNQVkdkNXJxR1FsMWxNSW1FVHNXaE5G
ZUa1A3SkNTWlFoTXNEY3lNS2cyamZSRUV0b05vSENyZG01cVdsQmRibWVPZTlNM3NUdWFKcVF4cDFIS3BEN0pvSXN2QTVxSFVSZ9i
YTdUT2IyeW8wR3VneDNkcis0amtGVHl1ZnNJeUJ4RHB5VUJxTysrK3hEMXNJRFdCK3paTWU3ZUpzNHVub0NwZklwMW9rNkdJSC9Cd
ppMWNwc0IvdWhERjI4V2F6dWVOdz09PC9Nb2R1bHVzPjxFeHBvbmVudD5BUUFCPC9FeHBvbmVudD4VZhbHVlPg==
< /PublicKey>
< EncPrivateKey />
< KeyHash>gP6RE28PFeaa8lgMBJWsLvSbOk3n1jsjdHlk/7THgDY=< /KeyHash>
< KeyNaCl />
< /KeyFobName>
< /KeyFobs>
Encrypted Container XML Format
The Encrypted Container XML document is contains metadata relating to your encrypted file as well as the encrypted data itself.  It contains the TGPContainer root element and the following field elements:
  • RSAPublicKey – This is a Base64 encoded copy of the public key used to encrypt the file.  It’s not actually used for anything other than identification of what key was used to encrypt the file.  The data is not consumed in any way once the file is decrypted.
  • KeyName – this is the textual name given to the Key Fob used.
  • EncryptedAESKey – This is the Base64 encoded RSA -2048 asymmetrically encrypted key used to encrypt the data blob itself.  When encrypting data, an AES-256 bit symmetric key is randomly (cryptographically strong randomized key) generated every time you encrypt a data file.  This AES-256 symmetric key is asymmetrically encrypted with an RSA-2048 bit key derived from your public key, and the resulting byte array is converted to Base64 and stored in this field.
  • AESInitVector – AES not only requires a key to encrypt data, but also an initialization vector (IV) for block cipher operations. In standard cryptography applications, the AES-IV is not encrypted even though it is required to decrypt the file.  For added security, I actually encrypt the AES-IV bits too because, well, I just felt like it.  It too is RSA-2048 asymmetrically encrypted with the public key of the fob. 
  • CrytoBlob – The CryptoBlob field is a Base64 encoded string created from the actual AES-256 encrypted data stream.
  • BlobHash – The BlobHash is the Base64 encoded SHA256 computed hash of the CrytoBlob byte array.  This hash is recalculated and compared to the data blob during the decryption phase to check for validity.

< !--TGP - Thor's Godly Privacy: Encrypted Container XML Document-->
< TGPContainer>
< RSAPublicKey>
PFJTQUtleVZhbHVlPjxNb2R1bHVzPjJkWVdFWjNNN1R2TXdlV2V4M0ZrWDkxp4UTnJkOW< /RSAPublicKey>
< KeyName>Timothy "Thor" Mullen
< EncryptedAESKey>PZpkcVvpogLL4tFOEl69ZL2f15L4O9/GpL/a6b4ZdwNW4pCrgMYKGQ6AHqfdSI=< /EncryptedAESKey>
< AESInitVector>1F7HbYzuj8cNym8p7IRlxJ2nzlbplaTg2U0LuEaVTZZcojygfZIE+8CrkdJCBvGBmWfpZ+FUC3a8PZs6yn4s/tU
QIUVSKqhXm+a/oCtRcq0DwD5tdGH/r8vskcK2IoKOJJyRaNR0Mh/g=
< /AESInitVector>
< CryptoBlob>tZB5BygrPW7tqqBiC0c1x8ZYV3rTru0guvVi0ltoglzRHv6QTJK1j82EF9CLiLCglZvATUesLUNbsJ8cTGAFhmlwt
bwY3CoOwEKq5QastZBQc857iBAkz2Y8WEALM6VEcAWr7BLkrMQQdkNk=
< /CryptoBlob>
< BlobHash>ZrhkKpe8hZ6Izz+2Um5V2YJ+/6lmw4mGq4oDly2uE/g=< /BlobHash>
< /TGPContainer>



Current Revision History
v2.2 - Current Stable Release
There was some pressure from external influences to remove the Rainmaker API. Apparently it’s considered “too easy to be leveraged for abuse.” That’s obviously untrue, but I removed it anyway. Not because of the pressure, but because I’m working on bigger and better API calls with the ability to automatically format disparate data sources into proper XML tags and will include sources such as Facebook and Google. It’s awesome.


v2.1 10/20/11 Internal production version released after several revisions from v2.1.
The below statement regarding v1.2.4 being the last Windows release has obviously been revised. I felt compelled to provided continued development for the users who depended on my support. The major revision update is due to the inclusion of sample Rainmaker API server-based key management code. It also contains the first TGPWin version for Windows Mobile.

Created Rainmaker "Cloud Key Management" service

Created TGP Mobile, a Windows7Phone TGP Client

Created handler for incorrect password when decrypting keyfob private key

Included internal routine for assigning AES encrypted data to a base64 encoded string for future Base64 AES output options.

Fixed CryptographicException catching to better accommodate incorrect password entries without kicking the user completely out of TGP. I needed a better balance of "user experience" without enabling brute-force functionality against password protected private keys.

v1.2.4
The v1.2.4 Release will most probably be the last TGP development on the Windows platform. All listed features are in and tested (gold). I will, however, add one more feature set which is to consume Open-SSL public/private .pem files. It’s easy enough, actually since they’re just Base64 encoded binary numbers. But going forward, all development for TGP (and hopefully all other HoG tools) will be under OSX and Linux. The reasons are actually pretty severe, but I’ll get into all that later on the HoGBloG.

Added single-file AES256 encryption functions for binary encryption of files outside of the TGP KeyFob/MSL framework, using user-supplied passwords instead of RSA key-based AES key encryption. It's your basic "password protected AES256 encrypted files," but it actually has a pretty decent use case.

Added file/text hashing capabilities for MD5/SHA1/SHA256/SHA512. You select an input file or paste text into the generator, and select which hash message digest you would like to generate. It's quite helpful for, um, whatever you want to generate hashes for, I guess. For instance, I use TGPWin to get a SHA1 hash of itself to post for signature verification.

Added block cryptostream buffering in order to support very large AES file encryption (tested to several gig). This is not yet possible for TGP XML files due to the complexities in creating large embedded crypto-blobs inside XML text files.
But I'm working on that. However, I did optimize bitchunking as much as I could in my current generation framework and have not problem with generating 500 meg TGP XML files. That's pretty big for a single file, so I'm OK with that for now.

Added "Auto Complete" function to predict decryption output file name and auto-populate the OutFile variable. Note this function automatically overwrites existing output files by design. User toggled.

Added "Launch File on Success" feature to automatically launch decrypted files upon successful decryption. User toggled.

Added multi-threaded operation for AES cryptographic functions, and updated "ThreadUpdate" status capabilities to track multiple threaded operations throughout lifespan.

Oliver noticed what I thought was a 96 character base was only 95 for the password strength meter, so that has been changed.

v1.2.3
Added full support for Microsoft x509 Certificate public and private keys to use in addition to TGP KeyFobs. This way you can leverage your own internal x509 PKI infrastructure if you choose to.   Note that this is for encryption-only applications.  TGP doesn't (and in many cases couldn't even if I tried) look for CRLs or check for certificate validation against your CA.   Earlier I considered adding those capabilities, but there is already a robust collection of certificate-validation applications, and I strongly doubt I could add any value beyond them.

Keith Langmead, a fellow member of the Security Focus MSFT, noticed that a test password, in this case
53dsfkzabwvg, was showing a higher number of iterations than the key-space itself.  The problem was in the way I had coded the character base set - I was treating that password as a base 62 password while the key-space was checked against a base 36 password.  I've fixed that by explicitly carving out different base character sets  for my indexing as described in the password strength section above.

Omar, a TGP user, noticed that if a key was loaded, and a new key was selected but an incorrect password was given that the "Export" command button would stay enabled from the old key's availability. This has been fixed. Also, as per request, if you hit "Load Key," any existing key is explicitly unloaded. So if you go to load a new key and cancel the operation, all keys are still unloaded.


v1.2.2

Fixed a reference to some VB libraries that do not exists (they never did). VS had loaded references to some VB Power Pack that caused install issues on some machines. Thanks to Daniel Bachfeld for the find. - Changed hyperlink references to http://www.hammerofgod.com/tgp.aspx from the old html page.

v1.2.1
Fixed version references (nothing worse than having to build a new version because the old version references were not updated).
Fixed parsing issue with certain key usage type public-only x509 certificates that you probably never even heard of anyway.

v1.2
Added full support for standardized x509 certificate public and private keys to use in addition to TGP KeyFobs. This way you can leverage your own internal x509 PKI infrastructure if you so choose to.
Fixed crypto-stream flush issue with tiny source files to completely flush the output buffer with very small source arrays of a few bytes. RECOMMENDED upgrade if you were encrypting really small input files (as in only a few bytes).

v1.1.13.4
John Lightfoot was kind enough to look through my logic and found a bug where I didn't use the right base when A-Z were being used in the strength check of "my password."  I've fixed that bug.  Thanks John.

v1.1.13.1
FxCop (A code analysis tool) was having issues with my use of try-catch-finally for some specific object types in regard to Dispose() calls. No bugs, but just suggestions on better ensuring properly formatted and clean code. Thus, I reworked my logic to encapsulate logical groups with Using instead. Much tighter, and it looks better. Extended combination code to support really, really big numbers.

v1.1.12
Added new "Password iterations" function to not only test for how long it would take to brute force the password key-space, but how long it would take based on the actual password you enter. Another one-of-a-kind HoG feature!

v1.1.11
Created PasswordStrength routine, wrapped more methods.
Added thread counter to shine up UI when building  multiple keys simultaneously.

v.1.1.10
Wrapped OpenFile and SaveFile under TGPVar class.
Moved many string refs to resource reference.
Wrapping of try/catch/finally on a few routines.


v1.1.09
Added multi-threading offloading for key generation.
Fixed shared out-filename issue when generating multiple key files simultaneously.

v1.1.08
Added support for selectable RSA key sizes from 1024 to 16384.

v1.1.07
Added signing with strong name/assembly key.
Removed custom error for decrypt.
Code tested for and marked as CLSCompliant.
Marked attribute for NeutralResourcesLanguageAttribute (US English)
GUID 9468f889-3851-4698-8754-2a989ba7f0ac assigned.
Replaced all =="" with String.IsNullOrEmpty.Full check for Flush/Close/Dispose and object Dispose.
Stacks Image 194