TGP – “Thor’s Godly Privacy Individual Security in a Cloud Environment"
The Password Strength Checker is now living on its own, and has been moved
(along with the docs) to
HERE.
Revision History (Back to
Top
)
08/07/10 v1.2.4 - Beta (RC) now including
x64 bit versions.
- 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 SHA256 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 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.
- 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 my "ThreadUpdate" status capabilities to
track multiple threaded operations throughout the operation lifespan. For
example, if you launch a 16k Key Fob generation process, which will take a
while, you can now go and AES encrypt a 3 gig file while that is going on, and
while THAT is going on, you can TGP decrypt an .xlsx.tgp file and launch Excel
with the decrypted file. When the AES encryption is finished, TGP will let
you know that you've still got a background process running (the Keygen).
If you try to exit, it warns you before you orphan your existing threads.
Here's a screenshot of the new
hashing functions:
|
There's no need for me to go into what hashes are here as if I had something to
do with coming up with them. If you don't know, then
let me
Bing that for you.
These functions allow you to select an input file to calculate a hash against,
or by typing or pasting text into the Input Text box. TGP supports:
MD5 (128 bit /16 bytes)
SHA1 (160 bit / 20 bytes)
SHA256 (256 bit / 32 bytes)
SHA384 (384 bit / 48 bytes)
SHA512 (512 bit / 64 bytes)
It's no big deal... in fact, it's a rather basic function. But I wanted to
be able to easily provide the hash signatures of my .exe's so when I wrote the
app to sign my apps, I figured I'd include it here as well.
|
07/15/10 v1.2.3 - Current Stable Release
- 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 keyspace 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 keyspace 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.
07/13/10 v1.2.2
- Fixed a reference to some VB libaries 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.
07/09/10 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 certs that you
probably never even heard of anyway.
07/08/10 v1.2
- 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 so choose to.
- Fixed cryptostream 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).
06/23/10 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.
06/22/10 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.
06/21/10 v1.1.12
- Added new "Password iterations" function to not only test for how long
it would take to brute force the password keyspace, but how long it would take based
on the actual password you enter. Another one-of-a-kind HoG feature!
06/19/10 v1.1.11
- Created PasswordStrength routine, wrapped more methods
- Added thread counter to shine up UI when building multiple keys simultaneously.
06/18/10 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
06/16/10 v1.1.09
- Added multi-threading offloading for key generation
- fixed shared outfilename issue when generating multiple key files simultaneously
06/16/10 v1.1.08
- Added support for selectable RSA key sizes from 1024 to 16384
06/15/10 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
- replaced all =="" with String.IsNullOrEmpty
- full check for Flush/Close/Dispose and object Dispose
About TGP (Back to
Top
)
TGP is a small yet very powerful encryption utility. With all
eyes on “the cloud,” I decided to write an encryption application better suited
to an environment where
portability and 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 a
“file server” is becoming more and more ubiquitous.
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 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.
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: 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. 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 travelling 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. However, the .NET installer
for the 4.0 client profile does – that’s not my doing. Regardless,
here are the file structures TGP uses:
Things that still (only kind of) suck about TGP
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 a gigabyte file. 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. I'm building a current beta where I'll
use a different streaming method to increase filesizes.
Private Key “KeyFob” XML Formatt
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:
KeyFobName – A “friendly name” you
give your key fob. This will be displayed on when you select
the fob and it will be listed when you create encrypted TGP files.
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.
The following is an example of a private
key fob XML document:
<xml version="1.0"?>
<!--TGP - Thor's Godly Privacy: KeyFob XML Document-->
<KeyFobs><KeyFobName>TGP
PrivateTest</FobName>
<PublicKey></PublicKey>
<EncPrivateKey> kUnv1MSq305Ebj8lSJbdMhJ03/mXU/eUrydhzbdrlksE2zwpdfnfuWbUXb4Tz8BibUXI3drAMx1llXwCArSP9zKblfOB78owYLp1haY8+yx+Zh
KLv0s7y7WpdKdFzQxNeOBCdsz7mIUwgc8rGsyl4/3t/rA04IfkyZHRPwXpOz5YBnTHaVoo2gSZdR6xGk27Tq59PZNsb+z2BiMozKA6s3vXY/mKzPoMhm0hpOPCxx6H
o2QmYJHuPbOr2tLlFr6ICPyiAWZFw/g+qNBDST0LrQVHh6R0yAu15mo7L2R5WlERhOGTx8+/Y7pXWvH1sqxnLKUZ6sEqt2+zlW0lUYyvvpgDTabOvuHmsvZz3Wthvd
V8C0iManQkmSHQpaDKkzuYc8wv3Zz7uHbLTupEBA3MEckNXLvIwFRG6KGetLVG43Nxj/vhXQJjrBTEXB6Cnaf+Q+AKwhPDRv8e5lRcHoGK8jB59uLRx3DKUg6NC70Xr
4do0sSWGCNdOtEVMVZuARiHgEtzzRnabQJDn6f8Mc2S+HKOvLxBnG4SBdYu1uWE/s7z8ygn8ROqWv5EN2R5Yo46ihB4NTHOg5CgiNO/QDTaXPqqMR1V7sVvdRLiME51
X0fn/EFqD2+BmetpyiAb/QRQZvjHYkZgSi06nMTZ0u847nMnerlAsleak3NJuLH3au2YMIQ9UIMrUSWrtFsU99Xljje5lnQ2hKnwZUe3xpmXmo2Mm+3KOmw0/9cir
HemcL9wcMd1ywCQjWwvcug+yIjU8UseLKtrH2se+VZB3EjagpH1SKOtroyH29lOrg45Q25EkE1Pk0xF+CdOL4pEmBFzw5Gxw6vkEzmWmMwmeCLKYD+dPP9TqsQM1V7
czKeV/zUL3hSeO8svJdNHbNCN4fWI5STtEvdhSLh41S39HbIVOQbhAjAoD7LalhQRiTugkLLuqtmF8amGyAHmGA9aAldE0U28DHakcAKRWSPUTEluvWSTcnREgIpKA
f7WSpUYqWq53Ht/c6HiZ2S+RgW4N8LCpIR8VCyxkfW46wzQVgurPP/UiddBZmzG0KpbYmktXNfb5L6SiECEpXfPQSoqjVqX7QYC/YjcvVUhIbtTddNJ8Tpsrno55g
q+3fSx7nmKd1SDjjGl7z+2or/2d9GRe063ZnYg7GNjqjYN/wDZIuROUhKGYKF5+JhMU7UNZuuGy6P6NSWdJNwvnRcUu7WPOWO4WZocDmsY98PuvQt6FGjn+yIi3xYl
NkvajxZDiAUUapM9CJssi1cmdpLasaCGdvKnXdDBQBGGdmHZuvkWLKGRIp6h1hTqlnt1Rne+04JaaQ4wGxxt4pKyVZoJinS35rrLuIsCr9Pa2HcSHUWcLMhG3Qpt7a
uZBU2m50EPNtqLgFGx8CQmGRD9EiLN/fqjc9j+GWWT/BeJrYXBUgkPWHTaDyIm+okMEQue1Zl59UYxFKhUeCM2b8PksoDWn851lgFO5EjPZ9mbGny9OAE9Wzxdmpqn
Oaq6qYxuusg/9H/heQ6IjydPhUhH5FZl+e7q/n+nLDtuXjgkd/776T0SohGqIA88TKFNba9LpyhDKOO26uaK1GpGb/4gRgs+kLTdd2AYfW1u8nWO1Ug3/7WZ89inBy
JNtI5eHqyxPl7cTVl3WhSuGLcxfQnb+ajx8yZpBhrNtz7jC4T8xZm8rh2FVhV7Qu4l3VosSJh/giSrGmC55Mau9X1/K2tsDJuPOLibK3ZYSi4ZlAAuktLBDjomX3db
fNuvK5FthP+rjvfVAg8bRHvReTnsQ/cA2iMW11blCE42HcnSyq/ulFkch+Y6vlSNhNR+Crh5nXrXixaFDcA8hO3PjPHp5ocRGbZMXtBf3xptrFmfga9nMvzdJS5Vmin
YHlV4kgh7HK8L+uh38UqVir/Dusj9JtJMxYzVZWmAqO2JO+rKdPdzXNEm896O/uF6zlgoHIG64HRE8I+NAyxxew8rN5lyIWFqhsx058sGsIiWoX7yAL4CIY8mgSsP4
tR2wzBh2UhSlqwdSsUt/Flkk/cwS+8jrkIGxLDNHvcRqFlrH3iydqkz3LwUCproQrNZQ7sI2Wjmcsw+bETAVvRQhkvYdxUghGxZqM5MxjonuUrZ1fNWxFkQsaa9gJ
u1TK7lGIXtSA2RkS2HwYBNpp74fYpLiKSTeRMeMdmrClQ3CdHjv1epn6TZrqFtpvaMwVb5EbSzBSzmkSIKGtkP6ZOD6vItsp1Lkpvx0XeIEgY3sACUS+RhYiLxZF1X
EDQXxbyNNl28XeQmL/v3qq3NlyviO8NqfttLHyl7tRc3Llx0LBjc2d34CEXFB19aFj2LHNG7Y1lpgOjKYjxRsFyy3I9Q3d3TUKWXqbgATYdc3UFT0OyRVXuFK2CRKO
0T1JjH30m58RRw29Zsn6BLKxIPavwLD+MVxSeukYhD4Vr3j/Ke/yyklJMTpNqw+UQey9+Xu3hoVw==
</EncPrivateKey>
<KeyHash>ir3Co+lV+P6GnGKKlCOeKOtyex/b0p2fNHgoIhuW9Ek=</KeyHash>
<KeyNaCl>d9OkMGXGWswbSqhxw2VsUw==</KeyNaCl>
</KeyFobName></KeyFobs >
Public Key “Key Fob” XML Format
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: Public KeyFob XML Document-->
<KeyFobs><KeyFobName>TGP<FobName>PublicTest</FobName>
<PublicKey>PFJTQUtleVZhbHVlPjxNb2R1bHVzPjJkWVdFWjNNN1R2TXdlV2V4M0ZrWDkxR285bXpWOFp6YkZNQnNVckRtMjNReXZ5dFNhWk0veE5WT3hQTnFwMF
hmd0ZZazQvdWpUTnJkOWt0TkRubGN0Y0dFL2hGQ1YzeTJMV0d5L2dTY2hFTUt4bUVjbk80KzVycnJNWnZlaFFmVUE5U1R0bDdWenNOTjJjdnpGOUlRY0lyYzdubHd
iZ0JrcnZLNFFIRktVTT08L01vZHVsdXM+PEV4cG9uZW50PkFRQUI8L0V4cG9uZW50PjwvUlNBS2V5VmFsdWU+</PublicKey>
<EncPrivateKey />
<KeyHash>iqnUIFKJpEpE1+Bj9chX7727d0W7gqIDUZrKAG0n3I0=</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.
<?xml version="1.0"?>
<!--TGP - Thor's Godly Privacy: Encrypted Container XML Document-->
<TGPContainer>
<RSAPublicKey>PFJTQUtleVZhbHVlPjxNb2R1bHVzPjJkWVdFWjNNN1R2TXdlV2V4M0ZrWDkxR285bXpWOFp6YkZNQnNVckRtMjNReXZ5dFN
hWk0veE5WT3hQTnFwMFhmd0ZZazQvdWpUTnJkOWt0TkRubGN0Y0dFL2hGQ1YzeTJMV0d5L2dTY2hFTUt4bUVjbk80KzVycnJNWnZlaFFmVUE5U1R0bDdWenNOTjJj
dnpGOUlRY0lyYzdubHdiZ0JrcnZLNFFIRktVTT08L01vZHVsdXM+PEV4cG9uZW50PkFRQUI8L0V4cG9uZW50PjwvUlNBS2V5VmFsdWU+</RSAPublicKey>
<KeyName>Timothy "Thor" Mullen</KeyName>
<EncryptedAESKey>zK2fdQN9kiqwVU0k2qcidNn35AC93XBmU6hkYShmK/g7uGWBVpM8fyix1Ty7JPizrtN43MKvi2TyRqYcAYhCw/Y+7GrumFjyoch+/gCDG6yt
CXPKR1AUGQ6Y7AZpw7+vw7tyv2m53XIqjU4KF7MAqHX0f/rGK8dZoLktefWwM8c=</EncryptedAESKey>
<AESInitVector>zDwSsCdah5R6jtiBjDPZjKbo5FakibSpULMzWXr69gBzHc0wh1Cm9oGgUd+v9isKGj7GtB96lgAcb4/WgKM0vEofIHkDoA3bO7q5aL5jRDUs/
p/pB7PCOcFFYNSdfO+WP8gkfad+aNKglCEbRPukPjakDEtDdzZFc3YJiOJDXT8=</AESInitVector>
<CryptoBlob>0a0eiwVi0uqhjsq0ypokBg==</CryptoBlob>
<BlobHash>suf4bdbu2jX1bs/CapPeGvtcQZMD42p7ujNw0aQTG0k=</BlobHash>
</TGPContainer>
How to use TGP
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 than 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 Dr. Wright 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 algo, 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.
One 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 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 knows that 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 functoid like that when I have time.
*this used to say "private" but that was a typo.
Thanks Jeffery.
Encrypt
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 "Autogenerate 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.
Comments welcome: thor @ hammer of god.com
Get Hammered at Hammer of God.com
Copyright notice, legal crap, and other
sports stories:
Copyright 2001-2010, Timothy "Thor" Mullen, Hammer of God
Permission is hereby granted, free of charge, to any person obtaining
a copy of any HoG software from this site and associated documentation files
(the
"Software"), in all of its awesomeness, to deal in the Software without
restriction, including
without limitation, the rights to use, copy, modify, codify, notify, eat, merge, publish,
polish,
distribute, revoke, sublicense, sublease, sublime, subsandwich, and/or sell
copies of the Software,
even if your greedy little ass doesn't give me a fair share, and to
permit persons to whom
the Software is furnished to do so as well, subject to
the following conditions:
The above and below copyright notice, and this permission notice, shall be
included in all copies or substantial portions of the Software. And it
would be nice if you named your kids "Thor." Even if they are girls.
Idiots are not
allowed to use this software, except in the case where they are voted Tard Of
The Month
at your local HoG franchise. No, really.
You also cannot use this software if you are a terrorist,
or other sort of sketchy scumbag who is up to no good.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR IMPLIED, RAW OR FRIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
MERCHANTABILITY, SELLABILITY, HILLABILLITY, FITNESS FOR A PARTICULAR PURPOSE,
UNFITNESS
FOR ANY OTHER PURPOSE, THROWING A FIT, AND NONINFRINGEMENT EVEN IN
CASES OF
FRINGE INFRINGEMENT OR
GENERAL IRRITABILITY. IN NO EVENT SHALL THE AUTHORS
OR COPYRIGHT HOLDERS,
ME, ANY OF MY PERSONALITIES, OR THAT CHICK AT STARBUCKS
BE LIABLE FOR ANY CLAIM, DRAIN, PAIN, SUFFERING, DAMAGES OR OTHER LIABILITY,
WHETHER IN AN ACTION
OF CONTRACT, INACTION OF CONTRACT, INDIRECT CONTACT OR CONTACT HIGH, ANY TORT, FORT, WORT,
SNORT OR OTHERWISE, ARISING FROM, OUT OF, AROUND
THE SIDE OF,
UNDERNEATH, UP ABOVE, SIDEWAYS, OR IN CONNECTION WITH THE SOFTWARE OR
THE USE OF OR OTHER DEALINGS IN THE SOFTWARE, IF YOU POKE OUT YOUR EYE WITH
A SHARP STICK, OR ANY OTHER GENERAL BITCHING
YOU MAY BE UP TO.
THIS PRODUCT MAY INCORPORATE IMPLEMENTATIONS OF CRYPTOGRAPHIC ALGORITHMS
THAT ARE REGULATED (E.G., SUBJECT TO EXPORT/IMPORT CONTROL REGULATIONS) OR
ILLEGAL
IN SOME COUNTRIES. IT IS SOLELY YOUR RESPONSIBILITY TO VERIFY THAT IT IS LEGAL
TO IMPORT
AND/OR (RE)EXPORT AND/OR USE THIS PRODUCT (OR PORTIONS THEREOF) IN COUNTRIES
WHERE YOU
INTEND TO USE IT AND/OR TO WHICH YOU INTEND TO IMPORT IT AND/OR FROM WHICH YOU
INTEND TO
EXPORT IT, AND IT IS SOLELY YOUR RESPONSIBILITY TO COMPLY WITH ANY APPLICABLE
REGULATIONS,
RESTRICTIONS, AND LAWS.
IOW, even if your head explodes while using any HoG software, don't come crying
to me. But
if you get video of that, it would be cool.
Copyright 2010, Timothy "Thor" Mullen, Hammer of God
Top